Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

>> Policy 6.1 says >> | Programs called from maintainer scripts should not normally have a >> | path prepended to them. >> >> Ie, programs that are on PATH should be found via the PATH rather than >> by hardcoding /usr/bin/foo or whatever. In general, I think we >> normally, at least in software

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

On Dec 05 2016, Ron wrote: > Hi Sam, > > On Wed, Nov 30, 2016 at 11:39:08AM -0500, Sam Hartman wrote: >> > "Ron" == Ron writes: >> >> Ron> Hi OdyX, >> >> Ron> On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud >> wrote: >> >> Hi

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

On Nov 07 2016, Ron wrote: >> In my opinion, the fact that you had no time for this issue for multiple >> years, but are now able to send a large number of long emails about it >> to the ctte does not speak in your favor. > > I'm sorry, remind me again about where and what you

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

On Nov 06 2016, Ron wrote: > On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote: >> Ron writes: >> > >> > I can try to clarify that if there's a question in your mind that >> > you don't think I touched on there. >> >> The question that remains is

Re: Bug#797533: New CTTE members

On Sep 09 2015, Steve Langasek wrote: > On Wed, Sep 09, 2015 at 05:30:03PM +0100, Wookey wrote: > >> So what I learned from this is that, as currently operating, the >> committee is incapable of making quick 'overrule unreasonableness' >> decisions. My overriding impression was

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

On Aug 31 2015, Sam Hartman wrote: > OK. > I'd really appreciate hearing from anyone now who needs more time before > a CFV. Please don't forget that if anyone needs more time, they can always vote FD. Best, -Nikolaus -- GPG encrypted emails preferred. Key id:

Bug#741573: Comparison of Options AB and D

On Aug 30 2015, Sam Hartman hartm...@debian.org wrote: Nikolaus == Nikolaus Rath nikol...@rath.org writes: Nikolaus On Aug 29 2015, Sam Hartman hartm...@debian.org wrote: Option D goes further. Option D requires that packages drop their traditional menu entries if they ship

Re: Bug#741573: Comparison of Options AB and D

On Aug 30 2015, Sam Hartman hartm...@debian.org wrote: if you actually want the TC to only choose with no comment from the options before it; if you want us not to raise objections and actually set policy as we are charged with in the constitution, There is an (important) difference between

Bug#741573: #741573: Menu Policy and Consensus

On Aug 28 2015, Ian Jackson ijack...@chiark.greenend.org.uk wrote: [ things about the menu system ] This really has become a farce. This issue been open for more than a year. Sam rephrased the entire issue earlier this year in terms of consensus and has just finished his analysis. And now it

Bug#741573: #741573: Menu Policy and Consensus

On Aug 28 2015, Sam Hartman hartm...@debian.org wrote: Nikolaus == Nikolaus Rath nikol...@rath.org writes: Nikolaus On Aug 28 2015, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Nikolaus [ things about the menu system ] Nikolaus This really has become a farce. This issue

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[ Resending to bug address rather than just ctte list ] Don Armstrong d...@debian.org writes: On Wed, 10 Dec 2014, Nikolaus Rath wrote: Don Armstrong d...@debian.org writes: 4. The CTTE appreciates the effort of Debian contributors to mitigate any issues with the transition

Re: Bug#762194: Initial draft of affirming transition to systemd as default for #762194

Don Armstrong d...@debian.org writes: On Wed, 10 Dec 2014, Nikolaus Rath wrote: Don Armstrong d...@debian.org writes: 4. The CTTE appreciates the effort of Debian contributors to mitigate any issues with the transition by: a) Providing a fallback boot entry for sysvinit when

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

Don Armstrong d...@debian.org writes: 4. The CTTE appreciates the effort of Debian contributors to mitigate any issues with the transition by: a) Providing a fallback boot entry for sysvinit when systemd is the default init in grub (#757298) b) Developing a mechanism to warn on

Re: please stop

Steve Langasek vor...@debian.org writes: On Sat, Nov 08, 2014 at 07:49:10PM -0800, Nikolaus Rath wrote: Joey Hess jo...@debian.org writes: I'll add that the ctte is rubber-stamping Ian's wording, when that went *so* well last time. I believe this issue is at least partly caused by the fact

Re: please stop

Joey Hess jo...@debian.org writes: I'll add that the ctte is rubber-stamping Ian's wording, when that went *so* well last time. I believe this issue is at least partly caused by the fact that the work of the tech ctte has, for the last two years or so, been effectively split between just two

Bug#741573: Two menu systems

Keith Packard kei...@keithp.com writes: 1. Implement .desktop parsing support in the existing 'menu' package so that packages providing only .desktop files would be incorporated into menu programs without further change. FWIW, it seems there is at least partial support for that

Bug#741573: Please decide on a reversion of commit 3785878 in the Policy's Git repository.

Jonathan Nieder jrnie...@gmail.com writes: Charles Plessy wrote: In particular, in the absence of Bill's contribution to the resolution of our conflict, I am asking the TC to not discuss the menu systems and focus instead on correcting Bill's

Bug#727708: Additional CTTE Drafting Meeting useful?

Ian Jackson ijack...@chiark.greenend.org.uk writes: Ansgar Burchardt writes (Re: Additional CTTE Drafting Meeting useful?): In this case I suggest to decide just the question of the default init system on Linux architectures first and address further details later if no consensus can be found

Bug#727708: Call for votes on init system resolution

Russ Allbery r...@debian.org writes: Don Armstrong d...@debian.org writes: On Thu, 06 Feb 2014, Kurt Roeckx wrote: So let me expand on that a little. Image the following options - A: something that doesn't overrule the ctte (1:1) - B: something that does overrule the ctte (2:1) - FD In

Bug#727708: Vote sysvinit 4 jessie

Michael Gilbert mgilb...@debian.org writes: On Mon, Feb 3, 2014 at 11:44 PM, Nikolaus Rath wrote: Michael Gilbert writes: On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote: So all deferring for another cycle does is leave Debian with annoying cumbersome init scripts and unsolvable race

Bug#727708: Vote sysvinit 4 jessie

Michael Gilbert mgilb...@debian.org writes: On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote: So all deferring for another cycle does is leave Debian with annoying cumbersome init scripts and unsolvable race conditions for another cycle. Which have already been solved for a long time now.

Bug#727708: init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)

Bdale Garbee bd...@gag.com writes: Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following resolution: 1. The Technical Committee does not wish any resolutions it passes about the init system question(s) to stand in the face of any contrary view

Bug#727708: The tech ctte isn't considering OpenRC at all

Ian Jackson ijack...@chiark.greenend.org.uk writes: Nikolaus Rath writes (Bug#727708: The tech ctte isn't considering OpenRC at all): Ian Jackson ijack...@chiark.greenend.org.uk writes: Thomas, does OpenRC provide a means for do non-forking daemon startup ? [...] Ian, quoting from your

Bug#727708: Thoughts on Init System Debate

Andres Freund and...@anarazel.de writes: On 2014-01-19 23:18:26 -0800, Steve Langasek wrote: As you say that planned features or development could sway your opinion: are there particular features that you have in mind, here? For instance, correcting upstart's socket-based activation interface

Bug#727708: The tech ctte isn't considering OpenRC at all

Ian Jackson ijack...@chiark.greenend.org.uk writes: Thomas Goirand writes (Bug#727708: The tech ctte isn't considering OpenRC at all): But that OpenRC just hasn't been considered just because of rumors is really unacceptable. The reason I haven't seriously considered OpenRC for the default

Bug#727708: init system thoughts

Anthony Towns a...@erisian.com.au writes: To emulate systemd dependencies in an event model (ie, X depends on Y), you'd need to do either: * change Y's job to say start on starting X * add stop on stopping Y to X's job description or * add a pre-start script to X in order to

Bug#727708: init system thoughts

Hello, I am aware that this bug already has a lot of emails in it, but I think the issue below is important enough to warrant a *ping* to the upstart developers. It would be great if someone could comment on this. Best Nikolaus Nikolaus Rath nikol...@rath.org writes: Cameron Norman

Bug#727708: init system discussion status

Uoti Urpala uoti.urp...@pp1.inet.fi writes: On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote: Clint Adams cl...@debian.org writes: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: or alternatively 4. Packages may, however, depend on a specific init system (which

Bug#727708: init system discussion status

Ian Jackson ijack...@chiark.greenend.org.uk writes: | Choice of init system: | | 1. The default init(1) in jessie will be upstart. | | 2. Architectures which do not currently support upstart should try to |port it. If this is not achieved in time, those architectures may |continue

Bug#727708: init system discussion status

Clint Adams cl...@debian.org writes: On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. 4. The above criterium also extends

Bug#727708: loose ends for init system decision

Russ Allbery r...@debian.org writes: This message is about a transition plan for an init system replacement and about how to handle portability to our non-Linux ports. I'm keeping the same subject as Ian's message on the same basic topics and attaching it to the same thread, but this is more

Bug#727708: upstart and upgrading from sysvinit scripts

Steve Langasek vor...@debian.org writes: 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 upstart (beyond

Bug#727708: loose ends for init system decision

On 01/02/2014 10:20 AM, Ian Jackson wrote: Nikolaus Rath writes (Bug#727708: loose ends for init system decision): I think there is one additional questions that will probably need to be decided by the tc but hasn't really been discussed yet: Will packages that explicity depend on a (non

Bug#727708: loose ends for init system decision

On 01/02/2014 10:30 AM, Ian Jackson wrote: Nikolaus Rath writes (Re: Bug#727708: loose ends for init system decision): For example, a hypothetical future program to interactively adjust program cgroups cannot be sysvinit compatible in any meaningful sense, because it does not need

Bug#727708: init system thoughts

Colin Watson cjwat...@debian.org writes: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the

Bug#727708: init system thoughts

On 01/01/2014 04:00 PM, Nikolaus Rath wrote: My second point is that by treating dependencies as events, upstart does not seem to truly recognize dependencies as such and is then unable to resolve them. For example, with the following two job files (created according to the upstart cookbook

Bug#727708: init system thoughts

Cameron Norman camerontnor...@gmail.com writes: On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote: Colin Watson cjwat...@debian.org writes: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things

Bug#727708: init system thoughts

Cameron Norman camerontnor...@gmail.com writes: I think you raise a lot of good points in this email, but here you are saying something which may demonstrate your (understandable) confusion about the Upstart event model. Upstart does not treat dependencies as events. Often times, Upstart

Bug#727708: requires in systemd

Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: As I understand, a systemd unit with Requires=jobTwo will not start without jobTwo running. If you request the start of jobOne, without jobTwo running, systemd will start jobTwo in addition to jobOne. There's also a Requisite=

Bug#727708: upstart and upgrading from sysvinit scripts

Steve Langasek vor...@debian.org writes: On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote: I'm a bit surprised that you mention this only now, after Russ' extensive mail. Could you tell us if there are there other components in systemd that you think are similarly flawed, Why

Bug#727708: upstart and upgrading from sysvinit scripts

Steve Langasek vor...@debian.org writes: On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote: I'll have more to say about the relative merits of the two init systems later, but one thing I wanted to not briefly: this exercise was extremely valuable in helping me get a more realistic

Bug#733452: Minimal code for systemd protocol

Hello, It's already been mentioned elsewhere, but I think it should be included in this bug for reference. The minimum code to support systemd style readyness notification is (from https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ): static void notify(const char

Bug#727708: init system other points, and conclusion

Ian Jackson ijack...@chiark.greenend.org.uk writes: It does, however, have a number of missing features. Those I have in mind are: - ability to log daemon output to syslog - multiple socket activation (systemd socket activation protocol) - socket activation for IPv6 (and datagram

Bug#733452: init system daemon readiness protocol

Ian Jackson ijack...@chiark.greenend.org.uk writes: (I have cloned the bug for this, to keep this particular sub-discussion separable.) As I have reported, we have a problem with non-forking daemon readiness protocols. We have a problem seems a bit exxagerated to me. So far, the only problem

Bug#727708: Problems with upstarts event model

Hi, I just want to raise one issue that I think has not been adequately addressed by any of the position statements (it has unfortunately been deleted from the upstart page and been trimmed down a lot on the systemd page): I think an important drawback of upstart is the idea of treating

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

On 10/31/2013 09:51 PM, Russ Allbery wrote: You can, of course, be disciplined about this when writing systemd helper scripts by always exernalizing the shell script into a separate file, but I really like that upstart lets me inline trivial shell fragments without worrying about that while