=== genii is now known as genii-core === genii-core is now known as genii [14:31] o/ [14:31] omw [14:31] give me 2 min to start [14:32] hey [14:32] good morning [14:33] hey! It's going to be my first MIR meeting, as I want to join the team for foundations. [14:33] welcome slyon :) [14:33] :) [14:33] ok let me get this started [14:33] #startmeeting Weekly Main Inclusion Requests status [14:33] Meeting started at 14:33:47 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:33] Available commands: action, commands, idea, info, link, nick [14:33] o/ [14:34] ping for MIR ddstreet didrocks doko slyon sarnold jamespage [14:34] #topic Review of previous action items [14:34] I have sent around some thoughts about rust, but that isn't an "action" yet [14:34] I'd love if all of you could give that a review or if you are ok just an "ack" on the mail itself [14:34] thanks for the reminder [14:35] will do [14:35] if you want an open discussion about it please let us do so at the end in the "any other business" section [14:35] will do [14:35] ok [14:35] then heads up and for the log file now [14:35] slyon: here will be our new MIr team member from foundations [14:35] he will help out where doko couldn't make it [14:35] welcome slyon :) [14:35] and he will start with adsys which shall make didrocks happy I hope [14:35] \o/ [14:36] o/ yes. I already prepared the adsys MIR, which I'd like to get reviewed/approved by some of you folks.. [14:36] https://paste.ubuntu.com/p/HhTKzRJSDQ/ [14:36] but first of all (there isn't that much of a process, but I need to ask) - any objections that we include him [14:36] wfm [14:36] no objection either [14:36] slyon: In can give your MIR-review a review tomorrow morning and let you know if I'd change anything [14:37] I've taken a TODO for it [14:37] thanks [14:37] in general to all of you, you know how it works - initially slyon will do reviews like each of us, but probably ask one of us if it is ok. Give him the favor of checking his work [14:37] that way he can fully grow into the team [14:38] about rust - once we have some discussions / acks in place I can (as promised) go further with it as suggestes by Steve [14:38] now let us start the actual MIR content for today ... [14:38] #topic current component mismatches [14:38] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:38] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:38] mostly known false positives [14:39] sarnold: weekly question for fence-agents review? [14:39] cpaelzer: weekly answer, slightly more positive this time :) [14:39] just FYI we updated the documentation already that talks about the package split and the promotion to main happening [14:39] so the docs say you have done and hopefully ack'ed it in time :-) [14:39] python-oslo ? [14:40] I think I remember we talked about it, let me check the referenced MIR bugs [14:40] Hmm [14:40] no opend 5 days ago [14:40] it is new and will be assigned in a later stage of the meeting as usual [14:40] jamespage: or did you plan to review them anyway? [14:40] that is https://bugs.launchpad.net/ubuntu/+source/python-oslo.metrics/+bug/1943143 [14:41] Launchpad bug 1943143 in python-prometheus-client (Ubuntu) "[MIR] python-oslo.metrics, python-prometheus-client" [Undecided, New] [14:41] and python-cheroot was added to https://bugs.launchpad.net/ubuntu/+source/python-cheroot/+bug/1930111 [14:41] Launchpad bug 1930111 in cherrypy3 (Ubuntu) "[MIR] new dependencies of cherrypy3: jaraco.collections, jaraco.classes, jaraco.text, python-cheroot, python-jaraco.functools, python-tempora, python-portend, zc.lockfile" [Undecided, In Progress] [14:41] but that already is on security [14:41] sarnold: is this tracked wherever you track the incoming reviews [14:42] and BTW nothing else in mismatches to be concerned about [14:42] cpaelzer: python-chroot yes, python-oslo.* no [14:42] slyon: remind me on monday to tell you the story behind false-positives [14:42] python-cheroot rather. silly name. [14:42] ack [14:42] sarnold: that is ok then, oslo needs to go through MIR review first [14:42] #topic New MIRs [14:42] #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:43] 3 (kind of) bugs to review [14:43] we have oslo (actually two packages) [14:43] in [14:43] in [14:43] https://bugs.launchpad.net/ubuntu/+source/python-oslo.metrics/+bug/1943143 [14:43] Launchpad bug 1943143 in python-prometheus-client (Ubuntu) "[MIR] python-oslo.metrics, python-prometheus-client" [Undecided, New] [14:43] anyone wants to take that? [14:43] and we have libportal in [14:43] https://bugs.launchpad.net/ubuntu/+source/libportal/+bug/1932485 [14:43] Launchpad bug 1932485 in libportal (Ubuntu) "[MIR] libportal" [Low, New] [14:43] that needs a review as well [14:44] I think libportal is desktopish, I can take that [14:44] it is indeed [14:44] your experience there is appreciated [14:44] jamespage: did you intend to deal with oslo yourself [14:44] "Note that there is a question on whether the API is stable at this point" .. is this really a candidate for 22.04 main? [14:44] jamespage: and is thie urgent (21.10) or has time (22.04) ? [14:45] indeed sarnold [14:45] didrocks: please give some extra scrutiny to how maintainable that seems [14:45] if it has only one user, maybe - but if many components use it and it is unstable I'm not sure ... [14:45] will do [14:45] good point [14:46] assigned - thanks [14:46] oslo then [14:46] that should be fast, depsite being two libs [14:46] I can have a look [14:46] #topic Incomplete bugs / questions [14:46] #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:47] egl-wayland we did last week [14:47] and rust is the bug for the discussion that is in your mail inbox already [14:47] nothing else newly incomplete that needs our action [14:47] #topic Any other business? [14:47] ok, open stage this is your chance if you have to adress anything [14:48] Can we change the assignee of https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/1936907 to myself? I do not seem to have sufficient permission [14:48] Launchpad bug 1936907 in adsys (Ubuntu) "[MIR] ADSys" [Undecided, New] [14:48] slyon: mind if we take 5 minutes post-meeting so that we address the first comments? [14:48] doko added you to the team, so you should [14:48] bit I can in any case [14:49] done slyon [14:49] thanks cpaelzer [14:49] sure didrocks [14:49] good suggestion I'll close for the logs to finish [14:49] and then we can do a quick read of the RFC he linked [14:49] anything else? [14:49] nothing from me [14:49] nothing either [14:49] nothing [14:49] ok already thanks to all of you [14:49] #endmeeting [14:49] Meeting ended at 14:49:58 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-14-14.33.moin.txt [14:50] thanks! [14:50] thanks cpaelzer, all :) [14:50] o/ [14:50] now let us have a look at the pastebin I guess [14:50] is the discussion about rust public? [14:50] schopin: not yet in detail [14:50] onyl that it happens [14:50] OK, I'll wait for the movie then :) [14:50] we need to ensure we are sort of in sync before anything goes public yet [14:50] or we will discuss-rip apart each other without much benefit for anyone [14:51] other than movie like entertainment [14:51] Oh I was just thinking public as in read-only. [14:51] sorry schopin the show will happen at a later point in time :-) [14:51] slyon: ok, so, let’s go in order, some are good recommendations/required, some needs more comments :) [14:51] required TODOS: [14:52] -> Please add a team subscription (~desktop-bugs?). This has been amended and there is a check before promotion by archive admins [14:52] (it’s desktop-packages btw for desktop) [14:52] it is still recommended to subscribe upfront but no more strictly required [14:52] indeed [14:52] -> dh-apport build-dependency needs to be promoted to main (src:apport already in main) [14:52] oh i see, I wasn't aware of this [14:53] I wasn't sure about dh-apport either, are build-depends required to be in main? [14:53] this is a build-dep and for a few cycles, we don’t require build-deps to be in main. The only exception is when you staticalliy compile ofc, as the code will be in main [14:53] slyon: re-read our ruls, if it is unclear propose a change next week - ok ? [14:53] we all might do it from memory [14:53] (and as the code will be executed) [14:53] cpaelzer: will do [14:53] makes sense, didrocks [14:53] ack to the build-dep only being in main when static linking [14:54] 3rd Required TODO: ack, is it in the wiki? (my bad), I really like the wording :) [14:54] if it’s not in the Wiki, we should definively write it there to be explictely stated [14:54] it is in the wiki [14:54] it is there [14:54] should take back from a fresh template sometimes, my bad then. I’ll add it in the initial comment [14:55] this does not ahve to go to main "adsys-dbgsym" [14:55] yeah, that was my final one, spoiled! [14:55] unless there is an explicit dependency to it [14:55] :) [14:55] sorry didrocks [14:55] :p [14:55] Recommended TODOs: [14:55] OK [14:55] - Make autopkgtests pass (it's not a regression as the autopkgtests passed never before) [14:55] well spotted, my bad, it’s working on 10 machines, on VM and on CI in docker and non docker [14:56] I never thought autopkgtest wouldn’t pass, it seems some issues with the filesystem, I will check [14:56] - Add debian/watch file [14:56] yeah... autopkgtest infrastructure can provide a funny environment sometimes :) [14:56] heh :) [14:56] didrocks: maybe the nrew rule applies that if tests won't work at buld/autopkgtest time that you link and show examples of regular tests in other places? [14:56] cpaelzer: well, I would prefer really that we fix them [14:56] oh yeah I'd "prefer" that as well [14:56] it helps to have others not breaking you also [14:57] like a new Go :) [14:57] just saying if it can't be fixed there, do not end up saying "no" but consider another place to run them [14:57] yeah [14:57] we can relax that, it’s recommended anyway, not required, which is okish IMHO. But not how I like to approach it for my projects :) [14:58] on d/watch -> this is where I have to disagree, this is a native package, built from the upstream VCS. There is then no such thing as "upstream tarballs" [14:58] so nothing to download from [14:58] one thing - the sudo rule "use of sudo, gksu, pkexec, or LD_LIBRARY_PATH" is meant for the delivered packages [14:58] ugh, you're right! good spot [14:58] not the tests [14:59] yes, that one as well ^ [14:59] it isn't a problem if the tests internally sudo (still your hint at needs_root is great) [14:59] but in terms of "rules" having it in the tests isn't a problem [14:59] ack [14:59] a silend sudo or setuid in what we install OTOH would be a problem [14:59] (anyway, the package is using policykit, have a daemon running as root, listening on unix socket, the security review is still needed) [14:59] I have to run for a meeting, sorry [14:59] o/ [15:00] thanks cpaelzer, we will finish up and if you want to scrollback then… :) [15:00] well, last one is special for golang: [15:00] missing-notice-file-for-apache-license [15:00] -> this is in vendor/ [15:00] what go mod vendor does it vendoring dependencies (btw, it’s better at eliminates uneeded deps in 1.17, which we don’t have yet) [15:00] and by design, it’s not copying LICENSE file, just code [15:01] I think a lintian warning is needed there [15:01] eww [15:01] sarnold: my debian/copyright is fun to complete, as you can guess :p [15:01] didrocks: yeah :/ [15:02] hardening-no-pie -> I think this is something general in Go packages [15:02] didrocks: is it common in goland to use spdx headers in files to describe licenses? [15:02] I prefer to not override it in a lintian warnings [15:02] I need to double check in vendor/. as that hint was provided by lintian when doing a test build [15:02] yeah, I think golang is just funny there and doesn't emit pie with any amount of effort :( [15:02] sarnold: I don’t think so, some have headers, some will never use them [15:02] ok [15:02] sarnold: should I keep the lintian warning in, or is it something we will never be able to do? [15:02] I think upstream is not interested in support PIE? [15:03] supporting* [15:03] didrocks: bummer. at some point I wouldn't be surprised if supplying to the US govt requires far more "software bill of material" things, and having those all throughout might make that approachable. [15:03] yes [15:03] IMO you can keep the lintian warning in [15:04] as I saw that as a recommendation only [15:04] I don’t like too many warnings either, because when they start piling up… [15:04] :) [15:04] didrocks: if we do silence it, a TODO or XXX nearby to ask it to be reviewed every year or two would be nice ;) [15:04] but yeah, let’s do that for now [15:04] ok, let’s not silence it [15:04] * sarnold <-- always the optimist [15:04] just the license one [15:04] hehe, I will blame you if I still see it in a couple of years [15:04] personnally ofc :) [15:04] :) [15:04] naturally :) [15:04] (and if I remember!) [15:05] slyon: I guess that’s mostly it? Did I forget anything? [15:05] nope. that's it. [15:05] (I think the bigger task is the autopkgtest one, I’ll do an upload in a week with fixes anyway) [15:05] Thank you so much for your feedback! I will update the RFC accordingly and wait for cpaelzer's feedback, before sending it to LP [15:05] and thanks for spotting because, as it was never blocked and the tests are running in so many places, I never even double-guess this was always failing [15:06] thanks! [15:06] yeah, double check with cpaelzer, as I’m part of it, better for him to be around so that I don’t try to bend it my way too much :p [15:06] heh [15:08] (I think the autopkgtests are chmod that don’t work, like when we try to trigger errors with unable to write to a file and in setup(), we chmod the file to make it RO first ) [15:08] is it something known? It rings a bell but I’m not sure I haven’t dreamt it [15:09] doesn't ring a bell here [15:11] yeah, all failing tests are FHS related when we try to trigger edge error cases with chmoding file to make them RO, I will try in autopkgtests VM [18:58] \o [18:58] o/ [18:59] o/ [19:01] #startmeeting Technical Board [19:01] Meeting started at 19:01:04 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:01] Available commands: action, commands, idea, info, link, nick [19:01] #topic Action review [19:01] ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. [19:02] Previous discussion here [19:03] Is there anything actually actionable by the TB any more here? [19:03] we need to figure out who's in charge of MATE I guess [19:03] I'd like for the TB to either drop this, or specify exactly what the TB needs to do :-/ [19:03] * vorlon waves [19:03] o/ [19:04] as I recall, the MATE boutique enables a PPA? [19:04] I don't remember if it's a ppa or an archive external to LP; but it's not under Ubuntu governance [19:04] Right, and I think it's agreed that this will be fixed, and how, but there's been no movement or ETA in many months/years AIUI. [19:05] right [19:06] I'm not sure if we want to actually do this, but the only way I can see to get this to move is for the TB to mandate a deadline after which MATE cannot ship as an official flavour unless/until this is fixed. Either that, or we drop the matter and let MATE continue as they wish. [19:06] well, I was going to say either a deadline for not being a flavor, or an upload to remove this behavior [19:06] I don't think we should let them continue [19:06] I agree [19:07] a deadline sounds appropriate [19:07] With Impish imminent, how about we set the requirement for J? [19:07] I would be +1 on removing the behavior, but I still hope we'll get some news back from Wimpy [19:07] So let Impish slide, but it's a hard requirement that this isn't a problem in J, otherwise it doesn't ship officially. [19:08] I agree to that [19:09] If flavour leads object, I'd be opening to them discussing alternatives with us. But setting the default position will help get some conclusion on this I think. [19:09] sil2100: opinion? [19:09] As in, are you +1 also? [19:09] I'm +1, just was trying to read some backlog to figure out - is this behavior with the boutique in impish right now? [19:10] That's the impression I have. If not, then there should be no problem :) [19:10] if it's changed, no one has told us [19:10] I think there was a vague sense that it might migrate to snaps but I haven't heard that this had happened [19:11] Yes that was discussed (very briefly) at https://irclogs.ubuntu.com/2021/05/28/%23ubuntu-desktop.html#t10:42 [19:11] This is the problem when there's no active communication... [19:11] #agreed MATE is required to resolve the PPA situation by the J release. Otherwise, MATE will not be an official flavour in J. [19:11] AGREED: MATE is required to resolve the PPA situation by the J release. Otherwise, MATE will not be an official flavour in J. [19:12] #action rbasak to communicate the TB's MATE resolution to the MATE flavour leads. [19:12] ACTION: rbasak to communicate the TB's MATE resolution to the MATE flavour leads. [19:12] ACTION: formal ratification of third party seeded snap security policy, depends on: [19:12] 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:12] fwiw I have more capacity this month than I have recently and think I will be able to make progress on this soon [19:13] Thanks - let's carry. [19:13] #action formal ratification of third party seeded snap security policy, depends on: [19:13] ACTION: formal ratification of third party seeded snap security policy, depends on: [19:13] #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:13] 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:13] ACTION: vorlon to reply to seeded snap upload permissions question on list [19:13] likewise :) [19:13] #action vorlon to reply to seeded snap upload permissions question on list [19:13] ACTION: vorlon to reply to seeded snap upload permissions question on list [19:13] 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:16] Yes, sadly that's still in progress, didn't progress much since the last meeting: https://wiki.ubuntu.com/OEMArchive <- the page is started, I have a few more drafted words but nothing much more [19:16] OK thanks. Carried then. [19:16] #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:16] 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:16] The next item wasn't updated on the agenda, but based on the logs from last time: [19:17] ACTION: mdeslaur to follow-up/respond for security team on advice for the flatpak TB request [19:17] I asked seth to file a bug: https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1943480 [19:17] Launchpad bug 1943480 in flatpak (Ubuntu) "flatpak installation permission requirements different from ubuntu software" [Undecided, New] [19:17] Thanks mdeslaur and sarnold! [19:17] though I now see that the bug doesn't specifically state the security team position on the matter, I'll make sure that is fixed [19:17] Is there anything further for the TB here? [19:18] mdeslaur: heh, yeah, I wasn't 100% sure we'd reached a consensus yet :( [19:18] OK how about I leave that action with mdeslaur for now? Or can you relay the security team position now for discussion? [19:19] I think the TB opinion is likely to follow the security team's opinion, and then the TB part could be concluded/closed and it'll just be a bug to implement. [19:19] I'm not sure there's anything more for the TB here [19:19] The TB deferred to the security team [19:20] OK thanks let's consider the TB part done then, and no further action for the TB. [19:20] It would just circle back is someone disagreed with the security team's decision [19:20] *if [19:20] ACTION: all TB members to "vote" or explain what they do not like of a proposal on https://pad.ubuntu.com/third-party-repository-requirements (cyphermox, 19:25) [19:20] I hope everyone did their homework? [19:20] I did spend some time on that page, but I still need to think about it some more [19:22] Can the others go through it before the next meeting, please? [19:22] * vorlon nods [19:22] Will do o/ [19:22] Yep, thanks. And also that might mean that the rest of us need to circle round again to continue discussion / clarify any further questions. [19:23] So I'll leave the action for everyone. I certainly need to read mdeslaur's comments in detail. [19:23] #action all TB members to "vote" or explain what they do not like of a proposal on https://pad.ubuntu.com/third-party-repository-requirements [19:23] ACTION: all TB members to "vote" or explain what they do not like of a proposal on https://pad.ubuntu.com/third-party-repository-requirements [19:23] #topic Erich Eickmeyer via the mailing list: DisplayCAL in the archive as a deb that pulls in a Flatpak, and its inclusion in Ubuntu Studio by default. See https://lists.ubuntu.com/archives/technical-board/2021-July/002562.html and https://pad.ubuntu.com/third-party-repository-requirements [19:23] I think this is deferred for now, until the previous item is completed. [19:23] Any further discussion on this topic? [19:24] nope === rbasak changed the topic of #ubuntu-meeting to: Scan the mailing list archive for anything we missed (standing item) [19:24] #topic Scan the mailing list archive for anything we missed (standing item) [19:24] I screwed that up. Wrong magic symbol :-/ [19:25] Anyway [19:25] :( [19:25] :) [19:25] (also wrong magic symbol) [19:25] I don't see anything on the ML. [19:25] #info Nothing spotted on the ML. [19:25] #topic Check up on community bugs (standing item) [19:26] #info No currently open community bugs [19:26] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:26] Next chair will be vorlon. Backup: sil2100 [19:26] #topic AOB [19:26] AOB? [19:26] I've got none [19:26] nothing here [19:27] #endmeeting [19:27] Meeting ended at 19:27:14 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-14-19.01.moin.txt [19:27] Thanks all! [19:27] thanks everyone [19:27] * rbasak wonders what the previous topci was [19:27] o/ === sil2100 changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [19:28] I think this is it? [19:28] Thank you!