< achow101>
is the zmq_test failing for anyone else?
< achow101>
(in rpc tests)
< jonasschnelli>
jnewbery: jeremyrubin: I can hold back the PR. There is no hurry. Lets firs aim on the one you have listed above
< gmaxwell>
jonasschnelli: I happened to see the list recently, and I think you shouldn't waste your time arguing with people who are philosophically opposed to supporting encryption. These people are acting in a way which is harmful to human rights and wellfare. I do not know if they are confused or if they are working for state actors which are opposed to personal freedom, or what. But it's a waste of ti
< gmaxwell>
me. Support for encryption and authication is completely optional and if other people want to use it it simply isn't any of their busienss.
< jonasschnelli>
gmaxwell: Yes. That had cost me a lot of time and nerves... :)
< jonasschnelli>
Thanks!
< jonasschnelli>
gmaxwell: What I really dislikes is that those guys tried to enflame others and it partially worked... that's why I was commenting on some of the concerns
< luke-jr>
gmaxwell: or possibly scared of what State actors opposing encryption might do to them/Bitcoin
< gmaxwell>
luke-jr: if so, then they're arguing dishonestly... and I can't see a reason to do that.
< luke-jr>
hm
< gmaxwell>
If someone argued that adding encryption to Bitcoin would make some state actors hate bitcoin, I think that could be pretty easily refuted.
< * wumpus>
running gitian builds to check pre-rc1
< Victorsueca>
wumpus: you're going to tag 0.14 rc1 today?
< wumpus>
Victorsueca: unless there is a critical issue, that's the plan
< Victorsueca>
wumpus: anything that needs some extra testing on windows?
< wumpus>
argh my dev/build machine died, that's not a good start of the day...
< Victorsueca>
RIP
< wumpus>
building bitcoin core apparently breaks power supplies now :-) things should be back to normal, restarting testing gitian builds in a bit
< gmaxwell>
libsecp256k1 easily overheats cpus.
< luke-jr>
building it⁇
< gmaxwell>
for libsecp256k1? running the tests... which you hopefully do at build time!
< Victorsueca>
I'm making the depends and it's downloading samba ccache, is that new or it just got updated?
< Victorsueca>
ffs, it's downloading everything again, not sure why
< Victorsueca>
I hate building boost
< wumpus>
building boost should be very quick, at least from depends, we have restricted that to only build the modules and variants that we actually use
< wumpus>
building qt on the other hand...
< wumpus>
we have done the same there - select only what we need, but GUI toolkits are beasts
< Victorsueca>
problem with boost is not nly the time it takes, it's quiet, there's nothing more stressing than that, you don't know if it's still building or it got stuck
< wumpus>
I'm pretty sure there's a flag to make it verbose, if you want that
< bitcoin-git>
bitcoin/0.14 1a02ecc Wladimir J. van der Laan: doc: Update release notes from wiki
< wumpus>
will do that in a bit
< cfields>
did a full gitian build of linux/win/osx as of a few commits ago (afae75fd3da). So far, linux/osx test_bitcoin pass, osx gets reliable rpc test failure: http://pastebin.com/raw/7mgt7jsQ
< wumpus>
argh
< cfields>
will re-test from 0.14 after the latest importmulti changes
< wumpus>
and it doesn't happen with normal build of the same, just gitian?
< wumpus>
I don't remember that issue on travis so probably
< cfields>
wumpus: i haven't tried an osx build from the same spot, i'll do that at the same time as the 0.14 rebuild
< Arvidt>
Is it better for Bitcoin to run a full node, or is it also ok ok to run a pruned node with 100 GiB (-prune=100000) ?
< wumpus>
when running a pruned node it doesn't matter what the size is, no pruned node will serve blocks
< wumpus>
so if you want to provide blocks to other nodes that are bootstrapping, you need to run a non-pruned node, at least currently
< Arvidt>
ok, thanks for the info. There is very few information about pruned mode in the internet, only bitcoiin core release notes and some bitcointalk thread that are two years old.
< bitcoin-git>
bitcoin/0.14 268c390 Wladimir J. van der Laan: doc: Update manpages for 0.14.0
< cfields>
wumpus: local build passes :\. Waiting for gitian built to finish so i can compare.
< wumpus>
ok, hopefully it was a false positive
< cfields>
wumpus: yes, that tests passes on 0.14. Still waiting for the whole suite to finish, but looks like a false alarm
< achow101>
I had an rpc test failing yesterday, I'm checking again now on master to see if it still fails
< achow101>
yeah, zmq_test.py still fails for me
< cfields>
ok, all osx pass
< cfields>
wumpus: need to bump the gitian descriptors if we want separate package caches for 0.13/0.14. Will PR now.
< bitcoin-git>
[bitcoin] theuni opened pull request #9783: release: bump gitian descriptors for a new 0.14 package cache (0.14...gitian-descriptor-bump) https://github.com/bitcoin/bitcoin/pull/9783
< Chris_Stewart_5>
We have a specific test in script_tests.json that pads R values and doesn't require DERSIG flag
< wumpus>
cfields: I had no idea that we were still using the 0.13 dependencies for master
< bitcoin-git>
[bitcoin] laanwj closed pull request #9783: release: bump gitian descriptors for a new 0.14 package cache (0.14...gitian-descriptor-bump) https://github.com/bitcoin/bitcoin/pull/9783
< cfields>
wumpus: it doesn't matter a ton. The chain is hashed and it always grabs the right deps based on the recipe. Splitting just lets you keep them separate, so you can stash 0.13 away if you want, to save time for 0.13.3 build
< wumpus>
cfields: right
< gmaxwell>
release notes still say nothing about the massive performance improvements. Shall I write something?
< bitcoin-git>
bitcoin/0.14 871e19a Wladimir J. van der Laan: doc: Add list of authors to release notes...
< wumpus>
sure, that'd be very welcome, release notes can be updated until the final release
< wumpus>
still need to add the big list of changes too
< cfields>
gmaxwell: i started to a few days ago but got distracted. I'm unsure if we want to just add a "performance increases" section and add a bunch of stuff, or add individual features and mention what they speed up
< gmaxwell>
Perfmrnace increases with a line per improvement might be nice.
< cfields>
gmaxwell: works for me. Have you already started, or shall I?
< gmaxwell>
Go ahead. Hm. I thought I wrote release notes for assume valid.
< gmaxwell>
that certantly should be release noted, esp as someone might feel its a security model change (at least without the explination)
< gmaxwell>
oh Idid and it was just all removed. :(
< cfields>
gmaxwell: sure, and imo it goes under performance improvements. Not sure if that's what you were implying. But to an end-user, that's surely the benefit
< gmaxwell>
It is a performance improvement but unless explained it could be understood as a significant security model change.
< gmaxwell>
Can someone please explain to me why the release note for that was removed?
< wumpus>
what was removed? you should edit the release notes in 0.14, not on master
< wumpus>
master was completely cleaned out
< gmaxwell>
wumpus: doing that means that changes that write their release notes get their notes nuked.
< sipa>
gmaxwell: ?
< wumpus>
gmaxwell: this has been the case for every major release
< sipa>
things that are merged in 0.14 have their notes in 0.14
< wumpus>
0.14 is branched off, master is 0.15 now
< gmaxwell>
so was -0.14.0 Fundrawtransaction change address reuse
< wumpus>
gmaxwell: wasn't that just moved somewhere else?
< achow101>
the problem was that some things got into the release notes in the repo, and others were in the wiki
< wumpus>
it's in the wrong place after all, in the section reserved for PRs
< wumpus>
so my assumption was that it was moved upwards, but if it got removed it should be added back (in the right place)
< gmaxwell>
wumpus: it was in the notable changes section, and no it's nowhere mentioned in the release notes now.
< wumpus>
ok, re-add it then
< gmaxwell>
At least I know what happened now!
< gmaxwell>
I think we do want changes writing their own release notes, no? we'll just need to figure out how to merge that with the wiki.
< gmaxwell>
(in the future)
< wumpus>
gmaxwell: I apparently missed that when merging changes from the wiki; I saw some stuff was removed, but Ithought it were just the items in the wrong place that were merged back
< wumpus>
in the future we should pay attention to changes, just like you did now, good job
< wumpus>
:)
< cfields>
sipa / gmaxwell: any notable perf improvements from libsecp256k1 for 0.14? I'm hazy on the timeline
< wumpus>
is it something that affects end users much?
< gmaxwell>
yea, kinda sad because that was a relly impressive work.
< gmaxwell>
a secondary purpose of release notes, its also a communication channel about what we're doing.
< gmaxwell>
(and interesting to)
< gmaxwell>
the only effect on users was that it avoided some build problems with openssl api changes that some people expirenced later.
< wumpus>
the release notes for 0.13 were already huge, if there are too many notable changes no one is going to read everything
< wumpus>
I think it's fine to not add a specific paragraph for everything
< wumpus>
i'm certainly in favor of publishing awesome developer changes in bitcoin core, but I'm not sure the release notes is the right place for that
< wumpus>
a tech blog on bitcoincore.org would be nice
< gmaxwell>
That is fair too.
< gmaxwell>
But who has the time?
< wumpus>
well if you'd have the time to add it to the release notes, you'd also have time to write a blog post, those are equivalent time-wise
< gmaxwell>
release note would have been one/two paragraphs, would make for a kind of lame blogpost. :P
< wumpus>
brg444 did a nice writeup on bitcoin core performance improvements
< gmaxwell>
but there could be summary posts, I suppose with things that weren't important enough to usage to go into the release notes.
< wumpus>
why? not everything needs to be a long story
< wumpus>
short, frequent updates are good too
< Chris_Stewart_5>
The Chronicles of Bitcoin Core (TM)
< gmaxwell>
I hope he hasn't published that yet, it didn't have measurement last I saw and was weaker without it... unfortunately it takes so long to sync with older versions it takes a while to get numbers! :)
< wumpus>
I don't think he has, but I like that it puts everything into context
< gmaxwell>
wumpus: Thanks, good points.
< gmaxwell>
Yea, I saw a draft too... I should check again, it was missing a bunch of stuff but I bet he's added it now.
< gmaxwell>
We have two stack protector not protecting compiler warnings on 0.14 branch, might want to consider fixing in the next RC if they're trivial fixes.
< cfields>
gmaxwell: ah, nice. I've been trying to figure out how to state the net performance improvements in a meaningful way. Full IBD from before/after seems pretty reasonable.
< wumpus>
what causes those?
< wumpus>
and I don't think I've ever seen those warnings, what gcc/clang gives them?
< gmaxwell>
"running newer compilers" :P
< gmaxwell>
httprpc.cpp: In function ‘bool HTTPReq_JSONRPC(HTTPRequest*, const string&)’:
< gmaxwell>
which made no sense to me but I figured there was some kind of over-my-head c++ magic happening.
< luke-jr>
I get them with 4.9.4
< wumpus>
I'm fairly sure I didn't *intend* that when writing that code at least
< wumpus>
so I'm curious
< gmaxwell>
I agree the test isn't so important, but the users compiling seeing warnings isn't ideal. Certantly lower priority.
< wumpus>
I also think it's strange it comes up now
< sipa>
i've seen that warning for months, at least
< wumpus>
shouldn't that warning have been there for ages?
< gmaxwell>
it's been there for a while but I ignore warnings in master because they're usually eliminated before release, didn't realize that most other people weren't seeing it.
< wumpus>
oh and you just mention it now just before a release, ok :/
< gmaxwell>
Actually I have mentioned it once before.
< gmaxwell>
but I thought everyone else was seeing it too.
< gmaxwell>
Sorry.
< sipa>
building from scratch with 6.2.0 now, i'll report the warnings i get
< sipa>
/usr/bin/ar: `u' modifier ignored since `D' is the default (see `U')
< wumpus>
I don't think it's a big deal but I want to know what is causing a variable sized buffer there
< sipa>
httprpc.cpp: In function ‘bool HTTPReq_JSONRPC(HTTPRequest*, const string&)’:
< sipa>
httprpc.cpp:150:13: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]
< wumpus>
variable-sized buffers on the stack are usually a code stink
< wumpus>
honestly I thought the practice died in the 90's
< sipa>
(several more 'u' modifier warnings)
< jonasschnelli>
I think we should mention the AES change there...
< jonasschnelli>
(in the release notes)
< wumpus>
yes the modfifier warnings are well-known, there's an issue open for those IIRC
< gmaxwell>
jonasschnelli: what aes change?
< jonasschnelli>
Sorry,.. I hadn't scrolled down...
< gmaxwell>
:P
< sipa>
jonasschnelli, wumpus, gmaxwell: how about we first move all the AES mode of operation code into ctaes (it's currently in crypto/aes.cpp), and then write a blog post about ctaes in general
< jonasschnelli>
I just saw a discussion about ctaes
< sipa>
/usr/include/boost/type_traits/detail/bool_trait_def.hpp:18:78: note: #pragma message: NOTE: Use of this header (bool_trait_def.hpp) is deprecated
< sipa>
# pragma message("NOTE: Use of this header (bool_trait_def.hpp) is deprecated")
< sipa>
leveldb/db/memtable.cc: In member function ‘void leveldb::MemTable::Add(leveldb::SequenceNumber, leveldb::ValueType, const leveldb::Slice&, const leveldb::Slice&)’:
< sipa>
leveldb/db/memtable.cc:104:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
< wumpus>
I'm not usually for disabling language features, but I can see no good coming out of this one
< cfields>
wumpus: sounds good. There was another case like that a while back wrt hashing, I guess that was fixed at one point
< gmaxwell>
that one seems safe but we should be very cautious about werror... compilers change warning detection all the time and then crap won't compile for users.
< cfields>
sipa / gmaxwell: can you comment on whether -Werror=vla blows up on the old code?
< sipa>
cfields: let's check
< wumpus>
especially if it silently makes functions vulnerable by disabling the stack cookie
< wumpus>
gmaxwell: agreed, Werror certainly shouldn't be enabled generally
< cfields>
gmaxwell: Werror= allows you to only error on specific warnings
< gmaxwell>
VLAs aren't so bad... they have good uses, but I agree we shouldn't have them in our codebase.
< gmaxwell>
cfields: yes but many warnings change their behavior. As I said, vla sounds safe.
< gmaxwell>
but many other warnings change their specific triggers from version to version.
< wumpus>
while building w/ gitian, not while running it, mind you
< cfields>
^^ should get rid of the "NOTE: Use of this header (bool_trait_def.hpp) is deprecated")"
< achow101>
wumpus: lol
< achow101>
is the tag still happening today?
< cfields>
wumpus: would you like release notes additions PR'd directly to 0.14, i assume?
< wumpus>
achow101: yes, in a minute
< luke-jr>
"Out-of-sync Modal Info Layer" looks like something that can be removed from release notes to trim it down
< wumpus>
cfields: yes, editing the wiki has little sense now, we should probaly add a warning there
< cfields>
ok
< luke-jr>
" - After resetting the options by clicking the `Reset Options` button in the options dialog or with the `-resetguioptions` startup option, the user will be prompted to choose the data directory again. This is to ensure that custom data directories will be kept after the option reset which clears the custom data directory set via the choose datadir dialog."
< luke-jr>
^ where did this change happen? I don't see any code for this behaviour
< wumpus>
I'm not aware of any other changes there (and log -p confirms this)
< luke-jr>
oh, does it preserve *and* reprompt? :o
< wumpus>
anyhow, time to tag
< sipa>
ack tag
< jonasschnelli>
\O/
< wumpus>
* [new tag] v0.14.0rc1 -> v0.14.0rc1
< sipa>
\o/ \\o o//
< wumpus>
\\o//
< cfields>
woohoo!
< sipa>
you have 4 arms? that explains!
< wumpus>
if only :)
< gmaxwell>
that symbol is a tutrle on its back.
< wumpus>
gitian will probably have to rebuild all dependencies as the gitian-depends version was bumped
< gmaxwell>
flip him over!
< jonasschnelli>
heh
< achow101>
\o/
< wumpus>
cfields: we should not forget to bump the depends version to 0.15 on master as soon as possible so that we don't have this problem next time
< cfields>
wumpus: indeed. I'm cheating and symlinking for now.
< cfields>
will PR that in just a min.
< wumpus>
yeah I thought about that too, but I'm not doing that, want to be sure to get the right output
< wumpus>
I'd be the person to symlink the wrong directory then get a wrong executable, spend hours debugging that, and lose a lot of time compared to... simply rebuilding everything :p
< achow101>
luke-jr: it preserves and reprompts the datadir
< jonasschnelli>
Can you just gpg sign the gitian assets file on a different machine? No need for the descriptor, right?
< wumpus>
jonasschnelli: yes, see "signing externally" in gitian-building.md
< jonasschnelli>
wumpus: Thanks... great.. wasn't aware of that doc part
< instagibbs>
nice work :)
< wumpus>
you can also pass -p true to gsign to make it skip the call to gpg complately
< wumpus>
but it doesn't matter whether you do that or let the gpg call fail, it's the last statement in gsign, in both cases you can copy the unsigned assert file and detach-sign it yourself
< gmaxwell>
the CLANG vs GCC VLA warning on hash.h is an example of why we should -Wvla but not error on it.
< sipa>
gmaxwell: from investigating briefly, it seems that VLAs are standard in C99 but optional in C11. They're not specified in C++ or C++11.
< gmaxwell>
Apparently their analog is in C++14, std::dynarray and "runtime sized arrays" (exactly the same syntax as VLA but: sizeof works, and they can't be multidimensional)
< luke-jr>
eh? sizeof works with C99 VLAs..
< luke-jr>
or is that a GNU extension?
< gmaxwell>
luke-jr: sorry, I wasn't clear, I was saying that it does not work in the C++14 spec.
< luke-jr>
oh
< * luke-jr>
wonders if we should remove "About Qt" from the menu. It seems (without knowing the languages) translators are interpreting "Qt" as "Bitcoin-Qt"
< sipa>
luke-jr: i've noticed that too
< sipa>
in past times, it seems "Qt" was even understood to refer to the bitcoin core program name
< gmaxwell>
it's kind of confusing in any case. like... "information no one ever wants"
< luke-jr>
other Qt apps used to have it, but I don't think many (if any) do anymore
< luke-jr>
in KDE apps, it's just "About <app>" and "About KDE"
< achow101>
I thought it was required as part of the license that Qt uses