Bug#692155: Please

On Fri, Nov 02, 2012 at 04:41:19PM -0700, Russ Allbery wrote: Didier 'OdyX' Raboud o...@debian.org writes: ... Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit : In practice, divergence from the upstream SONAME practice is probably a bad idea. This business of having an exposed

Bug#727708: systemd jessie - jessie+1 upgrade problems

Hi Josselin, reading through the systemd position statement [1], I ran into a statement that is either incomplete or incorrect: The upstart position statement [2] states: -- snip -- systemd is hasty. ... While we are committed to having sane upgrade paths and not depend on such kernel

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: this hits exactly the core of the problem: The minimum supported Linux kernel version in glibc is currently 2.6.16, released in 2006. And I'd trust glibc upstreamt that this requirement

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote: Adrian == Adrian Bunk b...@stusta.de writes: Adrian Yes, it is speculation that other new features (or even Adrian bugfixes) might appear in the kernel and might become Adrian mandatory in systemd between jessie

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote: Hi Adrian, Hi Josselin, Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 08:53:04AM -0500, Sam Hartman wrote: Adrian, I'm frustrated when I read your message because you put words in my mouth that I did not speak. Hi Sam, I never said that Debian should allow systemd to dictate policy for multiple distributions nor did I say that Debian

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote: On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote: ... When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). I think you still misread the argument

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote: Hi, Adrian Bunk b...@stusta.de writes: On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote: And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 03:50:33PM +0100, Josselin Mouette wrote: Hi, Hi Josselin, ... I do not consider keeping an arbitrary number of packages at the wheezy version an appropriate answer, regardless of the choice of init systems. ... how many and which packages would have to be kept at the

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: ... When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). There appears to be near-unanimous agreement that Debian

Bug#727708: systemd jessie - jessie+1 upgrade problems

On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: [1] Personally, I am sceptical whether it is a good idea to switch to a different init system for jessie. But I am not on a desperate rant against systemd, and if something I bring up

Bug#727708: Bits from linux.conf.au

On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow

Bug#727708: Bits from linux.conf.au

On Tue, Jan 14, 2014 at 06:03:33PM +, Ian Jackson wrote: Adrian Bunk writes (Bug#727708: Bits from linux.conf.au): ... 3. Switching init systems after installation. Assume I am currently using systemd. What is supposed to happen when I do apt-get install sysvinit-core? I think

Bug#727708: Bits from linux.conf.au

On Tue, Jan 14, 2014 at 11:31:09AM -0700, Bdale Garbee wrote: Adrian Bunk b...@stusta.de writes: ... If dependencies like installing GNOME enforces systemd as init system would be legal, then after a few more such dependencies it would turn out that systemd will be the only option available

Bug#727708: Init system resolution open questions

On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote: ... Maintainers only should not drop support for a (default) init system when the application supports it. ... So if udev (maintained by systemd upstream as part of the systemd sources) would ever get a dependency on systemd

Bug#727708: On diversity

On Fri, Jan 17, 2014 at 05:08:51PM +0100, Christoph Anton Mitterer wrote: On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote: The universal operating system phrase is a slogan. Sure it is, but that slogan actually stands for some important principles in the open source world... like not

Bug#727708: Thoughts on Init System Debate

On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote: ... With all that said, I think all of these considerations give me a slight preference for systemd over upstart, though I believe that whatever the committee decides on will be a great improvement over venerable SysV. ... 3:

Bug#727708: Init system resolution open questions

On Fri, Jan 17, 2014 at 08:13:30PM -0800, Russ Allbery wrote: ... I believe it is reasonable to allow GNOME to require systemd as the init system if that's the only way to get a working logind with the software that we release with jessie, Why does logind actually have to be a hard dependency

Bug#727708: Init system resolution open questions

On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote: ... If software that people want to package for Debian is deeply entangled in one init system (that is supported in Debian), for good or for ill, regardless of what one might think of the decisions made by upstream that created that

Bug#727708: Init system resolution open questions

On Fri, Jan 17, 2014 at 12:51:48PM +, Ian Jackson wrote: Adrian Bunk writes (Re: Bug#727708: Init system resolution open questions): (Only as a PM since I am repeating myself.) Thanks for your mail. I think it deserves wider consideration. One question you should consider adding

Bug#727708: Init system resolution open questions

On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote: There is a natural process here, where rarely-used configurations slowly stop working and people eventually decide not to bother

Bug#727708: Init system resolution open questions

On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote: ]] Adrian Bunk I already gave my hypothetical udev gets a hard dependency on systemd as init system worst case. To make the worst case even worse, assume a new upstream version of systemd with this change gets released

Bug#727708: Init system resolution open questions

On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote: ... No, I am not assuming bad faith. But there will be cases where the goals like 1. give users of systemd under Linux the best

Bug#727708: Init system resolution open questions

On Sun, Jan 19, 2014 at 04:05:08PM +0100, Tollef Fog Heen wrote: ]] Adrian Bunk ... If I was a systemd maintainer I would consider it a reasonable option to rather upload a new version of systemd that adds such a dependency to udev instead of shipping an ancient systemd in the next

Bug#727708: multiple init systems - formal resolution proposal

On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote: ... == version multiple only == 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an

Bug#727708: multiple init systems - formal resolution proposal

On Mon, Jan 27, 2014 at 08:54:13PM -0500, Michael Gilbert wrote: On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote: 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing

Bug#727708: multiple init systems - formal resolution proposal

On Tue, Jan 28, 2014 at 08:40:01AM +0200, Adrian Bunk wrote: ... [1] That's ignoring the possibility that a non-systemd logind replacement with sufficient functionality for all software following the latest logind features might show up one day - but ,,, Please ignore this part of [1

Bug#727708: call for votes on default Linux init system for jessie

On Tue, Jan 28, 2014 at 11:39:51AM +, Ian Jackson wrote: ... M. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Software outside of an init system's implementation may

Bug#727708: multiple init systems - formal resolution proposal

On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote: On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : No. My question isn't about logind, but about using a user systemd session to supervise

Bug#727708: call for votes on default Linux init system for jessie

On Tue, Jan 28, 2014 at 09:12:54AM -0800, Keith Packard wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it doesn't make sense to allow people to require a non-default init. I think this position is consistent with allowing each maintainer broad autonomy, and not

Bug#727708: call for votes on default Linux init system for jessie

On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote: On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote: The former. So : Where feasible, software should interoperate with non-default init systems;

Bug#727708: multiple init systems - formal resolution proposal

On Wed, Jan 29, 2014 at 10:05:22AM +0100, Josselin Mouette wrote: Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit : On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote: On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote: Le mardi 28 janvier 2014

Bug#727708: call for votes on default Linux init system for jessie

On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote: On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote: For anyone intending to make Debian the laughingstock of the open source world, here is a good opportunity: Debian decides that Upstart is the default init system

Bug#727708: multiple init systems - formal resolution proposal

On Tue, Jan 28, 2014 at 10:50:00PM +0100, Olav Vitters wrote: ... Further, in my experience it was *way* more stable to either go for full systemd or always rely on the reduced functionality. The runtime detection of is systemd running as PID 1 was IMO not very stable (and that wasn't just

Bug#727708: multiple init systems - formal resolution proposal

On Wed, Jan 29, 2014 at 06:41:11PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : ... Assuming jessie will support multiple init systems, why would GNOME need a dependency on systemd? Because it needs logind. https://lists.debian.org

Bug#727708: multiple init systems - formal resolution proposal

On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch

Bug#727708: multiple init systems - formal resolution proposal

On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10

Bug#727708: multiple init systems - formal resolution proposal

On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote: 2014-01-29 Adrian Bunk b...@stusta.de: [...] I do fully acknowledge that there are issues with ConsoleKit being unmaintained and many non-systemd codepath in GNOME being unmaintained and with GNOME missing some non-basic

Bug#727708: TC resolution revised draft

On Fri, Jan 31, 2014 at 03:02:21PM +0100, Sébastien Villemot wrote: Le vendredi 31 janvier 2014 à 11:55 +, Neil McGovern a écrit : On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote: Given the Condorcet voting method is susceptible to tactical voting, Hi Josselin,

Bug#727708: package to change init systems

On Sat, Feb 01, 2014 at 10:44:27PM -0800, Russ Allbery wrote: ... I think L is a bad technical design, regardless of the relative merits of the possible init systems that we might switch to. It's effectively equivalent to requiring sysvinit support for all packages indefinitely, and if we

Bug#727708: package to change init systems

On Sun, Feb 02, 2014 at 11:44:55AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: No, it does not require sysvinit support for all packages indefinitely. The current TC decision is *for jessie*. The D/U/O/V/GR options are for jessie. T and L aren't. Nothing in T or L

Bug#727708: package to change init systems

On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Yes. I would still prefer to see something like that. I don't remember exactly what the objections were and I'm very very tired now but perhaps something like We

Bug#727708: package to change init systems

On Mon, Feb 03, 2014 at 03:13:06PM +, Ian Jackson wrote: Bdale Garbee writes (Bug#727708: package to change init systems): I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least

Bug#727708: Call for votes on init system resolution

On Wed, Feb 05, 2014 at 09:56:14AM -0800, Steve Langasek wrote: ... 8. OT openrc default in jessie, requiring specific init is allowed 8. VT sysvinit default in jessie, requiring specific init is allowed ... Is this a typo or an intentional equal ranking? cu Adrian -- Is

Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)

On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote: ... Now, I think there is currently a shared agreement in Debian that all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort sysvinit

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote: On 7 February 2014 06:20, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Don Armstrong writes (Bug#727708: Call for votes on init system resolution): Given the already stated preferences of the CTTE, and the previous votes

Bug#727708: Call for votes on init system resolution

On Thu, Feb 06, 2014 at 02:20:51PM -0800, Russ Allbery wrote: ... This is one of the major reasons why I'm voting GR second. I see Bdale's point that we shouldn't abdicate our responsibility to make the best decision that we can, and I followed that maxim by voting my preference first. But

Bug#727708: Call for votes on init system resolution

On Fri, Feb 07, 2014 at 01:08:46AM -0800, Keith Packard wrote: Russ Allbery r...@debian.org writes: I consider the L option as currently written to be a commitment to a course of action that is technically broken and unsustainable. I also think the effect of L is contrary to its intended

Re: Bug#727708: Call for votes on init system resolution

On Sun, Feb 09, 2014 at 01:17:50AM +1000, Anthony Towns wrote: On 8 February 2014 18:26, Adrian Bunk b...@stusta.de wrote: On Sat, Feb 08, 2014 at 04:40:22AM +, Anthony Towns wrote: ... I'd actually call it a bug in the voting system that the casting vote might decide between an option

Bug#727708: Call for votes on init system resolution

On Sat, Feb 08, 2014 at 12:38:21PM -0800, Russ Allbery wrote: ... I don't see any reason why, say, mountall or socklog-run should be required to support sysvinit. ... What about udev? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness.

Bug#727708: call for votes on default Linux init system for jessie

On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote: On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote: On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote: Bdale == Bdale Garbee bd...@gag.com writes: Bdale Steve Langasek vor...@debian.org writes:

Bug#727708: init system coupling etc.

On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote: ... All packages should support smooth upgrades from wheezy to jessie, including upgrades done on a system booted with sysvinit. ... This sounds like a statement by the TC that smooth upgrades from wheezy to jessie will

Bug#727708: init system coupling etc.

On Wed, Feb 12, 2014 at 11:35:11AM -0800, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote: ... All packages should support smooth upgrades from wheezy to jessie, including upgrades done on a system booted

Bug#727708: init system coupling etc.

On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote: Hi, I must admit that I only followed this part of the discussion from a distance. However, one thing really strikes me: On 12/02/14 at 14:08 +, Ian Jackson wrote: [loose coupling] Software outside of an init

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Wed, Oct 05, 2016 at 10:06:57AM -0500, Don Armstrong wrote: > On Wed, 05 Oct 2016, Adrian Bunk wrote: > > Please describe the relevant differences between browserified > > javascript and perl that make the TC believe that the former has a > > DFSG issue but the latter proba

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Wed, Oct 05, 2016 at 12:59:36PM +0100, Ian Jackson wrote: >... > I think the TC has many reasonable options. > > * You could say that you think you aren't authorised, by the >constitution, to overrule a decision on DFSG-ness, and invite the >petitioners to consider a GR. In any case

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Wed, Oct 05, 2016 at 10:00:53AM -0400, Sam Hartman wrote: >... > I think it's clear that the TC believes that this package is not DFSG > free. > I think it's clear that the TC believes perl would be better if the > situation was improved. > I thought it was clear we believed perl had a DFSG

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 10:43:00AM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2 > (reopening)"): > > Perl's Configure or SQLite are other examples of code with similar > > issues currently in Debian, and it woul

Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 11:48:36AM +0200, Philip Hands wrote: >... > The security team are going to have to track down every instance of that > code and fix it. If the bug is something to do with an interaction > between the code and the tools used to "browserifiy" the code, that may be >

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Tue, Oct 04, 2016 at 05:54:55PM -0400, Sam Hartman wrote: > >>>>> "Adrian" == Adrian Bunk <b...@stusta.de> writes: > > Adrian> In other words, the best way forward for getting any > Adrian> decision would be an RC bug against perl

Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote: >... > I think it'd be preferable for the software to be in contrib (AFAIK > there's nothing here which is non-free?) >... When a package is not DFSG-free it is non-free. Only DFSG-free packages that depend on non-free software are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 07:48:28PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote: > > >... > > > I think it'd be preferable for the software to be in contrib (AFAIK > > >

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote: > ❦ 5 octobre 2016 22:49 CEST, Philip Hands  : > > > If you fancy explaining what you think browserified means w.r.t. the > > Jison stuff, go ahead of course. That might at least help to focus the > > discussion a

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 01:13:16AM -0400, Joseph R. Justice wrote: > For the record, I wish the message I am now responding to, and other > subsequent responses and discussion, were being sent to the bug mail > address *in addition to* all the other addresses they're being sent to. >... For the

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote: >... > Here are some factors to consider: > > 1) It's not clear to several TC members that the FTP team has decided > on this question. It seems fairly clear how they would decide if they > did decide, but from a process standpoint,

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Wed, Oct 05, 2016 at 08:21:40PM +0200, Philip Hands wrote: > Adrian Bunk <b...@stusta.de> writes: > > > Why are TC members complaining that they do not even properly understand > > what "browserified" means, instead of using the power to give advic

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

On Thu, Oct 06, 2016 at 02:23:37PM +0200, Didier 'OdyX' Raboud wrote: >... > All of the above are imperfections (yes, bugs) in how src:firefox handles its > internal sqlite3.c code copy. In an ideal world: > > * src:sqlite3 would provide sqlite3.c in a binary package (sqlite3-static ?) > *

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

Hi, looking at something where I worked on the upstream implementation ages ago: https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/ It is a common problem that users should be able to get started quickly after installing a program. When liferea is

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > Hi, > > > > looking at something where I worked on the upstream implementation ages ago: > > https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

On Fri, Aug 17, 2018 at 08:58:49AM -0700, Sean Whitton wrote: > Hello, > > On Fri 17 Aug 2018 at 12:01AM +0300, Adrian Bunk wrote: > > > On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote: > >> For example, someone might want to use a Debian syste

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

On Sun, Aug 19, 2018 at 12:11:01PM -0700, Sean Whitton wrote: >... > On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote: >... > > For a user it doesn't make a difference which tool applies the patches. > > In my mind, it does; it matters whether or not it is part o

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

On Fri, Aug 17, 2018 at 07:33:02PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Bug#904302: Why outlawing vendor-specific patch series > would be a bad idea"): > > The main misconception is that there would always be *the* source. > > > > Steps you might

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote: > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote: > > How should we handle architecture-specific patches properly inside > > Debian? > > Why should there ever be architecture-specifi

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

On Fri, Oct 05, 2018 at 08:49:47AM +0200, Philip Hands wrote: > Adrian Bunk writes: > > > On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote: > >>... > >> IMO policy should recomend the use of separate source packages as the > >> prefered solut

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

On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote: >... > IMO policy should recomend the use of separate source packages as the > prefered solution to the problem that vendor-specific patch series were > supposed to address. In this case please make an explicit decision on whether

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

On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote: >... > The Committee therefore resolves that: > > 1. Any use of dpkg's vendor-specific patch series feature is a bug for > packages in the Debian archive (including contrib and non-free), This misses an important part of the

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

On Thu, Oct 04, 2018 at 01:32:08PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should > be permitted in the archive"): > > On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote: > > > T

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

On Fri, Jul 26, 2019 at 07:05:50PM +0200, Santiago Vila wrote: >... > https://people.debian.org/~sanvila/single-cpu/ >... > 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

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

On Tue, Jul 30, 2019 at 02:40:06PM +0200, Santiago Vila wrote: >... > This is really like a weak form of "reproducible builds", as in "every > time I try to build the package in a capable system, the build succeeds". Is a single-core system capable of rebuilding a package with parallel=64 ? >

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

On Tue, Jul 30, 2019 at 09:05:04PM +0200, Santiago Vila wrote: > Quoting Debian Policy: > > Packages should build reproducibly, which for the purposes of this > document [19] means that given > > a version of a source package unpacked at a given path; > a set of versions of installed

Bug#932795: Ethics of FTBFS bug reporting

On Tue, Jul 23, 2019 at 01:30:58PM +0100, Ian Jackson wrote: > Santiago Vila writes ("Bug#932795: Ethics of FTBFS bug reporting"): >... > On the point at issue, do these packages build in a cheap single-vcpu > vm from some kind of cloud vm service ? ISTM that this is a much > better argument than

Bug#932795: Ethics of FTBFS bug reporting

On Tue, Jul 23, 2019 at 01:54:10PM +0200, Santiago Vila wrote: >... > * I'm told that single-cpu systems are an oddity and that most > physical machines manufactured today are multi-core, but this > completely fails to account that single-cpu systems are today more > affordable than ever thanks to

Bug#932795: Ethics of FTBFS bug reporting

On Tue, Jul 23, 2019 at 08:45:42PM +0200, Ansgar wrote: > Adrian Bunk writes: > > - An environment with at least 16 GB RAM is supported. > > > > Not sure about the exact number, but since many packages have > > workarounds for gcc or ld running into the 4 GB addr

Bug#932795: Ethics of FTBFS bug reporting

On Wed, Jul 24, 2019 at 11:34:53AM +0200, Santiago Vila wrote: >... > This is a Makefile bug in gcc-8-cross, a package which would qualify > as "big". Maintainer did not initially believe it was a real bug, > maybe because he built the package a lot of times in the past and the > bug never

Bug#932795: Ethics of FTBFS bug reporting

On Thu, Jul 25, 2019 at 09:16:53AM +0100, Colin Watson wrote: > On Tue, Jul 23, 2019 at 06:11:04PM +0300, Adrian Bunk wrote: > > On Tue, Jul 23, 2019 at 01:30:58PM +0100, Ian Jackson wrote: > > > Santiago Vila writes ("Bug#932795: Ethics of FTBFS bug reporting"):

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

On Thu, Jul 25, 2019 at 01:22:42PM +0200, Santiago Vila wrote: > On Wed, Jul 24, 2019 at 12:05:45PM +0100, Simon McVittie wrote: >... > Ok, my build environment: > > * Had enough RAM. > * Had enough disk. >... > The only thing it did not have was more than one CPU, but AFAIK that's > not

Bug#994275: Reverting breaking changes in debianutils

On Wed, Sep 15, 2021 at 09:20:34AM +0200, Helmut Grohne wrote: > On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote: >... > > 1. The "which" program must be provided by an essential package. > > This request seems overzealous to me. Banning the shrinking of

Bug#994275: Reverting breaking changes in debianutils

On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote: > 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

Bug#994275: Reverting breaking changes in debianutils

On Thu, Sep 16, 2021 at 03:02:57PM -0700, Sean Whitton wrote: > Hello Adrian, > > On Wed 15 Sep 2021 at 01:36AM +03, Adrian Bunk wrote: > > > Package: tech-ctte > > Severity: normal > > > > This is a request to override the maintainer of debianutils o

Bug#994275: Reverting breaking changes in debianutils

On Fri, Sep 24, 2021 at 10:44:06AM +0200, Ansgar wrote: > On Fri, 2021-09-24 at 09:26 +0300, Adrian Bunk wrote: > > In my opinion, an amicable middle-ground proposal would be that the > > debianutils maintainer completely removes "which" from debianutils, > >