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