| === nkshirsa_ is now known as nkshirsa | ||
| cpaelzer | o/ | 14:31 |
|---|---|---|
| jbicha | o/ | 14:31 |
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 14:31 |
| meetingology | Meeting started at 14:31:54 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:31 |
| eslerm | o/ | 14:31 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:31 |
| sarnold | good morning | 14:31 |
| cpaelzer | Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) | 14:32 |
| slyon | o/ | 14:32 |
| cpaelzer | #topic current component mismatches | 14:32 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 14:32 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:32 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:32 |
| joalif | o/ | 14:32 |
| cpaelzer | To keep things in consumable chunks the first 6 of the perl deps for spamassassin are now up | 14:32 |
| cpaelzer | see the red color | 14:32 |
| dviererbe | o/ | 14:32 |
| cpaelzer | we'll get to that when assigning new MIR cases for review | 14:32 |
| cpaelzer | nvmse-stas was considerd ready, but waiting dor dasbus | 14:32 |
| cpaelzer | which is on security atm | 14:33 |
| cpaelzer | nothing else new here AFAICS | 14:33 |
| cpaelzer | even nothing new in proposed | 14:34 |
| cpaelzer | which feels right given we are in feature freeze | 14:34 |
| slyon | libei is now ready for security, too (but also some TODOs for jbicha) | 14:34 |
| cpaelzer | good to know | 14:34 |
| sarnold | now I wonder about the flood of FFEs :) | 14:34 |
| jbicha | 👍 | 14:34 |
| cpaelzer | dracut also is ok, will enter security later on (for next cycle) | 14:34 |
| cpaelzer | but for now we agreed on a package splitting that allows to pass just a minimal thing without | 14:35 |
| slyon | nice! | 14:35 |
| cpaelzer | it is back on bdrung to get this in place | 14:35 |
| slyon | ACK | 14:35 |
| cpaelzer | #topic New MIRs | 14:35 |
| cpaelzer | Mission: ensure to assign all incoming reviews for fast processing | 14:35 |
| 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:35 |
| cpaelzer | uh wow 10 | 14:36 |
| cpaelzer | so much for "not much because of FF" | 14:36 |
| cpaelzer | but as I said | 14:36 |
| cpaelzer | 6 of them are meant to be trivial perl cases | 14:36 |
| cpaelzer | back in the day they almost got no review, that isn't how we should do it again | 14:36 |
| cpaelzer | but really, structurally they are mostly a mechanical repack of the perl modules | 14:36 |
| cpaelzer | with auto-autopkgtest and usually good test sets | 14:36 |
| cpaelzer | with small and well defined use cases | 14:37 |
| sarnold | being on the hotpath for handling email they deserve a reasonable look | 14:37 |
| cpaelzer | So I'd wonder if we can distribute those to just one person as they'd all feel very similar | 14:37 |
| sarnold | lintian modules are something else | 14:37 |
| cpaelzer | indeed | 14:37 |
| cpaelzer | I was just going there sarnold | 14:37 |
| cpaelzer | It will not be no review, but by structurally sharing that much there likely would be a huge efficiency gain by one doing them all | 14:38 |
| cpaelzer | that is what I wanted to say :-) | 14:38 |
| sarnold | that makes sense, yes | 14:38 |
| cpaelzer | so I'm looking for a volunteer for 6xsupposed-to-be-simple cases | 14:38 |
| slyon | I could probably take 2-3 of those for next week, assuming they are small. But probably not all of them | 14:38 |
| joalif | I can also take some | 14:38 |
| cpaelzer | it is actually 8, so how about 4 each but no complaining stares if not all of them are done next week? | 14:39 |
| slyon | +1 | 14:39 |
| joalif | sure | 14:39 |
| cpaelzer | assigned | 14:40 |
| bdrung | cpaelzer, I just uploaded dracut 059-4ubuntu2 that splits out dracut-install. Should I assign the ticket back to you? | 14:41 |
| cpaelzer | update the bug, set it back to new and unassign yourself | 14:41 |
| cpaelzer | bdrung: ^^ | 14:41 |
| cpaelzer | and I guess make the seed or dependency change that will pull it in | 14:42 |
| cpaelzer | once all is in place ping one from the team here to ack for the promotion of dracut-install | 14:42 |
| bdrung | thanks. I am working on the initramfs-tools change now. | 14:42 |
| cpaelzer | we'll set the state to "in progress" reflecting that | 14:42 |
| cpaelzer | Then subscribe ubuntu archive admins to do the promotion | 14:42 |
| cpaelzer | ok | 14:43 |
| cpaelzer | ok, in terms of reviews two more to g | 14:43 |
| cpaelzer | go | 14:43 |
| cpaelzer | I'll take gnome-clocks, because why not | 14:43 |
| cpaelzer | leaved https://bugs.launchpad.net/ubuntu/+source/pappl-retrofit/+bug/2031814 unassigned | 14:43 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2031814 in pappl-retrofit (Ubuntu) "[MIR] pappl-retrofit" [Undecided, New] | 14:43 | |
| cpaelzer | missing didier who is out atm | 14:43 |
| cpaelzer | we have assigned more than we commted to be able to do each week (due to those perly things) | 14:44 |
| cpaelzer | so I think this one has to wait | 14:44 |
| cpaelzer | s/commted/committed/ | 14:44 |
| slyon | I agree | 14:44 |
| cpaelzer | and of course this is a late "needs to be in 23.10" *sigh* | 14:45 |
| cpaelzer | but still we are humans and have plenty of other tasks | 14:45 |
| cpaelzer | I think that is ok, re-eval next week | 14:45 |
| cpaelzer | #topic Incomplete bugs / questions | 14:45 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 14:45 |
| 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:45 |
| cpaelzer | dracut was clarified above | 14:45 |
| cpaelzer | s390x-tools and rust has gotten a block-proposed update | 14:46 |
| cpaelzer | most recent actual change is https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531 | 14:46 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2023531 in dotnet6 (Ubuntu) "[MIR] dotnet6" [Undecided, Incomplete] | 14:46 | |
| cpaelzer | hmm, that is a response to the review | 14:46 |
| cpaelzer | I need to read that with some time | 14:46 |
| cpaelzer | since I've done the review | 14:46 |
| cpaelzer | opic Process/Documentation improvements | 14:47 |
| cpaelzer | Mission: Review pending process/documentation pull-requests or issues | 14:47 |
| cpaelzer | #link https://github.com/canonical/ubuntu-mir/pulls | 14:47 |
| cpaelzer | #link https://github.com/canonical/ubuntu-mir/issues | 14:47 |
| dviererbe | Greet new contributers on first issue/pr #37 https://github.com/canonical/ubuntu-mir/pull/37 | 14:47 |
| -ubottu:#ubuntu-meeting- Pull 37 in canonical/ubuntu-mir "Greet new contributers on first issue/pr" [Open] | 14:47 | |
| cpaelzer | that is a nice idea, but also so new the tests didn't run yet right? | 14:48 |
| dviererbe | Github queue seems to be long today, the Ci was just not run yet | 14:48 |
| cpaelzer | I generally like this idea | 14:49 |
| slyon | Maybe s/GMT/UTC/, otherwise lgtm. | 14:49 |
| cpaelzer | where you able to pre-test this somehow dviererbe? | 14:49 |
| dviererbe | Kind of yes here: https://github.com/canonical/ubuntu-mir/actions/runs/5939665817/job/16106543321 but I oriented myself on the config of other repos that used the action | 14:50 |
| cpaelzer | ok, nice | 14:50 |
| dviererbe | https://grep.app/search?q=%20%20%20%20%20%20uses%3A%20actions/first-interaction%40v1 | 14:50 |
| slyon | dviererbe: do we need to install the "secrets.GITHUB_TOKEN" somehow? | 14:50 |
| cpaelzer | how about this - fix the GMT/UTC and allow time to pass for any potential further reviewers | 14:51 |
| dviererbe | No this is a environment variable that gets injected by the action runner | 14:51 |
| cpaelzer | then we can land once tests also have ran e.g. in next weeks meeting | 14:51 |
| slyon | ok | 14:51 |
| dviererbe | Than I also should replace it in the Readme.md | 14:51 |
| dviererbe | Thats where I took it from | 14:51 |
| cpaelzer | is that what we have oO | 14:52 |
| cpaelzer | let me look at the invite what TZ we have set for real | 14:52 |
| slyon | well.. yeah. It's more of a nitpick. We can also keep it as-is. | 14:52 |
| cpaelzer | it is actually "4.30pm CET" | 14:52 |
| slyon | cpaelzer: I think giving the real TZ make sense, as that would account for time shifts | 14:52 |
| cpaelzer | how about chaning .md and this to that value | 14:52 |
| dviererbe | https://github.com/canonical/ubuntu-mir/blob/bb1087152706f72aa0c535a20dde5c72a442033b/README.md?plain=1#L1073 | 14:52 |
| sarnold | hah, it's in there twice | 14:52 |
| cpaelzer | so that git matches the calendar | 14:52 |
| sarnold | (Tuesdays 15:30-16:00 GMT) near the end | 14:52 |
| dviererbe | I change it | 14:53 |
| sarnold | 2023-08-22 14:52:58 < sarnold> (Tuesdays 15:30-16:00 GMT) near the end | 14:53 |
| cpaelzer | well and this PR, other than adding the nice welcome | 14:53 |
| sarnold | funny enough, that second one is just plain wrong part of the year :) | 14:53 |
| cpaelzer | could sync all those mentions with the calendar entry we have | 14:53 |
| cpaelzer | dviererbe: ok with that? | 14:53 |
| dviererbe | Yes :) | 14:53 |
| cpaelzer | next is https://github.com/canonical/ubuntu-mir/pull/36 | 14:54 |
| -ubottu:#ubuntu-meeting- Pull 36 in canonical/ubuntu-mir "Add an ask about isolation features" [Open] | 14:54 | |
| sarnold | woot, thanks dviererbe :) | 14:54 |
| cpaelzer | which we had some approval when discussing | 14:54 |
| cpaelzer | but now have PR actually writing about it | 14:54 |
| cpaelzer | no need to read it now | 14:54 |
| cpaelzer | but before next week an ack or feedback would be nice | 14:54 |
| cpaelzer | ok? | 14:54 |
| sarnold | ack | 14:54 |
| cpaelzer | ok, the rest is old/draft | 14:54 |
| cpaelzer | #topic MIR related Security Review Queue | 14:55 |
| cpaelzer | Mission: Check on progress, do deadlines seem doable? | 14:55 |
| cpaelzer | Some clients can only work with one, some with the other escaping - the URLs point to the same place. | 14:55 |
| cpaelzer | #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 | 14:55 |
| cpaelzer | #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 | 14:55 |
| cpaelzer | Internal link | 14:55 |
| cpaelzer | - ensure your teams items are prioritized among each other as you'd expect | 14:55 |
| cpaelzer | - ensure community requests do not get stomped by teams calling for favors too much | 14:55 |
| cpaelzer | #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 | 14:55 |
| cpaelzer | never heard of semgrep_rules_manager | 14:55 |
| cpaelzer | why is that in this kanban board at all? | 14:55 |
| eslerm | I'll add libei to our jira board | 14:55 |
| cpaelzer | thanks eslerm | 14:55 |
| cpaelzer | about dracut | 14:56 |
| cpaelzer | while we split things out and promote a very small subset now | 14:56 |
| cpaelzer | this would also want to be added to the security board tracking | 14:56 |
| cpaelzer | even not yet being assigned to you on the bug | 14:56 |
| cpaelzer | that is https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2031304 | 14:56 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2031304 in dracut (Ubuntu) "[MIR] dracut" [Undecided, Incomplete] | 14:56 | |
| cpaelzer | would you be able to add that as well? | 14:56 |
| eslerm | can do | 14:56 |
| cpaelzer | the rest looks kind of "as expected" | 14:56 |
| cpaelzer | heif and siblings to fully complete soon or 24.04 the ltest | 14:57 |
| cpaelzer | stuff in progress | 14:57 |
| cpaelzer | all good AFAICS | 14:57 |
| cpaelzer | keeping time in mind let me call for | 14:57 |
| cpaelzer | #topic Any other business? | 14:57 |
| sarnold | none here | 14:57 |
| eslerm | heif had a block last week, let me find it | 14:57 |
| slyon | eslerm: I added some update comments to the heif related MIRs | 14:57 |
| slyon | pfsmorigo: I was wondering about the state of cargo? | 14:58 |
| eslerm | ack, thanks I'll follow up | 14:58 |
| cpaelzer | I didn't want to ask about cargo given the time, but you are right to do so ... :-/ | 14:58 |
| eslerm | Seth, can you answer for Paulo please | 14:58 |
| sarnold | slyon: pfsmorigo has written a report on it, and I've not yet had the time to read his report :( | 14:59 |
| slyon | sarnold: can we see that report somewhere, or is it still internal? | 14:59 |
| sarnold | slyon: yeah I could bounce you a copy | 14:59 |
| slyon | that be great, thanks | 14:59 |
| slyon | nothing else from my side | 15:00 |
| cpaelzer | next meeting is starting and nothing else | 15:00 |
| sarnold | eek thanks for the 'next meeting' reminder | 15:00 |
| sarnold | I swear if my head weren't bolted on.. | 15:00 |
| cpaelzer | hehe | 15:00 |
| dviererbe | :D | 15:00 |
| cpaelzer | thanks | 15:01 |
| cpaelzer | see you all | 15:01 |
| cpaelzer | #endmeeting | 15:01 |
| meetingology | Meeting ended at 15:01:07 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-08-22-14.31.moin.txt | 15:01 |
| eslerm | thanks all o/ | 15:01 |
| dviererbe | thanks everyone! | 15:01 |
| slyon | thanks all! o/ | 15:01 |
| dviererbe | o/ | 15:01 |
| joalif | thanks all! | 15:01 |
| * vorlon waves | 18:55 | |
| vorlon | https://wiki.ubuntu.com/TechnicalBoardAgenda says 'next meeting 7/25', have we missed all the meetings since then? | 18:56 |
| rbasak | o/ | 19:00 |
| amurray | o/ | 19:00 |
| rbasak | No meetings until July 2025? :-) | 19:00 |
| seb128 | checking irclog it seems the 7/25 - 8/8 ones didn't have quorums | 19:00 |
| vorlon | then I guess rbasak is chair today | 19:02 |
| rbasak | #startmeeting Technical Board | 19:02 |
| meetingology | Meeting started at 19:02:12 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:02 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:02 |
| rbasak | #topic Action Items | 19:02 |
| rbasak | ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:02 |
| rbasak | I've seen some text. Is that ready? | 19:02 |
| seb128 | hum | 19:04 |
| seb128 | do we need Ken to reply to your comments? | 19:05 |
| rbasak | There are some comments, and also I've seen a suggestion from timhm to drop the current use of the branches that auto-close. | 19:05 |
| rbasak | I pinged timhm but he's only back from PTO today. | 19:05 |
| vorlon | fwiw the text there is different than the original rationale for the ubuntu-YY.MM tracks | 19:05 |
| rbasak | I was going to ping Ken today but I found that he's out for a few days too | 19:05 |
| rbasak | > The complete channel name can be structured as three distinct parts separated by slashes: | 19:06 |
| rbasak | > <track>/<risk>/<branch> | 19:06 |
| vorlon | i.e. they weren't intended to be a committment to "bugfix+security only changes", they were only intended to be an escape hatch if there was a per-release regression due to integration issues | 19:06 |
| rbasak | Currently I believe we're using *branch* | 19:06 |
| rbasak | Which autocloses after 30 days | 19:06 |
| vorlon | ah | 19:06 |
| rbasak | "Requirement B: Ubuntu developers will be able to override and patch the package" | 19:07 |
| vorlon | yes, sorry, I assumed this was referring to the stuff we were currently using and second-guessed myself on track vs branch :) | 19:07 |
| rbasak | That would be fulfilled by the current use of the branch I think. | 19:07 |
| rbasak | And is sort of similar to the escape hatch rationale you mention but not quite the same. | 19:07 |
| seb128 | the current use is to set our snap to follow stable/ubuntu-<xx.yy> right? | 19:07 |
| vorlon | right | 19:07 |
| seb128 | so that means following stable | 19:07 |
| seb128 | but what we would like is rather to follow a serie specific track | 19:08 |
| vorlon | "we would like" - who would like that and why? | 19:08 |
| seb128 | like for GNOME 45 we should set mantic to follow 45/ stable | 19:09 |
| seb128 | 45/stable | 19:09 |
| seb128 | well, if the goal is to have a behaviour similar to what we have today with debs | 19:09 |
| rbasak | I think that would be fine | 19:09 |
| seb128 | following latest/stable would mean mantic users would get GNOME 46 updates when those are flagged stable | 19:10 |
| rbasak | But it would need to be 45/stable/ubuntu-24.04 or similar | 19:10 |
| amurray | the reason I suggested tracks rather than branches is to avoid the issue of branches auto-closing - and the reason I put in the bug/security fixes only is to try and have the same expectation for snaps as debs from an end-users perspective | 19:10 |
| rbasak | So using <branch> like we already do, but also adding <track>. | 19:10 |
| rbasak | amurray: so I think the pushback from the store admins would be that this overloads the purpose of tracks and the idea that snaps are supposed to be distro-agnostic. | 19:11 |
| rbasak | AIUI, there was a similar resistance to using branches in this way, but it did end up happening. | 19:11 |
| rbasak | There's another important behaviour to keep in mind here. | 19:11 |
| rbasak | snapd can "track" firefox latest/stable/ubuntu-22.04 for example, but if that doesn't exist, then it just falls back to use "latest/stable" instead. | 19:12 |
| vorlon | 45 is not an Ubuntu version, of course. If we are using tracks based on the versioning of the application upstream, that will cause more work on the Ubuntu side to keep track of the tracks; if we wanted consistency on the Ubuntu side to always use tracks such as ubuntu-23.10/stable (the current suggested text?) that puts more work on the snap publisher | 19:12 |
| rbasak | Replace "latest" with a track if you like. | 19:12 |
| rbasak | So we don't usually have to publish to the branch, so auto-closing isn't much of a concern in practice. | 19:12 |
| rbasak | If we used the escape hatch, _only then_ would we need to make sure we keep republishing within 30 days, or see about changing that feature. | 19:13 |
| vorlon | fwiw firefox has been using the branches | 19:13 |
| vorlon | as has subiquity | 19:13 |
| rbasak | On this machine I have: | 19:13 |
| rbasak | tracking: latest/stable/ubuntu-22.04 | 19:13 |
| vorlon | just in case anyone thought this was a vestigial feature | 19:13 |
| rbasak | Oh yes and my revno is different from the channels that are publicly visible. | 19:14 |
| amurray | yep but I thought there was pushback from the desktop team that they found it onerous that the branches autoclose | 19:14 |
| rbasak | To make progress with the doc in general, I suggest that we document what we're currently doing, and make sure that before we change what we're doing everyone involved reaches consensus first? | 19:14 |
| amurray | it sounds like we are choosing between two problems - either we use branches and that puts the burden on the publisher to keep publishing else they auto-close - or we use tracks which gets pushback from the store team..? | 19:15 |
| vorlon | amurray: well, I think that's a valid objection and maybe worth revisiting with the store team? but for this discussion, wrt track naming I'll point out that a firefox upstream version would not be suitable for the track if you wanted it to be different for 22.04 and 23.04 | 19:15 |
| vorlon | why would the store team push back on the use of tracks? | 19:16 |
| rbasak | AIUI, they don't want Ubuntu-specific tracks. The store is supposed to be distro-agnostic, so the tracks should be what makes sense to the upstream. | 19:17 |
| vorlon | ok | 19:17 |
| vorlon | then tracks are unsuitable for firefox | 19:17 |
| vorlon | because the differences between the snaps on the different branches right now are about base+content snap, not upstream version branches | 19:18 |
| rbasak | I don't mind how this is implemented, but I think that our base requirements are reasonable and the snap ecosystem needs to be able to figure out how to support them :-/ | 19:18 |
| vorlon | the store team doesn't want to accomodate branches that don't auto-close, but nothing says that the publishers can't set up timers to auto-refresh those branches and keep them open | 19:19 |
| vorlon | but, as rbasak points out, the implementation is not really a TB question | 19:20 |
| vorlon | wrt this point on the agenda, it doesn't seem we're ready to close anything out? | 19:21 |
| rbasak | Agreed. | 19:21 |
| rbasak | But can we agree on next steps? | 19:21 |
| amurray | same | 19:21 |
| rbasak | I had a suggestion on that bove | 19:21 |
| vorlon | "document what we're doing" - +1 from me | 19:22 |
| seb128 | +1 | 19:22 |
| rbasak | Could someone who understands exactly what we're doing please take that action? :) | 19:22 |
| vorlon | I think seb128 is best positioned | 19:23 |
| seb128 | alright :p | 19:23 |
| rbasak | OK so let's carry the action | 19:23 |
| rbasak | #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:23 |
| meetingology | ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:23 |
| rbasak | ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:23 |
| rbasak | I'll carry this over again | 19:24 |
| rbasak | #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:24 |
| meetingology | ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:24 |
| rbasak | (I'm not aware for any reason for this to be a priority right now) | 19:24 |
| rbasak | ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps | 19:24 |
| rbasak | Hmm. I don't remember this. | 19:24 |
| vorlon | IIRC there was a question about what should be required wrt test plans for seeded snaps, vs. the MIR requirements for autopkgtests | 19:25 |
| rbasak | Just found the logs | 19:26 |
| rbasak | OK looks like I knew the details once, so I'll carry that over and I don't think I'm blocked | 19:26 |
| rbasak | #action rbasak to follow up on finding consensus on question of test plans for third party apps | 19:26 |
| meetingology | ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps | 19:26 |
| rbasak | ACTION: rbasak to restructure the third-party repo doc to make the status clearer | 19:26 |
| rbasak | This one's done I think? | 19:26 |
| rbasak | ACTION: rbasak to open wider discussion on third-party repo policy | 19:26 |
| rbasak | I started writing up a post for a call for wider discussion and feedback. | 19:27 |
| rbasak | I feel a little blocked on a comment from Ken in the doc. I intend to follow up with him his week or next week after he's back from PTO. | 19:27 |
| rbasak | #action rbasak to open wider discussion on third-party repo policy | 19:27 |
| meetingology | ACTION: rbasak to open wider discussion on third-party repo policy | 19:27 |
| rbasak | ACTION: seb128 to follow up 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 | 19:27 |
| seb128 | carry over please | 19:28 |
| rbasak | #action seb128 to follow up 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 | 19:28 |
| meetingology | ACTION: seb128 to follow up 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 | 19:28 |
| rbasak | #topic Packages in the archive that download and run software from the Internet, and third-party repository requirements | 19:28 |
| rbasak | (vorlon) | 19:28 |
| vorlon | hi | 19:28 |
| vorlon | the reason I put this on the agenda was that I happened to just notice that the lutris package in multiverse downloads software from possibly arbitrary locations on the Internet to be run | 19:29 |
| vorlon | and I think that's bad and was going to dig into it to see just how bad and whether it should be thrown out of the archive | 19:29 |
| vorlon | and then I realized I didn't have a written policy on this stuff that I could point to | 19:30 |
| rbasak | I'm reminded of flashplugin-downloader or whatever it was called | 19:30 |
| rbasak | Also torbrowser-launcher | 19:30 |
| vorlon | flashplugin-downloader at least had the constraints that it would only download files with known hashes that were embedded in the packaging | 19:30 |
| rbasak | That one's in universe. | 19:30 |
| vorlon | the fact that it downloaded at install time rather than shipping in the package was a concession to redistribution constraints | 19:31 |
| amurray | hmm is this a slippery slope? we also have say emacs which can be configured to download emacs lisp packages from arbitrary locations | 19:31 |
| amurray | (just as an example) | 19:31 |
| rbasak | I was going to point at wget :-P | 19:31 |
| vorlon | heh | 19:31 |
| seb128 | or you can download anything to install from a webbrowser... | 19:31 |
| rbasak | So, where's the line? | 19:32 |
| rbasak | Does being in multiverse make it OK? | 19:32 |
| amurray | does lutris do any sandboxing internally? perhaps if it did then that would lessen the risk here | 19:34 |
| vorlon | well lutris is effectively a package shipping a "store" for third-party games from the Internet | 19:34 |
| rbasak | Sounds like the flatpak package :-P | 19:35 |
| rbasak | (although it doesn't default to a store I don't think!) | 19:35 |
| rbasak | So snapd | 19:35 |
| vorlon | well, right, and clearly we have expectations about what the snapd package should present as a store :) | 19:35 |
| rbasak | One could argue that a user understands that installing lutris opts them in to a specific store | 19:36 |
| vorlon | the bit that irked me was actually watching it download a mame tarball from the Internet when we have mame as a deb | 19:36 |
| vorlon | rbasak: I don't think our users should be expected to assess the security design of every store someone puts in the Debian or Ubuntu archive as a deb and that we should have some common guidelines | 19:37 |
| vorlon | does lutris have cryptographic verification of the games it downloads from the Internet? is that based on ssl or on some sort of signing of a store payload? who manages that? is there sandboxing? etc | 19:38 |
| rbasak | lutris is synced from Debian though? | 19:38 |
| amurray | common guidelines sound reasonable | 19:38 |
| rbasak | So while I understand your concern and would like to see improvement there, I'm not sure we could really be effective unless Debian is also doing it, so it seems like we would need consensus in Debian | 19:39 |
| rbasak | OTOH the other stuff involving third party requierements are mostly Ubuntu-specific differences | 19:39 |
| rbasak | Like we might as well document "if Debian do it then it's acceptable for Ubuntu by default because autosync" in our doc | 19:40 |
| vorlon | well even if there is a policy we'd likely be playing whack-a-mole for a while in either Debian or Ubuntu | 19:40 |
| vorlon | I would still like to see some documented principles of what we expect from packages in the Ubuntu archive | 19:40 |
| rbasak | I have no objection to having the TB endorse something like that. | 19:40 |
| vorlon | (btw lutris actually completely failed to download and install the game I was trying to get running on my kid's system, and I wound up grabbing a zip file of the DOS program and running it directly under dosbox :P) | 19:41 |
| rbasak | vorlon: would you like an action to write some guidelines? | 19:41 |
| vorlon | rbasak: sounds like you're suggesting .. ^ that :) | 19:41 |
| vorlon | yes | 19:41 |
| rbasak | #action vorlon to write up draft guidelines for packages in the archive that download from the Internet | 19:42 |
| meetingology | ACTION: vorlon to write up draft guidelines for packages in the archive that download from the Internet | 19:42 |
| rbasak | ^ that wording is deliberately open. You can figure out how to define the scope when you write it up :) | 19:42 |
| rbasak | Any further discussion on this topic? | 19:42 |
| vorlon | fwiw I think there's other historical precedent of e.g. disabling browser plugin stores by default in browsers | 19:43 |
| vorlon | or of disabling vendor auto-update mechanisms | 19:43 |
| rbasak | This will be quite slippery to define I think. | 19:43 |
| vorlon | all related :) | 19:43 |
| vorlon | yep. challenge accepted, thanks | 19:43 |
| rbasak | #topic Scan the mailing list archive for anything we missed (standing item) | 19:43 |
| rbasak | #info No recent ML posts | 19:44 |
| rbasak | #topic Check up on community bugs and techboard bugs | 19:44 |
| rbasak | #info No new bugs; existing bugs are all being handled through existing action items | 19:44 |
| rbasak | #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) | 19:45 |
| rbasak | #info Next chair will be seb128 with vorlon as backpu | 19:45 |
| rbasak | #indo | 19:45 |
| rbasak | #undo | 19:45 |
| meetingology | Removing item from minutes: INFO | 19:45 |
| rbasak | #info Next chair will be seb128 with vorlon as backup | 19:45 |
| seb128 | ack | 19:45 |
| * vorlon nods | 19:45 | |
| rbasak | #topic AOB | 19:45 |
| rbasak | Anything else from anyone? | 19:46 |
| vorlon | nothing here | 19:46 |
| rbasak | #endmeeting | 19:46 |
| meetingology | Meeting ended at 19:46:35 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-08-22-19.02.moin.txt | 19:46 |
| rbasak | Thanks all! | 19:46 |
| seb128 | thanks! | 19:46 |
| vorlon | fwiw I'm going to have another request to twiddle the weeks due to my availability changing again, but that's not until after the next meeting | 19:46 |
| rbasak | ack | 19:46 |
| vorlon | thanks! | 19:46 |
| amurray | thanks for chairing rbasak | 19:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
