--- Day changed Thu Sep 15 2016
00:08 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-jcmiqzzflvizwaoe] has quit [Ping timeout: 265 seconds]
00:10 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-itusvovcfdzicgvj] has joined #bitcoin-core-dev
00:15 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-mpgyffmrauxeavgv] has joined #bitcoin-core-dev
00:16 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-mpgyffmrauxeavgv] has quit [Client Quit]
00:17 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-upchjwuqyoijfnjx] has joined #bitcoin-core-dev
00:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:47 -!- cdecker [~cdecker@184.68.38.206] has joined #bitcoin-core-dev
01:02 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev
01:10 -!- cdecker [~cdecker@184.68.38.206] has quit [Ping timeout: 240 seconds]
01:18 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev
01:20 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 265 seconds]
01:33 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev
01:48 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
01:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds]
02:11 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
02:11 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
02:11 < GitHub156> [bitcoin] jonasschnelli opened pull request #8735: [Wallet] add option for a custom extended master privat key (xpriv) (master...2016/09/hd_set_seed) https://github.com/bitcoin/bitcoin/pull/8735
02:11 -!- drizztbsd is now known as timothy
02:41 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
02:44 -!- rebroad_ [~rebroad@183.89.38.148] has quit [Ping timeout: 260 seconds]
02:49 < dcousens> wumpus: oh, I wanted to mention.  And all other things aside.  A small RPC cache works wonders for reducing some of the performance issues with high loads (10-20 mb)
03:08 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
03:10 < GitHub24> [bitcoin] wjx opened pull request #8736: base58: Improve DecodeBase58 performance. (master...speedup-decodebase58) https://github.com/bitcoin/bitcoin/pull/8736
03:13 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Quit: laurentmt]
03:14 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
03:14 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
03:14 -!- drizztbsd is now known as timothy
03:42 < GitHub86> [bitcoin] paveljanik opened pull request #8737: Trivial: UndoReadFromDisk works on undo files (rev), not on block files. (master...20160915_Undo_error_message_fix) https://github.com/bitcoin/bitcoin/pull/8737
03:52 -!- rebroad_ [~rebroad@223.205.85.90] has joined #bitcoin-core-dev
03:57 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
03:58 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
04:30 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
04:51 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:11 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
05:12 -!- paveljanik [~paveljani@79.98.72.216] has joined #bitcoin-core-dev
05:12 -!- paveljanik [~paveljani@79.98.72.216] has quit [Changing host]
05:12 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
05:21 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
05:21 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
05:25 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Ping timeout: 250 seconds]
05:26 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
05:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:47 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 276 seconds]
05:49 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
05:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
05:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:54 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
05:56 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Excess Flood]
05:57 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
06:38 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 265 seconds]
06:39 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []
06:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 244 seconds]
06:43 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 244 seconds]
06:47 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
06:47 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
06:49 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
06:51 -!- cryptapus [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev
06:51 -!- cryptapus [~cryptapus@66.119.84.15] has quit [Changing host]
06:51 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:09 -!- ganger [~ganger@223.73.1.39] has joined #bitcoin-core-dev
07:22 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
07:27 -!- wjx [~quassel@123.120.20.66] has quit [Remote host closed the connection]
07:27 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Quit: laurentmt]
07:44 < GitHub111> [bitcoin] rebroad closed pull request #8729: More granular debug (master...MoreGranularDebug6) https://github.com/bitcoin/bitcoin/pull/8729
07:46 -!- ganger [~ganger@223.73.1.39] has quit []
08:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
08:05 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
08:10 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
08:14 -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev
08:16 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 255 seconds]
08:16 -!- e4xit_ is now known as e4xit
08:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:36 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
08:41 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
09:02 < phantomcircuit> jonasschnelli: poke 8696 updated to address nits
09:06 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
09:08 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
09:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
09:32 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
09:40 < GitHub112> [bitcoin] sdaftuar opened pull request #8739: [qa] Fix broken sendcmpct test in p2p-compactblocks.py (master...fix-cb-test) https://github.com/bitcoin/bitcoin/pull/8739
09:40 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-core-dev
09:40 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
09:49 -!- cryptapus_ is now known as cryptapus
10:04 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
10:10 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
10:26 -!- echonaut1 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]
10:27 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev
10:37 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 265 seconds]
10:56 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
11:29 -!- cryptapus [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev
11:29 -!- cryptapus [~cryptapus@66.119.84.15] has quit [Changing host]
11:29 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
11:42 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has left #bitcoin-core-dev ["Leaving"]
11:42 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has joined #bitcoin-core-dev
11:48 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev
11:52 < paveljanik> wumpus, jonasschnelli: here is a rough QT -Wshadow commit (https://github.com/paveljanik/bitcoin/commit/f9d00d7e624a6760a099ca61caca25d7982844d1). I'd like to hear what you like or dislike about such changes or what to do in some other way.
11:54 < paveljanik> E.g. using member initializers instead in some places etc.
11:54 < jonasschnelli> phantomcircuit: newline nits: https://github.com/bitcoin/bitcoin/pull/8696/files#diff-b2bb174788c7409b671c46ccc86034bdR2518
11:54 < jonasschnelli> phantomcircuit: I prefere modeIn instead of _mode
11:54 < jonasschnelli> But consider it as nit
11:54 < paveljanik> for ~qt we already agreed on _...
11:55 < jonasschnelli> Okay. Fair enought.
11:55 < jonasschnelli> _ look always after instance vars IMO
11:55 < jonasschnelli> But maybe because of my Obj-C past
11:56 < jonasschnelli> phantomcircuit: But the change-set looks good!
11:56 < jonasschnelli> ah. meant paveljanik 
11:56 < paveljanik> it is a bit huge :-(
11:57 < paveljanik> and there are still two other issues, but they are more serialization related than qt/
11:57 < paveljanik> and I do not like how I solved this-> stuff because it can be a lot nicer.
11:58 < jonasschnelli> Maybe split it into parts? But I don't care. I'm happy to merge it at once. Its fairly reviewable.
11:59 < paveljanik> this itself is a part ;-)
11:59 < cfields_> jonasschnelli: completely agree, but i didn't want to create noise :)
11:59 < jonasschnelli> Ah. Okay then. :)
12:00 < sipa> DING
12:00 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-core-dev
12:00 < jonasschnelli> meeting?
12:00 < petertodd> pong
12:00 < cfields_> (about _foo being member)
12:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:00 < kanzure> greetz.
12:00 < paveljanik> peng
12:00 < sdaftuar> hi
12:00 < jonasschnelli> cfields_, paveljanik: do we already make use of _var instead of varIn?
12:00 < cfields_> jonasschnelli: yea, in the PRs that are already in
12:01 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
12:01 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #bitcoin-core-dev
12:01 < jonasschnelli> #startmeeting
12:01 < lightningbot> Meeting started Thu Sep 15 19:01:19 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < jonasschnelli> topic proposals?
12:01 < MarcoFalke> proposed short topic: EOL 0.11
12:02 < jonasschnelli> #topic EOL 0.11
12:02 < cfields_> I'll only be around for ~30 min before I have to head out.
12:02 < MarcoFalke> #link https://github.com/bitcoin-core/bitcoincore.org/pull/211
12:02 < wumpus> if we're following the same schedule as usual, 0.11 was EOL at the moment 0.13 was released
12:02 < sipa> except critical fixes?
12:02 < jonasschnelli> agree with wumpus
12:03 < MarcoFalke> it is about critical fixes
12:03 < wumpus> security problems may be an exception
12:03 < MarcoFalke> We should set a date when we no longer fix critial issues
12:03 < gmaxwell> I thought 0.11 was EOL when 0.13 was released, except for whatever exceptions we decide...
12:03 < jeremyrubin> nheren
12:03 < wumpus> but usually no new executables will be built, just simple backports
12:03 < sipa> gmaxwell: agree
12:03 < petertodd> ack EOL; you can always run 0.11 behind a 0.13 node if you need too
12:03 < sipa> so we need to get https://bitcoincore.org/en/lifecycle/ updated?
12:04 < kanzure> i think the concern was that 0.11 was not marked as EOL, not that it wasn't considered EOL.
12:04 < MarcoFalke> Jup, note that I already changed maintenance end to 2016-08-23
12:04 < wumpus> yes the bitcoin.org page needs to be updated
12:04 < wumpus> +Core
12:04 < achow101> If 0.11 is EOL, then what about 0.10?
12:04 < sipa> ah, so 0.11 is not EOL but maintenance end
12:04 < sipa> EOL means not even security critical backports
12:05 < sipa> according to that website
12:05 < gmaxwell> achow101: it was unmaintained as of january or so.
12:05 < achow101> gmaxwell: but it is still marked as receiving critical updates on bitcoincore.org
12:05 < jonasschnelli> According to bitcoincore.org 0.10 has EOL in 2017
12:05 < sipa> but 0.10 should be EOL at 2016-08-23
12:05 < morcos> it seems to me that ending security critical backports depends not just on how old the release is but on how many people are still using it
12:05 < gmaxwell> what morcos says.
12:05 < wumpus> and how difficult it is to backport/test
12:06 < morcos> ha ha, of course!
12:06 < wumpus> I mean if it's just updating a dependency library like upnp...
12:06 < gmaxwell> the reality is that it has nothing to do with dates. We're not actively seeking to maintain these versions but will do what it takes to protect the ecosystem.
12:06 < sipa> sure, but the reason for having a clearly stated policy is so that people can make informed decisions about what to run
12:06 < MarcoFalke> ^
12:06 < wumpus> I think this will always be a discussion people can't really agree on
12:06 < MarcoFalke> We should communicate the EOL in advance
12:06 < luke-jr> frankly 0.12 seems like EOL before 0.14 at this rate
12:06 < petertodd> gmaxwell: setting expectations also can help protect the ecosystem
12:07 < gmaxwell> We also continue to see no feedback from parties that would prefer to use a 0.old.next over a 0.new.hottness. :)
12:07 -!- cryptapus [~cryptapus@87.254.202.229] has joined #bitcoin-core-dev
12:07 -!- cryptapus [~cryptapus@87.254.202.229] has quit [Changing host]
12:07 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
12:07  * jonasschnelli still count 569 0.10.x peers with status "good" on his seeder
12:07 < morcos> agreed with all, but i'm saying we should be supplementing our discussion with #'s of nodes running 0.10, 0.11
12:07 < sipa> i wish we had more insight in users' needs... that there would be requests of the form "wait! no! i can't upgrade to 0.12 yet for reason X, but we really need updated for now"
12:07 < wumpus> in practice it's indeed not about dates, but if someone cares about using/maintainging it
12:07 < BlueMatt> am I the only one who wasnt aware of that page? I mean I dont think a strict N-monghts schedule really works, so we'd need to all be thinking about it/aware of it, at least, to make it reasonable
12:07 < wumpus> it seems to be 0 people
12:07 < gmaxwell> Which supports the view that effort spent supporting older versions is of negative value.
12:07 < luke-jr> wumpus: maintaining it is not practical without testing/usage
12:07 < petertodd> morcos: so many nodes are run because users "want to contribute" - I wouldn't read too much into that number. Equally, a lot of nodes are likely spy-nodes...
12:07 < wumpus> luke-jr: right it's a chicken egg problem
12:08 < sipa> wumpus: that's a fair characterization of reality, but perhaps that page should reflect that
12:08 < kanzure> BlueMatt: i think it's something like "people should be following the mailing lists and announcement mailing lists and the webpage, although apparently the webpage is out of sync with reality for the moment"
12:08 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 240 seconds]
12:08 < wumpus> yes, updating the webpage to reflect reality would make sense
12:08 < BlueMatt> kanzure: hmm? people shouldnt have to follow the ml to find out if their node is EOL...we should have some kind of information for users, but devs have to be aware that it exists for it to be accurate :p
12:08 < gmaxwell> If we were being completely pragmatic we would probably say that we only support the very latest thing put out at all.-- this is all that I can tell people are upgrading to. But I think that is a bad principle and the fact that the only thing people upgrade to is the latest thing is an aspect of industry immaturity which will hopefully go away.
12:08 < luke-jr> wumpus: I maintained old versions back to 0.4 for years with no indication of real usage or feedback - the first few got some testing, but after a while it never made it past RC
12:09 < petertodd> fwiw I've never gotten any feedback from python-bitcoinlib users complaining about non-backwards-compatible changes
12:09 < luke-jr> IMO we *should* have longer support, but it just doesn't seem feasible with softforks
12:09 < wumpus> the point of creating that webpage was to have an easier available place where release maintenance status was available, but yes if it runs out of date with reality then at some point it's only confusing
12:09  * BlueMatt wishes there was an "ask the community" button for this kind of thing....
12:10 < petertodd> BlueMatt: too bad we got rid of the alert system... /ducks
12:10 < kanzure> wumpus: probably a good fix would be to have a checklist for releases, and add EOL webpage updates to that checklist.
12:10 < wumpus> and it should reflect how things are, not how we think ideally they should be
12:10 < sipa> we could make node software automatically show a warning X months after being released...
12:10 < luke-jr> kanzure: we do have release-process.md
12:10 < kanzure> well is it in there?
12:10 < luke-jr> sipa: +1
12:10 < wumpus> kanzure: there's one in the release process, but there is already so much stuff there. I don't thin kthe assumption should be that the same person does all that
12:10 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-core-dev
12:11 < kanzure> "EOL" not found in that doc, nor variations of it.
12:11 < petertodd> sipa: signal does that actually - they forgot the timer expired once and scared a bunch of people
12:11 < kanzure> wumpus: sure, sure, perhaps it's multiple people. but a checklist can still be helpful regardless of number of people that use it.
12:11 < BlueMatt> petertodd: is that automated? heh, yea, maybe
12:11 < achow101> has anyone actually tried asking the community? like posting on reddit, bitcointalk, etc.
12:12 < luke-jr> petertodd: if we stagnate for 12 months, something else is wrong
12:12 < wumpus> I think we should first document how things are clearly on the site, and only then worry about maybe changing it
12:12 < btcdrak> oh sorry I am late
12:12 < jonasschnelli> The problem is probably not what the community want, its more what the team is capable of delivering
12:12 < gmaxwell> achow101: we've posted asking for feedback on older versions many times in the past, and also called for testing on old support backups.
12:12 < wumpus> exactly jonasschnelli
12:12 < jonasschnelli> Its an OSS, if people want longer EOL, they should contribute
12:13 < gmaxwell> I've also gone 1:1 to several companies. Mostly we've recieved complete silence. scanning the network (and watching inbounds) also shows that adoption of point releases after a new major is out is basically non-existant.
12:13 < wumpus> as I've said before I have nothing against maintaining old releases if someone really commits to that
12:13 < sipa> that's fair... we're only so many people, and review for backports is a significant burden
12:13 < luke-jr> I'm happy to go back to maintaining stable versions longer if people will actually use it (and can't upgrade)
12:13 < gmaxwell> jonasschnelli: or at least speak up.
12:13 < wumpus> but I've never seen much interest, so reality is, it doesn't
12:13 < kanzure> i don't know what to think about re: automatic warnings after timelapse.   as long a there's some good reason to think it' dissimilar from automatic updates, i suppose..
12:13 < jonasschnelli> gmaxwell: right.
12:13 < wumpus> kanzure: I don't know what to think about it either
12:13 < kanzure> didn't mean to impose on wumpus with the checklist suggestion
12:14 < luke-jr> maybe update EOL page, and mention the lack of usage as the reason, suggesting if people want it, they should get in touch
12:14 < jonasschnelli> Luke-Jr: +1
12:14 < BlueMatt> ok, so lets post something on the ml or so that says "We're gonna stop doing this, but would very much love to hear if anyone actually wants it" and then link to that from reddit/emails/twitter/whatever
12:14 < BlueMatt> yea, that
12:14 < gmaxwell> stop doing what?
12:14 < gmaxwell> I am really confused.
12:14 < BlueMatt> stop supporting backports
12:14 < BlueMatt> beyond like one or two versions, maybe
12:14 < wumpus> kanzure: I really don't like time-locks in programs. Though this would just be a warning I guess... but it could be intimidating
12:14 < gmaxwell> We have a stated policy, we maintain one major version behind. 
12:14 < luke-jr> gmaxwell: stop promising backports we aren't really doing anyway
12:14 < gmaxwell> BlueMatt: we already did that, like, a yea ago.
12:14 < jonasschnelli> stop doing sound negative... something more like "...we are concentrating ressources on X"
12:15 < gmaxwell> year*
12:15 < sipa> BlueMatt: "beyond one version" is exactly what the page says
12:15 < BlueMatt> s/one or two versions/one or so point releases/
12:15 < luke-jr> wumpus: might be good to make the time limit fuzzy, so not everyone gets hit at the same time
12:15 < btcdrak> Seems there's a lot of discussion here which was _already)_ covered in previous meetings and is detailed in the Lifecycle document https://bitcoincore.org/en/lifecycle/ tldr maintenance and EOL are two different things.
12:15 < luke-jr> perhaps 1 year from when it was installed?
12:15 < gmaxwell> what btcdrak says
12:15 < BlueMatt> sipa: gmaxwell to be fair, the website doesnt say that
12:15 < wumpus> well then add it to the website!
12:15 < wumpus> everyone can submit pulls there you know
12:15 < btcdrak> I suggest people re-read the Lifecycle page after the meeting :)
12:15 < wumpus> we can spend an hour discussing what should be added to the website, or just add it
12:16 < jonasschnelli> #action update Lifecycle page on bitcoincore.org
12:16 < Chris_Stewart_5> ^
12:16 < kanzure> luke-jr: cool idea. fuzzy random noise time-delay notifications.  (hopefully nobody proposes "intentionally low performance over time until someone thinks to get a new version")
12:16 < BlueMatt> ok, next topic
12:16 < gmaxwell> BlueMatt: read the "Maintance period" section on the site, I think it's completely clear.
12:16 < wumpus> any other topics?
12:16 < jonasschnelli> #into hackdays in milan: http://coredev.tech/nextmeeting_tmp.html
12:16 < wumpus> 0.14 release schedule maybe
12:17 < jonasschnelli> Its a temporary page.. not public yet. But feel free to register
12:17 < wumpus> I've posted a proposal for the 0.14 release schedule here: https://github.com/bitcoin/bitcoin/issues/8719
12:17 < jonasschnelli> #topic 0.14 release schedule
12:17 < MarcoFalke> sounds fine
12:17 < sipa> yes, sounds good
12:17 < jonasschnelli> yes. fine for me
12:18 < btcdrak> looks good to me
12:18 < wumpus> I'll mail it around on the mailing lists if there are no issues with it
12:18 < BlueMatt> yea, looks good now
12:18 < CodeShark> +1
12:18 < wumpus> ok great!
12:18 < kanzure> jonasschnelli: you have a typo in your form ("your are")
12:18 < morcos> wumpus: my only thought is 0.13.1 release is a bit of a heavy lift, and depending on when that happens, it may seem like 0.14.0 is coming up quite quickly...  but i don't feel strongly about it
12:18 < jonasschnelli> kanzure: ill give you edit right. :)
12:18 < wumpus> morcos: it's already a month later compared to 0.12 was this year
12:19 < MarcoFalke> No worries. I am sure the will be last-minute blockers for 0.14.0
12:19 < wumpus> morcos: postponsing major releases for minor releases makes very little sense I think
12:19 < wumpus> 0.14 will have lots of new features, 0.13.1 will not
12:19 < morcos> wumpus: yeah i was only pointing out that 0.13.1 is not minor in a lot of ways..  but if others are fine with it, i don't object
12:20 < wumpus> morcos: I agree with that
12:20 < luke-jr> ? 0.13.1 should only be fixes + softfork
12:20 < btcdrak> yes.
12:20 < wumpus> luke-jr: it is
12:20 < morcos> anyway, seems not its a widely shared concern, so lets stick with the schedule
12:20 < gmaxwell> having a short gap between releases would be a good problem to have. :)
12:20 < BlueMatt> yup
12:20 < jonasschnelli> #topic 0.13.1 release
12:21 < wumpus> it's a minor release strictly, just a lot of code changes, so you can jokingly call it 'major'
12:21 < btcdrak> Here are the remaining PRs and issues for 0.13.1 https://github.com/bitcoin/bitcoin/milestone/22
12:21 < btcdrak> #link https://github.com/bitcoin/bitcoin/milestone/22
12:21 < sdaftuar> i wanted to suggest that we consider dropping some of those PRs from the 0.13.1 milestone
12:21 < btcdrak> sdaftuar which in particular?
12:21 < wumpus> sdaftuar: specific suggestions?
12:22 < BlueMatt> nulldummy as softfork?
12:22 < sdaftuar> 8654 is one
12:22 < kanzure> was there a mempool issue still open for 0.13.1.. don't see it listed there.
12:22 < BlueMatt> I figure I'd get yelled at, but I'm not convinced
12:22 < CodeShark> Is the mempool dos thing still urgent?
12:22 < kanzure> ah there it is.
12:22 < sdaftuar> that's a performance optimization that i think is not urgent
12:22 < kanzure> (8279)
12:22 < btcdrak> I recall sipa saying #8635 may not be essential for 0.13.1
12:22 < luke-jr> I reviewed a few merged fixes and commented on a few that they should be backported. Did someone with tagging access get to tag those?
12:23 < jonasschnelli> Luke-Jr: I'll have a look
12:23 < MarcoFalke> luke-jr: I think I did
12:23 < jl2012> i think #8635 may be dropped for 0.13.1
12:23 < sipa> agree
12:23 < jonasschnelli> jl2012: what do you think about https://github.com/bitcoin/bitcoin/pull/8654?
12:23 < btcdrak> ok let's untag it
12:23 < sipa> i'd like to see 8654 in
12:23 < btcdrak> *untag 8635
12:24 < luke-jr> ACK dropping 8635 for 0.13.1
12:24 < btcdrak> I guess the big blocker is #8393 compact blocks.
12:24 < jonasschnelli> untagged
12:24 < wumpus> #decision dropped #8635 for 0.13.1
12:24 < luke-jr> jonasschnelli: if that's strictly an optimisation, it should wait for 0.14
12:25 < jonasschnelli> sipa: why did you want to see 8654 in 0.13.1?
12:25 < wumpus> luke-jr: depends on whether it's an optimisation or an 'optimisation' (e.g. - DoS fix)
12:25 < gmaxwell> btcdrak: thats ... working fine for me, but we probably need to do a bit more organized testing. sdaftuar was updating some tests for it.
12:25 < luke-jr> wumpus: right, hence "if" ☺
12:25 < btcdrak> gmaxwell: well it's fine to merge afaik, but there was some discussion about the BIP text which is blocking it afaik
12:26 < btcdrak> I think #8636 is ok to merge.
12:26 < wumpus> that has a lot of ACKs
12:26 < michagogo> Hi
12:26 < wumpus> #action merge #8636
12:26 < wumpus> michagogo: hey!
12:27 < gmaxwell> Can someone make a list of all PR's merged for master that are not in 0.13 so we can check to make sure we haven't missed any that need backport?
12:27 < morcos> oh i was going to vote against 8636 as well
12:27  * BlueMatt isnt a huge fan of 8636 in 0.13.1
12:27 < morcos> i haven't reviewed it and don't necessarily have any concrete concerns
12:27 < wumpus> gmaxwell: all that still need backport should have the 'needs backport' tag
12:27 < wumpus> https://github.com/bitcoin/bitcoin/labels/Needs%20backport
12:27 < BlueMatt> its just more stuff for segwit that could easily fit in another softfork
12:27 < michagogo> Sorry, not too around -- was with my grandmother (my grandfather passed away on Sunday), and now shopping with the family.
12:27 < gmaxwell> assuming they got tagged.
12:27 < BlueMatt> better to push any more complication further
12:27 < luke-jr> gmaxwell: I did, but I may have missed some. (minor ones I didn't comment on, and have a local list I can backport myself)
12:27 < wumpus> (including what is already merged)
12:27 < morcos> but just seems it possibly hasn't been thought about enough to know there isn't a hidden risk like jl2012 found low-s
12:28 < gmaxwell> it's an istandardness rule
12:28  * michagogo wonders if zu will become the new 11
12:28 < btcdrak> morcos: it's already a standard rule
12:28 < gmaxwell> oh you're talkign about nulldummy sorry.
12:28 < BlueMatt> gmaxwell: yea, sorry, nulldummy...I'm more ok with adding standard rules for things we want to softfork out soon
12:28 < wumpus> michagogo:  hah, luckily the C parser doesn't accept it as number
12:29 < wumpus> otherwise some magic constants should be defined as zuzuzuzu, especially on windows
12:29 < jl2012> #8499 actually somehow depends on nulldummy softfork
12:29 < luke-jr> #define zu 11
12:30 < luke-jr> fixed C parser
12:30 < jl2012> it still works, just can't protect CHECKMULTISIG
12:30 < morcos> re: nulldummy, ok so if we think its got sufficient technical review, and we also think its technical enough it doesn't need more community discussion (for instance never appears in chain?) then ok wiht me
12:30 < sipa> i think the risk for nulldummy is very low
12:30 < petertodd> nulldummy is very, very simple
12:30 < jl2012> since without a softfork, we can't DoS ban a peer sending us a violating transaction
12:31 < sipa> jl2012: well we can't generally do that anyway
12:31 < sipa> an attacker node can always pretend to be an old version
12:31 < jl2012> for segwit tx we could
12:31 < gmaxwell> we could for Sw things however, as it doesn't have transisiton issue.  
12:31 < cfields_> crap, gtg. wumpus: not a meeting topic, but I noticed that the libevent unit tests fail for the zu case. We should consider running unit tests for deps somewhere.
12:31 < cfields_> bbl
12:31 < jl2012> 8499 is for segwit only
12:31 < luke-jr> sipa: if it's bundled with segwit I think we can?
12:31 < gmaxwell> But we could ban without the softfork in such a case too.
12:32 < sipa> luke-jr: an old node can always pretend to be pre-segwit
12:32 < gmaxwell> There is no need to link those behaviors though we have previously.
12:32 < wumpus> cfields_: yes did you see https://github.com/bitcoin/bitcoin/pull/8730?
12:32 < luke-jr> but then it won't have witness data at all
12:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:32 < wumpus> cfields_: running libevent tests would make some sense, yes, although we'd first need a travis run on ubuntu 16.04
12:32 < sipa> luke-jr: so? it's an attacker node. it just won't send segwit txn
12:32 < cfields_> wumpus: yes, I'm still making my way through that problem.
12:32 < sipa> it can make up all its transactions
12:32 < gmaxwell> in any case, I only think that its urgent to at least have these behaviors non-standard.
12:33 < cfields_> wumpus: indeed, it was just a general thought
12:33 < luke-jr> sipa: afaik the proposal is to ban Nulldummy-violating sw txns
12:33 < sipa> luke-jr: to ban nulldummy-violation sw *peers*
12:33 < sipa> so an attacker will just not be an sw peer
12:33 < wumpus> cfields_: at least that one's easy to fix, the -stack-protector-all problem is more worrying
12:34 < wumpus> cfields_: anyhw better to speak of this outside the meeting some time
12:34 < jl2012> sipa: I think it's to ban segwit-nulldummy-violation peers
12:34 < sipa> jl2012: ok
12:34 < morcos> too many conversations
12:34 < sipa> same thing
12:34 < sipa> morcos: agree
12:34 < luke-jr> well, whether it's useful or not is another matter - maybe it isn't
12:34 < sipa> what is the topic?
12:34 < jonasschnelli> 0.13.1
12:34 < morcos> in summary i'm happy to let you guys decide what should go into 0.13.1 and what shouldn't, as i have been a bit out of the loop
12:34 < jonasschnelli> (nulldummy)
12:35 < wumpus> 0.13.1 still
12:35 < morcos> however i just want to raise the concern that maybe we're putting a lot of things in very quickly at the end
12:35 < gmaxwell> welcome back
12:35 < morcos> and that should cause us to be nervous
12:35 < sipa> i think nulldummy is very low risk, but also not very useful
12:35 < gmaxwell> :)
12:35 < morcos> when already the segwit activation is going to be a lot to pay attention to
12:35 < BlueMatt> 0.13.1 - various things...I think morcos, sdaftuar and I generally arent a fan of all these policy and various things coming in last minute before 0.13.1, but, I think we've all been out of the loop so maybe they have more review than we think
12:35 < sipa> it should happen at some point, and perhaps doing it together with segwit is easier
12:35 < btcdrak> morcos: in all fairness, these PRs have been worked on over quite a long time.. they arent out of the blue.
12:36 < BlueMatt> maybe nulldummy is ok, but still, so many things happening at the same time is a review burden and complicates things further
12:36 < btcdrak> you need to sync up on the conversations / background of them
12:36 < sipa> BlueMatt: yes, i don't like that either, but i think we just discovered many things to improve
12:36 < BlueMatt> when segwit is already complicated
12:36 < BlueMatt> sipa: ok, lets do it in a later sf
12:36 < BlueMatt> ?
12:36 < BlueMatt> i mean sf-able things, that is
12:36 < gmaxwell> it's unclear whats being discussed now.
12:36 < BlueMatt> and maybe if policy isnt as restrictive as we'd like in 0.13.1, thats ok
12:36 < sipa> nulldummy sf
12:37 < btcdrak> the only sf is nulldummy, the rest is just policy standardness.
12:37 < jonasschnelli> Didn't we had this discussion already and where mostly for including nulldummy sf together with SW in 0.13.1?
12:37 < gmaxwell> bluematt is talking about many, if the discussion is limited to nulldummy whatever.
12:38 < gmaxwell> But the policy changes are more important.
12:38 < wumpus> yes I think trying to stash a lot of changes into 0.13.1 has caused some delays already, at the least we shouldn't be adding anything else now and focus on what is there getting in
12:38 < gmaxwell> jonasschnelli: yes, we did. 
12:38 < luke-jr> IMO nulldummy isn't worth all the time we're spending disucssing it now.
12:38 < jonasschnelli> https://bitcoincore.org/en/meetings/2016/09/01/#nulldummy-and-lows-softfork-proposals
12:38 < Chris_Stewart_5> Do we have a tentative release date for 0.13.1 or feature freeze? 
12:38 < gmaxwell> wumpus: that isn't what happened. We had specific necessary to fix issues related to SW specific moderate risk denial of service attacks, and the path to fixing them spun off a number of sub isues along the way.
12:38 < wumpus> if you discover any other nice improvements they can wait until next version, unless it's critical to deployment of segwit
12:38 < jonasschnelli> cfields_: no
12:39 < jonasschnelli> Chris_Stewart_5: no
12:39 < gmaxwell> It's a little frustrating to loop rediscussing the same things over again. Makes the meetings feel like a waste of time, FWIW.
12:39 < wumpus> gmaxwell: agreed
12:39 < wumpus> there are a lot of repeated topics lately
12:39 < jonasschnelli> agree with gmaxwell
12:39 < jonasschnelli> (which is mostly a sign of not made decistions)
12:39 < wumpus> e.g. people that have been out of the loop then bring up something that was discussed a meeting or a few meetings ago
12:39 < wumpus> meetings are not there to bring you up to speed
12:40 < btcdrak> we publish meeting summaries, people should be reading them :-p
12:40 < wumpus> the logs and minutes are available, and summaries are made and published on the site
12:40 < gmaxwell> okay, thats enough probably. :) people get the point.
12:40 < wumpus> and you can always ask about things outside the meeting
12:40 < gmaxwell> (I am glad to not be alone!)
12:40 < BlueMatt> wumpus: IIRC there are folks complaining now who were in favor of it, as there are now 5 related issues that are coming up.....8634, eg, was not previously discussed and is in the same veign
12:41 < BlueMatt> maybe that should be the next topic
12:41 < BlueMatt> otherwise, someone can propose a different topic :)
12:41 < wumpus> BlueMatt: yes, I'm not saying it should be impossible to reconsider things discussed in previous meetings if convinng new reasons come up! just that repeating the same discussions with the same outcomes is not constructive
12:41 < gmaxwell> BlueMatt: thats fine, things can be rediscussed again, but instead of repeating the discussion we should focus on whats changed or whats disagreed with.. a diff rather than a redo.
12:41 < btcdrak> We need some more ACKs on #8634 and #8499 and #8526
12:42 < wumpus> yes
12:42 < wumpus> #action review #8634 and #8499 and #8526
12:42 < sipa> it's not clear what is being discussed. if we're talking about nulldummy sf, i think there is little risk, but little benefit. it was discussed before however, and unless people strongly feel that everything being done is too much, then this is something that can be reconsidered. please don't start reconsidering everything. there are good reasons and they were discussed before
12:42 < btcdrak> then the compact block/BIP thing needs to be finalised so we can merge the compact block pull #8393
12:43 < BlueMatt> sipa: eg, btcdrak just pointed out three prs...two of which i think are optional in 0.13.1
12:43 < BlueMatt> as is nulldummy
12:43 < BlueMatt> now we're in a position where we have a at least 3 prs that are "optional", at least one or two has been previously agreed upon
12:43 < wumpus> nulldummy softwork has been discussed zillions of times in the meeting, everytime the sentiment was slightly in favor of doing it because it has very little risk
12:43 < btcdrak> sipa: it's been well reviewed, and run on testnet for 4 weeks already.
12:43 < BlueMatt> but we want to get this thing out the door without spreading ourselves thin over too much review
12:43 < wumpus> and by now it has lots of testing and review too
12:43 < btcdrak> can we move on?
12:43 < sipa> so let's just stick to it
12:43 < wumpus> so if you want to reconsider it have a very good reason
12:44 < wumpus> not just 'I personally don't like it very much'
12:44 < BlueMatt> btcdrak: "run on testnet for 4 weeks" is the opposite of "good testing"
12:44 < gmaxwell> fwiw, all of my testing lately has been with most of this stack applied.
12:44 < btcdrak> BlueMatt: it's completely trivial, come on. 
12:44 < wumpus> topc nulldummy is over now
12:44 < btcdrak> Is there any thing I can do regarding CB, I'm sort of confused about what is holding it up?
12:44 < wumpus> other topic proposals?
12:45 < sipa> segwit cb?
12:45 < btcdrak> yes please
12:45 < wumpus> #topic segwit cb
12:45 < gmaxwell> yes, I'm also unsure what else is required. I have been testing. 
12:45 < sipa> gmaxwell: the latest version?
12:45 < sdaftuar> i'm working on testing.  i foudn a bunch of problems with the test unfortunately :(
12:45 < sipa> (as of a few days ago)
12:45 < BlueMatt> it was updated a few days ago, afaik only sdaftuar has looked at it since
12:45 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 276 seconds]
12:45 < sipa> i did
12:45 < morcos> i like the concept of the latest version, and looked at the code.  but unfortunately i have to review CB in the first place before i can review the pull, so thats what i'm doing
12:46 < BlueMatt> and sdaftuar is now rewriting the testers for it, so not much to talk about aside from people should look at it?
12:46 < gmaxwell> sipa: as of a week ago? I could check. 
12:46 < morcos> not to say you need to wait for my review of course
12:46 < sipa> gmaxwell: 2 days ago
12:47 < BlueMatt> next topic?
12:48 < gmaxwell> (Fwiw, more segwit traffic on testnet would make live testing of that PR more useful)
12:48 < luke-jr> gmaxwell: where did you guys go btw?
12:48 < gmaxwell> luke-jr: to the photo room.
12:48 < btcdrak> gmaxwell: roasbeef is preparing to produce some load in the next day
12:48 < gmaxwell> btcdrak: okay, I'll try to get things updated to the latest first.
12:49 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
12:49 < jonasschnelli> any other topics?
12:50 < sipa> specifically it would be useful to test connections between 0.13-with-segwit-activation-removed testnet nodes with #8393
12:50 < sdaftuar> sipa: i'm also working on doing that in regtest, fyi
12:50 < sipa> awesome
12:50 < btcdrak> great
12:50 < gmaxwell> sipa: okay, I'll make sure that I run with that too.
12:50 < sipa> thanks
12:51 < luke-jr> would be handy to have some regular segwit spam on testnet in general IMO
12:51 < btcdrak> luke-jr: it's coming, roasbeef is setting something up
12:52 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
12:53 < btcdrak> *silence*
12:53 < jonasschnelli> #endmeeting
12:53 < lightningbot> Meeting ended Thu Sep 15 19:53:41 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:53 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.html
12:53 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.txt
12:53 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.log.html
12:55  * btcdrak looks around
12:56 < btcdrak> I think I entered the twilight zone
12:56  * sipa hands btcdrak a handful of crickets
12:56 < btcdrak> XD
12:56  * petertodd hands btcdrak a cricket of handfuls
12:56 < jonasschnelli> Well,... everyone went reviewing the 0.13.1 PRs
12:57  * btcdrak beer
12:57 < petertodd> jonasschnelli: and I released OpenTimestamps earlier today, and have been up all night :) https://petertodd.org/2016/opentimestamps-announcement
12:57 < jonasschnelli> Saw that! Nice job btw!
12:57  * sipa hands petertodd a giveful of btcdraks
12:57 < petertodd> thanks!
12:58 < petertodd> jonasschnelli: gonna (hopefully!) have a blog post tomorrow morning about the git commit timestamping it does as well
12:58 < petertodd> sipa: "hands.... hands everywhere...."
12:58 < jonasschnelli> petertodd: Yes. I think a "non-technical" description of the possibilities would be nice
12:59 < petertodd> jonasschnelli: I've actually written up (most) of that post already: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md
12:59 < petertodd> jonasschnelli: a step-by-step example of a case where you could use it (e.g. sipa's key compromise) would be good though
13:01 < jonasschnelli> petertodd: your git sig time-stamping is very clever...
13:02 < petertodd> jonasschnelli: yeah, that's a fun hack! I noticed it was possible awhile back, and made a demo of a PGP-signed git commit with signatures from Isis Lovecruft and myself on one commit :)
13:02 < petertodd> jonasschnelli: unfortunately, github shows those sigs as "unverified", but that's a minor problem
13:03 < jonasschnelli> Yes. The github-verified icon is nice. But does not prove anything. :)
13:03 < roasbeef> re testnet segwit spam: would help if we could get more segwit enabled hashpower on testnet and to get those currently mining to limit by max weight (4mil) instead of stripped size
13:03 < petertodd> jonasschnelli: well, if you trust github...
13:03 < roasbeef> err I mean regular size
13:04 < sipa> jonasschnelli: sure it does. as long as you trust github and the companies hosting their hardware.
13:04 < sipa> if.
13:04 < jonasschnelli> kanzure: I gave you edit right on https://docs.google.com/forms/d/1HbJecbEN62r8sL2H0nBjlznmJEa1VDCR_FWC76-qEvo/edit
13:04 < jonasschnelli> Thanks for fixing the typos. :)
13:05 < kanzure> oh.
13:05 < jonasschnelli> sipa: Yes. And probably trust all your browser plugins. :)
13:06 < jonasschnelli> I guess github.com does not include any third-party CDN-ish CSS/JS files..
13:06 < sipa> yes, and you c library, X server, kernel, cpu, motherboard manufacturer, delivery company, ...
13:06 < jonasschnelli> okay. stop. :)
13:07 < btcdrak> roasbeef: will pass it on
13:07 < sipa> (but admittedly, the browser is the easiest target of all of those)
13:07 < luke-jr> sipa: ping
13:08 < sipa> luke-jr: pung
13:17 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-core-dev
13:39 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 276 seconds]
13:40 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 265 seconds]
13:47 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
13:50 < phantomcircuit> jonasschnelli: just the newline?
14:18 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 276 seconds]
14:44 < GitHub48> [bitcoin] laanwj opened pull request #8740: net: No longer send local address in addrMe (master...2016_09_addrfrom_version) https://github.com/bitcoin/bitcoin/pull/8740
14:45 -!- mappum [sid43795@gateway/web/irccloud.com/x-aylckcjxvpzvmyjs] has quit [Ping timeout: 250 seconds]
14:46 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services]
14:46 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Ping timeout: 250 seconds]
14:46 -!- CyrusV [~cyrus@unaffiliated/cyrusv] has quit [Ping timeout: 250 seconds]
14:46 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 250 seconds]
14:46 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 250 seconds]
14:46 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 250 seconds]
14:46 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 250 seconds]
14:47 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:8419:4777:d81c:45e] has quit [Ping timeout: 250 seconds]
14:47 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 250 seconds]
14:47 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 250 seconds]
14:47 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:e1e8:378f:29b1:e12d] has joined #bitcoin-core-dev
14:48 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev
14:48 -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
14:48 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev
14:50 -!- mappum [sid43795@gateway/web/irccloud.com/x-ofdiarglswxvevsu] has joined #bitcoin-core-dev
14:50 -!- mjdecour [~textual@107-147-8-228.res.bhn.net] has joined #bitcoin-core-dev
14:51 -!- CyrusV [~cyrus@unaffiliated/cyrusv] has joined #bitcoin-core-dev
14:51 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev
14:51 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-core-dev
14:52 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev
14:52 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev
14:52 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
14:54 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-core-dev
14:55 -!- aalex [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer]
15:00 < gmaxwell> would it be unreasonable for us to keep a bitcoin-core keyring file that has the pgp keys of all the regulars around here in it?
15:09 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 260 seconds]
15:15 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev []
15:20 < BlueMatt> argh ffs...can we all agree to not use github's fancy new review mode thing? it seems to be breaking github's emails as they are no longer threaded together for a single issue...hopefully they can fix in a day or two but they really broke my bitcoin-email workflow :(
15:20 < BlueMatt> damn github and their not always working perfectly :(
15:20 < BlueMatt> gmaxwell: https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys
15:20 < BlueMatt> we already have that :)
15:21 < gmaxwell> thats gitian, and doesn't include things like morcos' key.
15:21 < midnightmagic> mine's not in there either.
15:21 < BlueMatt> it doesnt include morcos' key because he had +/- never used it until a few days ago...
15:21 < BlueMatt> I had to push his to the keyserver for him :(
15:22 < BlueMatt> gmaxwell: but, I dont see why we shouldnt just include everyone there, whether the folder is renamed from gitian or not :)
15:22 < gmaxwell> right. 
15:22 < btcdrak> seems about right.
15:23 < BlueMatt> oh, it doesnt have you there, gmaxwell :'(
15:24 -!- jnewbery [~jnewbery@67.251.193.154] has joined #bitcoin-core-dev
15:28 < luke-jr> BlueMatt: is there an issue for this on GitHub?
15:28 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-core-dev
15:29 < BlueMatt> luke-jr: dunno, I emailed their support@ alias that has been responsive to me in the past
15:30 -!- jnewbery [~jnewbery@67.251.193.154] has quit []
16:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
16:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
16:37 -!- adiabat [~adiabat@159.203.193.74] has quit [Remote host closed the connection]
16:55 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 244 seconds]
17:22 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Read error: Connection reset by peer]
17:26 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Remote host closed the connection]
17:37 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-core-dev
17:52 -!- rebroad_ is now known as rebroad
17:54 < rebroad> please could someone tell me where I can find the doc on gitian building for windows and arm?
17:54 < rebroad> oh found it
17:55 -!- harrymm [~wayne@104.222.140.120] has quit [Remote host closed the connection]
17:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wmccdywsmlpiopbp] has quit [Quit: Connection closed for inactivity]
17:58 -!- harrymm [~wayne@104.222.140.128] has joined #bitcoin-core-dev
18:18 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
18:32 -!- wjx [~quassel@123.120.20.66] has joined #bitcoin-core-dev
18:45 -!- mjdecour [~textual@107-147-8-228.res.bhn.net] has quit [Ping timeout: 272 seconds]
19:21 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 244 seconds]
19:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:32 -!- mjdecour [~textual@107-147-8-228.res.bhn.net] has joined #bitcoin-core-dev
20:37 -!- jron [~okok@ec2-54-161-129-226.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds]
20:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
20:49 < GitHub14> [bitcoin] fanquake opened pull request #8742: Specify Protobuf version 2 in paymentrequest.proto (master...proto2-vs-proto3) https://github.com/bitcoin/bitcoin/pull/8742
21:41 < GitHub3> [bitcoin] fanquake opened pull request #8743: Remove old manpages from contrib/debian in favour of doc/man (master...remove-old-manpages) https://github.com/bitcoin/bitcoin/pull/8743
21:44 < dgenr8> how does gitian know not to try to build qt for arm?
22:28 -!- cdecker [~cdecker@184.68.38.206] has joined #bitcoin-core-dev
22:31 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
22:48 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
22:48 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
22:48 -!- drizztbsd is now known as timothy
22:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jtmmhoetlnprdfpq] has joined #bitcoin-core-dev
23:11 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
23:28 -!- assder [d4555899@gateway/web/freenode/ip.212.85.88.153] has joined #bitcoin-core-dev
23:49 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host]
23:49 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev
23:53 < jonasschnelli> dgenr8: the configure (autoconf) process will auto-detect the qt libraries..
23:54 < jonasschnelli> If not available, it will be built headless.
23:54 < jonasschnelli> You might want to check the bitcoin-qt.m4 macro file
23:57 < jonasschnelli> dgenr8: and the magic point where qt gets not compiled for ARM is here: https://github.com/bitcoin/bitcoin/blob/master/depends/packages/packages.mk#L7