17:57:53 #startmeeting 17:57:53 Meeting started Mon Jul 28 17:57:53 2014 UTC. The chair is gregoa. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:57:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:01 #chair Dom ntyni 17:58:01 Current chairs: Dom gregoa ntyni 17:58:04 #meetingtopic Perl 5.20 transition 17:58:08 #meetingname perl-5.20-transition 17:58:08 The meeting name has been set to 'perl-5.20-transition' 17:58:12 #topic useful links 17:58:18 #link https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.20-transition;users=debian-perl@lists.debian.org bugs tagged perl-5.20.transition 17:58:23 #link https://release.debian.org/transitions/html/perl5.20.html transition page 17:58:26 #link https://lists.debian.org/debian-perl/2014/07/msg00046.html proposed agenda 17:58:29 #save 17:58:48 #link http://meetbot.debian.net/debian-perl/2014/ meetings logs 17:58:52 #topic Intro and welcome 17:59:02 ok, that was the copy&paste part :) 17:59:24 good, I guess we can start? 17:59:26 so, who is paying attention? 17:59:33 * daxim 17:59:36 * hlieberman 17:59:37 * ntyni 17:59:39 * dam 17:59:43 * ansgar just arrived by chance. 17:59:44 and/or interested in helping :) 18:00:00 pochu wrote he would be late or read the logs 18:00:03 Yup. 18:00:42 Thanks for taking the time to come along - this was partly a result of ntyni and I not being around lots so wanting to be organised about planning 18:00:43 Dom: you proposed an agenda in https://lists.debian.org/debian-perl/2014/07/msg00046.html ; what would you like to start with? 18:01:21 okay, so that's a reasonable agenda I think. 18:01:28 agreed 18:01:40 * gregoa agrees 18:02:05 In terms of FTBFS packages, I undersatnd ntyni test-rebuilt the packages which will need binNMUs a couple of months ago and filed a big round of bugreports 18:02:12 #topic review FTBFS and other mass-testing bugs 18:02:53 so, the current status is that uploading 5.20 to sid would introduce 45 new RC bugs 18:02:59 I also started rebuilding on i386 this weekend, although a screwup on my part means that hasn't got as far as it should have done 18:03:32 the release team obviously wants less but I'm not sure if there's a threshold other than zero 18:03:33 #info uploading 5.20 to sid would introduce 45 new RC bugs 18:03:34 ntyni: of those, do you have a number for how many are 'trivially' fixable? (eg the usr/lib/perl5 thing) 18:03:51 Per the link earlier, it appears that a patch is available for most of them. 18:03:53 (btw; my rebuild has not found anything notable/new) 18:03:57 Dom: 37 have patches, 2 are pending 18:04:10 good point! 18:04:18 (I think 2 more are trivial, BICBW) 18:04:31 #info Of the 45 RC critical bugs, 37 have patches, and 2 are pending 18:04:34 I'm slightly uneasy about the three SWIG related ones 18:04:53 Only 8 RC bugs w/o patch sounds fairly good :) 18:04:59 also I haven't checked how many affect testing 18:05:03 Hmm, silence on the maintainer front there 18:05:35 ntyni: what makes you uneasy about the SWIG bugs? 18:05:38 re SWIG stuff, plan B could be to NMU with patched generated files 18:06:02 leaving plan A to the maintainers :) 18:06:12 dam: I think that's plan A :) (if I understand the patches correctly) 18:06:38 dam: right, it's just that patching generated files is wrong :) 18:07:13 but regenerating is obviously far more intrusive and I'd certainly like to leave that to the actual maintainers 18:07:21 agreed, but uninstallable packages is worse 18:07:33 I *think* it's tolerable for an NMU 18:07:40 Dom: so do I 18:07:49 ok, so we NMU with the patched generated files if there is no maintainer reaction soon? 18:07:50 so forget about my uneasiness 18:08:07 gregoa: +1 to that 18:08:08 Who wants to do the NMU? 18:08:10 gregoa: s/soon//; the bugs were filed long ago 18:08:22 shall we come back to NMUs later 18:08:30 #agreed swig bugs: we NMU with the patched generated files if there is no maintainer reaction 18:08:43 Iiih, patching gnerated files. Just let them be RC buggy until there is a proper fix? 18:08:43 Dom: ack, I'd also do the "who does what when" later 18:09:06 I'm not sure if we need to prioritize the remaining bugs or if we're confident "someone" will fix them in time 18:09:22 ansgar: that's probably for the maintainer to decide, I'd tend towards downgrade to important. But not important. 18:09:36 in terms of other FTBFS bugs which we may not have caught yet: 18:09:53 ntyni: I take it you didn't rebuild arch:all lib*-perl yet? 18:10:08 Dom: I actually did 18:10:22 ah, okay. 18:10:26 Dom: I mean not uploading a NMU changing the generated files, but just let them FTBFS/rc-buggy until there is a proper fix. 18:10:26 at least all that didn't need an uninstallable build dependency, of course 18:10:55 ansgar: ah, I see. 18:11:45 fwiw, the three swig-related packages are amanda, libprelude, and libpreludedb 18:11:55 amanda is already orphaned. 18:11:59 I haven't checked about their reverse dependencies 18:12:00 I would guess the RT would prefer that the packages build even if they are a bit messy. 18:12:24 libprelude sounds like there won't be many rdeps. 18:12:48 Hmm, actually there are quite a few :/ 18:13:41 Good reminder that amanda is orphaned. I guess it is still widely enough used that a hack to get it building is better than it being removed 18:13:53 * gregoa agrees 18:14:01 * dam us a (stable) amanda user 18:14:50 okay, so still broad agreement about the NMUing then I think 18:15:09 two other bugs that stand out are the "alternative dependencies" ones 18:15:22 For what it's worth, libprelude now has an updated upstream, so there may be fixes in there for the FTBFS. 18:15:54 Does running swig during the build not work? 18:15:56 #info two unfixed bugs are "Perl 5.20: alternative dependencies" 18:16:13 ntyni: right, and IIRC they are both from jo0nas, so either he or someone else can just fix them 18:16:14 ansgar: I don't think anyone has tried that yet 18:16:32 Dom: the alt-deps' log reminds me of a bike-shedding, so not really a great technical problem 18:17:01 ah, still the swig issue :) I guess either someones tries to look at regenerating during build or we stick with the NMU plans. - any takers? 18:17:09 dam: well said :) 18:17:53 * Dom reads the alt-dep bugs fully 18:18:51 okay, it's a variant of what we've seen lots before. 18:18:58 I'm quite impressed if there are only two of them! 18:19:07 I think in fact we have, besides what we've mentioned so far, 4 bugs without a solution so far, the "Forwarded bugs -- Important bugs (4 bugs)" section 18:19:22 Dom: the rest is already fixed without discussions :) 18:20:03 and for those four, we either need to ping upstream or find a fix ourselves or live with the fallout 18:20:24 I could try to look at running swig during package build. But not sure when :) 18:20:40 not sure how popular embperl is nowadays, the others look like low popularity leaf packages (but I didn't actually check) 18:20:54 okay, so let's look at the fallout 18:20:57 #action ansgar to look into the swig bugs (trying to regenerate stuff during build) 18:21:03 embperl has had a difficult couple of years 18:21:31 too bad fsfs is not here, I think he looked after embperl in the last years 18:21:37 it is finally back in testing, it would be a shame to lose it again especially for fsfs 18:22:16 gregoa: has he been active recently? Can we ask him if he can look at that bug? 18:22:27 embperl could be just something trivial like a new warning in the test logs 18:22:38 I think I can take a look at that 18:22:42 # info libclone-fast-perl: no rdeps; libencode-arabic-perl]: 1 rdep (libelixirfm-perl); libje-perl: no rdeps 18:23:04 #action ntyni looks at embperl 18:23:17 #action fsfs hopefully feels pinged as well for embperl :) 18:23:33 Dom: IIRC he was not very active in the last months but still around 18:23:41 gregoa: I can relate to taht... 18:23:47 :) 18:23:58 ok, anything else for the bug topic or shall we move on? 18:24:05 debhelper 18:24:14 ah, right 18:24:16 namely #750021 18:24:36 #info one of the debhelper patches is applied in git, not the other 18:24:43 IIRC something minor breaks if that isn't fixed 18:25:06 ok, who pings the bugs/joeyh? 18:25:32 the other one should be wishlist 18:26:06 iow it's not a blocker 18:26:16 #info #751684 in debhelper should probably be wishlist, and only has a minor effect if unfixed 18:26:40 #info #751684 18:26:40 2014-04-11 11:50 Joey Hess o Minor typos. Closes: #74│+ 18:26:50 #info ... is the one fixed in git 18:26:57 bother, I got it the wrong way round. 18:27:03 *cough* 18:27:40 no, looks right? 18:27:49 ntyni: could you confirm the impact of both bugs? 18:28:21 Dom: I think #750021 is dh_fixperms breaking for files in $Config{vendorarch} 18:28:48 Dom: and #751684 should be wishlist as we have another implementation in place for the affected packages 18:29:21 What is the other implementation? 18:29:32 Dom: setting perlapi-* manually via d/rules 18:29:53 thanks 18:30:19 so i suppose neither of those are blockers but it would be nice to have #750021 fixed before the transition 18:30:45 dh_fixperms breaking> sounds serious? 18:31:03 #info it would be nice to have #750021 fixed before the transition 18:31:04 Dom: I think it only breaks for files currently in /usr/lib/perl5 18:31:42 Dom: and I expect those are mostly correct anyway (but I could be wrong) 18:31:57 s/those/their permissions/ 18:32:03 gregoa: I'll ping #750021 18:32:18 * gregoa doesn't remember any seeing any permission problems in his rebuilds, but I haven't paid close attention to all lintian messages 18:32:24 Dom: thanks 18:32:34 #action Dom to ping #750021 18:32:47 ok, next topic? 18:33:15 #topic review bugs/work needed on perl package 18:33:31 okay, so this probably covers the debian-policy bugs I was just looking at too 18:33:54 Dom: would be nice but techically they are no blockers 18:34:14 #info bug pinging covers the debian-policy bugs as well 18:34:15 ntyni: do you have an todo if things needed on the perl package for 5.20? 18:34:16 the policy bugs are fixed in git, I think that should be enough 18:34:29 Dom: not really, there's #747628 but I'm just checking for others 18:34:34 ah, good point 18:35:07 I saw quite a log of commits for 5.18 recently. I assume we at least need to merge in 18:35:46 so IIRC the question was Depends/Recommeds for the deprecated modules, and using NEWS.Debian or not, right? 18:35:51 Dom: that's mainly the s390x hell 18:36:15 gregoa: from what I remember, that's an accurate summary 18:36:18 ntyni: which was binary incompatibility related, so not an issue for 5.20? 18:36:25 ntyni: The libc joys? 18:36:26 #info check if something from 5.18 needs to be merged into 5.20 18:36:29 since we're bumping the abi anyway? 18:36:34 Dom, ansgar: right 18:37:06 except that s390x upstream is now reverting the libc abi change so if the timing is bad enough we may have to redo the dance with 5.20 18:37:15 \o/ 18:37:27 pong 18:37:37 * XTaran is now here, too. 18:37:52 gregoa: there is, if only for git history 18:37:59 ntyni: in #747628 you wrote "I still think that once the build failures are fixed, Recommends: should be strong enough." is this still the current state, and: any other opinions? 18:38:03 i'd actually prefer to handle the reversion with 5.18 but we'll see how it goes 18:38:04 * gregoa welcomes XTaran 18:38:35 Dom: ack 18:39:22 gregoa: I think so but I'm sort of hazy on the details now 18:40:13 still on the s390 issue 18:40:41 ntyni: and 5.18 used Recommends, right? (libarchive-extract-perl, libmodule-pluggable-perl, libpod-latex-perl, libterm-ui-perl, libtext-soundex-perl) 18:40:58 ntyni: it does sounds like it would be smoother that way, but do we have any idea what the likely schedule is? 18:41:37 gregoa: yes, we've successfully used Recommends in the past 18:41:54 ntyni: cool, thanks 18:42:02 * gregoa waits for Dom and s390x now :) 18:42:20 Dom: the s390x upstream revert decision was just a few days ago and I have no idea how soon it will trickle to Debian 18:43:01 * ntyni is looking for a link 18:43:01 if it happens when we've already uploaded 5.20 to unstable, what effect will that have? Just making the transition status a bit more tricky and having to untangle extra rebuilds needed? 18:43:54 Dom: I really hope it doesn't happen at the same time as the 5.20 rebuilds; afterwards it's going to need similar source uploads as I've done with 5.18 lately 18:44:14 Dom: to bump s390x to perlapi-5.20.0d with the reverted abi or whatever 18:44:16 my IRC logs also just say that aurel32 announced the decision on -release without anys schedule yet 18:45:14 I suppose there's nothing we can do right now re s390x? 18:45:15 okay, I guess we should alert the RT to the fact 18:45:22 to make sure we don't get them entangled 18:46:05 Dom: I expect they'll notice it themselves but it doesn't hurt 18:46:09 #info s390x libc reversion and perl 5.20 transition should not be entangled 18:46:18 pochu said he will read the logs of this meeting 18:46:39 Okay, I think we're done on that, shall we carry on with Recommends/Depends? 18:46:48 * gregoa nods 18:47:21 ntyni notes in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747628 18:47:27 "I still think that once the build failures are fixed, Recommends: 18:47:28 should be strong enough." 18:47:34 Dom: I suppose I need to think the Recommends/Depends thing through properly once more but I'd appreciate a second set of eyeballs 18:47:47 (ie the ones in various Architecture: all packages) 18:47:55 recommends seems like a reasonable balance to me 18:48:06 after all, the removals are for a reason 18:48:20 so moving them to recommends now, then maybe suggests as of 5.22, and then removing as of 5.24 18:48:25 (and treating other removals similarly) 18:48:45 mst: previously we've dropped references entirely after one release cycle 18:48:51 seems like a nice balance between debian-level backcompat guarantees and "letting deprecated modules gradually fade away" 18:48:52 (Debian release cycle that is) 18:49:05 since you are not promised anything smooth by jumping releases 18:49:10 I'd be totally fine with that as well 18:49:13 (suggests or dropping is not much difference) 18:49:13 yo 18:49:21 sorry folks 18:49:26 I just don't want them to stay in 'recommends' that long 18:49:26 * gregoa welcomes pochu 18:49:26 ntyni: okay, so let's both review in our time 18:49:31 because it isn't really a recommendation, as such 18:49:40 it's a "you quite possibly need this, but we no longer recommend it" 18:49:55 the other point about #747628 is things being deprecated in 5.20. 18:50:12 #action ntyni and Dom to review Depends/Recommends one last time with all their eyes 18:50:13 sorry, that's not what I mean 18:50:38 what I mean is that we should review the build logs again. 18:50:54 ah 18:51:09 #action Dom to review the build logs again 18:51:11 fwiw I suppose this isn't really a blocker for the transition as we can meddle with them afterwards too 18:51:56 this deprecation thing is more difficult for me to grok than it should be even though we've done it before. Melding the perl and debian release cycles turns out to need some thinking 18:52:06 ntyni: good point 18:52:14 let's move on then. 18:52:14 #info can also be improved after transition in case it becomes necessary 18:52:38 ok, do we need to discuss NEWS.Debian? 18:53:00 briefly? 18:53:40 what's the argument for not doing so, other than we haven't before? 18:53:50 not sure if Russ proposed NEWS.Debian as a general practice for removed packages or just the future CGI.pm removal 18:53:51 ok; my preference is against using NEWS.Debian as it's shown to too many users who don't care; but I can live with it as well 18:54:02 s/removed packages/removed modules/ 18:54:20 gregoa: +1 to that 18:54:22 hmm, I suppose there is a bit of a user/developer difference we can't quite cope with there 18:54:24 .oO(release notes) 18:54:40 dam: yes, I think we've used release notes for this before 18:54:55 shouldn't hurt to do it again 18:55:02 #link https://lists.debian.org/debian-perl/2014/05/msg00137.html ← rra and NEWS.Debian and CGI.pm 18:55:03 volunteers to draft a release notes update for changes to perl for jessie? 18:55:25 I mean, it is way less intrusive that README.Debian and people we care about read them 18:56:29 this one is not a blocker for the transition either; are we short on time? 18:56:56 yep. 18:57:19 #agreed someone drafts a release notes update for changes to perl for jessie 18:57:40 good. next topic from the agenda: 18:57:42 so I think we can move onto actions/next steps? 18:57:46 one thing that's not on the agenda is Perl 5.20.1 timing and it's effect on us 18:57:53 if it has an effect,that is 18:57:55 (and AOB) 18:58:03 gregoa: blocker thing probably doesn't need its own item 18:58:06 Dom: shall we skip "topic identify blockers we need help with"? 18:58:14 snap 18:58:14 ah, right :) 18:58:21 ok, then schedule/actions: 18:58:32 #topic actions/next steps 18:58:52 ntyni mentioned 5.20.1 timing 18:59:02 is that scheduled yet? 18:59:08 ack - now or afterwards? 18:59:29 okay, later 18:59:44 ok. so, 5.20 and the schedule 18:59:58 next steps: I will complete the rebuild of arch:any packages and send a report to debian-perl 18:59:58 there was a draft about the upload date, right? 19:00:06 also of arch:all 19:00:14 Hoping to not find any surprises... 19:00:18 #action Dom will complete the rebuild of arch:any packages and send a report to debian-perl 19:00:40 gregoa: if it is to happen before DebConf, it's August 12th or thereabouts 19:00:44 gregoa: we thought before Debconf would be good so we can have some hack time working on resolving issues. 19:00:57 makes sense 19:01:14 #info current proposed date for upload to sid: August 12th or thereabouts 19:01:29 so that's in ~2 weeks 19:01:30 I think really just that week? 19:01:56 exact timing depends on ntyni and my availability. 19:02:04 but yes. I'm nitpicking. 19:02:24 right. (and maybe on s390x libc :/) 19:02:26 Dom: yeah, that week or so I guess 19:02:58 I saw in the backlog someone saying perl and libc shouldn't be entangled. any reason not to? 19:02:59 pochu: is the week of August 12th still ok for the release team? and are there any news re s390x libc abi reversion? 19:03:04 So, the other main thing we have to do is a lot of NMUs or otherwise prodding people. 19:03:15 (people = maintainers, to apply patches) 19:03:30 gregoa: that should still be fine, and no news on the reversion, other than the plan is to revert it 19:03:42 pochu: ok, thanks 19:03:55 I think entangling perl and libc would be good, as libc is pretty simple 19:04:08 and then we avoid doing another transition in the future 19:04:22 pochu: right, if it's coordinated I think it's fine 19:04:28 * Dom defers to RT on this one :) 19:04:36 pochu: I was worried about the abi changing in the midst of the 5.20 rebuilds 19:04:36 yes. I'll talk to Aurelien 19:04:49 ntyni: oh, yeah, that'd be bad :) 19:04:51 pochu: thanks. 19:04:59 #action pochu to check with aurel32 about s390x libc 19:05:14 also, have you talked about bringing the list of bugs down before the transition starts? 19:05:20 #info entangling perl and libc would be good 19:05:26 pochu: we're covering that now, basically 19:05:37 pochu: that's the question Dom has just asked :) 19:05:42 Next step is probably to upgrade all the blockers 19:05:50 which will be a prod for maintainers 19:06:00 heh, right. sorry 19:06:03 :) 19:06:18 * pochu was thinking about s390x and didn't see that :) 19:06:20 which will hopefully prod maintainers into action 19:06:21 yes, making them explicitly RC a bit before the transition is what we've done in the past 19:06:36 ah, me has forgotten about this details 19:06:37 pochu: is that OK with the release team? 19:07:19 yes. I'm fine with either bumping to serious (saying this will FTBFS in 2 weeks or whatever) or with keeping it as important but doing uploads to DELAYED/5 or so 19:07:41 bugs have been opened for a while now, no need to ping again if you can NMU really 19:07:50 I'd favour the former, it matches what we've done before 19:08:00 * dam too 19:08:03 just upload to DELAYED and say the maintainers are welcome to fix it sooner :) 19:08:12 #info RT fine with either bumping to serious in advance or keeping at important and NMUing to DELAYED/5 19:08:26 pochu: but getting maintainers to do some work before we have to is also good 19:08:34 :) 19:08:34 indeed 19:08:36 given the numbers 19:08:37 Dom: ack 19:08:50 ok, so let's bump them. when and who? 19:08:57 ok so bump it, and then NMU at will to DELAYED/5 19:08:59 not sure if there are active RC bug hunters other than gregoa, but if there are, we could get them to help too 19:09:09 gregoa: when: ASAP 19:09:33 * dam could bump 19:09:38 Dom: ok. sounds ok since we are at t minus 2 weeks 19:09:46 dam: thanks 19:10:00 #action dam to bump blocking bugs to serious asap 19:10:22 and I guess then, in a few days, we can start to NMU 19:10:40 e.g. over the coming weekend 19:10:43 *nod* 19:11:15 #agreed start NMUing remaining bugs in a couple of days 19:11:35 I'm happy to join the NMU party, since I've already some patches on my disk :) 19:11:45 anyone else? dam? 19:11:59 gregoa: yes, sure. count me in 19:12:03 \o/ 19:12:21 #action dam and gregoa NMU blocking packagaes, others welcome to join 19:12:32 gregoa, dam: awesome 19:12:51 good. anything else re schedule/actions before we go to 5.20.1 and AOB? 19:12:52 I'll try to help where I can 19:12:59 ntyni: thanks! 19:13:11 thanks indeed gregoa and dam 19:13:41 #topic 5.20.1 timing 19:13:51 do we know something about 5.20.1? 19:13:52 ntyni: you mentioned 5.20.1. Have you seen any talk about a date for that? 19:13:55 mst: ^^^ 19:14:24 I've not seen anything formal about planning for it 19:14:29 all I know is upstream is busily cherry-picking patches for 5.20.1 19:14:32 unless there's something on perl5-porters I've missed 19:14:37 well, yes, but we do that as we go 19:14:42 because that's the intelligent thing to do 19:14:47 mst: anything informal we should know? 19:14:51 sure, it just picked up speed recently 19:14:57 RC1 2nd/3rd August 19:15:06 * Dom digs out link 19:15:49 http://www.nntp.perl.org/group/perl.perl5.porters/2014/07/msg217597.html 19:16:01 this doesn't necessarily affect this transition 19:16:03 I'm not too fussed about that 19:16:25 final might hit us about the same time as we upload to sid, but anything super-urgent can be included, and anything else can wait until the dust settles 19:16:34 ntyni: agreed 19:16:52 #info anything super-urgent can be included from 5.20.1, and anything else can wait until the dust settles 19:16:57 but if we have to postpone things until September, I guess 5.20.1 is ready then 19:17:14 that's looking less and less probable though 19:17:15 5.20.1 should, in theory, be a relatively trivial update from 5.20.0 though 19:17:26 (the postponing part, that is) 19:17:30 in that we're a -lot- more conservative about what goes into a .z release these days 19:18:06 right, and for wheezy we ended up with 5.14.2 + most of the patches in 5.14.3 19:18:20 good. so plan A: 5.20.0 in august, just in case of delays 5.20.1 if it's there 19:18:22 in the worst case we can do that for jessie too 19:18:42 gregoa: agreed 19:18:47 I'd wondered why it had a huge number of locally applied patches 19:19:00 #agreed plan A: 5.20.0 in august, just in case of delays 5.20.1 if it's there 19:19:21 ha, this sounds like a good point for "AOB" :) 19:19:27 #topic AOB? 19:19:56 ntyni: it'd be nice if you somehow noted the fixes that were backports-from-maint, btw 19:20:12 btw Aurelien confirms the plan is to revert the abi break on s390x, patches are being reviewed upstream and it should be fine to do the revert right before the perl transition 19:20:41 I don't think I have any AOB 19:20:45 #info it should be fine to do the revert [s390x libc] right before the perl transition 19:20:55 I'm done too 19:20:57 lots more catching up to during Debconf as I've been so out of the loop for a few months 19:21:14 that's all from me as well 19:21:26 cool 19:21:47 thanks everybody! I guess we can finish the meetbot logged part now 19:21:53 Thanks gregoa for chairing! 19:22:05 yes, thank you very much! 19:22:13 :) 19:22:14 #endmeeting