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