[15:28] <jbicha> o/
[15:30] <eslerm> o/
[15:30] <cpaelzer> arrr
[15:30] <cpaelzer> I have a meeting running over
[15:30] <cpaelzer> I can read but might not be able to lead
[15:30] <cpaelzer> anyone up to jump in?
[15:30] <cpaelzer> pretty please?
[15:30] <sarnold> good morning
[15:30] <slyon> hey!
[15:30] <slyon> I can I guess...
[15:30] <slyon> let me prepare some tabs
[15:30] <joalif> o/
[15:31] <jamespage> o/
[15:31] <slyon> #startmeeting Weekly Main Inclusion Requests status
[15:31] <meetingology> Meeting started at 15:31:20 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:31] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:31] <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[15:31] <slyon> #topic current component mismatches
[15:31] <slyon> Mission: Identify required actions and spread the load among the teams
[15:31] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:31] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:31] <slyon> non-proposed looking clean
[15:32] <slyon> -proposed is known AFAICT, except for openjdk-21
[15:32] <slyon> For openjdk-21 we need to demote the -doc binary. cpaelzer could you do that (later)?
[15:32] <slyon> That's how it had been handled in the past
[15:33] <slyon> #topic New MIRs
[15:33] <slyon> Mission: ensure to assign all incoming reviews for fast processing
[15:33] <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
[15:33] <slyon> bug #2054480
[15:33] -ubottu:#ubuntu-meeting- Bug 2054480 in nbd (Ubuntu) "[MIR] nbd-client" [Undecided, New] https://launchpad.net/bugs/2054480
[15:33] <didrocks> (I’m around today, but in meetings)
[15:34] <slyon> Any volunteers to review ^ ?
[15:34] <didrocks> I’m happy to take any MIRs, I can’t sign off they will be done next week though, I’ll aim for the next next one
[15:34] <didrocks> of*
[15:34] <joalif> i can take the simple-perl
[15:35] <slyon> simple-perl is done already AFAIC.
[15:35] <didrocks> it doesn’t seem there is due date for ndb, so I can it
[15:35] <didrocks> take*
[15:35] <slyon> thanks, assigning to didrocks
[15:35] <jamespage> that ndb one is odd - its a binary only promotion for a package already in main
[15:35] <jamespage> so that might be super-easy!
[15:36] <jamespage> nbd rather...
[15:36] <jamespage> I also typo that
[15:36] <slyon> indeed. it's well written too, so let's see what remarks are given
[15:36] <slyon> moving on... bug #2054480
[15:36] -ubottu:#ubuntu-meeting- Bug 2054480 in nbd (Ubuntu) "[MIR] nbd-client" [Undecided, New] https://launchpad.net/bugs/2054480
[15:36] <slyon> opps.
[15:36] <slyon> bug #2029379
[15:37] -ubottu:#ubuntu-meeting- Bug 2029379 in libdbd-sqlite3-perl (Ubuntu) "[MIR] promote libdbd-sqlite3-perl (libmail-dmarc-perl dependency)" [Undecided, New] https://launchpad.net/bugs/2029379
[15:37] <joalif> that also has a review
[15:38] <slyon> it seems ready, except for the team subscription. Can you confirm this joalif ?
[15:38] <slyon> So I'd move it to "In Progress"
[15:38] <joalif> yup that's correct
[15:39] <slyon> bug #2031491
[15:39] <cpaelzer> I can fix the subscription right now
[15:39] -ubottu:#ubuntu-meeting- Bug 2031491 in libemail-simple-perl (Ubuntu) "[MIR] libemail-simple-perl ( libemail-mime-perl dependency as libmail-dmarc-perl dependency)" [Undecided, New] https://launchpad.net/bugs/2031491
[15:40] <slyon> same here, we have the condicinal ACK and the duplication concern was addressed
[15:40] <slyon> already subscribed, too
[15:40] <slyon> let's move it forward
[15:41] <slyon> bug #2055165
[15:41] -ubottu:#ubuntu-meeting- Bug 2055165 in gcr4 (Ubuntu) "Move gcr4 to main" [Undecided, New] https://launchpad.net/bugs/2055165
[15:41] <jbicha> hi
[15:42] <jbicha> we're wondering if we can avoid the whole MIR process for gcr4
[15:42] <slyon> jbicha: hey! Are there major code changes between gcr and gcr4? Or should it be considered a "versioned package upgrade", that does not need MIR, but just AA approval?
[15:43] <cpaelzer> FYI: subscription on libdbd-sqlite3-perl added
[15:43] <sarnold> I don't understand quite what that first paragraph is saying; if gcr doesn't include gui widgets, why do we need a separate version for gtk4?
[15:45] <jbicha> gtk4 apps couldn't use libgcr-ui-3-1 anyway because of its gtk3 dependency. gcr devs also chose to make some other api changes at the same time
[15:45] <slyon> jbicha: is gcr4 a continuation of the gcr codebase?
[15:45] <jbicha> slyon: yes!
[15:46] <jbicha> it's still https://gitlab.gnome.org/GNOME/gcr
[15:46] <cpaelzer> usually versioned transitions can have some overlap, but eventually resolve. Is this expected to only have gcr4 at some point, if so when?
[15:46] <slyon> I'd assume that depends on GTK3 usage in main..?
[15:47] <jbicha> I can't give you an exact time since seahorse & shotwell are undermaintained & porting to gtk4 is a lot for big apps
[15:47] <cpaelzer> I see, so it really is once all GTK3 in main are gone some day
[15:47] <jbicha> the old gcr will be in universe for a long time
[15:47] <jbicha> yes
[15:47] <seb128> hey there, sorry I wanted to join but I've another call at the same time and forgot to /j on IRC
[15:48] <cpaelzer> I'm personally fine with that TBH
[15:48] <seb128> jbicha, thanks for covering for desktop :)
[15:48] <slyon> Considering it's a versioned transition and we have precedence for parallel GTK3 & GTK4 I'm +1 on promoting this. But I'd like to defer to cpaelzer and/or didrocks for a final decision, with their AA hats on
[15:48] <cpaelzer> I'm +1 as well, with a twist (not too bad one, let me write ...)
[15:49] <didrocks> I don’t think that’s much different from gtk3 -> gtk4. It would have been a good time for reviewing the package and how we can improve it, but I don’t think this is doable in a realistic timeframe
[15:49] <cpaelzer> I haven't had a look, but is it reasonable to ask for improved testing and quality
[15:49] <cpaelzer> otherwise we have to wait for GTK5  :-)
[15:49] <cpaelzer> OTOH I totally see hwo time runs out for that
[15:50] <cpaelzer> given that it is the same as before but newer I'm +1 even without, but couldn't resist asking for some QA and testing eyes
[15:50] <slyon> Let's make improved/non-superficial autopkgtest a recommendation, then?
[15:50] <cpaelzer> slyon: yeah, that
[15:50] <seb128> +1, we can card that on our backlog, not going to happen for feature freeze though :)
[15:51] <cpaelzer> that is ok as a compromise - if it is before final freeze (vs the backlog being 234235346345 items long)
[15:51] <slyon> I updated the case on LP. status: Fix Committed
[15:51] <cpaelzer> thanks
[15:52] <slyon> #topic Incomplete bugs / questions
[15:52] <slyon> Mission: Identify required actions and spread the load among the teams
[15:52] <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
[15:52] <slyon> bug #2023971
[15:52] -ubottu:#ubuntu-meeting- Bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [High, Incomplete] https://launchpad.net/bugs/2023971
[15:53] <slyon> seems to be a tracking update (cc joalif)
[15:53] <slyon> bug #2051850
[15:53] -ubottu:#ubuntu-meeting- Bug 2051850 in trace-cmd (Ubuntu) "[MIR] trace-cmd" [Undecided, Incomplete] https://launchpad.net/bugs/2051850
[15:54] <slyon> here we're waiting on implementation of required TODOs by foundations
[15:54] <slyon> bug #2051916
[15:54] -ubottu:#ubuntu-meeting- Bug 2051916 in libtraceevent (Ubuntu) "[MIR] promote libtraceevent as a trace-cmd dependency" [Undecided, Incomplete] https://launchpad.net/bugs/2051916
[15:54] <eslerm> (I'm planning to do the trace-cmd audit early)
[15:54] <slyon> I've been working with upils actively to move this forward. There are still some issues with testing on s390x. To be resolved soon
[15:54] <slyon> thanks eslerm
[15:55] <slyon> bug #2051925
[15:55] -ubottu:#ubuntu-meeting- Bug 2051925 in libtracefs (Ubuntu) "[MIR] promote libtracefs as a trace-cmd dependency" [Undecided, Incomplete] https://launchpad.net/bugs/2051925
[15:55] <slyon> similar to the previous bug. We have a patch that needs review and sponsoring. not actionable for MIR team
[15:56] <slyon> bug #2048781
[15:56] -ubottu:#ubuntu-meeting- Bug 2048781 in authd (Ubuntu) "[MIR] authd" [Undecided, Incomplete] https://launchpad.net/bugs/2048781
[15:56] <cpaelzer> on this very topic of the production-tools related MIRs
[15:56] <cpaelzer> I have ruled out two cases with  a pre-review, they will never hit the MIR queue
[15:56] <slyon> yes, there's overall quite some frustration about the perf tools MIRs, as the packages are not in very good shape
[15:57] <cpaelzer> they are in much better shape than those I eliminated upfront
[15:57] <slyon> ok
[15:57] <cpaelzer> TL;DR: I've drawn a line for some to be ok to match what common documentation mentioned, but need to stay in universe
[15:57] <cpaelzer> so meta package cahnges to get them easy : yes - full main approval - no
[15:57] <cpaelzer> sorry to distract, keep goin
[15:57] <cpaelzer> g
[15:58] <slyon> joalif: should bug #2048781 be status: New to make it into the security-review list?
[15:58] -ubottu:#ubuntu-meeting- Bug 2048781 in authd (Ubuntu) "[MIR] authd" [Undecided, Incomplete] https://launchpad.net/bugs/2048781
[15:58] <joalif> slyon: sorry in 2 meetings checking
[15:58] <slyon> I see no required TODOs there
[15:59] <slyon> moving on in parallel, feel free to give your comment later on
[15:59] <slyon> #topic Process/Documentation improvements
[15:59] <slyon> Mission: Review pending process/documentation pull-requests or issues
[15:59] <joalif> slyon I think it's already in securitiy-review list
[15:59] <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
[15:59] <slyon> #link https://github.com/canonical/ubuntu-mir/issues
[15:59] <slyon> joalif: OK, setting to "Confirmed" then
[15:59] <slyon> Simple typo fix https://github.com/canonical/ubuntu-mir/pull/50
[15:59] -ubottu:#ubuntu-meeting- Pull 50 in canonical/ubuntu-mir "fix(typo) external endpoint exposed case" [Open]
[16:00] <cpaelzer> feel free to merge
[16:00] <eslerm> one issue to raise within the base-sets issue also
[16:00] <slyon> Will double-check and merege after the meeting.
[16:00] <eslerm> within the authd MIR, there are comments about windows crates being vendored
[16:00] <slyon> eslerm: your comment from December?
[16:00] <eslerm> this is related to https://github.com/canonical/ubuntu-mir/issues/35#issuecomment-1859325671
[16:00] -ubottu:#ubuntu-meeting- Issue 35 in canonical/ubuntu-mir "RFC: Introduce 'base-sets' for vendored dependencies" [Open]
[16:01] <eslerm> yes
[16:01] <eslerm> please see comment #11 from authd as well
[16:01] <eslerm> I'm not sure where to take this issue beyond here
[16:02] <slyon> I guess there are some hints in https://wiki.ubuntu.com/RustCodeInMain how to mangle the unneeded crates manually..
[16:03] <sarnold> that's for mangling, does it also work for deleting?
[16:04] <eslerm> in the best case, that is manual work for each package
[16:04] <eslerm> I'm not sure how well rerunning `crate vendor` works
[16:04] <slyon> Yes, I think it's manual work. The package should have some script to drop unneeded stuff and mangle the manifest accordingly
[16:05] <eslerm> and it would be ongoing manual work
[16:05] <slyon> I think longer term we'd need upstream toolchain support to vendor only the necessary deps
[16:06] <slyon> but that's not something that we have right now.
[16:06] <eslerm> I have links to upstream comments
[16:06] <didrocks> yeah, I think that should be done centrally, at worst, in the packaging tooling then
[16:06] <eslerm> in the MIR and issue thread
[16:06] <didrocks> otherwise, everyone will have different ways of doing it, hard to update and so on
[16:06] <eslerm> this is out of scope for cargo upstream, a thirdparty lint is likely needed
[16:07] <slyon> I can put it into the Foundations/Toolchain squad's backlog for review during next roadmap planning
[16:07] <sarnold> thanks
[16:07] <eslerm> thank you !
[16:07] <slyon> #topic MIR related Security Review Queue
[16:08] <slyon> Mission: Check on progress, do deadlines seem doable?
[16:08] <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[16:08] <didrocks> sounds perfect!
[16:08] <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
[16:08] <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
[16:08] <slyon> Internal link
[16:08] <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[16:08] <slyon> sarnold: eslerm: what are the security-review updates?
[16:08] <sarnold> progress is progressing :)
[16:09] <eslerm> we're fairly caught up. we're expecting MIRs for tracing and perl to land in our queue soon
[16:09] <slyon> sounds good. Let's move on as we're already overtime. All pending/ready MIRs seem to be in the queue
[16:10] <slyon> #topic Any other business?
[16:10] <eslerm> dbus-broker is very close
[16:10] <slyon> Is there still a change to do the dbus-broker switch in noble (cc seb128)?
[16:10] <slyon> chance*
[16:11] <slyon> I mean, it would be great the have the MIR and security review ready anyway
[16:11] <slyon> so we can to the change whenever needed
[16:11] <slyon> Do we have anything else?
[16:12] <eslerm> not from me
[16:12] <slyon> sorry for running late! o/
[16:12] <slyon> #endmeeting
[16:12] <meetingology> Meeting ended at 16:12:44 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-02-27-15.31.moin.txt
[16:12] <sarnold> nothing here
[16:12] <joalif> thanks slyon, all :)
[16:12] <sarnold> thanks slyon, all :)
[16:13] <eslerm> thanks everyone o/
[16:14] <slyon> cpaelzer: maybe you could look into demoting openjdk-21-doc?
[16:22] <seb128> slyon, sorry, I was off for one week and struggling to catchup/get things in Noble for feature freeze atm
[16:24] <seb128> slyon, I don't really understand what changed of dbus-broker, the dbus-run-session equivalent feature is being worked by someone upstream but doesn't seem at the point of being merged yet
[16:24] <seb128> of->for
[16:24] <seb128> which means we can't demote src:dbus
[16:24] <seb128> which is what is the basis on which the MIR team nacked the request previous cycles
[16:25] <slyon> seb128: sure, I can fully understand that. Considering that things are moving in the right direction (security review progressing, upstream work on the dbus-run-session equivalent), I was just wondering if there are any plans to make that switch for 24.04?
[16:26] <seb128> I would love to see that happen but it doesn't seem like things align enough for it?
[16:26] <slyon> seb128: I think most recent discussions (from last week? https://bugs.launchpad.net/ubuntu/+source/dbus-broker/+bug/2015538/comments/19) revealed that we'd be willing to have it split into individual binary packages. So that src:dbus and src:dbus-broker could be in main at the same time, but only with the relevant binary packages (dbus-broker daemon + dbus policy)
[16:26] -ubottu:#ubuntu-meeting- Launchpad bug 2015538 in dbus-broker (Ubuntu) "[MIR] dbus-broker" [Undecided, Incomplete]
[16:28] <seb128> slyon, we had that discussion at the time we had the first review round iirc, but someone pointed out (mdeslaur?) back then that dbus-run-session depends on the dbus service
[16:28] <seb128> I didn't have the free slots to read the code to see if that's true
[16:28] <seb128> but assuming that's a true fact it means we can't do the split/demote dbus service thing
[16:29] <seb128> if I understand correctly what you want to split (dbus-session-run in main, dbus in universe, right?)
[16:31] <slyon> I think the idea was to get the upstream dbus-broker dbus-run-session equivalent integrated, so that we could demote dbus and dbus-run-session to universe, while keeping the src:dbus policy bits, which are not shipped by dbus-broker on purpose.
[16:31] <slyon> But doing that split and integration work would need somebody with capacity to drive it
[16:33] <slyon> comment #17 also suggest that there is no such hard dependency, which would give even more options: "In Debian we just keep both, dbus-run-session from the src:dbus package works just fine, and it can be installed in parallel without any issues when somebody needs it. So it doesn't seem to me that you need that separate implementation?"
[16:33] <slyon> But it needs checking the details
[16:35] <seb128> slyon, ack, thanks for the details
[16:35] <seb128> it's on my backlog, I doubt I will get to it this week though but I'm still interested, maybe we manage to squeeze a ffe next week for it if things turn out to not be too complicated
[16:36] <seb128> the fact that the new binary is written in rust is annoying it means it's not a simple patch to drop it
[17:35] <cpaelzer> slyon: I could demote it, but this needs an extra exclude or it would come just back
[17:36] <cpaelzer> slyon: it only has https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/supported#n214
[18:05] <slyon> cpaelzer: good catch! I'll work on that
[20:00] <sil2100> o/
[20:00] <rbasak> o/
[20:00] <vorlon> time_t, everybody
[20:00] <vorlon> time_t?
[20:00] <vorlon> oh sorry, where am I again
[20:00] <sil2100> Ahahah
[20:00] <sil2100> Okay, I see I'm the chair
[20:01] <sil2100> Let me start this one then, give me 1 minute
[20:01] <sil2100> #startmeeting Ubuntu Technical Board
[20:01] <meetingology> Meeting started at 20:01:39 UTC.  The chair is sil2100.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[20:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[20:01] <sil2100> #topic Apologies
[20:02] <sil2100> amurray sent his apologies for having to miss the meeting
[20:02] <sil2100> #topic Action review
[20:02] <sil2100> ACTION: seb128/amurray/sil2100 to help drafting the snap-store Ubuntu-specific tracks usage
[20:02] <sil2100> There's no update from me here, not sure about seb128 or amurray, so let's just carry over for now
[20:03] <rbasak> I've been ill so haven't made any progress list last time, sorry.
[20:03] <rbasak> I was going to try and set up a higher bandwidth meeting to try to catch up on the third party repo req. stuff
[20:03] <sil2100> Let me carry over those then, no worries!
[20:03] <sil2100> #action seb128/amurray/sil2100 to help drafting the snap-store Ubuntu-specific tracks usage
[20:03] <meetingology> ACTION: seb128/amurray/sil2100 to help drafting the snap-store Ubuntu-specific tracks usage
[20:03] <sil2100> #action seb128 to organize a meeting to unblock the draft of the tracks usage section
[20:03] <meetingology> ACTION: seb128 to organize a meeting to unblock the draft of the tracks usage section
[20:03] <sil2100> #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[20:03] <meetingology> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[20:04] <sil2100> #action rbasak to follow up on finding consensus on question of test plans for third party apps
[20:04] <meetingology> ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps
[20:04] <sil2100> #action rbasak to open wider discussion on third-party repo policy
[20:04] <meetingology> ACTION: rbasak to open wider discussion on third-party repo policy
[20:04] <sil2100> #action seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
[20:04] <meetingology> ACTION: seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations
[20:04] <sil2100> So, regarding this one:
[20:04] <sil2100> ACTION: seb128 to follow-up with ubuntu cinnamon on 24.04 request
[20:04] <sil2100> Does anyone remember if that happened?
[20:04]  * sil2100 looks at the ML
[20:05] <sil2100> I guess not
[20:05] <seb128> hey, sorry for being late, evening rush time here
[20:05] <tsimonq2> Eickmeyer and I have been interfacing with ItzSwirlz on this front.
[20:05] <sil2100> seb128: o/
[20:05] <seb128> sil2100, no, none of my action moved, sorry
[20:05] <seb128> I was on holidays one week and now it's feature freeze coming
[20:05] <seb128> I will try to catch up next week and get things moving by the next meeting
[20:05] <sil2100> seb128: do you need help with that one? I could also take a look at it, since I know many teams might be at capacity due to FF
[20:06] <sil2100> Either way, for now carrying over!
[20:07] <sil2100> #action seb128 to follow-up with ubuntu cinnamon on 24.04 request
[20:07] <meetingology> ACTION: seb128 to follow-up with ubuntu cinnamon on 24.04 request
[20:07] <sil2100> ACTION: vorlon to look into scripting for packages in flavor-specific overlays
[20:07] <sil2100> vorlon: ^ ?
[20:07] <vorlon> sorry, not yet done
[20:07] <sil2100> I guess time_t..?
[20:07] <vorlon> yeah ;)
[20:07] <sil2100> time_t ;)
[20:07] <seb128> sil2100, no it's fine but thanks, I will catch up next week :)
[20:07] <sil2100> #action vorlon to look into scripting for packages in flavor-specific overlays
[20:07] <meetingology> ACTION: vorlon to look into scripting for packages in flavor-specific overlays
[20:07] <sil2100> seb128: excellent!
[20:07] <sil2100> ACTION: vorlon to follow up on xnox's request to set noble.publish_i18n_index to False
[20:08] <vorlon> done
[20:08] <sil2100> vorlon: didn't follow that one too closly - I guess it happened?
[20:08] <sil2100> \o/
[20:08] <sil2100> Okay, that's all action items from our list for now
[20:08] <sil2100> #topic Scan the mailing list archive for anything we missed (standing item)
[20:09] <sil2100> I don't see anything really
[20:09] <sil2100> Can someone else confirm that I didn't miss anything?
[20:09] <sgmoore> Is this the right place to ask about Kubuntu LTS requalification?
[20:10] <sil2100> sgmoore: sure! Let me just move to AOB
[20:10] <sil2100> #topic Check up on community bugs and techboard bugs
[20:10] <sil2100> ...none!
[20:10] <sil2100> #topic AOB
[20:10] <sil2100> sgmoore: the floor is yours o/
[20:10] <vorlon> I'm not sure whether kubuntu LTS qualification is blocked on me providing scripts for a saner view of the "what packages is kubuntu committing to support" question
[20:11] <tsimonq2> I think given the scale of the Kubuntu packageset, if the TB is wanting to block on a more concise packageset list, then yes. :)
[20:11] <rbasak> ML thread "Upload of translation files" -> I just replied to redirect them to ubuntu-translators@. Hopefully that's helpful, though with Gunnar gone I'm not sure who's left :-(
[20:11] <vorlon> the thread had gone in that direction but maybe we just need to have that information available and don't need to consider it a blocker?
[20:11] <sgmoore> I know we need a proper packageset, but other than that, how are we looking :) I am working hard on getting a spectacular release ready :)
[20:11] <vorlon> rbasak: :/
[20:13] <seb128> rbasak, I think I'm the only standing member left to deal with some of those translations things :/
[20:14] <seb128> I need to sort that out somehow and find other people to involve
[20:14] <seb128> if anyone is reading and want to help with translations please msg me
[20:15] <vorlon> sgmoore: so I guess amurray who isn't here today was on point for driving the Kubuntu discussion.  I'll work on getting my action item sorted one way or the other so we can have a sane conversation about a packageset. From my perspective personally, that shouldn't be a blocker for LTS qualification but amurray will need to call the vote
[20:15] <sil2100> The only thing I can commit to, sadly, is operating the machinery
[20:15] <rbasak> seb128: IMHO, you should "close" those MLs and venues and bring everything into one place - ubuntu-devel@, or Discourse. It's not like we're going to be swarmed by traffic. Otherwise everyone assumes that there's a team somewhere that's running just fine.
[20:15] <sgmoore> vorlon: Fair enough :)
[20:16] <seb128> rbasak, the issue is that those lists are contact point for role-accounts on launchpad
[20:17] <sil2100> sgmoore: out of curiosity, maybe composing a list of packages that you and your team worked on in the last 6 months when working on Kubuntu would be a start
[20:17] <sgmoore> I only just started back with Kubuntu a few weeks ago.
[20:17] <seb128> rbasak, I could set e.g devel but that doesn't resolve the issue than in practice the only admin in the team able to do the action is me
[20:18] <seb128> (or maybe launchpad admins or some other admin groups, I don't remember the details and didn't go check)
[20:18] <tsimonq2> sgmoore: I'll happily walk through UDD with you if you find it helpful :)
[20:18] <sgmoore> I find any new knowledge helpful lol
[20:19] <tsimonq2> Okay, will follow up with you after the meeting
[20:19] <sgmoore> sounds good thanks!
[20:20] <sil2100> Okay, any other business?
[20:21] <sil2100> Out of curiosity, with part of my release team hat on...
[20:22] <seb128> nothing from me
[20:22] <sil2100> Does anyone have contact with the Ubuntu Mate developers?
[20:22] <seb128> sort of
[20:23] <vorlon> it doesn't appear they've applied yet for 24.04 LTS qual
[20:23] <sil2100> Just asking since I noticed they were a bit absent from .4
[20:23] <sil2100> Anyway, guess that's not a TB-topic per-se
[20:24] <sil2100> #topic Select a chair for the next meeting
[20:24] <seb128> I will give a ping to Martin just to ask
[20:25] <sil2100> ...okay, how is this chair selection working
[20:25] <sil2100> Since none of the sorting of TB members results in the current order for me
[20:25] <vorlon> https://launchpad.net/~techboard/+members lists you last and Alex next after wrapping around
[20:26] <seb128> sil2100, you got rescheduled for missing your previous chair so that confused the logical order
[20:26] <sil2100> Yes, so how come rbasak was the backup today
[20:26] <sil2100> Aaah
[20:26] <seb128> :)
[20:26] <sil2100> Okay, so next chair will be amurray, backup rbasak
[20:27] <sil2100> Thank you everyone!
[20:27] <sil2100> #endmeeting
[20:27] <meetingology> Meeting ended at 20:27:16 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-02-27-20.01.moin.txt
[20:27] <vorlon> thanks!
[20:28] <seb128> thanks sil2100 for the chairing and doing in an efficient way, always good to not spend longer that needed in meetings during the rush times :)
[21:29] <sil2100> yw!
[23:11] <amurray> sgmoore: re Kubuntu LTS - I agree with vorlon, resolving the packageset is not a blocker for LTS qualification, so will call for a vote via the mailing list today - let me know though how you go with manually defining the packageset as suggested by sil2100 / tsimonq2