| jbicha | o/ | 14:30 |
|---|---|---|
| cpaelzer | ahoi | 14:30 |
| cpaelzer | Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) | 14:31 |
| eslerm | o/ | 14:31 |
| cpaelzer | hello everyone, it is unusually calm today | 14:31 |
| sarnold | good morning | 14:31 |
| slyon | o/ | 14:31 |
| cpaelzer | ah, there we go | 14:31 |
| cpaelzer | #topic current component mismatches | 14:31 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 14:31 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:31 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:31 |
| cpaelzer | right away, yes we are still working on the dmarc perl tree | 14:32 |
| cpaelzer | sorry for all the delay | 14:32 |
| cpaelzer | what else is in there being new ... | 14:32 |
| slyon | iniramfs-tools -> dhcpcd seems ready. maybe cpaelzer (as the original reviewer) can double check | 14:32 |
| sarnold | webkit2gtk -> jpeg-xl -> highway ? | 14:33 |
| cpaelzer | I will double check dhcpcd tomorrow morning (moved to that queue) | 14:33 |
| jbicha | sarnold: https://launchpad.net/ubuntu/+source/webkit2gtk/2.41.90-1ubuntu1 | 14:33 |
| cpaelzer | thanks for the ping | 14:33 |
| sarnold | jbicha: yay :) | 14:33 |
| cpaelzer | nice | 14:33 |
| cpaelzer | wow | 14:34 |
| cpaelzer | just curious, how long is that usually building? | 14:34 |
| cpaelzer | 6h in already oO | 14:34 |
| jbicha | sarnold: I expect we'll file a MIR for jpeg-xl for 24.04. We really need the version from experimental (to add gdk-pixbuf support) but there are build test issues | 14:34 |
| cpaelzer | that sounds good jbicha | 14:34 |
| cpaelzer | also support in the upcoming LTS is "more" important than in the shorter mantic release | 14:34 |
| jbicha | cpaelzer: webkit2gtk can take days to build on riscv64. It has to build 3 times: gtk3+libsoup2, gtk3+libsoup3, gtk4. Still more work needed to drop the libsoup2 build | 14:35 |
| sarnold | six and a half hours for 2.40.5-1 | 14:35 |
| cpaelzer | ok, in line with the past then | 14:35 |
| sarnold | heh, and riscv64 .. took 2 days, 14 hours, 48 minutes, 16.1 seconds | 14:36 |
| cpaelzer | the only other seen in mismatches is the long term "jaraco.text" misses | 14:36 |
| cpaelzer | those are known to openstack | 14:36 |
| cpaelzer | no need to act here in the meeting on them | 14:36 |
| cpaelzer | going on ... | 14:36 |
| cpaelzer | #topic New MIRs | 14:37 |
| cpaelzer | Mission: ensure to assign all incoming reviews for fast processing | 14:37 |
| 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:37 |
| cpaelzer | 4 of them | 14:37 |
| cpaelzer | doenet6 again, is that back from incomplete? | 14:37 |
| cpaelzer | no, back from security | 14:37 |
| eslerm | that should be "in progress" ? | 14:37 |
| cpaelzer | checking the right state just now | 14:37 |
| cpaelzer | it was MIR team ack under constraints | 14:38 |
| cpaelzer | since then no feedback on addressing those (it might have happend but we didn#t get pinged to review) | 14:38 |
| cpaelzer | re-review I should say | 14:38 |
| cpaelzer | and security is | 14:38 |
| cpaelzer | After the MIR Team's requirements have been fulfilled to their satisfaction, | 14:38 |
| cpaelzer | the Security team ACK for promoting dotnet6 to main. | 14:38 |
| cpaelzer | so it is actually incomplete | 14:38 |
| cpaelzer | until those requirements have been fulfilled | 14:39 |
| cpaelzer | setting it that way | 14:39 |
| eslerm | thank you | 14:39 |
| cpaelzer | done | 14:40 |
| cpaelzer | next is | 14:40 |
| cpaelzer | libwebm | 14:40 |
| cpaelzer | because that is the oldest | 14:40 |
| cpaelzer | also out of security | 14:40 |
| cpaelzer | nice | 14:40 |
| slyon | this seems ready. autopkgtest are now there and pass. s390x build passes, too. That were the two required TODOs from didrocks | 14:40 |
| slyon | So I guess it should be "In Progress"? | 14:40 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/libwebm/+bug/2004523/comments/5 say all requirements should be good | 14:40 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2004523 in libwebm (Ubuntu) "[MIR] libwebm (transitive dependency of libheif)[libheif -> aom -> libwebm]" [Undecided, New] | 14:40 | |
| cpaelzer | security acked as well | 14:41 |
| cpaelzer | if we trust #5 -> in progress, maybe worth a re-check if all is true | 14:41 |
| cpaelzer | was it just tests that we asked for? | 14:41 |
| cpaelzer | build warnings | 14:41 |
| slyon | cpaelzer: I just did a brief re-check. didrocks requrested autopkgtest and s390x builds. Which is both done | 14:41 |
| eslerm | for all the codec related MIRs, could we please review https://bugs.launchpad.net/ubuntu/+source/libheif/+bug/1827442 | 14:42 |
| -ubottu:#ubuntu-meeting- Launchpad bug 1827442 in libheif (Ubuntu) "[MIR] libheif" [Undecided, In Progress] | 14:42 | |
| slyon | others were recommended TODOs | 14:42 |
| cpaelzer | yes, coming to the same conclusion slyon | 14:42 |
| cpaelzer | setting to in-progress where it can wait until all heif bits are ready | 14:42 |
| slyon | ack | 14:42 |
| cpaelzer | two left | 14:43 |
| cpaelzer | dracut and libei | 14:43 |
| cpaelzer | we only have slyon and me today | 14:44 |
| cpaelzer | or is any of didrocks or joalif around as well? | 14:44 |
| slyon | dracut is foundations. So I guess I take libei | 14:44 |
| cpaelzer | sort of makes sense | 14:44 |
| cpaelzer | I'd have liked emulated input, but for separation it makes sense | 14:44 |
| cpaelzer | I can#t guarantee fast processing on dracut | 14:44 |
| cpaelzer | what is the urgency level on this - do you happen to know slyon? | 14:45 |
| sarnold | re dracut ... I had the impression that vor_lon may not want to take us down that path https://lists.ubuntu.com/archives/ubuntu-devel/2023-August/042752.html | 14:45 |
| slyon | cpaelzer: I think the plan is landing it this cycle | 14:45 |
| cpaelzer | puh, ok | 14:45 |
| cpaelzer | well, i'll try | 14:45 |
| slyon | I recommended bdrung to get the changes into -proposed already, while waiting on MIR. | 14:45 |
| cpaelzer | ack | 14:46 |
| slyon | it's related to all the inird efficiency discussions on ubuntu-devel | 14:46 |
| cpaelzer | in regard to FF especially | 14:46 |
| cpaelzer | #topic Incomplete bugs / questions | 14:46 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 14:46 |
| 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:46 |
| cpaelzer | dotnet, heif, libmail - all cases we already had | 14:47 |
| cpaelzer | what is s390x-tools with rust waiting on? | 14:47 |
| cpaelzer | ... checking | 14:47 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/2030482 | 14:47 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2030482 in s390-tools (Ubuntu) "[MIR] s390-tools Rust dependencies (vendored)" [Undecided, Incomplete] | 14:47 | |
| slyon | s390-tools needs a packaging update and filing a MIR, Foundations will look into that | 14:48 |
| cpaelzer | thanks | 14:48 |
| cpaelzer | but nothing to act yet as MIR team | 14:48 |
| cpaelzer | FYI I think other serde-* have been approved as well | 14:48 |
| slyon | basically a re-MIR, due to new vendored Dependencies, because of newly added Rust tooling | 14:48 |
| cpaelzer | I saw your scan for "what is in already" | 14:48 |
| cpaelzer | ok, next agenda item | 14:48 |
| cpaelzer | #topic Process/Documentation improvements | 14:48 |
| cpaelzer | Mission: Review pending process/documentation pull-requests or issues | 14:48 |
| sarnold | that "what'sin already" scan is very nifty :) | 14:48 |
| cpaelzer | #link https://github.com/canonical/ubuntu-mir/pulls | 14:49 |
| cpaelzer | #link https://github.com/canonical/ubuntu-mir/issues | 14:49 |
| cpaelzer | re-reviews are on hold | 14:49 |
| cpaelzer | no one really wanted to commit the resources for those | 14:49 |
| cpaelzer | the idea isn't bad | 14:49 |
| cpaelzer | but it isn't the right time it seems | 14:49 |
| sarnold | :( | 14:49 |
| eslerm | :,( | 14:50 |
| cpaelzer | we asked last week for everyone to read on base-sets | 14:50 |
| cpaelzer | slyon: did you get enough feedback? | 14:50 |
| cpaelzer | that is https://github.com/canonical/ubuntu-mir/issues/35 | 14:50 |
| -ubottu:#ubuntu-meeting- Issue 35 in canonical/ubuntu-mir "RFC: Introduce 'base-sets' for vendored dependencies" [Open] | 14:50 | |
| slyon | cpaelzer: eh.. not too much feedback. | 14:50 |
| slyon | But I think the idea of having those as parts of seeds is good. | 14:51 |
| slyon | Not sure what the next step would be, though. | 14:51 |
| cpaelzer | was that my idea? then it is good :-P | 14:51 |
| sarnold | :) | 14:51 |
| cpaelzer | but TBH - feel free to continue pushing on this a bit at low/med prio | 14:51 |
| slyon | Maybe I'll bring that up with toolchain maintainers during the next sprint | 14:51 |
| cpaelzer | I think it is a good move for the rust toolchain owning sub-team of foundations | 14:51 |
| cpaelzer | +1 | 14:51 |
| cpaelzer | and then there is https://github.com/canonical/ubuntu-mir/issues/34 | 14:52 |
| -ubottu:#ubuntu-meeting- Issue 34 in canonical/ubuntu-mir "Should we ask for a bit of research/investment on isolation?" [Open] | 14:52 | |
| cpaelzer | I guess we had general "we like it" but I'd need to prep a PR with suggested wording | 14:52 |
| cpaelzer | putting it on my not-so-far-back-log | 14:52 |
| cpaelzer | #topic MIR related Security Review Queue | 14:52 |
| cpaelzer | Mission: Check on progress, do deadlines seem doable? | 14:52 |
| cpaelzer | Some clients can only work with one, some with the other escaping - the URLs point to the same place. | 14:52 |
| 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:52 |
| cpaelzer | #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:52 |
| cpaelzer | Internal link | 14:52 |
| cpaelzer | - ensure your teams items are prioritized among each other as you'd expect | 14:52 |
| cpaelzer | - ensure community requests do not get stomped by teams calling for favors too much | 14:52 |
| cpaelzer | #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 | 14:52 |
| cpaelzer | we have seen quite some complete | 14:52 |
| cpaelzer | I'm proud of security, tell them that eslerm and sarnold! | 14:52 |
| sarnold | :D | 14:53 |
| cpaelzer | queues look healthy, some in each lane | 14:53 |
| cpaelzer | and we have seen there is progress | 14:53 |
| cpaelzer | is anything in danger of beeing too later for the cycle? | 14:53 |
| sarnold | I'm still a bit scared of the big pile of perl but it feels to me like things are going smoothly | 14:53 |
| cpaelzer | remember, that promotions can be done after FF - just rebuilds with changed feature enablement are a bit more tricky | 14:53 |
| cpaelzer | I keep pushing for the perl work internally | 14:54 |
| cpaelzer | but really, look how those were in the past | 14:54 |
| sarnold | yes | 14:54 |
| cpaelzer | I expect maybe <5 out of those to need to go in depth | 14:54 |
| sarnold | I know you've beencutting that pile down to size :) | 14:54 |
| cpaelzer | and that should be doable | 14:54 |
| eslerm | I'd like to discuss LP#1827442 and possibly pause all related security reviews until it is retriaged | 14:54 |
| -ubottu:#ubuntu-meeting- Launchpad bug 1827442 in libheif (Ubuntu) "[MIR] libheif" [Undecided, In Progress] https://launchpad.net/bugs/1827442 | 14:54 | |
| sarnold | and a lot of those just won't go through us | 14:54 |
| cpaelzer | well then eslerm | 14:55 |
| cpaelzer | #topic Any other business? | 14:55 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/libheif/+bug/1827442 | 14:55 |
| cpaelzer | as requested to discuss above | 14:55 |
| jbicha | . | 14:56 |
| eslerm | comments near the end state the current status | 14:56 |
| sarnold | uhoh, is that a placeholder for a *new* issue? or an indicator of a comment-in-progress? :) | 14:56 |
| eslerm | I'm not sure that libheif could be promoted without kvazaar or other replacements | 14:56 |
| cpaelzer | That is actually a great set of a summary eslerm | 14:56 |
| sarnold | yes | 14:57 |
| cpaelzer | I only fail to see how each of those component stand in their own progress through the MIR process | 14:57 |
| jbicha | I'm wondering how strict the MIR team's policy on requiring rust dependencies to be vendored is. Specifically thinking about librsvg for 24.04 (out of scope for Mantic). background in Debian bug 1049413 | 14:57 |
| -ubottu:#ubuntu-meeting- Debian bug 1049413 in src:librsvg "librsvg: Update to 2.56 or later" [Wishlist, Open] https://bugs.debian.org/1049413 | 14:57 | |
| slyon | jbicha: I guess the situation is similar as bug #2030482 | 14:58 |
| -ubottu:#ubuntu-meeting- Bug 2030482 in s390-tools (Ubuntu) "[MIR] s390-tools Rust dependencies (vendored)" [Undecided, Incomplete] https://launchpad.net/bugs/2030482 | 14:58 | |
| cpaelzer | jbicha: we have recently discussed on slowly weakening the "forced vendoring" if there is strong reason to believe in stability of a particular lib (https://github.com/canonical/ubuntu-mir/issues/35) | 14:58 |
| -ubottu:#ubuntu-meeting- Issue 35 in canonical/ubuntu-mir "RFC: Introduce 'base-sets' for vendored dependencies" [Open] | 14:58 | |
| slyon | eslerm: I guess I can ask vpa1977 to give his stance on bug #1827442 AFAIK it's a bit on the back burner right now | 14:58 |
| -ubottu:#ubuntu-meeting- Bug 1827442 in libheif (Ubuntu) "[MIR] libheif" [Undecided, In Progress] https://launchpad.net/bugs/1827442 | 14:58 | |
| cpaelzer | jbicha: but this hasn't yet concluded or led to changes to policy being made | 14:58 |
| jbicha | I think the Rust GTK stack is still under heavy development but we generally have GTK bindings for popular languages in main. And Rust is very popular for newer GNOME-ish apps | 14:59 |
| eslerm | thanks slyon, I'm only raising this because of mantic. if this is a backburner issue, perhaps that is fine | 14:59 |
| cpaelzer | jbicha: is that GTK rust stack at least "one stack" which generally agrees on which versions/interfaces to use at a given time? | 15:00 |
| cpaelzer | that incompatibility and often breaking on changes was one of the reasons to enforce vendoring back int he day | 15:00 |
| cpaelzer | you might want to bribe slyon and the toolchain team to act on https://github.com/canonical/ubuntu-mir/issues/35 and bug #2030482 quicker as they would pave the way and policy for you | 15:01 |
| -ubottu:#ubuntu-meeting- Bug 2030482 in s390-tools (Ubuntu) "[MIR] s390-tools Rust dependencies (vendored)" [Undecided, Incomplete] https://launchpad.net/bugs/2030482 | 15:01 | |
| -ubottu:#ubuntu-meeting- Issue 35 in canonical/ubuntu-mir "RFC: Introduce 'base-sets' for vendored dependencies" [Open] | 15:01 | |
| jbicha | the rust-gtk stack is large (I don't have an exact count, maybe 15+ packages) and yes, they are generally compatible with each other & hopefully 3rd party apps keep up | 15:01 |
| cpaelzer | I'm unsure if we can do much for you on that topday jbicha other than saying "yes we have thought about reconsidering the forced-vendoring" | 15:01 |
| cpaelzer | jbicha: you might be able to help by stating that as an example and the general compatibility into https://github.com/canonical/ubuntu-mir/issues/35 | 15:02 |
| -ubottu:#ubuntu-meeting- Issue 35 in canonical/ubuntu-mir "RFC: Introduce 'base-sets' for vendored dependencies" [Open] | 15:02 | |
| jbicha | that's fine. This is just an early heads up that we are exploring this | 15:02 |
| cpaelzer | to be clear, no one said "yay vendoring" it was more a choice between two bad options back then picking the less impactful one | 15:02 |
| cpaelzer | but as we see in many places now, things seem to change ... | 15:03 |
| cpaelzer | but either way this needs help, support and backing by the /rust)-toolchain people | 15:03 |
| cpaelzer | so win them! | 15:03 |
| cpaelzer | we are over time already | 15:03 |
| cpaelzer | but also at the end of the agenda | 15:03 |
| cpaelzer | thanks jbicha for bringing it up - this helps the topic overall to gain traction | 15:03 |
| cpaelzer | nothing else from server | 15:03 |
| sarnold | nothin from me | 15:04 |
| jbicha | thanks all | 15:04 |
| cpaelzer | thank you all | 15:04 |
| cpaelzer | bye | 15:04 |
| slyon | nothing, thanks! | 15:04 |
| cpaelzer | #endmeeting | 15:04 |
| eslerm | o/ | 15:04 |
| sarnold | thanks cpaelzer, all :) | 15:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
