14:31 #startmeeting Weekly Main Inclusion Requests status 14:31 Meeting started at 14:31:10 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:31 Available commands: action, commands, idea, info, link, nick 14:31 good morning 14:31 Ping for MIR meeting - didrocks joalif slyon sarnold c_paelzer jamespage ( eslerm dviererbe ) 14:31 #topic current component mismatches 14:31 Mission: Identify required actions and spread the load among the teams 14:31 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:31 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:31 o/ 14:32 dkms vs gcc-13 is new and for the kernel team to look into 14:32 Hi! If you have any questions regarding the MIR for `retry`, let me know, I'm around :-) 14:32 x11-utils vs luit is new (only a Recommends, so we might be able to just drop/dowgrade it to Suggests), it's for the desktop team, so I'd like to ask didrocks for investigation 14:33 the other ones seem to be known/in-progress. Thanks jamespage for getting all the openstack MIRs started! 14:33 #topic New MIRs 14:33 Mission: ensure to assign all incoming reviews for fast processing 14:33 #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:33 I have a question in those for later 14:33 ko 14:33 ok* 14:34 I'll take a look at bug #2066272 after the meeting (CC jbicha), to verify if my requirement was met 14:35 bug #2073783 14:36 this is new and for the desktop team, I can probably take it for review 14:36 bug #2076381 14:37 This is also new and for canonical-ubuntu-qa (related to foundations). joalif do you have capacity to take that? 14:38 does canonical-ubuntu-qa have sufficient capacity to take on new ownership? 14:38 Skia: ^ ? 14:38 yes, this would be part of what we already do in maintaining autopkgtest 14:39 ack, thanks 14:39 I see no other MIR bugs assigned to joalif, currently. So I'm passing it to her. Please unassign yourself if you feel like you can't handle it. 14:39 Please note that the MIR also concern Jammy and Noble 14:39 because of the SRU exception for autopkgtest 14:40 thanks for pointing it out :) 700 lines of hopefully-good-quality C is probably no real risk for previous release support 14:40 Skia: we've been doing retroactive MIRs in the past. The versions are very close (v1.0.4 & v1.0.5) so I don't see an issue with that 14:40 okay, good to hear 14:40 we'd usually first handle devel/oracular, and then double-check the delta to the LTS 14:41 Skia: you might need to poke us about it from time to time, as it might fall through the reporting cracks when it's resolved for devel/oracular ;-) 14:41 #topic Incomplete bugs / questions 14:41 Mission: Identify required actions and spread the load among the teams 14:41 #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:42 .. and I don't know what the actual mechanism is to get it published to main in the previous releases. 14:42 slyon: noted :-) 14:42 sarnold: it's usually the normal MIR + (potential) security review. Then poking an AA to get it promoted 14:42 slyon: is a new upload necessary? 14:43 sarnold: I don't think so, as long as the MIR review doesn't find any issues. Otherwise, we'd need an SRU before being able to promote it 14:43 bug #2072620 is the only bug with recent updates 14:44 ^ tracking update from jamespage. Is this the bug you wanted to talk about? 14:44 actually its bug 2072621 14:44 okay. Let's wait for AOB then.. 14:44 referencing just needs a bit of work to get a test suite running - working with python modules team in debian for that 14:44 ACK, thanks for the update. Moving on. 14:44 #topic Process/Documentation improvements 14:44 slyon: hmm, is there an easy way to find the packages that "are in main" but don't have a new upload since the move, and thus only have .../universe/... paths on the archives? 14:44 Mission: Review pending process/documentation pull-requests or issues 14:45 #link https://github.com/canonical/ubuntu-mir/pulls 14:45 #link https://github.com/canonical/ubuntu-mir/issues 14:45 oh wow you're really on top of things today :D 14:46 sarnold: I don't know... We don't need new uploads when moving things from universe->main in devel. So I'd assume the AA tooling taking care of everything. 14:46 (sorry, I want to save some time for AOB :P) 14:47 *nod* 14:47 I merged https://github.com/canonical/ubuntu-mir/pull/62 earlier today. Thanks for everybody who reviewed! 14:47 I created https://github.com/canonical/ubuntu-mir/pull/64 earlier today, addressing a valid issue reported by eslerm (thanks!) 14:48 Please everybody take a look at ^ and give your comments on GitHub, so we can get it landed soon. 14:48 #topic MIR related Security Review Queue 14:48 Mission: Check on progress, do deadlines seem doable? 14:48 Some clients can only work with one, some with the other escaping - the URLs point to the same place. 14:48 #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:48 #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir 14:48 Internal link 14:48 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 14:48 sarnold: what's the status on your side? 14:48 I'm curious about whether the Security team thinks it is likely for libimobiledevice-glue to complete its Security Review before 24.10 is released 14:48 This isn't to bump its priority (same priority as several other desktop pkgs), but because it is part of an incomplete transition we inherited from Debian autosync. 14:48 So if it lands for 24.10, we can leave things as they are. If it is unlikely to land, then we could work to undo the transition for 24.10 and redo it next cycle. 14:48 slyon: I was at another meeting, I'll take care of the MIR 14:49 thx joalif! 14:50 (you could also look into it and get back to me about it) 14:50 I see a bunch of security review piling up, especially for the desktop team. 14:50 heh yeah i'll have ot do that :( the included copies of crypto code is slightly worrying 14:50 so much :( 14:51 maybe c_paelzer can help raising severity for getting new security reviewers once he's back from PTO.. 14:51 But they'd also need to be trained first :( 14:51 we did make some progress on sysprof, but otherwise it's a real challenge to get time from folks due to deadlines from $elsewhere 14:52 ACK. So jbicha please coordinate with sarnold directly when you need to shuffle the desktop security review priority/order. 14:52 #topic Any other business? 14:52 jamespage: wanted to talk about bug #2072621 14:52 nothing else from me :) 14:52 ah yes 14:52 so... 14:53 package is a python wrapper around rust (similar to python-crytography) 14:54 I was trying to figure out how this fits into the agreed standards for Rust packages - am I reading the rules right in that the Rust dependencies should be vendored into the package? 14:54 yes 14:55 so to confirm that's different from static linking from rust packages via BD's 14:55 yes, that's been common practice for the Rust ecosystem. Because non-venored dependencies have been unfeasible for now (although it would be nicer/prefered) 14:56 ok I was looking for prior art to follow - python-cryptography is similar 14:57 is that newly rustic? 14:57 rpds-py? its in the dependency chain for jsonschema updates coming from debian 14:57 I wonder if that started doing rust after it was in main, and perhaps never got real attention to it after a transition 14:57 replacement for pyrsistent which is in main (but scheduled for demoition) 14:58 If the dependency tree is small enough, it would still be nicer to do static linking from rust packages BD's, but we might not have all the correct verions in the archive and it might need lots of additional MIR paperwork for each of the BDs. So vendoring it all into the python package is the more streamlined approach 14:58 sorry, I meant the python-cryptography -- I'm curious if it actually serves as a good example of what we decided on 14:58 it did switch once in main yes 14:58 its small 14:58 https://www.irccloud.com/pastebin/nivxTBBl/ 14:59 that does pull in a load of other librust-*-dev packages 14:59 ^ that's the problem 15:00 infact more than a few - loads 15:00 ok so I need to vendor in what's needed 15:00 we'd need to work through the whole tree of librust-*-dev packages, doing MIRs. Which was deemed infeasible in the past. 15:00 ACK. Vendoring is the way forward here. 15:01 did we have a nice discussion somewhere of the best way to approach that problem? 15:01 jamespage: there's been some discussion about how to best trim the set of vendored dependnecies to a minimum, I think this is the starting point: https://github.com/canonical/ubuntu-mir/issues/51 15:02 thanks for all of the pointers :) 15:02 Do we have anything else for AOB? 15:02 nothing here 15:03 3.2.1 15:03 thanks all! o/ 15:03 thanks slyon, all :) 15:03 #endmeeting