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

On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer wrote: > I found that some important arguments are still missing. A recent mail by > Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste > the relevant content into this mail for convenience of the reader: I think

Bug#841294: Overrule maintainer of "global" to package a new upstream version

On Sat, 10 Dec 2016 06:54:17 +1030 Ron wrote: > You then had the gall to angrily insist that while you thought he might > be a better maintainer than me, it was still my responsibility to do the > work to fix all the obvious things that others had missed in their fork > (which he

Bug#841294: Overrule maintainer of "global" to package a new upstream version

On Mon, 21 Nov 2016 17:16:34 +1030 Ron wrote: > If we run with your proposal, what are you actually suggesting we tell > the people who'd be upset by the loss of htags without notice in Stretch? > Because I don't really see how you've addressed that here. >  > AFAICS, there's

Bug#841294: Overrule maintainer of "global" to package a new upstream version

On Tue, 8 Nov 2016 15:33:32 +1030 Ron wrote: > On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote: > > It seems you're only interested in impartial and non-partisan voices > > when they happen to back your position. I am impartial and non-partisan, > > and formed my

Bug#841294: Overrule maintainer of "global" to package a new upstream version

Note: this is written as an outsider who doesn't have any direct stake in the issue. On Sun, 6 Nov 2016 05:00:12 +1030 Ron wrote: > > And I think the latter is basically what the "just ship multiple > versions and hope the future gets clearer" option boils down to. > All it

Bug#830978: Browserified javascript and DFSG 2

On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands <p...@hands.com> wrote: > Uoti Urpala <uoti.urp...@pp1.inet.fi> writes: >  > > In what sense couldn't everyone modify the concatenated form? >  > Perhaps if I frame my question from: >  >   https://bugs.debian.org

Bug#830978: Browserified javascript and DFSG 2

On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney <ben+deb...@benfinney.id. au> wrote: > On 17-Jul-2016, Uoti Urpala wrote: > > If you want to argue "upstream convenience" as a reason for the > > second, >  > Maybe if that were the only justification

Bug#830978: Browserified javascript and DFSG 2

On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams wrote: > On Fri, 15 Jul 2016 23:45:01 +0530 > Pirate Praveen wrote: >> If this argument is accepted, we will not be able to package a fork >> because the original upstream won't accept a patch against

Bug#765803: Status of prompting / notification on upgrade for init system switch?

On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt mp...@debian.org wrote: I'll leave this to the Debian maintainers, as I'm mostly responsible for the Ubuntu side, haven't really discussed this with the two Michaels/Tollef/Marco, and I don't feel qualified to speak for the Debian systemd team.

Bug#746578: Reasons to keep systemd-sysv as the first alternative

On Thu, 2014-09-18 at 17:14 -0700, Cameron Norman wrote: On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote: Personally, in this case, I'd argue that the desirable dependency (which we can't easily express) would be sysvinit-core ? systemd-shim : systemd-sysv. To

Bug#746578: Reasons to keep systemd-sysv as the first alternative

On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote: On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote: I agree completely that it doesn't make sense for the transition from sysvinit to systemd to take place via libpam-systemd rather than via some core package like init,

Bug#727708: Processed: block 726763 with 727708

On Tue, 2014-02-04 at 16:53 +, Colin Watson wrote: On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote: You mean, like installing the systemd-sysv package? Indeed; but people earlier in this thread have said that this isn't the preferred approach, so I was arguing that this

Bug#727708: TC resolution revised draft

On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote: Sébastien Villemot writes (Bug#727708: TC resolution revised draft): P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT This is a nice example which actually demonstrates why these questions need to be

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

On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote: 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,

Bug#727708: On diversity

On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: I think the divergence has gone too far in things like non-Linux ports. They have had an overall negative effect on people working on Linux within Debian and people creating derivatives. I

Bug#727708: On diversity

On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote: Uoti Urpala wrote: Even the upstart proponents do not seem to have significant arguments about upstart having better functionality, and there don't seem to be all that many people who would have a reasonably informed opinion

Bug#727708: On diversity

On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote: * Debian is a forum for cooperation and technical development. * Debian, as a piece of software, tries to be all things to all people (within reason). This flexibility and tolerance for divergence has made Debian an extremely

Bug#727708: init system discussion status

On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: | 3. At least in jessie, unless a satisfactory compatibility approach is |developed and deployed (see paragraph 10), packages must continue |to provide sysvinit scripts. Lack

Bug#727708: init system thoughts

On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote: On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote: You can simply not install any of these additional services if you don't want them. This is completely trivial to do. It is indeed technically trivial, but I invite you

Bug#727708: init system thoughts

On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote: On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote: Colin Watson cjwat...@debian.org writes: Basically, systemd would be more compelling to me if it tried to do less. I don't expect to persuade systemd advocates of

Bug#727708: init system other points, and conclusion

On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote: Also, I get the impression me that the integration of much of this functionality into the systemd source package has been done for political rather than technical reasons. Indeed to the extent that there is a problematically tight

Bug#727708: init system thoughts

On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote: My main concerns with systemd relate to its broad scope regarding units it provides for system initialisation tasks currently performed by other packages, and the potential for that to interfere with past and future work elsewhere in

Bug#727708: upstart and upgrading from sysvinit scripts

On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote: However, I think this gets to the heart of why upstart upstream has avoided ever recommending the use of socket-based activation. There are some fairly fundamental problems that basically halted development of socket-based activation in

Bug#727708: upstart and upgrading from sysvinit scripts

On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote: It's quite possible that I am doing something wrong, but I don't think this is it. Each of the .service units in question already had 'WantedBy=multi-user.target', and each of the .socket units had 'WantedBy=sockets.target'; on Fedora

Bug#727708: systemd vs. binfmt-support

On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote: I was referring more to Tollef's position, really. Debian systemd maintenance ought to take into account matters of Debian integration, which includes whether it fits well into best-of-breed Debian practice. If it's easy enough to

Bug#727708: systemd vs. binfmt-support

On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote: On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote: In this particular case, as you write, I hadn't really given it any consideration before, but what I think would make sense is to extend systemd to support the same

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people

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

On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote: On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote: I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could

Bug#727708: systemd socket activation protocol rationale

On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote: I've just been reading sd_listen_fds(3). It's vaguely similar to upstart's socket activation protocol. It supports multiple sockets (which is obviously important). But I have a few questions about the details: Why do only some of the

Bug#727708: systemd (security) bugs

On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote: On Tue, 03 Dec 2013, Josselin Mouette wrote: Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : Josselin Mouette j...@debian.org writes: There are two implied assumptions here: * that the same people are

Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]

On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote: Uoti Urpala writes (Bug#727708: systemd (security) bugs (was: init system question)): My guess is that most people do not consider that exciting or really care - thinking of system states in terms of runlevels is mostly obsolete

Bug#727708: systemd (security) bugs (was: init system question)

Ian Jackson wrote: It isn't always 100% clear to me from reading these which of them apply to systemd's init replacement. But reading the systemd debate page makes it clear that the other components in the systemd upstream package are seen by systemd proponents as part of their offering, and