< Chris_Stewart_5>
Has anyone had to deal with using bitcoind as a dependency with travis ci? Is there a way to get them to whitelist it's use in -regtest mode?
< sipa>
?
< sipa>
why would it need a whitelist?
< Chris_Stewart_5>
It looks like travis-ci bans people that use bitcoin as a dependency in .travis.yml
< bitcoin-git>
bitcoin/master b8251f6 John Newbery: [tests] allow zmq test to be run in out-of-tree builds
< bitcoin-git>
bitcoin/master 83073de Wladimir J. van der Laan: Merge #10307: [tests] allow zmq test to be run in out-of-tree builds...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10307: [tests] allow zmq test to be run in out-of-tree builds (master...fix_zmq_test_out_of_tree) https://github.com/bitcoin/bitcoin/pull/10307
< bitcoin-git>
bitcoin/master 185c7f0 Matt Corallo: Avoid reading the old hd master key during wallet encryption...
< bitcoin-git>
bitcoin/master d3dce0e Wladimir J. van der Laan: Merge #10115: Avoid reading the old hd master key during wallet encryption...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10115: Avoid reading the old hd master key during wallet encryption (master...2017-03-cleanup-sethdmasterkey) https://github.com/bitcoin/bitcoin/pull/10115
< bitcoin-git>
bitcoin/master 91c91e1 John Newbery: Control mempool persistence using a command line parameter....
< bitcoin-git>
bitcoin/master a750d77 John Newbery: Add tests for mempool persistence...
< bitcoin-git>
bitcoin/master 2a183de Wladimir J. van der Laan: Merge #9966: Control mempool persistence using a command line parameter...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9966: Control mempool persistence using a command line parameter (master...mempoolpersistenceoption) https://github.com/bitcoin/bitcoin/pull/9966
< jnewbery>
wumpus did you see my comment on #10225? It's causing test runs to fail intermittently for me. Can we revert it until it's had some review?
< wumpus>
just commenting out the test so it doesn't run automatically would be enough I guess
< jnewbery>
yes, that would solve the immediate problem, but I'd also like to make sure that the test gets some review. I had a bunch of review comments for the PR which I didn't add because it wasn't even running reliably for me
< wumpus>
no matter waht, comments must be addressed in a new PR
< wumpus>
it's not possible to unmerge and reopen a PR
< jnewbery>
can we do something like: new PR or commit to remove the test entirely, and then PR it again
< wumpus>
I guess if no one fixes it, we can remove the test again at some point
< wumpus>
I don't really see how that is better than just disabling the test (so it can still be run manually) then fixing its problems while it's not blocking travis, but okay...
< jnewbery>
because the test is unreviewed and untested. I think we *should* have the test, I'd just like it to go through a review process before it gets merged :)
< BlueMatt>
jonasschnelli: i believe there was previously discussion of just always not having tray icons
< jonasschnelli>
Yes. Removing the tray makes sense... though, to prevent distraction, we shouldn't hurry. The option was a good start IMO
< jonasschnelli>
I mean "removing the tray icon".
< jonasschnelli>
OSX has already deprecated those "global menu icons" since years. Because it looks like that every new application wants to place a icon there and mostly the space is limited to just a handfull.
< jonasschnelli>
I guess it's similar on Ubuntu/Windows.
< jonasschnelli>
But all new application ignore these deprecations. :)
< jonasschnelli>
Dropbox / Adobe / VMWare, etc.
< wumpus>
ubuntu is going to drop unity anyhow
< wumpus>
so the problem will go way
< jonasschnelli>
wumpus: There are no such thing like Tray icons in GNOME?
< wumpus>
but yes completely removing tray icon functionality would be a possible future thing too
< wumpus>
jonasschnelli: there are, but that problem shouldn't exist there
< wumpus>
it's a problem specific to how unity intercepts the tray menu
< wumpus>
as I understand, at least
< jonasschnelli>
Okay. Yes. I think as long as users like apps that inject tray icons, we should not hurry with removing the option.
< jonasschnelli>
We could first set the option to false by default
< wumpus>
right
< wumpus>
but as I understand it this problem is specific to unity: it doesn't exist on GNOME, nor KDE
< wumpus>
haven't tested, though.
< jonasschnelli>
Yes. I think so.
< jonasschnelli>
BlueMatt: the current PPA is built with Qt4? Right?
< BlueMatt>
yes
< jonasschnelli>
Hmm... what speaks against Qt5?
< BlueMatt>
wumpus: luke-jr was also complaining about qt5 not working with kde4 folks (do people still use kde4...or kde?)
< jonasschnelli>
Yes. But that orthogonal to the PPA.
< BlueMatt>
true, but it is further reason why we need to support Qt4
< BlueMatt>
(is there even a reason to migrate to qt5)
< BlueMatt>
or, quickly migrate, that is
< wumpus>
well, most software moved away from qt4 by now, so requiring qt4 for the ppa pulls that in, and makes the software look different from other things
< wumpus>
this is a different decision than stopping qt4 support anyhow
< BlueMatt>
how do other projects support qt5 on ubuntu? just no tray icons?
< wumpus>
I think so, yes
< jonasschnelli>
I expect much less maintenance on the qt4 branch. Things like HiDPI, etc. which nowadays is also common on Ubuntu is only possible with Qt5.
< wumpus>
software on linux that adds tray icons is kind of rare
< BlueMatt>
lol, why is all software terrible
< wumpus>
the "correct way" to do tray functionality on ubuntu is to register beneath one of the existing (vendor-provided) tray icons in the tray menu. They have an API for this. Of course, given that it's going to disappear it's not worth spending time on that.
< wumpus>
(if it ever was)
< wumpus>
but e.g. some instant messenger and email clients etc do that
< BlueMatt>
ah
< wumpus>
(probably, ubuntu maintains their own patches for that)
< BlueMatt>
<BlueMatt> lol, why is all software terrible
< wumpus>
why is all terrible
< BlueMatt>
fair point
< luke-jr>
BlueMatt: Qt5 doesn't adapt to Qt4, *and vice versa*. KDE 4 is rapidly becoming Windows XP. I think we're okay to drop Qt4 entirely as soon as it becomes a burden, but changing builds to use Qt5 ASAP is a good idea.
< wumpus>
the bitcoin.org builds have been using qt5 for considerable time, it's just the PPA using qt4
< luke-jr>
Ubuntu is no longer Unity; I'm guessing we still support an older Unity-based version though?
< wumpus>
there's no Ubuntu no-Unity release yet afaik? I just meant that starting from there we can switch it to qt5
< luke-jr>
is there a way to make debs use a different version based on their target?
< luke-jr>
(parazyd - the guy who opened that PR - 's target is Knots on Devuan FWIW)
< wumpus>
"On 5 April 2017 Mark Shuttleworth announced that Canonical's work on Unity will end and that Ubuntu 18.04 LTS, a year away from release at the time, will abandon the Unity desktop and employ the GNOME 3 desktop instead"
< wumpus>
yes he's using KDE5, which doesn't work with qt4 all too well, so I understand his concern
< BlueMatt>
luke-jr: all debian builds have the release hardcoded
< BlueMatt>
well, for uploads to ppa/debian builds/ubuntu builds
< BlueMatt>
manual builds ignore that
< luke-jr>
I thought for PPAs you upload once and it built for everything? :o
< BlueMatt>
nope, it gets uploaded like 5 times
< luke-jr>
ew
< luke-jr>
BlueMatt: it would be nice if there was a gitian descriptor that produced the files to upload btw ;)
< BlueMatt>
the files to upload is pretty much just the debian/ folder from contrib/debian and a copy of the git archive, all signed by my pgp key
< BlueMatt>
not sure how useful it would be, then, unsigned :p
< luke-jr>
there isn't something that requires a Debian-based OS to generate?
< BlueMatt>
I dunno, I use the debian tools to upload, but used to use the debain tools on arch, even
< BlueMatt>
now its in a vm
< sipa>
i thought PPA was ubuntu-spdcific
< luke-jr>
it is
< BlueMatt>
PPAs are, but the tools to upload to them are debian-generic
< luke-jr>
BlueMatt: well, it'd be nice to have that VM turned into a gitian descriptor simply for convenience IMO; gitian as an automating tool rather that determinism tool ;)O
< BlueMatt>
luke-jr: yes, but there'd be no point in anyone but me using it?
< BlueMatt>
so why bother?
< BlueMatt>
its already dead-simple to do
< luke-jr>
BlueMatt: well, you don't want to maintain a PPA for Knots I assume?
< BlueMatt>
just copy contrib/debian into debian and run dpkg-buildpackage
< BlueMatt>
you need to add ppaname to some config file
< BlueMatt>
but ofc thats the part that is me-specific
< BlueMatt>
not gitian-able
< BlueMatt>
also your pgp key name has to match the top entry in debian/changelog for dpkg-buildpackage to sign it right
< luke-jr>
your daily and RC PPAs seem dead since 2011 btw
< BlueMatt>
im aware
< BlueMatt>
they need to be deleted, probably
< Lauda>
Is 'walletpassphrase' supposed to return 'null' now on correct entry of pass?
< wumpus>
it always did AFAIK
< wumpus>
on failure it throws an error, on success it returns NullUniValue
< Lauda>
It may just be me, but I haven't noticed 'null' up until today on 0.14.1
< Lauda>
Thanks for clarifying though!
< BlueMatt>
luke-jr: i cant add people to the "bitcoin" team on launchpad because adding people means they get instant upload rights....so adding people needs to be a public process of "this person is gonna get PPA upload rights"
< wumpus>
Lauda: might be that the GUI now displays it differently?
< Lauda>
wumpus IIRC the GUI never returned 'null', that's why it surprised me (it had an empty line or something). Again, might be me :l
< luke-jr>
BlueMatt: hmm, no way to add me with just a second PPA for knots?
< BlueMatt>
luke-jr: I dont believe so, but may be wrong
< luke-jr>
weird
< wumpus>
Lauda: ah I think I remember now, IIRC that was changed because an empty line was confusing people
< Lauda>
maybe in 0.14.0 (just tested that one, as it also has null). Thanks :D
< luke-jr>
BlueMatt: dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../bitcoin_0.11.0.orig.tar.{bz2,gz,lzma,xz}
< BlueMatt>
luke-jr: you need to create a git archive with the listed name :p
< luke-jr>
dpkg-source: info: local changes detected, the modified files are: bitcoin/source/clientversion.cpp
< BlueMatt>
yes, and the source has to match the git archive exactly, so the git archive magic in clientversion.cpp needs to be updated accordingly
< BlueMatt>
really you're supposed to just untar the release source (which for us is git archive)
< luke-jr>
not the gitian-generated tarball?
< BlueMatt>
i suppose it doesnt matter?
< BlueMatt>
i mean you can upload any source you want, i use git archives
< luke-jr>
the latter has clientversion correct and configure generated :D
< BlueMatt>
ehh, I'll stick with autogen on launchpad, doesnt matter
< jtimon>
mhmm, travis wasn't launched for #9494 on last rebase... wumpus can you or someone else make it happen or should I just push with a different commit id or something?
< gribble>
https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] RHavar closed pull request #10100: Make ApproximateBestSubset optimize for amount of inputs (master...coinselection) https://github.com/bitcoin/bitcoin/pull/10100
< sipa>
sorry, i think in my own branch names rather than PRs
< BlueMatt>
ah, k
< sipa>
dbcache was 6.3G at that point though, and 2.7G on disk after flushing
< BlueMatt>
sipa: still missing lots of context...how do those numbers compare to previously :p
< BlueMatt>
(esp cache size)
< sipa>
BlueMatt: yeah, i haven't done a rigorous benchmark on this system recently, so i can't tell
< sipa>
i was just surprised by a reindex of 1.5h
< sipa>
maybe that's due to improvements in master i'm not aware of, or maybe my memory is faulty :)
< BlueMatt>
or assumevalid
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10330: fix zapwallettxes interaction with persistent mempool (master...zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10330
< jnewbery>
sipa: I may be wrong, but I think that your travis issue is with the unit tests rather than bitcoin-util-test.py. Compare: https://travis-ci.org/bitcoin/bitcoin/jobs/228344728 . I think the final line in your output:
< jnewbery>
indicates that bitcoin-util-test.py has returned and you're now running the unit tests
< sipa>
jnewbery: sounds plausible
< sipa>
any idea on how to find out which test is the cause?
< luke-jr>
I'm not sure the UAWITNESS service bit in BIP 149 is sufficient. At the very least, relying on service bits is a bad idea.
< luke-jr>
what happens if a malicious node sends 0.14.1 a segwit block when BIP9 didn't activate? will it permanently flag it as invalid and never reconsider a stripped version?
< abpa>
Don't you have the same issue if SegWit 2 is proposed with BIP9 over again?
< luke-jr>
abpa: possibly. changing the dummy byte may workaround this.
< jnewbery>
how reproducible is this on travis? Perhaps you could update the travis/make config to run the unit tests with verbose output?
< sipa>
jnewbery: i have 2 PRs which reproducibly failed in 1 or 2 builds, both windows builds
< sipa>
how do i run the tests verbose?
< jnewbery>
sipa: test_bitcoin --log_level=all if you're running them manually, but that produces a lot of output. I haven't looked at how you'd update makefiles/travis config to do this
< sipa>
jnewbery: i cannot reproduce it locally
< sipa>
ok
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10331: Share config between util and functional tests (master...shared_util_function_test_config) https://github.com/bitcoin/bitcoin/pull/10331
< sipa>
ARM does not have an rdtsc instruction, and clock_gettime has much higher precision than gettimeofday
< sipa>
i guess it does not matter that much... because on OSX we'll always be on a platform that does have rdtsc
< cfields>
sipa: opposed to using std::chrono::high_resolution_clock ?
< sipa>
ah!
< cfields>
(i assume it's just an abstraction around clock_gettime for *nix)
< sipa>
checking how it is implemented; thanks for the suggestion
< cfields>
np
< * sipa>
is slightly scared about these things, after seeing how useless the std::random_device implementations can be...
< cfields>
to answer your question, in case this doesn't work out, in the "AC_SEARCH_LIBS([clock_gettime]", just add a third argument. Do the AC_DEFINE there.
< sipa>
(a library call, to be clear... but no conversion anywhere)
< cfields>
oh, nice :)
< cfields>
sipa: static_assert(std::ratio_greater_equal<std::chrono::high_resolution_clock::period, std::nano>::value == true, "no nanosecond precision");
< cfields>
zero instructions for that one :)
< sipa>
cfields: that compiles fine on mingw, even though the result only has microsecond precision
< sipa>
(it always returns numbers that are multiples of 1000)
< cfields>
hmm
< sipa>
what output do you get on osx from my snippet?
< cfields>
nano
< cfields>
1033378907044228
< cfields>
1033378907124163
< cfields>
...
< cfields>
oh sorry, got that static_assert backwards. That should be ratio_less_equal
< cfields>
with that change, mingw fails to compile for me.
< sipa>
still compiles fine here
< cfields>
sipa: to avoid multiples of 1000 with microsecond precision, you can use: "auto value = std::chrono::duration_cast<std::chrono::high_resolution_clock::duration>(epoch);"
< cfields>
(though it sounds like your mingw is lying to you about precision at compile-time, so that may not help)