< gmaxwell>
so then at least we'd have some amount of base diversity, without any offers to support crazy stuff.
< gmaxwell>
"Why won't it bootstrap on BeOS???????"
< cfields>
gmaxwell: I'd just feel honored to be the preimage for BeOS :p
< gmaxwell>
I used to have a BeOS machine in jenkins CI for opus, it was interesting to test on because it made some pretty different calls from linux on optional extensions beyond pure posix.
< cfields>
erm, when was this?
< gmaxwell>
ten years ago. (it was long dead by then too, of course)
< cfields>
ah, ok. I was trying to figure out the overlap between Jenkins and BeOS.
< gmaxwell>
since jenkins uses java you can run most anything java will run on as a remote build target.
< contrapumpkin>
have y'all looked at the Nix builds of bitcoin at all?
< contrapumpkin>
roconnor wrote most of them, but it's a nice baseline to start with
< sipa>
i don't think they're deterministic?
< contrapumpkin>
I don't think so either
< contrapumpkin>
but it's a less heavyweight starting point than a VM for the determinism
< contrapumpkin>
when all your inputs are effectively deterministic modulo meaningless shit
< sipa>
contrapumpkin: i think we pretty much already have all that that does through the depends build system
< Randolf>
contrapumpkin: I recently made a minor contribution by adding instructions for NetBSD support, and there were many developers who took an interest in what I was doing and helped to make it even better.
< Randolf>
contrapumpkin: It seems to me that Unix/Linux support is very good, but I guess you've got some improvements in mind? (If so, great!)
< bitcoin-git>
bitcoin/master 85aa839 Matt Corallo: Hold mempool.cs for the duration of ATMP....
< bitcoin-git>
bitcoin/master 02fc886 Matt Corallo: Add braces to meet code style on line-after-the-one-changed.
< bitcoin-git>
bitcoin/master d57d10e Wladimir J. van der Laan: Merge #12368: Hold mempool.cs for the duration of ATMP....
< bitcoin-git>
[bitcoin] laanwj closed pull request #12368: Hold mempool.cs for the duration of ATMP. (master...2018-02-getrawmempool-race) https://github.com/bitcoin/bitcoin/pull/12368
< gmaxwell>
FWIW, I've had that stack of patches running for a few hours without issue, plus some restart cycles in valgrind.
< wumpus>
yeah, the bech32 dumpwallet one is the one of the bunch that isn't completely straightforward and might require more testing - luckily this will be rc3, not final
< wumpus>
the "address type is whatever there is a label for" part is interesting
< wumpus>
though correct, I think
< gmaxwell>
the alternative construction would be to emit duplicate lines, one with each address we'd accept.
< bitcoin-git>
bitcoin/master 5bdbbdc João Barbosa: Refactor HaveKeys to early return on false result
< bitcoin-git>
bitcoin/master a1ffddb Wladimir J. van der Laan: Merge #12298: Refactor HaveKeys to early return on false result...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12298: Refactor HaveKeys to early return on false result (master...2018-01-ismine-havekeys) https://github.com/bitcoin/bitcoin/pull/12298
< wumpus>
"git log src/crypto/ctaes" shows the last change to ctaes was made a year and two months ago
< wumpus>
maybe it has to do with "git clone --depth=50 --branch=0.16" , will try that
< wumpus>
that's it: at depth 50, it cannot see that it is a subtree
< wumpus>
e.g. the last change to ctaes was more than 50 commits ago, so for a shallow checkout, it's "lost"
< wumpus>
the obvious solution would be to clone deeper, I guess, though it might be kicking the can down the road, I'd say to be robust the check needs to generate a warning in this case but continue
< wumpus>
anyow I'll create a github issue, good to know at least this signals nothing important
< BlueMatt>
wumpus: where are we managing release notes for 16? (or do you want to just make sure that they mention the change in regtest consensus rules causing a CheckBlockIndex() failure on upgrade)
< bitcoin-git>
bitcoin/master 0b9207e practicalswift: Enable flake8 warning for "list comprehension redefines 'foo' from line N" (F812)
< bitcoin-git>
bitcoin/master 4cbab15 practicalswift: tests: Fix accidental redefinition of previously defined variable via list comprehension
< bitcoin-git>
bitcoin/master a9d0ebc practicalswift: Enable flake8 warnings for all currently non-violated rules
< wumpus>
it's currently the same as the one on the 0.16 branch, but you should do editing on the wiki
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #12295: Enable flake8 warnings for all currently non-violated rules (master...accidental-redefinition-of-variable) https://github.com/bitcoin/bitcoin/pull/12295
< BlueMatt>
thanks!
< instagibbs>
i was able to do a couple gitian runs, now compiling rc3 and getting: ./bin/gbuild:21:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
< instagibbs>
ideas?
< bitcoin-git>
[bitcoin] MajorFireball opened pull request #12390: Docs 0.16 - SHA verification for regular people on Windows (master...0.16) https://github.com/bitcoin/bitcoin/pull/12390
< wumpus>
instagibbs: anything in build.log?
< bitcoin-git>
[bitcoin] laanwj closed pull request #12390: Docs 0.16 - SHA verification for regular people on Windows (master...0.16) https://github.com/bitcoin/bitcoin/pull/12390
< instagibbs>
wumpus, pages and pages of file timestamps being from the future, and "Check your system clock" message, followed by exit
< wumpus>
instagibbs: strange, never seen that before
< wumpus>
gitian seems like a gambling machine sometimes
< wumpus>
(though, maybe as a surprising anecdote, here it's been 100% reliable for a long time)
< wumpus>
oh crap, I've just apt-get-upgraded the VM running gitian, this might have been the last time that ^
< achow101>
wumpus: I highly suggest that you never do that because it will break gitian
< wumpus>
so this went to debian 8.x now, not 9
< wumpus>
oh, wrong, /etc/debian_version says 9.3
< wumpus>
no it is 8.10 alright, checked the wrong VM, phew. It would have been really surprising to end up with 9 when just upgrading packages on 8.x. Now let's see if the build still works.
< provoostenator>
instagibbs: I'm also getting " failed to run on-target setarch x86_64 "
< provoostenator>
And that's a fresh Debian 8 that I used for rc2 two days ago.
< provoostenator>
Though I used --setup that time, using -b this time.
< wumpus>
buliding on (upgraded) 8.10 seems to be going ok here
< provoostenator>
My VM clock is totally wrong though, why doesn't Debian sync it?
< Sentineo>
is it just an offset ? it does it for me on lxc ... always gmt
< wumpus>
debian doesn't install as many packages by default as ubuntu does, maybe you need to install the ntp stuff
< wumpus>
always compare date -u against UTC, the timezone shouldn't matter
< provoostenator>
I just installed ntp. Trying gitian again.
< instagibbs>
i thought mocktime somethingsomething was under the hood for these builds
< MarcoFalke>
yeah, why would wall clock time matter
< instagibbs>
provoostenator, please report back, ill hold out
< provoostenator>
That seems to have done the trick.
< provoostenator>
So let's just add installation instructions for ntp to the docs and not worry about why :-P
< achow101>
instagibbs: MarcoFalke I'm guessing that the time of the vm and the time of the lxc container need to be the same so that the vm can send commands to the container
< achow101>
the container has mocktime for the build itself
< wumpus>
yes, having working instruction is more important than knowing why, I've found that usually with time-related problems it's something with SSL certificates or other network communications getting confused about large time differences
< provoostenator>
I wonder what made suddenly made it picky though; I never paid much attention to the time on my gitian machines thus far, and I certainly didn't leave them on non-stop.
< wumpus>
also if your time is too far in the past, any .tar.gz you unpack will have dates in the future, causing problems with make
< provoostenator>
I may however have frozen the state, rather than shutting it down.
< Sentineo>
some daemons refuse to start when time is not going forward, especially network daemons
< instagibbs>
yeah looks like it's fixed
< promag>
jnewbery: do you think bitcoind should auto-set LIBC_FATAL_STDERR_?
< wumpus>
no, bitcoind should not set that, if desired it's intended to be set in the environment by calling process
< promag>
ok, I didn't know that env var
< wumpus>
me neither; it's specific to glibc so will likely not work on other OSes
< wumpus>
PSA: rc3 was tagged earlier today, if you haven't started your gitian build yet, please do so :)
< promag>
topic suggestion, next high priority stuff
< wumpus>
yes
< instagibbs>
provoostenator, you filed an issue for timestamps right?
< wumpus>
#topic high priority for review
< wumpus>
we still have plenty of things in https://github.com/bitcoin/bitcoin/projects/8, but it hasn't been updated for a few weeks because we've effectively used the 0.16 milestone for that, so now that 0.16 has branched it's up for discussion to add/remove things
< jnewbery>
cfields: perhaps the upcoming Core dev tech days is a good opportunity to go through and clear out old PRs?
< wumpus>
achow101: I've added 10583, you already have the coin selection one I think two high prio per person is a good limit
< jtimon>
yeah, there have been no interest in https://github.com/bitcoin/bitcoin/pull/9608 for a while so I'm more inclined to close it than to rebase it at this point unless someone changes my mind
< meshcollider>
hi
< sipa>
could i have some comments on #10785 ?
< instagibbs>
jnewbery, PR triage/close session sounds like a good idea
< jnewbery>
It feels like in-person is the most efficient way to do a bulk purge. Probably most efficient if a set of us make lists beforehand for what we think can be closed
< bitcoin-git>
[bitcoin] instagibbs closed pull request #10360: [WIP] [Wallet] Target effective value during transaction creation (master...feedo) https://github.com/bitcoin/bitcoin/pull/10360
< cfields>
maybe that should've been the last topic :p
< wumpus>
so ocongratulations everyone on rc3! we were reallly fast with the fixes this time
< achow101>
hopefully this will be the last rc
< wumpus>
hopefully, yes
< wumpus>
cfields: at least the closes end up in the meeting log now
< Randolf>
wumpus: Is rc3 available for download?
< wumpus>
Randolf: no, it's just tagged earlier today
< Randolf>
Okay. Thanks.
< wumpus>
but if you have no problems with rc2, it should be ok, rc3 mostly fixed some edge cases
< wumpus>
(to do with initialization and shutdown)
< cfields>
wumpus: heh
< Randolf>
I was planning to try rc2 this weekend. If rc3 comes out first though, then rc3 is where I'll start.
< wumpus>
I think it'll be possible to upload binaries for rc3 tomorrow
< achow101>
have we gotten anywhere with the MPC RSA signing thing?
< Randolf>
That will be great.
< wumpus>
already lots of rc3 gitian sigs
< cfields>
achow101: oh, right
< cfields>
gmaxwell: ping ^^. Any update?
< achow101>
I'm gonna guess that gmaxwell is not here right now
< wumpus>
I guess so too
< instagibbs>
busy with ___root
< wumpus>
I'm also not hearing any other proposals for topics, so this will be a short meeting I suppose
< Randolf>
instagibbs: ...or fork (if he has kids). ;)
< * wumpus>
just merged the rc3 signatures on bitcoin-core/gitian.sigs
< Randolf>
wumpus: Moving away from Boost libraries?
< achow101>
Randolf: he doesn't have kids. I'm pretty sure he hates children
< Randolf>
wumpus: ...as a topic?
< cfields>
wumpus: mine just finished building. We can do binaries today if we get the osx sig :)
< wumpus>
Randolf: is there anything specific to discuss about that? it's been going on, slowly, for a long time
< wumpus>
Randolf: review cfields's PRs!
< Randolf>
wumpus: Well, it seems to me a good idea because Boost libraries have been a problem with getting numerous things compiled on NetBSD. I guess I'm just wondering how things are going on that front.
< Randolf>
sipa: Oh, so there must be a lot of things tied to it then.
< arubi>
yea, missed the ctrl :)
< Randolf>
cfields: Thanks. Wow, there's quite a lot to do there, and I wonder if that's everything that needs to be done.
< wumpus>
there's no hurry in any case
< cfields>
Randolf: short version: I think we'll be able to get rid of a few parts of boost for 0.17, but things like the unit tests will keep it hanging around for a while
< Randolf>
Sure, because it's working.
< Randolf>
cfields: That seems reasonable.
< wumpus>
boost::filesystem can only be replaced in c++17 or so
< cfields>
anyway, we can discuss after the meeting
< Randolf>
Okay.
< wumpus>
will be a while until we can start using that
< cfields>
wumpus: right
< wumpus>
or at least, mandating it, it could theoretically be an option, but meh. I'd recommend you just solve whatever build problems you have with boost and put it behind you for now
< wumpus>
yes, let's close the meeting
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Feb 8 19:28:21 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< Randolf>
I had a terrible problem with Boost many years ago on NetBSD when I was trying to get two different software projects compiled. They both needed different versions of Boost that had conflicting APIs. Backward compabitility seems to be a problem because I ultimately had to either run one of the
< Randolf>
So, I tend to favour the idea of getting rid of stuff like that.
< Randolf>
applications under a chroot or in a VM, or on a different system.
< wumpus>
that's terrible, bitcoind shouldn't have problems like that though, it works with a wide range of boost versions
< Randolf>
Oh, Bitcoin wasn't one of the applications.
< cfields>
Randolf: sounds familiar. Boost is basically the testing project for c++-next. So it's kinda like adding "#include <c++-unstable>" to your project :(
< Randolf>
Oh. Wow.
< jonasschnelli>
Sorry,.. missed the meeting... new timezone. :(
< Randolf>
jonasschnelli: Lots of PRs were closed. It was quick.
< jtimon>
but for C++11 we needed to get rid of some things before worring about changing the build, no? or am I missremembering? my question is more, is there something like that?
< jtimon>
some prerriquisite before even considering moving?
< wumpus>
FWIW a few months ago I built bitcoind with c++17, and there were a few small changes necessary to get it to compile, I can try to find the patch, but nothing serious
< jtimon>
wumpus: awesome, what kind of change ? can I have a look?
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #12392: Fix ignoring tx data requests when fPauseSend is set on a peer (master...2018-02-fix-fpausesend-getdata-resp) https://github.com/bitcoin/bitcoin/pull/12392