14:31 <slyon> #startmeeting Weekly Main Inclusion Requests status
14:31 <meetingology> Meeting started at 14:31:14 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:31 <meetingology> Available commands: action, commands, idea, info, link, nick
14:31 <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold c_paelzer jamespage ( eslerm dviererbe )
14:31 <slyon> #topic current component mismatches
14:31 <slyon> Mission: Identify required actions and spread the load among the teams
14:31 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
14:31 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
14:32 <slyon> the component-mismatches report is still outdated. Last run was about a week ago. sil2100 is coordinating with IS to get it resolved.
14:32 <jamespage> o/
14:32 <slyon> There's not much we can do. No news in the old reports.
14:32 <slyon> #topic New MIRs
14:32 <slyon> Mission: ensure to assign all incoming reviews for fast processing
14:32 <slyon> #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:32 <slyon> the review queue is empty.
14:32 <slyon> #topic Incomplete bugs / questions
14:33 <slyon> Mission: Identify required actions and spread the load among the teams
14:33 <slyon> #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:33 <slyon> bug #2080965 is basically ready
14:33 <slyon> but waiting for some -dev packages exclusion discussion (more on that later)
14:34 <slyon> (no security review needed)
14:34 <slyon> bug #2058192
14:35 <slyon> eslerm suggested this package should move to the OEM archive. I talked to sil2100 but he couldn't help a lot. We need to coordinate with the OEM team directly, then he can drop it from multiverse/restricted (if desired).
14:35 <slyon> The updates on the LP bug suggest that the OEM team might be interested in keeping it in the primary archive, still.
14:36 <cpaelzer> hey, sorry for all the roadmap to blast over MIR meetings
14:36 <cpaelzer> BTW I've followed up on wsdd as you pinged me last week - thanks
14:37 <sarnold> wsdd https://bugs.launchpad.net/ubuntu/+source/wsdd/+bug/2070025
14:37 <slyon> let me ask them to address the comments made by didrocks on the bug report, as that would be a minimal requirement for main/restricted inclusion
14:39 <didrocks> thanks slyon :)
14:40 <slyon> comment added.
14:40 <slyon> thanks for moving wsdd forward, cpaelzer !
14:41 <slyon> I also moved this one forward, which is now ready for a seed change https://bugs.launchpad.net/ubuntu/+source/xdg-terminal-exec/+bug/2069308 (cc jbicha)
14:41 <slyon> #topic Process/Documentation improvements
14:41 <slyon> Mission: Review pending process/documentation pull-requests or issues
14:41 <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
14:41 <slyon> #link https://github.com/canonical/ubuntu-mir/issues
14:42 <slyon> sarnold: could you confirm this is working for you? https://github.com/canonical/ubuntu-mir/pull/68 then we could merge it
14:42 <sarnold> oo moment..
14:42 <slyon> I wasn't able to continue on the Rust docs, https://github.com/canonical/ubuntu-mir/pull/66 – would love to adopt/recommend the s390-tools way of doing it, but didn't get to it this week between all the other stuff
14:44 <slyon> which leaves us with only one (new) issue: https://github.com/canonical/ubuntu-mir/issues/69 and I'd love to see senior MIR people chime in on this (cc cpaelzer didrocks jamespage)
14:44 <slyon> I had some discussions about this with seb128 today, after the architecture-properties MIR in https://launchpad.net/bugs/2080965
14:45 <cpaelzer> why is that even a big problem?
14:45 <cpaelzer> the "by default" is only the auto-include meant to cover things that are usually not picked up by direct dependencies
14:45 <cpaelzer> that is the set of -doc and -dev
14:45 <cpaelzer> but AFAIK it was always ok to opt-out by adding an extra-exclude
14:46 <slyon> we have a case of libglib2.0-dev depending on a new "architectures-properties" tool that mostly a helper script for cross-building
14:46 <cpaelzer> Surely this comes from a time when the support on universe was not yet as good, community not as mature and pro did not yet exist to cover universe
14:46 <cpaelzer> back than it was more important to move those to main if it was possible
14:47 <cpaelzer> but if there are conflicts and problems, and really the only thing that puts the -dev/-doc into main is the auto-incliude
14:47 <cpaelzer> then just go for adding an exclude
14:47 <cpaelzer> If I understand correctly, the question is "do we still want to try to promote these by default" right?
14:48 <slyon> right. I guess that's true for "normal" packages. But "Demoting libglib2.0-dev isn't easy because it's a low level libraries that most other desktop dev libraries depends on." So the desktop team would need to maintain a long-tail of -dev exclusions
14:48 <slyon> or get their -dev dependencies included in "main"
14:48 <slyon> correct cpaelzer
14:48 <cpaelzer> If other things "really" depend on it (not just the auto-inclusion), then yes it should stay in main IMHO
14:49 <cpaelzer> about the issue of maintaining long tails
14:49 <cpaelzer> we faced similar issues in server when some packages had too much content in a few packages
14:49 <cpaelzer> like 50 plugins of which only 2 really were prime time
14:49 <cpaelzer> there we ended up splitting the package
14:50 <cpaelzer> and the one that stayed in main has much more reasonable dependencies than the former huge super-package
14:50 <cpaelzer> I do not know the libglib2.0-dev situation, but could something like that help there too?
14:50 <didrocks> cpaelzer: smell like a similar story than gstreamer plugins :)
14:50 <slyon> I need to check the germinate output to see what exactly is pulling in libglib2.0-dev.
14:51 <didrocks> slyon: I’m afraid you will end up with a long list of -dev packages depending on libglib2.0-dev
14:51 <didrocks> gtk being one, for instance
14:51 <slyon> But do I understand correctly, that you suggest instead of doing the MIR for a new build-tool dependency we should rather work with Extra-Excludes?
14:52 <cpaelzer> the one that is accoutned for in germinate is libaccountsservice-dev  , but there might be more than that as didrocks says
14:52 <didrocks> yeah, germinate will only points to the "first" one that it founds IIRC
14:52 <cpaelzer> correct
14:52 <didrocks> you "fix" it, then goes to the next…
14:52 <slyon> right.
14:53 <cpaelzer> slyon: If that -dev package has no deep purpose or reason on it's own to be in main - AND only is in for auto-include. Then an auto-exclude is ok AFAIK
14:53 <cpaelzer> there are -dev which contain tools that are needed, others are actually always linked in so they are actually active code, ... - these would not qualify
14:53 <cpaelzer> but if it really is a normal -dev mostly having headers but not more
14:53 <cpaelzer> then an exclude if it causes pain might be ok
14:54 <didrocks> and agreed
14:54 <cpaelzer> but one would need to work back the chain e.g. the aforementioned libaccountsservice-dev
14:54 <cpaelzer> and add them all
14:54 <cpaelzer> ensuring that NONE of them has a deeper purpose
14:54 <cpaelzer> -doc is a similar story BTW
14:55 <cpaelzer> often pulling in weird tools to build yet another special markdown language
14:55 <didrocks> another approach is to patch so that architectures-properties can be downgraded to a suggests
14:55 <slyon> Yes... https://bugs.launchpad.net/ubuntu/+source/architecture-properties/+bug/2080965 might have a deeper purpose potentially, it provides the "architecture-is-64bit" or "architecture-is-big-endian" meta packages. but OTOH we didn't need it in main up to now
14:55 <didrocks> as it’s "only" for cross-arch builds from what you discussed?
14:55 <jbicha> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=4c41750b is an approximation of the number of excludes you would need
14:56 <slyon> it also provides a wrapper around qemu-user to execute cross-architecture tests for example
14:56 <jbicha> it's incomplete because it would take me a few rounds with an archive admin to ensure we got everything
14:56 <sarnold> the "Build-Dependencies not necessarily in main" thing was kinda intended to help us keep sphinx and the like from getting messy
14:58 <slyon> Okay. ovearll it seems like there's no consensus for changing the defaults to exclude -dev packages. And we should rather work out the issues case-by-case. Do we want to vote on this?
14:59 <slyon> Maybe we can do that on Github, so we can move on with the meeting.
14:59 <slyon> #topic MIR related Security Review Queue
14:59 <slyon> Mission: Check on progress, do deadlines seem doable?
14:59 <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
14:59 <slyon> #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:59 <slyon> #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:59 <slyon> Internal link
14:59 <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:59 <slyon> sarnold: are you still keeping up the pace?
15:01 <sarnold> sorry, distracted ..
15:01 <slyon> I see rpds-py is now in progress (cc jamespage)
15:02 <jamespage> \o/
15:02 <sarnold> the velocity is not what it was, but yes, progress is still being made on some packages
15:02 <slyon> Okay. We're over time already. So do we have anything else?
15:02 <slyon> https://github.com/canonical/ubuntu-mir/issues/67
15:02 <cpaelzer> at least that, thanks
15:03 <slyon> #topic Any other business?
15:03 <slyon> (sorry, wrong paste-buffer above)
15:03 <sarnold> sigh, I thought I had something, but i've gone blank. :/
15:04 <cpaelzer> not from me
15:04 <slyon> sarnold: next time you remember it, create an issue on the ubuntu-mir github. so you don't have to remember it :)
15:04 <cpaelzer> lol
15:04 <sarnold> lol
15:05 <slyon> :P
15:05 <cpaelzer> thanks slyon for driging in these roadmappy times
15:05 <cpaelzer> umm "driving"
15:05 <slyon> if nothing else, thats all, folks!
15:05 <sarnold> thanks slyon, all :)
15:05 <slyon> #endmeeting