Re: Proposal: switch default desktop to xfce

[Nikolaus Rath]

Neil Williams  writes:
>> 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?
>
> Yes.

Aeh, are you sure? I think you missed my point. I'm not involved with
any init system, nor a Debian developer, yet by developing some random
app and having it depend on a specific init system, I could (according
to you) make that init system unsuitable for Debian?

That doesn't make any sense at all.

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/87r4b7xtif@vostro.rath.org

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

[Russ Allbery]

Paul Wise  writes:

> I wasn't talking about link-order stuff but about dependency inflation;
> binaries linking against libraries that aren't used by the binaries
> linking against them. IIRC this is the purpose of --as-needed and what
> it works around.

> To clarify further, I think --as-needed should be the default in GCC
> upstream, not just in Ubuntu or elsewhere. Debian should not make it
> the default before upstream do. Until it becomes the default in GCC
> upstream, Debian should send patches to remove dependency inflation
> from upstream build systems.

Good luck with that.  I haven't been able to get rid of some dependency
inflation even in packages for which I'm upstream.  In some cases (such as
a shared library package that also contains binaries linked against that
shared library but which don't need to be linked with the dependencies of
the shared library), the only way to do so is to stop using Libtool
completely, which I'm not willing to do.

Even when it is possible, it often requires a complete rewrite of the
upstream Autoconf machinery that makes it considerably more complex, and
upstream is going to rightfully ask "why?".  And I don't think we have a
good answer.

> If the linker generates errors then we will be forced to send patches
> but if the linker just warns then we would have to rely on the buildd
> log scanner reporting these issues to maintainers via the PTS. Hopefully
> our upstreams will eventually start using the new GCC and begin fixing
> these issues on their own.

They will for link order, since that's important.  They won't for
dependency inflation, because it's a lot of work for no obvious gain,
particularly when --as-needed exists.

I used to feel the way that you did and tried to patch the software that I
packaged, and finally realized I was just being masochistic.  I switched
over to --as-needed for packages like gnubg and the intense relief I felt
was the wall that I stopped beating my head against.

-- 
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/87iowjwj85@windlord.stanford.edu

Re: Pro-Action against dependency hell

[Paul Wise]

On Sat, Oct 26, 2013 at 11:54 PM, Kevin Chadwick wrote:

> epdfview depends on libqt

epdfview has been removed from Debian but it never depended on Qt, always GTK+:

http://bugs.debian.org/710550
http://packages.debian.org/source/stable/epdfview

> evince pulls in the whole of QT adding ages to the build time.

None of the build logs here mention anything to do with Qt, since
evince only uses GTK+/GNOME related technologies.

https://buildd.debian.org/status/package.php?p=evince

> It would be rediculous if chattr +ias /sbin/init needed to be set
> before installing systemd.

It isn't needed because the systemd package does not include that pathname:

http://packages.debian.org/sid/amd64/systemd/filelist

-- 
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/CAKTje6G0HooOjKxb5AWSv71FQZ63nQ3_=p7w4zbepaw6mx5...@mail.gmail.com

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

[Paul Wise]

On Sat, Oct 26, 2013 at 1:57 PM, Colin Watson wrote:

> Linking in the correct order is not a workaround; it's being correct.

I wasn't talking about link-order stuff but about dependency
inflation; binaries linking against libraries that aren't used by the
binaries linking against them. IIRC this is the purpose of --as-needed
and what it works around.

To clarify further, I think --as-needed should be the default in GCC
upstream, not just in Ubuntu or elsewhere. Debian should not make it
the default before upstream do. Until it becomes the default in GCC
upstream, Debian should send patches to remove dependency inflation
from upstream build systems. If the linker generates errors then we
will be forced to send patches but if the linker just warns then we
would have to rely on the buildd log scanner reporting these issues to
maintainers via the PTS. Hopefully our upstreams will eventually start
using the new GCC and begin fixing these issues on their own.

-- 
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/CAKTje6G-r-prrxL=L1DY6-Q+OCjj=cwjkys2y26rxh2r09k...@mail.gmail.com

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

[Charles Plessy]

> On Saturday, October 26, 2013 10:45:55 Charles Plessy wrote:
> > 
> > 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.

Le Fri, Oct 25, 2013 at 10:31:32PM -0400, Scott Kitterman a écrit :
> 
> 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.

Le Sat, Oct 26, 2013 at 07:55:00AM +0100, Neil Williams a écrit :
> 
> If there are people inside Debian (i.e. people who would have a vote
> in a Debian GR or who are actively involved in packaging) who have no
> confidence in the Debian Technical Committee to come to a fair decision
> for the benefit of all of Debian then I would be concerned. That random
> people not involved in Debian have prejudged individual members is of
> no concern.

Hi all,

the reason why the reaction to a conflict of interest should be automatic is
that it protects the people: their honesty is not put in question.  They do not
have to justify it or to convince others, they just automatically refrain from
voting, regardless how themselves or others are confident that they would vote
without bias.  It also protects the comittee itself, by completely nullifying
the question from the very start.

I strongly recommend that the three current and former employees of Canonical
refrain from voting: not only because of the current circumstances, but also to
make the case for the time a different conflict of interest will happen.  We
should not consider that we can have a relaxed attitude now and that we will do
the right time at that time, this is wishful thinging.  If we do not keep high
standards now, it will be hard to have high standards then, because the same
arguments will come again, that the mere idea that somebody can be biased is
insulting to that person, etc...

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/20131026234959.ga14...@falafel.plessy.net

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

[Zbigniew Jędrzejewski-Szmek]

On Sat, Oct 26, 2013 at 11:02:13PM +0100, Simon McVittie wrote:
> # systemd units on my laptop that are generated internally by systemd
> # when it reads a sysvinit script (or "LSB init script" as it
> # calls them)
> % systemctl list-units | grep LSB | wc -l
That's only currently loaded units, i.e. probably the ones which are/were
running, without --all.

> # systemd units on my laptop that are really systemd units,
> # only counting ".service" files (its closest equivalent of init
> # scripts) and not counting systemd's equivalents of the initscripts
> # package, or daemons from src:systemd
> % systemctl list-units | grep -v 'LSB\|systemd-' | grep '\.service' | wc -l
> 28

Also it's better to say systemctl list-units -t service --no-legend --all
then grep by type.

Yours nitpicky,
Zbyszek


-- 
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/20131026233712.gm28...@in.waw.pl

Re: Proposal: switch default desktop to xfce

[Marco d'Itri]

On Oct 26, Luca Capello  wrote:

> A small note: does anyone consider that there are still people on
> not-so-fast Internet connections?
Yes: unless they need to install multiple computers (unusual, I think) 
and do not know how to share the downloaded packages among them, then 
netinstall is the most efficient choice in this scenario.
I used to do this with 56k modems...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bits from the Release Team (Jessie freeze info)

[peter green]

Johannes Schauer wrote:

Until these two issues are fixed we will not be able to get an algorithmic
answer to the question of what constitutes the minimum required set of
packages.
  
There is also the complication of what I will call "non-key self 
building compilers". fpc is an example


These are not needed to bootstrap the core of debian but if one wants to 
bootstrap all of debian they will need to be built. Since the only way 
to build them is with themselves they cannot be bootstrapped natively 
even with the help of build profiles. So the only way to bootstrap them 
is to either cross-build them or start with a binary from upstream.




--
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/526c4c1c.3060...@p10link.net

Bug#727798: ITP: node-range-parser -- HTTP Range header parser - Node.js module

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-range-parser
  Version : 0.0.4
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/node-range-parser
* License : Expat
  Programming Lang: JavaScript
  Description : HTTP Range header parser - Node.js module

This module parses the HTTP Range header, relative to a given length,
the length being a file size in most applications.
.
Node.js is an event-based server-side javascript engine.


-- 
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/20131026230345.9116.68890.reportbug@imac.chaumes

Re: let's split the systemd binary package

[Simon McVittie]

On 26/10/13 21:23, Florian Weimer wrote:
>> "Session tracking" includes suspending/hibernating, because logind has
>> a mechanism to let apps delay suspend, which is necessary for things
>> like closing the inherent race condition in "lock the screensaver when
>> we suspend... oh, oops, it didn't get scheduled until after we
>> resumed, so the old screen contents are still visible for a moment
>> when you open your laptop".
> 
> Has this finally been fixed?  Locking and suspend is not synchronized
> in GNOME 3.8.

My understanding is that this was finally fixed in the GNOME 3.8 cycle:
if you have GNOME Shell 3.8 and logind, and something suspends *via
logind* (including hotkeys, lid-close events and Shell itself), suspend
will be delayed until either the Shell has locked the screen, or some
reasonably long timeout has elapsed. I could be wrong there, though.

If a privileged process suspends not-via-logind (direct use of kernel
interfaces, and perhaps also pm-suspend), then logind doesn't have the
opportunity to enforce that locking. Also, I'm not sure whether
gnome-screensaver, as used in fallback/flashback/whatever it's called
this week, participates in that locking mechanism.

S


-- 
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/526c3fd8.3070...@debian.org

Bug#727797: ITP: node-fresh -- Check freshness of HTTP request and response headers - Node.js module

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-fresh
  Version : 0.2.0
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/node-fresh
* License : Expat
  Programming Lang: JavaScript
  Description : Check freshness of HTTP request and response headers - 
Node.js module

This module checks HTTP If-Modified-Since, If-None-Match, Cache-Control
request headers, as well as Last-Modified, Etag response headers to
determine if the client requesting the resource has a stale or fresh cache.
.
Node.js is an event-based server-side javascript engine.


-- 
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/20131026220336.27946.49137.reportbug@imac.chaumes

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

[Simon McVittie]

On 25/10/13 16:28, Russ Allbery wrote:
> Fully supporting an init system means, among other things, writing or
> generating native configuration files for that init system so that we can
> take full (or at least fuller) advantage of its capabilities.  We're
> currently not doing that for anything other than sysvinit.

For what it's worth, quite a few packages already ship native systemd
and/or Upstart jobs alongside their sysvinit scripts, which are used in
preference to the sysvinit scripts:

# systemd units on my laptop that are generated internally by systemd
# when it reads a sysvinit script (or "LSB init script" as it
# calls them)
% systemctl list-units | grep LSB | wc -l
36
# systemd units on my laptop that are really systemd units,
# only counting ".service" files (its closest equivalent of init
# scripts) and not counting systemd's equivalents of the initscripts
# package, or daemons from src:systemd
% systemctl list-units | grep -v 'LSB\|systemd-' | grep '\.service' | wc -l
28
# Upstart jobs on my laptop
% ls /etc/init/ | wc -l
17

I keep meaning to write native systemd units for my pkg-games packages,
but they're still in the "LSB" category at the moment.

S


-- 
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/526c3be5.9020...@debian.org

Re: Bits from the Release Team (Jessie freeze info)

[Cyril Brulebois]

Johannes Schauer  (2013-10-26):
> (I was not able to find the debian-ports list on lists.debian.org (so I
> subscribed via email) did I just miss it?)

Dead list: http://lists.debian.org/debian-ports/

AFAICT it's now an alias for all debian-$port lists.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the Release Team (Jessie freeze info)

[Johannes Schauer]

Hi,

(I was not able to find the debian-ports list on lists.debian.org (so I
subscribed via email) did I just miss it?)

Quoting Steven Chamberlain (2013-10-23 22:04:59)
> I had a play with the 'botch' tool (see description[1]) for determining build
> order when bootstrapping an architecture.

botch author here. Just stumbled upon this already a few day old email in my
inbox :)

> To start off with it determines a minimum required set of packages - you'd
> normally cross-compile those from another system.  This set (see attached
> example list for kfreebsd-amd64 wheezy) looks to me like what constitutes the
> 'toolchain'.

This minimum set of packages which has to be cross compiled (because no binary
package of the target architecture exists at this point) is what we call the
minimal native build system (the name is misleading as disjunct dependencies
make different choices of this set possible).

Currently it is not possible to present a correct selection of source packages
which have to be cross compiled to produce the minimal build system. What we
currently do is to just do:

grep-dctrl -X \( -FPackage build-essential --or -FPackage debhelper --or 
-FEssential yes)

and assume that the resulting list of packages (the one you attached to your
last email) is cross compilable from nothing. This is of course not the case in
practice but a formal analysis is not possible yet. This is because multiarch
annotations are missing in some packages and because of the problem of how to
handle source packages directly depending on gcc, g++, binutils etc in the
cross compilation case. While the first one is easy to fix there doesnt exist a
solution for the second one yet. Build profiles would be able to solve the
second problem.

Until these two issues are fixed we will not be able to get an algorithmic
answer to the question of what constitutes the minimum required set of
packages.

On the other hand wookey did lots of ubuntu crossing and identified that with
just (I think it was) a dozen modified packages (reducing their build
dependencies to break cross build dependency cycles) he was able to cross build
all of these packages:

http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html

So while an automated analysis is not possible right now, it also does not seem
to be necessary to have this automated. Having the to-be-crossed selection of
packages retrieved automatically becomes more interesting as more source
packages are known to be cross-compilable including all their required
recursive build dependencies.

> The list will be different for each port, and change over time.  This example
> included freebsd-libs, freebsd-utils and kfreebsd-kernel-headers but of
> course others won't.

Thanks for trying out botch for kfreebsd :)

> AIUI those packages should be able to rebuild each of themselves without any
> other dependencies.

Should but unfortunately they are not :(

In fact, to nativel rebuild the minimal build system for amd64 (just
essential:yes + build-essential + debhelper) one needs to be able to compile
383 source packages (excluding the source packages in the minimal build system
itself).

This is as of debconf13 when I last ran those scripts. You can look at the
numbers here as well:

http://mister-muffin.de/bootstrap/stats/

These 383 source packages include ugly ones like iceweasel, nautilus, webkit,
network-manager, mysql, kde4libs which as you can imagine draw in half of what
makes a modern desktop system and thus might naively have been dismissed as
non-essential for the bootstrapping purpose at all. But of course this list
will be different between arches.

> I think doing that regularly would be a good health check for a port's
> toolchain.  Probably these packages would be the focus of the
> reproducible-builds project, at least from a security point-of-view.  Any
> differences in output of subsequent builds are of interest, and would
> potentially reveal when significant changes or bugs were introduced too.

Being able to use botch to automatically bootstrap all arches from scratch has
always been one of botch's goals. Unfortunately the build profile discussion is
holding up the implementation of this in practice but guillem promised to look
into this for dpkg 1.17.2.

cheers, josch


--
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/20131026213931.16796.6@hoothoot

Bug#727795: ITP: node-raw-body -- Request body length validation supporting streams - module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-raw-body
  Version : 0.0.3
  Upstream Author : Jonathan Ong 
* URL : https://github.com/stream-utils/raw-body
* License : Expat
  Programming Lang: JavaScript
  Description : Request body length validation supporting streams - module 
for Node.js

This module gets the entire buffer of a stream and validates its length
against an expected length. A limit can also be set, preventing memory
exhaustion. It is useful for parsing request bodies.
.
Node.js is an event-based server-side javascript engine.


-- 
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/20131026204154.19830.69472.reportbug@imac.chaumes

Re: let's split the systemd binary package

[Florian Weimer]

* Simon McVittie:

> "Session tracking" includes suspending/hibernating, because logind has
> a mechanism to let apps delay suspend, which is necessary for things
> like closing the inherent race condition in "lock the screensaver when
> we suspend... oh, oops, it didn't get scheduled until after we
> resumed, so the old screen contents are still visible for a moment
> when you open your laptop".

Has this finally been fixed?  Locking and suspend is not synchronized
in GNOME 3.8.


-- 
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/87y55faii2@mid.deneb.enyo.de

Re: Proposal: switch default desktop to xfce

[Luca Capello]

Hi there!

On Sat, 26 Oct 2013 08:08:53 -0700, Andrew M.A. Cater wrote:
> On Fri, Oct 25, 2013 at 11:44:48PM +0100, Steve McIntyre wrote:
>> 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!
>
> Now that USB sticks at 16/32GB are (relatively) cheap - it is actually a much 
> better
> bet to install the Blu-Ray .iso image in the same way :)

A small note: does anyone consider that there are still people on
not-so-fast Internet connections?

I am still on a consumer 5000/500kbps ADSL at home and on a professional
4000/512kbps at one of the company I work for.  And it seems that where
I am now (visiting a friend) is even worse:
=
$ wget 
http://cdimage.debian.org/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso
--2013-10-26 13:23:12--  
http://cdimage.debian.org/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso
Resolving cdimage.debian.org (cdimage.debian.org)... 130.239.18.163, 
130.239.18.173, 2001:6b0:e:2018::173, ...
Connecting to cdimage.debian.org (cdimage.debian.org)|130.239.18.163|:80... 
connected.
HTTP request sent, awaiting response... 302 Found
Location: 
http://gemmei.acc.umu.se/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso
 [following]
--2013-10-26 13:23:13--  
http://gemmei.acc.umu.se/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso
Resolving gemmei.acc.umu.se (gemmei.acc.umu.se)... 130.239.18.137, 
2001:6b0:e:2018::137
Connecting to gemmei.acc.umu.se (gemmei.acc.umu.se)|130.239.18.137|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 3934945280 (3.7G) [application/x-iso9660-image]
Saving to: ‘debian-7.2.0-amd64-DVD-1.iso’

 0% [ ] 410,076 
 107KB/s  eta 8h 55m ^C
=

I am full in favor of dropping CDs, but not with the reasoning that no
one use them anymore.

Despite I usually prefer the netinst multi-arch *CD*, I always have the
default CD1 in my laptop bag, it could be useful to install Debian with
no Internet connection at all (maybe I am a bit too old in this regard).

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

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

[Marco d'Itri]

On Oct 26, Thomas Goirand  wrote:

> If neither Upstart or Systemd works for these non-Linux ports, then
> there's OpenRC. Which is why I worked on it (and I did this, mainly
> because of "ethical and philosophical reasons" as you put it). It
> wouldn't hurt to have more help on it...
Having all packages implement the configuration for a second init 
system just to support a few hundreds of users is not really a 
reasonable solution.
Not just for the time wasted, but also because nobody would test this.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Marco d'Itri]

On Oct 26, Svante Signell  wrote:

> This really pinpoints the whole problem: What happened to the Unix
> philosophy, with freedom of choice?
We killed it for good in 2008:
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Svante Signell]

On Sat, 2013-10-26 at 00:00 +0100, Kevin Chadwick wrote:
> > 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.

This really pinpoints the whole problem: What happened to the Unix
philosophy, with freedom of choice? If you want a locked-in OS, with no
choices, choose Mac* or Windows*. This question is really getting out of
hand: We are talking Unix system freedom here, with all that follows
with it :) Please, freedom of choice, and (preferably free) software!


-- 
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/1382816708.4094.9.camel@PackardBell-PC

Re: Bits from the Release Team (Jessie freeze info)

[Holger Levsen]

Hi,

On Mittwoch, 23. Oktober 2013, Stewart Smith wrote:
> Jenkins can have slaves on remote hosts, via SSH. It runs a small java
> app there, so as long as the arch has a JVM then you're pretty right.

that JVM is not even needed, just schedule jobs via ssh and be done.


cheers,
Holger



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

Re: Jessie release goal: DNSSEC as default recursive resolver

[Marco d'Itri]

On Oct 26, Thomas Goirand  wrote:

> I'd find it very nice if we had, by default, DNSSEC resolving in Debian,
> at least in the "default" configuration (whatever that means). By this,
I agree with the general principle, but I do not think that a recursive 
resolver should be installed by default on every system. This would 
violate a lot of reasonable expectations...

> Probably this is too narrow for a release goal, or it is too late to
> raise this topic, though I would find it very nice if we had the
> feature, which is why I'm raising this topic. Thoughts welcome.
It would help if you can describe exactly what is missing to achieve 
this goal.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Thomas Goirand]

On 10/26/2013 10:37 PM, Christoph Anton Mitterer wrote:
> - Against systemd speaks that it's uncertain on whether there will be a
> solution in the end for the non-Linux UNIX flavours - which I think
> Debian should support for ethical and philosophical reasons.
> Admittedly I have no idea how the situation is there wrt upstart.

If neither Upstart or Systemd works for these non-Linux ports, then
there's OpenRC. Which is why I worked on it (and I did this, mainly
because of "ethical and philosophical reasons" as you put it). It
wouldn't hurt to have more help on it...

Cheers,

Thomas Goirand (zigo)


-- 
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/526c1027.3070...@debian.org

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

[Steve Langasek]

On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote:
> Steve Langasek  writes:

> > I don't think either of these are the right question.  Even if we change
> > the default init system for jessie, because we *must* support backwards
> > compatibility with sysvinit for upgrades, there is no justification for
> > requiring packages to do anything else for jessie and no policy change
> > is needed.

> That isn't obvious to me.  We have, in the past, allowed upgrades to
> require a preliminary upgrade of one or more packages.  The udev
> transition comes to mind.

udev transitions have always happened under duress.  We should do better
than this where we reasonably can.  (In the udev case, we had no choice but
to require a risky lockstep upgrade of the kernel and udev, because
maintaining udev compatibility with older kernels would have required an
excessive amount of new work.)

>  We *could* do the same thing here and require an init upgrade as a
> pre-upgrade step when going from wheezy to jessie, alongside a dependency
> on systemd or upstart (added by debhelper, for example) for all packages
> providing startup configuration but not an init script.  I'm not saying
> that's necessarily a good option, but it is an option that we should
> discuss.

Ok, point taken.  We *could* decide that something other than sysvinit was
now the new least common denominator for jessie, and using dependencies
ensure a smooth upgrade (i.e., this still wouldn't be the udev problem).  I
think that would be a surprisingly bold change for Debian to make in the
space of a single release cycle, when up to now we collectively have very
little experience running either systemd or upstart in production on Debian,
and we don't as yet have a resolution for compatibility with non-Linux
ports.

> Also, we will eventually have to decide whether to drop the requirement
> that packages provide sysvinit-compatible init scripts.  Even if we agree
> on a requirement to do so for jessie, we could drop that requirement for
> jessie+1 (and indeed will want to if we choose any init system other than
> sysvinit or "all of the above," given that most of the benefits of either
> upstart or systemd from a packaging perspective will only be seen when we
> take that step).

> We could always defer that decision until jessie+1, but that's the
> decision with the most impact on kFreeBSD and Hurd, and if I were them,
> I'd want to know whether that's the eventual project direction or not as
> soon as possible so that I have as much time as possible to decide on my
> next steps.

Right.  Whichever init system we pick, I do expect the next step to be to
drop the requirement to maintain sysvinit backwards-compatibility; my point
was that I don't expect this to be something we change in policy for this
cycle as part of the TC decision.

-- 
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: Jessie release goal: DNSSEC as default recursive resolver

[Ondřej Surý]

Hi Russ,

On Sat, Oct 26, 2013, at 18:20, Russ Allbery wrote:
> Thomas Goirand  writes:
> 
> > If this means installing a recursive DNS resolver by default (unbound
> > pops to my mind, since it has the feature by default), I'd say be it,
> > though probably that is more of an open question, and an implementation
> > details. I personally wouldn't mind at all if the Debian default
> > configuration would by-pass whatever ISP are providing, since we've seen
> > this broken in multiple cases (so many that I don't think it's even
> > necessary to use an example to illustrate that fact here...).
> 
> One has to be careful about this, since quite a few installations are on
> unroutable IP addresses that can't do direct DNS queries to the DNS
> roots.
> Even if a system is installed via the network installer, that may be with
> the goal of eventually moving it into a private network.  If your primary
> DNS resolver doesn't reply due to inability to reach the root DNS
> servers,
> it tends to cause all sorts of weird slowness and issues that are hard
> for
> the average user to understand or track down, even if you have other DNS
> servers listed as secondary resolvers.
> 
> The safe default is still to rely on the organizational DNS resolvers as
> provided by DHCP or local manual configuration.

we can adopt dnssec-trigger
(https://www.nlnetlabs.nl/projects/dnssec-trigger/) for such scenarios.

> I'm definitely in favor of improved DNSSEC support, but I think it's
> going to need to be something that people can optionally install if we're
> trying to provide it by bypassing local DNS infrastructure.

I still think that the Debian should be a technology leader.
Conservative, but technology leader. And DNSSEC adoption would help the
case.

Also the DSA has already enabled DANE (DNSSEC validated TLS certs) on
Debian's MTAs, the postfix 2.11 will have DANE support.

I think this goal is very reasonable and I thank Thomas for proposing
it.

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/1382809952.16288.38938833.72fff...@webmail.messagingengine.com

Re: Jessie release goal: DNSSEC as default recursive resolver

[Ondřej Surý]

On Sat, Oct 26, 2013, at 18:58, Kevin Chadwick wrote:
> I believe the reliability (DOS) issues that DNSSEC imposes coupled with

Please, not this again. If you say DNSSEC DOS issue, you must state all
the other issues that DNS has.

> the low level of adoption

It's certainly more adopted than IPv6 and we do support IPv6.

> would make it very unlikely that DNSSEC would
> be enabled for certainly default resolving on OpenBSD without DNSCURVE
> protection or some significant DNSSEC re-development.

How is the DNSSEC adoption by OpenBSD relevant to Debian decisions?

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/1382809758.15230.38938129.3733e...@webmail.messagingengine.com

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

[Russ Allbery]

Steve Langasek  writes:

> I don't think either of these are the right question.  Even if we change
> the default init system for jessie, because we *must* support backwards
> compatibility with sysvinit for upgrades, there is no justification for
> requiring packages to do anything else for jessie and no policy change
> is needed.

That isn't obvious to me.  We have, in the past, allowed upgrades to
require a preliminary upgrade of one or more packages.  The udev
transition comes to mind.  We *could* do the same thing here and require
an init upgrade as a pre-upgrade step when going from wheezy to jessie,
alongside a dependency on systemd or upstart (added by debhelper, for
example) for all packages providing startup configuration but not an init
script.  I'm not saying that's necessarily a good option, but it is an
option that we should discuss.

Also, we will eventually have to decide whether to drop the requirement
that packages provide sysvinit-compatible init scripts.  Even if we agree
on a requirement to do so for jessie, we could drop that requirement for
jessie+1 (and indeed will want to if we choose any init system other than
sysvinit or "all of the above," given that most of the benefits of either
upstart or systemd from a packaging perspective will only be seen when we
take that step).

We could always defer that decision until jessie+1, but that's the
decision with the most impact on kFreeBSD and Hurd, and if I were them,
I'd want to know whether that's the eventual project direction or not as
soon as possible so that I have as much time as possible to decide on my
next steps.

-- 
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/87ob6cylfl@windlord.stanford.edu

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

[Steve Langasek]

On Sat, Oct 26, 2013 at 11:07:36AM +0200, Lucas Nussbaum wrote:
> I think that there are two different questions:
> 1) Could you clarify which init system(s) must be supported by packages
>involved during system startup (daemons, etc.) and low-level services?

>[ the answer to that question would likely result into a update of
>  the Debian Policy, section 9.3 and 9.11 ]

>[ Note that most daemons will likely still have to support sysvinit
>  in jessie, in order to handle partial upgrades. ]

> 2) sysvinit is currently "Essential: yes", which causes it to be
>installed by default by the installer. Should sysvinit stay
>Essential? If not, should another init system be Essential?
>If not, how should this be addressed in the debian installer?

I don't think either of these are the right question.  Even if we change
the default init system for jessie, because we *must* support backwards
compatibility with sysvinit for upgrades, there is no justification for
requiring packages to do anything else for jessie and no policy change is
needed.

Likewise, the Essential: yes bit on the sysvinit package will be in effect
for a full release cycle regardless of what init system we choose, so it
needs to become a metapackage that depends on an ORed list of possible
implementations in order for us to make any change in jessie.

The real question before the TC is simply: what should the default init
system be for jessie?  The rest are technical details that can be
straightforwardly worked out once we have a decision on the direction.

-- 
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: Jessie release goal: DNSSEC as default recursive resolver

[Kevin Chadwick]

> If I'm not mistaking (please correct me), Fedora has the feature, and
> it's been a long time they do. FreeBSD as well (they have unbound in the
> default installer). OpenBSD also removed bind and switched to unbound
> (or at least is planning on doing it, I'm not sure). Debian shouldn't be
> left behind.

OpenBSD has it's own resolver with a tcp only option, unbound is in base
as a default off cache option due to the decision that bind's upstream
was making some odd decisions, bad coding and creating work and nsd was
saner in the vast majority of cases anyway.

I believe the reliability (DOS) issues that DNSSEC imposes coupled with
the low level of adoption would make it very unlikely that DNSSEC would
be enabled for certainly default resolving on OpenBSD without DNSCURVE
protection or some significant DNSSEC re-development.

-- 
___

'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/999192.15566...@smtp140.mail.ir2.yahoo.com

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

[Kevin Chadwick]

> systemd doing more is quite relevant for this decision as far as I
> understand the discussion: unlike upstart, systemd is not just an init
> replacement, but offers additional services like journald or logind.

I don't mean to be rude but please read up on systemd and see the pros
of cons such as on LWN.net comments or any distro mailing list as many
are tired of systemd discussion and this wide ranging and much of the
stolen/borrowed/existing functionality is what many don't want
mandated on all systems by default for various reasons.

You can have it if you want it through installation you shouldn't have
to have it in memory etc. and optionally not use it.

-- 
___

'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/293633.76504...@smtp132.mail.ir2.yahoo.com

Re: Proposal: switch init system to systemd or upstart

[Kevin Chadwick]

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

Generally the Linux kernel bends over backwards to avoid this breakage
and I know there is already some compatibility layer so please refrain
from commenting if you are this unsure or it is another controversial
and undecided topic such as Google requiring it.

-- 
___

'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/401821.95358...@smtp135.mail.ir2.yahoo.com

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

[Kevin Chadwick]

>  I recommend one more option, nicknamed "rotten tomatoes",
> that basically says that this GR should never have been proposed. 

And even more so not listened to for a few reasons.

Little has changed since the last discussion that I feel came to a
reasonable current standing with an overview possibly from Thorsten.

Allowing unforgivable and inconsiderate possibly purposeful upstream
decisions to improve the chances of migration with potential future
black mailing fall out to come from the non-negotiable systemd camp can
only encourage dispicable behaviour and send the wrong message and
one that is far more important not to send than not sending Gnome
dropped because of systemd message which would actually have some
justification.

I feel a consensus to never talk about systemd migration when systemd
or dependencies cause problems should be made and to do so only when a
high level decision is made that it is the right time to decide
whether to switch or stay with the current init has been made and on a
general what init system is best process rather than thread change. If
anyone deviates simply tell them that any general discussion not
relating to a particular problem is off agenda currently.

I wish not to get involved but worry about what will happen if I don't
and so would be glad if all can agree to simply replying to any attempts
for the time being with something like.

'/SBIN/INIT MIGRATION OR NOT IS CURRENTLY BEING CONSIDERED AND NOT
OPEN FOR DISCUSSION CURRENTLY'

-- 
___

'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/298796.95358...@smtp135.mail.ir2.yahoo.com

Re: systemd effectively mandatory now due to GNOME

[Kevin Chadwick]

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

Not against new technologies in general but if you are talking about
something which you expect every Linux user to use (when actually they
can't in deep embedded etc.) then yes they are hugely valid concerns
unless you want to reduce the applicability of Linux of course.

-- 
___

'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/814012.95358...@smtp135.mail.ir2.yahoo.com

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

[Kevin Chadwick]

> Steve Langasek has been consistently posting dishonest FUD against
> systemd. Maybe you could explain that as excessive zeal following from
> valid technical considerations, but I'd consider that an excessively
> charitable interpretation for a member of a body that is supposed to
> have public trust.

Please be specific if you ever use the word FUD again as I have it used
against myself when the details of what I have stated have simply not
been understood or omitted through weariness and it is perfectly
possible that varying user requirements simply lead to opposing
positions, which is normally a huge and unparalleled strength of UNIX
in catering to both when it's tried and tested principles are adhered
to.

For the record when reading this it occured to me that Steve was being
far more reasonable and meritable than you.

perhaps the words 'FUD' and 'modern' should be banned as non technical
arguments on this list.

-- 
___

'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/823544.95358...@smtp135.mail.ir2.yahoo.com

Re: let's split the systemd binary package

[Kevin Chadwick]

> "Session tracking" includes suspending/hibernating, because logind has
> a mechanism to let apps delay suspend, which is necessary for things
> like closing the inherent race condition in "lock the screensaver when
> we suspend... oh, oops, it didn't get scheduled until after we
> resumed, so the old screen contents are still visible for a moment
> when you open your laptop".

xlock && /usr/sbin/pm-suspend

That is the flexible way of doing that specific thing with a few ifs or
config checks where needed.

-- 
___

'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/251878.95358...@smtp135.mail.ir2.yahoo.com

Re: systemd effectively mandatory now due to GNOME

[Svante Signell]

On Wed, 2013-10-23 at 23:42 +0200, Svante Signell wrote:
> On Wed, 2013-10-23 at 23:06 +0200, John Paul Adrian Glaubitz wrote:

> > And does this cause any problems actually? Does your system no longer
> > boot properly using sysvinit when systemd is installed?
> 
> Well, gdm3 does not start for a new installation, probably caused by
> systemd(-logind). I had to use xfce4 instead as desktop for now, see
> also bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724731
> 

s/xfce4/lightdm+xfce/

bug 724731 not solved yet:(


-- 
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/1382804913.4094.2.camel@PackardBell-PC

Re: Proposal: switch default desktop to xfce

[Andrew M.A. Cater]

On Sat, Oct 26, 2013 at 04:41:00PM +0100, Jonathan Dowland wrote:
> 
> 
> > On 26 Oct 2013, at 16:08, "Andrew M.A. Cater" 
> >  wrote:
> > 
> > That wouldbe my preference - a tasksel change for "no desktop" "KDE" "GNOME"
> > "LXDE" XFCE" etc. for the netinst - default being no desktop - ideal for a 
> > minimum
> > install.
> 

This is for the netinst - so something that will install a minimum system from 
the network and is <400M at the moment.


> I don't understand how that would work: I presume you don't mean an isolinux 
> option that changed the meaning of "Debian desktop environment" to "no 
> desktop".
> 
> I think the boot options make the situation more complicated. Why not have a 
> selection of tasks
> 

No, that is pretty much what I mean: it would be useful to have no desktop 
installed by default.

If you select - "Install a desktop environment" then you get to select which 
one you want: if that changes init choices / software choices to 
pull in the appropriate DE package list before your first boot into the new 
system.

Then if someone says - "I need to install a DE because I forgot to install a DE 
at initial install time" - one command is needed - 
something like

dpkg-reconfigure desktop-environment -plow

should do it.


> XFCE desktop environment (default)
> LXDE desktop environment
> GNOME desktop environment
> KDE desktop environment
>  
> Where the debian recommended is suffixed as I've indicated above, and to get 
> no desktop, you deselect them all.
> 
> My main concern about this would be the task selection screen having too many 
> options. In which case the desktop questions could all have their own screen.
> 

Yes - a desktop selection should probably have its own screen - that way you 
can add any number of DEs you need.

AndyC


-- 
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/20131026164339.ga5...@galactic.demon.co.uk

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

[Richard Hartmann]

Off list.

Thanks!

Richard

Pro-Action against dependency hell

[Kevin Chadwick]

What can be done to prevent rather than reacting to dependency hell all
the time. Some developers obviously get it and yet others seem to
pro-actively work in the other direction.

There was a time when it was said that this problem was finally heading
in the right direction.

There is an example that I am not clear on in terms of build
dependencies too as oppose to runtime dependencies.

epdfview depends on libqt

evince pulls in the whole of QT adding ages to the build time. 

Speaking to a guy on a QT stand at an exhibition he said that he had
not heard of evince but seemed to think that evince must be using QT
wrongly.

> > 
> > Installing systemd does not magically switch your init system.  
> 
> It doesn't *right now*, but from [0] I conclude that it would very much
> like to do so and so possibly, in the future, will.

It would be rediculous if chattr +ias /sbin/init needed to be set
before installing systemd.

Of course a better option would be if major contributors were fighting
and not contributing to dependency hell. It really irks how
inconsiderate to others time upstream has shown itself to be when they
already have the knowledge to do it right in the first place. It makes
me wonder who educated them.


-- 
___

'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/105179.95358...@smtp135.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

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

I saw a general survey possibly on techrepublic that alleged
reasonable data collection methods (though I don't recall how the data
was collected) suggesting that xfce was very close or overtaken Gnome
now and KDE was the most widely used desktop.

On those grounds I would therefore advocate KDE as default, however I am
not fond of the lack of modularity of KDE, whereas with xfce it is a
primary goal making users able to shape their debian for whatever
general usage easily and fast is fast on fast systems too.

-- 
___

'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/770901.95358...@smtp135.mail.ir2.yahoo.com

Re: Proposal: switch init system to systemd or upstart

[Ben Hutchings]

On Sat, 2013-10-26 at 08:34 +0300, Uoti Urpala wrote:
> 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).
[...]

Your understanding seems to be incomplete.

There are two architectural problems with the current cgroups API: (1)
the multiple types of cgroups form separate hierarchies, which can
result in effective conflicts between different cgroup controllers (2)
when the cgroupfs is manipulated by multiple tasks, this results in
unpleasant race conditions for userland.

I think there is agreement in the kernel community that (1) should be
fixed by requiring all cgroups to fit into a single hierarchy.  There is
not yet agreement as to whether (2) should be fixed by (a) putting a
single daemon (presumably pid 1) in charge of cgroupfs and having other
userland programs make requests to that daemon, or (b) improving the API
to make the race conditions avoidable, so control over sub-trees can be
safely delegated.

There was a discussion of these problems at the Kernel Summit on
Thursday and I hope to see a more detailed report in LWN within the next
few days.

Ben.

-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding stump
of a severed limb. - me, 29 June 1999


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

Re: Jessie release goal: DNSSEC as default recursive resolver

[Russ Allbery]

Thomas Goirand  writes:

> If this means installing a recursive DNS resolver by default (unbound
> pops to my mind, since it has the feature by default), I'd say be it,
> though probably that is more of an open question, and an implementation
> details. I personally wouldn't mind at all if the Debian default
> configuration would by-pass whatever ISP are providing, since we've seen
> this broken in multiple cases (so many that I don't think it's even
> necessary to use an example to illustrate that fact here...).

One has to be careful about this, since quite a few installations are on
unroutable IP addresses that can't do direct DNS queries to the DNS roots.
Even if a system is installed via the network installer, that may be with
the goal of eventually moving it into a private network.  If your primary
DNS resolver doesn't reply due to inability to reach the root DNS servers,
it tends to cause all sorts of weird slowness and issues that are hard for
the average user to understand or track down, even if you have other DNS
servers listed as secondary resolvers.

The safe default is still to rely on the organizational DNS resolvers as
provided by DHCP or local manual configuration.

I'm definitely in favor of improved DNSSEC support, but I think it's going
to need to be something that people can optionally install if we're trying
to provide it by bypassing local DNS infrastructure.

-- 
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/87fvro0zs0@windlord.stanford.edu

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

[Ondřej Surý]

On Sat, Oct 26, 2013, at 16:37, Christoph Anton Mitterer wrote:
> On Sat, 2013-10-26 at 10:00 +0200, Stefano Zacchiroli wrote:
> > GRs should be used for societal and policy[*] decisions. Using GRs for
> > *technical* decision is stupid.
> Is it for sure that this (and I guess it's mostly about upstart vs.
> systemd is *only* a technical question?

Several Debian Developers has voiced that this is the technical
question. Could you please stop commenting and suggesting how we should
run Debian project? I think we can handle well even without your
contributions.

It would be much appreciated if we can stop this useless thread now.

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/1382804321.26653.38912417.5718b...@webmail.messagingengine.com

Jessie release goal: DNSSEC as default recursive resolver

[Thomas Goirand]

Hi,

I'd find it very nice if we had, by default, DNSSEC resolving in Debian,
at least in the "default" configuration (whatever that means). By this,
I mean that any non-experienced user would just install (or upgrade to)
Jessie, start a web browser (Chormium, Iceweasel, etc.: take your
pick...), and have DNSSEC resolving just working. Of course, we'd have
this also for non-browser applications as a consequence if it's
implemented (I'm thinking about stuff like curl, wget), though to me,
the browser part is the most important.

If this means installing a recursive DNS resolver by default (unbound
pops to my mind, since it has the feature by default), I'd say be it,
though probably that is more of an open question, and an implementation
details. I personally wouldn't mind at all if the Debian default
configuration would by-pass whatever ISP are providing, since we've seen
this broken in multiple cases (so many that I don't think it's even
necessary to use an example to illustrate that fact here...).

If I'm not mistaking (please correct me), Fedora has the feature, and
it's been a long time they do. FreeBSD as well (they have unbound in the
default installer). OpenBSD also removed bind and switched to unbound
(or at least is planning on doing it, I'm not sure). Debian shouldn't be
left behind.

Probably this is too narrow for a release goal, or it is too late to
raise this topic, though I would find it very nice if we had the
feature, which is why I'm raising this topic. Thoughts welcome.

Thomas Goirand (zigo)

P.S: I wont have time to get involve in this, though I don't think that
there is so much work involved, is it?


-- 
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/526be8e3.9000...@debian.org

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

[Ansgar Burchardt]

Hi,

Christoph Anton Mitterer  writes:
> On Sat, 2013-10-26 at 10:00 +0200, Stefano Zacchiroli wrote:
>> GRs should be used for societal and policy[*] decisions. Using GRs for
>> *technical* decision is stupid.
> Is it for sure that this (and I guess it's mostly about upstart vs.
> systemd is *only* a technical question?
>
> - Apparently both are much more capable than sysvinit
> - Apparently you can do most things of a "modern" init system with both
>
> Sure there are many detailed questions like e.g. systemd doing some
> (IMHO useless integrity protection on logs, which AFAIK upstrart hasn't
> anything similar)... but that's IMHO rather a matter of taste.

systemd doing more is quite relevant for this decision as far as I
understand the discussion: unlike upstart, systemd is not just an init
replacement, but offers additional services like journald or logind.

These provide useful functionality and parts of them would be needed
even when using upstart (logind was mentioned). So deciding for upstart
means providing these services via some other means, such as writing a
replacement, forking an old version of systemd's logind, or convincing
systemd upstream to provide a logind that works together with upstart.
I am not sure how much work this will be, esp. should additional modules
be required later.

Also the tight integration into systemd allows to provide some really
nice features. From trying out systemd for a bit, I found "systemctl
status" quite impressive. I don't know if upstart has something
comparable.

For just the init part, I'm not sure how large the differences between
the systems are. Systemd seems to provide more features, upstart tries
to be small and simple.

Ansgar


-- 
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/87ppqs10dr@eisei.43-1.org

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

[Andrey Rahmatullin]

On Sat, Oct 26, 2013 at 04:37:55PM +0200, Christoph Anton Mitterer wrote:
> [...] non-Linux UNIX flavours - which I think Debian should support for
> ethical and philosophical reasons.
Uh-oh.



-- 
WBR, wRAR


signature.asc
Description: Digital signature

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

[Christoph Anton Mitterer]

On Sat, 2013-10-26 at 10:00 +0200, Stefano Zacchiroli wrote:
> GRs should be used for societal and policy[*] decisions. Using GRs for
> *technical* decision is stupid.
Is it for sure that this (and I guess it's mostly about upstart vs.
systemd is *only* a technical question?

- Apparently both are much more capable than sysvinit
- Apparently you can do most things of a "modern" init system with both

Sure there are many detailed questions like e.g. systemd doing some
(IMHO useless integrity protection on logs, which AFAIK upstrart hasn't
anything similar)... but that's IMHO rather a matter of taste.


IMHO there is quite some big political point in the whole question,
namely which of the both fractions one wants to support.

- Canonical/*buntu
- RedHat and (what seems to be) the rest of the world

It's also a question wheter Debian will at least politically be tied
even more to Canonical/*buntu - and I guess no one can claim that there
wouldn't be sucht ties (already by having many Canonical workers being
DDs,too)[0].


I wouldn't see many technical arguments that speak strongly really in
favour of one or the other, perhaps:
- Against systemd speaks that it's uncertain on whether there will be a
solution in the end for the non-Linux UNIX flavours - which I think
Debian should support for ethical and philosophical reasons.
Admittedly I have no idea how the situation is there wrt upstart.

- For systemd speaks, that it seems most of the rest of the world is
focusing on it (many kernel developers, the wayland guys, etc.).
Does upstart receive the same "attention" here?
Could that mean much effort or even problems for Debian in the end, if
it decides for upstream?



Cheers,
Chris.






[0] And note that I neither said these ties would be good nor bad.


smime.p7s
Description: S/MIME cryptographic signature

Re: Proposal: switch default desktop to xfce

[Jonathan Dowland]

> On 26 Oct 2013, at 16:08, "Andrew M.A. Cater"  
> wrote:
> 
> That wouldbe my preference - a tasksel change for "no desktop" "KDE" "GNOME"
> "LXDE" XFCE" etc. for the netinst - default being no desktop - ideal for a 
> minimum
> install.

I don't understand how that would work: I presume you don't mean an isolinux 
option that changed the meaning of "Debian desktop environment" to "no desktop".

I think the boot options make the situation more complicated. Why not have a 
selection of tasks

XFCE desktop environment (default)
LXDE desktop environment
GNOME desktop environment
KDE desktop environment
 
Where the debian recommended is suffixed as I've indicated above, and to get no 
desktop, you deselect them all.

My main concern about this would be the task selection screen having too many 
options. In which case the desktop questions could all have their own screen.

--
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/485d0ad4-e982-4902-9f70-719daf1b3...@debian.org

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

[Enrico Tassi]

On Fri, Oct 25, 2013 at 07:09:45PM +0300, Uoti Urpala wrote:
> Steve Langasek has been consistently posting dishonest FUD against
> systemd. Maybe you could explain that as excessive zeal following from
> valid technical considerations, but I'd consider that an excessively
> charitable interpretation for a member of a body that is supposed to
> have public trust.

Steve *has* public trust.  There are very few people around here that
contributed to Debian more than he did.

If you don't feel he has public trust, then you know nothing about
Debian, and you are for sure not in a position to criticize the
decisions he may take as technical committee member.

Ditto for Colin and the other members of the board, that are there for a
reason.  In case you don't know, that reason is not being champions of
trolling on -devel.

Who are you?  Who pays your bills?
-- 
Enrico Tassi


-- 
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/20131026153000.GA10501@birba.invalid

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

[Andrew Starr-Bochicchio]

On Sat, Oct 26, 2013 at 4:00 AM, Stefano Zacchiroli  wrote:
> On one hand, the belief that every DD is technically omniscient is the
> reason why we still have so many pointlessly heated debates on this
> mailing list. We would have way less of those if we let only people who
> have a clue debate specific matters. Unfortunately, many of us seem to
> be too arrogant to realize they, in fact, don't have a clue.
>
> On the other hand, if we stop believing that every single DD is
> technically omniscient, we would realize how foolish is to use GRs to
> vote on technical matters. Doing so results in taking important
> technical decisions essentially randomly. Based on popularity of the
> various options, trends, vocality of the supporting groups, etc. That's
> not what Debian is or should be about.

I've been trying very hard to not get involved in this, but I feel the
need to poke my head up to give this a very strong +1. For the same
reason the chances of me uploading the kernel approach zero, there's
no reason I need to vote on the init system. In fact, by the tone of
the discussions we've had on the topic I have very little confidence
in a GR leading to a decision being made on technical merits. It's
time to let the tech-ctte do their constitutionally mandated job.

Thanks,

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/CAL6k_AwEaeCzAKTtmjHCYXAJoOTYNXLoWrEAZB7Y1_==bxq...@mail.gmail.com

Re: Proposal: switch default desktop to xfce

[Andrew M.A. Cater]

On Fri, Oct 25, 2013 at 11:44:48PM +0100, Steve McIntyre wrote:
> Andy Cater wrote:
> >
> >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?
> 

That wouldbe my preference - a tasksel change for "no desktop" "KDE" "GNOME"
"LXDE" XFCE" etc. for the netinst - default being no desktop - ideal for a 
minimum
install.


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

Now that USB sticks at 16/32GB are (relatively) cheap - it is actually a much 
better
bet to install the Blu-Ray .iso image in the same way :)

Thanks for reading,

All the best - hope to get myself sorted to come to the mini-Debconf in 
November -
see you then,

AndyC

> -- 
> 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/20131026150853.ga4...@galactic.demon.co.uk

Re: MySQL.. no.. _I_ need your help!

[Patrick Galbraith]

Clint - perhaps you and I can talk about this in Hong Kong?


-- 
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/5f7ce033-3ae0-4c17-8356-a31015a72...@patg.net

Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)

[Emilio Pozuelo Monfort]

On 26/10/13 16:38, Jonas Smedegaard wrote:
> Quoting Emilio Pozuelo Monfort (2013-10-26 13:03:13)
>> On 26/10/13 12:02, Jonathan Dowland wrote:
>>> On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote:
 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).
>>>
>>> gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks
>>>
>>> How do you suggest this was fixed?
>>>
>>> (There's an explanation for the libgnom2-0 → gvfs dependency in
>>> #550479).
>>
>> libgnome2 is long deprecated, port gnucash away from it!
> 
> If that's the case, I believe the library should be moved to oldlibs: 
> Please consider file a bugreport suggesting that to the package 
> maintainer.

Done in svn:

libgnome (2.32.1-5) UNRELEASED; urgency=low

  * debian/control.in:
+ Move to section oldlibs.

 -- Emilio Pozuelo Monfort   Sat, 26 Oct 2013 16:54:53 +0200


-- 
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/526bd801.8020...@debian.org

Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)

[Jonas Smedegaard]

Quoting Emilio Pozuelo Monfort (2013-10-26 13:03:13)
> On 26/10/13 12:02, Jonathan Dowland wrote:
>> On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote:
>>> 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).
>> 
>> gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks
>> 
>> How do you suggest this was fixed?
>> 
>> (There's an explanation for the libgnom2-0 → gvfs dependency in
>> #550479).
> 
> libgnome2 is long deprecated, port gnucash away from it!

If that's the case, I believe the library should be moved to oldlibs: 
Please consider file a bugreport suggesting that to the package 
maintainer.

(not filing bugreport about that myself, as I only know the issue from 
above post).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Olav Vitters]

On Sat, Oct 26, 2013 at 12:02:00AM +0100, Kevin Chadwick wrote:
> > 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).

There are various maintainers+developers who would love to see GNOME
support Wayland and nothing more. This due to code complexity and test
matrix (too many different options and it becomes difficult to test
things). And we do do continuous integration, plus I had to deal with
the bugs caused by the introduction of Wayland support.

Various of above mentioned maintainers/developers are sponsored by Red
Hat. I say sponsored because they pretty much do what they think is
good. I have not seen any corporate agenda (I also fail to understand
why we have so many of them). Anyway, they just don't want code
complexity.

The *main* reason that GNOME will keep Wayland + X compatibility for a
long time, thus introducing more bugs and slowing down full Wayland
support, is the same GNOME release team person who urged to support
Wayland. He's sponsored by Red Hat.

In brief: The person mainly responsible for allowing people to rely on
our X support for a much longer time is one of those Red Hat people.

Not sure if you like Wayland or not, but something to keep in mind, if
it wasn't up to this Red Hat person, X support would be die much more
quickly. And this decision is not made due to forcing, it is to due
supporting one thing well, not multiple things a bit with various
degrees of testing and buggyness.

-- 
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/20131026131723.gj29...@bkor.dhs.org

Re: Proposal: switch default desktop to xfce

[Jonathan Dowland]

> On 26 Oct 2013, at 13:00, Neil Williams  wrote:
> 
> Desktop
> components cannot dictate how the rest of the system operates.

The gnome folks are free to do what they please. They don't answer to us and 
your repeated assertions that they're crossing a line just shine a light on 
your own hubris. Here, we decide what happens *in Debian*.

--
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/1438a3ea-7b25-4727-9dc7-905bedb02...@debian.org

Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)

[Sébastien Villemot]

Le samedi 26 octobre 2013 à 13:03 +0200, Emilio Pozuelo Monfort a
écrit :
> On 26/10/13 12:02, Jonathan Dowland wrote:
> > On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote:
> >> 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).
> > 
> > gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks
> > 
> > How do you suggest this was fixed?
> > 
> > (There's an explanation for the libgnom2-0 → gvfs dependency in
> > #550479).
> 
> libgnome2 is long deprecated, port gnucash away from it!

This is already done in the current development release (in
experimental).

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594



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

Re: Proposal: switch default desktop to xfce

[Neil Williams]

On Fri, 25 Oct 2013 14:58:34 -0700
Nikolaus Rath  wrote:

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

Yes. It is the tight coupling between desktop and init which is
precisely the problem. *IF* the chosen init system is already the
default, then by all means use the features provided. Desktop
components cannot dictate how the rest of the system operates. The
desktop is optional. Adding a desktop to a running system must not
require a change of init, just as it cannot require a change of kernel
or perl interpreter.

I get to choose how I enable or disable mounting drives and other
niceties which would require root access, not the desktop. Equally,
user switching is something I've never considered useful, so that's
easily omitted too.

-- 


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



signature.asc
Description: PGP signature

Re: Proposal: switch default desktop to xfce

[Chris Bannister]

[Please don't top post on this mailing list!]

On Thu, Oct 24, 2013 at 06:45:02PM +0200, Zlatan Todoric wrote:
> And just bashing GNOME DE for systemd and GNOME Classic
> is not good enough point because probably the largest user base
> of Debian user use GNOME.

That is because it is installed by default! (unless you explicitly
opt-out.)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20131026112612.GR358@tal

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

[Steve McIntyre]

Zack wrote:
>
>Note that the *possibility* of taking technical decisions by GRs is
>important, as it provides a balance of powers within the project, but we
>should always do everything in our power to avoid doing that.
>
>The decisions about the init system (both "which are the supported
>ones?" and "which is the default one?") clearly belong to the tech-ctte
>at this point.

Agreed 100%. Let's see what they have to say.

-- 
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/e1va1ll-0003ty...@mail.einval.com

Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)

[Emilio Pozuelo Monfort]

On 26/10/13 12:02, Jonathan Dowland wrote:
> On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote:
>> 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).
> 
> gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks
> 
> How do you suggest this was fixed?
> 
> (There's an explanation for the libgnom2-0 → gvfs dependency in
> #550479).

libgnome2 is long deprecated, port gnucash away from it!

Emilio


-- 
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/526ba171.6000...@debian.org

gnucash dependencies (was Re: Proposal: switch default desktop to xfce)

[Jonathan Dowland]

On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote:
> 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).

gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks

How do you suggest this was fixed?

(There's an explanation for the libgnom2-0 → gvfs dependency in
#550479).


-- 
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/20131026100204.ga32...@bryant.redmars.org

Bug#727759: ITP: websocket-client -- WebSocket client library for python

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: websocket-client
  Version : 0.12.0
  Upstream Author : liris 
* URL : https://github.com/liris/websocket-client
* License : LGPL-2.1+
  Programming Lang: Python
  Description : WebSocket client library for python

 websocket-client provides a low-level, synchronous API providing WebSocket
 client functionality to Python programs. It conforms to the WebSocket
 specification as standardized by the IETF in RFC 6455.
 .
 WebSocket is a protocol providing full-duplex communication channels over
 TCP, mostly used in Web browsers.

This module is a test dependency for moksha.hub. It will be packaged under the
DPMT umbrella, and the binary package will be called python-websocket
as per the Debian Python Policy.


-- 
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/20131026094406.6017.11840.report...@darboux.home.olasd.eu

Bug#727757: ITP: ruby-mizuho -- Mizuho documentation formatting tool

[Felix Geyer]

Package: wnpp
Severity: wishlist
Owner: Felix Geyer 

* Package name: ruby-mizuho
  Version : 0.9.19
  Upstream Author : Hongli Lai
* URL : https://github.com/FooBarWidget/mizuho
* License : Expat
  Programming Lang: Ruby
  Description : Mizuho documentation formatting tool

Mizuho is a documentation formatting tool, best suited for small to
medium-sized documentation.
Mizuho converts Asciidoc input files into nicely outputted HTML,
possibly one file per chapter. Multiple templates are supported,
so you can write your own.


-- 
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/20131026093028.30989.26333.reportbug@localhost6.localdomain6

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

[Lucas Nussbaum]

On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote:
> In response to the recent threads, I'd like to ask the tech-ctte to
> please vote on and decide on the default init system for Debian.

I agree. I don't think that many substantial new arguments are going to
be brought by waiting more on this topic. And it is clear that we have
reached a point where not having clear guidance is severely hurting the
project.

On 25/10/13 at 16:40 +, Thorsten Glaser wrote:
> I’d still say, let’s just GR about it. Prepare one now, then
> have some time to cool down before the vote period.

I think that it would be a failure of the Debian project if we had to have a GR
about such a technical decision. I think that we need to trust that the
Technical Committee will make the right decision. A GR about this will likely
result in splitting and hurting the project even more.

On 25/10/13 at 14:43 -0400, Paul Tagliamonte wrote:
> 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.

I think that there are two different questions:
1) Could you clarify which init system(s) must be supported by packages
   involved during system startup (daemons, etc.) and low-level services?
   
   [ the answer to that question would likely result into a update of
 the Debian Policy, section 9.3 and 9.11 ]

   [ Note that most daemons will likely still have to support sysvinit
 in jessie, in order to handle partial upgrades. ]

2) sysvinit is currently "Essential: yes", which causes it to be
   installed by default by the installer. Should sysvinit stay
   Essential? If not, should another init system be Essential?
   If not, how should this be addressed in the debian installer?

Lucas


signature.asc
Description: Digital signature

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

[Martin Wuertele]

* Uoti Urpala  [2013-10-25 18:27]:

> Steve Langasek has been consistently posting dishonest FUD against
> systemd. Maybe you could explain that as excessive zeal following from
> valid technical considerations, but I'd consider that an excessively
> charitable interpretation for a member of a body that is supposed to
> have public trust.

Care to back your accusation. If you don't like his backed arguements,
come up with something better but declaring them "dishonest FUD against
systemd" because you favor systemd and he does not is plain wrong imo.

Yours Martin


-- 
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/20131026084646.gy15...@anguilla.debian.or.at

Bug#727754: New "security-aware-resolver" virtual package.

[Charles Plessy]

Package: debian-policy
Version: 3.9.4
Severity: wishlist

Le Thu, Oct 24, 2013 at 09:28:32AM +0200, Ondřej Surý a écrit :
> Hi James,
> 
> since the authoritative-name-server idea was rejected by the list, I was
> going to propose alternative:
> 
> security-aware-resolver
> 
> The definition from RFC4033:
> 
>Security-Aware Resolver: An entity acting in the role of a resolver
>   (defined in section 2.4 of [RFC1034]) that understands the DNS
>   security extensions defined in this document set.  In particular,
>   a security-aware resolver is an entity that sends DNS queries,
>   receives DNS responses, supports the EDNS0 ([RFC2671]) message
>   size extension and the DO bit ([RFC3225]), and is capable of using
>   the RR types and message header bits defined in this document set
>   to provide DNSSEC services.

Dear all,

are there Debian Developers seconding or objecting to this new virtual package
name ?

Have a nice week-end,

-- 
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/20131026084441.gj17...@falafel.plessy.net

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

[Chris Bannister]

On Thu, Oct 24, 2013 at 11:00:42PM +0900, Norbert Preining wrote:
> On Do, 24 Okt 2013, Charles Plessy wrote:
> > at this point, I would like to point at a very important part of the
> > "revised code of conduct" that Wouter is proposing: "Assume good faith".
> 
> On Do, 24 Okt 2013, Adam Borowski wrote:
> > My apologies, I overreacted.
> 
> 
> Oh holy s...sunshine (I have to be careful, otherwise I will be ostracised
> again) ... now that useless "political correctness" is taking
> over again.

Just remember that if someone is offended it doesn't mean they are
right.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20131026082804.GO358@tal

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

[Stefano Zacchiroli]

On Fri, Oct 25, 2013 at 02:03:38PM +, Thorsten Glaser wrote:
> Let’s GR it.

No. I think I've already argued in the past against this idea on -devel,
possibly even in reply to you, Thorsten. As I can't find my post back
then, let me reiterate.

GRs should be used for societal and policy[*] decisions. Using GRs for
*technical* decision is stupid.  We really need to stop thinking that
every single member of the Debian project, just because he/she is a DD,
has a clue on every single technical matter that go on in the project.
And note that proving you have a clue on something in Debian is pretty
easy: just work actively on that matter, being the maintainer of related
packages, or having a verifiable flow of working patches against them,
etc.

[*] in a broad sense, not related to the document called Debian Policy

On one hand, the belief that every DD is technically omniscient is the
reason why we still have so many pointlessly heated debates on this
mailing list. We would have way less of those if we let only people who
have a clue debate specific matters. Unfortunately, many of us seem to
be too arrogant to realize they, in fact, don't have a clue.

On the other hand, if we stop believing that every single DD is
technically omniscient, we would realize how foolish is to use GRs to
vote on technical matters. Doing so results in taking important
technical decisions essentially randomly. Based on popularity of the
various options, trends, vocality of the supporting groups, etc. That's
not what Debian is or should be about.

Note that the *possibility* of taking technical decisions by GRs is
important, as it provides a balance of powers within the project, but we
should always do everything in our power to avoid doing that.

The decisions about the init system (both "which are the supported
ones?" and "which is the default one?") clearly belong to the tech-ctte
at this point.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Neil Williams]

On Sat, 26 Oct 2013 07:57:50 +0300
Uoti Urpala  wrote:

> 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 see how that is relevant to the project. AFAICT you are not
directly involved in Debian and would have no vote if this did go to a
GR, neither are you involved in packaging systemd for Debian.

https://nm.debian.org/public/people

https://alioth.debian.org/project/memberlist.php?group_id=100797

http://ftp-master.metadata.debian.org/changelogs/main/s/systemd/unstable_changelog

Whether or not the project has confidence in the Technical Committee has
nothing to do with your opinions, which are blatantly biased.

If there are people inside Debian (i.e. people who would have a vote
in a Debian GR or who are actively involved in packaging) who have no
confidence in the Debian Technical Committee to come to a fair decision
for the benefit of all of Debian then I would be concerned. That random
people not involved in Debian have prejudged individual members is of
no concern.

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

True, but it's the people doing the work in Debian who matter in
respect of this decision. That is where the resolution of this problem
must take place - the opinions of those not doing any of the work,
ultimately, count for nothing.

-- 


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



signature.asc
Description: PGP signature