=== not_phunyguy is now known as phunyguy [14:29] #startmeeting Weekly Main Inclusion Requests status [14:29] Meeting started at 14:29:46 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:29] Available commands: action, commands, idea, info, link, nick [14:29] good morning [14:29] o/ [14:30] slyon: joalif: sarnold: jamespage: didrocks: ping for MIR meeting [14:30] hey [14:30] o/ [14:30] no past action items to review [14:30] (slyon the MR would be other business I think) [14:30] yes [14:30] #topic current component mismatches [14:30] Mission: Identify required actions and spread the load among the teams [14:30] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:30] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:31] llvm-toolchain-13 vs z3 should be resolved by: https://bugs.launchpad.net/ubuntu/+source/z3/+bug/1971128 (but I suppose it needs to pass proposed-migration first) [14:31] Launchpad bug 1971128 in rustc (Ubuntu Jammy) "z3 is incorrectly marked as a MIR candidate" [Medium, Confirmed] [14:31] z3 is taken care in https://bugs.launchpad.net/ubuntu/+source/z3/+bug/1971128 btw [14:31] hehe - same info :-) [14:31] :) [14:32] the 5 perl bugs are in https://bugs.launchpad.net/ubuntu/+source/libobject-pad-perl/+bug/1972853 [14:32] Launchpad bug 1972853 in libxs-parse-sublike-perl (Ubuntu) "[MIR] lib*-perl" [Undecided, Incomplete] [14:32] two approved - others challenged [14:32] nothing to act on for us right now [14:32] webrick was new last week which lucas brought up in https://bugs.launchpad.net/ubuntu/+source/ruby-webrick/+bug/1975523 [14:32] Launchpad bug 1975523 in ruby-webrick (Ubuntu Kinetic) "[MIR] Promote to main in Jammy and Kinetic" [Undecided, New] [14:32] and joalif already reviewed that one [14:33] python-charset-normalizer is being worked on as well (no bug) [14:33] tiff -> lerc is new to me [14:33] jamespage: you wanted to look after jaraco IIRC - any news ? [14:34] didrocks: tiff -> lerc sounds desktoppy, do you know what this is about? [14:34] no, but I can have a look at it [14:34] https://launchpad.net/ubuntu/+source/tiff/4.4.0-2 [14:34] sounds intentional [14:35] and yes tiff is desktop [14:35] thanks didrocks for having a look [14:35] (I think people should realize that I’m doing very little pure distro work nowdays and thus, I can’t follow GNOME/desktop changes) [14:35] that is fine, but you still know the people best [14:35] yep :) will track it [14:35] it is similar for me and server packaging TBH [14:35] I see nothing else worth to discuss in mismatches [14:36] at lesat nothing we need to act on [14:36] hmmm, in the debian bug, "The problem is that LERC does not supports BE upstream." [14:36] going on unless someone objects [14:36] #topic New MIRs [14:36] Mission: ensure to assign all incoming reviews for fast processing [14:36] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir [14:36] none [14:36] \o/ [14:37] we have had enough last week that I'm not complaining [14:37] after last week spam, that helps :) [14:37] btw great job by all of you for doing so many reviews quick [14:37] #topic Incomplete bugs / questions [14:37] Mission: Identify required actions and spread the load among the teams [14:37] #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 [14:38] most recent updates are tags but nothing important [14:38] one is different IMHO [14:38] https://bugs.launchpad.net/ubuntu/+source/libldac/+bug/1973784 [14:38] Launchpad bug 1973784 in libldac (Ubuntu) "[MIR] libldac" [Undecided, Incomplete] [14:39] this might lead to the next topic and your MR - slyon do you think this needs an PR to change the wording? [14:39] yes, there was some discussion wrt out "seeded-in-ubuntu" (and some question about superficial testing) [14:39] I think I have answered them, the open question is - do we want to update the wording in the template? [14:39] I'm still not yet super clear about the seeded-in-ubuntu case, as what has been described in cpaelzer's comment matches the "check-mir" test IMO [14:40] seeded-in-ubuntu seems to be more about a change of component (universe->main) during freeze, as that would require a re-spin of installation images? [14:40] (at least that is according to its manpage) [14:41] slyon: it is just one more check that would flag things that are in main [14:41] you could iterate over dependencies of a new MIR pkg and see if they are all seeded [14:41] some people (not me) preferred that way [14:42] which is how the statement got in [14:42] aha! now I get it [14:42] yes we should improve the wording [14:42] this list is "use either of these or any else if you like" [14:42] how about going to the next section then, while we talk about wording [14:42] yes [14:43] first security [14:43] #topic MIR related Security Review Queue [14:43] Mission: Check on progress, do deadlines seem doable? [14:43] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir [14:43] sarnold: how does the cycle look, we are starting to pile up a queue again [14:43] sarnold: is this time progress expected sooner than FeatureFreeze :-) [14:44] I didn't make progress last week, I was on cve triage; and yesterday was a national holiday :) -- so no real 'local' progress to report [14:44] cpaelzer: very much so :) [14:44] anyone but you on those reviews ? [14:44] amurray did one last week, but I don't think there's currently anyone else working a mir [14:44] we've got a team meeting today, I'll fish around for more volunteers :) [14:45] instead of exploding late, could you ask for anyone else to assist you in this phase of the cycle please? [14:45] yup [14:45] thanks [14:45] WFM [14:45] #topic Any other business? [14:45] we have 1.5 topics here [14:45] first the discussion from above [14:46] which we haven't a PR yet, slyon do you want to prep a PR matching your newfound understanding until next week? [14:46] Now that I got it, I can prepare a proposal to change the wording on this one [14:46] or should we try to come up with wording right here right now? [14:46] ok, we are not in a hurry - looking forward to that PR then [14:46] I'll do it for next meeting [14:46] but for today we have [14:46] https://github.com/cpaelzer/ubuntu-mir/pull/10/files [14:46] Pull 10 in cpaelzer/ubuntu-mir "mention update of d/control when a Ubuntu delta was introduced" [Open] [14:46] This is (I guess) inspired by a forgotten update-maintainer [14:47] This one ^ came up in a discussion with seb this morning. I think it makes sense to have it as a MIR check, too. It is already enforced (in most cases) by dpkg [14:47] unsure if this will really help in practice TBH, but could still be added [14:47] To me I think this is a fine change, it should almost never be a real problem. But it would be a potential legal issue if it is forgotten [14:47] There are a lot of examples of sync, then adding a change, then sync, and so on [14:47] and people who don’t use their @ubuntu.com or @canonical.com won’t have the warning when building the source package [14:47] buildpkg already warns people [14:48] but I think it does not consume any more time (we look at d/control anyway) [14:48] and therefore should be fine to add [14:48] yeah, I just wanted to state that I’m unsure how effective this will be in practice, but I have nothing against it [14:48] didrocks: yes, this was the case for seb, too. Therefore, we thought it would make sense to add it to the MIR template [14:48] I agree to didrocks that I'm unsure if it would help [14:48] I think people should use their @ubuntu/canonical when preparing a package for ubuntu [14:48] it doesn't need to be a blocking change for MIR. but we try to keep packages in main in good shape [14:48] do we have any tooling to enforce / notice when version numbers don't clearly indicate a delta from debian? [14:49] I'm tempted to suggest "only add the reporter rule, but not the MIR review statement" [14:49] WFM [14:49] there (at the reporter) is where this could have a benefit by re-assuring the awareness for this [14:49] wfm as well [14:49] the recent 'maysync' discussion makes me wonder how often, if ever, someone accidentally uploads a package with a delta that isn't visible by version string alone [14:50] on the review stage it won't help much - as didrocks said there are sync/upload/sync/upload casess and mcuh more where the one time of the review won't help much [14:50] (I'm mentioning it here mainly because 'discovering if there is a delta' to me means going to the patches.ubuntu.com website..) [14:50] sarnold: it's less about the version string, than about the "Maintainer" field in d/control. [14:50] TL;DR: about what update-maintainers does [14:51] sarnold: IIRC, the "no warning" for non ubuntu emails was for 2 cases: per package upload rights in the archive and native from upstream [14:51] It seems we have no strong objections, but also not much trust in the benefit. Can we vote on my suggestion of only adding the reporter section of the PR please ? [14:51] +1 (obviously) [14:51] +1 [14:51] +1 [14:52] is that the first hunk or second hunk? :) [14:52] first [14:52] first [14:52] +1 :) thanks [14:52] we already have reached qorum but joalif? [14:53] and jamespage [14:53] giving you 30 more sec to object :-) [14:53] sorry I'm at other mtg at same time [14:53] is anybody still signed-in to wiki.ubuntu.com and could update that hunk? Otherwise I guess we're blocked on IS to fix the wiki [14:53] * didrocks tries [14:53] +1 [14:53] I can slyon [14:54] not signed in, keep your token close to you cpaelzer :) [14:54] lol [14:54] I was going through that pain two weeks ago [14:54] that is how I have a fresh and shiny token [14:54] cpaelzer: do you want me to update the MR or will you just copy paste the first hunk only? [14:54] haha [14:55] I have merged the MR (the git isn#t totally in sync anyway) [14:55] and updated the wiki [14:55] thanks [14:55] I'll update git now after the meeting [14:55] for you to rebase next weeks change [14:55] k [14:55] and that seems to wrap up today meeting [14:55] I have a topic to bring [14:55] sorry if you wanted to leave early :p [14:55] any last thing we forgot [14:55] ah [14:55] about libsoup3 [14:55] no didrocks, please go [14:55] https://bugs.launchpad.net/ubuntu/+source/libsoup3/+bug/1972153/comments/5 [14:55] Launchpad bug 1972153 in libsoup3 (Ubuntu) "[MIR] libsoup3" [Undecided, Confirmed] [14:55] so, it’s a soname bump [14:56] but a security sensitive lib, obviously [14:56] I don’t think we should plan on GNOME updating all dependencies in one release [14:56] and head for the worst scenario [14:56] (one or two releases with both v2 and v3) [14:56] getting as much done in lts+1 seems like a good idea [14:56] unsure how security is feeling about it? [14:56] doubling your pain, basically for a couple of ubuntu releases :p [14:56] but I am concerned about The Project losing steam before the next LTS and leaving us with too many webkits [14:56] we have had prior cases where alternatives were kept around for a bit [14:57] would never be ok to go into an LTS [14:57] yeah, it seems we have time ahead of us [14:57] the question is how sure we are that it will be gone in 23.04 then? [14:57] but unsure how much this can sleep away [14:57] and how could we track that before LTS [14:57] exactly [14:58] so… I wanted to gather other opinions, in particular from sarnold :) [14:59] slyon: git updated [14:59] thank you [14:59] I'm fine with a bit of duplication early in the overall lts cycle, but the consequences of not finishing the transition before the next lts does make me wonder how exactly we'd back out of the situation -- demote the 'old' packages? demote the 'new' packages? hustle and finish it? [14:59] .. be clear at roadmap sprints that Brand New Features can't be added until our old unloved features are removed? :) [15:00] that would be great :) [15:00] I really hope the optimistic view prevails [15:00] yeah, I think we are really early in the LTS meta-cycles [15:00] but the job is all about pessimism, isn't it? :) [15:00] so I’m hopeful [15:00] thanks for raising it and getting started on it early [15:00] but we don’t have a good way of tracking this [15:00] so, let’s +1 for now with the concerns written down in the MIR [15:01] ensuring this is tracked somewhere for the desktop team [15:01] sounds good to you? [15:01] perhaps a cronjob on your local machine that runs apt purge oldwebkitpackage ? :) every week an email of what's left.. [15:01] yeah that works well for me, thanks [15:01] we can upload a package that does it before next LTS :p [15:02] thanks for the feedback! [15:02] I’ll sum that up/copy the verbatim on the bug [15:02] ah great, thanks [15:02] (that’s it from me) [15:03] nothing from me [15:03] nothing here [15:03] nothing [15:06] ok [15:06] closing [15:06] thanks [15:06] #endmeeting [15:06] Meeting ended at 15:06:57 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-05-31-14.29.moin.txt [15:07] thanks cpaelzer, all :) [15:08] thanks all o/ [15:08] o/ [15:09] thanks! [19:00] o/ [19:01] * vorlon waves [19:01] Lukasz sent his apologies [19:02] I don't see cyphermox here [19:02] So it's just us I guess? [19:02] I have two tasks to carry over [19:02] I don't see anything else on the agenda apart from the regular items [19:02] yeah looks like it - so I'd say we're inquorate and can chat informally if you want [19:03] Yep [19:03] Is there anything to discuss here? [19:03] I have an email draft in progress replying to your private thread fwiw [19:03] Thanks! [19:03] hoped to have it sent before the meeting; I'll get it done in the next half hour regardless [19:04] That's the only thing I'm waiting on I think. [19:04] So let's use the time for that :) [19:05] ack