Ian Jackson writes:
> Firstly, I should say that I think the CLA is utterly ridiculous.
> I want to be completely clear that like almost everyone else in this
> conversation, I would certainly not sign it.
It's divisive, and has already managed to fragment the community into
two camps. As Kay sa
Keith Packard writes ("Re: Bug#727708: init system discussion status"):
> I feel that having the Debian community endorse software where a CLA is
> involved will tacitly encourage developers to enter into those
> agreements so that their work can be published as widely as possi
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140120 12:27]:
> Keith Packard writes ("Re: Bug#727708: init system discussion status"):
> > I feel that having the Debian community endorse software where a CLA is
> > involved will tacitly encourage developers to enter int
On Mon, Jan 20, 2014 at 11:23:39AM +, Ian Jackson wrote:
> Keith Packard writes ("Re: Bug#727708: init system discussion status"):
> > I feel that having the Debian community endorse software where a CLA is
> > involved will tacitly encourage developers to enter int
Steve Langasek writes:
> I would prefer to see more neutral wording, something to the effect
> of:
I didn't mean that the TC decision should mention the CLA. I don't think
that's an appropriate place for this kind of statement.
--
keith.pack...@intel.com
pgpixwDU4Pjfm.pgp
Description: PGP si
On Sun, Jan 05, 2014 at 12:16:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> git notes are used to mark backport-worthy commits. See
> http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
> We currently mark patches as bugfixes (which includes fixes for bugs
> present i
Josh Triplett writes ("Bug#727708: init system discussion status"):
> I don't subscribe to debian-ctte@; I read it via the list archives.
> I've been replying using the "Reply to:" links at the bottom of mails,
> and then manually copying and quoting the resp
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"
Ian Jackson writes:
> Andreas, Bdale, Don, Keith: please let us know what you're thinking,
> and what more information/discussion would be useful.
As the newest TC member, I hope to emulate my learned colleagues and try
to keep the discussion moving in a positive direction.
First off, my person
Keith Packard writes ("Bug#727708: init system discussion status"):
> In contrast, upstart has a developer community limited to Canonical
> employees and others who are able and willing to sign the onerous CLA
> associated with that software. [...]
You said on IRC that the C
So we know where Colin, Steve, Russ and I stand on the main question.
If we want to make a decision soon we need to start to thrash out the
details so that we have something concrete to vote on.
It would be helpful to know how far along the other TC members are.
So:
Andreas, Bdale, Don, Keith: pl
Ian Jackson writes:
> Andreas, Bdale, Don, Keith: please let us know what you're thinking,
> and what more information/discussion would be useful.
Right. I've meant to post something before now, but after returning
home from a family road trip over the holidays, I was hit by a nasty
cold. Feel
Bdale Garbee writes ("Bug#727708: init system discussion status"):
> [stuff]
Thanks for posting your views.
You'll have seen Russ's comments on the details and loose ends as I
call them. Russ and I were mostly agreed on these points.
I have written a draft resolution fr
Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> I have written a draft resolution from my own point of view and
> checked it into the tech-ctte git repo. Perhaps some of it is useful.
> Ansgar commented a bit on it on IRC. I guess I should post i
On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:
> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> > I have written a draft resolution from my own point of view and
> > checked it into the tech-ctte g
Cameron Norman writes ("Re: Bug#727708: init system discussion status"):
> On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
> ijack...@chiark.greenend.org.uk> wrote:
...
> | 9. [ Policy should provide non-binding suggestions to Debian
> > |contributors who are co
Cameron Norman writes:
> Should it not be added that raise(SIGSTOP) should only be used with a
> command line option (like --debian-Z) to ensure that the daemon does not
> hang on sysv or systemd?
No, because see Colin's point that Debian developers may be doing the
integration and adding a new
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Cameron Norman writes:
> > Should it not be added that raise(SIGSTOP) should only be used with a
> > command line option (like --debian-Z) to ensure that the daemon does not
> > hang on sysv o
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
>> I have written a draft resolution from my own point of view and checked
>> it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar
>> commented a bit on it
Ian Jackson writes:
> I think it would be reasonable to state that the raise(SIGSTOP)
> integration should be done with a new command line option OR a new
> environment variable; ie that the daemon should not be changed to
> raise(SIGSTOP) by default.
Agreed.
> I don't know whether it's valuabl
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Thank you very much for writing this. (And, in general, thank you for
> often taking the initiative in producing drafts. It's something that I
> find difficult, and I really appreciate your work on it.
]] Ian Jackson
> I think it would be reasonable to state that the raise(SIGSTOP)
> integration should be done with a new command line option OR a new
> environment variable; ie that the daemon should not be changed to
> raise(SIGSTOP) by default.
I don't see why you think that doing so because a
Tollef Fog Heen writes:
> ]] Ian Jackson
>> I think it would be reasonable to state that the raise(SIGSTOP)
>> integration should be done with a new command line option OR a new
>> environment variable; ie that the daemon should not be changed to
>> raise(SIGSTOP) by default.
> I don't see why
Ian Jackson 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 to use sysvinit. [ Non-
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
> Ian Jackson 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 of a sysvinit script (fo
Nikolaus Rath writes ("Bug#727708: init system discussion status"):
> 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.
I agree with this.
> 4. The above cri
Uoti Urpala wrote:
> Suppose an upstream releases a new daemon that is intended
> to be used with systemd using socket activation, and as such does not
> contain any code to do double-forking or open listening sockets. Would
> it be forbidden to package this daemon in Debian unless the maintainers
"Alexander E. Patrakov" writes:
> Uoti Urpala wrote:
>> Suppose an upstream releases a new daemon that is intended to be used
>> with systemd using socket activation, and as such does not contain any
>> code to do double-forking or open listening sockets. Would it be
>> forbidden to package this
Russ Allbery writes ("Bug#727708: init system discussion status"):
> The thrust of this seems right, but I dislike telling people what to do.
> Can we recast this in a way that avoids that problem? Maybe something
> like:
Sure. I borrowed your text and edited it slightly f
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> Another issue, which I did not address here but which we should
>> probably say something about, is that the init process 1 implementation
>> and the system used to run d
Ian Jackson writes:
> Sure. I borrowed your text and edited it slightly for clarity. I also
> changed "upstart/systemd" to "upstart", for two reasons: one is that at
> this stage I'd prefer to try to maintain only one version of this text.
Yeah, that's fine. We can hammer out the details of o
On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote:
> Ian Jackson writes:
> > I've written a version of Niklaus's rule about dependencies:
>
> >Likewise, packages must not Depend on or Recommend (directly or
> >indirectly) a specific init(1). Violations of this are also an RC
> >b
Uoti Urpala writes:
> One case to consider is what should happen with GNOME if it requires
> interfaces that nobody has implemented for sysvinit.
The likelihood of this and possible impact is one of the things that I'm
checking on. I'd rather not have the argument if it turns out not to be
some
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 to dependencies that are not related
Clint Adams writes:
> As loath as I am to participate in this discussion, I have to ask if
> your intent is to suddenly outlaw all the packages which depend on
> runit.
I don't think runit (or daemontools) are init systems. If you feel like
that may be ambiguous, we should say that explicitly.
On Fri, Jan 3, 2014 at 7:17 PM, Russ Allbery wrote:
> Clint Adams writes:
>
> > As loath as I am to participate in this discussion, I have to ask if
> > your intent is to suddenly outlaw all the packages which depend on
> > runit.
>
> I don't think runit (or daemontools) are init systems. If yo
Josh Triplett writes:
> I think it'd be appropriate to allow dependencies on runit (or another
> package that contains an implementation of /sbin/init), as long as
> either the depending package doesn't depend on having /sbin/init be that
> init (which holds true for runit), *or* if an alternativ
Clint Adams 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 to depen
Russ Allbery writes:
>> I've written a version of Niklaus's rule about dependencies:
Just for the record, my suggestion was to include language that
regulates dependencies on the init system, but I do not have any
preferences whether they should be allowed or forbidden.
>>Likewise, packages
On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
> Clint Adams 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 may
> >>not be the default init) for features t
Russ Allbery writes:
> My inclination would be to give maintainers technical advice to accept
> integrations with either existing synchronization protocols, but leave it
> as technical advice rather than the binding part of the decision.
I strongly agree.
Bdale
pgp5ex_rCH3W3.pgp
Description:
On Fri, 2014-01-03 at 18:41 -0800, Russ Allbery wrote:
> Uoti Urpala writes:
>
> > One case to consider is what should happen with GNOME if it requires
> > interfaces that nobody has implemented for sysvinit.
>
> The likelihood of this and possible impact is one of the things that I'm
> checking
Bdale Garbee writes ("Bug#727708: init system discussion status"):
> Russ Allbery writes:
> > My inclination would be to give maintainers technical advice to accept
> > integrations with either existing synchronization protocols, but leave it
> > as technical advi
Uoti Urpala writes ("Bug#727708: init system discussion status"):
> There are two different kinds of dependencies: dependencies expressed in
> package metadata, and functional dependencies (as in whether the package
> does anything useful with another init). Your earlier wordi
Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit :
> Uoti Urpala writes ("Bug#727708: init system discussion status"):
> > Your earlier wording sounds
> > like it was talking about the former ("installable") and Ian's proposal
> > defini
Ian Jackson writes:
> Bdale Garbee writes ("Bug#727708: init system discussion status"):
>> Russ Allbery writes:
>>> My inclination would be to give maintainers technical advice to accept
>>> integrations with either existing synchronization protocols,
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > Would that suit you both ?
>
> I may have lost the thread here, but that doesn't sound quite right.
> Wouldn't we want to say that each daemon package should impl
Sjoerd Simons writes:
> Essentially this boils down to whether the logind interfaces will be
> available when using sysvinit. Most of the other interfaces (at least
> for current gnome as in experimental) would cause some functionality to
> either be missing or not work, but wouldn't yield a comp
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> I may have lost the thread here, but that doesn't sound quite right.
>> Wouldn't we want to say that each daemon package should implement the
>> native non-fork
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > Are the protocols offered by systemd and upstart each so plainly
> > reasonable, that we are willing to overrule a maintainer who feels they
> > protocol they are
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > And the other is that IMO the proposed prescription for non-Linux ports
> > doesn't make sense for systemd. There is little prospect of systemd
> > being "por
(Josh, is there some reason why you replied to the TC list directly
rather than the bug report ? You should send your messages to the bug
so they are filed, displayed and archived there. Thanks.)
Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
> Clint Adams
Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> Are you going to vote to overrule a maintainer who says
>
> I have already implemented non-forking readiness protocol X and I
> think support for all init systems in my daemon should be done via
>
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> I think they are. Furthermore, I don't think there's any likely
>> prospect that either will adopt a socket-based synchronization protocol
>> other than syste
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson writes:
> > It seems daft to go around making two (or perhaps three or more) patches
> > to every daemon when one patch to each daemon, and a couple of
> > compatibility modes in
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> Whether systemd upstream should support the SIGSTOP protocol is
>> certainly debatable, but I'm very reluctant to support an option that
>> tries to force the systemd
Ian Jackson writes:
> The question isn't what you would prefer. The question is this:
> Are you going to vote to overrule a maintainer who says
> I have already implemented non-forking readiness protocol X and I
> think support for all init systems in my daemon should be done via
> one
Russ Allbery writes ("Bug#727708: init system discussion status"):
> I consider the TC, when working properly, to be like a court, not an
> executive or legislature.
One of our roles is to rule on the content of policy. That's much
more like a legislative role.
I think w
On 4 January 2014 15:46, Josselin Mouette wrote:
> Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit :
>> Uoti Urpala writes ("Bug#727708: init system discussion status"):
>> > Your earlier wording sounds
>> > like it was talking about the form
On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
> > And the other is that IMO the proposed prescription for non-Linux ports
> > doesn't make sense for systemd. There is little prospect of systemd
> > being "ported" to those systems.
> I'd prefer to leave it in. Upstream's opinions
Steve Langasek writes:
> On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
>> I'd prefer to leave it in. Upstream's opinions aside, systemd is free
>> software and if someone wants to try to port it (or, possibly more
>> likely, "port" it by writing something native that provides the
On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> > ... (Note that the latter would work better if upstart stopped
> > conflicting with sysvinit, similar to how systemd can be installed
> > without being init.)
> There does seem to need to be some work there.
That has already been r
]] Russ Allbery
> 2. Package logind separately from systemd, get it working with sysvinit.
>The problems with doing this, as I understand it, is that we'd not be
>able to upgrade such a separately-packaged logind beyond 204 for
>jessie. I'm not sure how much impact that would have.
Russ Allbery writes ("Bug#727708: init system discussion status"):
> I thought that was already resolved? I objected to the "should" in the
> original language regarldess of which init system we choose, and Ian said
> that he'd reworded it already to something ak
On Sat, Jan 04, 2014 at 11:08:36AM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
> >> I'd prefer to leave it in. Upstream's opinions aside, systemd is free
> >> software and if someone wants to try to port it (or, possibly m
]] Dimitri John Ledkov
> Also which upstream are staying with? systemd upstream git history[4]
> has only one branch, which is linear with linear version number
> increments, without any stable release branches or other indications
> of which patches are stable (or possibly security) bugfixes.
T
ople who have requested mbox archives in the past.
> Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
> > Clint Adams wrote:
> > > As loath as I am to participate in this discussion, I have to ask
> > > if your intent is to suddenly outla
On Sat, Jan 04, 2014 at 11:27:26AM -0800, Steve Langasek wrote:
> On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> > > ... (Note that the latter would work better if upstart stopped
> > > conflicting with sysvinit, similar to how systemd can be installed
> > > without being init.)
>
On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
> Sjoerd Simons writes:
> > Not having the logind interface is a lot harder to cope with and
> > something that will not only impact Gnome. So essentially the most
> > likely impact of using sysvinit _without_ a provider of the logind
> > int
On Sat, Jan 04, 2014 at 06:59:46PM +, Dimitri John Ledkov wrote:
> Also it is sad that systemd upstream is actively promoting for
> everyone to execute runtime checks of is systemd-init pid1,...
This is done public systemd libraries to become NOPs if not running on
or not compiled for systemd,
Uoti Urpala writes:
> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
>> Clint Adams 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 may
>> >>not be the
On 4 January 2014 23:16, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jan 04, 2014 at 06:59:46PM +, Dimitri John Ledkov wrote:
>> Also it is sad that systemd upstream is actively promoting for
>> everyone to execute runtime checks of is systemd-init pid1,...
> This is done public systemd libra
On 5 January 2014 00:07, Nikolaus Rath wrote:
> Uoti Urpala writes:
>> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
>>> Clint Adams writes:
>>> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
>>> >> or alternatively
>>> >>
>>> >> 4. Packages may, however, depend on a
Dimitri John Ledkov writes:
> This confirms that systemd is not generic across all upstreams and all
> distributions, and everyone is maintaining their own (in part influenced
> by release cadence, and well distro-specific integration) Having git
> repos, or even distro specific branches on Freed
On 4 January 2014 23:13, Sjoerd Simons wrote:
> On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
>> Sjoerd Simons writes:
>
>> > Not having the logind interface is a lot harder to cope with and
>> > something that will not only impact Gnome. So essentially the most
>> > likely impact of usi
Dimitri John Ledkov writes:
> On 5 January 2014 00:07, Nikolaus Rath wrote:
>> I think that if a program functionally depends on another, but the
>> package does not declare this dependency, then it's a bug. So in this
>> context I consider functional dependencies and package dependencies to
>>
On 5 January 2014 01:26, Russ Allbery wrote:
> Dimitri John Ledkov writes:
>
>> This confirms that systemd is not generic across all upstreams and all
>> distributions, and everyone is maintaining their own (in part influenced
>> by release cadence, and well distro-specific integration) Having gi
Dimitri John Ledkov writes:
> Imho that's a gross overstatement. Over more than a year, an Ubuntu
> GNOME team was established and became official ubuntu flavour with so
> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
> is any indication they are fast growing ubuntu flav
Dimitri John Ledkov writes:
> On 5 January 2014 01:26, Russ Allbery wrote:
>> I'm amused by this comment given that one of the points of criticism of
>> systemd prior to this (by people other than yourself, to be clear) was
>> that the systemd maintainers were unwilling to apply and carry
>> nec
On 4 January 2014 19:42, Tollef Fog Heen wrote:
> ]] Dimitri John Ledkov
>
>> Also which upstream are staying with? systemd upstream git history[4]
>> has only one branch, which is linear with linear version number
>> increments, without any stable release branches or other indications
>> of which
On 5 January 2014 01:46, Russ Allbery wrote:
> Dimitri John Ledkov writes:
>
>> Imho that's a gross overstatement. Over more than a year, an Ubuntu
>> GNOME team was established and became official ubuntu flavour with so
>> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
>
On Jan 5, 2014 2:39 AM, "Russ Allbery" wrote:
> I'm doubtful that either of us are going to convince the other on this
> point. I don't consider it comparable to the other examples you're
> citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
> choice. Simple, yes, but that
Dimitri John Ledkov writes:
> I see thanks. I guess the only relevant addition, is that there is a
> pool of self-selected developers that are working on the similar type of
> integration issues: GNOME3 with logind without systemd-init. The Ubuntu
> GNOME team (packaging team is 18 people at the
Anthony Towns writes:
> On Jan 5, 2014 2:39 AM, "Russ Allbery" wrote:
>> I'm doubtful that either of us are going to convince the other on this
>> point. I don't consider it comparable to the other examples you're
>> citing, and I think it's inobvious that raise(SIGSTOP) is a good
>> technical
Le Sun, Jan 05, 2014 at 02:11:41AM +, Dimitri John Ledkov a écrit :
>
> at least following any of the practices adviced by the debian policy - patch
> target, 3.0 (quilt) format
Dear Dimitri,
the Debian Policy does not recommend one source format over another.
Have a nice day,
--
Charles
On Jan 5, 2014 10:40 AM, "Russ Allbery" wrote:
> Anthony Towns writes:
> > How hard would it be to write an external wrapper that converts the
> > systemd style socket activation to the SIGSTOP protocol (for upstart
> > invoking a systemd compatible daemon)?
On second thoughts, I think I meant t
Anthony Towns writes:
> On Jan 5, 2014 10:40 AM, "Russ Allbery" wrote:
>> Anthony Towns writes:
>>> How hard would it be to write an external wrapper that converts the
>>> systemd style socket activation to the SIGSTOP protocol (for upstart
>>> invoking a systemd compatible daemon)?
> On secon
Russ Allbery writes:
> This, sadly, is slightly harder, since you can't use this hack:
>>> The wrapper could fork and then exec the daemon in the *parent*, and
>>> have the *child* listen for the notification message and then
>>> kill(SIGSTOP) its parent and immediately exit. I wonder if that w
On Sun, Jan 05, 2014 at 12:54:04AM +, Dimitri John Ledkov wrote:
> So components inside systemd-source tree do not follow what's advised
> to all other projects: e.g. link or statically include sd_* helper
> files, and perform runtime checks?
The advice for other projects assumes that systemd i
On Sun, Jan 05, 2014 at 02:11:41AM +, Dimitri John Ledkov wrote:
> > Were you unable to find
> > http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ? It's where
> > Fedora has all of their packaging..
>
> As explained by Zbigniew Jędrzejewski-Szmek, that is not actually
> where that hap
]] Dimitri John Ledkov
> >> Fedora/RPM based distributions are significantly different, thus it is
> >> inevitable that we'll have to maintain a fork of systemd for best
> >> integration into Debian. This does not seem evident from the current
> >> systemd maintainers, which file bugs to disable/
On Sun, 2014-01-05 at 02:18 +, Dimitri John Ledkov wrote:
> On 5 January 2014 01:46, Russ Allbery wrote:
> > Dimitri John Ledkov writes:
> >
> >> Imho that's a gross overstatement. Over more than a year, an Ubuntu
> >> GNOME team was established and became official ubuntu flavour with so
> >>
Le samedi, 4 janvier 2014, 19.10:21 Josh Triplett a écrit :
> Dimitri John Ledkov wrote:
> > Rejections on mailinglists and else where to split:
> > /lib/systemd/systemd-multi-seat-x
> > /lib/systemd/systemd-timedated
> > /lib/systemd/systemd-localed
> > /lib/systemd/systemd-logind
> > /lib/systemd
Le dimanche 05 janvier 2014 à 01:37 +, Dimitri John Ledkov a écrit :
> > Patching upstream unit files to change paths is trivial, but even better
> > would be to convince upstream to substitute in the proper path when
> > building the unit file.
> Oh that indeed would be wonderful, why did sys
Hello,
On Sat, 04 Jan 2014 16:46:28 +0100
Josselin Mouette wrote:
> > I think systemd-ui is part of the systemd init system so falls into
> > the exception. Of course that means that nothing else should depend
> > (functionally or in package dependencies) on it.
> There is no way that, for exa
95 matches
Mail list logo
