Re: [debian-mysql] MySQL.. no.. _I_ need your help!

[Jonathan Aquilina]

I would like to help in some capacity. Would working in a chrooted
environment or would one need a fully fledged os?


On Fri, Oct 25, 2013 at 5:32 PM, Clint Byrum  wrote:

> Greetings earthlings,
>
> As some of you may know, I've been doing the bulk of the package
> maintenance on the mysql package for a while now. It started as part of
> my day job with Canonical, but since leaving Canonical it has been more
> a labor of love for Debian.
>
> I have love for other things too, such as my children, and seeing the
> sun shine every once in a while. Thus, I have found almost no time for
> packaging MySQL for Debian.
>
> I am asking you, the Debian developers, to step up and help. I am
> basically unable to contribute more than an hour a month now. There is a
> new round of secret CVE bugs to fix, and some old bugs that need to be
> handled. I think my October hour is about to be available, so I might
> be able to address those, but after that, if I don't get any more help,
> I'm done.
>
> What can you do to help?
>
> - Raise your hand and say you'll help
> - Perhaps help us do this right (I suspect I should have an RFH bug)
> - Join #debian-mysql on OFTC
> - Join the alioth team and request svn access
> - Triage bugs (src:mysql-5.5 and for oldstable src:mysql-5.1)
> - Help package the latest patch releases from Oracle
> - Help with MariaDB (James Page and Otto, thanks for doing this btw!)
> - Help us migrate to git
>
> Now, all of that said, please do not just pick up the package and run
> off and do a bunch of things without first letting us know you're doing
> it. There are people quietly working on some long term interesting
> things and you may be duplicating or diverging heavily from their work.
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
>



-- 
Jonathan Aquilina

Re: Proposal: s have a GR about the init system

[Colin Watson]

On Sat, Oct 26, 2013 at 07:57:50AM +0300, Uoti Urpala wrote:
> I don't have anything against Colin Watson, and have nothing in
> particular to complain about in his reply concerning the conflict of
> interest. But I don't think there really is much he could even
> theoretically say to fully remove concerns about the conflict. That
> there is a conflict of interest is not a statement about him in person;
> it's a statement about the situation.

At present I feel I have a well-known and declared interest, but not a
conflicting one, for reasons previously stated.  I'll recuse myself if
that changes or if my colleagues on the TC feel I should (as I
mentioned, I previously sought advice on this from the TC chair and he
didn't think it was necessary).

> I don't see what would be the point of CD #1 options for different
> inits. Is that really a serious suggestion?

I don't know whether I yet agree with this, but I can see where it's
coming from, given that GNOME has tighter integration into one init
system than other desktop systems do.

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


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

Re: Proposal: s have a GR about the init system

[Scott Kitterman]

On Saturday, October 26, 2013 07:57:50 Uoti Urpala wrote:
> Scott Kitterman wrote:
> > Unless there's some kind of disclosure policy for everyone involved in the
> > any technical discussion around Debian,
> 
> CTTE decisions are quite distinct from "any technical discussion".
> 
> >  I think it's silly to claim Steve and
> > 
> > Colin are inherently unable to separate what's good for Debian from what's
> > good for Canonical.  This is just one more symptom of irrational anti-
> > Ubuntu/Canonical bias I see from some people in Debian and I encourage
> > Steven and Colin not to give in to it.
> 
> A conflict of interest is not the same as claiming the people involved
> are "inherently unable" to distinguish different interests. And I'd say
> this is a very obvious case of conflict of interest - their employer has
> an official stance, and the decision also has a direct impact on that
> employer. I do not see what reason you would have to label such concerns
> "silly" or "symptoms of irrational bias" unless you reject the whole
> concept of "conflict of interest" and say such concerns are always
> "silly" anywhere. Is that your view?
> 
> I am no longer willing to assume that Steve Langasek would act in good
> faith in evaluating init systems; he has posted false claims about
> systemd too many times for me to believe they would all be honest
> mistakes, and has posted what has clearly been deliberate FUD. This
> independently of and in addition to any conflict of interest.

If someone has engaged in actions that cause you to think their decision 
making is suspect (I'm not saying either way here, it's your opinion, not 
mine) that's fair, IMO.  

Holding their employer against them based on no evidence that there is an 
actual problem is not.  The most important thing in the absence of an actual 
problem is to shine a light on the potential.  That's been done and I think 
that's enough.

> I don't have anything against Colin Watson, and have nothing in
> particular to complain about in his reply concerning the conflict of
> interest. But I don't think there really is much he could even
> theoretically say to fully remove concerns about the conflict. That
> there is a conflict of interest is not a statement about him in person;
> it's a statement about the situation.
> 
> > No matter what gets decided, some people aren't going to like it and will
> > complain.
> > 
> > Personally, I don't think there's more than one sane choice for Jessie
> > anyway:
> > 
> > 1.  Init systems in Debian MUST provided compatibility with sysvinit
> > scripts. 2.  Packages needing an init MUST provide a sysvinit script and
> > may provide native init scripts also for alternative systems.
> > 3.  For the various CD #1 options, there can be different default init
> > scripts
> > 
> > Something like that.  Anyone who thinks their pet sysvinit alternate is
> > going to destroy all opposition and become the one true init for Jessie
> > is dreaming.
> I think the important thing is making a decision on what init system
> Debian will use in the future. Details of the transition are then
> secondary. I wouldn't expect every trace of sysvinit scripts to
> disappear before next release (unless it takes a long enough time...).
> 
> I don't see what would be the point of CD #1 options for different
> inits. Is that really a serious suggestion?

I haven't thought about it deeply, but we've already got different CD #1's for 
different DEs.  If there is support for multiple inits in the Debian archive, 
there's no reason why all of them would have to use the same one.  I haven't 
thought about it in detail, but it strikes me as much less far fetched than 
thinking Jessie will ship with a single init system other than sysvinit.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/6321481.z8tQd60ckK@scott-latitude-e6320

Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable

[Andrey Rahmatullin]

On Sat, Oct 26, 2013 at 06:57:50AM +0100, Colin Watson wrote:
> > > The usefulness of supporting --as-needed isn't because of Ubuntu.  It's
> > > because switching --as-needed on across the board
> > 
> > I think it would be better send all our upstreams patches for their
> > build systems than to work around all the bugs in them. Lets be honest
> > here, IIRC any use of --as-needed is a workaround for over-inflated
> > DT_NEEDED and fixing those upstream benefits the wider free software
> > community, which we pledged in Social Contract item 2.
> 
> Linking in the correct order is not a workaround; it's being correct.
> Sufficiently portable upstreams already get it right since at least some
> traditional Unix systems already required linking in the correct order,
> so this is not a new thing.
... or when linking with static libs.

> I obviously have no objection to sending link-order patches upstream,
> but realistically this sort of thing only gets fixed across the board if
> driven by distributions, and the sensible way to track how far we've got
> is to fix it in the distribution.
Not to mention dead upstreams. Does anyone have some estimates about how
many packages have dead upstreams?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

[Ondřej Surý]

Funny thing, the people who are undermining the Debian processes most loudly 
are not even Debian Developers and thus they are not bound by them.

I am tired of this recurring flamewar, please stop it and let the tech-ctte do 
their job. This is not a democracy any more, but the loudiestcracy.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

> On 26. 10. 2013, at 0:10, Christoph Anton Mitterer  
> wrote:
> 
>> On Sat, 2013-10-26 at 00:36 +0300, Uoti Urpala wrote:
>> I don't think the technical experience would be that much of an issue,
>> but I do see being employed by Canonical as a very substantial conflict
>> of interest. IIRC Canonical has made an official statement that they
>> will keep supporting Upstart and believe in it. This is a fairly visible
>> company choice. Your work environment has at least at some level an
>> official policy that Upstart should be considered better than systemd.
>> Ubuntu still wants to keep using Upstart, but if Debian chooses systemd,
>> Ubuntu will likely also need to admit that Upstart failed and plan for a
>> switch.
>> 
>> If your vote decides that Debian will choose systemd, and as a result
>> upstreams conclusively drop any support for Upstart while Ubuntu still
>> wants to keep using it, do you believe this will not have any negative
>> consequences for your career at Canonical? I consider this the biggest
>> question about the conflict of interest, more than direct "you must vote
>> this way" pressure from your employer.
> 
> 
> I would see it the same way... it's not only a question whether
> objective ruling would be made, but also whether it could bring our
> tech-ctte members into troubles when they decide (i.e. against
> upstream).
> 
> And another issue: If e.g. tech-ctte (with some Canonical employees in
> it) now decides in favour of upstart... then we'll see forever people
> who challenge the neutrality and objectiveness of such decision.
> 
> The best would probably be, if people who are either
> - directly involved in the development of any of the discussed
> init-systems (in the sense of playing a bigger part)
> - who work for a company which is pushing the respective system (RedHat,
> Canonical) or
> - who maintain the respective package in Debian
> should abstain from the decision, but just provide their technical input
> and arguments.
> 
> 
> Cheers,
> Chris.

Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable

[Colin Watson]

On Sat, Oct 26, 2013 at 10:51:41AM +0800, Paul Wise wrote:
> On Sat, Oct 26, 2013 at 7:14 AM, Colin Watson wrote:
> > The usefulness of supporting --as-needed isn't because of Ubuntu.  It's
> > because switching --as-needed on across the board
> 
> I think it would be better send all our upstreams patches for their
> build systems than to work around all the bugs in them. Lets be honest
> here, IIRC any use of --as-needed is a workaround for over-inflated
> DT_NEEDED and fixing those upstream benefits the wider free software
> community, which we pledged in Social Contract item 2.

Linking in the correct order is not a workaround; it's being correct.
Sufficiently portable upstreams already get it right since at least some
traditional Unix systems already required linking in the correct order,
so this is not a new thing.

I obviously have no objection to sending link-order patches upstream,
but realistically this sort of thing only gets fixed across the board if
driven by distributions, and the sensible way to track how far we've got
is to fix it in the distribution.

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


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

Re: Proposal: switch init system to systemd or upstart

[Uoti Urpala]

Brian May wrote:

> As much as I would like to see systemd as the default in Debian (and
> have switched to it on my Desktops), I see two show stopper issues:
> 
> 
> * Needs to work (somehow) with other applications (including not in
> Debian) that need to manage cgroups. In Debian this would include lxc.

My understanding is that the _kernel_ side wants to change the cgroup
API, and this means that at least in the long term current cgroup-using
applications will need to change in any case (possibly by using systemd
APIs instead). I'm not familiar with the specific case of lxc, but I
really doubt systemd would make it unusable. Generally anything must
already work with systemd to be usable on several major distros, so it
should be a reasonably safe assumption that things will work.

> * See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721775, seems
> to have the systemd maintainers stuck.

To me that looks like a bug in old v44, which no maintainer is using any
more. Do you have reason to believe it would be relevant to current
unstable/testing?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382765682.1856.172.camel@glyph.nonexistent.invalid

Re: Proposal: s have a GR about the init system

[Uoti Urpala]

Scott Kitterman wrote:
> Unless there's some kind of disclosure policy for everyone involved in the 
> any 
> technical discussion around Debian,

CTTE decisions are quite distinct from "any technical discussion".

>  I think it's silly to claim Steve and 
> Colin are inherently unable to separate what's good for Debian from what's 
> good for Canonical.  This is just one more symptom of irrational anti-
> Ubuntu/Canonical bias I see from some people in Debian and I encourage Steven 
> and Colin not to give in to it.

A conflict of interest is not the same as claiming the people involved
are "inherently unable" to distinguish different interests. And I'd say
this is a very obvious case of conflict of interest - their employer has
an official stance, and the decision also has a direct impact on that
employer. I do not see what reason you would have to label such concerns
"silly" or "symptoms of irrational bias" unless you reject the whole
concept of "conflict of interest" and say such concerns are always
"silly" anywhere. Is that your view?

I am no longer willing to assume that Steve Langasek would act in good
faith in evaluating init systems; he has posted false claims about
systemd too many times for me to believe they would all be honest
mistakes, and has posted what has clearly been deliberate FUD. This
independently of and in addition to any conflict of interest.

I don't have anything against Colin Watson, and have nothing in
particular to complain about in his reply concerning the conflict of
interest. But I don't think there really is much he could even
theoretically say to fully remove concerns about the conflict. That
there is a conflict of interest is not a statement about him in person;
it's a statement about the situation.


> No matter what gets decided, some people aren't going to like it and will 
> complain.
> 
> Personally, I don't think there's more than one sane choice for Jessie anyway:
> 
> 1.  Init systems in Debian MUST provided compatibility with sysvinit scripts.
> 2.  Packages needing an init MUST provide a sysvinit script and may provide 
> native init scripts also for alternative systems.
> 3.  For the various CD #1 options, there can be different default init scripts
> 
> Something like that.  Anyone who thinks their pet sysvinit alternate is going 
> to destroy all opposition and become the one true init for Jessie is dreaming.

I think the important thing is making a decision on what init system
Debian will use in the future. Details of the transition are then
secondary. I wouldn't expect every trace of sysvinit scripts to
disappear before next release (unless it takes a long enough time...).

I don't see what would be the point of CD #1 options for different
inits. Is that really a serious suggestion?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382763470.1856.157.camel@glyph.nonexistent.invalid

Re: Proposal: s have a GR about the init system

[Adam Borowski]

On Fri, Oct 25, 2013 at 10:31:32PM -0400, Scott Kitterman wrote:
> Personally, I don't think there's more than one sane choice for Jessie anyway:
> 
> 1.  Init systems in Debian MUST provided compatibility with sysvinit scripts.
> 2.  Packages needing an init MUST provide a sysvinit script and may provide 
> native init scripts also for alternative systems.
> 3.  For the various CD #1 options, there can be different default init scripts
> 
> Something like that.  Anyone who thinks their pet sysvinit alternate is going 
> to destroy all opposition and become the one true init for Jessie is dreaming.

Even if we all suddenly agreed to one option, a switch for Jessie is
impossible because of upgrades: a system must not become unusable before
init is reloaded on reboot.  Just like kernels, the previous stable
release's init must be enough for daemons, as you can't[1] replace the
running init.

Thus, sysvinit compat must remain at least until after Jessie.


[1]. Technically, on modern Linux you can ptrace init, and thus force it to
exec() something else, but that's obviously not a real option here.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131026034118.gb4...@angband.pl

Re: let's split the systemd binary package

[Olav Vitters]

On Fri, Oct 25, 2013 at 08:53:35PM +0200, Marc Haber wrote:
> They choose the way most easy for them, which is behavior often
> encountered inside the systemd-favoring community. Too bad.

You mean ConsoleKit with this? Why GNOME? Do you know it is on
freedesktop.org? Do you know there hasn't been any development for 1.5
years? Why is this up to GNOME?

In any way, above is totally wrong. We still support ConsoleKit. Just
for some things we rely on either logind for reasons already explained.
Or in brief, Canonical had it working.

The rewriting of history is getting a bit tiresome.

-- 
Regards,
Olav


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

Re: let's split the systemd binary package

[Olav Vitters]

On Fri, Oct 25, 2013 at 06:06:04PM +0100, Neil Williams wrote:
> That is my gripe, that's the core problem in GNOME. It's why I stopped
> trying to develop code to work alongside GNOME and only work with XFCE
> and Qt. GNOME upstream are toxic.

XFCE is same as GNOME:
- Supports ConsoleKit
- Supports logind

Note that it would be good to read my messages before accusing me of
being toxic. It would also be good to be a bit friendlier towards me and
GNOME in general, or at least get your facts straight before using words
such as "topic".

I don't mind people calling GNOME out on bad behaviour, but please,
don't then use XFCE as an example because they are just less vocal. I
rather loudly advise of (potential) problems. That is what I think an
upstream *should* do. Now if there are issues where GNOME is behaving
badly (e.g. I am aware of some things which people could raise), feel
free to start using strong words. But at the moment, this is not
impressive at all.

-- 
Regards,
Olav


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

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

[Olav Vitters]

On Fri, Oct 25, 2013 at 06:15:28PM +0200, Marc Haber wrote:
> On Fri, 25 Oct 2013 16:54:47 +0200, Olav Vitters 
> wrote:
> >On Fri, Oct 25, 2013 at 11:38:56AM +, Thorsten Glaser wrote:
> >> found it usable even in 1.x days), is also true for GNOME: it
> >> is said to disable the ability of users to theme and customise
> >> it, and Torvalds’ opinions are well-known.)
> >
> >GNOME tweak tool has existed since GNOME 3.
> 
> Like Windows TweakUI which has been necessary since nearly 20 years?
> Does GNOME need to emulate everything?

Please don't ask me such questions. Above ones are pointless, without
content and I don't care about Windows.

FWIW, GNOME is usually said to emulate tablets, iPhone, touchscreens and
MacOS X. So if you want to ask me pointless question about Windows on
debian-devel, maybe include those?

Follow up to me personally please.

-- 
Regards,
Olav


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

Re: Proposal: switch default desktop to xfce

[Luca Capello]

Hi there!

On Fri, 25 Oct 2013 17:17:03 -0700, Thorsten Glaser wrote:
> And neither my IBM X40 nor my employer's X61 can boot from SD card,
> despite having the drive built in. Sucks.

Off-topic, but still.

My X60 (from late 2006) can not either, but IMHO the reason behind it
that the SD reader it is not connected through the USB bus:
=
$ lspci | grep SD
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 18)
=

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable

[Paul Wise]

On Sat, Oct 26, 2013 at 7:14 AM, Colin Watson wrote:

> The usefulness of supporting --as-needed isn't because of Ubuntu.  It's
> because switching --as-needed on across the board

I think it would be better send all our upstreams patches for their
build systems than to work around all the bugs in them. Lets be honest
here, IIRC any use of --as-needed is a workaround for over-inflated
DT_NEEDED and fixing those upstream benefits the wider free software
community, which we pledged in Social Contract item 2. Of course there
are some upstreams where the issues present will unlikely to ever be
fixed so --as-needed may be appropriate there.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6hatwce9js8p7qwe50qyovyeu+lcjj_ygxpw45oxtw...@mail.gmail.com

Re: Please assume good faith

[Nikolaus Rath]

David Kalnischkies  writes:
> On Fri, Oct 25, 2013 at 11:31 PM, Nikolaus Rath  wrote:
>> Thorsten Glaser  writes:
>>> Lars Wirzenius  liw.fi> writes:
>>>
 I write a backup program. It uses its own storage format, and people
 sometimes ask if they could use tar files instead. But I am evil
 incarnate and FORCE them to use my own storage format instead. Should
>>> […]
 can be, and I think that the storage format I've developed is better
 than storing backups in tar files. I truly, deeply feel that using my
 format makes the program better, and that offering tar as a choice
 would be pretty much disastrous, because almost all of the features I
>>>
>>> This *is* bad because if there is an existing userbase with tar (which
>>> isn’t true in the obnam case, sure, but would be true if you were to
>>> try forbidding all other backup programs in Debian) this will break
>>> their use cases, and *that* is what the systemd situation is all
>>> about.
>>
>> I don't understand this point of view. Even if there is an existing
>> userbase, I don't think that would obligate me (as the author) in any
>> way to support them in the future. […]
>
> You are not forced of course, but if you have (or aim to have) a userbase
> consisting of more than just a few people you might want to consider to not
> alienate them because you are a nice fellow (or aim to be one).

Yes, that's certainly what I do in practice. But I do not understand how
you make the jump from this to:

> That isn't meant to be advocating to never change anything, but you better
> have really really really good reasons to do it OR you accept that people
> start to distrust you and avoid you like the plague even if you have
> invented the cure for the common cold this time.

Is that really how you'd feel toward me if I stopped working on a piece
of software? By being nice to you for a limited time I get your distrust
and avoidance afterwards? I don't think that's a healthy attitude for
open source, because it means that if you want to get along with people,
you better not release any of your code in the first place (at least
everyone will still be neutral to you then).

(Note that I do not see a difference between stopping to work on a
project or taking it in a new direction. The old version is still
available in both cases.)

> A considerable amount of my volunteer work here in Debian is spent on
> keeping APT working even in the strangest usecases. I e.g. had quiet a few
> sleepless nights while trying to find a way to massage MultiArch into it
> without breaking too much.

(and that work is certainly much appreciated)

> Others did similar things in other areas.  If anyone involved would
> have a "I don't care about users" attitude we would probably still use
> ia32libs.

Not sure about that. I'm a user of my software, and I very much care
about me. I would not be surprised if much of this and other work was
because the developers personally wanted to have something fixed, rather
than because they wanted to improve the life of some random people
they've never met. I'm not saying that the latter doesn't happen, but
it's certainly not the only reason for work being done on open source
projects.

> And based on that we don't have enough people to maintain one APT¹, I doubt
> you find enough for two, so a "just fork it" sounds nice in theory, but
> just because you have a million users doesn't mean you have a million
> developers willing to work on it…

No, but that's really a problem (or non-problem) of the millions of
users. If no one is interested in working on apt, isn't that a sign that
apt is really good enough for most of its millions of users?

At least this is the reason that I'm not working on apt. For me it works
perfectly, so I spend my time working on things that really bug me
rather than working on apt.

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li1glq3y@vostro.rath.org

Re: Proposal: s have a GR about the init system

[Scott Kitterman]

On Saturday, October 26, 2013 10:45:55 Charles Plessy wrote:
> Le Fri, Oct 25, 2013 at 07:33:01PM -0400, Scott Kitterman a écrit :
> > I think that is all true and correct, but I certainly didn't get that from
> > the original message. It certainly read to me like an attempt to undermine
> > the legitimacy of any future TB decision in favor of upstart.  ICBW, of
> > course.
> 
> Hi Scott,
> 
> while the original message may be borderline, the conflict of interest is
> here.
> 
> Conflict of interest is not a judgement on a person.  It is a judgement
> about a situation, and a recommendation on how systematically react,
> without making exceptions.
> 
> For the choice of an init system, the technical comittee is a typical
> example where conflict of interest disqualifies a large number of its
> members (3 current or former employees of Canonical).  This has been also
> observed in comittees making decisions on the approval of pharmaceutical
> drugs on the market, for instance, and it is a hard problem to solve.
> 
> Luckily, the quorum of the technical comittee is 2 and the president has a
> casting vote, so it is possible to take a decision with the remaining
> members only.  I hope that the conflict of interest will be taken seriously
> if there is a vote.
> 
> But I also think that it is premature to make a decision without seeing the
> final implementations working.

It's one thing to say there's a potential bias that people should be aware of 
(as Russ did).  It's quite another to say that a tech-ctte vote in which they 
participate is illegitimate is another.  This only comes up because we know 
who they are employed by and what their interest is.  Many people in Debian 
are employed to do different things related to Debian that aren't disclosed.  

Unless there's some kind of disclosure policy for everyone involved in the any 
technical discussion around Debian, I think it's silly to claim Steve and 
Colin are inherently unable to separate what's good for Debian from what's 
good for Canonical.  This is just one more symptom of irrational anti-
Ubuntu/Canonical bias I see from some people in Debian and I encourage Steven 
and Colin not to give in to it.

No matter what gets decided, some people aren't going to like it and will 
complain.

Personally, I don't think there's more than one sane choice for Jessie anyway:

1.  Init systems in Debian MUST provided compatibility with sysvinit scripts.
2.  Packages needing an init MUST provide a sysvinit script and may provide 
native init scripts also for alternative systems.
3.  For the various CD #1 options, there can be different default init scripts

Something like that.  Anyone who thinks their pet sysvinit alternate is going 
to destroy all opposition and become the one true init for Jessie is dreaming.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4172401.Q9LG19E9lY@scott-latitude-e6320

Re: Proposal: s have a GR about the init system

[Charles Plessy]

Le Fri, Oct 25, 2013 at 07:33:01PM -0400, Scott Kitterman a écrit :
> 
> I think that is all true and correct, but I certainly didn't get that from
> the original message. It certainly read to me like an attempt to undermine
> the legitimacy of any future TB decision in favor of upstart.  ICBW, of
> course. 
 
Hi Scott,

while the original message may be borderline, the conflict of interest is here.

Conflict of interest is not a judgement on a person.  It is a judgement about a
situation, and a recommendation on how systematically react, without making
exceptions.

For the choice of an init system, the technical comittee is a typical example
where conflict of interest disqualifies a large number of its members (3
current or former employees of Canonical).  This has been also observed in
comittees making decisions on the approval of pharmaceutical drugs on the
market, for instance, and it is a hard problem to solve.

Luckily, the quorum of the technical comittee is 2 and the president has a
casting vote, so it is possible to take a decision with the remaining members
only.  I hope that the conflict of interest will be taken seriously if there is
a vote.

But I also think that it is premature to make a decision without seeing the
final implementations working.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131026014555.gb17...@falafel.plessy.net

Re: Proposal: switch init system to systemd or upstart

[Brian May]

On 25 October 2013 23:29, Marco d'Itri  wrote:

> It is more and more obvious that modern software needs an event-based
> init system.
>

As much as I would like to see systemd as the default in Debian (and have
switched to it on my Desktops), I see two show stopper issues:

* Needs to work (somehow) with other applications (including not in Debian)
that need to manage cgroups. In Debian this would include lxc.
* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721775, seems to
have the systemd maintainers stuck.

If I had to change back from systemd, it would be, reluctantly, due to one
or both of the above.
-- 
Brian May 

Re: Proposal: switch default desktop to xfce

[Adam Borowski]

On Fri, Oct 25, 2013 at 05:42:55AM +1100, Jackson Doak wrote:
> +1 to xfce, but it might be worth using a nicer theme than the current xfce 
> one.

It might be good to default to what's used on XFCE's own homepage.  That
icon theme, faenza, is stuck in ITP (#595106), despite at least two people
having prepared working packaging.

As for the controls theme, the current default might be not pretty but at
least it's not too ugly to live.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131026015104.ga4...@angband.pl

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

[Paul Wise]

On Sat, Oct 26, 2013 at 12:22 AM, YunQiang Su wrote:

> After more than half of a year's hard work, we have the mips64el port
> almost done.
> Now we have more than 7600 packages build successfully.

Congrats!

Please create a page on the Debian wiki and or update the MIPSPort
wiki page about this new architecture. You could also send patches to
update the list of ports on the Debian website:

https://wiki.debian.org/MIPSPort
http://www.debian.org/ports/
http://www.debian.org/ports/mips/
http://www.debian.org/devel/website/

> The current build status can be found in http://vip.moonux.org/attempted/

Would you like me to register mips64el.debian.net and CNAME it to
vip.moonux.org or another domain?

> Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
> Most important is that it is running a Debian Unstable, MIPS64EL.
>
> Anyone has need to port package(s) can apply a account.
> Please post me your ssh public key signed by a trust-able PGP key.

You should probably talk to DSA about getting it a debian.net domain
and getting it listed in LDAP as a porter machine.

https://db.debian.org/machines.cgi

> I also working on make a rootfs to make it easy to install this port.

In Debian we usually expect people to either run debootstrap or d-i to
perform Debian installations since otherwise some files that should be
different between installs will be identical. So please just point
people at debootstrap instead. This is a problem with Debian that we
currently have to work around once for every image creation tool; all
of debian-live, cloud images, mips64el rootfs' etc  need/have hacks to
remove files like the dbus machine identifier or the openssh host keys
from the system after debootstrap has run.

> Here we still have 2 problems:
>1. I believe that it is time of use to talk about how to make this
> port to debian-ports.org.
> Anyone can help us?

http://www.debian-ports.org/contacts

I have heard rumours on IRC that debian-ports.org is having resource
issues so adding new ports there might be hard.

>2. Which ISA  to be used for this port when it is in debian-ports.
> Now we use mips64r2 with tune loongson3a.
> Should we downgrade ISA requirement to mips3 or mips64?

That is up to yourself and people who own or otherwise care about MIPS
hardware. Take into consideration what hardware is available
commercially now and will be in the future, as well as what hardware
most people already own. I don't know much about GCC tuning but I
expect that tuning for one specific machine isn't a good idea.

For future the future steps, here are the requirements for adding
mips64el to the archive and getting it officially included in a future
Debian release:

https://ftp-master.debian.org/archive-criteria.html
http://release.debian.org/testing/arch_policy.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6en85omcxtdu+3-zj3-k5rgppemiwg6vah1jpbe2sc...@mail.gmail.com

Re: let's split the systemd binary package

[Brian May]

On 25 October 2013 21:52, Dmitrijs Ledkovs  wrote:

> - it's pam module called "pam_systemd" instead of logind
>

It wouldn't be the first PAM module with an inappropriate name.

(e.g. pam_unix.so would be less confusing if it was called pam_nss.so IMHO,
as if I understand correctly it uses NSS library calls, but that is getting
off-topic for this discussion)
-- 
Brian May 

Re: Please assume good faith

[David Kalnischkies]

On Fri, Oct 25, 2013 at 11:31 PM, Nikolaus Rath  wrote:
> Thorsten Glaser  writes:
>> Lars Wirzenius  liw.fi> writes:
>>
>>> I write a backup program. It uses its own storage format, and people
>>> sometimes ask if they could use tar files instead. But I am evil
>>> incarnate and FORCE them to use my own storage format instead. Should
>> […]
>>> can be, and I think that the storage format I've developed is better
>>> than storing backups in tar files. I truly, deeply feel that using my
>>> format makes the program better, and that offering tar as a choice
>>> would be pretty much disastrous, because almost all of the features I
>>
>> This *is* bad because if there is an existing userbase with tar (which
>> isn’t true in the obnam case, sure, but would be true if you were to
>> try forbidding all other backup programs in Debian) this will break
>> their use cases, and *that* is what the systemd situation is all
>> about.
>
> I don't understand this point of view. Even if there is an existing
> userbase, I don't think that would obligate me (as the author) in any
> way to support them in the future. […]

You are not forced of course, but if you have (or aim to have) a userbase
consisting of more than just a few people you might want to consider to not
alienate them because you are a nice fellow (or aim to be one).

A considerable amount of my volunteer work here in Debian is spent on
keeping APT working even in the strangest usecases. I e.g. had quiet a few
sleepless nights while trying to find a way to massage MultiArch into it
without breaking too much. Others did similar things in other areas.
If anyone involved would have a "I don't care about users" attitude we
would probably still use ia32libs.

And based on that we don't have enough people to maintain one APT¹, I doubt
you find enough for two, so a "just fork it" sounds nice in theory, but
just because you have a million users doesn't mean you have a million
developers willing to work on it…

That isn't meant to be advocating to never change anything, but you better
have really really really good reasons to do it OR you accept that people
start to distrust you and avoid you like the plague even if you have
invented the cure for the common cold this time.

You can think what you want about how Linus is communicating his points,
but he earned quiet some credit with "we don't break userspace - EVER".


And while we are at trust and communicating: We might want to consider
admitting that "systemd" isn't an init system.
'Normal' programs like GNOME do not depend on an init system as much as
they don't depend on a package manager. They depend on a certain userland,
like GNU, BSD, Plan9, busybox or … yes, or systemd. It just happens to be
that this userland contains also a binary which provides PID1.
I think busybox has one, too. (And it also namespaces everything.)


Best regards

David Kalnischkies

¹ It's the only team I have personal experience with, but I guess you can
pick any random Debian core/native-devel team and the sentence is
still valid.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caaz6_fcbsnpxdxjiuxkeuckqhxgrgrn7yguenzf1sbyl4ho...@mail.gmail.com

Re: Proposal: let’s have a GR about the init system

[Charles Plessy]

Le Fri, Oct 25, 2013 at 02:03:38PM +, Thorsten Glaser a écrit :
> 
> Possible alternative choices for the GR would be:
> 
> - switch to systemd, do not permit any other init system
> 
> - switch to upstart, do not permit any other init system
> 
> - switch to systemd/upstart for $subset_of_architectures,
>   permit architectures to not support the full set of init
>   systems including lowering the number of supported ones
>   down to one

Hi Thorsten,

with my experience of having proposed a GR that eventually led to a vote and a
lot of bitterness, I recommend one more option, nicknamed "rotten tomatoes",
that basically says that this GR should never have been proposed.  This is a
risky option, but at least if it loses to "further discussion", there will be
less debate on whether it is too easy to start GRs, if this one could have been
avoided, etc.  If on the other hand it wins to all other options, you will have
learned for yourself, at the expense of the other developers, that your
understanding of the situation was wrong, which is still less bad than being
left with "further discussion" only.

Currently, I would vote "rotten tomatoes".

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131026005751.ga17...@falafel.plessy.net

Re: systemd effectively mandatory now due to GNOME

[Christoph Anton Mitterer]

On Sat, 2013-10-26 at 00:00 +0100, Kevin Chadwick wrote:
> * CVE 2013-4327 - Towards a world where even simple systems and
> firewalls are vulnerable!
> 
> p.s. CVE-2013-4392, CVE-2013-4391 and I think I've missed out the really
> bad one to do with remote connection.

On one hand I agree, we see security problems due to the utopia
technologies (consolekit, polkit, etc.).. like I remember the one
where,.. was it devkit? exported the dm-crypt master keys to anyone...
o.O


But that alone is not an argument against introducing new technologies.
One just has to be careful in what is done.


Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382747908.6907.37.ca...@heisenberg.scientia.net

Re: Proposal: switch default desktop to xfce

[Thorsten Glaser]

Andrew Kane dixit:

>A lot of these boxes are ones that one would reasonably expect to
>support booting from USB, but in some cases the option isn't there in
>the BIOS setup or boot menu and in others the option is there but is
>ignored on boot some or all of the time. The inability to boot from a

Yeah, USB FDD works but not USB HDD, or something like that.

I recently had one of these cases (on a modern VIA C7 system even!)
and just threw the (Freeware, i.e. non-free in Debian terms) Plop
bootmanager on a floppy disc and used it to boot the Grml USB stick:
http://www.plop.at/en/bootmanager/index.html

And neither my IBM X40 nor my employer's X61 can boot from SD card,
despite having the drive built in. Sucks.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml


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

Re: Fwd: Proposal: switch default desktop to xfce

[Andrew Kane]

On Fri, Oct 25, 2013 at 4:13 PM, Ian Campbell  wrote:
> On Fri, 2013-10-25 at 07:51 -0700, Andrew Kane wrote:
>
>> As someone who deals with a lot of random donated hardware, I can
>> attest that we run into these cases frequently.
>
> Interesting data point, thanks. hat sort of vintage of random hardware
> are you seeing?

The majority of what we see is about 4-8 years old, I'd say. The
oldest system I remember seeing was a 486; until recently we had a few
ISA SCSI cards in inventory. Really old stuff like that mostly gets
disassembled and recycled, so I'm not including it in my estimation.
A lot of these boxes are ones that one would reasonably expect to
support booting from USB, but in some cases the option isn't there in
the BIOS setup or boot menu and in others the option is there but is
ignored on boot some or all of the time. The inability to boot from a
DVD correlates slightly with the former case but not with the latter;
for us it's moot anyway since we have a cd-sized Xubuntu install disk.

>
> Do these systems have NICs but not PXE support?
We don't yet have a PXE server set up, that's in progress but waiting
for me to complete a few other projects first ;)

> Could something like
> http://etherboot.org/wiki/isolinux be useful to boot such a system from
> CDROM to kick off a network boot?

I expect it would. Any live media that provides GRUB can also be used
to grab a PXE boot IIRC- though I've not done it yet.



-- 
Helping Seattle's Needy Get Nerdy
http://freegeekseattle.org/wiki/index.php/Free_Geek_Seattle:About

http://freegeekseattle.org/wiki/index.php/Projects

Maillist:
https://groups.google.com/forum/?fromgroups#!forum/freegeek-seattle

IRC:
#freegeek-sea on freenode

freegeekseattle.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKErO63NvQ1ftmj+71LyP-WH==ijFzXC_TJ=uigmuxn0inw...@mail.gmail.com

Re: Proposal: s have a GR about the init system

[Scott Kitterman]

Russ Allbery  wrote:
>Steve McIntyre  writes:
>> Bastien wrote:
>
>>> It seems that the tech committee is composed of two well known
>ubuntu
>>> developers.  Isn't that biased? I mean do you see them voting
>against
>>> upstart, I know that the decision should be based around technical
>>> facts, but that is not in their interest to vote against their
>project,
>>> especially since canonical is isolating itself from the rest of the
>>> community, so having Debian support is, I guess, really important,
>so
>
>> -1, Troll.
>
>> Please apologise to the TC members immediately for your insinuations
>> of corruption, or go away and don't come back.
>
>Hang on a second.  I really don't think Bastien is accusing people of
>corruption.  Rather, he's saying that people have a conflict of
>interest.
>And he's right; there is a conflict of interest.
>
>I think it's fair game to say that, and I think it's important to say
>that.  Governance processes should be open and forthright about
>conflicts
>of interest.
>
>Just because someone is conflicted doesn't mean that there's
>necessarily a
>problem, or even that they necessarily need to recuse themselves.  It
>all
>depends on the nature of the conflict and the nature of the issues
>involved, what role they have in the decision-making process, and so
>forth.  But those conflicts absolutely should be acknowledged, since
>that's the first step in analyzing what action should be taken about
>them,
>if any.
>
>Free software communities tend to be small and very tightly entwined,
>so
>conflicts of interest are (in my experience) common in free software
>governance and sometimes unavoidable.  That makes it all the more
>important to talk about them, be conscious of them, and decide how one
>is
>going to handle them.  You'll often see people talk about taking off or
>putting on different hats; that is, in part, a ritual and mental
>reminder
>that one has potential conflicts of interest and one should be very
>clear
>in one's own mind about what role one is playing at any given point. 
>For
>example, I also have multiple potential conflicts of interest in my TC
>work: I'm also a Policy editor, which can be relevant when the TC issue
>is
>an escalated Policy dispute, and I work for an employer who uses Debian
>heavily and therefore have an incentive to support things in Debian
>that
>my employer would want to see happen.  Those are conflicts that I have
>to
>be aware of and manage.
>
>There's absolutely nothing wrong with publicly discussing conflicts of
>interest and being aware of them, and reminding people that they do
>have
>conflicts.

I think that is all true and correct, but I certainly didn't get that from the 
original message. It certainly read to me like an attempt to undermine the 
legitimacy of any future TB decision in favor of upstart.  ICBW, of course. 

Scott K



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2cd05438-6f04-4145-a0ec-898b26d3e...@email.android.com

Re: let's split the systemd binary package

[Kevin Chadwick]

> You're aware that GNOME and systemd upstreams are two completely
> distinct groups

But they do both have strong redhat links, coincidence or not.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/150504.92540...@smtp118.mail.ir2.yahoo.com

Re: systemd effectively mandatory now

[Kevin Chadwick]

> This is a move to SABOTAGE linux as an OS. 

I have to admit if RedHat stuck to kernel work, I would be much
happier.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/756315.92540...@smtp118.mail.ir2.yahoo.com

Re: let's split the systemd binary package

[Kevin Chadwick]

> E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit,
> you'll notice it is NOT maintained.

XFCE *needs* neither and in fact the vast vast majority of users do
not either.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/499122.81463...@smtp137.mail.ir2.yahoo.com

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

[Kevin Chadwick]

> I'm fed up with repeated attempts to force components on the rest of the
> system, but that's mostly a fault of Gnome's upstream

There seems to be a trend emanating from packages involving RedHat devs.
I actually went to the RedHat site a few weeks ago to try and get some
sort of oversight on this but there seemed to be no appropriate contact
point (bookmarked).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/572460.92540...@smtp118.mail.ir2.yahoo.com

Re: let's split the systemd binary package

[Kevin Chadwick]

> without being micromanaged in what they put into their dependency
> fields.

That's an odd comment as the dependencies should ideally be the very
minimal that are absolutely required. (I understand it may not be
always easy)

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/75658.92540...@smtp118.mail.ir2.yahoo.com

Re: systemd effectively mandatory now due to GNOME

[Kevin Chadwick]

> * it is buggy.  I did install a straightforward install of experimental
> GNOME to test if it improved even a bit, running systemd as init, and, with
> 2G RAM assigned to the machine, I got an OOM from one of systemd's
> components.  Excuse me for not looking more closely but purging the machine
> and running away screaming: even in early stages of integration, an init
> system which even *can* possibly OOM is not fit for any non-toy use.
> 
> * it breaks other users of cgroups.  I have not tested this personally
> (mostly because of the above point), but if I understand it right, it takes
> over the whole cgroups system, requiring anything that runs on the same
> kernel instance to beg it via dbus to perform required actions.  This might
> be possible to organize on a single system, but not really between multiple
> systems on the same kernel.  Even if you run massive Rube Goldberg tricks
> (akin to those once needed for dbus inside a chroot), this is still doable
> only if you run the same version both in host and guests.  And I for one
> heavily use vservers, which are supposed to be replaced with lxc.  Not being
> able to run an arbitrary, possibly old[2], distribution in a guest -- or even
> being able to move a live system into a container, without replacing its
> init system, means it's a no-no for me.

* CVE 2013-4327 - Towards a world where even simple systems and
firewalls are vulnerable!

p.s. CVE-2013-4392, CVE-2013-4391 and I think I've missed out the really
bad one to do with remote connection.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/441543.92540...@smtp118.mail.ir2.yahoo.com

Re: let's split the systemd binary package

[Kevin Chadwick]

> > I believe that systemd/GNOME upstream is intentionally coupling the two
> > in order to force adoption of systemd.  There are obviously others who
> > do not believe this.  If it is true, however, I would consider it
> > sufficient justification to both change Debian's default DE and
> > eliminate systemd as a candidate for the default init system, regardless
> > of any technical merits.  
> 
> +1

+1 (I thought it had already been announced as planned)

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/994695.92540...@smtp118.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

> Pros:
> 
>  * CD#1 will work again without size worries
> 
>  * Smaller, simpler desktop
> 
>  * Works well/better on all supported kernels (?)
> 
>  * Does not depend on replacing init

* Users can pick and choose components and drop down the size
  significantly such as for debian embedded or security reasons as it
  is designed to be modular and follow the unix philosophy.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/722750.92540...@smtp118.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

> > Why should I have installed packages I'm not using and I don't want to
> > use?  I know it's rhetorical question but not all systems are having
> > enough disk space besides I don't like have packages I'm not using on
> > my systems.  So it's not a solution to anything just kind a nasty
> > workaround.  
> 
> But you would be using it, if you've got it installed as a GNOME
> dependency and you are using GNOME. It does more than one thing:
> it's an init, and it does other bits, and the other bits are what
> GNOME needs. It's not a superfluous dependency.

I have Gnucash installed and it depends on udisks, trust me I have
absolutely no need for udisks or polkit, so don't be so sure (I am not
saying that I am sure that he is not).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/608372.92540...@smtp118.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

> For people who just don't care, are you doing them a favour by installing
> xfce rather than GNOME?
> 
> I don't think so. Most of the things people hate about GNOME are things that
> GNOME is doing to specifically target people who just don't care.

Personally I wouldn't put Gnome 3 in front of new users as with
my only fairly short lived recent experience you would end up similar to
win8 with the "how do I shutdown issue". I switched my parents over to
XFCE (without udisks, polkit, some system dbus-services even) from
Unity and they are very happy.

Another plus, XFCE is fast on many systems, you cannot say that about
KDE and Gnome.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/149526.92540...@smtp118.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

> XFCE is short of maintainers, both upstream and debian, but 4.12 is
> expected to be released sometime in the next 6 months. That said,
> everything both debian and upstream is stable, and a number of 4.11
> "development release" packages are able to be uploaded to experimental
> if more people come onboard to help with the resultant bugs.

I built and installed 4.10 towards the end of old stable with little
problem but improvements so I don't think it would be much work. I have
no doubt I would have hit some major blockers trying to do that with
newer Gnome or KDE.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/638409.92540...@smtp118.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[brian m. carlson]

On Fri, Oct 25, 2013 at 02:15:02PM -0400, Joey Hess wrote:
> Also, I was not in a position to try gnome 3.4 myself at all, hardware,
> and bandwidth wise, until rather too late in the release cycle. I didn't
> see conclusive proof that gnome 3.4 was really the wrong default for
> wheezy until I started putting it on end-user machines and seeing them
> struggle with it, and then be perfectly happy when switched to xfce.
> (A few such real world tests are much more useful than a metric mutt-load
> of threads.)

I can confirm that XFCE tends to work much better than GNOME on older
hardware, and has for years.  Back when my iBook G3 was my only laptop,
I installed XFCE on it because GNOME eventually became too heavyweight.

I can also say that generally people who come from Windows and Mac OS X
tend to understand and be able to work with XFCE a little more easily
than GNOME, in my experience.  I have friends who have seen me use both,
and they have generally found GNOME Shell a bit confusing when they've
needed to use my laptop.

Finally, XFCE provides a bit more customizability out of the box than
GNOME does, or at least it did when I switched.  I distinctly remember
that there were several settings that XFCE provides in the settings
dialogs that required arcane trips through the gconf/dconf settings, if
they were there at all.  It's possible that's changed, though.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable

[Colin Watson]

[Not defending the rather odd NMU practice here, but ...]

On Fri, Oct 25, 2013 at 12:57:24PM +0200, Rene Engelhard wrote:
> Until then there's no action needed to make it work in Debian. Debian is
> not Ubuntus development platform, so why should one NMU stuff for  this
> when it's not needed in Debian _yet_?

The usefulness of supporting --as-needed isn't because of Ubuntu.  It's
because switching --as-needed on across the board lets us easily cut out
a swathe of unnecessary direct DT_NEEDED entries in binaries, which in
turn removes unnecessary direct dependencies which cause transition
headache, and reduces the probability of future crashes due to libraries
that are both directly and indirectly linked changing their SONAME
without perfect coordination.  Forget about Ubuntu, and the unsurprising
fact that a good percentage of the patches you see for this class of
issue come from Ubuntu; this would be good for *Debian*.

By saying "it's not needed in Debian yet", you're setting up a deadlock.
The more packages that would fail to build as a consequence, the harder
it is to change the toolchain defaults.  It's valuable to fix this kind
of thing in advance, just as (for example) it's valuable to make sure
that config.guess/sub files are suitably updated in advance of somebody
actually coming along and trying to bring up new architectures in
Debian.

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


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

Re: Fwd: Proposal: switch default desktop to xfce

[Ian Campbell]

On Fri, 2013-10-25 at 07:51 -0700, Andrew Kane wrote:

> On Fri, Oct 25, 2013 at 6:09 AM, Ian Campbell  wrote:
> >
> > On Fri, 2013-10-25 at 13:31 +0100, Steve McIntyre wrote:
> > > ...I've been
> > > told multiple times that we still have a non-negligible set of users
> > > owning/running hardware that can't do DVDs.
> >
> > The set of hardware which can't boot from DVDs *or* boot from a USB
> > stick must surely be pretty tiny. (AIUI it is the DVD ISOs which can be
> > thrown onto a stick, so throwing away CDs wont hurt that)
> >
> > Add in "or boot from network" and it must be a minuscule set.
> >
> As someone who deals with a lot of random donated hardware, I can
> attest that we run into these cases frequently.

Interesting data point, thanks. hat sort of vintage of random hardware
are you seeing?

Do these systems have NICs but not PXE support? Could something like
http://etherboot.org/wiki/isolinux be useful to boot such a system from
CDROM to kick off a network boot?

Ian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382742831.22417.159.ca...@hastur.hellion.org.uk

Re: Proposal: switch default desktop to xfce

[Jukka Ruohonen]

On Fri, Oct 25, 2013 at 07:56:20PM +0200, Martin Steigerwald wrote:
> I do see quite an amount of ignorance and pushing regarding adoption of 
> systemd and GNOME. I fully accept that it may be difficult to agree on a way 
> forward? but currently I get the impression that any neither GNOME nor 
> systemd 
> upstream actually cares about agreement with all involved parties. systemd 
> developers are not even willing to accept patches to make systemd portable.

Indeed. And given the train wreck of contemporary Gnome, I fully welcome the
discussion on alternative default desktops. Some people are keen to rule out
the stakeholder issues, but a fact on the so-called agenda remains.

- Jukka.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131025231211.GA9076@marx.bitnet

Re: Proposal: let’s have a GR about the init system

[Colin Watson]

On Sat, Oct 26, 2013 at 12:36:15AM +0300, Uoti Urpala wrote:
> I don't think the technical experience would be that much of an issue,
> but I do see being employed by Canonical as a very substantial conflict
> of interest. IIRC Canonical has made an official statement that they
> will keep supporting Upstart and believe in it. This is a fairly visible
> company choice. Your work environment has at least at some level an
> official policy that Upstart should be considered better than systemd.
> Ubuntu still wants to keep using Upstart, but if Debian chooses systemd,
> Ubuntu will likely also need to admit that Upstart failed and plan for a
> switch.

Possibly.  It would certainly impose a cost on Canonical.  Like any such
cost, though, you should expect companies to look at both sides; the
counterweight would be that Canonical has built a lot of technology and
expertise around Upstart, and switching would carry its own significant
costs.

One thing to point out is that Ubuntu has come this far without Upstart
being the default init system in Debian, and the initial deployment
didn't *require* it to be in Debian at all; it's certainly both in the
interests of Canonical economically and in the personal interests of
those of us who are both Debian and Ubuntu developers to merge back as
much as possible, but the relevant stack of patches to add Upstart jobs
isn't actually a particularly horrible patch set to have to carry.
Sure, there are things like logind integration, but they're not really
that big a deal in the grand scheme of things.  My personal opinion is
that you'd have to look at rather a long time interval to reach the
point where the effort of leaving things be exceeded the effort of
migrating.

> If your vote decides that Debian will choose systemd, and as a result
> upstreams conclusively drop any support for Upstart while Ubuntu still
> wants to keep using it, do you believe this will not have any negative
> consequences for your career at Canonical?

Firstly, many Upstart jobs are carried in packaging, just as many init
scripts are.  I don't know how much of a dent Debian's decision would
make for upstreams, and furthermore I don't know offhand what percentage
of packages it would affect even if all upstreams immediately deleted
all Upstart support.  So this is really a worst-case scenario rather
beyond what I would expect.

Secondly, I've been at Canonical for a long time and (setting aside
false modesty) I believe I have an excellent record in performance
reviews and the like.  I'd expect to be asked to justify myself if I
came to the conclusion that a systemd default was the best thing for
Debian, but I'm not afraid for my job.

Cheers,

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


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

Re: Proposal: switch default desktop to xfce

[Steve McIntyre]

Joey Hess wrote:
>Steve McIntyre wrote:
>> This goes back to during the wheezy release cycle. There was a little
>> discussion around a change in tasksel [1], but rather too late in the
>> day for the change to make sense. Now we have rather more time, I
>> feel. Let's change the default desktop for installation to xfce.
>
>So, I wish that wheezy had shipped with xfce as the default. It was the
>better choice of the options we had (although possbly kde would have
>been a good choice too).

Right.

...

>Anyway, at the moment I don't know which is the right choice for jessie.
>There is a full year for gnome to be improved, and it could easily be
>a better experience for users at that point. I would not be opposed to
>changing the default for xfce for now, and reverting it if gnome's
>improvements make it a better choice.

OK. I suggest that we *try* that for now. I'm also suggesting that we
drop our CDs soon, *except* for keeping the netinst around. Unless we
get a lot of feedback from people asking explicitly for full CD sets,
I'm more convinced than ever that we can just drop them.

>I do wish that some of the .. energy .. seen in these threads could be
>used for something more interesting. For example, find a way to detect
>touch screen systems, on which xfce is *not* pleasant, and don't install
>a desktop task there, but a separate task with whichever UI is currently
>best suited for tablets.

OK... :-)

>>  * Tweak CD and installer builds:
>>+ change what happens with no desktop selected to use xfce instead
>>  of Gnome (netinst, DVD, BD etc.)
>
>The tasksel change handles that.

Almost all of it. debian-cd/tools/update_tasks will also need some
simple tweaks. At the moment, for example, a generic build implies
task-gnome-desktop, and that would need changing.

>>+ Add an explicitly-named Gnome CD#1
>>+ Remove the explicitly-named XFCE CD#1
>
>You might consider making the default CD be a symlink to the explicitly
>named desktop CD.

If we keep them, sure.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vzqjt-00010r...@mail.einval.com

Re: Fwd: Proposal: switch default desktop to xfce

[brian m. carlson]

On Fri, Oct 25, 2013 at 05:49:59PM +0200, Adam Borowski wrote:
> On Fri, Oct 25, 2013 at 07:51:48AM -0700, Andrew Kane wrote:
> > As someone who deals with a lot of random donated hardware, I can
> > attest that we run into these cases frequently. It may be rare that
> > new systems lack these capabilities,
> 
> Donated x86 hardware that lacks an USB port?  I kind of believe that not.

I used to have an x86-64 box that claimed to support booting from a USB
stick but steadfastly refused to do so.  As someone who until recently
did desktop support for years, I can tell you that there are a lot of
machines I've encountered that can't boot off a USB stick, and maybe
about a third of those don't do DVD.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Steve McIntyre]

Andy Cater wrote:
>On Fri, Oct 25, 2013 at 01:41:42AM +0100, Steve McIntyre wrote:
>> 
>> I guess not everybody understands the reasons for Debian choosing a
>> default desktop, so I'll explain/expand them here.
>> 
>> 1. We have several types of installation media (netboot, netinst, DVD,
>>BD) where we can happily install any desktop - they either contain
>>*all* of the bits needed for any of the desktops, or *none*. The
>>choice was made years ago to *not* ask users which desktop they
>>prefer during the tasksel phase, to reduce the number of questions
>>that new users would have to answer. Hence, we chose a
>>default. Since that point, we've added options in the boot menus on
>>these generic media (where possible, via isolinux or grub) to make
>>it easier to make a desktop choice, but to the best of my knowledge
>>most people just take the default option. We *could* revisit the
>>tasksel design choice to not list all the desktops if people want -
>>that's another discussion to have, maybe.
>> 
>
>I think it would be a good idea to have the netinst have an
>additional option to select desktop easily including the option for
>"command line only, no graphical desktop" as default.

We already have that option right now - in fact, you can deselect the
"graphical desktop" task readily tasksel from any of the installation
media and just get a simple command line system. Or are you
specifically asking for such an option directly on the isolinux/grub
installer boot screen?



>Can DVD #1 install multiple desktops in and of itself? For machines that can 
>boot
>from USB, I now routinely dd the image of DVD1 straight onto a 4GB stick and 
>go from there.

Yes, it can. It should contain enough of the packages needed to be
able to support all 4 of the recognised DEs. However, at current rates
it won't take long for them to outgrow the 4GB of space available!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vzq7c-rd...@mail.einval.com

Re: Please assume good faith

[Thorsten Glaser]

Nikolaus Rath dixit:

>To cut a long story short, I am not convinced that by open sourcing my
>code I am acquiring a moral obligation to take into account the
>preferences of potential users in future versions - no matter how large

But that’s just the thing! You are!

Of course, only in a way, and only morally, but if you want to
ever have people building systems with blocks of yours again,
you better do, or you lose credibility.

Open Source is *not* about the code, or the licence. It’s about
Free Users, and it’s a way of life, and this includes the way
things are developed. (For example, many projects from larger
companies aren’t; pcc doesn’t feel like it either, and, naming
it explicitly because it’s different in a different way than
what I mean with “projects from companies” above, MySQL sure
as hell isn’t, either.)

bye,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine


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

Re: Please assume good faith

[Russ Allbery]

Nikolaus Rath  writes:

> To cut a long story short, I am not convinced that by open sourcing my
> code I am acquiring a moral obligation to take into account the
> preferences of potential users in future versions - no matter how large
> (or vocal) the userbase.

+1

Obviously, there are drawbacks to not maintaining backward compatibility,
and some people (possibly a lot of people) may decide not to use the new
version.  But as long as one is clear about what one is doing, there isn't
any more of a moral obligation to maintain backward compatibility than
there is to continue to work on the open source software project in the
first place.  (It should be trivially obvious why this is the case.)

Unless we think upstreams should no longer be allowed to stop doing their
volunteer maintenance of their projects, we can't argue that they should
be required to maintain backward compatibility either.

If you want control over how someone maintains software, get into a
contractual arrangement with them.  This will probably require money
changing hands, since at that point you've turned the software maintenance
into a job.  People are generally only willing to give up their autonomy
in this fashion in exchange for some other benefit, generally money.

If one doesn't have that sort of contractual relationship, politeness
dictates that one stop at expressing preferences or discussing possible
alternatives and not continue on to dictate what other people do with
their time.

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


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

Re: Please assume good faith

[Nikolaus Rath]

Thorsten Glaser  writes:
> Lars Wirzenius  liw.fi> writes:
>
>> I write a backup program. It uses its own storage format, and people
>> sometimes ask if they could use tar files instead. But I am evil
>> incarnate and FORCE them to use my own storage format instead. Should
> […]
>> can be, and I think that the storage format I've developed is better
>> than storing backups in tar files. I truly, deeply feel that using my
>> format makes the program better, and that offering tar as a choice
>> would be pretty much disastrous, because almost all of the features I
>
> This *is* bad because if there is an existing userbase with tar (which
> isn’t true in the obnam case, sure, but would be true if you were to
> try forbidding all other backup programs in Debian) this will break
> their use cases, and *that* is what the systemd situation is all
> about.

I don't understand this point of view. Even if there is an existing
userbase, I don't think that would obligate me (as the author) in any
way to support them in the future. If they do not like the changes I'm
making, they are free to stick with an older version (or fork the
program, or contribute patches). If you do not consider this a valid
option, would you also say that by publishing my code, I suddenly have
an obligation to maintain it forever? Since otherwise people would end
in the same situation in which they are if they don't agree with my
choices: they're stuck with an old, unmaintained version.


To cut a long story short, I am not convinced that by open sourcing my
code I am acquiring a moral obligation to take into account the
preferences of potential users in future versions - no matter how large
(or vocal) the userbase. 



Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8761slhwbh@rath.org

Hostile upstreams (was Re: Proposal: ...)

[Steve McIntyre]

Paul Tagliamonte wrote:
>On Fri, Oct 25, 2013 at 06:14:18PM +, Thorsten Glaser wrote:
>> Isn’t that a reason to rather remove it, under the hostile upstream
>> clause (cf. J�rg Schilling), or at the very least, not base anything
>> important on it?
>
>Hostile upstream != GPL / CDDL incompatabilities.

I don't know how aware you are of the history with Schily; a hostile
upstream with a willfully strange interpretation of how GPL works is
worse than just GPL / CDDL incompatibilities.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vzpoe-j6...@mail.einval.com

Re: systemd effectively mandatory now due to GNOME

[Steve Langasek]

On Thu, Oct 24, 2013 at 12:37:11PM -0700, Russ Allbery wrote:
> Christoph Anton Mitterer  writes:

> > Well I hope this doesn't turn into some kind of flame war... about
> > systemd, GNOME or similar.

> > In sid, gnome-settings-daemon depends now on systemd.

> I'm missing a key bit of context here.  Does gnome-settings-daemon just
> require that systemd be installed?  Or does it require that the init
> system be systemd?

> The systemd package itself can be installed without changing init systems,
> so it's possible that gnome-settings-daemon just needs the non-init parts
> of this and one can install systemd for those bits and then go on with
> one's life without changing init systems.  However, I don't know if
> systemd installed this way then starts its various non-init services.

> This seems like a fairly critical question, since if all that is required
> is for the systemd package to be installed (but without a change in the
> init system), this is all a tempest in a teapot.

Formally, it only requires that the dbus services be available, which is
given by installing the systemd package, not by running it as init.

But there are several issues with having this all in one package the way it
is currently.  In addition to the dbus services, the systemd package ships:

 - /lib/lsb/init-functions.d/40-systemd - functions which permute the
   behavior of LSB init scripts
 - /lib/udev/rules.d/99-systemd.rules - udev rules that will be active on
   any system with /sys/fs/cgroup/systemd present (because of logind, this
   directory is not a good proxy for whether pid1 == systemd).

So even if you consider it reasonable for the GNOME desktop to depend on a
package which ships commands on the path that won't do sensible things
unless you use systemd as init (I don't consider it reasonable FWIW), it's
not the case that the rest of the package aside from these dbus services is
inert on the filesystem.  There are runtime side effects here that have
nothing to do with the dbus services that GNOME actually is interested in.

And then there's the matter of the ambiguity that's introduced by using a
dependency on a package providing an init system to express a logical
dependency on a dbus service.

-- 
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

Re: [ANNOUNCE] git-deb: a Git importer for Debian packages

[Gabriel de Perthuis]

Le ven. 25 oct. 2013 21:34:39 CEST, Joey Hess a écrit :
> Gabriel de Perthuis wrote:
>> I only know what dgit does from reading the source code.  dgit works
>> server-side and is only available to DDs; as I understand it it creates
>> a new, canonical repo, imports the current version and uses that as a
>> base for new uploads.  It's useful as part of a maintainer's workflow.
>> My tool is useful to get a git view of any package, without waiting for
>> anyone to convert their repo.
>
> Conceptually, they are quite similar. Both are viewing the Debian
> archive as poor man's version control system, and providing a git
> interface to it. dgit doesn't currently concern itself with downloading 
> historic versions of the package, so it essentially does a shallow clone
> from the archive, while git-deb does a deep clone.

Okay.  They also integrate with git in different ways: dgit calls git
commands here and on alioth, while git-deb is essentially a git plugin.
 Aside from the unusual url, it's just another remote in a standard git
repo.

> It would be useful if you could arrange for git-deb to produce the
> identical git commit shas for importing a given version of a package as
> does dgit. dgit uses some simple techniques, like using the
> debian/changelog date as the git commit date, to ensure that repeatedly
> importing the same version of a package from the debian archive will
> always yield the same sha.

I've mentioned in this thread that the fast-import stream is stable.
It is derived from changelogs and dsc signatures.  That makes the top
hash of an import stable.

Matching dgit repos will have to come through graft points; I'm not
going to shed useful metadata or freeze the stream format.  The benefit
would be dubious since a shallow stream would never match anyway.

> Note that you can use dgit clone any package without being a Debian
> developer. You only need an alioth account in order to dgit push.

Here's what it looks like:
Permission denied (publickey).
ssh: failed command: ssh coccia.debian.org 'set -e; cd
/srv/ftp-master.debian.org/ftp/dists; if test -h unstable; then readlink
unstable; exit 0; fi; if test -d unstable; then echo unstable; exit 0;
fi; exit 1'
dgit: subprocess failed with error exit status 255


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526aeab4.2000...@gmail.com

Re: Proposal: switch default desktop to xfce

[Josselin Mouette]

Le vendredi 25 octobre 2013 à 13:36 +0100, Neil Williams a écrit : 
> I firmly
> believe that GNOME threw away that justification with GNOME Shell and
> if GNOME persists in the eye-candy approach and then adds an entirely
> unjustifiable dependency from a *desktop* to an *init* system then I
> have no reason to respect GNOME or GNOME maintainers ever again.

This is clearly the problem here: respect. You are not showing any.

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


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

Re: Proposal: switch default desktop to xfce

[Josselin Mouette]

Le vendredi 25 octobre 2013 à 18:15 +0100, Neil Williams a écrit : 
> The option existed to make the desired features optional and that
> option was deliberately written out in an effort to extend GNOME beyond
> a desktop. 

Oh, but of course these features are optional. You can still run GNOME
without any of them. I can’t guarantee this will be a pleasant
experience, but maybe you manage your device groups yourself, do not
care about user switching, and do every operation needing temporary
privilege escalation in a root terminal.

If you want to get logind split out and working without systemd as init,
just go ahead and show us the code, nobody is stopping you. But please
stop complaining that GNOME is using the only available implementation
for these features.

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


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

Re: Proposal: switch default desktop to xfce

[Nikolaus Rath]

Neil Williams  writes:
> If someone comes up with good reasons to consider systemd on it's own
> merit, I'm willing to consider it. With the current approach of a
> fait-accompli "systemd is part of the GNOME dependency chain, so tough"
> then I am quite happy to dismiss systemd as an option simply because of
> this insane top-down dependency. systemd simply cannot be a viable
> choice if it has to be forced down people's throats like this.

Please reconsider this. If I wrote a little GUI calculator and made it
depend on e.g. upstart, would that also make upstart unsuitable as a
default init system because of the resulting insane top-down dependency?


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738nphv1x@rath.org

Re: Proposal: let’s have a GR about the init system

[Christoph Anton Mitterer]

On Sat, 2013-10-26 at 00:36 +0300, Uoti Urpala wrote:
> I don't think the technical experience would be that much of an issue,
> but I do see being employed by Canonical as a very substantial conflict
> of interest. IIRC Canonical has made an official statement that they
> will keep supporting Upstart and believe in it. This is a fairly visible
> company choice. Your work environment has at least at some level an
> official policy that Upstart should be considered better than systemd.
> Ubuntu still wants to keep using Upstart, but if Debian chooses systemd,
> Ubuntu will likely also need to admit that Upstart failed and plan for a
> switch.
> 
> If your vote decides that Debian will choose systemd, and as a result
> upstreams conclusively drop any support for Upstart while Ubuntu still
> wants to keep using it, do you believe this will not have any negative
> consequences for your career at Canonical? I consider this the biggest
> question about the conflict of interest, more than direct "you must vote
> this way" pressure from your employer.


I would see it the same way... it's not only a question whether
objective ruling would be made, but also whether it could bring our
tech-ctte members into troubles when they decide (i.e. against
upstream).

And another issue: If e.g. tech-ctte (with some Canonical employees in
it) now decides in favour of upstart... then we'll see forever people
who challenge the neutrality and objectiveness of such decision.

The best would probably be, if people who are either
- directly involved in the development of any of the discussed
init-systems (in the sense of playing a bigger part)
- who work for a company which is pushing the respective system (RedHat,
Canonical) or
- who maintain the respective package in Debian
should abstain from the decision, but just provide their technical input
and arguments.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Proposal: switch init system to systemd or upstart

[Steve Langasek]

On Fri, Oct 25, 2013 at 02:09:44PM +0100, Neil Williams wrote:

> Are either of the alternatives, at the versions currently in Debian
> testing, ready for the migration? (I have no idea, I'm wondering out
> loud).

upstart is two package integration uploads away from being ready.

> How long might the migration take? Are we talking Jessie or Jessie+1
> here? Jessie+2?

There's no reason not to make the change in jessie, once the decision is
made.

> I can see some / many services being migrated but *all* ?

All the options maintain compatibility with sysvinit scripts; there is no
flag day here.

-- 
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

Re: supporting more than one... (Re: let's split the systemd binary package

[Steve Langasek]

On Fri, Oct 25, 2013 at 10:31:57PM +0200, Marco d'Itri wrote:
> > Seriously, we are supporting more than one init system already and this is 
> > a 
> No, we are not. Only a tiny number of packages do ship configuration 
> files for systemd and/or upstart, and the really important ones (the 
> boot infrastructure: mounting local/remote block devices, enabling 
> networking, etc) only supports sysvinit.

Not true.  If you know of any bugs in the boot infrastructure for upstart,
please let me know - but aside from plymouth integration, TTBOMK this is all
done.

-- 
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

Re: Proposal: switch default desktop to xfce

[Josselin Mouette]

Le vendredi 25 octobre 2013 à 14:21 -0400, Joey Hess a écrit : 
> > I humbly disagree. I'm mainly interested in the perspectives of systemd on
> > servers.
> 
> Systemd on servers is offtopic for this thread.

Not when one of the nonsensical arguments used for systemd-bashing is
that it would be inappropriate for servers.

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


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

Re: Proposal: let’s have a GR about the init system

[Uoti Urpala]

Colin Watson wrote:
> I've done some work on Upstart itself and a good deal more designing
> subsystems around it; no doubt that experience will have a bearing on my
> vote.  The other Technical Committee members will also surely bring
> relevant experience of one kind or another to the table, as we've all
> worked on a wide range of systems with considerations that relate to the
> varying designs of systemd and Upstart.

It unfortunately seems that nobody on the ctte is particularly familiar
with systemd though (unless someone there has studied it in private), so
a decision would need to be mainly based on evaluating the
representations of others.


>   Anticipating the kind of
> accusation that Bastien makes, I talked with Bdale at DebConf in his
> capacity as TC chair and asked whether he felt I should recuse myself; I
> don't remember exactly the words he used but I think it was something
> along the lines of TC members not needing to recuse themselves just
> because they happen to have relevant technical experience.

> One thing I will say here and now: if I feel under pressure from my
> employer to vote a particular way, then I will immediately recuse myself
> from the vote and from further part in the discussion.  I'd hope that

I don't think the technical experience would be that much of an issue,
but I do see being employed by Canonical as a very substantial conflict
of interest. IIRC Canonical has made an official statement that they
will keep supporting Upstart and believe in it. This is a fairly visible
company choice. Your work environment has at least at some level an
official policy that Upstart should be considered better than systemd.
Ubuntu still wants to keep using Upstart, but if Debian chooses systemd,
Ubuntu will likely also need to admit that Upstart failed and plan for a
switch.

If your vote decides that Debian will choose systemd, and as a result
upstreams conclusively drop any support for Upstart while Ubuntu still
wants to keep using it, do you believe this will not have any negative
consequences for your career at Canonical? I consider this the biggest
question about the conflict of interest, more than direct "you must vote
this way" pressure from your employer.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382736975.1856.108.camel@glyph.nonexistent.invalid

Re: Proposal: let’s have a GR about the init system

[Steve Langasek]

On Fri, Oct 25, 2013 at 04:42:18PM +, Thorsten Glaser wrote:
> >We support three init-systems badly. We should fully support one
> >init-system and make it awesome and easy to use, and not having many
> >half-baked solutions which are a pain to maintain.

> I disagree: neither upstart nor systemd are “one size fits all”,
> nor do they intend to.

I'm not sure where you get that impression.  Upstart and systemd both intend
to be the only init system you'll ever need.  Unfortunately, that's not a
title that they can easily share. ;)

-- 
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

Re: tech-ctte: Decide which init system to default to in Debian.

[Steve Langasek]

On Fri, Oct 25, 2013 at 09:43:17PM +0100, Jonathan Dowland wrote:

> They have proposed a release goal that is probably a necessary
> prerequisite for default init but has not yet been achieved.  (I wouldn't
> expect it to be, yet.  We aren't releasing for ages.)

No.  The decision of the default init system should be made *before* the
release team should be asked to sign off on a release goal of porting
packages to a particular init system.

As all of the init systems are compatible with the existing sysvinit
scripts, there's no technical reason that the porting work should be done
before deciding which should be the default, or even before changing the
default.

The TC should certainly not force a change in the archive before the pieces
are technically ready, but I don't see any reason to delay the question any
further.

-- 
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

Re: tech-ctte: Decide which init system to default to in Debian.

[Uoti Urpala]

Jonathan Dowland wrote:
> Whilst I think you have honourable intentions in referring this to tech-ctte, 
> I can't help but think it's premature.
> 
> The systemd maintainers have never said that they believe systemd is ready to 
> be the default init nor whether they could handle supporting it if the 
> decision was made out of their hands.
> 
> They have proposed a release goal that is probably a necessary prerequisite 
> for default init but has not yet been achieved. (I wouldn't expect it to be, 
> yet. We aren't releasing for ages.)
> 
> If asked what init system should be default *now* the only reasonable answer 
> is "stick" but that isn't a useful question.

I don't think the release goal of having native files for everything
would be a prerequisite; I see no particular reason why it would not be
OK to change default while some packages still use sysv compatibility.
But it's true that actually changing to default is not a question for
right now. However, I still think it would be appropriate to make a
decision (and would have already been appropriate to do it earlier). The
properties of the systems that the decision should be based on are not
likely to change - the future init system should not be decided based on
how polished the packaging is at the moment. In fact I'd consider it
insane to fully polish everything to be ready for an actual switch, and
only THEN make a decision whether to actually use the result or throw
everything away.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382735781.1856.94.camel@glyph.nonexistent.invalid

Re: Proposal: switch default desktop to xfce

[Marco d'Itri]

On Oct 25, Steve Langasek  wrote:

> In the long term, we certainly need a decision for the default init system
> in Debian.
No: we need one in the short term to be able to support it in jessie, or 
we will be stuck with an antiquated init system for many more years.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Steve Langasek]

On Fri, Oct 25, 2013 at 09:26:09PM +0100, Jonathan Dowland wrote:
> > On 25 Oct 2013, at 21:04, Steve Langasek  wrote:

> > If someone is interested in maintaining Unity in Debian, I would be happy to
> > help figure out how Debian could leverage the existing CI infrastructure
> > that's in place for these packages in Ubuntu.

> Aren't these folks working on it?
> https://wiki.debian.org/Ayatana

Thanks, I hadn't seen that team mentioned before anywhere.  It looks like
the right place for this work to happen.  Unfortunately it seems rather
dormant, as the packages they do have in place date back to Ubuntu 12.04
(i.e., before any of the work on touch began in earnest).

-- 
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

Re: Proposal: switch default desktop to xfce

[Steve Langasek]

On Fri, Oct 25, 2013 at 06:15:27PM +0100, Neil Williams wrote:
> > On Fri, Oct 25, 2013 at 12:41:26PM +0200, Josselin Mouette wrote:
> > > Le jeudi 24 octobre 2013 à 16:40 +0100, Steve McIntyre a écrit : 
> > > > This goes back to during the wheezy release cycle. There was a
> > > > little discussion around a change in tasksel [1], but rather too
> > > > late in the day for the change to make sense. Now we have rather
> > > > more time, I feel. Let's change the default desktop for
> > > > installation to xfce.

> > > What are the reasons exactly for deliberately depriving the default
> > > installation’s users of a more complete and featureful desktop?

> > > So far, in this discussion, I only read “I don’t like
> > > systemd” (which is irrelevant)

> > This is a strawman.  The real objection is "tight coupling of a
> > desktop to an init system and kernel is at best lazy engineering, and
> > at worst a massive power grab by an upstream, and is contrary to
> > Debian's values."

> +1

> The option existed to make the desired features optional and that
> option was deliberately written out in an effort to extend GNOME beyond
> a desktop. A land grab.

> Other desktop environments have similar features without requiring a
> change of init system. It was a choice by GNOME upstream and a choice
> that could have had a much more friendly and supportable alternative.
> The choice has been made and it seems unlikely that GNOME upstream will
> now accept requests to change direction, leaving distributions to sort
> out the mess.

I'd like to be clear here that I do not fault GNOME upstream for making the
decision to leverage the systemd dbus APIs.  The session manager is a very
important component of the desktop, and as Olav has pointed out, the choices
in the field are logind or consolekit.  Of the two, logind is a much better
code base, with a better architecture that learns from the mistakes of
consolekit and takes advantages of Linux features (i.e., cgroups) that were
not available at the time consolekit was written.

The problem comes when logind in turn dictates the init system, which is
what happens with systemd 205.  Tollef, one of the systemd maintainers in
Debian, has said here that he "[does] explicitly not guarantee [running
logind without systemd init] will work at all."  As a systemd maintainer,
that's not an unreasonable position for him to hold; providing such a
guarantee would imply a lot of work that he doesn't want to commit to, work
which doesn't align with his and upstream's goal of seeing systemd more
widely adopted.

But each of these individual decisions, which are made in good faith and
represent a local optimum, result in a terrible outcome for Debian.

My assertion is that it's not acceptable to Debian for:

  GNOME to be the default desktop, and
  GNOME to depend on logind, and
  logind to require systemd init.

But there are multiple ways to solve this problem.  Steve McIntyre has
already made it clear that he thinks we should negate the first of these.  I
have no strong opinion on that, but do feel we should address the third of
these, because the logind service is actually quite good and desktop
environments *should* prefer that service over consolekit... they just
shouldn't be forced to adopt systemd init as baggage along with it.  And I
think Debian, as a project, should push back on this tight coupling, and
require an implementation of the logind interface independent from systemd
init.

In the short term, this could be a committment from the systemd maintainers
to hold the package at version 204 until the dust settles around cgroup
manager interfaces[1].  Or it could be an agreement to provide a 'logind'
virtual package for GNOME to depend on, and someone could repackage systemd
204 to provide the dbus services separately, so they remain independently
available even if the systemd package moves on in unstable.  This is
something I can imagine being willing to help with.  (It would probably be
less of a time committment than trying to keep up with this thread!)

In the long term, we certainly need a decision for the default init system
in Debian.  If Debian decides to adopt systemd as the default (via its
constitutional processes, not because a GNOME dependency forces the issue),
then it's not worth anyone's effort to maintain a fork of logind.  If the
decision is for something other than systemd, then we need to address the
maintenance of such a logind fork to make sure it remains viable, so that it
doesn't wind up bit rotting like consolekit.  That requires someone to put
their money where their mouth is, and be willing to maintain the code.

-- 
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

[1] Those interested in the cgroup ma

Re: tech-ctte: Decide which init system to default to in Debian.

[Paul Tagliamonte]

On Fri, Oct 25, 2013 at 09:43:17PM +0100, Jonathan Dowland wrote:
> Hi Paul,
> 
> Whilst I think you have honourable intentions in referring this to tech-ctte,

Thank you, I'm happy to hear it came across that way (it's how it was
done, FWIW)

> I can't help but think it's premature.

Perhaps.

> 
> The systemd maintainers have never said that they believe systemd is ready to
> be the default init nor whether they could handle supporting it if the
> decision was made out of their hands.
 
Technically speaking, I mean, fedora has been using it, as has a host of
other distros. Seems to work OK for them, I'm willing to bet we can make
it work too.

Also, to this point, if the systemd folks don't see this as something
that can handle pid1, and the maintainers say "We won't support
{logind,d-bus shutdown} without pid1", we have a massive problem with
GNOME depending on this.

Either way, *that* in of itself is something ctte-worthy, without init
judgement (although deciding init at the same time is something that in
so incremental from there, might as well do both)

> They have proposed a release goal that is probably a necessary prerequisite
> for default init but has not yet been achieved. (I wouldn't expect it to be,
> yet. We aren't releasing for ages.)
> 
> If asked what init system should be default *now* the only reasonable answer
> is "stick" but that isn't a useful question.
> 
> I'm worried asking and answering the question at such an early stage is going
> to prevent it being asked again at a more appropriate time.

It's perfectly OK for ctte to say "Well, this systemd thing is nice, but
the maintainers can't do this now. We'll re-evaluate in 6 months", or
something, if that's what they see.

> It does feel like we've spent a long long time discussing these things but as
> the saying goes, "talk is cheap, show me the code". Even a *lot* of talk is
> cheap.

I'm honestly just super tired of this thread. It keeps coming up time
after time after time after time.

I don't care if they decide something that I don't agree with -- at all --
I'd just prefer that we had *a* decision, backed with facts, that has a
Debian-ish argument behind it.


Much love,
  T

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

[Matthias Klumpp]

2013/10/25 Colin Watson :
> [...]
> One thing I will say here and now: if I feel under pressure from my
> employer to vote a particular way, then I will immediately recuse myself
> from the vote and from further part in the discussion.  I'd hope that
> would be generally understood as ethical behaviour.
And *that* is the point :-) All members of the TC have contributed
lots of useful stuff to Debian, and I trust everyone of them to has
the knowledge to decide on something for Debian, finding the
(technically) best solution. If some of the members do also contribute
to Ubuntu is irrelevant, and there are also other members who aren't
associated with Ubuntu.
The only thing I would not accept would be if a company forced a TC
member to manipulate a decision - I trust the individual TC members,
but not necessarily their employers.
But I don't see that risk here :-) Thank you so much, Colin, for
bringing this (IMHO very important) point up!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny_pJECoMFYo8RE+aHWQNP7pQ8-0ezM_k1A7=a6ylal...@mail.gmail.com

Re: supporting more than one... (Re: let's split the systemd binary package

[Marco d'Itri]

On Oct 25, Holger Levsen  wrote:

> Seriously, we are supporting more than one init system already and this is a 
No, we are not. Only a tiny number of packages do ship configuration 
files for systemd and/or upstart, and the really important ones (the 
boot infrastructure: mounting local/remote block devices, enabling 
networking, etc) only supports sysvinit.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: tech-ctte: Decide which init system to default to in Debian.

[Jonathan Dowland]

Hi Paul,

Whilst I think you have honourable intentions in referring this to tech-ctte, I 
can't help but think it's premature.

The systemd maintainers have never said that they believe systemd is ready to 
be the default init nor whether they could handle supporting it if the decision 
was made out of their hands.

They have proposed a release goal that is probably a necessary prerequisite for 
default init but has not yet been achieved. (I wouldn't expect it to be, yet. 
We aren't releasing for ages.)

If asked what init system should be default *now* the only reasonable answer is 
"stick" but that isn't a useful question.

I'm worried asking and answering the question at such an early stage is going 
to prevent it being asked again at a more appropriate time.

It does feel like we've spent a long long time discussing these things but as 
the saying goes, "talk is cheap, show me the code". Even a *lot* of talk is 
cheap.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ef350060-7139-425a-bb45-1334e69af...@debian.org

Re: Proposal: switch default desktop to xfce

[Jonathan Dowland]

> On 25 Oct 2013, at 21:04, Steve Langasek  wrote:
> 
> If someone is interested in maintaining Unity in Debian, I would be happy to
> help figure out how Debian could leverage the existing CI infrastructure
> that's in place for these packages in Ubuntu.

Aren't these folks working on it?
https://wiki.debian.org/Ayatana

Bug#727730: ITP: libjs-img.srcset -- fast JavaScript polyfill for img srcset

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libjs-img.srcset
  Version : 2.0.0
  Upstream Author : David Knight
* URL : https://github.com/weblinc/img-srcset
* License : Expat
  Programming Lang: Javascript
  Description : fast JavaScript polyfill for img srcset

  img.srcset is a lightweight, no nonsense, all browser supporting, fast
 polyfill for img srcset, allowing for lighter yet backwards-compatible
 responsive web design.
 .
 The srcset attribute is an HTML extension for adaptive (a.k.a.
 responsive) images.  More info at .
 .
 A polyfill is (in the context of HTML5) Javascript code implementation
 of a functionality often available in modern web browsers, allowing web
 designers to use simpler standards-compliant and declarative code,
 burdening only older/simpler browsers with these fallback snippets.

libjs-img.srcset is a dependency of libjs-slidy (ITP bug#673634).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131025202511.8656.39825.report...@auryn.jones.dk

Re: Proposal: let’s have a GR about the init system

[Colin Watson]

On Fri, Oct 25, 2013 at 08:31:38AM -0700, Russ Allbery wrote:
> Bastien beudart  writes:
> > It seems that the tech committee is composed of two well known ubuntu
> > developers.  Isn't that biased? I mean do you see them voting against
> > upstart, I know that the decision should be based around technical
> > facts, but that is not in their interest to vote against their project,
> > especially since canonical is isolating itself from the rest of the
> > community, so having Debian support is, I guess, really important, so…
> 
> Steve and Colin have both been Debian developers for a lot longer than
> they've been Ubuntu developers.  I would indeed be surprised to see Steve
> vote against upstart, but that would be on the basis of its technical
> merits as he sees them and as he's made clear in various discussions over
> the years.

I've done some work on Upstart itself and a good deal more designing
subsystems around it; no doubt that experience will have a bearing on my
vote.  The other Technical Committee members will also surely bring
relevant experience of one kind or another to the table, as we've all
worked on a wide range of systems with considerations that relate to the
varying designs of systemd and Upstart.  Anticipating the kind of
accusation that Bastien makes, I talked with Bdale at DebConf in his
capacity as TC chair and asked whether he felt I should recuse myself; I
don't remember exactly the words he used but I think it was something
along the lines of TC members not needing to recuse themselves just
because they happen to have relevant technical experience.

My employer certainly has an interest in Upstart, that much is clear,
and certainly I find it personally helpful when individual packages
carry Upstart support in Debian because it means we don't have to go to
the effort of maintaining deltas against them in Ubuntu.  But I think if
I have a pre-existing bias it is more towards not having a monoculture,
because in cases where we have multiple competing systems with broadly
similar capabilities (and e.g. the fact that we support glibc and not
uclibc isn't really a good comparison, since the latter is explicitly
targeting embedded rather than general-purpose systems), I think the
competition is healthy for all of them and for Debian, even if it
results in a bit more work.  For similar reasons I think the breadth of
architectures we support is a distinct strength of Debian, even if it
involves more work, and it brings the concrete benefit that when we need
to bring up a new one we have the flexibility designed into the system
to be able to do so without much fuss.  Of course we need a default,
which I'd like not to be sysvinit, and I hope we can look at *that* as
objectively as possible with a minimum of mud-slinging.

One thing I will say here and now: if I feel under pressure from my
employer to vote a particular way, then I will immediately recuse myself
from the vote and from further part in the discussion.  I'd hope that
would be generally understood as ethical behaviour.

Cheers,

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


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

Re: Proposal: switch default desktop to xfce

[Steve Langasek]

On Fri, Oct 25, 2013 at 03:19:30PM -0400, Joey Hess wrote:
> Neil Williams wrote:
> > Is there one in Debian?

> > Equally, is there genuine support for tablets within Debian beyond the
> > problems with GUIs and touchscreens? I'm not aware of anything
> > approaching usable GUI support, even discounting touch.

> I know that multiple desktop projects are interested in making the leap,
> so it makes sense to plan accordingly. I doubt xfce would be the first
> to get there. I also wonder why unity is not being packaged in Debian..

It's a rapidly-moving stack with a complex set of interdependencies, and
would be hard for one person to stay on top of.  I think it would need a
team to maintain it, and someone to get the ball rolling on such a team.

If someone is interested in maintaining Unity in Debian, I would be happy to
help figure out how Debian could leverage the existing CI infrastructure
that's in place for these packages in Ubuntu.

-- 
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

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Joey Hess  wrote:
> Hmm, I just gave KDE a try with my laptop fliped to tablet mode,
> and did not see anything that works better than xfce. I was still stuck
> fatfingered with a tiny panel, and once I started konqueror, could
> not drag to scroll the page, or make any other gestures.

Plasma Active is a different user interface on top of things, not yet
packaged for Debian.

The underlying libs are shared with the rest of the workspace, so it is
"just" getting the last bits integrated and tested. But the debian kde
team is lacking manpower to also take that up. It is just ~3-4 source
packages and maybe enabling e.g. the okular tablet port in the okular
package.

The Plasma Active upstream people are maintaining a Mer based reference
image for a couple of tablets.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnl6ljqd.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Joey Hess]

Sune Vuorela wrote:
> On 2013-10-25, Neil Williams  wrote:
> > Equally, is there genuine support for tablets within Debian beyond the
> > problems with GUIs and touchscreens? I'm not aware of anything
> > approaching usable GUI support, even discounting touch.
> 
> Plasma Active is quite mature and I'm sure the debian KDE team would
> love to assist people wanting to get Plasma Active in in a well
> supported way.

Hmm, I just gave KDE a try with my laptop fliped to tablet mode,
and did not see anything that works better than xfce. I was still stuck
fatfingered with a tiny panel, and once I started konqueror, could
not drag to scroll the page, or make any other gestures.

Is there a configuration setting somewhere to enable the tablet
features?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Andrew M.A. Cater]

On Fri, Oct 25, 2013 at 01:41:42AM +0100, Steve McIntyre wrote:
> 
> I guess not everybody understands the reasons for Debian choosing a
> default desktop, so I'll explain/expand them here.
> 
> 1. We have several types of installation media (netboot, netinst, DVD,
>BD) where we can happily install any desktop - they either contain
>*all* of the bits needed for any of the desktops, or *none*. The
>choice was made years ago to *not* ask users which desktop they
>prefer during the tasksel phase, to reduce the number of questions
>that new users would have to answer. Hence, we chose a
>default. Since that point, we've added options in the boot menus on
>these generic media (where possible, via isolinux or grub) to make
>it easier to make a desktop choice, but to the best of my knowledge
>most people just take the default option. We *could* revisit the
>tasksel design choice to not list all the desktops if people want -
>that's another discussion to have, maybe.
> 

I think it would be a good idea to have the netinst have an additional option 
to select 
desktop easily including the option for "command line only, no graphical 
desktop" as
default.

That would produce a minimalist install - ideal for servers - and the option at 
that
time to add KDE/Gnome or whatever other desktop environment if you want a 
graphical desktop.  
That way, too, any changes that require to be made to accomodate the 
requirements of any 
particular desktop environment can readily be accommodated in package listings 
that 
install the environment.

CD #1 for KDE, with a different #1 for LXDE/XFCE - not many people now have
CD drives only.

Can DVD #1 install multiple desktops in and of itself? For machines that can 
boot
from USB, I now routinely dd the image of DVD1 straight onto a 4GB stick and 
go from there.

Perhaps DVD#1 for KDE/XFCE/LXDE and a separate DVD#1 that bootstraps Gnome?

> 
>I don't think it would be a sensible option to have multiple sets
>of CDs, each tailored to a specific desktop. Hence, we end up
>picking a default here too.
> 
> >I understand that the both of these are good arguments, but maybe solutions
> >can be found for both. One idea would be the design of better download pages
> >[0] that provide minimal information about the desktop environments like a
> >picture of the desktop and a link to the upstream project. Not sure what to 
> >do
> >with the CD sets though.
> 
> Quite. :-/
> 

All the best,

Andy Cater



signature.asc
Description: Digital signature

Re: [ANNOUNCE] git-deb: a Git importer for Debian packages

[Joey Hess]

Gabriel de Perthuis wrote:
> I only know what dgit does from reading the source code.  dgit works
> server-side and is only available to DDs; as I understand it it creates
> a new, canonical repo, imports the current version and uses that as a
> base for new uploads.  It's useful as part of a maintainer's workflow.
> My tool is useful to get a git view of any package, without waiting for
> anyone to convert their repo.

Conceptually, they are quite similar. Both are viewing the Debian
archive as poor man's version control system, and providing a git
interface to it. dgit doesn't currently concern itself with downloading 
historic versions of the package, so it essentially does a shallow clone
from the archive, while git-deb does a deep clone.

It would be useful if you could arrange for git-deb to produce the
identical git commit shas for importing a given version of a package as
does dgit. dgit uses some simple techniques, like using the
debian/changelog date as the git commit date, to ensure that repeatedly
importing the same version of a package from the debian archive will
always yield the same sha.

Note that you can use dgit clone any package without being a Debian
developer. You only need an alioth account in order to dgit push.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: supporting more than one... (Re: let's split the systemd binary package

[Ondřej Surý]

On Fri, Oct 25, 2013, at 20:40, Holger Levsen wrote:
> Seriously, we are supporting more than one init system already and this
> is a good thing. (Or maybe it's not, but supporting just one would definitly
> be our worst choice at this time.)

As a maintainer of several packages (~10) that provide init scripts I
must say that I did thought it might be a good thing to support them
all. But after matching the though with reality and really adding
sysvinit AND upstart AND systemd init scripts I must admit that I hate
the triumvirate and I would really like to support just one init system.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382728451.31220.38589013.3d96a...@webmail.messagingengine.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Neil Williams  wrote:
> Equally, is there genuine support for tablets within Debian beyond the
> problems with GUIs and touchscreens? I'm not aware of anything
> approaching usable GUI support, even discounting touch.

Plasma Active is quite mature and I'm sure the debian KDE team would
love to assist people wanting to get Plasma Active in in a well
supported way.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnl6lhif.j8.nos...@sshway.ssh.pusling.com

Re: supporting more than one... (Re: let's split the systemd binary package

[Paul Tagliamonte]

On Fri, Oct 25, 2013 at 08:40:48PM +0200, Holger Levsen wrote:
> Hi,

Yo, Holger!

> On Freitag, 25. Oktober 2013, Paul Tagliamonte wrote:
> > Supporting two different init systems is something I don't think
> > *anyone* wants to get into. 
> 
> are you sure *so* many people are against *reality*? I always assume there 
> are 
> a few, but you make it sound like it is the majority ;-p

I mean, I may be wrong, but this is my mindset:

(where "A package" is some mid-size or major package)

Situation A:

 A package ships a sysvinit file
 A package ships a systemd unit file

Situation B:

 A package ships a sysvinit file
 A package does not ship a systemd unit file

Situation C:

 A package does not ship a sysvinit file
 A package ships a systemd unit file


I'd argue everyone agrees A is fine, and that B is fine.

However, I don't think many folks would think C is fine. I therefore
posit that we treat sysvinit different than systemd, if not by rule,
then by behavior.

I'd argue this is *not* the case with KDE or GNOME, since packages that
do one (and not the other) is quite common.


I have no point here, except to say that, currently, I do not believe we
fully support anything other then sysvinit as a project.

> Seriously, we are supporting more than one init system already and this is a 
> good thing. (Or maybe it's not, but supporting just one would definitly be 
> our 
> worst choice at this time.)

Perhaps so, something worth talking about :)

In the meantime, I'm more keen on getting *a* decision we can get
behind, and bring the discourse up a notch (to technical arguments in
ctte, rather then the flame threads that really distract everyone and
drive us all insane.

> cheers,
>   Holger


Much love,
  T

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

[Gunnar Wolf]

Thorsten Glaser dijo [Fri, Oct 25, 2013 at 02:27:44PM +]:
> > Let's tech committee it :)
> 
> I’d ask them to solve the situation of gnome/xfce depending on systemd,
> or something like that, but not a decision whether we want to support
> one or multiple init systems, and if not all currently existing ones
> (plus maybe OpenRC which had a GSoC after all), then which one. That’s
> something for the Developers to decide IMHO. And we should do this now.
> Still relatively early in the release process, so that any action can
> be done by jessie+1 at the latest, with jessie already carrying everything
> needed to enable it.

Yes and no.

Yes, all of us have an opinion — and valid, important reasons to hang
to that opinion.

No, because we have had already many flames on this topic, and I do
not see it has helped move the current situation.

A GR is out of the question, because GRs should only address
non-technical issues — and this topic is a technical one.

Now... A ruling by the tech committee will have to be followed by us
all. And if the tech-ctte were to rule we are all moving to OpenRC,
and I were a rabid OpenRC basher... Well, you  cannot force a
volunteer to do it, right? (yes, we can choose an init system by
policy and make my packages insta-RC-buggy, but that's also far from
ideal)

But... Back to the topic: Given the recurrence of the topic, the
difficulty to reach a decision and the breadth of its impact... Yes, I
would support requesting tech-ctte for a ruling.

Oh, and about the other subthread, about a bias inside the committee:
I fully trust our committee members to discuss and decide based on the
best outcome for Debian, regardless of who pays their RL job. All of
them have proven to be the most committed people to our project over a
very long timespan, and have earned their position through hard work
and commitment. Yes, Russ mentions there might be a conflict of
interest — Having the conflict explicitly stated were it to exist (it
has to be acknowledged by the affected people), the members that feel
so might decide not to get involved with the present discussion from
within their role.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131025192003.gb13...@gwolf.org

Re: Proposal: switch default desktop to xfce

[Joey Hess]

Neil Williams wrote:
> Is there one in Debian?
> 
> Equally, is there genuine support for tablets within Debian beyond the
> problems with GUIs and touchscreens? I'm not aware of anything
> approaching usable GUI support, even discounting touch.

I know that multiple desktop projects are interested in making the leap,
so it makes sense to plan accordingly. I doubt xfce would be the first
to get there. I also wonder why unity is not being packaged in Debian..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Mike Gabriel]

Hi,

On  Fr 25 Okt 2013 13:52:05 CEST, Olav Vitters wrote:


Note that also various MATE developers have git.gnome.org accounts (I
set that up for them). IIRC they took over one of the deprecated
components.


just for the record: The MATE Packaging Team is preparing the MATE  
desktop for Debian. We work closely together with MATE upstream and we  
expect to have the complete MATE desktop in Debian by the end of this  
year.


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


binzVFn7pg8YC.bin
Description: Öffentlicher PGP-Schlüssel


pgpqwfdzjuqmh.pgp
Description: Digitale PGP-Signatur

Re: let's split the systemd binary package

[Marc Haber]

On Fri, 25 Oct 2013 18:26:06 +0200, Matthias Klumpp 
wrote:
>No, but GNOME has a mission to create a great desktop-environment
>which is easy to use and "just works". And logind (in combination with
>systemd) offers features to accomplish that goal and provides some
>truly awesome features for session-management, multiseat etc. which
>GNOME decided to support.

"support" is something different than "offering as the only option". A
developer team aware of its responsibilities would have written the
code in a way that it falls back to some basic functionality if system
were not present.

They choose the way most easy for them, which is behavior often
encountered inside the systemd-favoring community. Too bad.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vzmvr-8m...@swivel.zugschlus.de

supporting more than one... (Re: let's split the systemd binary package

[Holger Levsen]

Hi,

On Freitag, 25. Oktober 2013, Paul Tagliamonte wrote:
> Supporting two different init systems is something I don't think
> *anyone* wants to get into. 

are you sure *so* many people are against *reality*? I always assume there are 
a few, but you make it sound like it is the majority ;-p

Seriously, we are supporting more than one init system already and this is a 
good thing. (Or maybe it's not, but supporting just one would definitly be our 
worst choice at this time.)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: Proposal: switch default desktop to xfce

[Joey Hess]

Sune Vuorela wrote:
> I've said that for years, but we still haven't changed to KDE Plasma
> Desktop as the default.

http://qa.debian.org/popcon-graph.php?packages=task-xfce-desktop+task-lxde-desktop+task-kde-desktop&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

This makes it difficult to argue that more of our users would be happy with
kde (or lxde) than with xfce.

I'm assuming that, despite kfreebsd *defaulting* to xfce rather than
gnome in wheezy (IIRC), there are not enough kfreebsd users to
significantly bias the numbers. Since there are still under 200 popcon
reporters for kfreebsd-*, that seems right.

Of course, the gnome default makes adding gnome to the plot not
currently useful. One nice side benefit of at least temporarily
switching the default desktop to xfce would be that if a lot of people
wanted gnome, rather than just picking it as the default, we'd see that
reflected in the popcon data.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: tech-ctte: Decide which init system to default to in Debian.

[Paul Tagliamonte]

And, since I've been informed that this was basically a contentless bug,
I'd like to frame the technical half of the question better:


Whereas:

 * the init system / pid 1 is a bit of software that multiple packages provide

 * the choice of init system also dictates which types of init scripts
   package maintainers write and maintain

 * the situation in which packages depend on a feature of systemd that's not
   dependent on pid 1 being systemd (such as dbus shutdown, or using logind)
   being run without systemd as pid1 is *not* something the systemd maintainers
   will support (fairly) is getting *more* common, and has been introduced into
   a major package (GNOME)

It is requested that the tech-ctte make a decision as to the init system
Debian shall use as the default, and make a judgement call on where the
efforts to resolve this situation shall go (patching *around* the lack
of systemd, or patching software to use systemd)

I believe this is within the ctte's jurisdiction, given 6.1 section 2.


Thanks for your consideration,
   Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

[Paul Tagliamonte]

On Fri, Oct 25, 2013 at 06:14:18PM +, Thorsten Glaser wrote:
> Isn’t that a reason to rather remove it, under the hostile upstream
> clause (cf. J�rg Schilling), or at the very least, not base anything
> important on it?

Hostile upstream != GPL / CDDL incompatabilities.


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Neil Williams]

On Fri, 25 Oct 2013 14:15:02 -0400
Joey Hess  wrote:

> I do wish that some of the .. energy .. seen in these threads could be
> used for something more interesting. For example, find a way to detect
> touch screen systems, on which xfce is *not* pleasant, and don't
> install a desktop task there, but a separate task with whichever UI
> is currently best suited for tablets.

Is there one in Debian?

Equally, is there genuine support for tablets within Debian beyond the
problems with GUIs and touchscreens? I'm not aware of anything
approaching usable GUI support, even discounting touch.

This is just one of the reasons for #726769 - O: tslib

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Proposal: switch default desktop to xfce

[Joey Hess]

> I humbly disagree. I'm mainly interested in the perspectives of systemd on
> servers.

Systemd on servers is offtopic for this thread.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

[Thorsten Glaser]

Thomas Goirand dixit:

>> and at turning
>> the required changes to packaged software into general and defensible
>> upstream improvements.  I've always been very impressed by this effort,

>Well, because of the upstream for Systemd, it can't, someone would have
>to fork the project (or maintain a separate branch, which would be as
>painful). Lennart has been (IMO sadly) very clear about this.

Isn’t that a reason to rather remove it, under the hostile upstream
clause (cf. J�rg Schilling), or at the very least, not base anything
important on it?

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc


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

Re: Proposal: switch default desktop to xfce

[Joey Hess]

Steve McIntyre wrote:
> This goes back to during the wheezy release cycle. There was a little
> discussion around a change in tasksel [1], but rather too late in the
> day for the change to make sense. Now we have rather more time, I
> feel. Let's change the default desktop for installation to xfce.

So, I wish that wheezy had shipped with xfce as the default. It was the
better choice of the options we had (although possbly kde would have
been a good choice too).

Personally, having been through the gnome 2.0 transition, and seeing
that the gnome devs can throw out old stuff, arguably regress
functionality for a while, but end up with new better stuff, I had to
discount the initial discontent about gnome shell. (Also, most of the
threads about it rapidly reached a point of diminishing returns to keep
reading.)

Also, I was not in a position to try gnome 3.4 myself at all, hardware,
and bandwidth wise, until rather too late in the release cycle. I didn't
see conclusive proof that gnome 3.4 was really the wrong default for
wheezy until I started putting it on end-user machines and seeing them
struggle with it, and then be perfectly happy when switched to xfce.
(A few such real world tests are much more useful than a metric mutt-load
of threads.)

Anyway, at the moment I don't know which is the right choice for jessie.
There is a full year for gnome to be improved, and it could easily be
a better experience for users at that point. I would not be opposed to
changing the default for xfce for now, and reverting it if gnome's
improvements make it a better choice.

I do wish that some of the .. energy .. seen in these threads could be
used for something more interesting. For example, find a way to detect
touch screen systems, on which xfce is *not* pleasant, and don't install
a desktop task there, but a separate task with whichever UI is currently
best suited for tablets.

>  * Tweak CD and installer builds:
>+ change what happens with no desktop selected to use xfce instead
>  of Gnome (netinst, DVD, BD etc.)

The tasksel change handles that.

>+ Add an explicitly-named Gnome CD#1
>+ Remove the explicitly-named XFCE CD#1

You might consider making the default CD be a symlink to the explicitly
named desktop CD.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

[Thomas Goirand]

On 10/26/2013 12:02 AM, Russ Allbery wrote:
> Thomas Goirand  writes:
> 
>> Plus if we choose Upstart or Systemd, then that's effectively what we
>> are going to do (I mean, we'd have to support 2 init systems, because of
>> Hurd & kFreeBSD).
> 
> Not necessarily. We could also decide that whichever init system we pick
> will need to be ported to Hurd and kFreeBSD (in some fashion, possibly
> with functionality restrictions)
>
> I think it's worth noting that, historically, the Hurd port has never
> required us to hold back the Linux architectures.  Rather, the Hurd
> porters have worked hard on adding functionality to Hurd to support the
> software in the archive by implementing Linux interfaces

I've been very impressed by the hurd effort as well.

> and at turning
> the required changes to packaged software into general and defensible
> upstream improvements.  I've always been very impressed by this effort,
> and I don't think we should assume systemd or upstart could not be handled
> the same way that many other things have been handled in the past.

Well, because of the upstream for Systemd, it can't, someone would have
to fork the project (or maintain a separate branch, which would be as
painful). Lennart has been (IMO sadly) very clear about this.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526ab38a.60...@debian.org

Re: Proposal: switch default desktop to xfce

[Martin Steigerwald]

Am Freitag, 25. Oktober 2013, 17:32:30 schrieb Sune Vuorela:
> On 2013-10-25, Neil Williams  wrote:
> > Other desktop environments have similar features without requiring a
> > change of init system. It was a choice by GNOME upstream and a choice
> 
> Other desktop environments either are reimplementing bits of systemd or
> is having some more or less weird bugs related to some of the issues
> the systemd suite is solving.
[…]
> Why not consolidate on shared code rather than having several bits
> providing the similar functionality for fairly simple tasks ?

I do agree to this technically.

But for me it depends on the how.

I do see quite an amount of ignorance and pushing regarding adoption of 
systemd and GNOME. I fully accept that it may be difficult to agree on a way 
forward… but currently I get the impression that any neither GNOME nor systemd 
upstream actually cares about agreement with all involved parties. systemd 
developers are not even willing to accept patches to make systemd portable.

Its this ignorance I feel uneasy about.

And then currently on Debian with systemd as PID 1 hibernation in KDE is 
broken as I pointed out in my other mail. No matter where the real culprit 
lies, as long I am asked for a password prior to hibernating when systemd is 
PID 1 while everything works just fine with init as PID 1, systemd won´t be PID 
1 on my system. I am sure that Fedora and OpenSUSE have both solved this bevor 
releasing systemd as default init to the public tough. Otherwise they would 
have needed to shutdown their bugzillas from their users I think.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2826421.TFKmrUPPL9@merkaba

Re: Proposal: switch default desktop to xfce

[Tom Perdido]

As a matter of personal preference I would like to see something other than
gnome as default. I've had much better luck converting users from windows,
specifically older and middle aged users, with xfce or lxde.

But this conversation really goes back to the init conversation. On which I
suggest we go for freedom of choice and upholding principles of the Unix
philosophy.
On Oct 25, 2013 12:33 PM, "Guillem Jover"  wrote:

> On Fri, 2013-10-25 at 11:07:09 +, Thorsten Glaser wrote:
> > • On a VM, I might want to run very low-consuming software only, to lower
> >   the cost of separating things into VMs of their own. (I’ll be writing a
> >   syslog dæmon some day because sysklogd (three processes, c’mon!) is now
> >   removed from the archive and both rsyslog and syslog-ng are way
> >   too heavy-weight for this, for example.)
>
> Before reimplementing something from scratch you might want to
> consider inetutils-syslogd (which I'm pretty happy with :), or
> perhaps dsyslog (although I've never tried it).
>
> Thanks,
> Guillem
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20131025173321.gb15...@gaara.hadrons.org
>
>

Re: Propose Release Goals (delayed ;) - xz compression

[Bastian Blank]

On Fri, Oct 25, 2013 at 05:36:08PM +0200, Marko Randjelovic wrote:
> Not quite, xz is also slower than gzip in decompression, cca 3 times,
> which is not neglectable on slow machines, especially when installing
> large sets of packages.

This is incorrect.  xz -[012] is way better in terms of decompression
time and compression ratio then gzip -9 (the old default).

Bastian

-- 
We fight only when there is no other choice.  We prefer the ways of
peaceful contact.
-- Kirk, "Spectre of the Gun", stardate 4385.3


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131025172615.ga6...@mail.waldi.eu.org

Re: tech-ctte: Decide which init system to default to in Debian.

[Paul Tagliamonte]

On Fri, Oct 25, 2013 at 07:27:21PM +0200, Guillem Jover wrote:
> *Siiigh*, this is a decision that has project-wide implications
> by setting the project's direction, and even if the consititution grants
> the tech-ctte this power it's precisely here where a GR would be the most
> fair option, because lots of people might need to end up having to do or
> stop doing work due to this. Also even if a majority of the project would
> disagree with any such decision, subsequently overruling the tech-ctte by
> way of a GR requires more than a simple majority. You know, GRs do not
> eat babies or something.
> 
> If I had wanted to be told top-down, by a small committee how to spend
> my *volunteer* time in a project I'd have joined a corporate-backed one
> instead…
> 
> Very much not amused…

Good, because I wasn't joking.

> I'm happy to sponsor a GR to decide this, though.

That's your right as a Developer.

I do, however, think that this is grounds for the tech-cttie to discuss
and rule on, given the technical background for the decision, and if
that turns into a GR, we'll at least have well-formed and discussed
points, rather then the nonsense we have in these threads.


Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Guillem Jover]

On Fri, 2013-10-25 at 11:07:09 +, Thorsten Glaser wrote:
> • On a VM, I might want to run very low-consuming software only, to lower
>   the cost of separating things into VMs of their own. (I’ll be writing a
>   syslog dæmon some day because sysklogd (three processes, c’mon!) is now
>   removed from the archive and both rsyslog and syslog-ng are way
>   too heavy-weight for this, for example.)

Before reimplementing something from scratch you might want to
consider inetutils-syslogd (which I'm pretty happy with :), or
perhaps dsyslog (although I've never tried it).

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131025173321.gb15...@gaara.hadrons.org

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Neil Williams  wrote:
> Other desktop environments have similar features without requiring a
> change of init system. It was a choice by GNOME upstream and a choice

Other desktop environments either are reimplementing bits of systemd or
is having some more or less weird bugs related to some of the issues
the systemd suite is solving.

We still have anything in debian that ensures XDG_RUNTIME_DIR is set,
except the systemd+logind combination. This results in user session
daemons either trampling on each other or predictable shared filenames
or various other hackish things.

We have in KDE ktimezoned that is one of those 'gazillion daemons' that
all apps spawn and we frequently get bug reports about.
systemd+timezoned is also solving the same issue.

systemd+hostnamed is also solving issues. and it can probably save quite
some lines of code in kded.

very much of what e.g. kded does is plugging holes in the linux platform
on a quite high level.

Why not consolidate on shared code rather than having several bits
providing the similar functionality for fairly simple tasks ?

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnl6lapn.j8.nos...@sshway.ssh.pusling.com