[14:31] <slyon> o/
[14:31] <cpaelzer> omw
[14:31] <cpaelzer> give me 2 min to start
[14:32] <didrocks> hey
[14:32] <sarnold> good morning
[14:33] <slyon> hey! It's going to be my first MIR meeting, as I want to join the team for foundations.
[14:33] <didrocks> welcome slyon :)
[14:33] <slyon> :)
[14:33] <cpaelzer> ok let me get this started
[14:33] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:33] <meetingology> Meeting started at 14:33:47 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:33] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:33] <ddstreet> o/
[14:34] <cpaelzer> ping for MIR ddstreet didrocks doko slyon sarnold jamespage
[14:34] <cpaelzer> #topic Review of previous action items
[14:34] <cpaelzer> I have sent around some thoughts about rust, but that isn't an "action" yet
[14:34] <cpaelzer> 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] <sarnold> thanks for the reminder
[14:35] <slyon> will do
[14:35] <cpaelzer> if you want an open discussion about it please let us do so at the end in the "any other business" section
[14:35] <didrocks> will do
[14:35] <cpaelzer> ok
[14:35] <cpaelzer> then heads up and for the log file now
[14:35] <cpaelzer> slyon:  here will be our new MIr team member from foundations
[14:35] <cpaelzer> he will help out where doko couldn't make it
[14:35] <sarnold> welcome slyon :)
[14:35] <cpaelzer> and he will start with adsys which shall make didrocks happy I hope
[14:35] <didrocks> \o/
[14:36] <slyon> o/ yes. I already prepared the adsys MIR, which I'd like to get reviewed/approved by some of you folks..
[14:36] <slyon> https://paste.ubuntu.com/p/HhTKzRJSDQ/
[14:36] <cpaelzer> 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] <sarnold> wfm
[14:36] <didrocks> no objection either
[14:36] <cpaelzer> slyon: In can give your MIR-review a review tomorrow morning and let you know if I'd change anything
[14:37] <cpaelzer> I've taken a TODO for it
[14:37] <slyon> thanks
[14:37] <cpaelzer> 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] <cpaelzer> that way he can fully grow into the team
[14:38] <cpaelzer> about rust - once we have some discussions / acks in place I can (as promised) go further with it as suggestes by Steve
[14:38] <cpaelzer> now let us start the actual MIR content for today ...
[14:38] <cpaelzer> #topic current component mismatches
[14:38] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:38] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:38] <cpaelzer> mostly known false positives
[14:39] <cpaelzer> sarnold: weekly question for fence-agents review?
[14:39] <sarnold> cpaelzer: weekly answer, slightly more positive this time :)
[14:39] <cpaelzer> just FYI we updated the documentation already that talks about the package split and the promotion to main happening
[14:39] <cpaelzer> so the docs say you have done and hopefully ack'ed it in time :-)
[14:39] <cpaelzer> python-oslo ?
[14:40] <cpaelzer> I think I remember we talked about it, let me check the referenced MIR bugs
[14:40] <cpaelzer> Hmm
[14:40] <cpaelzer> no opend 5 days ago
[14:40] <cpaelzer> it is new and will be assigned in a later stage of the meeting as usual
[14:40] <cpaelzer> jamespage: or did you plan to review them anyway?
[14:40] <cpaelzer> that is https://bugs.launchpad.net/ubuntu/+source/python-oslo.metrics/+bug/1943143
[14:41] <cpaelzer> and python-cheroot was added to https://bugs.launchpad.net/ubuntu/+source/python-cheroot/+bug/1930111
[14:41] <cpaelzer> but that already is on security
[14:41] <cpaelzer> sarnold: is this tracked wherever you track the incoming reviews
[14:42] <cpaelzer> and BTW nothing else in mismatches to be concerned about
[14:42] <sarnold> cpaelzer: python-chroot yes, python-oslo.* no
[14:42] <cpaelzer> slyon: remind me on monday to tell you the story behind false-positives
[14:42] <sarnold> python-cheroot rather. silly name.
[14:42] <slyon> ack
[14:42] <cpaelzer> sarnold: that is ok then, oslo needs to go through MIR review first
[14:42] <cpaelzer> #topic New MIRs
[14:42] <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
[14:43] <cpaelzer> 3 (kind of) bugs to review
[14:43] <cpaelzer> we have oslo (actually two packages)
[14:43] <cpaelzer> in
[14:43] <cpaelzer> in
[14:43] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/python-oslo.metrics/+bug/1943143
[14:43] <cpaelzer> anyone wants to take that?
[14:43] <cpaelzer> and we have libportal in
[14:43] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libportal/+bug/1932485
[14:43] <cpaelzer> that needs a review as well
[14:44] <didrocks> I think libportal is desktopish, I can take that
[14:44] <cpaelzer> it is indeed
[14:44] <cpaelzer> your experience there is appreciated
[14:44] <cpaelzer> jamespage: did you intend to deal with oslo yourself
[14:44] <sarnold> "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] <cpaelzer> jamespage: and is thie urgent (21.10) or has time (22.04) ?
[14:45] <cpaelzer> indeed sarnold
[14:45] <cpaelzer> didrocks: please give some extra scrutiny to how maintainable that seems
[14:45] <cpaelzer> if it has only one user, maybe - but if many components use it and it is unstable I'm not sure ...
[14:45] <didrocks> will do
[14:45] <sarnold> good point
[14:46] <cpaelzer> assigned - thanks
[14:46] <cpaelzer> oslo then
[14:46] <cpaelzer> that should be fast, depsite being two libs
[14:46] <cpaelzer> I can have a look
[14:46] <cpaelzer> #topic Incomplete bugs / questions
[14:46] <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
[14:47] <cpaelzer> egl-wayland we did last week
[14:47] <cpaelzer> and rust is the bug for the discussion that is in your mail inbox already
[14:47] <cpaelzer> nothing else newly incomplete that  needs our action
[14:47] <cpaelzer> #topic Any other business?
[14:47] <cpaelzer> ok, open stage this is your chance if you have to adress anything
[14:48] <slyon> 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] <didrocks> slyon: mind if we take 5 minutes post-meeting so that we address the first comments?
[14:48] <cpaelzer> doko added you to the team, so you should
[14:48] <cpaelzer> bit I can in any case
[14:49] <cpaelzer> done slyon
[14:49] <slyon> thanks cpaelzer
[14:49] <slyon> sure didrocks
[14:49] <cpaelzer> good suggestion I'll close for the logs to finish
[14:49] <cpaelzer> and then we can do a quick read of the RFC he linked
[14:49] <cpaelzer> anything else?
[14:49] <sarnold> nothing from me
[14:49] <didrocks> nothing either
[14:49] <slyon> nothing
[14:49] <cpaelzer> ok already thanks to all of you
[14:49] <cpaelzer> #endmeeting
[14:49] <meetingology> 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] <didrocks> thanks!
[14:50] <sarnold> thanks cpaelzer, all :)
[14:50] <slyon> o/
[14:50] <cpaelzer> now let us have a look at the pastebin I guess
[14:50] <schopin> is the discussion about rust public?
[14:50] <cpaelzer> schopin: not yet in detail
[14:50] <cpaelzer> onyl that it happens
[14:50] <schopin> OK, I'll wait for the movie then :)
[14:50] <cpaelzer> we need to ensure we are sort of in sync before anything goes public yet
[14:50] <cpaelzer> or we will discuss-rip apart each other without much benefit for anyone
[14:51] <cpaelzer> other than movie like entertainment
[14:51] <schopin> Oh I was just thinking public as in read-only.
[14:51] <cpaelzer> sorry schopin the show will happen at a later point in time :-)
[14:51] <didrocks> slyon: ok, so, let’s go in order, some are good recommendations/required, some needs more comments :)
[14:51] <didrocks> required TODOS:
[14:52] <didrocks> -> Please add a team subscription (~desktop-bugs?). This has been amended and there is a check before promotion by archive admins
[14:52] <didrocks> (it’s desktop-packages btw for desktop)
[14:52] <cpaelzer> it is still recommended to subscribe upfront but no more strictly required
[14:52] <didrocks> indeed
[14:52] <didrocks> -> dh-apport build-dependency needs to be promoted to main (src:apport already in main)
[14:52] <slyon> oh i see, I wasn't aware of this
[14:53] <slyon> I wasn't sure about dh-apport either, are build-depends required to be in main?
[14:53] <didrocks> 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] <cpaelzer> slyon: re-read our ruls, if it is unclear propose a change next week - ok ?
[14:53] <cpaelzer> we all might do it from memory
[14:53] <didrocks> (and as the code will be executed)
[14:53] <slyon> cpaelzer: will do
[14:53] <slyon> makes sense, didrocks
[14:53] <cpaelzer> ack to the build-dep only being in main when static linking
[14:54] <didrocks> 3rd Required TODO: ack, is it in the wiki? (my bad), I really like the wording :)
[14:54] <didrocks> if it’s not in the Wiki, we should definively write it there to be explictely stated
[14:54] <slyon> it is in the wiki
[14:54] <cpaelzer> it is there
[14:54] <didrocks> should take back from a fresh template sometimes, my bad then. I’ll add it in the initial comment
[14:55] <cpaelzer> this does not ahve to go to main "adsys-dbgsym"
[14:55] <didrocks> yeah, that was my final one, spoiled!
[14:55] <cpaelzer> unless there is an explicit dependency to it
[14:55] <didrocks> :)
[14:55] <cpaelzer> sorry didrocks
[14:55] <didrocks> :p
[14:55] <didrocks> Recommended TODOs:
[14:55] <slyon> OK
[14:55] <didrocks> - Make autopkgtests pass (it's not a regression as the autopkgtests passed never before)
[14:55] <didrocks> well spotted, my bad, it’s working on 10 machines, on VM and on CI in docker and non docker
[14:56] <didrocks> I never thought autopkgtest wouldn’t pass, it seems some issues with the filesystem, I will check
[14:56] <didrocks> - Add debian/watch file
[14:56] <slyon> yeah... autopkgtest infrastructure can provide a funny environment sometimes :)
[14:56] <sarnold> heh :)
[14:56] <cpaelzer> 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] <didrocks> cpaelzer: well, I would prefer really that we fix them
[14:56] <cpaelzer> oh yeah I'd "prefer" that as well
[14:56] <didrocks> it helps to have others not breaking you also
[14:57] <didrocks> like a new Go :)
[14:57] <cpaelzer> just saying if it can't be fixed there, do not end up saying "no" but consider another place to run them
[14:57] <didrocks> yeah
[14:57] <didrocks> 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] <didrocks> 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] <didrocks> so nothing to download from
[14:58] <cpaelzer> one thing - the sudo rule "use of sudo, gksu, pkexec, or LD_LIBRARY_PATH" is meant for the delivered packages
[14:58] <slyon> ugh, you're right! good spot
[14:58] <cpaelzer> not the tests
[14:59] <didrocks> yes, that one as well ^
[14:59] <cpaelzer> it isn't a problem if the tests internally sudo (still your hint at needs_root is great)
[14:59] <cpaelzer> but in terms of "rules" having it in the tests isn't a problem
[14:59] <slyon> ack
[14:59] <cpaelzer> a silend sudo or setuid in what we install OTOH would be a problem
[14:59] <didrocks> (anyway, the package is using policykit, have a daemon running as root, listening on unix socket, the security review is still needed)
[14:59] <cpaelzer> I have to run for a meeting, sorry
[14:59] <cpaelzer> o/
[15:00] <didrocks> thanks cpaelzer, we will finish up and if you want to scrollback then… :)
[15:00] <didrocks> well, last one is special for golang:
[15:00] <didrocks> missing-notice-file-for-apache-license
[15:00] <didrocks> -> this is in vendor/
[15:00] <didrocks> 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] <didrocks> and by design, it’s not copying LICENSE file, just code
[15:01] <didrocks> I think a lintian warning is needed there
[15:01] <sarnold> eww
[15:01] <didrocks> sarnold: my debian/copyright is fun to complete, as you can guess :p
[15:01] <sarnold> didrocks: yeah :/
[15:02] <didrocks> hardening-no-pie -> I think this is something general in Go packages
[15:02] <sarnold> didrocks: is it common in goland to use spdx headers in files to describe licenses?
[15:02] <didrocks> I prefer to not override it in a lintian warnings
[15:02] <slyon> I need to double check in vendor/. as that hint was provided by lintian when doing a test build
[15:02] <sarnold> yeah, I think golang is just funny there and doesn't emit pie with any amount of effort :(
[15:02] <didrocks> sarnold: I don’t think so, some have headers, some will never use them
[15:02] <slyon> ok
[15:02] <didrocks> sarnold: should I keep the lintian warning in, or is it something we will never be able to do?
[15:02] <didrocks> I think upstream is not interested in support PIE?
[15:03] <didrocks> supporting*
[15:03] <sarnold> 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] <didrocks> yes
[15:03] <slyon> IMO you can keep the lintian warning in
[15:04] <slyon> as I saw that as a recommendation only
[15:04] <didrocks> I don’t like too many warnings either, because when they start piling up…
[15:04] <didrocks> :)
[15:04] <sarnold> 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] <didrocks> but yeah, let’s do that for now
[15:04] <didrocks> ok, let’s not silence it
[15:04]  * sarnold <-- always the optimist
[15:04] <didrocks> just the license one
[15:04] <didrocks> hehe, I will blame you if I still see it in a couple of years
[15:04] <didrocks> personnally ofc :)
[15:04] <sarnold> :)
[15:04] <sarnold> naturally :)
[15:04] <didrocks> (and if I remember!)
[15:05] <didrocks> slyon: I guess that’s mostly it? Did I forget anything?
[15:05] <slyon> nope. that's it.
[15:05] <didrocks> (I think the bigger task is the autopkgtest one, I’ll do an upload in a week with fixes anyway)
[15:05] <slyon> 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] <didrocks> 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] <didrocks> thanks!
[15:06] <didrocks> 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] <slyon> heh
[15:08] <didrocks> (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] <didrocks> is it something known? It rings a bell but I’m not sure I haven’t dreamt it
[15:09] <slyon> doesn't ring a bell here
[15:11] <didrocks> 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] <mdeslaur> \o
[18:58] <rbasak> o/
[18:59] <sil2100> o/
[19:01] <rbasak> #startmeeting Technical Board
[19:01] <meetingology> Meeting started at 19:01:04 UTC.  The chair is rbasak.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[19:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[19:01] <rbasak> #topic Action review
[19:01] <rbasak> ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns.
[19:02] <rbasak> Previous discussion here
[19:03] <rbasak> Is there anything actually actionable by the TB any more here?
[19:03] <mdeslaur> we need to figure out who's in charge of MATE I guess
[19:03] <rbasak> 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] <rbasak> o/
[19:04] <mdeslaur> as I recall, the MATE boutique enables a PPA?
[19:04] <vorlon> I don't remember if it's a ppa or an archive external to LP; but it's not under Ubuntu governance
[19:04] <rbasak> 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] <vorlon> right
[19:06] <rbasak> 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] <vorlon> well, I was going to say either a deadline for not being a flavor, or an upload to remove this behavior
[19:06] <mdeslaur> I don't think we should let them continue
[19:06] <vorlon> I agree
[19:07] <mdeslaur> a deadline sounds appropriate
[19:07] <rbasak> With Impish imminent, how about we set the requirement for J?
[19:07] <sil2100> I would be +1 on removing the behavior, but I still hope we'll get some news back from Wimpy
[19:07] <rbasak> 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] <mdeslaur> I agree to that
[19:09] <rbasak> 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] <rbasak> sil2100: opinion?
[19:09] <rbasak> As in, are you +1 also?
[19:09] <sil2100> 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] <rbasak> That's the impression I have. If not, then there should be no problem :)
[19:10] <vorlon> if it's changed, no one has told us
[19:10] <vorlon> I think there was a vague sense that it might migrate to snaps but I haven't heard that this had happened
[19:11] <rbasak> Yes that was discussed (very briefly) at https://irclogs.ubuntu.com/2021/05/28/%23ubuntu-desktop.html#t10:42
[19:11] <sil2100> This is the problem when there's no active communication...
[19:11] <rbasak> #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] <meetingology> 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] <rbasak> #action rbasak to communicate the TB's MATE resolution to the MATE flavour leads.
[19:12] <meetingology> ACTION: rbasak to communicate the TB's MATE resolution to the MATE flavour leads.
[19:12] <rbasak> ACTION: formal ratification of third party seeded snap security policy, depends on:
[19:12] <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.
[19:12] <vorlon> 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] <rbasak> Thanks - let's carry.
[19:13] <rbasak> #action formal ratification of third party seeded snap security policy, depends on:
[19:13] <meetingology> ACTION: formal ratification of third party seeded snap security policy, depends on:
[19:13] <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.
[19:13] <meetingology> 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] <rbasak> ACTION: vorlon to reply to seeded snap upload permissions question on list
[19:13] <vorlon> likewise :)
[19:13] <rbasak> #action vorlon to reply to seeded snap upload permissions question on list
[19:13] <meetingology> ACTION: vorlon to reply to seeded snap upload permissions question on list
[19:13] <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
[19:16] <sil2100> 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] <rbasak> OK thanks. Carried then.
[19:16] <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
[19:16] <meetingology> 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] <rbasak> The next item wasn't updated on the agenda, but based on the logs from last time:
[19:17] <rbasak> ACTION: mdeslaur to follow-up/respond for security team on advice for the flatpak TB request
[19:17] <mdeslaur> I asked seth to file a bug: https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1943480
[19:17] <rbasak> Thanks mdeslaur and sarnold!
[19:17] <mdeslaur> 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] <rbasak> Is there anything further for the TB here?
[19:18] <sarnold> mdeslaur: heh, yeah, I wasn't 100% sure we'd reached a consensus yet :(
[19:18] <rbasak> OK how about I leave that action with mdeslaur for now? Or can you relay the security team position now for discussion?
[19:19] <rbasak> 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] <mdeslaur> I'm not sure there's anything more for the TB here
[19:19] <mdeslaur> The TB deferred to the security team
[19:20] <rbasak> OK thanks let's consider the TB part done then, and no further action for the TB.
[19:20] <mdeslaur> It would just circle back is someone disagreed with the security team's decision
[19:20] <mdeslaur> *if
[19:20] <rbasak> 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] <rbasak> I hope everyone did their homework?
[19:20] <mdeslaur> I did spend some time on that page, but I still need to think about it some more
[19:22] <mdeslaur> Can the others go through it before the next meeting, please?
[19:22]  * vorlon nods
[19:22] <sil2100> Will do o/
[19:22] <rbasak> 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] <rbasak> So I'll leave the action for everyone. I certainly need to read mdeslaur's comments in detail.
[19:23] <rbasak> #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] <meetingology> 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] <rbasak> #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] <rbasak> I think this is deferred for now, until the previous item is completed.
[19:23] <rbasak> Any further discussion on this topic?
[19:24] <mdeslaur> nope
[19:24] <rbasak> #topic Scan the mailing list archive for anything we missed (standing item)
[19:24] <rbasak> I screwed that up. Wrong magic symbol :-/
[19:25] <rbasak> Anyway
[19:25] <vorlon> :(
[19:25] <vorlon> :)
[19:25] <vorlon> (also wrong magic symbol)
[19:25] <rbasak> I don't see anything on the ML.
[19:25] <rbasak> #info Nothing spotted on the ML.
[19:25] <rbasak> #topic Check up on community bugs (standing item)
[19:26] <rbasak> #info No currently open community bugs
[19:26] <rbasak> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
[19:26] <rbasak> Next chair will be vorlon. Backup: sil2100
[19:26] <rbasak> #topic AOB
[19:26] <rbasak> AOB?
[19:26] <mdeslaur> I've got none
[19:26] <vorlon> nothing here
[19:27] <rbasak> #endmeeting
[19:27] <meetingology> 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] <rbasak> Thanks all!
[19:27] <mdeslaur> thanks everyone
[19:27]  * rbasak wonders what the previous topci was
[19:27] <sil2100> o/
[19:28] <sil2100> I think this is it?
[19:28] <rbasak> Thank you!