14:29 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status 14:29 <meetingology> Meeting started at 14:29:46 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:29 <meetingology> Available commands: action, commands, idea, info, link, nick 14:29 <sarnold> good morning 14:29 <joalif> o/ 14:30 <cpaelzer> slyon: joalif: sarnold: jamespage: didrocks: ping for MIR meeting 14:30 <didrocks> hey 14:30 <slyon> o/ 14:30 <cpaelzer> no past action items to review 14:30 <cpaelzer> (slyon the MR would be other business I think) 14:30 <slyon> yes 14:30 <cpaelzer> #topic current component mismatches 14:30 <cpaelzer> Mission: Identify required actions and spread the load among the teams 14:30 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:30 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:31 <slyon> 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 <ubottu> Launchpad bug 1971128 in rustc (Ubuntu Jammy) "z3 is incorrectly marked as a MIR candidate" [Medium, Confirmed] 14:31 <cpaelzer> z3 is taken care in https://bugs.launchpad.net/ubuntu/+source/z3/+bug/1971128 btw 14:31 <cpaelzer> hehe - same info :-) 14:31 <slyon> :) 14:32 <cpaelzer> the 5 perl bugs are in https://bugs.launchpad.net/ubuntu/+source/libobject-pad-perl/+bug/1972853 14:32 <ubottu> Launchpad bug 1972853 in libxs-parse-sublike-perl (Ubuntu) "[MIR] lib*-perl" [Undecided, Incomplete] 14:32 <cpaelzer> two approved - others challenged 14:32 <cpaelzer> nothing to act on for us right now 14:32 <cpaelzer> webrick was new last week which lucas brought up in https://bugs.launchpad.net/ubuntu/+source/ruby-webrick/+bug/1975523 14:32 <ubottu> Launchpad bug 1975523 in ruby-webrick (Ubuntu Kinetic) "[MIR] Promote to main in Jammy and Kinetic" [Undecided, New] 14:32 <cpaelzer> and joalif already reviewed that one 14:33 <cpaelzer> python-charset-normalizer is being worked on as well (no bug) 14:33 <cpaelzer> tiff -> lerc is new to me 14:33 <cpaelzer> jamespage: you wanted to look after jaraco IIRC - any news ? 14:34 <cpaelzer> didrocks: tiff -> lerc sounds desktoppy, do you know what this is about? 14:34 <didrocks> no, but I can have a look at it 14:34 <cpaelzer> https://launchpad.net/ubuntu/+source/tiff/4.4.0-2 14:34 <cpaelzer> sounds intentional 14:35 <cpaelzer> and yes tiff is desktop 14:35 <cpaelzer> thanks didrocks for having a look 14:35 <didrocks> (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 <cpaelzer> that is fine, but you still know the people best 14:35 <didrocks> yep :) will track it 14:35 <cpaelzer> it is similar for me and server packaging TBH 14:35 <cpaelzer> I see nothing else worth to discuss in mismatches 14:36 <cpaelzer> at lesat nothing we need to act on 14:36 <sarnold> hmmm, in the debian bug, "The problem is that LERC does not supports BE upstream." 14:36 <cpaelzer> going on unless someone objects 14:36 <cpaelzer> #topic New MIRs 14:36 <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing 14:36 <cpaelzer> #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 <cpaelzer> none 14:36 <cpaelzer> \o/ 14:37 <cpaelzer> we have had enough last week that I'm not complaining 14:37 <didrocks> after last week spam, that helps :) 14:37 <cpaelzer> btw great job by all of you for doing so many reviews quick 14:37 <cpaelzer> #topic Incomplete bugs / questions 14:37 <cpaelzer> Mission: Identify required actions and spread the load among the teams 14:37 <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 14:38 <cpaelzer> most recent updates are tags but nothing important 14:38 <cpaelzer> one is different IMHO 14:38 <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libldac/+bug/1973784 14:38 <ubottu> Launchpad bug 1973784 in libldac (Ubuntu) "[MIR] libldac" [Undecided, Incomplete] 14:39 <cpaelzer> this might lead to the next topic and your MR - slyon do you think this needs an PR to change the wording? 14:39 <slyon> yes, there was some discussion wrt out "seeded-in-ubuntu" (and some question about superficial testing) 14:39 <cpaelzer> I think I have answered them, the open question is - do we want to update the wording in the template? 14:39 <slyon> 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 <slyon> 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 <slyon> (at least that is according to its manpage) 14:41 <cpaelzer> slyon: it is just one more check that would flag things that are in main 14:41 <cpaelzer> you could iterate over dependencies of a new MIR pkg and see if they are all seeded 14:41 <cpaelzer> some people (not me) preferred that way 14:42 <cpaelzer> which is how the statement got in 14:42 <slyon> aha! now I get it 14:42 <slyon> yes we should improve the wording 14:42 <cpaelzer> this list is "use either of these or any else if you like" 14:42 <cpaelzer> how about going to the next section then, while we talk about wording 14:42 <slyon> yes 14:43 <cpaelzer> first security 14:43 <cpaelzer> #topic MIR related Security Review Queue 14:43 <cpaelzer> Mission: Check on progress, do deadlines seem doable? 14:43 <cpaelzer> #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 <cpaelzer> sarnold: how does the cycle look, we are starting to pile up a queue again 14:43 <cpaelzer> sarnold: is this time progress expected sooner than FeatureFreeze :-) 14:44 <sarnold> 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 <sarnold> cpaelzer: very much so :) 14:44 <cpaelzer> anyone but you on those reviews ? 14:44 <sarnold> amurray did one last week, but I don't think there's currently anyone else working a mir 14:44 <sarnold> we've got a team meeting today, I'll fish around for more volunteers :) 14:45 <cpaelzer> instead of exploding late, could you ask for anyone else to assist you in this phase of the cycle please? 14:45 <sarnold> yup 14:45 <cpaelzer> thanks 14:45 <cpaelzer> WFM 14:45 <cpaelzer> #topic Any other business? 14:45 <cpaelzer> we have 1.5 topics here 14:45 <cpaelzer> first the discussion from above 14:46 <cpaelzer> which we haven't a PR yet, slyon do you want to prep a PR matching your newfound understanding until next week? 14:46 <slyon> Now that I got it, I can prepare a proposal to change the wording on this one 14:46 <cpaelzer> or should we try to come up with wording right here right now? 14:46 <cpaelzer> ok, we are not in a hurry - looking forward to that PR then 14:46 <slyon> I'll do it for next meeting 14:46 <cpaelzer> but for today we have 14:46 <cpaelzer> https://github.com/cpaelzer/ubuntu-mir/pull/10/files 14:46 <ubottu> Pull 10 in cpaelzer/ubuntu-mir "mention update of d/control when a Ubuntu delta was introduced" [Open] 14:46 <cpaelzer> This is (I guess) inspired by a forgotten update-maintainer 14:47 <slyon> 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 <didrocks> unsure if this will really help in practice TBH, but could still be added 14:47 <cpaelzer> 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 <didrocks> There are a lot of examples of sync, then adding a change, then sync, and so on 14:47 <didrocks> and people who don’t use their @ubuntu.com or @canonical.com won’t have the warning when building the source package 14:47 <cpaelzer> buildpkg already warns people 14:48 <cpaelzer> but I think it does not consume any more time (we look at d/control anyway) 14:48 <cpaelzer> and therefore should be fine to add 14:48 <didrocks> 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 <slyon> 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 <cpaelzer> I agree to didrocks that I'm unsure if it would help 14:48 <didrocks> I think people should use their @ubuntu/canonical when preparing a package for ubuntu 14:48 <slyon> it doesn't need to be a blocking change for MIR. but we try to keep packages in main in good shape 14:48 <sarnold> do we have any tooling to enforce / notice when version numbers don't clearly indicate a delta from debian? 14:49 <cpaelzer> I'm tempted to suggest "only add the reporter rule, but not the MIR review statement" 14:49 <slyon> WFM 14:49 <cpaelzer> there (at the reporter) is where this could have a benefit by re-assuring the awareness for this 14:49 <didrocks> wfm as well 14:49 <sarnold> 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 <cpaelzer> 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 <sarnold> (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 <slyon> sarnold: it's less about the version string, than about the "Maintainer" field in d/control. 14:50 <cpaelzer> TL;DR: about what update-maintainers does 14:51 <didrocks> 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 <cpaelzer> 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 <cpaelzer> +1 (obviously) 14:51 <slyon> +1 14:51 <didrocks> +1 14:52 <sarnold> is that the first hunk or second hunk? :) 14:52 <slyon> first 14:52 <cpaelzer> first 14:52 <sarnold> +1 :) thanks 14:52 <cpaelzer> we already have reached qorum but joalif? 14:53 <cpaelzer> and jamespage 14:53 <cpaelzer> giving you 30 more sec to object :-) 14:53 <joalif> sorry I'm at other mtg at same time 14:53 <slyon> 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 <joalif> +1 14:53 <cpaelzer> I can slyon 14:54 <didrocks> not signed in, keep your token close to you cpaelzer :) 14:54 <sarnold> lol 14:54 <cpaelzer> I was going through that pain two weeks ago 14:54 <cpaelzer> that is how I have a fresh and shiny token 14:54 <slyon> cpaelzer: do you want me to update the MR or will you just copy paste the first hunk only? 14:54 <didrocks> haha 14:55 <cpaelzer> I have merged the MR (the git isn#t totally in sync anyway) 14:55 <cpaelzer> and updated the wiki 14:55 <slyon> thanks 14:55 <cpaelzer> I'll update git now after the meeting 14:55 <cpaelzer> for you to rebase next weeks change 14:55 <slyon> k 14:55 <cpaelzer> and that seems to wrap up today meeting 14:55 <didrocks> I have a topic to bring 14:55 <didrocks> sorry if you wanted to leave early :p 14:55 <cpaelzer> any last thing we forgot 14:55 <cpaelzer> ah 14:55 <didrocks> about libsoup3 14:55 <cpaelzer> no didrocks, please go 14:55 <didrocks> https://bugs.launchpad.net/ubuntu/+source/libsoup3/+bug/1972153/comments/5 14:55 <ubottu> Launchpad bug 1972153 in libsoup3 (Ubuntu) "[MIR] libsoup3" [Undecided, Confirmed] 14:55 <didrocks> so, it’s a soname bump 14:56 <didrocks> but a security sensitive lib, obviously 14:56 <didrocks> I don’t think we should plan on GNOME updating all dependencies in one release 14:56 <didrocks> and head for the worst scenario 14:56 <didrocks> (one or two releases with both v2 and v3) 14:56 <sarnold> getting as much done in lts+1 seems like a good idea 14:56 <didrocks> unsure how security is feeling about it? 14:56 <didrocks> doubling your pain, basically for a couple of ubuntu releases :p 14:56 <sarnold> but I am concerned about The Project losing steam before the next LTS and leaving us with too many webkits 14:56 <cpaelzer> we have had prior cases where alternatives were kept around for a bit 14:57 <cpaelzer> would never be ok to go into an LTS 14:57 <didrocks> yeah, it seems we have time ahead of us 14:57 <cpaelzer> the question is how sure we are that it will be gone in 23.04 then? 14:57 <didrocks> but unsure how much this can sleep away 14:57 <didrocks> and how could we track that before LTS 14:57 <didrocks> exactly 14:58 <didrocks> so… I wanted to gather other opinions, in particular from sarnold :) 14:59 <cpaelzer> slyon: git updated 14:59 <slyon> thank you 14:59 <sarnold> 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 <sarnold> .. be clear at roadmap sprints that Brand New Features can't be added until our old unloved features are removed? :) 15:00 <didrocks> that would be great :) 15:00 <sarnold> I really hope the optimistic view prevails 15:00 <didrocks> yeah, I think we are really early in the LTS meta-cycles 15:00 <sarnold> but the job is all about pessimism, isn't it? :) 15:00 <didrocks> so I’m hopeful 15:00 <sarnold> thanks for raising it and getting started on it early 15:00 <didrocks> but we don’t have a good way of tracking this 15:00 <didrocks> so, let’s +1 for now with the concerns written down in the MIR 15:01 <didrocks> ensuring this is tracked somewhere for the desktop team 15:01 <didrocks> sounds good to you? 15:01 <sarnold> perhaps a cronjob on your local machine that runs apt purge oldwebkitpackage ? :) every week an email of what's left.. 15:01 <sarnold> yeah that works well for me, thanks 15:01 <didrocks> we can upload a package that does it before next LTS :p 15:02 <didrocks> thanks for the feedback! 15:02 <didrocks> I’ll sum that up/copy the verbatim on the bug 15:02 <sarnold> ah great, thanks 15:02 <didrocks> (that’s it from me) 15:03 <sarnold> nothing from me 15:03 <slyon> nothing here 15:03 <joalif> nothing 15:06 <cpaelzer> ok 15:06 <cpaelzer> closing 15:06 <cpaelzer> thanks 15:06 <cpaelzer> #endmeeting