00:52:40maaku:maaku is now known as Guest29213
01:51:32maaku:maaku is now known as Guest93855
02:14:19coryfields:wumpus: around by any chance?
02:15:02coryfields:wumpus: merging to gitian descriptors turned out to be more of a pain thatn i had realized. nearly done now. PR tomorrow for 100%.
02:17:38[\\\]:sipa, you about?
02:27:11Guest93855:Guest93855 is now known as maaku
02:29:50Burrito:Burrito has left #bitcoin-wizards
02:32:13Luke-Jr:coryfields: O.o?
02:33:23coryfields:Luke-Jr: moving the action out of the makefiles and into descriptors
02:33:44Luke-Jr:dunno why that's so important >_<
02:34:00Luke-Jr:at least with the makefiles separate, it was possible to build the cross-compiler without gitian :<
02:34:28coryfields:Luke-Jr: yea, i preferred it that way as well
02:34:36coryfields:for the first PR, i'm just trying to make it look like the others
02:34:56coryfields:since that's what was requested at some point
02:36:04Luke-Jr:coryfields: I would notably disagree with combining the dependencies into a single .yml, or putting them in the bitcoin git..
02:36:20Luke-Jr:part of the goal was to have it usable by more than just Bitcoin Core, remember
02:37:39coryfields:Luke-Jr: i agree with you. And I'm maintaining the makefile repo separately...
02:37:51coryfields:but ultimately, it needs to be in bitcoin git if we're going to use it for releases
02:38:16Luke-Jr:that's contrary to the modularisation direction IMO
02:39:48coryfields:the toolchain and dependencies have nothing to do with bitcoin modularization...
02:40:25Luke-Jr:they have nothing to do with bitcoin, hence why they don't belong in a bitcoin repo ;)
02:40:39coryfields:Luke-Jr: and the other gitian descriptors?
02:40:48Luke-Jr:coryfields: such as?
02:41:13Luke-Jr:deps-win32.yml and such, should be ideally split up into single libs and moved to a generic gitian repo IMO
02:41:27Luke-Jr:but that's not necessarily needed to do Mac that way
02:41:40Luke-Jr:not sure why Linux was done that way either..
02:43:07coryfields:i disagree
02:43:14coryfields:gitian is not useful for anything other than shipping releases
02:43:32coryfields:if someone's depending on it for dev, that's their problem imo
02:45:02Luke-Jr:huh? I don't see how that's an argument against anything I said.
02:45:06Luke-Jr:seems like a total change of topic
02:45:27coryfields:that seems like the only logical reason to split them up into single libs
02:45:44Luke-Jr:mac/libz.yml would be just as useful to BFGMiner (for example) as for Bitcoin Core
02:46:00Luke-Jr:but shouldn't need libminiupnp
02:47:53coryfields:Luke-Jr: if bfgminer wants to use our descriptors, that's fine. But I don't see why we should overcomplicate our processes for that
02:48:24Luke-Jr:coryfields: the point is to have generic gitian descriptors so every project doesn't need to reinvent their own yml and dependency binaries
02:48:48Luke-Jr:which also means that as more projects use them, there is less maintenance overhead for us
02:48:51coryfields:Luke-Jr: that's not a goal that i share with you
02:49:28Luke-Jr:coryfields: I believe it was one of the original requirements you accepted for this task.
02:49:43coryfields:Luke-Jr: that task is long-completed
02:49:52coryfields:i'm now interested in actually using it for bitcoin releases
02:50:50coryfields:Luke-Jr: https://github.com/theuni/osx-cross-depends/
02:51:09coryfields:any project can use that. they're split individually.
02:51:35coryfields:if the core devs are comfortable with using that for releases, then that's fine by me.
02:51:47coryfields:I just want to get eyes and testers on it. Currently, that's not happening.
02:51:52Luke-Jr:guess it's my fault for not listing a requirement of having it merged :p
02:52:13coryfields:having what merged?
02:52:31Luke-Jr:nm, doesn't matter now
02:52:41coryfields: coryfields: I would notably disagree with combining the dependencies into a single .yml, or putting them in the bitcoin git..
02:53:28Luke-Jr:mac/bccore.yml obviously is the exception to that
02:54:48Luke-Jr:long-term, I'd personally think the ideal is each library carry its own yml
02:55:11coryfields:Luke-Jr: to be clear, i agree that adding monolithic descriptors for toolchain and depends is a kludge. I don't like it at all. But I'm trying to carry this forward, and that seemed like the most obvious approach
02:56:27Luke-Jr:coryfields: maybe the yml can produce a separate output for each lib at least? then the different dep ymls could be compatible
02:56:28coryfields:Luke-Jr: it'd take something like 15 descriptors. That'd be a nightmare to build
02:56:54Luke-Jr:so what about 1-3 ymls that produce multiple tbz2s/zips?
02:57:03coryfields:that's exactly what i've done
02:57:44coryfields:osx-depends-qt-5.2.1-r2.tar.gz osx-depends-r2.tar.gz osx-native-depends-r2.tar.gz
02:58:20coryfields:oh, not multiple tarballs for each
03:00:26Luke-Jr:any harm in that?
03:00:44coryfields:yea, that drops the notion of a prefixed install
03:01:04coryfields:which breaks my next plan of adding prefix cache files for easy dev use
03:02:58Luke-Jr:* Luke-Jr ponders how difficult it would be to make Gentoo entirely deterministic <.<
03:05:08coryfields:Luke-Jr: anyway, I've got to do _something_ to get this rolling. I really want .9.2 built this way. So I'm going to finish up and PR it. Please comment on the PR. This is just a first step to get it some eyes, I'm very open to better ideas.
04:11:43maaku:maaku is now known as Guest22136
04:50:40Luke-Jr:that was trivial
04:50:52Luke-Jr:I just made distcc so my Gentoo packages are deterministic by default
06:15:26mappppum:mappppum is now known as mappum
07:04:54Luke-Jr:unfortunately, distcc is a pile of terrible spaghetti code, and (blocker) GCC arguments are not really viable to parse outside GCC *sigh*
07:05:21Luke-Jr:and trying to inject a simple hack in GCC seems futile. I can't even find where it calls the preprocessor :|
07:07:21Luke-Jr:BUT, to the limited extent I had distcc working, packages that compiled were deterministic..
09:09:37_ingsoc_:_ingsoc_ is now known as _ingsoc
09:16:55kdomanski_:kdomanski_ is now known as kdomanski
10:44:58HM:HM is now known as HM2
11:49:07wallet421:wallet421 is now known as wallet42
15:09:59c0rw1n:c0rw1n is now known as c0rw|afk
15:38:05Guest73673:Guest73673 is now known as qwertyoruiop
16:44:27amiller:jgarzik, if you haven't looked at it yourself yet, i'm confident saying that eb3full's simbit simulator deserves the bounty you and kjj posted about. https://github.com/ebfull/simbit https://bitcointalk.org/index.php?topic=603171.0
17:30:32wallet42:wallet42 is now known as Guest52904
17:30:32wallet421:wallet421 is now known as wallet42
17:34:36stqism:stqism is now known as ConfirmedMember\
17:34:46ConfirmedMember\:ConfirmedMember\ is now known as Trusted\BCB
17:35:15Trusted\BCB:Trusted\BCB is now known as stqism
18:40:48wallet421:wallet421 is now known as wallet42
19:47:30qwertyoruiop:qwertyoruiop is now known as Guest16037
22:02:22[BNC]dansmith:[BNC]dansmith is now known as dansmith_btc
23:22:01Quanttek_:Quanttek_ is now known as Quanttek
23:26:07amiller:lol https://twitter.com/matthew_d_green/status/466354368640737280/photo/1
23:27:05Emcy:its like a choose-your-ending book from my youth
23:47:14c0rw|afk:c0rw|afk is now known as c0rw1n