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

On Tue, 16 Jul 2013 at 16:08:33 +0200, Ondřej Surý wrote: > I think we can use the libjpeg8 compatibility layer of libjpeg-turbo. > > Although I am not sure if it is really needed as there was only one > package needing new API from libjpeg8 I have heard and that should be > trivial to fix. That

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

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 lib

Bug#1077764: Ruling request on os-release specification implementation

On Mon, 05 Aug 2024 at 09:02:51 +0200, Marc Haber wrote: > On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote: > > > If trixie was identified as trixie, and sid was identified as unstable, > > > what compromise would be, er, compromised, precisely? > > Unstable would become less useful at

Bug#1078598: piuparts.debian.org: oldstable22testing, oldstable222sid should not fail on /usr moves

Package: piuparts.debian.org Severity: normal X-Debbugs-Cc: debian-ctte@lists.debian.org piuparts.debian.org currently reports test failures for many packages in the "oldstable22testing" upgrade path (oldstable → stable → testing) and the "oldstable222sid" upgrade path (oldstable → stable → testin

Bug#727708: upstart and upgrading from sysvinit scripts

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 su

Bug#727708: init system discussion status

On Sun, 05 Jan 2014 at 00:54:04 +, Dimitri John Ledkov wrote: > post-208 rewrite, is interesting, burning bridges with dbus? As in all emails I write about this, I'm trying to be consistent about spelling the abstract specification "D-Bus" and its oddly-licensed reference implementation "dbus"

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

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#893200: TC Chair election

t; F : Niko Tyni > G : Gunnar Wolf > H : Simon McVittie > ===END=== I vote: A = B = C = D = E = F = G > H smcv signature.asc Description: PGP signature

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

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 docu

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

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

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

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 $ apt-fi

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

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 recommend

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

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 low-level

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

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 im

Bug#914897: affects private debs too

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 proble

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

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 var

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

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

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 syml

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

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: debootstrap, buster: Please disabled merged /usr by default

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 preferr

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

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 should

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

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 sufficient

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

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?

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 merged

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

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 t

Bug#932795: Ethics of FTBFS bug reporting

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

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#932795: How to handle FTBFS bugs in release architectures

On Thu, 25 Jul 2019 at 16:39:38 +0300, Adrian Bunk wrote: > On Thu, Jul 25, 2019 at 01:22:42PM +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. > > For CPU-bound tasks like package

Bug#934948: Unnecessary dependencies vs multiple binary packages

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#934948: Unnecessary dependencies vs multiple binary packages

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 automatica

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

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 tha

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

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

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

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). > > ===BEGIN

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

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). > > ===BEGIN

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

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. T

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

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 bet

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

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?

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 thei

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

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 soli

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

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?

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 inten

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

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 dep

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

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 m

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

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 th

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

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 avoi

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

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?

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 10,

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

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 pack

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

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 suppo

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

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 happen

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

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 wit

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

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 implementati

Bug#975075: analogies

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". Thi

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

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#982987: tech-ctte: Call for votes for new CTTE member

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#985270: Resignation + Call for votes for new Chair

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#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

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 constitut

Bug#994275: Reverting breaking changes in debianutils

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 thi

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

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

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

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 >

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

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 t

Bug#994275: Reverting breaking changes in debianutils

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 b

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

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, beca

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

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 > >to

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

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 > >> don&#

Bug#994275: Reverting breaking changes in debianutils

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 descrip

Bug#994275: Reverting breaking changes in debianutils

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#994275: Reverting breaking changes in debianutils

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) deprecation

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

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 Debian

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

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 "fur

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

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

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

(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 mode[

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

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. s

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

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. smc

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

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 not

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

t; ===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

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 containing

Bug#1007717: Ballot and call for votes

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 on merged-/usr

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 debootstr

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

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

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 l

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

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 ind

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

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]: > https://github.com/debuerreo

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

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 unmerged-usr

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

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 bookworm-sec

Re: merged-usr

On Tue, 13 Sep 2022 at 12:57:28 +0200, Adam Borowski wrote: > # debootstrap --no-merged-usr unstable foo ... > # chroot foo dpkg -l usr-is-merged|grep ^ii > ii usr-is-merged 30 all Transitional package to assert a > merged-/usr system ... > On the other hand: WTH? I assume yo

Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett

On Fri, 25 Nov 2022 at 15:39:12 -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Matthew Garrett be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Matthew Garrett > F: Further Discussion > ===END I vote H > F.

Bug#1026104: longstanding problem with dependencies of python3-numpy in testing

On Tue, 10 Jan 2023 at 20:04:08 +0100, Helmut Grohne wrote: > We do not see a simple change or > patch that would be readily applicable to improve the situation. Sandro > indicated that he does not want to work on such a patch, which is his > right granted by the Debian Constitution. On the other h

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote: > People build things on Debian that are not Debian packages. People > compile binaries on Debian, and expect them to work on any system that > has sufficiently new libraries. *raises hand* Hello, I represent an example of those people.

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Mon, 15 May 2023 at 06:48:04 +0200, Johannes Schauer Marin Rodrigues wrote: > Obviously, with Luca's proposal, binaries from packages built with a different > dynamic linker path in them would not work on distributions without > merged-/usr > symlinks. But if the property of stuff from Debian b

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote: > This sounds like a very interesting use case, and the first real one > mentioned, which is great to see - but I do not fully follow yet, from > what you are saying it seems to me that what you need is for your > binaries to use the usual

Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera

On Wed, 14 Jun 2023 at 10:03:19 +0100, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Stefano Rivera be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Stefano Rivera > F: Further discussion > ===END I vote R > F. s

Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling

On Wed, 14 Jun 2023 at 10:04:54 +0100, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Timo Röhling be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Timo Röhling > F: Further discussion > ===END I vote R > F. signatur

Re: Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote: > But, what matters here is the CTTE ruling in #1035831 -- for the time being, > packages must not move files between locations affected by the aliasing. If that happens in reality, then yes, that's bad, and reverting the change is a miti

Re: Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote: > bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the > aliased-dirs scheme. My intention in the MR that was included in the NMU[1] was to default to merged-/usr chroots in all cases for trixie and up, but continue to pr

Re: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote: > In the meanwhile, I'll immediately revert the sabotage. Both of you, please don't turn this into an NMU war in the archive: that doesn't benefit anyone. I would have preferred it if Adam had not immediately uploaded a 0-day revert, but

Bug#1050001: Unwinding directory aliasing

On Fri, 18 Aug 2023 at 07:57:14 +0100, Ian Jackson wrote: > I think we can probably fix it by backing out this change, and then > doing usrmerge the traditional Debian way by making changes to > debhelper, so that we move the files package by package, in the .debs. What do you consider to be the e

Re: Bug#1050001: Unwinding directory aliasing

On Sun, 20 Aug 2023 at 19:26:34 +0200, Adam Borowski wrote: > On Fri, Aug 18, 2023 at 02:39:48PM +0100, Simon McVittie wrote: > > we would still potentially have other issues triggered by > > the directories being distinct from one another (like the one discussed > > by

Bug#1050001: Unwinding directory aliasing

On Wed, 23 Aug 2023 at 17:04:36 +0100, Ian Jackson wrote: > Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"): > > What do you consider to be the end goal of this proposal? > > My idea of a desired end state is as follows: > > /bin and /lib etc.

Re: Bug#1050001: Unwinding directory aliasing

I would very much prefer it if we can keep this conversation respectful, because mediating between angry people is exhausting (and the more spoons I have to put into that, the less effectively I can advocate for the technical opinions that I think you and I mostly agree on, which I assume is not wh

  1   2   >