17:02:01 <h01ger> #startmeeting
17:02:01 <MeetBot> Meeting started Tue Jul 28 17:02:01 2015 UTC.  The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:02:17 <h01ger> #topic please say hi
17:02:27 <mapreri> hi o
17:02:28 <deki> hi
17:02:29 <mapreri> o/
17:02:34 <h01ger> #topic please say hi - agenda is at https://wiki.debian.org/ReproducibleBuilds/Meetings
17:02:38 <h01ger> hi hi
17:02:53 <h01ger> Agenda for the fifth meeting, 2015-07-28 17:00 UTC
17:02:53 <h01ger> discuss todays agenda
17:02:54 <h01ger> go though last meetings summary and look for unactioned action items
17:02:54 <h01ger> package/issue updates + r.a.d.o repo state
17:02:55 <h01ger> can we move old unneeded packages out of the way? (a /old/ directory?)
17:02:55 <h01ger> rp.d.n updates+issues
17:02:56 <Dhole> hi!
17:02:56 <h01ger> GSoC updates
17:02:58 <h01ger> any other business
17:02:59 <h01ger> announce next meeting
17:02:59 <h01ger> is todays agenda
17:04:06 <jumapico> hi
17:04:06 <h01ger> do you have other topics to discuss?
17:07:14 <deki> doesn't look like it
17:07:14 <mapreri> lgtm
17:07:15 <vagrantc> hi
17:07:15 <h01ger> #topic go through last meetings summary and look for unactioned action items
17:07:15 <h01ger> meetbot?
17:07:15 <h01ger> #topic go through last meetings summary and look for unactioned action items
17:07:15 <h01ger> oh well
17:07:16 <jumapico> :]
17:07:16 <h01ger> #action h01ger hasnt doesnt done this, so he will do this soon: AGREED: h01ger will polish https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain and we will review the result in the next meeting (h01ger, 17:14:58)
17:07:17 <h01ger> (darst says that meetbot might react soon again)
17:07:33 <h01ger> ah
17:07:37 <h01ger> #action h01ger hasnt doesnt done this, so he will do this soon: AGREED: h01ger will polish https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain and we will review the result in the next meeting (h01ger, 17:14:58)
17:07:40 <h01ger> #save
17:08:05 <h01ger> seems to work
17:08:39 <h01ger> looks like that those were the ACTION points from
17:08:46 <h01ger> http://meetbot.debian.net/debian-reproducible/2015/debian-reproducible.2015-07-07-17.00.html
17:09:14 <h01ger> #topic package/issue updates + r.a.d.o repo state
17:09:31 <h01ger> we have one sub topic here atm: can we move old unneeded packages out of the way? (a /old/ directory?)
17:09:36 <h01ger> anything else?
17:11:16 <h01ger> we might want to discuss autobuilding (our repo) here+now (for armhf) or later...
17:11:41 <mapreri> h01ger: -eparse of your last sentence
17:12:20 <h01ger> mapreri: atm we do manual source+amd64-binary uploads of our packages to our repo. this is good for amd64 but needs a solution for armhf
17:12:31 <h01ger> but lets start with old packages…
17:12:36 <h01ger> #topic package/issue updates + r.a.d.o repo state - subtopic: moving old packages out of the way
17:12:38 * vagrantc wonders if it's even good for amd64
17:12:54 <mapreri> what i want to do is: detect all packages build with old version of our patched packages; rebuild them; move those old versions of our patched packages out of the way (=NOT deleting them for now, since space is free). comments?
17:13:02 <h01ger> we cannot move old packages away, as long as we still have packages which were build using them
17:13:15 <h01ger> and as we dont have .buildinfo in a db, we cannot easily find out
17:14:05 <deki> we could move away all packages older than $oldest_build?
17:14:06 <h01ger> mapreri: i dont like the "rebuild them" part as it implies you want to schedule them all
17:14:26 <h01ger> mapreri: i'm not happy to interfere that much with build-age-based scheduling
17:14:35 <h01ger> s/happy/too happy/
17:14:58 <h01ger> mapreri: OTOH, if you merely detect that a old package has become unused and then move it away, then i like the plan ;)
17:15:05 <mapreri> that db is 600 MB in the current implementation. it's HUGE. but i think somebody might come up with a better ideas. i think i'll go the ML way for that, though
17:15:22 <h01ger> ouch
17:15:33 <h01ger> (size - ML sounds good)
17:15:46 <h01ger> #info mapreri will discuss implementation of buildinfo.db on the list
17:15:53 <mapreri> h01ger: you can see such db on my home, it's some weeks ago. it takes 8 minutes and more than 2 GB of ram to be created, fwiw
17:16:14 <h01ger> mapreri: if that is done once a day, 8min and 2gb is totally fine
17:16:36 * h01ger is a room with two people arguing loudly :-/
17:16:58 <h01ger> next topic?
17:17:03 <mapreri> about rescheduling packages built with old stuff. i believe there won't be that many
17:17:32 <h01ger> i just dont see the point dealing with scheduling to cleanup faster
17:17:56 <mapreri> the point is exactly cleanup faster :)
17:18:06 <h01ger> which cleanup?
17:18:18 <mapreri> the repo
17:18:53 <h01ger> mapreri: thats exactly the point i dont see
17:19:11 <mapreri> oh, well, i'll just remove already unused packages for now, i got it. guess i'll free something anyway
17:19:18 <deki> any comment on my comment? :)
17:19:33 <mapreri> deki: what does it mean?
17:19:36 <h01ger> deki: seems like a good algo
17:19:39 <h01ger> [19:13] < deki> we could move away all packages older than
17:19:44 <h01ger> $oldest_build?
17:19:48 <deki> mapreri: we don't clean as fast, but we clean eventually
17:19:49 <mapreri> yeah, what does it mean that?
17:19:56 <mapreri> ah
17:20:15 <mapreri> got it. umh... i'd still check whether they are still used in some old build
17:20:20 <deki> an old toolchain package is mvoed to old/ if there is a newer one, and the older one is older than the oldest build (40 days or so?)
17:20:28 <h01ger> deki: yup
17:20:48 <h01ger> (except for the moving to old/ part while they are still used)
17:20:58 <h01ger> if you really want faster repo speed
17:21:04 <h01ger> we should switch to reprepro
17:21:22 <h01ger> with bdrung_work's patch to allow more than one version in the repro in the same suite
17:21:32 <mapreri> which won't be installed on alioth because that's not the purpose of alioth, iirc a past #alioth discussion
17:21:51 <h01ger> i'm quite sure reprepro can be installed in ~ too
17:22:31 <mapreri> maybe yes... but i don't think we need it. we need our patches in the archive, not a more shiny repo
17:22:37 <h01ger> anyway, my point was: i think its better to use better tools, than to limit ourselves
17:22:44 <h01ger> yes, that also
17:23:19 <h01ger> #topic  package/issue updates + r.a.d.o repo state - subtopic: Dhole is looking for good toolchain "targets" to fix - any suggestions?
17:23:28 <h01ger> Dhole: ;-)
17:23:32 <Dhole> :)
17:23:47 <Dhole> I've worked on patching packages to honour SOURCE_DATE_EPOCH
17:23:54 <h01ger> i could merely suggest to go through the issues on https://reproducible.debian.net/index_issues.html from top to bottom..
17:23:55 <Dhole> so anotherone like that would be good
17:24:25 <Dhole> but other toolchain fixes are good too
17:24:48 <h01ger> #info Dhole welcomes suggestions for toolchain packages needing to be fixed (preferedly) using SOURCE_DATE_EPOCH but other suggestions are welcome too
17:25:05 <deki> Dhole: what about this: https://reproducible.debian.net/issues/unstable/timestamps_in_qch_issue.html
17:25:16 <deki> but i'm not sure if someone already worked on it
17:25:34 <bdrung_work> h01ger, that reminds me to refresh my patch set
17:25:41 <h01ger> bdrung_work: :)
17:25:54 <Dhole> deki: thanks for the suggestion, I'll work on that :)
17:26:03 <h01ger> deki: i havent seen anybody...
17:26:17 <deki> Dhole: but please check upstream repo.  i remember someone submitting qt-related patches some time ago
17:26:20 <h01ger> (at least i dont remember ever having heard about qch files :)
17:26:30 <Dhole> deki: will do :)
17:26:38 <h01ger> Dhole: there is some link in the about page on the wiki…
17:26:59 <h01ger> #topic rp.d.n updates+issues
17:27:39 <h01ger> #info /me still needs help debugging https://jenkins.debian.net/job/reproducible_freebsd/15/console "fatal error: 'namespace.h' file not found
17:27:41 <h01ger> "
17:28:10 <h01ger> and then vagrantc has thankfully setup these armhf boxes
17:28:20 <h01ger> (for testing debian)
17:29:08 <h01ger> and we have localhost for testing ssh scheduling for amd64, but i'll also setup 1 or probably rather 2 amd64 VMs so we can do proper remote builds for amd64 too
17:29:21 <h01ger> (and give them more ressoures too)
17:29:41 <h01ger> atm the most pressing problem to discuss is "how to get binary armhf packages for our repo"
17:30:02 <h01ger> i'm tempted to just start with manual built binNMUs
17:30:17 <mapreri> btw, building them with qemu (or in a porterbox for dds) is not that difficult
17:30:19 * h01ger has armhf build hw too
17:30:25 <h01ger> that also
17:30:35 <mapreri> if they are not huge packages, of course, otherwise qemu is a no-op
17:31:07 <h01ger> then it just needs some "research" whether our "repo" on alioth can cope with more archs
17:31:25 <mapreri> imho the most pressing issue is getting the rb code do its work with multi-arch, btw
17:31:45 <h01ger> mapreri: thats not the first step though
17:32:15 <h01ger> vagrantc: could you check whether our repo can deal with armhf packages and build those?
17:32:33 <h01ger> https://reproducible.debian.net/index_repositories.html has a list
17:34:21 <vagrantc> h01ger: i'm not sure what you mean exactly
17:34:38 <h01ger> vagrantc: "can you upload armhf binNMUs to our repo"
17:34:43 <h01ger> s#you#one#
17:34:47 <vagrantc> just manually build those packages?
17:34:52 <h01ger> yes
17:35:07 <h01ger> vagrantc: the question is whether the repo can deal with them
17:35:09 <vagrantc> do they need to be built in a reproducible environment? then we've got a bootstrapping challenge :)
17:35:15 <h01ger> manually building is the easy part
17:35:22 <h01ger> vagrantc: no, just start with dpkg and debhelper
17:35:34 <vagrantc> got it. umm... i can look at your repo, not sure i have permission to do anything to it
17:35:46 <deki> isn't debhelper arch independent?
17:35:51 <mapreri> indeed
17:36:08 <h01ger> right, then only dpkg :)
17:36:28 <h01ger> vagrantc: also whether the instructions on https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Adding_a_package_to_the_APT_archive match / have everything
17:36:45 <vagrantc> i can test that with fresh naive eyes
17:37:31 <h01ger> #info vagrant and h01ger will work on making our repo armhf "aware"
17:37:55 <h01ger> #info then it needs pbuilder setup on the new armhf machines and then it needs code to make j.d.n use it...
17:38:23 <h01ger> i'm not sure there is much more to discuss here about this now (?)
17:38:38 <mapreri> there is not, imo
17:38:44 <h01ger> (there is more to discuss, but just not now :)
17:39:04 <vagrantc> h01ger: i presume i needed to be added to a group on alioth?
17:39:15 <deki> just send a request :)
17:39:21 <h01ger> vagrantc: yes, you need to be part of the reproducible project
17:39:28 <h01ger> #topic GSoC updates
17:39:46 <h01ger> akira: Dhole: the "stage" is yours... ;)
17:40:11 <Dhole> so I've been working on ghostscript lately
17:40:46 <h01ger> how long is GSoC still running?
17:40:53 <Dhole> there was a patch by Peter De Wachter which I adapted to also set TZ=UTC, and now adapted to the new ghostscript version
17:41:00 <Dhole> will open a bug soon
17:41:08 <Dhole> I think it finishes on the 25th of August
17:41:22 <deki> ah, after DC :)
17:41:44 <akira> I have been working on packages tagged with not_using_dh_builddeb
17:41:49 <Dhole> I've also been working on timestamp issues for individual packages
17:42:36 <Dhole> akira: you've sent so many patches in the last two weeks! :D
17:42:37 <mapreri> vagrantc: here you are, welcome :)
17:42:52 <Dhole> akira: nice work :)
17:42:57 <akira> I realized that it is a bit complicated to figure out which bug belongs to which issue (for packages that have more than one issue)
17:43:01 <akira> Dhole: thanks =)
17:43:34 <h01ger> indeed, /me applauds akira once more! :)
17:43:35 <deki> akira: what do you mean with "which bug belongs to which issue"?
17:44:18 <akira> well these package usually have two issues and there was already a bug oppened for one of them but you cannot see for which bug is that issue oppened
17:44:23 <akira> like not easilly
17:44:34 <akira> if you read the patch then you see what it fixes
17:44:45 <deki> ah ok, i understand
17:45:04 <deki> so submitters should write more clear descriptions in the submitted bug?
17:45:15 <mapreri> akira: so, you'd like to see which usertag a bug has in the rb pages or something like that?
17:45:52 <akira> I would like if the bugs were tagged with the issues =)
17:46:05 <h01ger> heh
17:46:20 <deki> mapreri: no, some bugs have unclear descriptions, like "please make reproducible, see attached patch", with not many details.
17:46:29 <h01ger> akira: to phrase that differently: would you also like if the bugs were noted in the notes?
17:46:46 <mapreri> h01ger: they already are?
17:46:49 <deki> h01ger: bugs are noted in the notes?
17:46:54 <h01ger> hehe
17:46:57 <h01ger> touchee
17:47:09 <h01ger> doesnt work:
17:47:20 <h01ger> a package can have more then one bug and more then one note…
17:47:40 <deki> hm, afaik a package can have only one note. but multiple bugs on tht note
17:47:48 <h01ger> #info akira wonders whether its sensible to have usertags for each issue
17:47:55 <h01ger> deki: and multiple issue on a package
17:48:00 <josch> what is the problem with using the bts instead of packages.yml?
17:48:01 <deki> yes, right
17:48:17 <h01ger> josch: we havent invented all these usertags in the bts yet
17:48:26 <josch> h01ger: but you can make up any usertag you want
17:48:27 <h01ger> tracking in the bts is a bit harder
17:48:30 <josch> why?
17:48:40 <josch> you can just query it using the soap interface
17:48:41 <h01ger> because you cannot grep in issues.yaml then
17:48:45 <h01ger> which takes ages
17:48:49 <josch> then cache it
17:48:56 <h01ger> still
17:49:01 <mapreri> is way harder. in packages.yml there are a lot of information that are not available in the bts
17:49:02 <josch> but right now issues.yml duplicates things
17:49:08 <josch> like what?
17:49:15 <deki> also packages.yml contains some manual notes/comments without issues
17:49:24 <mapreri> a lot of packages without bugs. comments about sources
17:49:24 <josch> which should be in the bug
17:49:30 <josch> those should have bugs
17:49:37 <mapreri> not al
17:49:38 <mapreri> all
17:49:39 <h01ger> josch: i suggest you write a coherent proposal to the list. this topic is too big to cover it here in 5min and the changes would be too severe too
17:49:43 <josch> by keeping it in the yml file you make it more exclusive to the r-b team
17:49:49 <josch> just file a bug if there is a problem
17:49:57 <josch> h01ger: okay
17:50:01 <h01ger> it would be a fundamental change in workflows
17:50:11 <mapreri> some are there only to collect packages, to know how many and which are affected by given toolchain trouble. which can be accomplished by the bts, but is also harder
17:50:13 <deki> mapreri: that reminds me of something. a page would be nice that lists packages with notes that have comments.  because there are often useful information to fix packages in it.
17:50:14 <h01ger> also the yml is displayed to the world via r.d.n
17:50:24 <josch> so could the bts status...
17:50:40 <h01ger> deki: can you please add this to TODO? (that request)
17:50:45 <deki> ok
17:50:51 <h01ger> #topic any other business
17:51:35 * mapreri got dinner hour. now that i'm back to my relatives home i have dinner at insane hours, sorry :\
17:51:44 <h01ger> mapreri: enjoy!
17:52:01 <deki> have fun :)
17:52:04 <h01ger> if there's no other business, we can immediatly go to discuss the next meeting
17:52:11 <mapreri> i prefer having dinner when i like it with different people, tbh...
17:52:24 <h01ger> which should be in two weeks, but i fear i might be moving from debcamp to cccamp then..
17:52:47 <mapreri> we can still have it
17:52:58 <h01ger> sure!
17:53:14 <h01ger> i might also make it but i wont commit to it
17:53:21 <mapreri> no worries :)
17:53:26 <h01ger> #topic next meeting
17:53:44 <h01ger> so, august, the 11th, 17 UTC / 19 UTC then?!?
17:53:53 <mapreri> sounds good
17:54:08 <deki> ok
17:54:11 <Dhole> okay
17:54:48 <h01ger> #agreed next meeting, august, the 11th, 17 UTC / 19 UTC here
17:55:12 * h01ger thanks everybody for a joyful + constructive meeting
17:55:28 <h01ger> (not like the background noise i had here IRL...)
17:56:01 <deki> h01ger: 7b062c1
17:56:13 <mapreri> h01ger: while i'm having dinner (+sleeping, since i won't be able to do anything after) could you look at the 'remote' branch and maybe deploy it if you like, so i can start fiddling with it tomorrow?
17:56:24 <mapreri> see you tomorrow o/
17:56:30 <deki> \o
17:56:36 <h01ger> deki: thanks!
17:56:43 <h01ger> #endmeeting