17:58:19 #startmeeting 17:58:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:43 for instance I have a MR for debootstrap to make --variant=buildd stop implying --no-merged-usr 17:58:51 and I want to check that's not going to break stuff 17:58:55 #topic Jitsi: brief introduction to new ctte members 17:59:01 smcv: do join us 17:59:36 moment, switching to wired network 18:00:48 Be right there 18:01:18 http://subdivi.de/~helmut/dumat.yaml <- ready in time %-) 18:09:06 o/ 18:09:11 helmut: I saw a request to speak right before I closed my tab 18:09:17 helmut: what did you want to raise? 18:09:57 private matter done 18:10:01 ty. 18:10:02 #topic Roll Call 18:10:08 Apologies were received from Christoph Berg. 18:10:09 Sean Whitton 18:10:12 Helmut Grohne 18:10:15 Simon McVittie 18:10:15 Stefano Rivera 18:10:19 Timo Röhling 18:10:20 Matthew Vernon 18:11:02 It is great that we are back up to eight people :) 18:11:05 #topic Review of previous meeting AIs 18:11:22 Emperor and I had AIs and completed them. Is there anything remaining with recruitment etc.? 18:12:50 Matthew Garrett 18:13:19 sorry, I miscounted the names. 18:13:27 #topic Updates on merged-/usr from Helmut 18:13:30 helmut: what do you have for us. 18:14:09 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 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 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 sounds good :) 18:15:34 Are you hoping to be able to use it to do MBFs? 18:15:35 Next month very little will happen from my side. VAC. 18:15:50 spwhitton: worse. an automatic rc bug filing service 18:16:00 like a continuous mbf 18:16:13 for every bug you close, it files a random number >1 more bugs? 18:16:17 that's what paul Paul Gevers requested 18:16:37 hopefully, if they can be auto-filed, janitor can auto-fix them :) 18:16:55 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 highvoltage: not at all :( 18:17:13 highvoltage: however hope is that they are rare 18:17:24 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 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 smcv: it's detecting when mitigations are needed 18:18:32 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 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 ah no, I see. it's more reactive than that. 18:19:17 yes, we will move files to canonical locations and that probably just works most of the time 18:19:38 so, when does lifting the morotorium happen? 18:19:40 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 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 I think the prerequisit here is a) agreeing on a selection of mitigations b) having the automatic bug filing service operational 18:20:16 Once complete, would we have something that would auto-file bugs on any uploads that ship things in / inapropriately? 18:20:24 helmut: dpkg maintainer is fine with this approach too? 18:20:41 smcv: that's exactly what "risky replaces" means AFAIU 18:20:41 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 highvoltage: partially 18:21:13 mjg59: good idea, could that be added to lintian? 18:21:43 the major limitation of lintian is that it knows nothing about packages that are not the one currently being checked 18:21:59 so if your tool needs that knowledge, it can't be a lintian check 18:21:59 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 smcv: lintian does not need a global view to detect packages shipping stuff in / 18:22:59 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 sure, I was assuming it would need a broader view to be able to only suggest the safe-ish cases 18:23:18 since people have a tendency to do as lintian suggests with no critical thinking 18:23:52 spwhitton: difficult. as problems and disagreements pop up, we pushed timeline back repeatedly 18:24:16 it's been a while though since new problem classes have surfaced 18:24:35 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 right, that does sound good 18:24:59 I think that regression check is one that I should add to dumat anyway 18:25:01 or when the transition is say 95% done 18:25:08 right 18:25:09 it generally assumes that you never move from /usr to / 18:25:22 and if you do that, really bad things happen 18:26:16 yeah, that's the downside of a lintian check. People will remove things in response 18:26:21 I've already done a manual filing for undeclared file conflicts 18:26:29 *move 18:26:38 a next step is a manual filing of unnecessary empty directories (i.e. delete them rather than protect them) 18:27:12 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 yes 18:27:31 that's great. 18:27:42 question from my side: 18:28:07 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 perhaps ask specific people. e.g. josch. 18:28:47 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 perhaps just leave it to one side while working on the bug filing service. after some time, it might appear simpler. 18:29:34 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 anything else you want to know about /usr-merge or can we close it? 18:30:38 nothing from me. 18:30:41 thank you again. 18:30:50 I have a question (for the ctte, not helmut specifically) 18:31:52 AIUI, now that trixie development has opened, it's officially no longer a bug for packages to require/assume merged-/usr 18:31:55 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 (pause my question, let's talk about the dumat output for now) 18:33:03 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 smcv: yes, exactly 18:33:46 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 I'd be a bit surprised to see file moves in... what smcv just said 18:33:58 exactly 18:33:58 it's not actually a practical problem? 18:34:32 yes. the file still contains a lot of things that will not be practically broken 18:34:47 great, that's what I hoped 18:35:11 returning to your question? 18:35:20 and similarly, bullseye -> trixie would be listed in dumat.yaml 18:35:43 but we consider bullseye -> trixie to be an unsupported upgrade route, you must upgrade to bookworm first (and preferably reboot) 18:35:57 so in practice it wouldn't receive a bug? 18:36:04 I confirm 18:36:41 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 (definitely hasn't been doing any skip-upgrades recently, honest) 18:37:19 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 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 (: 18:38:32 you can recover from most of the failures from skip upgrades by reinstalling packages and recreating aliasing symlinks 18:38:42 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 "most" 18:39:06 returning to smcv's question? 18:39:09 yes 18:39:32 smcv: seems worth re-emphasising that skip upgrades are not supported in the release notes for trixie, given merged-/usr. 18:39:38 so, officially packages uploaded to exp/sid/trixie are allowed to require/assume merged-/usr now 18:39:49 spwhitton: +1 18:40:28 but at the moment, buildds and various QA tools are using unmerged-/usr chroots, to try to mitigate (RC-?)buggy packages 18:40:44 Emperor, smcv: could I action one of you to file a bug against release-notes about that? 18:41:26 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 smcv: sounds reasonable to me. 18:42:11 and I would like to do similarly for pbuilder, reprotest, piuparts, etc. 18:42:26 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 bluca had been meaning to do similar, and might get there first on some of the non-deboostrap packages 18:43:03 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 spwhitton: OK (not offering to write the text, but happy to file a bug) 18:43:48 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 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 failing that, we need to update debootstrap in -pu twice 18:45:05 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 #action Emperor to file bug against release-notes for trixie, to request reassertion that skip upgrades are not supported 18:45:15 Emperor: thanks. 18:45:44 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 smcv: I "vote": sid/trixie -> yes+now, -pu -> not yet 18:45:45 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 no, forget it, won't work 18:46:20 roehling: that's what my patch does 18:46:30 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 although actually I don't think doing two trips through the -pu process would be the worst thing 18:46:58 sounds like we have consensus on you going ahead with trixie&sid, smcv. 18:47:07 smcv: no. we have strong disagreement there. either we patch debootstrap in -pu or we patch cdebootstrap and mmdebstrap in -pu 18:47:48 huh, ok. so you're confident that we need to change *something* in -pu, but exactly what is tbd 18:48:02 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 smcv: confirmed. 18:48:32 would anyone volunteer to chime in on the bootstrap topic on d-devel? 18:48:53 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 smcv: should we mail d-release about that? 18:49:40 helmut: it seems okay to leave bootstrapping aside for now, if no-one volunteers? 18:50:17 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 well, it's reactionable 18:51:18 rejecting -pu requests ;) 18:51:21 ok move on? 18:51:33 thanks again both. 18:51:37 #topic DebConf23 presentation 18:52:17 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 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 I can do (ii) unless someone particularly wants to. 18:52:33 I'm not going to be physically present but yes what smcv said 18:52:35 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 helmut: will you be there? 18:53:37 and does anyone know about Christoph? 18:53:42 not there 18:54:25 okay so Stefano and possibly Christoph is it. 18:54:36 well volunteered ;-) 18:54:40 :P 18:54:49 \o/ yay tumbleweed :) 18:54:51 yeah, so I guess I'll take point i 18:54:51 I'll plan physical presence for 2024 18:55:08 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 yeah, if someone wants to present remotely we can do it 18:55:55 otherwise, I'm happy to do it but I obviously won't have as much context as a long-timer 18:56:26 well, I guess that if Myon does go then you could do it jointly, as the only two people there 18:57:12 tumbleweed: as you are a debconf person could you perhaps co-ordinate getting everyone's names on the presentation? 18:57:20 as co-presenters, I mean. 18:57:32 smcv, Myon, mjg59: If you sign up to the website I can add you as co-presenters 18:57:38 nice. 18:57:43 #action spwhitton to update the debconf slides 18:57:52 #action tumbleweed to ensure we're all co-presenters on the session 18:58:04 #info tumbleweed will lead the BoF as the only in-person confirmed attendee 18:58:32 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 but I think that's it fo rnow. thank you for volunteering, tumbleweed. 18:58:49 #topic Any Other Business 18:58:55 dd 18:58:56 does anyone have anything? 18:59:26 tumbleweed, roehling: typically we mention any disagreements that we are aware of that might eventually end in a TC bug. 18:59:28 sorry, ssh died. I'll probably not make it next meeting 18:59:42 helmut: thanks for letting us know. 18:59:55 nothing from me 19:00:56 nothing on my randar 19:01:05 *radar 19:01:07 me neither 19:01:15 I hope the ifupdown thing sorts well 19:02:15 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 mm. 19:02:36 #endmeeting