17:58:19 <spwhitton> #startmeeting
17:58:19 <MeetBot> Meeting started Tue Jul 11 17:58:19 2023 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:19 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:58:43 <smcv> for instance I have a MR for debootstrap to make --variant=buildd stop implying --no-merged-usr
17:58:51 <smcv> and I want to check that's not going to break stuff
17:58:55 <spwhitton> #topic Jitsi: brief introduction to new ctte members
17:59:01 <spwhitton> smcv: do join us
17:59:36 <smcv> moment, switching to wired network
18:00:48 <mjg59> Be right there
18:01:18 <helmut> http://subdivi.de/~helmut/dumat.yaml <- ready in time %-)
18:09:06 <tumbleweed> o/
18:09:11 <spwhitton> helmut: I saw a request to speak right before I closed my tab
18:09:17 <spwhitton> helmut: what did you want to raise?
18:09:57 <helmut> private matter done
18:10:01 <spwhitton> ty.
18:10:02 <spwhitton> #topic Roll Call
18:10:08 <spwhitton> Apologies were received from Christoph Berg.
18:10:09 <spwhitton> Sean Whitton
18:10:12 <helmut> Helmut Grohne
18:10:15 <smcv> Simon McVittie
18:10:15 <tumbleweed> Stefano Rivera
18:10:19 <roehling> Timo Röhling
18:10:20 <Emperor> Matthew Vernon
18:11:02 <spwhitton> It is great that we are back up to eight people :)
18:11:05 <spwhitton> #topic Review of previous meeting AIs
18:11:22 <spwhitton> Emperor and I had AIs and completed them.  Is there anything remaining with recruitment etc.?
18:12:50 <mjg59> Matthew Garrett
18:13:19 <spwhitton> sorry, I miscounted the names.
18:13:27 <spwhitton> #topic Updates on merged-/usr from Helmut
18:13:30 <spwhitton> helmut: what do you have for us.
18:14:09 <helmut> We have consensus on the point of view that (for reasons we have disagreement about) we want to move forward without major changes to dpkg
18:14:40 <helmut> We have disagreement on how to fix bootstrapping, but much of that disagreement seems to be based on a misunderstanding that is being sorted out
18:15:22 <helmut> We finally have the promised tool that can diagnose a number of issues relevant to /usr-merge. I intend to mail d-devel@ about that tool soon.
18:15:32 <Emperor> sounds good :)
18:15:34 <spwhitton> Are you hoping to be able to use it to do MBFs?
18:15:35 <helmut> Next month very little will happen from my side. VAC.
18:15:50 <helmut> spwhitton: worse. an automatic rc bug filing service
18:16:00 <helmut> like a continuous mbf
18:16:13 <spwhitton> for every bug you close, it files a random number >1 more bugs?
18:16:17 <helmut> that's what paul Paul Gevers requested
18:16:37 <highvoltage> hopefully, if they can be auto-filed, janitor can auto-fix them :)
18:16:55 <helmut> it is important that we prevent packages with /usr-merge issues from migrating to testing and rather than integrate with britney directly, integrate with the bts
18:17:01 <helmut> highvoltage: not at all :(
18:17:13 <helmut> highvoltage: however hope is that they are rare
18:17:24 <smcv> is this detection of packages that need one of the various mitigations you discussed, or is this detection of packages that are literally doing something unsafe?
18:17:43 <helmut> roughly speaking, in that .yaml file, there are items with what->risky something. those can become real issues and would cause rc bugs then
18:18:06 <helmut> smcv: it's detecting when mitigations are needed
18:18:32 <helmut> smcv: the idea is that we just allow maintainers to move their files and in the (hopefully rare) event that moving not just works, they'll get an rc bug
18:18:41 <spwhitton> helmut: I take it the goal is that once every bug filed on the basis of your tool is closed, we are done with the transition?
18:18:54 <spwhitton> ah no, I see.  it's more reactive than that.
18:19:17 <helmut> yes, we will move files to canonical locations and that probably just works most of the time
18:19:38 <spwhitton> so, when does lifting the morotorium happen?
18:19:40 <helmut> rather than having maintainers pay attention to where it does not, we tell them "upload to experimental first and wait a few days"
18:20:08 <smcv> I'm surprised to see dbus on that list, but I'm hoping its presence with "risky replaces" means "this would become a problem if you canonicalize /lib to /usr/lib" rather than "this is already a problem"?
18:20:08 <helmut> I think the prerequisit here is a) agreeing on a selection of mitigations b) having the automatic bug filing service operational
18:20:16 <mjg59> Once complete, would we have something that would auto-file bugs on any uploads that ship things in / inapropriately?
18:20:24 <highvoltage> helmut: dpkg maintainer is fine with this approach too?
18:20:41 <roehling> smcv: that's exactly what "risky replaces" means AFAIU
18:20:41 <helmut> smcv: indeed. risky means it is not a problem now. risky means that it could become a problem. risky does not receive a bug
18:20:47 <helmut> highvoltage: partially
18:21:13 <helmut> mjg59: good idea, could that be added to lintian?
18:21:43 <smcv> the major limitation of lintian is that it knows nothing about packages that are not the one currently being checked
18:21:59 <smcv> so if your tool needs that knowledge, it can't be a lintian check
18:21:59 <helmut> smcv: risky means: even if you move now, it might not be a problem. however if you then reorganize packages, you may the (much later after you canonicalized files) receive an rc bug
18:22:34 <helmut> smcv: lintian does not need a global view to detect packages shipping stuff in /
18:22:59 <spwhitton> helmut: you probably already had it in mind, but if you are soon writing to -devel about this, it would be good to include a rough timeline for how and when this tool gets the transition closer to finished.
18:23:01 <smcv> sure, I was assuming it would need a broader view to be able to only suggest the safe-ish cases
18:23:18 <smcv> since people have a tendency to do as lintian suggests with no critical thinking
18:23:52 <helmut> spwhitton: difficult. as problems and disagreements pop up, we pushed timeline back repeatedly
18:24:16 <helmut> it's been a while though since new problem classes have surfaced
18:24:35 <roehling> smcv: the lintian check for / sounds most useful once the transition is done and we don't want people to regress accidentally
18:24:47 <smcv> right, that does sound good
18:24:59 <helmut> I think that regression check is one that I should add to dumat anyway
18:25:01 <smcv> or when the transition is say 95% done
18:25:08 <roehling> right
18:25:09 <helmut> it generally assumes that you never move from /usr to /
18:25:22 <helmut> and if you do that, really bad things happen
18:26:16 <tumbleweed> yeah, that's the downside of a lintian check. People will remove things in response
18:26:21 <helmut> I've already done a manual filing for undeclared file conflicts
18:26:29 <tumbleweed> *move
18:26:38 <helmut> a next step is a manual filing of unnecessary empty directories (i.e. delete them rather than protect them)
18:27:12 <spwhitton> so, once there is confidence in the bug filing service, we'll be a big step closer to being able to lift the moratorium
18:27:21 <helmut> yes
18:27:31 <spwhitton> that's great.
18:27:42 <helmut> question from my side:
18:28:07 <helmut> the technical review of DEP17 was quite shallow. I think Simon Richter was one of the deepest, how can we increase that?
18:28:43 <spwhitton> perhaps ask specific people.  e.g. josch.
18:28:47 <helmut> second: the complexity of the bootstrap matter is so bad that basically everyone stopped understanding it. I have no idea how to reduce that complexity, but this essentially leaves us with nobody understanding it
18:29:26 <spwhitton> perhaps just leave it to one side while working on the bug filing service.  after some time, it might appear simpler.
18:29:34 <helmut> it seems we're moving into a space where decisions are more based on feelings and trust as the complexity takes too much toll
18:30:29 <helmut> anything else you want to know about /usr-merge or can we close it?
18:30:38 <spwhitton> nothing from me.
18:30:41 <spwhitton> thank you again.
18:30:50 <smcv> I have a question (for the ctte, not helmut specifically)
18:31:52 <smcv> AIUI, now that trixie development has opened, it's officially no longer a bug for packages to require/assume merged-/usr
18:31:55 <helmut> smcv: regarding dbus, keep in mind that all those risks are for upgrading from bullseye. i.e. that risk is absent in bookworm -> trixie upgrades. the yaml file also contains a noticeable number of "invalid" upgrades (e.g. bullseye -> experimental), so in that sense, there's fpos that won't get bugfilings
18:32:28 <smcv> (pause my question, let's talk about the dumat output for now)
18:33:03 <smcv> are you saying that it would be risky for a future update to dbus *in bullseye* to move its systemd unit from /lib to /usr/lib?
18:33:19 <helmut> smcv: yes, exactly
18:33:46 <smcv> but because that's in the class of change that if I tried it, the stable release managers would just laugh at me
18:33:56 <Emperor> I'd be a bit surprised to see file moves in... what smcv just said
18:33:58 <helmut> exactly
18:33:58 <smcv> it's not actually a practical problem?
18:34:32 <helmut> yes. the file still contains a lot of things that will not be practically broken
18:34:47 <smcv> great, that's what I hoped
18:35:11 <helmut> returning to your question?
18:35:20 <smcv> and similarly, bullseye -> trixie would be listed in dumat.yaml
18:35:43 <smcv> but we consider bullseye -> trixie to be an unsupported upgrade route, you must upgrade to bookworm first (and preferably reboot)
18:35:57 <smcv> so in practice it wouldn't receive a bug?
18:36:04 <helmut> I confirm
18:36:41 <smcv> good. a lot of what we were saying when discussing merged-/usr resolutions was predicated on skipping a release being unsupported
18:36:52 * Emperor looks shifty
18:37:04 <Emperor> (definitely hasn't been doing any skip-upgrades recently, honest)
18:37:19 <helmut> yes. so while the mitigations are really ugly. I hope that we rarely need them and the idea behind dumat is to use them as-needed
18:37:55 <smcv> if a current or former TC member (thinking of another cantabrigian here) can do a skip-upgrade successfully, that doesn't make it supportable :-)
18:38:13 <Emperor> (:
18:38:32 <helmut> you can recover from most of the failures from skip upgrades by reinstalling packages and recreating aliasing symlinks
18:38:42 <highvoltage> I can assure you that skipping an upgrade doesn't get 1% of the testing that a release-to-release upgrade does
18:38:48 <roehling> "most"
18:39:06 <helmut> returning to smcv's question?
18:39:09 <smcv> yes
18:39:32 <spwhitton> smcv: seems worth re-emphasising that skip upgrades are not supported in the release notes for trixie, given merged-/usr.
18:39:38 <smcv> so, officially packages uploaded to exp/sid/trixie are allowed to require/assume merged-/usr now
18:39:49 <Emperor> spwhitton: +1
18:40:28 <smcv> but at the moment, buildds and various QA tools are using unmerged-/usr chroots, to try to mitigate (RC-?)buggy packages
18:40:44 <spwhitton> Emperor, smcv: could I action one of you to file a bug against release-notes about that?
18:41:26 <smcv> I think now is the right time to be removing that mitigation, so I proposed a MR against debootstrap to make --variant=buildd no longer imply --no-merged-usr for >= trixie
18:42:11 <spwhitton> smcv: sounds reasonable to me.
18:42:11 <smcv> and I would like to do similarly for pbuilder, reprotest, piuparts, etc.
18:42:26 <helmut> smcv: I think the change is needed and d-devel didn't disagree with that on multiple mentions, but I also think that depending on the solution to bootstrap we want that other change (swap merge and unpack) included in -pu
18:42:39 <smcv> bluca had been meaning to do similar, and might get there first on some of the non-deboostrap packages
18:43:03 <smcv> but he wanted to make sure not to be jumping the gun and doing something that will be a problem for our (especially helmut's) plans
18:43:27 <Emperor> spwhitton: OK (not offering to write the text, but happy to file a bug)
18:43:48 <smcv> so I wanted to check: does anyone want to veto that, or is there TC consensus that it's OK to go ahead?
18:43:49 <helmut> for that reason, I'd like to not defer that bootstrapping question and have it sorted very soon to be able to include that change. other than this aspect, I think we should go ahead
18:44:33 <helmut> failing that, we need to update debootstrap in -pu twice
18:45:05 <smcv> because helmut raised it: yes this is really two questions: go ahead in sid/trixie, y/n? and backport into stable releases so the production buildds get the change, y/n?
18:45:10 <spwhitton> #action Emperor to file bug against release-notes for trixie, to request reassertion that skip upgrades are not supported
18:45:15 <spwhitton> Emperor: thanks.
18:45:44 <smcv> I agree with helmut, I want to do this in sid and get it migrated into trixie before we even think seriously about a stable backport
18:45:45 <helmut> smcv: I "vote": sid/trixie -> yes+now, -pu -> not yet
18:45:45 <roehling> helmut: would it be feasible to swap unpack and merge anyway, but skip the merge if the top-level symlinks have been created during unpack (implying they were shipped)?
18:46:10 <roehling> no, forget it, won't work
18:46:20 <helmut> roehling: that's what my patch does
18:46:30 <smcv> for debootstrap, we are reasonably sure that helmut's work is going to lead to changes to debootstrap, so it would make sense to batch those changes into one round of -pu
18:46:56 <smcv> although actually I don't think doing two trips through the -pu process would be the worst thing
18:46:58 <spwhitton> sounds like we have consensus on you going ahead with trixie&sid, smcv.
18:47:07 <helmut> smcv: no. we have strong disagreement there. either we patch debootstrap in -pu or we patch cdebootstrap and mmdebstrap in -pu
18:47:48 <smcv> huh, ok. so you're confident that we need to change *something* in -pu, but exactly what is tbd
18:48:02 <spwhitton> it would be good to get the ball rolling with our debconf prep, and I get the sense both smcv and helmut have enough work to be going on with for the immediate future, so shall we move on?
18:48:05 <helmut> smcv: confirmed.
18:48:32 <helmut> would anyone volunteer to chime in on the bootstrap topic on d-devel?
18:48:53 <smcv> ok. I will prepare MRs for trixie/sid only, and ask bluca etc. to do the same (if they get there first) for just now, until what happens in -pu is more settled
18:49:18 <helmut> smcv: should we mail d-release about that?
18:49:40 <spwhitton> helmut: it seems okay to leave bootstrapping aside for now, if no-one volunteers?
18:50:17 <smcv> my instinct is that -release have enough on their collective plate that we should only invoke them if we have something actionable
18:51:03 <helmut> well, it's reactionable
18:51:18 <helmut> rejecting -pu requests ;)
18:51:21 <helmut> ok move on?
18:51:33 <spwhitton> thanks again both.
18:51:37 <spwhitton> #topic DebConf23 presentation
18:52:17 <spwhitton> we can be thinking about doing something new in addition, but for our basic session, the requirements are (i) a ctte member who is at debconf taking point on the opening presentation, & running the bof (ii) updating the slides.
18:52:24 <smcv> as usual I'm not going to be at debconf but can join remotely if that's a thing we're doing
18:52:27 <spwhitton> I can do (ii) unless someone particularly wants to.
18:52:33 <mjg59> I'm not going to be physically present but yes what smcv said
18:52:35 <spwhitton> Is there someone who would like to do (i)?  I am not going.
18:52:53 * Emperor is not going to be present
18:53:02 * roehling neither
18:53:18 * tumbleweed will be there
18:53:33 <spwhitton> helmut: will you be there?
18:53:37 <spwhitton> and does anyone know about Christoph?
18:53:42 <helmut> not there
18:54:25 <spwhitton> okay so Stefano and possibly Christoph is it.
18:54:36 <Emperor> well volunteered ;-)
18:54:40 <tumbleweed> :P
18:54:49 <roehling> \o/ yay tumbleweed :)
18:54:51 <tumbleweed> yeah, so I guess I'll take point i
18:54:51 <helmut> I'll plan physical presence for 2024
18:55:08 <spwhitton> tumbleweed: it's a lot to ask you to do this just a couple of months after joining the committee.  one option is that we run it as a mostly remote presentation?  but, for a bof, that's less good.
18:55:32 <tumbleweed> yeah, if someone wants to present remotely we can do it
18:55:55 <tumbleweed> otherwise, I'm happy to do it but I obviously won't have as much context as a long-timer
18:56:26 <spwhitton> well, I guess that if Myon does go then you could do it jointly, as the only two people there
18:57:12 <spwhitton> tumbleweed: as you are a debconf person could you perhaps co-ordinate getting everyone's names on the presentation?
18:57:20 <spwhitton> as co-presenters, I mean.
18:57:32 <tumbleweed> smcv, Myon, mjg59: If you sign up to the website I can add you as co-presenters
18:57:38 <spwhitton> nice.
18:57:43 <spwhitton> #action spwhitton to update the debconf slides
18:57:52 <spwhitton> #action tumbleweed to ensure we're all co-presenters on the session
18:58:04 <spwhitton> #info tumbleweed will lead the BoF as the only in-person confirmed attendee
18:58:32 <spwhitton> we can all think about anything extra or special we might want to do this year, or topics we want to ask the bof participants to help us brainstorm
18:58:46 <spwhitton> but I think that's it fo rnow.  thank you for volunteering, tumbleweed.
18:58:49 <spwhitton> #topic Any Other Business
18:58:55 <helmut> dd
18:58:56 <spwhitton> does anyone have anything?
18:59:26 <spwhitton> tumbleweed, roehling: typically we mention any disagreements that we are aware of that might eventually end in a TC bug.
18:59:28 <helmut> sorry, ssh died. I'll probably not make it next meeting
18:59:42 <spwhitton> helmut: thanks for letting us know.
18:59:55 <Emperor> nothing from me
19:00:56 <tumbleweed> nothing on my randar
19:01:05 <tumbleweed> *radar
19:01:07 <roehling> me neither
19:01:15 <helmut> I hope the ifupdown thing sorts well
19:02:15 <roehling> oh right, the dhcp client thing
19:02:31 * Emperor going to have to vanish pretty soon, we're past the hour
19:02:31 <spwhitton> mm.
19:02:36 <spwhitton> #endmeeting