[14:00] hey [14:29] cpaelzer: SRU/MRU meeting? [14:29] yep [14:29] hi bittin [14:29] hey cpaelzer [14:29] #startmeeting Weekly Main Inclusion Requests status [14:29] Meeting started at 14:29:46 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:29] Available commands: action, commands, idea, info, link, nick [14:30] ping sarnold jamespage ddstreet doko didrocks999 - MIR team meeting [14:30] o/ [14:30] hey === didrocks999 is now known as didrocks [14:31] good morning [14:31] hello everyone, no previous action items so let us start with [14:31] #topic current component mismatches [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] a lot of usual suspects (false positives and dormant seeds) [14:31] what seems new to me is gnome-shell -> gtk4 -> fonts-cantarell [14:32] didrocks: that sounds liek you might know something about it [14:32] hi doko [14:32] just started component mismatches, gnome-shell ->... fonts-cantarell is the only new one [14:33] o/ [14:33] didrocks: ? ^^ [14:33] cpaelzer: I’ve already dealt with gtk4, doing the review, fonts-cantarell is only if we promote the -examples, which we won’t [14:33] woot [14:33] so you'll adda an extra exclude or something and this ill vanish? [14:33] will [14:34] cpaelzer: I think it’s because the source is not promoted yet, but I’ll do it and look back [14:34] well, ok [14:34] thanks didrocks [14:34] the important bit here is that it is under control and needs no action :-) [14:34] #topic New MIRs [14:34] yep:) [14:34] #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:34] empty \o/ [14:35] #topic Incomplete bugs / questions [14:35] hourra! [14:35] #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:35] fuse we mentioned last week - that now is a MIR project of foundations btw [14:35] bugs against many packages that still have fuse2 are filed [14:35] once all are ready we will transition, but that might take a while [14:36] afaik ginggs seems to lead that effort [14:36] nothing totally new in incomplete that we would not be aware of [14:36] jamespage: I still consider the cherryp3 incomplete case on you btw [14:36] #topic Any other business? [14:36] yeah.. [14:37] I wanted to ask everyone for their respective teams - are there more things coming for 21.10 MIRs? [14:37] we know we ahve a few blocked on the evey too busy security team [14:37] but further ones that will come into the MIR queue - are there more expected/planned ? [14:37] there's a v4l2loopback package that a commercial support group in canonical is looking to support in focal, hirsute, impish, and forward [14:37] there is adsys coming (hopefully next week) [14:38] ours (server) are already open MIRs (on security atm) [14:38] the security team is having a sprint next week i did hear in the latest https://ubuntusecuritypodcast.org/ [14:38] which will probably need a security review (and it’s a go package, with vendored deps) [14:38] bittin: probably a company-wide roadmap review sprint [14:38] sarnold: might be [14:38] well, yes, my impression was that ginggs wanted some input from the package owners ... [14:39] the nice folks working on v4l2loopback haven't done the 'usual mir' process; they've so far been doing everything via email [14:39] doko: on the few that I saw I was dealing with the cases [14:39] ok, is desktop doing the same? [14:39] doko: but surely there are more that I've not seen [14:39] sarnold: what does that mean - did they send a mail directly to -security ? [14:39] has anyone else been doing similar work on the v4l2loopback package 'out of usual channels'? [14:39] cpaelzer: yes [14:40] e.g. https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1935668 [14:40] Launchpad bug 1935668 in xdg-desktop-portal (Ubuntu) "Please switch to fuse3" [Undecided, New] [14:40] no I didn't see/get and v4l2loopback info [14:40] thanks for the info on adsys didrocks [14:40] didrocks: that xdg / fuse question is for you I guess [14:41] cpaelzer: I know we've got a flood of packages with names I can't remember all doing some supported things without much input / involvement from us, and I was curious where / how those sorts of exceptions from usual process are documented, and if I need to be asking this team to move to a public MIR bug [14:41] yeah, but I don’t know as I’m not doing GNOME work for some years now, I can be the man in the middle ofc and ask [14:41] sarnold: I'd answer to those mails pushing them to the official process - or do they have a good reason to go "secretly" [14:41] thanks didrocks [14:41] cpaelzer: good question [14:42] sarnold: if the intended use case is NOT promotion in the acrhive they might "only ask you" [14:42] but right now, just reading the message looks like we should hold it: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1935668/comments/2 [14:42] Launchpad bug 1935668 in xdg-desktop-portal (Ubuntu) "Please switch to fuse3" [Undecided, New] [14:42] and skip the normal MIR process [14:42] unsure if this is what doko is referring to as giving the bug # here [14:42] didrocks: yeah it is about assessing the situation to be "ready to move" [14:42] didrocks: not about uploading a change now [14:43] ack [14:43] right, we don't want to have two versions of fuse in main, therefore coordinating the switch ... [14:43] cpaelzer: okay, cool, I can work with this; I'll re-read the emails and see if it's actual promotion in the archive or if it's something else that they're after, and ask them to use the public process if it's archive promotion. thanks :) [14:43] great sarnold [14:44] I guess "that is it" for today then [14:44] thanks for the sync @everony [14:45] see you all next week [14:45] cyas [14:45] #endmeeting [14:45] Meeting ended at 14:45:14 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-07-13-14.29.moin.txt [14:45] woo, thanks cpaelzer, all :) [14:45] thanks cpaelzer, everyone :) === genii-core is now known as genii [18:59] \o [18:59] o/ [19:00] o/ [19:01] I think there's enough of us, right? [19:02] Let's maybe start this meeting o/ [19:02] yep! [19:02] #startmeeting Ubuntu Technical Board [19:02] Meeting started at 19:02:22 UTC. The chair is sil2100. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:02] Available commands: action, commands, idea, info, link, nick [19:02] #topic Apologies [19:02] No apologies for today, but I would like to apologize for missing last meeting - that was quite unexpected from my side [19:02] #topic Action review [19:03] ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. [19:03] I was on vacation last time and forgot about the meeting :P [19:03] I think there was some movement on that during the last meeting, right rbasak? [19:03] I need to follow up with Martin again there I think. [19:03] There was movement, yes, but not since then. [19:04] Ok, so should we leave it as-is until we know more? [19:04] Yes - carry the action for me, please. [19:04] #action Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. [19:04] ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. [19:05] The two next action items are on vorlon who doesn't seem to be around, so I'll carry them over [19:05] #action formal ratification of third party seeded snap security policy, depends on: [19:05] ACTION: formal ratification of third party seeded snap security policy, depends on: [19:05] #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. [19:05] 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. [19:05] Next one is from vorlon as well - did anyone hear any update on that? [19:05] i.e. vorlon to reply to seeded snap upload permissions question on list [19:06] If not, we'll carry it over [19:06] ...let's carry over! [19:06] #action vorlon to reply to seeded snap upload permissions question on list [19:06] ACTION: vorlon to reply to seeded snap upload permissions question on list [19:07] And final one is on me, and sadly this is not done yet - but I have just started drafting a draft some time before the meeting [19:07] So hopefully, pinky promise, there'll be something to review for the next meeting [19:07] #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 [19:07] 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 [19:07] #topic Scan the mailing list archive for anything we missed (standing item) [19:08] There are two ML items from June from what I see [19:08] There's two Flatpak related requests [19:08] Not sure if those got handled [19:08] Yeah, let's start with this one: https://lists.ubuntu.com/archives/technical-board/2021-June/002560.html [19:09] I'm tempted to delegate this decision to the security team [19:10] Any reason we shouldn't? [19:10] sarnold: FYI ^ [19:10] Sounds fair, I personally don't feel strongly about changing the current status-quo, especially that it's an universe package [19:11] But if the security team feels that Ubuntu would benefit more if we'd change, I guess it's something up for discussion [19:11] I think delegating to the security team is fine, unless there is controversy about the decision, in that case, the security team can bring it back to the tech board [19:12] sil2100: it's being promoted to main [19:12] thanks rbasak, reading.. [19:12] Ah, now I see mention of an MIR [19:13] hm, I must say that for packages we consider 'main' I like the idea of consistency, but I think it's fair to leave the decision to the security team [19:13] Let's ask the security team to provide an opinion in the first instance, at least. [19:13] I think it should be consistent too [19:14] Who wants to follow up on that e-mail? To get the security teams professional opinion? [19:15] I'd prefer someone else do the follow up [19:15] ;) [19:15] Sure [19:15] to ubuntu-hardened@l.u.c? [19:16] Oh, I didn't even know about such list? [19:16] * mdeslaur didn't either [19:17] rbasak: do you volunteer, or should I take it? [19:17] the one guy who used to use that list stopped writing us questions :( [19:17] I'm volunteering :) [19:17] \o/ [19:17] rbasak: cc the list, and cc security@u.c please [19:17] #action rbasak to follow up regarding security-team's advice on the flatpak TB request [19:17] ACTION: rbasak to follow up regarding security-team's advice on the flatpak TB request [19:18] mdeslaur: by "the list", you mean ubuntu-hardened@? [19:18] yeah [19:18] OK :) [19:18] thanks :) [19:19] What about the other TB ML message from June? Re: https://lists.ubuntu.com/archives/technical-board/2021-June/002559.html [19:20] I didn't read the thread, does it have anything actionable? [19:20] So Erich uploaded displaycal to Impish Unapproved, and it's been sitting there since. [19:20] I don't know what the AAs are expecting - maybe the resolution of this thread? [19:21] (FWIW, IMHO they're right to wait until the thread is resolved) [19:21] I think this is a case where we just need to make a decision. [19:21] Either us, or the AAs, or the release team. The appropriate team is unclear to me. [19:21] So therefore maybe this is a case where the TB should just decide. [19:22] IMHO, the biggest issue is the UX where users usually expect stuff installed by default to remain stable for the lifetime of the release. [19:22] I don't think I have enough context right now, would have to read the whole thread first [19:22] And that expectation would be broken here I think. [19:23] chromium is an exception in this matter, but I don't think DisplayCAL qualifies. [19:23] Ah, so this is the case of a new dummy package but with flatpak as the real source, right? [19:23] Right [19:23] yeah, plus it adds a new flatpak repo [19:23] Eickmeyer: o/ ^ [19:24] which is the thing that I personally don't like and is akin to adding PPAs [19:24] There are lots of open questions here, such as a flavour adding a third party software source by default, etc. [19:24] Yeah, tricky [19:24] doing that is the very reason we want mate to change how their store works [19:25] Eickmeyer points out that installing snaps by default, and the chromium deb that installs a snap, is also equivalent to "adding a third party software source". [19:25] However I don't think they're really the same, as I explained in the thread. Lots of differences that impact UX. [19:25] we ship with the snap repo preconfigured [19:25] the other one is adding a new one, contrary to user expectations [19:26] I mean, the difference is also that we make sure that the snaps that we do preinstall follow a certain level of 'stability', as rbasak already mentioned [19:26] Which I don't think we have the guarantee of with the case of the added flathub.org flatpak repository? [19:27] mdeslaur: I don't see the distinction you're describing. AIUI, Eickmeyer wants to ship with a Flatpak repo enabled by default, and a Flatpak installed, just as Ubuntu ships with the Snap Store enabled by default, and some snaps installed. [19:27] I do agree with what sil2100 just said though. [19:27] rbasak: he wants the deb package to enable a new flatpak repo [19:27] or am I misunderstanding [19:27] I mean, I would be fine if we just had the guarantee of stability with the new software they install - in one way or another [19:28] mdeslaur: that's just the mechanism. The snapd deb package enables the Snap Store :) [19:28] There's also questions over things like where the package is built, and the ability for Ubuntu developers to be able to override/patch what ships if required. [19:29] eg. if there's a security vulnerability and the upstream Flatpak repo maintainer is absent, then what happens? [19:29] Is the producer of the flatpak going to support it on ubuntu for the lifetime of the release? [19:29] In the Snap case, I believe there are arrangements to do with tracks and channels to support that situation. [19:29] mdeslaur: that's another difference. That isn't currently part of the proposal. [19:29] Yeah, so in my opinion it's not a matter of technology here, but a matter of arrangements with the people responsible [19:30] rbasak: (re: mechanism): one is installing the snapd software itself, the other is installing an random piece of software (displaycal) and getting a repo added [19:31] So it's not a problem that it's flatpak and from flathub.org, but more like a problem that we don't have arrangements with the people responsible, making sure that the flatpak remains stable and up-to-date with fixes [19:31] Since sure, we don't always have up-to-date universe packages, but Ubuntu developers have the powers to update them if needed [19:31] But here we need to have something arranged so that this still happens [19:31] Right - but also, that the package installed isn't a rolling release. [19:31] That's not what users expect from the average app that ships with Ubuntu by default. [19:32] and will that rolling release still support a 5 year old version of ubuntu in 5 years... [19:32] I think we basically have a fairly extensive list of "properties" of the system here, that we think users expect, but just adding this Flatpak will not deliver. [19:32] So personally I wouldn't straight away say 'no' to this proposal, but maybe before saying 'yes' try to get the discussion started on how to handle the maintenance situation from the Ubuntu perspective [19:33] Agreed [19:33] I think we need to enumerate the list. [19:33] If Eickmeyer finds a good way to solve this, we can say 'yes' no problem - I personally, right now, have no such good idea, but maybe Eickmeyer has a better concept! [19:33] And then see what Eickmeyer can come up with to meet those requirements (or negotiate them). [19:34] Ok, do you want to follow up, or maybe you want someone other from the TB to follow up instead? [19:34] (since I completely missed this thread) [19:35] I'm happy to do it, if others feel I'm the best person to tackle a reply! [19:35] can we work on that list of requirements? [19:36] I mean, can we collaborate on it before it is submitted? [19:36] How should we do that? [19:37] One way might be to do it on-list, making it clear that it's discussion towards a list of requirements rather than a final version? Or would you like to do this somewhere else? [19:37] Makes sense, but I'm not sure if we'd be able to discuss it fully during this meeting [19:38] rbasak: perhaps we can discuss it as a side-topic on the tech-board list and once we have a list of requirements we can submit them to the main topic? [19:38] On list is possible, there's also this uh, ugly way of using some shared document first? I know google docs isn't ideal, but maybe there are better technologies (more open) [19:38] Etherpad? [19:39] hey looks like ubuntu's instance is still live :) [19:39] I'm happy whichever way :) [19:39] Oh, etherpad! Been a while since I last used that - maybe that's a good idea? [19:40] Since it's good if each of us has time to think it through and leave some comments [19:40] https://pad.ubuntu.com/third-party-repository-requirements [19:41] Thanks for creating it! Let me add an action item for this for the next meeting [19:42] #action Work on getting a set of requirements for Ubuntu packages that enable third party software repositiories by default - related to a ML entry [19:42] ACTION: Work on getting a set of requirements for Ubuntu packages that enable third party software repositiories by default - related to a ML entry [19:42] Whoops, let me add the link there [19:42] #action ^ https://pad.ubuntu.com/third-party-repository-requirements [19:42] ACTION: ^ https://pad.ubuntu.com/third-party-repository-requirements [19:43] Ok, in the meantime, let us move on [19:43] Apparently it doesn't support apostrophes :-/ [19:43] #topic Check up on community bugs (standing item) [19:43] I didn't see any open bugs, so let's move on [19:43] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:44] #info The next chair is mdeslaur, with cyphermox as backup [19:44] ack [19:44] Thanks! [19:44] #topic AOB [19:44] ...anything we need to talk about? [19:45] If not, then let us finish up and start working on those requirements, I see rbasak already proposed some! [19:45] So be sure to take a look and write your thoughts/comments [19:45] #endmeeting [19:45] Meeting ended at 19:45:36 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-07-13-19.02.moin.txt [19:45] yeah, I'll take a look tomorrow [19:45] Thank you everyone! [19:45] I think this was quite productive [19:45] o/ [19:46] rbasak: sil2100 perhaps we should split "adding a default repo" and "installing a third party package" into two distinct things? [19:46] mdeslaur: sure - please go ahead and edit [19:46] mdeslaur: hm, might be an idea [19:46] ok will do first thing tomorrow, gotta run [19:46] I'm not sure how to split the requirements. [19:46] But we can figure that out [19:46] mdeslaur: could you write that up on the doc! [19:46] Thanks! [19:46] Ok, I disappear into the few final hours of my holidays [19:46] o/ [19:47] * sil2100 edits the agenda and goes [19:47] thanks sil2100! thanks rbasak