Bug#727708: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.

2014-01-29 Thread Matthias Klumpp
2014-01-30 ChaosEsque Team :
>  [bullshit]

Wasn't there some kind of a ban applied here?
I am confused.
Cheers,
Matthias


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-DLwHwO-UOwnpe1X5qUsxzYZyy=yaoly9+8wtqkdi...@mail.gmail.com



Bug#727708: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.

2014-01-29 Thread ChaosEsque Team
 >If you don't like the software, don't use it.

Absolutely. But that is not really an option that is to be afforded to all of 
us if
the systemd guys successfully have their way with linux.

It would be nice if they afforded us such a freedom, but their statements 
and their actions suggest that this would be a one way street:

They "convince" as many pieces of the "software stack" as possible
to depend on systemd, and we can go use "an embedded system or something"
(yes that's a quote from one of the systemders) if we don't like it.

When they came here their proposal was to remove all other init systems 
from Debian, and force everyone to use systemd.

They are here to conquer. In time the statement would read:
"If you don't like systemd, don't use linux - get a mac or something *SNCR*"

They have conquered a good number of other distributions, now it is time
to bring Debian, too, into the fold.

>Given that, your opinions about the quality of GNOME upstream development
>don't seem relevant to the problem we're trying to resolve.  If you don't
>like the software, don't use it.  And please don't hold opinions about the
>proper packaging of software you don't like and don't believe is
>well-written!  That's just intensely irritating and comes across as
>malicious sniping.  Let the people who are interested in making the
>software work figure out what that entails.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1391041442.788.yahoomailba...@web141701.mail.bf1.yahoo.com



Bug#727708: Re: Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread ChaosEsque Team
This sounds like a good solution, since MATE is the gnome we all knew, and the 
Gnome of today is a different beast entirely (though it gets to keep the name).
::
>Hum, we can always add “remove GNOME (3) from Debian” to the
>list of GR or TC points to consider (this *has* been suggested
>earlier, even)… and given that MATE seems to have picked up
>the market of GNOME…


>This is more of a threat than a promise.
There are alot of those from a certain crowd. 
They use the carrot and the stick approach.
The proper free/open approach is just the carrot and let people decide and 
respect them.
Not cattle pen them and run them to wherever one wishes.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1391040676.71762.yahoomailba...@web141702.mail.bf1.yahoo.com



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Russ Allbery
Andrew Shadura  writes:
> Josselin Mouette  wrote:

>> Gnome-shell uses GDM for screen locking, and GDM heavily relies on
>> logind nowadays. There is fallback code that uses ConsoleKit, but it
>> has been untested for several major releases, and now fails even for
>> trivial things. Add to that the fact that ConsoleKit itself has been
>> unmaintained for quite some time, making it unsuitable for a new stable
>> release that needs maintenance for several more years

> That only confirms the fact GNOME developers can't even keep their code
> working, not even speaking about testing its interoperability with most
> common environments. That doesn't create a good reputation, you know.

The point of this discussion is to determine the set of constraints we
have around dependencies on either init systems or components closely tied
to init systems.  GNOME's reputation for portability or code stability,
for good or for ill, is not directly relevant; what's relevant is whether
the software works or does not work in particular configurations, and what
the implications are for package dependencies within Debian.  Whether or
not GNOME itself is stable, portable, or to your liking is only relevant
if the project believes it is so unstable or so uninteresting that we're
not going to ship it in jessie, and I don't believe there is any realistic
chance we would pick that option.

Given that, your opinions about the quality of GNOME upstream development
don't seem relevant to the problem we're trying to resolve.  If you don't
like the software, don't use it.  And please don't hold opinions about the
proper packaging of software you don't like and don't believe is
well-written!  That's just intensely irritating and comes across as
malicious sniping.  Let the people who are interested in making the
software work figure out what that entails.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3di1ind@windlord.stanford.edu



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread James Rhodes
On 30 January 2014 09:54, Andrew Shadura  wrote:

> Hello,
>
> On Wed, 29 Jan 2014 19:17:29 +0100
> Josselin Mouette  wrote:
>
> > Gnome-shell uses GDM for screen locking, and GDM heavily relies on
> > logind nowadays. There is fallback code that uses ConsoleKit, but it
> > has been untested for several major releases, and now fails even for
> > trivial things. Add to that the fact that ConsoleKit itself has been
> > unmaintained for quite some time, making it unsuitable for a new
> > stable release that needs maintenance for several more years
>
> That only confirms the fact GNOME developers can't even keep their code
> working, not even speaking about testing its interoperability with
> most common environments. That doesn't create a good reputation, you
> know.
>

Why do you expect GNOME developers to maintain support for ConsoleKit, when
it's been deprecated and unmaintained for several years?  It's not the
responsibility of the GNOME developers to pick up maintenance of ConsoleKit
and to suggest that not doing this is representative of their quality as
developers is borderline offensive.

GNOME developers do keep their code working, against what they've stated
they will support.  That happens to be logind.

(Apologies if I'm not replying to this bug correctly as it's my first time
emailing against a Debian bug)

Regards, James.


Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Olav Vitters
On Wed, Jan 29, 2014 at 11:54:11PM +0100, Andrew Shadura wrote:
> On Wed, 29 Jan 2014 19:17:29 +0100
> Josselin Mouette  wrote:
> 
> > Gnome-shell uses GDM for screen locking, and GDM heavily relies on
> > logind nowadays. There is fallback code that uses ConsoleKit, but it
> > has been untested for several major releases, and now fails even for
> > trivial things. Add to that the fact that ConsoleKit itself has been
> > unmaintained for quite some time, making it unsuitable for a new
> > stable release that needs maintenance for several more years
> 
> That only confirms the fact GNOME developers can't even keep their code
> working, not even speaking about testing its interoperability with
> most common environments. That doesn't create a good reputation, you
> know.

Almost all of our developers are either using systemd, or they're using
something which provides logind (Ubuntu). Even Gentoo has started
depending on systemd (thus logind, etc) for GNOME.

In short: for the most common environment, GNOME is damn stable and very
well tested.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129230320.ge8...@bkor.dhs.org



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Andrew Shadura
Hello,

On Wed, 29 Jan 2014 19:17:29 +0100
Josselin Mouette  wrote:

> Gnome-shell uses GDM for screen locking, and GDM heavily relies on
> logind nowadays. There is fallback code that uses ConsoleKit, but it
> has been untested for several major releases, and now fails even for
> trivial things. Add to that the fact that ConsoleKit itself has been
> unmaintained for quite some time, making it unsuitable for a new
> stable release that needs maintenance for several more years

That only confirms the fact GNOME developers can't even keep their code
working, not even speaking about testing its interoperability with
most common environments. That doesn't create a good reputation, you
know.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature


Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Olav Vitters
On Wed, Jan 29, 2014 at 08:45:32PM +, Thorsten Glaser wrote:
> Matthias Klumpp dixit:
> 
> >No, Josselin is right: GNOME *does not* work without services provided
> >by systemd. He never said that - given some amount of work - it can't
> 
> Hum, we can always add “remove GNOME (3) from Debian” to the
> list of GR or TC points to consider (this *has* been suggested
> earlier, even)… and given that MATE seems to have picked up
> the market of GNOME…

As agreed privately, please don't talk about GNOME. Your suggestions
don't make much sense and you don't know what you're talking about
anyway. Your continued characterization of GNOME (e.g. "threat") while
knowing nothing is quite sad.

Apologies to the rest reading this…

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014012925.gd8...@bkor.dhs.org



Bug#728486: Draft of Resolution for 728486 (lvm/systemd compatibility)

2014-01-29 Thread Josh Triplett
Don Armstrong wrote:
> Below is the current draft of a resolution to resolve 728486. I have one
> current comment in the draft which I would like clarified. [CTTE
> members: please comment/suggest change.] I also expect to change the
> reference to the patch to a newly updated patch with the changes
> suggested in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#183.
> 
> ==BEGIN DRAFT==
> 
> When systemd is in operation in conjunction with lvm and lvmetad is
> not in use, lvchange -aay must be called after udevadm --settle which
> is provided by systemd-udev-settle.service, and before (and after)
> encrypted devices are configured (cryptsetup.target).
> 
> ==COMMENT==
> Is there any case where udevadm --settle would be required after the
> encrypted devices are configured? Does cryptsetup.target ensure that
> udev has triggered the appropriate rules for the newly configured
> encrypted devices?
> ==END COMMENT==
> 
> The patch prepared by Michael Stapelberg  in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#163 installs
> the two systemd unit files necessary to properly configure lvm devices
> when systemd is running, and additionally configures systemd-tmpfiles.d to
> create the lockfile directories required by systemd.
> 
> Therefore, the CTTE:
> 
> A. Overides the objection of the maintainer of lvm (Bastian Blank
> ) to this patch, and directs the maintainer to
> accept this patch or alternatively, authorizes an NMU to implement
> this patch.

One minor nit for this draft: the ruling should not exclude the
possibility of enhancing LVM in the future to handle dynamically added
devices *without* using systemd-udev-settle.service.  (That may occur by
using lvmetad in cases where it works, for instance.)

Suggested change, if a TC member agrees: leave all the existing content,
but add an additional paragraph right before the "Therefore" saying:
"Nothing in this ruling should be taken to block future changes to LVM
to support dynamic discovery of devices without the need for udevadm
--settle or systemd-udev-settle.service; in the event such changes fully
obsolete the patch in question, the patch may be dropped."

Does that sound reasonable?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129221933.GA16719@jtriplet-mobl1



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Russ Allbery
Adrian Bunk  writes:
> On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:

>> I'm still wondering if maybe there's just a communication failure here, so
>> let me try one more round.

>> My understanding of what Josselin is saying is that GNOME's ConsoleKit
>> support is effectively unmaintained and unsupported upstream, as is
>> ConsoleKit itself.  The consequences of that are starting to show in a
>> variety of unfixed bugs.
>>...

> No, Josselin was making the technical claim that GNOME 3.10 would need a 
> working logind even for basic functionality.

> So if it is possible to get the basic functionality of GNOME 3.10 
> without a working logind, his claim is just plain wrong.

> And when I was asking him for the technical details that would back up
> such a strong claim, he was not able to deliver.

He delivered exactly what you asked for, and you then deleted his response
and claimed he didn't provide it.  Then you did the same thing to me.

It looks like Josselin's response to you was the correct one, and I will
now follow his lead, do what I should have done a while back, and stop
responding to your email messages on this topic, since I don't believe
you're discussing in good faith.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vbx233ou@windlord.stanford.edu



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Adrian Bunk
On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote:
> 2014-01-29 Adrian Bunk :
> > [...]
> > 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 functionality without systemd.
> >
> > But claims that even basic functionality in GNOME in jessie could not
> > work without logind might just be FUD.
> >
> > The TC can rule that systemd will be the default for jessie and that
> > dependencies on systemd will be OK if a maintainer wishes do add them,
> > but such a decision should be based on facts and not on unproven
> > "GNOME needs it" claims.
> No, Josselin is right: GNOME *does not* work without services provided
> by systemd.

How did you verify that this claim you are making here is actually true?


> He never said that - given some amount of work - it can't
> be made working. But given the limited resources of the GNOME team, I
> can fully understand why they don't want to make the other solutions
> work (e.g. by taking over ConsoleKit maintenance).
> So, Joss' statement is correct.
>...

No, it is not correct.

Note that Josselin's statement [1]

  I also have to insist that GNOME 3.10+ *needs* a working logind even for
  basic functionality, and that starting with v205, logind *needs* systemd
  as PID 1. You might disagree with the implementation details that lead
  to this situation, but you should not expect either of these facts to
  change before jessie.

does not mention any resource problem.[2]

Neither does his statement contain any mentioning of ConsoleKit 
maintainership - and taking over ConsoleKit maintainership
would anyway not fix the alleged "GNOME 3.10+ *needs* a working logind".

He plainly claims that logind would be required for GNOME.

And you are wrong when you claim "He never said that it can't be made 
working." In fact, what Josselin insists on there is that starting with 
GNOME 3.10 no version of GNOME before jessie will be able to provide 
even basic functionality without logind.


> Cheers,
> Matthias
>...

cu
Adrian

[1] https://lists.debian.org/debian-ctte/2014/01/msg00360.html
[2] in which case a call for people working on that would be more
appropriate

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129205726.gh5...@bunk.dyndns.info



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Thorsten Glaser
Matthias Klumpp dixit:

>No, Josselin is right: GNOME *does not* work without services provided
>by systemd. He never said that - given some amount of work - it can't

Hum, we can always add “remove GNOME (3) from Debian” to the
list of GR or TC points to consider (this *has* been suggested
earlier, even)… and given that MATE seems to have picked up
the market of GNOME…

>Also, have in mind that logind provides the basis for some additional
>features (e.g. real multiseat-support, sane closing of applications on
>logout, shutdown inhibitions etc.) and that systemd/logind is required
>for using Wayland, and GNOME is definitively going that road. Also,

This is more of a threat than a promise.

>gnome-session codepath wil bitrot soon as well. And even on KDE we are
>evaluating that option[1], so it's not just GNOME going that way.

As long as it’s still evaluating… the evaluation can result in
“let’s do a more sane thing, after all GNOME got kicked off Debian
for requiring systemd”.

I *still* don’t see a problem with keeping sysvinit with sysv-rc,
which I’m not overly fond of but which is still better than the
alternatives – and all packages have sysvinit scripts already
*anyway* so there is no added maintenance burden except for those
who do wish to support other inits, which, in turn, can run the
existing initscripts. My favourite option would thus be to keep
sysvinit/sysv-rc forever, keep it as default for jessie, and do
not permit any package to depend on an init implementation, but
allow packages to degrade if the currently active init (be it
the default init or not) does not support everything needed (i.e.
no “allow degrade iff a default init is chosen” or “allow degrade
iff a non-default init is chosen”).

bye,
//mirabilos
-- 
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1401292040040.9...@herc.mirbsd.org



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Matthias Klumpp
2014-01-29 Adrian Bunk :
> [...]
> 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 functionality without systemd.
>
> But claims that even basic functionality in GNOME in jessie could not
> work without logind might just be FUD.
>
> The TC can rule that systemd will be the default for jessie and that
> dependencies on systemd will be OK if a maintainer wishes do add them,
> but such a decision should be based on facts and not on unproven
> "GNOME needs it" claims.
No, Josselin is right: GNOME *does not* work without services provided
by systemd. He never said that - given some amount of work - it can't
be made working. But given the limited resources of the GNOME team, I
can fully understand why they don't want to make the other solutions
work (e.g. by taking over ConsoleKit maintenance).
So, Joss' statement is correct.
Also, have in mind that logind provides the basis for some additional
features (e.g. real multiseat-support, sane closing of applications on
logout, shutdown inhibitions etc.) and that systemd/logind is required
for using Wayland, and GNOME is definitively going that road. Also,
there are plans to make systemd --user manage a GNOME session, so the
gnome-session codepath wil bitrot soon as well. And even on KDE we are
evaluating that option[1], so it's not just GNOME going that way.
Cheers,
Matthias

[1] Fallbacks in place, but I don't know anyone who likes working on startkde...
-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caknhny-yynvxrpgd0v-hozkjjgj4kfbk1arxk48se-3tbk2...@mail.gmail.com



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Adrian Bunk
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
> Adrian Bunk  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 without
> >>> logind?
> 
> >>> Note that I am not referring to bugs that are not yet sorted out like
> >>>   * Switch from consolekit to systemd-logind sessions. For some reason
> >>> gnome-shell 3.10 unlocking fails with consolekit...
> >>> 3 months ago in gdm3 - I am referring to basic functionality that is 
> >>> simply missing in GNOME 3.10 without logind.
> 
> >> You have the answer to your own question above. Unlocking the screen
> >> sounds like pretty basic functionality.
> 
> > Your statement was
> >   I also have to insist that GNOME 3.10+ *needs* a working logind even for
> >   basic functionality
> 
> > Are you saying that there are only some bugs to get sorted out for using 
> > GNOME 3.10 without logind, or is there a fundamental technical reason
> > why some *basic functionality* (which?) cannot be made working in
> > GNOME 3.10 without logind?
> 
> I'm still wondering if maybe there's just a communication failure here, so
> let me try one more round.
> 
> My understanding of what Josselin is saying is that GNOME's ConsoleKit
> support is effectively unmaintained and unsupported upstream, as is
> ConsoleKit itself.  The consequences of that are starting to show in a
> variety of unfixed bugs.
>...

No, Josselin was making the technical claim that GNOME 3.10 would need a 
working logind even for basic functionality.

So if it is possible to get the basic functionality of GNOME 3.10 
without a working logind, his claim is just plain wrong.

And when I was asking him for the technical details that would back up 
such a strong claim, he was not able to deliver.

And that does matter a lot, since such claims seem to be the basis
of all these "GNOME in jessie needs systemd" or "with multiple init 
systems, GNOME will need a dependency on systemd" (and Josselin even 
expects an exception from the release managers for that if the TC 
decision would not allow such a dependency [1]).


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 functionality without systemd.

But claims that even basic functionality in GNOME in jessie could not 
work without logind might just be FUD.


The TC can rule that systemd will be the default for jessie and that 
dependencies on systemd will be OK if a maintainer wishes do add them, 
but such a decision should be based on facts and not on unproven
"GNOME needs it" claims.


cu
Adrian

[1] https://lists.debian.org/debian-ctte/2014/01/msg00460.html

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129201325.gg5...@bunk.dyndns.info



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Russ Allbery
Adrian Bunk  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 without
>>> logind?

>>> Note that I am not referring to bugs that are not yet sorted out like
>>>   * Switch from consolekit to systemd-logind sessions. For some reason
>>> gnome-shell 3.10 unlocking fails with consolekit...
>>> 3 months ago in gdm3 - I am referring to basic functionality that is 
>>> simply missing in GNOME 3.10 without logind.

>> You have the answer to your own question above. Unlocking the screen
>> sounds like pretty basic functionality.

> Your statement was
>   I also have to insist that GNOME 3.10+ *needs* a working logind even for
>   basic functionality

> Are you saying that there are only some bugs to get sorted out for using 
> GNOME 3.10 without logind, or is there a fundamental technical reason
> why some *basic functionality* (which?) cannot be made working in
> GNOME 3.10 without logind?

I'm still wondering if maybe there's just a communication failure here, so
let me try one more round.

My understanding of what Josselin is saying is that GNOME's ConsoleKit
support is effectively unmaintained and unsupported upstream, as is
ConsoleKit itself.  The consequences of that are starting to show in a
variety of unfixed bugs.

In one sense, that's "just" bugs to be sorted out.  However, they're
upstream bugs in code that upstream appears to no longer be interested in
supporting, and they're bugs that the Debian GNOME maintainers are
unenthused about trying to fix, since that would effectively require
taking over maintenance of the ConsoleKit code upstream.  (Not to mention
that the logind code path appears to be technically much better and have a
much stronger future, so it's hard to get motivated to work on the
ConsoleKit code.)

In other words, they're bugs with no resources currently assigned.  Note
that things like screen lock have security implications, so the jessie
stable lifetime *is* important for this code.  Maintaining it properly
would require confidence that we would be able to identify and fix
security issues in the GNOME code and in ConsoleKit through the jessie
supported lifecycle.

Obviously, if resources appear, that changes the situation, but I think
the GNOME maintainers are understandably wary of such approaches as
someone taking a week and fixing all the currently known bugs and then
moving on to other things, since their expectation is that, given the
situation, new bugs and new issues will continue to arise.  The code
really needs an ongoing maintainer with a good upstream relationship who
can get the fixes and support incorporated upstream for it to remain
viable.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvo64mh2@windlord.stanford.edu



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Josselin Mouette
Le mercredi 29 janvier 2014 à 20:43 +0200, Adrian Bunk a écrit :
> > You have the answer to your own question above. Unlocking the screen
> > sounds like pretty basic functionality.
> 
> Your statement was
>   I also have to insist that GNOME 3.10+ *needs* a working logind even for
>   basic functionality

My bad. I was under the impression you wanted a serious discussion.
Sorry for contributing to the noise, everyone.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1391022321.14103.0.camel@tomoe



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Adrian Bunk
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 from consolekit to systemd-logind sessions. For some reason
> > gnome-shell 3.10 unlocking fails with consolekit...
> > 3 months ago in gdm3 - I am referring to basic functionality that is 
> > simply missing in GNOME 3.10 without logind.
> 
> You have the answer to your own question above. Unlocking the screen
> sounds like pretty basic functionality.

Your statement was
  I also have to insist that GNOME 3.10+ *needs* a working logind even for
  basic functionality

Are you saying that there are only some bugs to get sorted out for using 
GNOME 3.10 without logind, or is there a fundamental technical reason
why some *basic functionality* (which?) cannot be made working in
GNOME 3.10 without logind?


>...
> Add to that the fact that ConsoleKit itself has been
> unmaintained for quite some time, making it unsuitable for a new stable
> release that needs maintenance for several more years

Debian is anyway not providing much maintenance apart from security 
updates for stable, so there is no real problem here for jessie.

And for security fixes, companies like Red Hat are anyway committed to
provide these for ConsoleKit for their products until around 5 years 
*after* Debian will have dropped security support for jessie.[1]

cu
Adrian

[1] the announced End of Extended Life Cycle for
Red Hat Enterprise Linux 6 is Q4 2023

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129184337.gf5...@bunk.dyndns.info



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Josselin Mouette
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 from consolekit to systemd-logind sessions. For some reason
> gnome-shell 3.10 unlocking fails with consolekit...
> 3 months ago in gdm3 - I am referring to basic functionality that is 
> simply missing in GNOME 3.10 without logind.

You have the answer to your own question above. Unlocking the screen
sounds like pretty basic functionality.

Gnome-shell uses GDM for screen locking, and GDM heavily relies on
logind nowadays. There is fallback code that uses ConsoleKit, but it has
been untested for several major releases, and now fails even for trivial
things. Add to that the fact that ConsoleKit itself has been
unmaintained for quite some time, making it unsuitable for a new stable
release that needs maintenance for several more years

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1391019449.18551.804.camel@dsp0698014



Re: Next CTTE meeting at date -d 'Thu Jan 30 18:00:00 UTC 2014' in #debian-ctte on irc.debian.org

2014-01-29 Thread Keith Packard
Steve Langasek  writes:

> On Tue, Jan 28, 2014 at 04:59:10PM -0800, Don Armstrong wrote:
>> The next CTTE meeting is at date -d 'Thu Jan 30 18:00:00 UTC 2014' in
>> #debian-ctte on irc.debian.org
>
> FYI, I'm travelling this week and don't believe I'll make it to this
> meeting.

I don't leave for FOSDEM until around 18:30 UTC tomorrow, so I should be
able to make the start of the meeting at least...

-- 
keith.pack...@intel.com


pgp0dA8BGL5dD.pgp
Description: PGP signature


Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Adrian Bunk
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/debian-ctte/2014/01/msg00360.html
>...

You wrote there
  I also have to insist that GNOME 3.10+ *needs* a working logind even for
  basic functionality

What Olav wrote sounds quite different.

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 from consolekit to systemd-logind sessions. For some reason
gnome-shell 3.10 unlocking fails with consolekit...
3 months ago in gdm3 - I am referring to basic functionality that is 
simply missing in GNOME 3.10 without logind.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129180034.ge5...@bunk.dyndns.info



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Josselin Mouette
Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : 
> > No, you are not. There are several features in systemd that GNOME uses.
> > One of them is user sessions, for which there will indeed be a fallback
> > in place. But it is not the only one.
> 
> Can you provide a list of features without a fallback in place?

At least logind, timedated, hostnamed, localed, the boot control
interfaces. With a very widespread level of failure depending on the
unavailable interface.

> Assuming jessie will support multiple init systems, why would GNOME need 
> a dependency on systemd?

Because it needs logind.
https://lists.debian.org/debian-ctte/2014/01/msg00360.html

> Would making any init system other than systemd the default for jessie 
> automatically exclude GNOME from being considered as an option for the 
> default desktop in jessie?

There are solutions for a non-systemd init. They are technically wrong,
but they are realistic (basically it means using logind v204). But there
are no realistic solutions for having GNOME support multiple init
systems in jessie.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1391017271.18551.799.camel@dsp0698014



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

2014-01-29 Thread Steven Chamberlain
On 19:01, Adrian Bunk wrote:
> On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote:
> > What makes you think gnome is going to be the default?
> > 
> > http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5
> 
> Read the text in debian/changelog that is there - the final decision 
> will be made in August (or later).
> 
> I was sarcastically describing a worst-case scenario that is not 
> completely impossible - in reality I would expect enough sanity
> in Debian to ensure that something depending on a non-default
> init system cannot be part of a default installation.

I'd expect Debian GNOME install media would still give a GNOME desktop
by default, Debian KDE disc gives you KDE, etc.

Would it be crazy to suggest putting the preferred init system
in the 'task'?  A Debian GNOME install would likely install systemd,
otherwise it could be something else.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129172039.gb21...@squeeze.pyro.eu.org



Bug#728486: Draft of Resolution for 728486 (lvm/systemd compatibility)

2014-01-29 Thread Don Armstrong
Below is the current draft of a resolution to resolve 728486. I have one
current comment in the draft which I would like clarified. [CTTE
members: please comment/suggest change.] I also expect to change the
reference to the patch to a newly updated patch with the changes
suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#183.

==BEGIN DRAFT==

When systemd is in operation in conjunction with lvm and lvmetad is
not in use, lvchange -aay must be called after udevadm --settle which
is provided by systemd-udev-settle.service, and before (and after)
encrypted devices are configured (cryptsetup.target).

==COMMENT==
Is there any case where udevadm --settle would be required after the
encrypted devices are configured? Does cryptsetup.target ensure that
udev has triggered the appropriate rules for the newly configured
encrypted devices?
==END COMMENT==

The patch prepared by Michael Stapelberg  in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#163 installs
the two systemd unit files necessary to properly configure lvm devices
when systemd is running, and additionally configures systemd-tmpfiles.d to
create the lockfile directories required by systemd.

Therefore, the CTTE:

A. Overides the objection of the maintainer of lvm (Bastian Blank
) to this patch, and directs the maintainer to
accept this patch or alternatively, authorizes an NMU to implement
this patch.

B. Further discussion

==END DRAFT==

This draft is 728486_systemd_and_lvm_incompatibility/draft-dla in git.

-- 
Don Armstrong  http://www.donarmstrong.com

I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
 -- Douglas Adams _The Long Dark Tea-Time of the Soul_


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129171545.gb22...@teltox.donarmstrong.com



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

2014-01-29 Thread Adrian Bunk
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 for jessie,
> >   but it's default desktop GNOME forces the installation of systemd.
> 
> What makes you think gnome is going to be the default?
> 
> http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5

Read the text in debian/changelog that is there - the final decision 
will be made in August (or later).

I was sarcastically describing a worst-case scenario that is not 
completely impossible - in reality I would expect enough sanity
in Debian to ensure that something depending on a non-default
init system cannot be part of a default installation.

> Best wishes,
> Mike

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129170154.gb5...@bunk.dyndns.info



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Adrian Bunk
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
> GNOME components, others as well). Though that was under Mageia and
> later on Gentoo provided various patches to improve it (but no idea how
> good the current state is or if we regressed anywhere).

I'd guess the main reason for this is that distributions usually support 
only one init system so the runtime detection rarely gets tested, and if 
Debian would support multiple init systems such issues would get sorted 
out quickly.

> Regards,
> Olav

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129170218.gc5...@bunk.dyndns.info



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Adrian Bunk
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  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 processes started by the session. IIRC both GNOME
> > > >> and KDE were mentioned to consider this feature.
> > > >
> > > > I wouldn't worry much about such features, at least not for jessie. They
> > > > will most likely be fallbacks, and in the unlikely case they are at
> > > > build time, we could always put the two binaries in the same package
> > > > with dynamic detection, thus working around this requirement.
> > > 
> > > Fallback is intended, so for near future you'd be ok. Longer term, I
> > > expect almost no maintenance to occur from GNOME side, so be prepared
> > > to handle the maintenance if nobody else does.
> > >...
> > 
> > The freeze for jessie will be in November 2014, so it will ship with
> > GNOME 3.14 (or earlier).
> > 
> > Am I reading your email correctly that can Debian assume that for the 
> > GNOME in jessie proper fallbacks will be in place, so that GNOME in 
> > jessie will work fine with init systems other than systemd?
> 
> No, you are not. There are several features in systemd that GNOME uses.
> One of them is user sessions, for which there will indeed be a fallback
> in place. But it is not the only one.

Can you provide a list of features without a fallback in place?


Assuming jessie will support multiple init systems, why would GNOME need 
a dependency on systemd?

I fully get the point that in such a scenario some GNOME packages would 
have a *Suggests* on systemd-sysv (no matter whether it's the default
or not) - but do they really need a dependency?

Part of what I am trying to understand is the scope of problems a 
theoretical scenario "a new installation of jessie installs the default 
desktop GNOME and the default init system sysvinit [1]" would produce.

Would making any init system other than systemd the default for jessie 
automatically exclude GNOME from being considered as an option for the 
default desktop in jessie?


> Cheers,

cu
Adrian

[1] or upstart or OpenRC

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129170351.gd5...@bunk.dyndns.info



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-29 Thread Don Armstrong
On Sat, 18 Jan 2014, Michael Stapelberg wrote:
> Bastian Blank  writes:
> > On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
> >> --- /dev/null
> >> +++ b/debian/lvm2-activation-early.service
> >
> > Wrong name.
> Renaming them to lvm2{,-early}.service as you suggested is fine with me.

Do you have an updated patch with this change and a documentation of the
tmpfiles.d change?

I will draft a resolution shortly to implement this patch, and will
open it for discussion.

-- 
Don Armstrong  http://www.donarmstrong.com

PowerPoint is symptomatic of a certain type of bureaucratic
environment: one typified by interminable presentations with lots of
fussy little bullet-points and flashy dissolves and soundtracks masked
into the background, to try to convince the audience that the goon
behind the computer has something significant to say.
 -- Charles Stross _The Jennifer Morgue_ p33


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129163739.ga22...@teltox.donarmstrong.com



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

2014-01-29 Thread Colin Watson
On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
> On 28 January 2014 21:39, Ian Jackson  wrote:
> > I don't want to pass a resolution specifying the default without also
> > answering the other two, related, contentious questions:
> >   Q1: Do we intend to support multiple systems long-term, or do we
> >   intend to settle on a single system, probably in jessie+1 ?
> 
> FWIW, that seems overly prescriptive to me -- if we settle on systemd
> now, and as a result upstart stops getting maintained and systemfree
> gets written that uses the same config files but only works on FreeBSD
> and Hurd, maybe no one will want to maintain multiple init systems
> later.

Perhaps a better phrasing would be something like "remain open to
supporting multiple init systems as long as they are actively
maintained".

> Conversely, maybe people get excited about some init system we
> don't pick as default for jessie and it becomes really awesome by the
> time jessie is out; why would we want to prevent it being available in
> Debian even if it's not ready to be default, or doesn't work with
> Gnome yet, or whatever?

(I don't think I can suggest better wording for the "single" options as
they aren't ones I favour.)

> >   Q2: Is it OK for packages to depend on a specific init system as
> >   pid 1 ?
> 
> I don't think that's the right question for the issue(s) at play here.
> 
> >From what I can tell, the important question isn't whether systemd or
> upstart happens to be pid 1, but rather whether certain interfaces
> (dbus, logind, potentially others) that are only (currently) provided
> by systemd are available on the system.

That's certainly the principal issue for e.g. GNOME.  But I think it's
reasonable to anticipate that some maintainers might want to drop
support in their service packages for init systems which they don't
favour and which aren't the default; one can reasonably take different
views on whether that's appropriate, and I think guidance from the
committee would be useful.

I agree with you that it's worth breaking it down into the matters of
service specifications (which for the most part have resisted attempts
to implement translation layers) and other APIs (which have a better
track record here).

>   Q2a: Is it OK for packages providing init systems to provide other
> APIs beyond just the minimum needed for starting/stopping services?

We might disagree on the extent, perhaps, but I doubt anyone on the
committee would vote against this in its general form; both systemd and
upstart implement interfaces beyond the bare minimum, though upstart
certainly takes a more minimalist tack.

> After Steve's and Russ's comments in [0] and [1], and thinking about
> it some more, I'm inclined to think all those questions could
> reasonably be dealt with through the policy process, though I still
> think some non-binding advice from the tech ctte wouldn't be out of
> place.

I certainly don't think we should get into the specifics of how things
should be laid out, but the general direction is non-obvious and
important.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129111333.ga14...@riva.ucam.org



Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.

2014-01-29 Thread ChaosEsque Team
Not wanting to have to learn the flavor of the month, then relearn the new 
flavor of the month after that, and relearn the next flavor of the month is 
nonsense, gotcha.

And anyone who disagrees strongly with being forced to use systemd is a troll. 
Yep.

Wanting some stability in things, and voicing this opinion is forbidden.
Showing displeasure at the attempt to coopt everything to use and then rely
on systemd... that's just crazy.

Notice how the SystemD supporters reacted to the idea of having choice of init 
system earlier:
a (very polite, as things must be) "no". When other packages come into debian, 
they 
don't tend to remove other packages that do similar things. Not so with systemd.
SystemD is a SYSTEM. And we must all sign up for it. Out with the old, in with 
the new, so
on and so on.

Lennart Pottering is to Linux what Bill Gates was to the use of academic 
computer systems in the 80s. 
>Dear BTS admins,

>this troll has been polluting the already very long bug lof of #727708,
>and has apparently no interest in stopping after Russ already told him
>to stop.

>Could you please consider blocking him from the BTS?

>Thanks,
>-- 
>.''`.Josselin Mouette

On Wed, 1/29/14, Emilio Pozuelo Monfort  wrote:

 Subject: Re: Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to 
see it for what it is: Lennart/Linux OS. Yes it is.
 To: "ChaosEsque Team" , 727...@bugs.debian.org
 Cc: oia...@gmail.com, ow...@bugs.debian.org
 Date: Wednesday, January 29, 2014, 12:41 AM
 
 On 29/01/14 09:00, ChaosEsque Team
 wrote:
 > Ah, you're a systemd acolyte. You smugly proclaim that
 it is USELESS to resist!
 > ::
 >> Forking every package that depends on systemd is
 pointless.
 > 
 > 
 > If you read what I wrote
 
 Nobody read what you wrote because it's nonsense. Please
 stop it now.
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1390992073.5344.yahoomailba...@web141701.mail.bf1.yahoo.com



Bug#727708: multiple init systems - formal resolution proposal

2014-01-29 Thread Josselin Mouette
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  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 processes started by the session. IIRC both GNOME
> > >> and KDE were mentioned to consider this feature.
> > >
> > > I wouldn't worry much about such features, at least not for jessie. They
> > > will most likely be fallbacks, and in the unlikely case they are at
> > > build time, we could always put the two binaries in the same package
> > > with dynamic detection, thus working around this requirement.
> > 
> > Fallback is intended, so for near future you'd be ok. Longer term, I
> > expect almost no maintenance to occur from GNOME side, so be prepared
> > to handle the maintenance if nobody else does.
> >...
> 
> The freeze for jessie will be in November 2014, so it will ship with
> GNOME 3.14 (or earlier).
> 
> Am I reading your email correctly that can Debian assume that for the 
> GNOME in jessie proper fallbacks will be in place, so that GNOME in 
> jessie will work fine with init systems other than systemd?

No, you are not. There are several features in systemd that GNOME uses.
One of them is user sessions, for which there will indeed be a fallback
in place. But it is not the only one.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1390986322.18551.748.camel@dsp0698014



Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.

2014-01-29 Thread Emilio Pozuelo Monfort
On 29/01/14 09:00, ChaosEsque Team wrote:
> Ah, you're a systemd acolyte. You smugly proclaim that it is USELESS to 
> resist!
> ::
>> Forking every package that depends on systemd is pointless.
> 
> 
> If you read what I wrote

Nobody read what you wrote because it's nonsense. Please stop it now.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e8bea2.5080...@debian.org



Re: Next CTTE meeting at date -d 'Thu Jan 30 18:00:00 UTC 2014' in #debian-ctte on irc.debian.org

2014-01-29 Thread Steve Langasek
On Tue, Jan 28, 2014 at 04:59:10PM -0800, Don Armstrong wrote:
> The next CTTE meeting is at date -d 'Thu Jan 30 18:00:00 UTC 2014' in
> #debian-ctte on irc.debian.org

FYI, I'm travelling this week and don't believe I'll make it to this
meeting.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Not.

2014-01-29 Thread ChaosEsque Team
>This bug discussion is already quite long and protracted, and it would be
>easier for those following it if strategic discussions of how to drive the
>future of Linux could be moved to other, more appropriate forums where
>they have a better chance of finding their audience.

It's either Lennarts way or the highway.
He and his have declared the unix way dead, his fanboy developers
join other pivotal projects and subvert them from the inside.

>But the role of the Technical Committee on these sorts of discussions is
>reluctant and trailing-edge, not visionary and bleeding-edge.  We're a
>decision-making body of last resort called on to make decisions when the
>project needs to have a decision and the correct option isn't clear.  As a
>result, we have to deal with the practical, concrete, and currently
>available.  We are neither empowered to, nor in a position to, set grand
>design strategies for what other developers might work on, only to decide
>how to integrate the code we have available to us now in places where the
>right decision is not clear.

I wish the "bleeding edge" trail-blazing crap Lennart and crew stuff down our
throats was rejected. Virtually all of his followers say that systemd must be
the one true way or be prepared to go and fork all the projects that "rely"
on it now (and in the future). Maybe that should be done.

Their idea of a universal operating system is one where all opposition is 
crushed. Aka europe a few centuries ago.

For the record: I have forked opensource projects at points where they started
removing features or went in another direction, or had an as hole of a developer
take over the project and pretty much become king of it (the king of NO). These
are and were videogame projects so I guess aren't relevant. But to the "go
and fork it"... yea I've done it. Turns out fine. I got a concrete base, they go
off into loopy land. When they fix bugs or security issues I back port the few
lines manually.

Aside:
Those who have a userspace kernel to compete with the real linux kernel, and 
feel we must all use it, do not want to hear reasons why we shouldn't be forced
to use it:
"Just fuck off, this bug has already enough crap even without your fanatic 
bullshit."
--Ondřej Surý ond...@sury.org

Yea, I'd better shut up.

Honestly. I, and many many many others, do NOT WANT SYSTEMD.
We do not want to be forced or cajoled into using it.
NOR do we want to be PUNISHED for not using it.
"heheh yea you don't have to use it, but nothing will work on your system lolz 
hahhahah!"

The systemd people seem to hate freedom and choice. They seem to be 
totalitarians. Why must we be forced to use their "software stack"
Why do we have to accept their tendrils needlessly corrupting every 
free-software project that is at the "core" of Gnu/Linux?

Alot of the software is great as-is. How about keeping it pre systemd infection.
Let the systemd church have it's own system. Please do not make it hard
for us to have ours separate from them. They are taking over everything
that is good in linux, and they do not respect anyone.




--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1390983619.53781.yahoomailba...@web141702.mail.bf1.yahoo.com



Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.

2014-01-29 Thread ChaosEsque Team
Ah, you're a systemd acolyte. You smugly proclaim that it is USELESS to resist!
::
>Forking every package that depends on systemd is pointless.


If you read what I wrote you would see that I said fork everything below/or 
above
(whatever "software stack" direction you believe in) the linux kernel,
and maintain them in a very stable form, applying security patches and bug 
fixes.
::
>Fork the kernel???  right we all know how successful this turns out
>for those making clones of Solaris.  Solaris clones have to go SMC
>they don't have a option of using a different init system.

Personally I do not care what you or Lennart are sick of (which includes
unix philosophy, as-well as any people who are learned in the unix 
way). I do not want to learn your new little computer religion (getting
bigger every day). There are social consequences to your hostile 
internal fork of the Gnu/Linux system. You and Lennart do not give a
damn about those consequences for other people.
::
>Secure software is a science.  I am sick of those who say Software is
>more an art.  Saying software is a art is a nice universal excuse not
>todo quality control.

Anyway, one way to have secure software is to freeze development 
at some mature version, and then do an audit and focus on fixing
all the little niggling bugs and failings. Not that you windows programmer
refugees would know anything about that. You're a flavor of the month
or half-decade kind of people. And you are attacking the linux system
from the inside. You like building on shifting sands, and you like it
even more to force us all to live on the beach with you.

If you want secure software, it's called the grsecurity patch and PAX, not 
systemd.

>Sysvinit came on Linux by being lazy.
It came on linux by doing one thing and doing it well: it starts various 
processes
the system administrator wants started, and then it gets out of the way.
Very nice and secure design paradigm: does few things, has few lines of code.

>The Linux world is horribly fragmented.
Good. It is called choice. Guess what: the hobbyists do not exist to promote or
expand that religion in your mind called "Linux" or "Desktop Linux" or "The 
Universal Faith".
You think if you could just FORCE the Linux world to standardize on YOUR 
software and YOUR interfaces then they would work more efficiently towards YOUR
goals (of supreme Desktop OS or whatever computer religion/heresy you're into.)

As an aside: you know once upon a time there was little fragmentation in the 
init system area.
It was pretty much a non issue and no app cared what init system you ran.
Lennart and friends changed all that.
YOU are creating the DIVISION here, and YOU have the GALL to put blaim 
elsewhere.
YOU (Lennart and co) are UPROOTING what we all know and love, and telling us
to basically go a FCK ourselves if we do not like it ("Progress" "Go and fork 
everything *SNCR*")

Fsck Lennart. Fsck every abomination he foists onto us with gusto.
"It's free, it's all free software, what's the problem" So is a bullet, but I 
don't want one!

No one needs to "step up to the plate": Our current systems work fine for us, 
we do 
not want to be forced (and yes making every project you and yours infiltrate 
depend
on systemd does equal force in the software world)

Watch Lennart be a do chbag to the good man who is trying to give a 
presentation;
even jumps up on stage at the end. You can feel the dejected feel the man has
as he rushes through his carefully prepared presentation because Lennart got 
a mic and took up much of the allotted time.

www.youtube.com/watch?v=_ERAXJj142o

SystemD and the rest of Lennarts garbage (PulseAudio) is a hostile takeover
of what was once a nice unix like OS, by Lennart Pottering and his followers.

He loves the attention, we have to pay attention to every damn thing he does,
and learn HIS new way of doing things. He is a jackass, and a smug 
passive-aggressive totalitarian, as are many of his adoring followers.


>Software is closer to maths and science than art.   Yes there is a old
>believe that software is art but anyone holding that idea normally
>ends up making suspect software.

Yep, if we don't want systemd and pulseaudio so on and so forth,
not only are we suspect, but the software we write is suspect!

You Lennart guys always have some bullsht aside like this to
degenerate your detractors. There's always something wrong with
us: Just look at *this *bulleted *list *of *features. How could anyone
disagree with that, they must be insane!

In math and science there are often only a handful of ways to 
do a particular thing. In art and religion there are infinite possibilities
and choices: software is the same. Ofcourse all my software 
is suspect, as am I. Perhaps I'm a heretic and should be burned.

Go to tartarus, and bring Lennart and his religion with you.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org