17:01:24 #startmeeting 17:01:24 Meeting started Tue Jun 16 17:01:24 2015 UTC. The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:01:31 deki: that ML is full of automated emails, ~450 emails in just 2 weeks, i guess another dozen won't hurt too much? 17:01:57 #topic discuss todays agenda / everybody please say hi 17:02:03 perhaps. i just don't want to get them annoyed 17:02:06 hi 17:02:20 mapreri: deki: let's discuss this under "rp.d.n updates+issues", please?! 17:02:39 fine 17:02:39 the agenda for today is: 17:02:41 hi! 17:02:45 discuss todays agenda 17:02:46 go though last meetings summary and look for unactioned action items 17:02:46 package/issue updates + r.a.d.o repo state 17:02:46 discuss ftbfs_on_testing_due_to_unmigrated_dependencies issue discuss ftbfs usertag how to deal with cases like #786694 17:02:48 rp.d.n updates+issues 17:02:49 GSoC updates 17:02:50 any other business 17:02:51 announce next meeting 17:02:56 * h01ger also says hi + gets something to drink 17:03:21 +please speak up if things are missing in the agenda 17:03:33 maybe people ought a pingall just 30 secs before the meeting? 17:03:40 or just before #startmeeting 17:04:15 hi! 17:04:44 MeetBot: pingall: meeeeeting :) 17:04:44 h01ger: Error: "pingall:" is not a valid command. 17:04:49 MeetBot: pingall meeeeeting :) 17:04:49 meeeeeting :) 17:04:49 aef AGWA ajames akira bafs bochecha czchen deki Dhole dkg DrWhax Faux fchmmr ggherdov__ GhostInTheShell GoGi h01ger Haaninjo helmut HW42 infinity0 j_f-f jamessan jelmer josch KGB-0 KGB-1 KGB-2 KillYourTV lamby legind_ linuxmaniac lucas Lunar^ lynxis mapreri 17:04:49 MeetBot MoC Muz nicoo nthykier ntyni pabs paulproteus perryl rfreeman-w Sagi sgnb skitt_ ssam2 terceiro themill tom3468 tvincent urzo weasel za3k zarvox zwiebelbot 17:04:49 meeeeeting :) 17:05:42 omeone should file a bug against gtk-doc so our patch doesnt get lost. http://anonscm.debian.org/cgit/reproducible/gtk-doc.git/commit/?h=pu/reproducible_builds&id=aa2faf7883b528a63e5be88f6043b32c88fbc503 17:05:47 has that been done? 17:05:52 Well someone kick this spam bot? 17:05:58 MeetBot, that is 17:05:58 fchmmr: Error: "that" is not a valid command. 17:06:11 h01ger: i don't think it has been done 17:06:12 fchmmr: this is our meeting bot 17:06:15 Ok 17:06:20 h01ger: well, that link is 404, though 17:06:23 Meeting of what, for what purpose? 17:06:40 fchmmr: https://wiki.debian.org/ReproducibleBuilds/Meetings 17:06:49 ok 17:06:54 fchmmr: meeting of the reproducible builds team given that this is the reproducible builds team irc channel, maybe? 17:06:55 so it's not spam 17:06:56 :) 17:07:05 I'm new here, so I didn't know what the bot was for. 17:07:06 #info someone still needs to file a bug against gtk-doc so that our patch doesnt get lost 17:07:30 #link this one https://anonscm.debian.org/cgit/reproducible/gtk-doc.git/commit/?h=merged/reproducible_builds&id=fe1c60f53d04d2da3496acb5410c97d574f5c894 17:07:38 status of #785742 ? (our position about timestamps) 17:07:40 #save 17:08:25 AGWA: is that bug clear now for you? 17:08:26 I think the position should be to replace any timestamp > the debian/changelog date with the debian/changelog date 17:08:45 "clamp" it, in other words 17:08:54 * h01ger agrees and i think everybody does 17:09:00 my position now: timestamps are not evil if they are meaningful: build time is not meaningful but "last change" (changelog?) time it is. 17:09:05 so, clamp is good 17:09:12 * deki nods 17:09:22 and anybody can speak up in #785742 17:09:29 excellent :-) 17:09:42 #agreed [19:08] < AGWA> I think the position should be to replace any timestamp > the debian/changelog date with the debian/changelog date 17:09:44 h01ger: that is closed, i think there are better place to write that now 17:09:59 #agreed [19:08] < mapreri> my position now: timestamps are not evil if they are meaningful: build time is not meaningful but "last change" (changelog?) time it is. so, clamp is good 17:10:23 what else is left from last meeting? 17:10:56 nothing. all action items done. excellent! 17:11:06 #topic package/issue updates + r.a.d.o repo state 17:11:14 we have three sub topics here: 17:11:17 discuss ftbfs_on_testing_due_to_unmigrated_dependencies issue 17:11:18 discuss ftbfs usertag 17:11:20 how to deal with cases like 786694 17:11:23 h01ger: #subtopic exists too 17:11:24 anything else? 17:11:28 oh, shiny 17:11:39 #subtopic any other subtopics? 17:11:46 #save 17:12:17 meh, where are you... 17:12:18 #help 17:12:35 #topic package/issue updates + r.a.d.o repo state / discuss ftbfs_on_testing_due_to_unmigrated_dependencies issue 17:13:00 i'm sure there is somewhere, i use it on freenode on ubuntu channels... 17:13:10 i've come to think we should remove this issue again, as it distracts and is just busy work to keep it up2date 17:13:37 mapreri: feel free to start a testmeeting after this to debug this, but please leave it ignore it now 17:13:48 must be their patched version, so... meh. sure, will check another time 17:13:49 i agree... it takes time noting this issues, and again time to remove the notes. and those are only some temporary issues 17:14:16 yep and one day britney will prevent such packages from entering testing anyway 17:14:47 i agree too. just for the "temporary" bit, they are not too relevant. 17:15:21 it would also need more code (on jenkins.d.n.git) to make this tag meanigfully visible (and less distracting) and i think there are more interesting+useful tasks. and as it is, it is distracting 17:16:17 h01ger: do you mean adding it to the filter we already have or what? 17:16:36 that would only make sense for specific suites 17:16:51 i've looked at the code and decided its not worth it 17:17:04 also: we want to look at sid, not at testing 17:17:10 nod 17:17:22 let's drop that issue, so? 17:17:31 and this is/would mean busy-work to get a better view on testing = not what we want 17:17:37 #agreed ftbfs_on_testing_due_to_unmigrated_dependencies should be removed again, it's not helping and causing busy-work 17:18:27 #info as always if you disagree with an irc meeting agreement, bring it up on the mailing list. good arguments are convincing, nothing is set in stone just because it was decided at an irc meeting. 17:18:46 #topic package/issue updates + r.a.d.o repo state / discuss ftbfs usertag 17:18:52 oh 17:18:59 #topic package/issue updates + r.a.d.o repo state / discuss ftbfs_on_testing_due_to_unmigrated_dependencies issue 17:19:06 we should clarify who does that 17:19:37 i could+would but i would appreciate if someone else did, cause busybusy... :/ 17:19:37 i'll do that 17:19:42 thanks, deki 17:19:55 #action deki will remove the ftbfs_on_testing_due_to_unmigrated_dependencies issue 17:20:00 #topic package/issue updates + r.a.d.o repo state / discuss ftbfs usertag 17:21:14 i've come to agree with Lunar^ that this usertag is not useful / relevant for us. it's a good issue for notes.git but out of scope, so i think it makes sense to not introduce this usertag 17:21:33 before everything: currently it has a nice side effect: add the +/# signs after the package names in rb.d.o. I agree, that's bad. I still want to change that to look up every single bug in the notes and ignore everything else. 17:21:34 that said, maybe a catchall usertag "other" would be userful. 17:22:01 also i think "ftbfs" are a issue for us, as in "we can't test reproducibly" 17:22:19 e.g. imho ftbfs things *are* relevant to us 17:22:20 oh, and if we'd decide to keep the ftbfs usertag we should support it on rb.d.n 17:22:23 for* 17:22:44 i don't have an opinion here. i don't mind keeping or removing it 17:23:35 also usertags are quite nasty to use. I have yet to find a way to hide archived/closed bugs in the web view, so i don't think it clutters/dirts something 17:23:40 i'm not sure whether "ftbfs" is the right name 17:23:49 e.g. => what's the point of removing? 17:23:56 h01ger: proposal? 17:24:04 to only have sensible ones would be the point 17:24:11 (if we deem it not to be sensible) 17:24:14 i'm not too tied with names 17:24:33 as it is, this tag is just for ftbfs 17:24:46 maybe we need other too? 17:25:07 what do you mean with "other" here? 17:25:10 or maybe Lunar^ should speak up again why/if he still thinks that tag should go 17:25:15 other what? tags or packages? 17:25:23 can't we have "other" issues just not usertagged? 17:25:24 other issues which deserve a bug and should be usertagged for tracking purpose 17:25:34 deki: then we cannot track them 17:25:41 mapreri: other issues 17:25:46 oh ok 17:26:13 h01ger: currently i see the ftbfs usertag as in "we can't auto-test it on jenkins", e.g. i'd also attach it to the report of this morning/yesterday 17:26:19 and looking at https://reproducible.debian.net/stats_bugs.png i want too be careful not to have to many 17:26:22 (maybe yesterday, time is confusing) 17:26:36 mapreri: so maybe "untestable" instead of "ftbfs"? 17:27:08 h01ger: you don't track ftbfs bugs there, so they don't appear there. Also there are quite some usertagged bugs right now, so you'd see them in the graph quite clearly 17:27:40 mapreri: my point was: that png is confusing with 13 usertags already. 14 wont matter. but i try to avoid reaching 20 or 30 17:28:28 h01ger: i don't think such kind of bugs ought to be graphed, e.g. they are not important for a "random visitor" 17:29:05 mapreri: hm, but you want them to be in the gui with +/# signs 17:29:33 yes, that way if a person is looking for a patch to write can skip those entries 17:30:19 https://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-builds@lists.alioth.debian.org shows all no matter which tag, so maybe we should agree to omit some tags from rb.d.n indeed 17:30:27 I find the +/# signs very useful 17:30:42 but that bit can also (and probably will) be changed to look up "all bugs in the notes" instead of "all usertagged bugs". or maybe both, dunno. yet i think that if a bug # is in the notes, then it *is* relevant to us and ought to be usertagged 17:31:06 h01ger: they are separated by tags... 17:31:08 mapreri: i agree 17:31:29 actually categories, but in this case one category = one tag (/o\ names) 17:31:32 but then i also think all tags should be displayed on https://reproducible.debian.net/reproducible.html 17:32:15 umh 17:32:42 hmmmmmm. i'm not sure how to conclude this point besides deferring it, til it comes up again, or someone with a stronger opinion makes a more actionable proposal 17:33:35 #info maybe rename "ftbfs" usertag to "untestable"? (as this is what we care about) 17:34:15 #info please do speak up about ↑ 17:34:23 #save 17:34:34 Definitely seems sensible on the PTS stuff. 17:34:35 it ignores my #save, meh 17:34:42 #chair mapreri 17:34:42 Current chairs: h01ger mapreri 17:34:45 Faux: what? 17:34:46 not anymore :) 17:34:47 #save 17:34:54 h01ger: ;) 17:35:01 Faux: -v please 17:35:20 I dislike the way the developer info on the PTS shows untestable things as ftbfs. 17:35:32 But not a big issue. :) 17:35:35 Faux: packages.qa or tracker or both? 17:36:09 I think I was thinking of tracker. 17:36:13 just tracker i guess? (as i'm not aware of packages.qa.d.o showing r-b info) 17:36:18 Faux: some issues cause ftbfs packages not to be included in the .json, as not to display those issues in the PTS 17:36:25 Faux: are there some issues missing? 17:36:40 41 (0.2%) packages which failed to build from source in unstable/amd64 due to our changes in the toolchain or due to our setup. This list includes packages tagged ftbfs_werror_equals or bad_handling_of_extra_warnings or ftbfs_pbuilder_malformed_dsc or ftbfs_in_jenkins_setup or ftbfs_build_depends_not_available_on_amd64 or ftbfs_due_to_obsolete_dependencies or ftbfs_due_to_virtual_dependencies. 17:36:41 17:36:46 ^^ these are ignored 17:37:05 Faux: but consider that quite a lot of ftbfs are (were) not included in the the json => don't shows up in the tracker/ddpo/udd 17:37:06 Maybe I'm behind on what is actually happening, and I'm definitly behind on what's being discussed (transport was late, pah!); let me catch up on some scrollback. Continue without me. 17:37:29 Faux: np, just have this in mind, have a look later and if you find more issues need to be ignored, tell mapreri or me :) 17:37:37 next topic? 17:37:47 Faux: we discussed the ftbfs usertaggad i suddenly started using to usertag ftbfs bug that affects us as well 17:38:24 #info integrate 'ftbfs' usertagged bugs in rb.d.n has been added to its TODO 17:38:41 #topic package/issue updates + r.a.d.o repo state / how to deal with cases like #786694 17:38:44 I raised a whole bunch of FTBFS bugs this week, but I wasn't tagging or ccing them because they're real bugs that happen outside of jenkins / custom packages. 17:39:14 Faux: i think its still sensible to usertag+issue them... 17:39:25 #786694 is a similar one 17:40:11 /o\ timezones. 17:40:11 deki's reply to that bug is quite insightful 17:40:21 though it lacks an idea what to do 17:40:22 ;) 17:40:23 Faux: i got reached by some due to being in the multimedia team ;) 17:40:31 i think it's good to report such special cases, when we see them 17:40:49 h01ger: paultag would reply with "dak rm" :D 17:41:11 h01ger: in this case the right thing to do is add "makeinfo" (or the package where it's contained) to build dependencies. 17:41:22 Yeah. I definitely think "ftbfs in UTC-12" is a valid bug. Maybe we can get the qa people to do the next archive rebuild in NZ? ;) 17:41:31 deki: can you add this to the bug please 17:41:40 ok, after the meeting :) 17:41:40 i agree too 17:41:49 Faux: we are the qa people ;) 17:41:54 some of the 17:42:03 deki: also clone that and reassign to the two packages, please 17:42:06 Heh heh heh. 17:42:16 mapreri: ok, i'll try :) 17:42:33 and i also think "ftbfs in GMT-12" is a RC bug and i doubt nthykier disagrees 17:42:50 I have been raising them as important, not serious. 17:42:55 But I have no idea what I'm doing. 17:43:01 (at least now/at this stage of the release. in the freeze things might be evaluated differently) 17:43:06 #action deki to clone+reassign+comment+usertag on #786694 17:43:19 Faux: thats definitly nicer if you're not sure. 17:44:10 Faux: if you fail to build them in your own setup on your own laptop and you're quite sure your setup is fine, serious is fine too, then maintainers can either downgrade them or fix them. imho. 17:44:37 anyway, if you usertag the bugs i think we are going to review them some day or another (likely, once they are less and nearer to the release 17:45:03 deki: is adding "makeinfo" to the depends a proper solution for these cases "always"? 17:45:06 A number of these problems will go away when we go source-only uploads. (insert more laughing sounds) 17:45:44 we should also hurry up a bit, only 15min left and 4 topics.. 17:45:51 h01ger: they are building info pages, but have no makeinfo available. so imho yes, correcting build dependencies is the right solution 17:45:52 Faux: then enter the buildd team :P (as in, it's only a wanna-build problem now afaik :P) 17:46:14 h01ger: let's go on, this is done 17:46:52 #info for cases like #786694 which are building info pages, but have no makeinfo available, fixing the build-deps is the way to go. but should probably be filed as RC (pending RC team confirmation would be nice), but definitly important. and usertagged "ftbfs" too 17:47:01 #topic rp.d.n updates+issues 17:47:17 do we have more subtopics besides "mail notification issues"? 17:47:54 discussing openwrt+coreboot(+fedora+free/netbsd) we could maybe do after the meeting... 17:47:55 are there other issues since the recent changes? 17:48:12 i'm still convinced that since today we are really varying the locale :) 17:48:15 * h01ger aint aware of any but... :) 17:48:19 deki: only a huge backlog 17:48:22 ^^ 17:48:25 mapreri: not before?? 17:48:30 we've seen variations 17:48:32 anyhow 17:48:41 #topic rp.d.n updates+issues / mail notification issues 17:48:53 so the problem is backscatter spam? 17:49:20 the problem is that the haskell team subscribed to status changes (over 1000 packages iirc). and we currently have a lot of ftbfs 17:49:23 i don't recall any variation, and https://reproducible.debian.net/rb-pkg/testing/amd64/fannj.html makes me think that 17:49:30 deki: and that causes what? 17:49:38 deki: only 21 packages of that team FTBFS this morning 17:49:51 h01ger: that causes a lot of mails for those teams, even if it's not their fault 17:50:00 deki: mails to them? 17:50:03 why would we care? ;) 17:50:21 that means a total of 42 unwanted emails, in a ML that received ~450 email in only 2 weeks... (yeah, they're crazy :D) 17:50:33 did they complain? 17:50:36 nope 17:50:39 because people might get less interested in receiving such notifications, when they feel they can't do anything 17:50:46 (not explicitly, at least) 17:50:57 deki: i believe the haskell team is used to a lot of mails 17:51:21 and we do rebuild the whole archive once a month 17:51:26 twice, for both suites 17:51:27 h01ger: ok. i just assumed that some people wouldn't like that 17:51:35 so they will get lots of mails, over a year 17:51:56 maybe we should explain that on https://reproducible.debian.net/index_notify.html 17:52:19 another problem: the java team does not receive emails from us maybe because they are filtered and rejected/discarded by their ML configuration... what should we do? fix somehow our email setup or ask them to loose their sieve? 17:52:34 tell ebourg 17:52:40 dont bother. 17:52:43 can't they whitelist us? 17:53:00 h01ger: they don't get emails for every build, only for status change. hopefully not too often. 17:53:05 or maybe ask DSA (debian-admin) for advise / help 17:53:14 (e.g. i don't think another warning is needed) 17:53:28 deki: dunno, never tried looking at the mailman admin panel 17:53:29 mapreri: not also for every ftbfs or every unreproducible one? 17:53:40 then i think we are fine 17:53:41 h01ger: only status change 17:53:49 next topic then? 17:54:24 yes 17:54:35 #info mail notifications are only send for status changes - so unless we break stuff (like tonight, were 1000 packages wrongly became unreproducible) our frequent rebuilds cause no notifications 17:54:44 #topic GSoC updates 17:55:00 akira: Dhole: anything new / exciting / worth sharing? 17:55:27 http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150608/001910.html 17:55:28 http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150615/001922.html 17:55:36 I worked on __DATE__ and __TIME__ C macro issues last week 17:55:42 #info are the latest reports, more are linked at https://wiki.debian.org/ReproducibleBuilds/About#Publicity 17:55:58 I think I'll add some info in the wiki regarding this kind of issue 17:56:05 cool! 17:56:42 also, last meeting I commented on not being able to replicate the "umask issues" on my machine using pbuilder (with rebuild.sh) 17:56:58 I didn't manage to solve it, so I moved on with other issues 17:57:24 and that would be all 17:57:29 I am working on more doxygen affected packages, and fixing the issue of some packages in packages.yml 17:57:40 Dhole: maybe mapreri's recent refactoring can give another clue? 17:58:01 (and besides that, moving on when one is stuck, is quite clever :) 17:58:28 h01ger: he means with the prerebuild script, on his laptop. i actually have no clue, considering every single bit he tried to do... 17:58:33 hi akira, cool! 17:58:48 if you have nothing to add, lets move on? 17:59:17 yup 17:59:20 yup 17:59:23 #topic any other business 17:59:47 Dhole: if you want i can hand you to try the reproducible_build.sh script we use on jenkins, but it might be quite annoying to setup on one own laptopn (also messes up with the sudo configuration and you have to set up 3 different chroots just to build a package, meh... 18:00:01 * h01ger wondered whether it would be sensible to move the next meeting by a week (later) or if introducing irregularities already is a bad move ;) 18:00:18 akira: i like your email template for doxygen, actually, i want you to know that :) 18:00:25 h01ger: why? 18:00:30 but tuesday in two weeks i will be very tired... 18:01:02 i don't mind moving it 18:01:11 mapreri: thanks! :) 18:01:16 so instead of june 30th, we would have it on july 7th 18:01:57 mapreri: looking at that script would be useful. I may look into this issue again after the 22nd of June, I'll ask for it then :) 18:02:02 does anybody think moving is really bad and we shouldnt? 18:02:14 Dhole: ok! 18:02:16 Nope. 18:02:23 I'm fine with moving 18:02:38 is not really bad, let's move if you want to 18:02:39 Dhole: akira: are these meeting helping you and would you prefer to have it in two weeks? 18:04:03 I find them useful to share our advances, and also to get an overall idea of what other members of this project are working on, what kind of issues are there, etc. 18:04:34 I don't mind if the next meeting is moved a week forward 18:04:34 we could also have one next week and then in two again. i dont mind either way. 18:04:47 deki (or Faux ?): FYI i think i found two relevant mailman option to whitelist us. i'll ask ebourg to check. 18:04:59 nice 18:05:22 h01ger: i think in 3 weeks is fine 18:05:23 so next meeting on june 23rd or july 7th? 18:05:35 * h01ger would like to avoid yet another dudle 18:05:44 also in that period i'll be exactly in the middle of exams, so less troubles for me :) 18:06:07 2015-07-07 is good for me 18:06:25 * h01ger is still waiting for feedback from akira 18:06:36 #save 18:06:43 I agree with Dhole 18:07:41 so lets have one in 7 days and then the next on july 7th, and mapreri might probably miss the next one. or we stick with in 14 days. i'm sorry to cause trouble here 18:07:44 oh, it would have been on 30th. that day i'll be offline for sure (exams that day and the next) 18:08:09 we'll see, not sure about 23rd... 18:08:28 heh. so june 23rd and july 7th it is. meetings are voluntarily anyway :) 18:08:53 it's only 6 o'clock... 18:09:00 lol 18:09:15 #info next meeting moved one week earlier, to tuesday, june 23rd at 1700 UTC. next meeting after that will be july 7th, 1700 UTC 18:09:19 changing TZ in the middle of the day gives you a lot more of time to do stuff 18:09:25 i should do that more often 18:09:33 #topic announce next meeting 18:09:54 tuesday, june, 23rd, 1700 UTC, here 18:09:55 :) 18:09:58 done. 18:10:02 :) 18:10:05 :) 18:10:12 thanks everyone for attending and reading logs later! :-) 18:10:21 o/ 18:10:27 thanks for moderating! :) 18:10:38 :) 18:10:54 #endmeeting