Bug#717076: tech-ctte: Decide what jpeg library the Debian project will use

2013-07-17 Thread Simon McVittie
On 17/07/13 22:49, Ian Jackson wrote: Perhaps we could just patch our libjpeg6b to have the necessary function. It sounds like an API deficiency that it's missing. It appears that libjpeg-turbo 1.3+ has a libjpeg8-compatible jpeg_mem_(src|dest) by default, even if it's told to implement a

Bug#727708: upstart and upgrading from sysvinit scripts

2013-12-31 Thread Simon McVittie
On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote: The second supported option is DAEMON_OPTS, which sets additional flags to add to the process. For as long as we need to support multiple init systems, this option needs to stay in /etc/default/lbcd and be read from there by all

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

2018-01-04 Thread Simon McVittie
On Tue, 05 Dec 2017 at 12:26:43 +0100, Julian Andres Klode wrote: > More importantly, several packages now require just systemd-sysv. If > apt is told to install libpam-systemd and such a package in the same > operation (especially in a chroot I'd say, since that's where neither > shim nor sysv is

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

2018-08-02 Thread Simon McVittie
On Mon, 23 Jul 2018 at 09:22:17 +0800, Sean Whitton wrote: > There are currently at least 18 source packages which use > vendor-specific series files. I have not been able to determine an > upper bound. Here is a survey of packages that do this, based on this search from Stuart Prescott $

Re: Bug#887557: www.debian.org: tech-ctte membership updates

2018-03-27 Thread Simon McVittie
On Wed, 28 Mar 2018 at 01:47:03 +0900, Osamu Aoki wrote: > > > > - > domain="organization">chairman > > + > domain="organization">chair > > Can't we use neutral term "chairperson" as a tag even though we will > never see it. If you're going to rename the tag (and risk breaking something else

Re: Bug#887557: www.debian.org: tech-ctte membership updates

2018-03-26 Thread Simon McVittie
On Mon, 26 Mar 2018 at 17:33:15 +0300, Niko Tyni wrote: > > - domain="organization">chairman > + domain="organization">chair ... > -Didier Raboud ... > +Margarita Manterola I don't really speak WML, but I think you probably need to instead of if you want to use further down the

Bug#893200: TC Chair election

2018-03-23 Thread Simon McVittie
o Tyni > G : Gunnar Wolf > H : Simon McVittie > ===END=== I vote: A = B = C = D = E = F = G > H smcv signature.asc Description: PGP signature

Bug#904558: What should happen when maintscripts fail to restart a service

2018-10-17 Thread Simon McVittie
On Tue, 09 Oct 2018 at 20:35:33 +0200, Wouter Verhelst wrote: > According to "man invoke-rc.d", policy-rc.d can exit with exit state 106 > and provide a number of actions on stdout. These are then actions that > invoke-rc.d must try in order "until one of them succeeds". As such, a > policy-rc.d

Bug#911225: tech-ctte: Advice on stale libraries in a higher-precedence path entry

2018-10-17 Thread Simon McVittie
Package: tech-ctte Severity: normal I would like advice from the technical committee on . I am not asking for anyone to be overruled. GLib (src:glib2.0) consists of multiple libraries. The ones that are relevant for this bug are libglib-2.0.so.0, which is

Bug#904558: What should happen when maintscripts fail to restart a service

2018-10-07 Thread Simon McVittie
Attempting to summarize what was said on this topic in the thread so far, and at the last technical committee meeting: It's perhaps important to note that we are not discussing ideal situations here: any time this conversation becomes relevant, something is already wrong. We're aiming to

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

2018-12-22 Thread Simon McVittie
On Wed, 05 Dec 2018 at 14:03:19 +0100, Svante Signell wrote: > How about this case: > > - Make as default non merged-/usr for all buildds. This has been done: I sent patches, which have been applied. (This is actually implemented in two different places, either of which would have been

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-22 Thread Simon McVittie
On Mon, 03 Dec 2018 at 17:45:11 +0100, Svante Signell wrote: > On Sun, 2018-12-02 at 21:04 +0100, Marc Haber wrote: > > moving hundreds of megabytes from /usr to / over time. > > This solution was proposed by GNU/Hurd several years ago, and was scrapped due > to not being big enough player in the

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

2018-12-22 Thread Simon McVittie
To be completely clear about the decision that Ian asked the technical committee to overrule: In all debootstrap versions since 1.0.102, merged /usr is the default (for all variants except --variant=buildd). This means that new installations of Debian buster using debian-installer will have

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-01 Thread Simon McVittie
On Sat, 01 Dec 2018 at 17:18:35 +, Holger Levsen wrote: > https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html > lists these packages. > > what surprises me currently, are those 3 packages which are reproducible > in buster (even though we also

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default? /usr by default

2018-12-05 Thread Simon McVittie
Control: retitle 914897 tech-ctte: Should debootstrap disable merged /usr by default? I'm retitling the bug to avoid misrepresenting the technical committee's position on this. We have been asked to overrule the debootstrap maintainer, but we have not yet come to a conclusion on whether we

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Simon McVittie
On Sun, 02 Dec 2018 at 21:21:40 +0900, Hideki Yamane wrote: > - What is the problem? (broken build for which packages? Just R?) The problem we're aware of is: Some packages auto-detect the absolute path to an executable (for example bash or perl) and hard-code it into their output (for example

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Simon McVittie
On Sun, 02 Dec 2018 at 21:04:55 +0100, Marc Haber wrote: > The next debhelper change might choose to give / instead of /usr as a > target directory by default, moving hundreds of megabytes from /usr to / > over time. I don't think anyone is proposing that. There's no reason why it would be

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Simon McVittie
On Sun, 02 Dec 2018 at 20:16:10 +0100, Marc Haber wrote: > On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote: > > A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking > > /bin/grep will make that binary end up in /usr/bin/grep; but the > > /bin → /usr/bin

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Simon McVittie
On Sun, 02 Dec 2018 at 19:54:39 +, Simon McVittie wrote: > When installed on a merged /usr system: Oops, of course this should have said: .deb contains -> /bin/grep/usr/bin/perl /bin/fooexists thanks to /bin symlink exists thanks to /bin symlink /usr/b

Bug#914897: affects private debs too

2018-11-29 Thread Simon McVittie
On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote: > Regardless of debootstrap defaults or flag days, we could also consider > moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in > /{s,}bin I'm not convinced this is a good idea: it seems like it causes as many

Bug#923450: tech-ctte: requirements for being pre-dependency of bin:init

2019-05-15 Thread Simon McVittie
On Thu, 28 Feb 2019 at 12:06:15 +, Dmitry Bogatov wrote: > currently, inclusion of new init system into Debian requires inclusion into > pre-dependency of bin:init package, which is unsatisfactory. > > As can be followed in #838480, current practice puts maintainer of any > new init system

Bug#932795: How to handle FTBFS bugs in release architectures

2019-08-28 Thread Simon McVittie
On Fri, 26 Jul 2019 at 19:05:50 +0200, Santiago Vila wrote: > The practical implications of this is that we are currently forcing > users to spend extra money if they want *assurance* that all the > packages (and not just "most" of them) will build, which is a pity. I have two counterpoints to

Bug#934948: Unnecessary dependencies vs multiple binary packages

2019-08-26 Thread Simon McVittie
On Wed, 21 Aug 2019 at 22:59:50 +0530, Pirate Praveen wrote: > On 2019, ഓഗസ്റ്റ് 21 7:06:34 PM IST, Simon McVittie wrote: > >* As far as I can tell, the command-line executable > >`.../bin/autoprefixer` > > is not in the PATH. I don't know whether it is run automatically i

Bug#934948: Unnecessary dependencies vs multiple binary packages

2019-08-21 Thread Simon McVittie
On Sat, 17 Aug 2019 at 11:20:22 +0530, Pirate Praveen wrote: > I'd like to bring to your notice a disagreement with ftp masters about adding > multiple binary packages when the same source package has code targeting > multiple environments. While attempting to construct a summary of the situation

Bug#932795: Ethics of FTBFS bug reporting

2019-07-24 Thread Simon McVittie
On Tue, 23 Jul 2019 at 13:54:10 +0200, Santiago Vila wrote: > Ethics of FTBFS bug reporting I don't think framing this as a question of ethics is necessarily helpful. When people disagree on a technical question, a recurring problem is that both "sides" end up increasingly defensive, arguing from

Bug#932795: How to handle FTBFS bugs in release architectures

2019-07-25 Thread Simon McVittie
On Thu, 25 Jul 2019 at 13:22:42 +0200, Santiago Vila wrote: > The only thing it did not have was more than one CPU, but AFAIK that's > not something that may be considered as a misconfiguration. Roughly what proportion of Debian packages are failing to build in this environment? Roughly how many

Bug#947847: please install systemd-sysusers using update-alternatives

2020-01-29 Thread Simon McVittie
On Mon, 27 Jan 2020 at 11:18:53 +0100, Thomas Goirand wrote: > you don't seem to agree that it'd be ok for one to use > opensysuser instead of the systemd implementation if systemd is running. > I do not agree with this, and I believe it is up to the users to decide > what to do, even if we, as an

Review/testing requested for gnome-team/glib!9: cleaning up old GLib from /lib/

2020-10-05 Thread Simon McVittie
Now that GNOME 3.38 is (mostly) in testing, I've finally implemented a fix for the GLib upgrade issues referred to the technical committee in #911225 "Advice on stale libraries in a higher-precedence path entry" (see #896019, #955331, #954960). Sorry for the very long delay in implementing this.

Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

2020-05-26 Thread Simon McVittie
On Wed, 20 May 2020 at 17:03:16 -0300, David Bremner wrote: > I call for votes on the following ballot to fill a vacant seat in the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt > (§6.3.1). > >

Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

2020-05-26 Thread Simon McVittie
On Wed, 20 May 2020 at 17:10:26 -0300, David Bremner wrote: > I call for votes on the following ballot to fill a vacant seat in the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt > (§6.3.1). > >

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > #921012 is about changing network-manager to Depend upon "default-logind | > logind" rather than libpam-systemd This is a change that is *sometimes* appropriate, but sometimes not, depending on what facility the dependent package

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-21 Thread Simon McVittie
On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote: > I don't think this is very common. Init scripts are very specific to a > distribution. A Debian init script cannot be used for Redhat. A SUSE > init script does not work with Redhat. I find doubtful that the > compatibility would be

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Thu, 19 Nov 2020 at 11:40:20 +, Ian Jackson wrote: > My view is > that the behaviour seen in #921012 and #964139 is an outrage I don't think this is constructive, and if a package's maintainer doesn't want to enter into conversations, this doesn't seem like an approach that will change

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
Some procedural points, without going into the merits of the technical committee doing as you ask or not: On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > I invite the technical committee to rule that: > * The network-manager init script should be restored > * Network-manager should

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Thu, 19 Nov 2020 at 21:04:00 -0800, Elana Hashman wrote: > It would be much appreciated if Michael Biebl or another maintainer from > the Utopia team could add some context here. Most of the people in the pkg-utopia team are not active contributors to most of its packages, so I don't think

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Sat, 21 Nov 2020 at 10:47:17 +0200, Wouter Verhelst wrote: > On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote: > > 1) poor user experience - a package of initscripts would clutter > > /etc/init.d/ with a huge number of files (most of which would be no use to > > the user) > > This

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-14 Thread Simon McVittie
On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote: > The dependency issue is more challenging. As I said earlier in the thread, if we don't want to overrule on the logind dependency, then I don't think overruling on the init script would make any sense (whereas overruling on the logind

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Simon McVittie
On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote: > Could I just check if there's a point of common acceptability which both > sides of this discussion could live with? > > libpam-systemd | network-manager-nonsystemd Presumably this is an optimized form of what we perhaps conceptually

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-10 Thread Simon McVittie
On Sat, 02 Jan 2021 at 18:36:23 +, Matthew Vernon wrote: > While [lowering NM's dependency on libpam-systemd from Depends to > Recommends] does address the co-installability of network-manager with > elogind, I would like you to still say something officially about the issue, > please, since

Bug#978636: move to merged-usr-only?

2021-01-25 Thread Simon McVittie
On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote: > > The Technical Committee resolves that Debian 'bookworm' should support > > only the merged-usr root filesystem layout, dropping support for the > > non-merged-usr layout. Should we be more specific than this in what we vote on, to

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Simon McVittie
On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > On Mon, Jan 25, 2021 at 09:22:29PM +0000, Simon McVittie wrote: > > Some developers seem to be using "merged /usr" to refer to multiple > > concrete layouts: > > 1. an arrangement where all regular fil

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Simon McVittie
On Mon, 25 Jan 2021 at 14:47:56 -0800, Keith Packard wrote: > I think that and a transition plan are both key to this project. I > recently installed Debian from scratch on my HiFive unmatched board and > it got merged / and /usr. That ship has already sailed: on #914897 in 2019, before Debian

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Simon McVittie
On Tue, 26 Jan 2021 at 10:30:34 +0100, Bastian Blank wrote: > On Tue, Jan 26, 2021 at 09:01:12AM +0000, Simon McVittie wrote: > > On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > > > Aren't there two sub-solutions? > > > > > > 1a. with packages

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Simon McVittie
On Mon, 25 Jan 2021 at 21:22:29 +, Simon McVittie wrote: > On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote: > > > The Technical Committee resolves that Debian 'bookworm' should support > > > only the merged-usr root filesystem layout, dropping support for the

Bug#978636: move to merged-usr-only?

2021-02-01 Thread Simon McVittie
On Mon, 01 Feb 2021 at 13:35:28 +0100, Adam Borowski wrote: > On Sun, Jan 31, 2021 at 03:34:27PM -0600, Gunnar Wolf wrote: > > I want to state (and not as part of the vote, but just as > > yet another DD) that the only way I feel makes sense to continue now > > is via Simon's ① option: Symlinking

Bug#978636: move to merged-usr-only?

2021-01-31 Thread Simon McVittie
On Mon, 25 Jan 2021 at 11:45:55 -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee resolves that Debian 'bookworm' should support > only the merged-usr root filesystem layout, dropping support for the > non-merged-usr layout. > > Until after the release of 'bullseye', any

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Simon McVittie
On Tue, 26 Jan 2021 at 11:27:07 +0100, Bastian Blank wrote: > Before unpacking those packages, both /bin and /lib symlinks must > already exist, because it's past the cutoff date of non-aliased support. I would like that to become true, but the cutoff date of non-aliased support has not yet

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Simon McVittie
On Tue, 26 Jan 2021 at 12:17:37 -0600, Gunnar Wolf wrote: > Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]: > > We can (and should, IMO) declare *today* that for bookworm, shipping > > files in / (as opposed to /usr) that are not compatibility symlinks will > > be RC. > > I agree

Bug#975075: analogies

2021-01-31 Thread Simon McVittie
Sorry for the delay in responding to this, but I wanted to wait until the technical question before the committee had arrived at a result before replying to it. On Thu, 19 Nov 2020 at 06:49:37 -0800, Felix Lechner wrote: > In Debian, users of 'sysvinit' strike me as such a "disfavored class".

Bug#985270: Resignation + Call for votes for new Chair

2021-03-17 Thread Simon McVittie
On Mon, 15 Mar 2021 at 10:30:59 +0100, Margarita Manterola wrote: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Margarita Manterola > B : David Bremner > C : Niko Tyni > D : Gunnar Wolf > E : Simon McVittie > F : Sean Whi

Bug#982987: tech-ctte: Call for votes for new CTTE member

2021-02-17 Thread Simon McVittie
On Wed, 17 Feb 2021 at 12:45:05 -0600, Gunnar Wolf wrote: > ===BEGIN > > The Technical Committee recommends that Christoph Berg be > appointed by the Debian Project Leader to the Technical Committee. > > A: Recommend to appoint Christoph Berg > B: Further Discussion > > ===END I vote A > B.

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-09-15 Thread Simon McVittie
On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote: > - §(Building packages): I almost wrote an extra paragraph about how > this class of bugs becomes a non-issue when merged-/usr is the only > supported layout - but actually it doesn't! If we consider building > pa

Bug#994275: Reverting breaking changes in debianutils

2021-09-15 Thread Simon McVittie
On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote: > 5. Programs in debianutils must not be moved to /usr unless there is >project-wide consensus on packages doing such a move, and premature >moving must be reverted. This part touches on an issue we are looking at in parallel to

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-09-15 Thread Simon McVittie
On Wed, 15 Sep 2021 at 11:46:11 +0100, Simon McVittie wrote: > As for what that advice is, I'm open to suggestions, but I'm drafting > some possible wording, which I'll upload to > https://salsa.debian.org/debian/tech-ctte/ when I have a bug number > for it. Here it is: https://sals

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-09-15 Thread Simon McVittie
On Wed, 15 Sep 2021 at 11:34:33 -0400, Zack Weinberg wrote: > For the various files with a "canonical" location > either in /usr or in /, either specified by some standard or by > convention, and regularly referred to by absolute pathname, all > software should continue to refer to those files by

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-09-15 Thread Simon McVittie
Package: tech-ctte Severity: normal As discussed in our last meeting, I think we should issue more specific advice about merged-/usr, and in particular about what #978636 means for maintainers right now. Constitutionally, I'm asking the TC to use its power to offer formal advice (Debian

Bug#994275: Reverting breaking changes in debianutils

2021-09-25 Thread Simon McVittie
On Sat, 25 Sep 2021 at 02:22:44 +, Clint Adams wrote: > * debianutils gets closer to achieving its mission, by having >one fewer irrelevant utility that does not belong This seems a good opportunity to ask what I think is a key question here: what do you consider debianutils' mission to

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-13 Thread Simon McVittie
On Wed, 13 Oct 2021 at 20:13:08 +0100, Simon McVittie wrote: > I'm calling for votes on the following resolution as formal advice from > the Technical Committee (Constitution §6.1.5). There are no non-accepted > amendments, so the options to vote on are "yes" or "further

Bug#994275: Reverting breaking changes in debianutils

2021-10-10 Thread Simon McVittie
On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote: > The release team has so far protected users of testing from the > problem by blocking testing migration, but this is not a long-term > solution. Adrian asked in #994275 for changes in several topics to be reverted: - which(1)

Bug#994275: Reverting breaking changes in debianutils

2021-10-10 Thread Simon McVittie
On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote: > More specifically, I am asking the Technical Committee to decide that: I think this is really 5 separate (but related) requests, each of which we could either uphold or decline, separately. Do you agree? > 1. The "which" program must be

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-13 Thread Simon McVittie
I'm calling for votes on the following resolution as formal advice from the Technical Committee (Constitution §6.1.5). There are no non-accepted amendments, so the options to vote on are "yes" or "further discussion". begin text to be voted on Summary === There are currently

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-05 Thread Simon McVittie
On Mon, 27 Sep 2021 at 09:18:29 -0600, Sam Hartman wrote: > [smcv wrote] > >On merged-/usr systems, there is a possible failure mode involving files > >being moved between packages (with Replaces) during the same release > >cycle that their logical location is changed from the root filesystem >

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-05 Thread Simon McVittie
On Sun, 03 Oct 2021 at 16:52:15 -0700, Sean Whitton wrote: > On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote: > > On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote: > >> (1) The reason for this, to put it a bit simplistically, is that we > >> d

Bug#994275: Reverting breaking changes in debianutils

2021-10-06 Thread Simon McVittie
On Sun, 03 Oct 2021 at 22:09:31 +, Clint Adams wrote: > The package description uses the phrases "specific to Debian" and > "installation scripts of Debian packages". The fact that > debianutils is used on non-deb operating systems suggests a failure > at the former. Given its package

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-09-27 Thread Simon McVittie
On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote: > https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md I have updated this draft to incorporate my edits from !3, and feedback from bremner on IRC. I'd like to keep this moving, because i

Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr

2021-12-04 Thread Simon McVittie
(Speaking only on my own behalf, not on behalf of the TC, here) On Fri, 03 Dec 2021 at 16:08:24 -0500, Nicholas D Steeves wrote: > 1. Debian isn't yet ready for usrmerge Merged /usr is not actually the problem here, although it exacerbates what appears to be a pre-existing bug in the rescue

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

2021-10-27 Thread Simon McVittie
On Wed, 20 Oct 2021 at 12:30:54 -0700, Sean Whitton wrote: > I hereby call for votes on the following ballot to resolve #994275. I vote A > B > FD (which I believe means the outcome is no longer in doubt and we resolve A). > === Resolution A === > > The Technical Committee resolves: > > 1. The

Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon

2022-01-17 Thread Simon McVittie
On Fri, 14 Jan 2022 at 11:56:20 -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Matthew Vernon be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Matthew Vernon > F: Further Discussion > ===END I vote H > F.

Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne

2022-01-17 Thread Simon McVittie
On Fri, 14 Jan 2022 at 11:55:17 -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Helmut Grohne be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Helmut Grohne > F: Further Discussion > ===END I vote H > F.

Bug#1004611: Resignation & call for votes to elect the Chair

2022-02-02 Thread Simon McVittie
gt; > ===BEGIN > > A: Christoph Berg > B: Helmut Grohne > C: Elana Hashman > D: Simon McVittie > E: Niko Tyni > F: Matthew Vernon > G: Sean Whitton > H: Gunnar Wolf > > ===END I vote G > A = C = E = H > D > B = F. smcv signature.asc Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Simon McVittie
On Mon, 31 Jan 2022 at 10:11:19 +, Matthew Vernon wrote: > There are two "rename" programs, one part of upstream util-linux "rename.ul" > and one provided by the rename package "rename.pl"[0] Almost! The one in src:rename is installed as file-rename(1p), aka prename(1p) via a symlink (you

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-26 Thread Simon McVittie
On Wed, 20 Apr 2022 at 15:31:13 +0100, Matthew Vernon wrote: > ===Begin Resolution A > The Technical Committee overrides the util-linux maintainer, and requires > that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary > package built from src:util-linux. The package

Bug#1007717: Ballot and call for votes

2022-06-22 Thread Simon McVittie
On Mon, 20 Jun 2022 at 17:31:16 -0700, Sean Whitton wrote: > Using its powers under constitution 6.1.5, the Technical Committee > issues the following advice: > > 1. It is not a bug of any severity for a package with a non-native > version number to use a native source package format. > >

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2022-07-19 Thread Simon McVittie
On Mon, 18 Jul 2022 at 20:03:14 +0100, Luca Boccassi wrote: > On Mon, 2022-07-18 at 17:53 +0200, Johannes Schauer Marin Rodrigues > > Also, what is the relationship between the usr-is-merged package and the > > usrmerged package? Both were/are built by src:usrmerge but its changelog > > doesn't

Re: tech-ctte: more on merged-/usr

2022-07-17 Thread Simon McVittie
On Sun, 17 Jul 2022 at 00:56:14 +0100, Luca Boccassi wrote: > Piuparts has been enhanced with a new test case that covers the > moratorium on moving files manually between their location in the root > directories and /usr. Thanks for doing this, it will help a lot. > A MR is pending for

Re: tech-ctte: more on merged-/usr

2022-07-17 Thread Simon McVittie
On Sun, 17 Jul 2022 at 11:34:36 +0100, Simon McVittie wrote: > I personally agree that buildds should stay unmerged-/usr until the known > bugs that would be triggered by merged-/usr buildds have been raised to > RC severity, though. #992645 is a typical example. I'll try to have a look &

Re: tech-ctte: more on merged-/usr

2022-07-17 Thread Simon McVittie
On Sun, 17 Jul 2022 at 11:34:36 +0100, Simon McVittie wrote: > On Sun, 17 Jul 2022 at 00:56:14 +0100, Luca Boccassi wrote: [some discussion of the transition to merged /usr] Please note that #994388 has been closed and archived, and does not accept new messages, so I've removed it from

Re: tech-ctte: more on merged-/usr

2022-07-19 Thread Simon McVittie
On Mon, 18 Jul 2022 at 13:03:36 -0700, Tianon Gravi wrote: > Hopefully I'm not too OT (please feel free to tell me if so! [1] would > be an appropriate place to continue with more discussion on the topic) > but another angle to this is the container images. > > [1]: >

Re: tech-ctte: more on merged-/usr

2022-07-19 Thread Simon McVittie
On Tue, 19 Jul 2022 at 13:42:21 +0100, Luca Boccassi wrote: > And before release day, there's no such thing as a bookworm buildd, > right? Everything is built in unstable? As far as I know, bookworm buildd chroots already exist, and are used for uploads to testing-proposed-updates and

Re: tech-ctte: more on merged-/usr

2022-07-19 Thread Simon McVittie
On Sun, 17 Jul 2022 at 14:21:30 +0100, Luca Boccassi wrote: > So the reasoning behind adding the override to debootstrap in -- > variant=buildd mode is twofold. > > From a very practical perspective, it means it's supereasy to allow all > those builds and tools you mentioned to run in