15:29 <cpaelzer_> #startmeeting Weekly Main Inclusion Requests status 15:29 <meetingology> Meeting started at 15:29:41 UTC. The chair is cpaelzer_. Information about MeetBot at https://wiki.ubuntu.com/meetingology 15:29 <meetingology> Available commands: action, commands, idea, info, link, nick 15:30 <cpaelzer_> doko: jamespage: ddstreet: didrocks: sarnold: Ping for MIR Meeting 15:30 <doko> o/ 15:31 <cpaelzer_> hi doko 15:31 <cpaelzer_> getting started ... slowly ... so everyone can show up (re-ping jamespage: ddstreet: didrocks: sarnold:) 15:31 <cpaelzer_> #topic Review of previous action items 15:32 <jamespage> o/ 15:32 <cpaelzer_> actions we had were "just" some reviews we have assigned 15:32 <cpaelzer_> I've seen the on of ddstreet completed 15:32 <cpaelzer_> I also did mine (plus one that I found in my inbox the other day) 15:32 <cpaelzer_> doko: I think https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137 still waits for you right ? 15:32 <ubottu> Launchpad bug 1895137 in rpi-eeprom (Ubuntu) "[MIR] rpi-eeprom; raspberrypi-userland" [Undecided,In progress] 15:33 <doko> ahh, yes. still need to do ... 15:33 <cpaelzer_> ok, so we had this for being a reminder 15:33 <cpaelzer_> and then I remember https://bugs.launchpad.net/ubuntu/+source/abseil/+bug/1912307 which didrocks has done 15:33 <ubottu> Launchpad bug 1912307 in abseil (Ubuntu) "[MIR] abseil" [Undecided,Incomplete] 15:33 <cpaelzer_> that was all that we had 15:33 <cpaelzer_> going on with this weeks influx of cases .... 15:33 <didrocks> hey 15:33 <cpaelzer_> #topic current component mismatches 15:33 <cpaelzer_> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 15:34 <cpaelzer_> only known cases and known false-positives there - or does anyone disagree? 15:34 <sarnold> good morning 15:34 <cpaelzer_> hi didrocks and sarnold and jamespage 15:34 <didrocks> indeed 15:34 <jamespage> hi cpaelzer_ 15:35 <cpaelzer_> ok - as usual the more busy list is 15:35 <cpaelzer_> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 15:35 <sarnold> seems like known cases 15:36 <cpaelzer_> didrocks: this one isn't "new" but I'm unsure what the next step on https://bugs.launchpad.net/ubuntu/+source/tiff/+bug/1908502 really is 15:36 <ubottu> Launchpad bug 1908502 in tiff (Ubuntu Hirsute) "[MIR] libdeflate" [Undecided,Triaged] 15:36 <cpaelzer_> as the bug stands it is waiting for something from seb128 - is that true or would we want to put this onto our queue? 15:36 <cpaelzer_> maybe you want to check with him and update the bug so we can properly assign it next week 15:36 <doko> jamespage: re-promote libfcgi? 15:37 <jamespage> again? 15:37 <cpaelzer_> as-is it is a bit in a nimbus of being neither accepted nor rejected nor being worked on 15:37 <sarnold> two ini parsing packages at once, the 90s are alive in linux :) 15:37 <cpaelzer_> why was fcgi lost https://bugs.launchpad.net/ubuntu/+source/libfcgi/+bug/1017978 ? 15:37 <ubottu> Launchpad bug 1017978 in libfcgi (Ubuntu) "[MIR] libfcgi, ceph (radosgw)" [Medium,Fix released] 15:37 <didrocks> cpaelzer_: hum, unsure, I will check 15:37 <jamespage> looking 15:37 <seb128> cpaelzer_, libdeflate is ready as far as I'm concerned 15:38 <seb128> cpaelzer_, if it's waiting on me please give details so I can get it unblocked 15:38 <jamespage> well it was promoted to support part of ceph, but then they decided that libfcgi was all a bag of brokeness and running a data plan via apache was just a bad idea 15:38 <doko> it gained a dependency on libfcgi0ldbl 15:38 <cpaelzer_> didrocks: would you then give libdeflate a review please - you can best short-cut with seb128 and others in case there are questions 15:38 <didrocks> I know Olivier was supposed to deal with it, unsure what happened, probably waiting on seb128 doing the tiff part, I’ll check with him 15:38 <jamespage> so it got dropped in preference to something much better 15:38 <seb128> didrocks, there is no tiff part, see my comment 15:38 <didrocks> will do 15:38 <seb128> I just kept that bit open for the #by-team-excuses report 15:38 <seb128> otherwise the tag was not being picked 15:39 <seb128> didrocks, I took over from Olivier because he's overworked with other things 15:39 <seb128> anyway what's the normal process to hand it to you guys? 15:39 <seb128> I unassigned myself and change the status to New 15:39 <seb128> but seems that was still confusing? 15:39 <seb128> changed* 15:39 <didrocks> seb128: ah, I was reading the report and your comment, wasn’t clear from here, I think we can removed the tiff part? 15:40 <didrocks> libdeflate wasn’t confused, the tiff part was as Triaged 15:40 <seb128> if you do that the reference would drop https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages 15:40 <seb128> on the tiff section 15:41 <didrocks> hum, it’s kind of anoying we have to keep opened against the wrong component, but ack, we are all on the same page 15:41 <didrocks> I’ll handle the lib* part 15:41 <seb128> but yeah, it's bit suboptimal 15:41 <seb128> thanks 15:41 <cpaelzer_> jamespage: doko: back to fcgi 15:41 <cpaelzer_> in the past it was in main for ceph, but it isn't anymore 15:41 <ddstreet> sorry i'm late o/ 15:41 <cpaelzer_> what now pulls it in seems to be "libopenjpip-server" 15:41 <cpaelzer_> hi ddstreet 15:42 <cpaelzer_> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hirsute/all+extra 15:42 <cpaelzer_> libfcgi0ldbl | libfcgi | libopenjpip-server | Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> | 26076 | 95 15:42 <cpaelzer_> and that is pulled from openjpeg2 15:43 <cpaelzer_> which makes this component mismatch on fcgi a Desktop case nowadays 15:43 <cpaelzer_> didrocks: what do you tihnk, subscribe desktop to bring it in or cut the dependency somewhere? 15:44 <didrocks> cpaelzer_: well, I’m rather on seb128's opinion to only subscribe a team once the final ACK is nearly done 15:44 <cpaelzer_> didrocks: the ack is on that package as it was in main 15:44 <seb128> (which is a topic I wanted to discuss again and the reason I'm around) 15:44 <cpaelzer_> didrocks: seb128: ok to discuss in the "other business" section at the end 15:44 <didrocks> seb128: your opinion about libfcgi? 15:45 <cpaelzer_> for this particular case the question is "take it over" or "cut dependencies" 15:45 <seb128> right, I guess it's for us 15:45 <cpaelzer_> as I thinks jamespage saying "decided that libfcgi was all a bag of brokeness" means he does not want to own it 15:45 <cpaelzer_> ok that is enough for fcgi for now 15:46 <cpaelzer_> seb128: didrocks: come back to us with whatever you decide shall be the next step then 15:46 <seb128> k 15:46 <cpaelzer_> next in component mismatches is ... 15:46 <seb128> I'm checking 15:46 <jamespage> I was always rather uncomfortable about its status upstream tbh 15:47 <cpaelzer_> sarnold: about "in" parsing 15:47 <cpaelzer_> https://bugs.launchpad.net/ubuntu/+source/libinih/+bug/1883890 15:47 <ubottu> Launchpad bug 1883890 in libinih (Ubuntu) "[MIR] libinih" [Undecided,New] 15:47 <cpaelzer_> will that be in time for Hirsute? 15:47 <cpaelzer_> As I guess we will want to keep xfsprogs in main :-) 15:48 <sarnold> okay, I've slid it up the trello lane a bit 15:50 <cpaelzer_> ok 15:50 <cpaelzer_> no other items in here 15:50 <cpaelzer_> going on 15:50 <cpaelzer_> #topic New MIRs 15:50 <cpaelzer_> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir 15:50 <cpaelzer_> deflate we just mentioned, I guess didrocks you can assign that to you then? 15:50 <didrocks> yep 15:51 <cpaelzer_> doko: you have opened https://bugs.launchpad.net/ubuntu/+source/rpm/+bug/1913871 15:51 <ubottu> Launchpad bug 1913871 in rpm (Ubuntu) "[MIR] debugedit (binary package built from rpm)" [Undecided,New] 15:51 <cpaelzer_> and you have listed various options how to solve 15:52 <cpaelzer_> is there any preference, or do you want to have a review before deciding? 15:52 <doko> a review first for the first option, not modifying the package 15:52 <cpaelzer_> also have you opened this from the "This will be foundations POV" or did you just stumble over it working on proposed migration in general ? 15:52 <cpaelzer_> ok, thank doko 15:53 <doko> no, I'd like to have non-conflicting dbgsym packages by default 15:53 <cpaelzer_> I'll do a review of it this week 15:53 <cpaelzer_> from there you can decide hwo to proceed 15:53 <cpaelzer_> That leaves https://bugs.launchpad.net/ubuntu/+source/mtd-utils/+bug/1913321 15:53 <ubottu> Launchpad bug 1913321 in iniparser (Ubuntu Hirsute) "[MIR] iniparser (dependency of mtd-utils)" [Undecided,Incomplete] 15:53 <doko> thanks 15:53 <cpaelzer_> which is waiting for a reviewer 15:54 <cpaelzer_> as sarnold said, a second ini parser 15:54 <cpaelzer_> so (very) strictly speaking that would already be a reject - but I'm rather sure APIs won't be compatible :-/ 15:54 <cpaelzer_> well that is an assumption, who is willing to review this? 15:55 <cpaelzer_> didrocks: has one, doko has one (well the old one), and I have one 15:55 <cpaelzer_> that leaves jamespage and ddstreet for https://bugs.launchpad.net/ubuntu/+source/mtd-utils/+bug/1913321 15:55 <ubottu> Launchpad bug 1913321 in iniparser (Ubuntu Hirsute) "[MIR] iniparser (dependency of mtd-utils)" [Undecided,Incomplete] 15:55 <cpaelzer_> one of you up to it ? 15:55 <ddstreet> guess i'll take it then :) 15:55 <cpaelzer_> awesome 15:55 <cpaelzer_> I assigned both bug tasks 15:55 <cpaelzer_> one to me one to you 15:55 <cpaelzer_> done with this meeting segment 15:55 <jamespage> ta 15:56 <jamespage> oh missed 15:56 <cpaelzer_> #topic Incomplete bugs / questions 15:56 <jamespage> nm 15:56 <cpaelzer_> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir 15:56 <seb128> I don't understand the libfcgi situation, openjpeg2 didn't change (out of security patches) since focal how is it creating a component mismatch now? 15:56 <seb128> (unsure if now is an ok time to ask that) 15:56 <cpaelzer_> nothing in here we'd not yet have covered this meeting 15:56 <cpaelzer_> going on 15:56 <cpaelzer_> #topic Any other business? 15:56 <seb128> or now :p 15:56 <cpaelzer_> 1. let us clarify the fcgi situation (later then the package subscription) 15:58 <cpaelzer_> hmm, indeed libopenjpip-server is in universe (as I'd have hoped) 15:58 <cpaelzer_> so that trace was a red herring 15:58 <cpaelzer_> what else is pulling in fcgi then ... 15:59 <seb128> http://launchpadlibrarian.net/520473670/libfcgi-perl_0.79-1build1_0.79+ds-2.diff.gz ? 15:59 <seb128> -Build-Depends: debhelper-compat (= 12), 15:59 <seb128> +Build-Depends: debhelper-compat (= 13), 15:59 <seb128> + libfcgi-dev (>= 2.4.2), 15:59 <seb128> that's owned by server 15:59 <cpaelzer_> but build depends should no more be component mismatches ... 15:59 <seb128> https://launchpadlibrarian.net/520473739/buildlog_ubuntu-hirsute-amd64.libfcgi-perl_0.79+ds-2_BUILDING.txt.gz 15:59 <seb128> libfcgi-perl_0.79+ds-2_amd64.deb 15:59 <seb128> Depends: perl, perlapi-5.32.0, libc6 (>= 2.4), libfcgi0ldbl (>= 2.4.2) 15:59 <seb128> 16:00 <seb128> I guess that's leading to an autogenerated Depends? 16:00 <seb128> I'm not familiar with perl packaging and Depends generation 16:00 <cpaelzer_> seb128: it does lead to a generated dep indeed, but the question then usually becomes "why is the source of this in main" 16:00 <cpaelzer_> which here is libfcgi-perl 16:00 <didrocks> I guess it’s coming from ${perl:Depends}, as you say 16:00 <cpaelzer_> and then the Team owning that is asked 16:01 <seb128> k, so that would be server, not us 16:01 <cpaelzer_> yeah, whyever germinate output is lying to us 16:01 <cpaelzer_> I'll take it with me then 16:01 <seb128> thanks 16:02 <cpaelzer_> ha - well jamespage this is on sevrer Team for the date this was added pre-dates the split of server/openstack 16:02 <cpaelzer_> but no need to stall here, I'll check the details and might drop you and billy a mail about next steps 16:02 <didrocks> jamespage: cpaelzer_: libcgi-fast-perl is depending on libfcgi-perl 16:03 <cpaelzer_> next is seb128 and didrocks question about package subscription 16:03 <didrocks> I guess the track should continue from here :) 16:03 <seb128> we touched in it in one of the previous meeting 16:03 <seb128> to* 16:04 <didrocks> (Task: lamp-server) 16:04 <cpaelzer_> yep 16:04 <cpaelzer_> as I said I'll take it from here 16:04 <cpaelzer_> now about the package subscription 16:05 <seb128> cpaelzer_, my point was that team subscription equal to ownership, which makes things be listed on our reports for things that are still in universe and we didn't start maintaining yet (and sometime get nacked) 16:05 <seb128> e.g https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages recently listed a flatpak issue 16:05 <cpaelzer_> seb128: yeah - that has actually two benefits 16:05 <seb128> but https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1812456 isn't moving 16:05 <ubottu> Launchpad bug 1812456 in flatpak (Ubuntu) "[MIR] libflatpak0" [Medium,New] 16:05 <cpaelzer_> one is that the "to be owning" team will see a sample of the future influx of bugs 16:06 <cpaelzer_> which isn't too bad if that makes them decide to not want to go that way 16:06 <cpaelzer_> the other is that we have had a few cases where the order of "MIR ack, Security Ack, subscribe, AA promotion2 was going wrong 16:06 <cpaelzer_> so things ended up being promoted (as the AAs thought the Acks imply that subscription is complete) 16:06 <cpaelzer_> btu not subscribed 16:06 <cpaelzer_> so no one wtached these things in main 16:07 <seb128> right, that's when the workflow is inconsistency 16:07 <cpaelzer_> due to that the last discussion I remember ended with "better over-, than under-subscribe" 16:07 <seb128> if it was always subscribe & promote we wouldn't have errors 16:07 <didrocks> however, one the second one, if we change the process, I think it’s a matter of ensuring AA are aware (ofc, there will be human errors, as for the MIRs or any other part) 16:07 <cpaelzer_> seb128: the problem is that the AAs can't "subscribe you" 16:07 <cpaelzer_> so that is potentially another delay in an already slow process 16:07 <sarnold> can we amend the AA tooling to add the subscription? 16:08 <cpaelzer_> sarnold: ^^ that sounds reasonable 16:08 <cpaelzer_> or at least check and reject 16:08 <cpaelzer_> as LP won't allow non-team-admins to subscribe a team 16:08 <didrocks> hum, so everytime you -c main|restricted, having a list of teams that should be subscribed and at least one of them should be 16:09 <cpaelzer_> if the AA tooling (or agreed process) would put the "burden of checking the scubription" on them I'm ok if - for the MIR process - all we want is the "intended owner" 16:09 <sarnold> I'm rather of the opinion that being subscribed earlier helps provide visibility on problems on the package and reduces surprises about show-stopper bugs, but automating things away is nice too. 16:09 <cpaelzer_> sarnold: as I said, I like this beenfit as well 16:09 <cpaelzer_> of seeing the influx on this package 16:09 <didrocks> TBH, most of the time, the promotion is done with a restricted set of people already part of aware of MIRs, so the burden isn’t that big 16:10 <didrocks> I guess the point seb128 is making is to make a team accountable of packages that are taking months to get reviewed 16:10 <cpaelzer_> IMHO "accountable" only is true if "in main + subscribed" 16:11 <cpaelzer_> while "universe + subscribed" is the intend to own things 16:11 <cpaelzer_> but that is nowhere written up officially I guess and jsut my gut feeling 16:12 <seb128> also I don't think all reports work like that today 16:13 <cpaelzer_> This seems to be a case for voting, about "shall bug subscription only be mandatory when package promotion happens and thereby the responsibility to check subscription become task of the AAs". (This still wouldn't be immediately effective even if we agree on yes, as the AAs need to agree to it) 16:14 <cpaelzer_> #vote "shall bug subscription only be mandatory when package promotion happens and thereby the responsibility to check subscription become task of the AAs" 16:14 <meetingology> Please vote on: "shall bug subscription only be mandatory when package promotion happens and thereby the responsibility to check subscription become task of the AAs" 16:14 <meetingology> Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') 16:14 <didrocks> +1 16:14 <meetingology> +1 received from didrocks 16:14 <cpaelzer_> I like the current state more, but have no strong objections to the change, therefore 16:14 <cpaelzer_> +0 16:14 <meetingology> +0 received from cpaelzer_ 16:15 <cpaelzer_> ddstreet: jamespage: doko: - your opinion? 16:15 <seb128_> sorry, my internet went down :-/ 16:15 <cpaelzer_> np seb128_, we started voting on the question 16:15 <didrocks> seb128_: we are voting. Nothing else was discussed 16:15 <cpaelzer_> 3 votes missing 16:15 <sarnold> seb128_: https://pastebin.ubuntu.com/p/3Q535MGRyk/ 16:15 <seb128_> sarnold, thanks 16:16 <cpaelzer_> sarnold: vote? 16:17 <sarnold> cpaelzer_: I'm having trouble deciding between -1 and 0 -- I don't have a hugely strong opinion. -.5 would be my preference :) 16:17 <cpaelzer_> hmm, we ran overtime and our remaining voters might be consumed in other meetings 16:17 <cpaelzer_> didrocks: would you mind to put this into a mail together with seb and send it to the MIR-people? 16:17 <didrocks> sure! 16:17 <cpaelzer_> didrocks: that way we can have everones opinion without staring at IRC here 16:17 <didrocks> agreed 16:17 <cpaelzer_> #endvote 16:17 <meetingology> Voting ended on: "shall bug subscription only be mandatory when package promotion happens and thereby the responsibility to check subscription become task of the AAs" 16:18 <meetingology> Votes for: 1, Votes against: 0, Abstentions: 1 16:18 <meetingology> Motion carried 16:18 <sarnold> hehe :) 16:18 <cpaelzer_> no decided lacking qorum, postponed to a mail 16:18 <cpaelzer_> #action didrocks will convert the "when to subscribe" discussion into a mail 16:18 * meetingology didrocks will convert the "when to subscribe" discussion into a mail 16:18 <cpaelzer_> anything else, otherwise we'd be done 16:18 <didrocks> hopefully, this one will be decided before we start the Golang one back :) 16:19 <cpaelzer_> and sarnold, -0.5 is allowed IMHO, but ket us stick to no smaller fractions than .5 please :) 16:19 <sarnold> :) 16:19 <sarnold> rational, anyway? heh 16:19 * didrocks was going to suggest that… :) 16:19 <cpaelzer_> either way it should end up with documenting how we do it and the rational on which it was decided 16:20 <cpaelzer_> ok thank you @everyone 16:20 <cpaelzer_> this was along one, thanks for your time 16:20 <sarnold> thanks cpaelzer_, all :) 16:20 <cpaelzer_> #endmeeting