17:00:00 #startmeeting 17:00:00 Meeting started Tue Jul 7 17:00:00 2015 UTC. The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:06 o/ 17:00:17 #topic please say hi 17:00:25 hallo :) 17:00:25 huhu 17:00:40 h01ger: (btw, do you know that you can pass an argument of the entire meeting after #startmeeting?) 17:01:22 hi :) 17:01:35 #topic please say hi - agenda is at https://wiki.debian.org/ReproducibleBuilds/Meetings - anything missing there? 17:01:49 AGWA: Faux dkg infinity0 josch lamby Lunar^: meeting starting now! :) 17:02:02 #chair mapreri 17:02:02 LGTM (the agenda) 17:02:02 Current chairs: h01ger mapreri 17:02:11 anybody else wants to chair? 17:02:12 thx 17:02:21 agenda is: 17:02:24 go though last meetings summary and look for unactioned action items 17:02:24 package/issue updates + r.a.d.o repo state 17:02:24 formally agree on "Guidelines for adding a package to the APT archive" in ReproducibleBuilds/ExperimentalToolchain uploads of non toolchain packages 17:02:24 rp.d.n updates+issues 17:02:25 GSoC updates 17:02:25 any other business 17:02:28 announce next meeting 17:02:38 hi :) 17:02:43 Hi. 17:03:10 hello =) 17:03:18 o/ 17:03:25 anything to add to the agenda? 17:03:51 well then 17:03:53 let's go on 17:04:09 * h01ger mapreri to reschedule package where dbd timeouts to see whether they are fixed by dbd 24 17:04:14 did that happen? whats the result? 17:04:30 * h01ger AGWA to investigate/work on getting dh export the SOURCE_DATE_EPOCH 17:04:33 did that happen? whats the result? 17:04:46 dhole took that over, and he did it 17:04:49 * h01ger mapreri to announce the next meeting on the ML 17:04:51 some are gone, some not. Though now we have a few more package where dbd crash. just look at the lists on https://reproducible.debian.net/index_breakages.html 17:05:00 the meeting was announced on the list 17:05:07 h01ger: yeah, i did announce this very meeting :P 17:05:10 :) 17:05:42 we have dbd 26 now anyway, and Lunar^ is rewriting it, so i'd say all action items were acted on. yay! 17:06:05 so next… 17:06:11 probably with the Lunar^ rewrite where the checks are run in parallel quite all the timeouts will be gone 17:06:30 we have two sub topics here today: 17:06:37 1. formally agree on "Guidelines for adding a package to the APT archive" in ReproducibleBuilds/ExperimentalToolchain 17:06:45 2. uploads of non toolchain packages 17:07:11 lets go through them and if someone has another subtopic we can add that as 3rd, 4th, ... 17:07:19 #topic r.a.d.o repo - formally agree on "Guidelines for adding a package to the APT archive" in ReproducibleBuilds/ExperimentalToolchain 17:07:48 https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Adding_a_package_to_the_APT_archive ← comments? 17:07:51 search for FIXME in that URL... 17:08:48 for example, the packages i uploaded there used to target UNRELEASED, not unstable... 17:08:59 to me the guidelines are clear and good as they are, except that i'd like to add a paragraph saying something about "toolchain packages only, for other packages please use Debian experimental" 17:09:27 (which basically is subtopic 2. of this meetings topic..) 17:09:30 i don't think each upload should have a bug filed 17:10:05 for example for dbd tests or so 17:10:12 why not? else its harder to track and if it has no bug its probably not worth fixing 17:10:22 or if you want to first check feasibility before submitting a bug/patch 17:10:33 right. i think dbd and s-d are exceptions 17:10:44 debhelper+dpkg probably too, though i do want bugs for those 17:10:59 s-d => strip-nondeterminsm ? 17:11:06 deki: i also think rp.d.n should be stable… 17:11:07 mapreri: yes 17:11:29 deki: and it also says "guidelines", not "rules" :) 17:11:46 h01ger: ok. i'm fine with it then 17:12:02 in general i agree that bugs should be filed, but there may be exception that make sense 17:12:17 * h01ger nods 17:12:44 h01ger: I uploaded debhelper with support to export SOURCE_DATE_EPOCH but I didn't fill a bug, should I do that? The patch is written against the reproducible git branch, and not upstream 17:13:04 though I'd rewrite that "and have bugs filed in the BTS" with "and possibly have been forwarded to the BTS as a patch", to highlight that whatever test we run there ought to be pushed somewhere else too 17:13:23 ok, i volunteer to improve this howto/guidelines and then you can review the diffs and next meeting we can come back to this and see if we are happy with the result. ok? 17:13:36 Dhole: yes, file a bug please 17:13:59 h01ger: ok :) 17:14:08 h01ger: ok :) 17:14:20 h01ger: ok :) 17:14:27 my current todo is: 17:14:28 mention exceptions: dbd, s-d, debhelper+dpkg 17:14:28 rewrite that "and have bugs filed in the BTS" with "and possibly have been forwarded to the BTS as a patch" 17:14:28 remove FIXME 17:14:58 #agreed h01ger will polish https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain and we will review the result in the next meeting 17:15:19 can we make the abbreviation for strip-nondeterminism s-n or s-nd instead of s-d? :-P 17:15:32 AGWA: totally 17:15:40 s-nd sounds good to me 17:15:49 yeah, I like that a lot 17:16:05 * h01ger will just add "uploads of non toolchain packages" to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain 17:16:36 this was the topic formerly known as "lintian" but we discussed this in the channel already and i think everythings clear... or did someone miss the discussion and wants an update? 17:17:05 s#h01ger will just add…#h01ger will just add something about…# 17:17:11 h01ger: a quick update would be nice 17:17:42 i only quickly looked over the discussion. what was the result of it? 17:17:45 lintian was uploaded to our repo to test some reproducibility patches, but lintian is not a toolchain package 17:18:09 we need some mean to help people test stuff out, something different than "upload to the archive your tests" and also than "try on your computer" 17:18:16 then it showed up in several statistics about how we still need to modify the environment -> skewed stats 17:18:29 then it had to be removed manually -> some work 17:19:04 uploads to experiemental would have also given it testing in our infrastructure, without additional work and without skewing the stats 17:19:53 h01ger: with the difference that doing 2 uploads to exp and waiting for results is something that needs an entire afternoon if you're lucky, while that thing was done in < 1 hour 17:19:59 mapreri: i'd be fine with testing another repo… which is not experimental and where "anybody" could upload.. 17:20:16 yeah, i just need to finish that up :| 17:20:21 "just" 17:20:34 then we also documented how to test locally.. 17:20:42 AGWA: ^ basically that was that 17:20:56 OK, thanks 17:21:30 next topic? 17:21:41 so, let me finish these exams and i'll finish that branch up 17:21:54 :) 17:22:15 though I still don't see the "skewed stats" as a huge problems... we are not a statistic business... 17:22:27 #info mapreri plans to work on adding support for testing a special repo... (for faster tests than in experimental..) 17:22:35 #info faster + more in development... 17:23:05 mapreri: people notice the change in stats and then hunt for the cause -> wasted times 17:23:35 i then got curious where the branchs is, what changes where uploaded why... etc 17:24:39 next topic? 17:24:48 #topic rp.d.n updates+issues 17:25:17 well, just read Lunar^'s report for the updates :) 17:25:24 debhelper with SOURCE_DATE_EPOCH support \o/ 17:25:33 * h01ger plans to test freebsd and thus scheduling on another host next... 17:25:47 what are your urges and itches with rp.d.n? 17:25:58 any wishes what to fix/add next? 17:26:31 h01ger: you wanted to turn notification off by default. let's discuss it? 17:26:41 sure 17:26:46 the most awesome next step would be the 2nd build host imho 17:26:47 i think KGB is too noisy 17:27:28 deki: yeah, after my exams :P 17:27:28 deki: for that as a first step i want to add freebsd since testing with freebsd will not break anything else... 17:27:38 h01ger: ok, sounds good :) 17:27:55 I'm happy with rp.d.n atm; would maybe be nice if some of the page generator jobs were faster or more frequent. No idea what they're doing. 17:28:28 reproducible_html_graph (which generates the dashboards) is slow, because generating all the pkg sets is slow 17:28:42 moving the pkg set generation to python would speed up html_graphs a lot 17:28:55 i'm also wondering if a chroot rebuild could be triggered after there is an upload to our repository (which occurs very rarely. but when it happens, it would be nice to be able to test). 17:29:06 Faux: or do you mean pkg pages after you pushed notes.git? 17:29:28 After the pushing. 17:29:52 deki: for now i recommend to trigger mapreri or me to trigger that manually. adding push hooks to alioth is in the TODO (for many jobs) though 17:30:01 ok 17:30:10 Faux: that would also benefit from push hooks.. 17:30:14 (ftr, i started to move some reproducible_html_graph to py, but given up because it was in a time where h01ger was doing stuff too and every single change i made clashed with his changes, will restart one of these days) 17:30:17 Yeah. 17:30:54 mapreri: as said, i think it would be great+sufficient if you "just" moved the pkg set stuff to python.. should fit nicely into html_indexes.py 17:31:47 deki: Faux: please keep reminding us (me) about push hooks… i think getting the 2nd host support added first is more important but then it seems we should finally implement push hooks 17:31:51 h01ger: FSVO nicely, _indexes is structured in a particular way, umh... don't worry, i'll look at it :) 17:32:00 (for ~200 git repos on alioth...) 17:32:14 nah, probably just 100.. 17:32:18 Definitely; it's a minor itch. 17:32:35 anything else about rp.d.n? 17:33:01 Nope. 17:33:17 btw, anybody reading this who is good in css: i'd like to improve the look of the netbsd/openwrt/coreboot pages... help much appreciated! 17:33:39 #topic GSoC updates 17:33:45 * mapreri hates css 17:34:25 as mentioned before, last week I patched debhelper to export SOURCE_DATE_EPOCH, and uploaded the package in our APT repository 17:35:07 I also wrote a patch for GCC to replace the __DATE__ and __TIME__ macros with the time exported from SOURCE_DATE_EPOCH, and sent the patch to upstream mailing list 17:35:16 https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html 17:35:37 cool! 17:35:44 there's been some discussion, some alternative proposals, but no response so far from the maintainers (which are the ones responsible for accepting or rejecting patches) 17:35:55 also thanks for your weekly reports! likewise to akira! 17:36:02 :) 17:36:08 =) 17:36:09 I worked on doxygen and sbuild last week, this week I want to work on the timestamps_in_pdf_generated_by_latex issue 17:36:31 * dkg seconds holger 17:36:36 akira and Dhole: your reports are great reading and show exciting progress 17:36:36 also very cool! 17:36:52 dkg: thanks :) 17:37:04 doxygen upstream already looked at my patch and he asked some questions but they have not said anything else 17:37:05 Dhole: particularly gutsy to offer a patch to gcc. i think it's great :) 17:37:20 * h01ger seconds dkg ;-) 17:37:37 akira: asking questions is a good sign -- it shows that they're engaged. I'm assuming you've followed up on all their questions? 17:38:02 yup! 17:38:04 Amen. 17:38:05 nice 17:38:24 anything else about GSoC? 17:38:53 that's all for me 17:38:54 we need more students? :> 17:39:12 really, nice work :) 17:39:25 NOOOO NOT OCAML 17:39:28 mapreri: become one? ;-) 17:39:37 #topic any other business 17:40:06 * h01ger is very happy how small https://reproducible.debian.net/unstable/amd64/index_no_notes.html has become and i look forward to see it shrink further :) 17:40:15 Faux: libmysqlclient15-dev is gone for good some time ago, but without leaving trace in the changelogs.... 17:40:44 that page also makes it clear that there are packages with usertagged bugs but no issues recorded. cant the script add those issues automatically? 17:41:31 h01ger: there is a different version noted 17:41:41 https://reproducible.debian.net/rb-pkg/unstable/amd64/ricochet.html looks like a typo 17:42:08 that's why it appears in the "no notes" page for unstable 17:42:23 ah 17:42:37 (though i ment more in general..) 17:42:40 h01ger: some bugs have no related issues (also for good reasons, e.g. some special case only for that single package) 17:42:49 but do have a bug files 17:42:58 *some* 17:43:03 not issues 17:43:05 I'm going to flip index_no_notes to showing the ones with failing tests, and any existing "uninvestigated" packages are in a ftbfs_uninvestigated_bloody_horrifying category at some point. 17:43:06 just notes 17:43:35 (I'm on holiday next week so I don't know how far I'll get.) 17:43:38 Faux: the typo is in the bug too #787675 17:43:40 if there is a bug filed, a note (without issue) can be added to a package automatically 17:43:44 we just lack the automatism 17:43:45 s/ Faux / deki/ ↑ 17:44:06 h01ger: clean-notes pick up usertagged bugs and attach them in the notes, i run it every other day, more or less 17:44:16 we are really in sync, what case you talking about? 17:44:22 mapreri: oh 17:44:40 scikit-learn# cpqarrayd#n and libpam-sshauth# 17:44:51 oh 17:45:03 now i got it 17:46:02 mapreri: can the script do that? 17:46:15 yeha 17:46:19 how so? 17:46:31 one it's too young, filed yesterday, yet to pick up 17:46:53 ah 17:47:14 any other business? or are we done? 17:47:21 h01ger: -e missing-usertagged, iirc. used to be alway run at the early versions of that script, but i turned it off since it takes > 30 seconds and it's annoying to run 17:47:25 try --help 17:47:34 * h01ger nods, will do, thanks 17:47:45 I keep meaning to work out why it's > 30s. >.< 17:47:51 :) 17:47:54 Even b.d.n can render the list faster than that! 17:47:58 EVEN B.D.N 17:48:06 b.d.n ? 17:48:07 By about a second. 17:48:08 bugs. 17:48:13 Oh, it's .org. 17:48:18 I dislike this notation anyway. 17:48:27 #info next meeting, july 21st, 17 UTC 17:48:39 #info in #debian-reproducible 17:49:01 * h01ger thanks everybody for attending and/or reading this and wishes a splendid day! 17:49:08 o/ 17:49:21 Faux: it's querying a remote db (=5 secs) + double looping on the results => something O(n^2) or something like that (iirc, it has been a while since the last time i looked at it). it used to be even worse... 17:49:29 o/ :D 17:49:45 [05:48:47 PM] I dislike this notation anyway. ← which one? 17:50:00 wtf.qa.d.n 17:50:43 * mapreri is confused 17:50:46 #endmeeting? 17:50:49 #endmeeting