[15:31] <cpaelzer> o/
[15:31] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[15:31] <meetingology> Meeting started at 15:31:09 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:31] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:31] <cpaelzer> ping slyon, didrocks, sarnold, joalif, jamespage for MIR meeting
[15:31] <sarnold> good morning
[15:31] <joalif> o/
[15:31] <slyon> o/
[15:31] <cpaelzer> as I promised last time I'll be distracted by othe rmeetings, so i beg your pardon for my latency
[15:32] <cpaelzer> #topic Review of previous action items
[15:32] <cpaelzer> none
[15:32] <cpaelzer> #topic current component mismatches
[15:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:32] <cpaelzer> let us check what new entries we have that need to be adressed
[15:32] <cpaelzer> new info on llvm-toolchain-13 foundations confirmed to take it
[15:33] <cpaelzer> doko was tasked to resolve
[15:33] <slyon> cups-filters seems new?
[15:33] <cpaelzer> so that will be gone in a bit since it is just needing an AA being a new version
[15:33] <cpaelzer> I agree slyon
[15:33] <cpaelzer> I was not seeing cups-filters -> lync before
[15:33] <cpaelzer> cups ~-> Desktop
[15:33] <cpaelzer> didrocks: are you around?
[15:34] <cpaelzer> while we wait for that another FYI
[15:34] <sarnold> sigh "Firefox has just been updated in the background. Click Restart Firefox to complete the update"
[15:34] <cpaelzer> the suitesparse case was solved, that will be gone with the next run
[15:35] <cpaelzer> without an MIR actually by auto-excluding -doc and -dev 8suitesparse)
[15:35] <cpaelzer> ok, it really leaves cups-filters -> lynx as the one to act on
[15:35] <slyon> side question about that: how often are those SVGs generated? Would it be possible to add a timestamp to it? (maybe we can discuss this in the AOB section)
[15:35] <cpaelzer> I'll ping Desktop in their channel
[15:36] <cpaelzer> slyon: you can watch them as html with .html suffix
[15:36] <cpaelzer> slyon: https://people.canonical.com/~ubuntu-archive/component-mismatches.html
[15:36] <cpaelzer> there they have a timestamp
[15:36] <cpaelzer> updated as often as update-excuses
[15:36] <slyon> ok, nice
[15:36] <sarnold> how nice that it's generated 1.5 minutes before the meeting :)
[15:37] <cpaelzer> message sent to desktop
[15:37] <cpaelzer> #topic New MIRs
[15: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
[15:37] <cpaelzer> protobuf here does NOT need a review yet, it needs an owning team first
[15:38] <cpaelzer> foundations was suggested, slyon would you carry that to the team to say yes/no ?
[15:38] <cpaelzer> from there it can go into review
[15:38] <slyon> will do
[15:38] <cpaelzer> thanks
[15:38] <cpaelzer> #topic Incomplete bugs / questions
[15:38] <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
[15:39] <cpaelzer> libio-prompt-tiny-perl has a todo for foundations, once solved either the MIR isn't needed or it is approved
[15:39] <cpaelzer> no action needed
[15:39] <cpaelzer> rustc opened, but yet incomplete
[15:39] <cpaelzer> I wonder if we need to carry our needs from our "preliminary rust MIR rules" work into that MIR bug
[15:40] <cpaelzer> maybe when we do the review to not mess with whatever this was hled back as incomplete for now
[15:40] <cpaelzer> #topic Any other business?
[15:40] <cpaelzer> the mismatch timestamp was solved
[15:40] <slyon> ack
[15:41] <cpaelzer> I wanted to ask how the joint review of joalif + slyon worked out?
[15:41] <cpaelzer> anything out of that we want to change in our templates?
[15:41] <slyon> joalif did the initial work
[15:41] <slyon> I still need to find some time for a review and filling of gaps
[15:41] <joalif> I did some stuff, the only thing that caught my eye
[15:41] <cpaelzer> ok, both please do eventually speak up if you think there are docs or processes to change
[15:41] <joalif> is that this package runs a daemon as root
[15:42] <slyon> joalif: was there anthing confusing with the process/wiki page that you'd like to improve?
[15:42] <cpaelzer> joalif: which is ok as a finding, we have recently changed the reporter templates to explain why such (daemon as root) should be ok. Did the reporter explain something in that regard?
[15:43] <joalif> the one thing that confused me a bit was what to do with seeded-in-ubuntu
[15:44] <cpaelzer> you are right joalif
[15:44] <cpaelzer> with our new style where we split RULES and TODO this part clearly would be a  RULE
[15:44] <cpaelzer> as it is not meant to stay around in the final post
[15:44] <cpaelzer> And more like a hint how you could check
[15:46] <joalif> yes I understand, my problem is not knowing how I'm supposed to use the tool :p
[15:47] <joalif> other than that the review process seems straight forward
[15:48] <cpaelzer> https://github.com/cpaelzer/ubuntu-mir/pull/6
[15:48] <cpaelzer> Created for what we can improve here
[15:48] <cpaelzer> the rest to understand "how to do it" really is either mana-page study or co-reviewing with one of us
[15:48] <cpaelzer> everyone please have a look at the PR, if accepted until next week we can merge that as improvement
[15:48] <didrocks> cpaelzer: back, sorry, I thought we told we would skip this week, scrollbacking
[15:49] <cpaelzer> we are about to close didrocks, no problem
[15:49] <cpaelzer> unless cups->lynx is a problem to you
[15:50] <sarnold> how is lynx in the daily-live and daily-preinstalled seeds if it is in universe now?
[15:50] <didrocks> cpaelzer: no, I’ll follow up with Till
[15:50] <cpaelzer> thanks
[15:51] <cpaelzer> sarnold: magic
[15:51] <sarnold> :)
[15:51] <didrocks> not really liking this kind of magic :p
[15:51] <cpaelzer> sarnold: chances are that is another binary of src:lynx showing up here
[15:51] <cpaelzer> but yeah it is in universe
[15:51] <cpaelzer> afaics
[15:52] <cpaelzer> a kind of magic worth a quick look by didrocks when sorting out the above maybe
[15:52] <cpaelzer> never the less I'd be closing out for today
[15:52] <didrocks> yeah, it can bit us another time without noticing, hence not linking not understanding what’s going on, but that’s a topic for later :)
[15:56] <cpaelzer> ok, thank you all then
[15:56] <cpaelzer> see you next week
[15:56] <slyon> see you, thanks!
[15:56] <cpaelzer> #endmeeting
[15:56] <meetingology> Meeting ended at 15:56:26 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-01-18-15.31.moin.txt
[15:56] <sarnold> thanks cpaelzer, all :)
[15:56] <joalif> o/
[15:56] <didrocks> thanks!
[15:57] <sarnold> lynx spent some time in main in the old days .. https://launchpad.net/ubuntu/+source/lynx/+publishinghistory?batch=75&memo=75&start=75 .. I wonder if it's been in the seeds ever since? heh
[15:58] <didrocks> waow, until Jaunty, not that long ago
[15:59] <didrocks> … well, a little bit :)
[15:59] <didrocks> I wonder about the come back in main in Xenial…
[20:00] <rbasak> o/
[20:00] <sil2100> o/
[20:00] <rbasak> vorlon, mdeslaur: o/
[20:00] <mdeslaur> hi rbasak sil2100 vorlon
[20:00] <rbasak> cyphermox doesn't seem to be online
[20:01] <rbasak> But three is enough I think?
[20:01] <rbasak> And I guess I'm chairing then
[20:01] <rbasak> #startmeeting Technical Board
[20:01] <meetingology> Meeting started at 20:01:28 UTC.  The chair is rbasak.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[20:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[20:01] <rbasak> #topic Action Review
[20:01] <sil2100> I think so, thanks!
[20:01] <rbasak> ACTION: formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06)
[20:01] <rbasak> ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. (rbasak, 19:06)
[20:01] <rbasak> ACTION: vorlon to reply to seeded snap upload permissions question on list (rbasak, 19:06)
[20:01] <rbasak> ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which xnox and TB will review, edit, and ratify before we move on to figuring out the next step (rbasak, 19:08)
[20:02] <rbasak> ACTION: all members to continue discussion at https://pad.ubuntu.com/third-party-repository-requirements (rbasak, 19:11)
[20:02] <sil2100> o/
[20:02] <sil2100> I started the draft a while ago and did some modifications recently
[20:02] <sil2100> (for the OEM archive)
[20:02] <sil2100> There are things however that I didn't yet manage to get enough knowledge to fill in the gaps, so maybe one of you could help - if you know
[20:02] <sil2100> If not, I'll reach out to people working on it
[20:03] <sil2100> Because I was wondering: who has upload rights to the OEM archive?
[20:03] <sil2100> Since the Canonical OEM metapackage PPA is governed by the team for the PPU
[20:03] <sil2100> But I was actually wondering if it's the same team that gives power over the OEM archive itself?
[20:04] <sil2100> The still in-progress draft of the OEM scenario is done here: https://wiki.ubuntu.com/OEMArchive
[20:04] <rbasak> ALso https://lists.ubuntu.com/archives/technical-board/2020-January/002478.html for some discussion I think
[20:05] <sil2100> This was all before my time so I only wrote of the things that I knew about, might need to poke around to get all the other missing bits
[20:05] <sil2100> Yeah, this I remember
[20:06] <sil2100> But it doesn't directly say who besides the 'Canonical Teams' that got given access to the OEM private PPA are
[20:07] <sil2100> If no one remembers, I'll follow up on that since I think we need to have this clarified in the documentation, so that we know exactly how the ACLs for this is managed. Since if the OEM archive is enabled for our main Ubuntu certified machines, I'd like to know that who can upload packages for them
[20:07] <rbasak> Was there any explicit approval for the TB for Ubuntu to enable the OEM archive through the Ubuntu archive?
[20:07] <rbasak> *by* the TB I mean
[20:07] <mdeslaur> Sorry, I don't remember the OEM discussions
[20:08] <mdeslaur> pretty sure they were enabled before it was brought up to the tech board
[20:08] <sil2100> I was not part of the TB so I don't really know, the e-mail seems to say it was. Maybe this is worth revisiting? Should I investigate and we check back next meeting?
[20:08] <rbasak> I think you're raising good questions. So yes, that sounds good.
[20:08] <sil2100> Since I think it would be clear by checking the IRC logs and maybe poking Dimitri and Iain for some context
[20:09] <sil2100> Could you add an additional action item just so that I don't forget? Would be helpful!
[20:09] <mdeslaur> yeah, I think we need to make sure we're ok with how that works, and how people get upload rights to it
[20:09] <rbasak> https://lists.ubuntu.com/archives/technical-board/2019-August/002456.html might be relevant
[20:10] <rbasak> There's followup in October and January.
[20:10] <rbasak> AFAICT, it was already being done on "preinstalled Ubuntu" without any explicit involvement of the TB.
[20:10] <sil2100> True
[20:10] <rbasak> So I suspect it's "Canonical" that can upload to the OEM archive with no further governance rules.
[20:11] <rbasak> https://lists.ubuntu.com/archives/technical-board/2020-January/002478.html has a summary
[20:12] <sil2100> Still, since we were involved in getting it done 'properly', I think we should at least have clear information about ownership here, and maybe also get to know a bit better about what policies such OEM archive uploads follow
[20:12] <mdeslaur> +1
[20:13] <rbasak> Yes please. And thank you for getting into this.
[20:14] <sil2100> Will try to gather as much info for the next meeting then o/
[20:14] <rbasak> On the third party repository requirements thing, I think it's time I converted the pad into a written draft, now that we've got input from everyone.
[20:15] <rbasak> I'll do that next, and present that for further discussion.
[20:15] <rbasak> So everything needs carrying over then, I guess?
[20:15] <rbasak> #topic Scan the mailing list archive for anything we missed (standing item)
[20:16] <rbasak> There's "Setting NotAutomatic for hirsute+1-proposed" - do we have a decision on this?
[20:17] <sil2100> Let me take a look at that one again
[20:18] <sil2100> hm, ok, so I sadly missed some TB meetings, but was this brought up here or only on the ML?
[20:18] <rbasak> Only on the ML so far
[20:19] <mdeslaur> was anyone opposed to that? do we need to make a decision on it?
[20:19] <rbasak> But we're on the IRC agenda topic that makes us look for open things on the ML :)
[20:19] <rbasak> I think we need to decide if/when to switch it on, and on which series
[20:21] <rbasak> Eg. retrospectively for all releases now, or only for Jammy onwards now, or after Knotty opens and then retrospectively for previous releases after it's proven there, etc.
[20:21] <sil2100> I have no strong opinions regarding this, since I personally didn't have and didn't see anyone I know have problems with -proposed enabled
[20:21] <rbasak> It'll immediately break pbuilder/sbuild users I think to make the change right now. They'll end up not picking up packages from -proposed I think.
[20:21] <sil2100> So I don't really know how much of an impact this has on users right now
[20:21] <mdeslaur> besides vorlon mentioning he'd like it enabled in stable releases, was that really being considered?
[20:22] <rbasak> I don't think anything was considered except that it's now possible because Launchpad supports it. The details have been left to us.
[20:23] <sil2100> I know this sounds a bit lazy, but maybe we could bring this up again on the next meeting when vorlon is around? As he certainly has an opinion here
[20:23] <rbasak> Sure, we can defer it
[20:23] <mdeslaur> yeah, I don't mind turning it on on the dev release
[20:23] <rbasak> Also it's only next week with the phase change
[20:24] <mdeslaur> but I'd rather discuss it with vorlon around if it affects stable releases
[20:24] <rbasak> I don't see any other open ML posts, so I think that's it for this topic.
[20:24] <rbasak> #topic Check up on community bugs (standing item)
[20:24] <rbasak> There are none.
[20:25] <rbasak> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
[20:25] <rbasak> Next chair will still be cyphermox, with I guess vorlon as backup.
[20:25] <sil2100> +1 o/
[20:25] <rbasak> #topic AOB
[20:25] <mdeslaur> sounds good
[20:26] <rbasak> Anything else to raise?
[20:26] <rbasak> #endmeeting
[20:26] <meetingology> Meeting ended at 20:26:22 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-01-18-20.01.moin.txt
[20:26] <rbasak> Thanks all!
[20:26] <mdeslaur> thanks rbasak, sil2100
[20:26] <sil2100> Thank you guys!
[21:09] <xnox> rbasak:  sil2100: i don't think TB has ratify OEM archive implementation; beyond me sending two update emails; and like having a couple of IRC chats with TB; and DBM sorting out delegation / package set for the oem-metas uploads.
[21:09] <xnox> *has ratified
[21:14] <rbasak> xnox: thanks (and for your previous email summaries of the status!)
[22:18] <laney> Please make sure to involve the wider dev community in the discussion, if the TB is taking responsibility for the NotAutomatic change (to be honest, I think it could be an archive/SRU team decision but...)