Re: systemd effectively mandatory now due to GNOME

[Sune Vuorela]

On 2013-10-27, Brian May  wrote:
> * Some people say this means it needs systemd running as pid=1, same say it
> doesn't. Am still confused here.

The facts seems to be that logind/systemd in version 204 (the current
one in debian) doesn't need systemd as pid 1, but latest upstream
(version 205 and newer) does.

> * Some people say that the parts of systemd that Gnome uses should be split
> into a separate package, so, in theory, it should be possible to install
> just those parts without installing all of systemd. However the systemd
> object to doing this (I missed the reasons behind this).

It is more work for the systemd maintainers, and all people will gain is
a couple of kilobytes of free diskspace from the systemd executable
(haven't looked up its size)

> * Gnome is said to work fine even on platforms that don't have systemd
> installed. Does this mean that systemd is optional?

It is more a matter of defining 'fine'. Apparantly suspend/hibernate is
bound now logind, as well as user switching and a couple of other
features

> * For reasons I don't properly understand, some people seem to think a
> decision is needed to make or not make systemd the default in Debian.

It is more a matter of many people wanting a new init system because
features and others seems to not want something new because they know
what they have.
And since we can't have two init systems being the default, and we can't
expect maintainers of packages to actively test a bunch of different
init systems, we need a decision to be able to move forward.

> Have I missed anything or got anything wrong?

You missed a few bits, but yeah.

/Sune


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

Re: Proposal: switch default desktop to xfce

[Stefano Zacchiroli]

On Fri, Oct 25, 2013 at 11:57:29PM +0100, Steve McIntyre wrote:
> > I would not be opposed to changing the default for xfce for now, and
> > reverting it if gnome's improvements make it a better choice.
> 
> OK. I suggest that we *try* that for now.

If we try, what will be the criteria for assessing whether the
experiment has been successful (and hence worth keeping for Jessie) or a
failure (and hence reverting it)?

Hint: I don't think that the amount of opinionated posts anti-GNOME or
anti-Xfce posted on debian-devel is a good success metric :-)

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

Bug#728085: ITP: pyfftw -- A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms.

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: pyfftw
  Version : 0.9.2
  Upstream Author : Henry Gomersall 
* URL : http://hgomersall.github.io/pyFFTW/
* License : GPL-3, some windows-specific headers in BSD clause-2 and 3
  Programming Lang: python 
  Description : A pythonic wrapper around FFTW, the FFT library, presenting 
a unified interface for all the supported transforms.

pyFFTW is a pythonic wrapper around FFTW 3, the speedy FFT library. The
ultimate aim is to present a unified interface for all the possible transforms
that FFTW can perform.

Both the complex DFT and the real DFT are supported, as well as on arbitrary
axes of abitrary shaped and strided arrays, which makes it almost feature
equivalent to standard and real FFT functions of numpy.fft (indeed, it supports
the clongdouble dtype which numpy.fft does not).

Wisdom import and export now works fairly reliably.

Operating FFTW in multithreaded mode is supported.

pyFFTW implements the numpy and scipy fft interfaces in order for users to take
advantage of the speed of FFTW with minimal code modifications.

A comprehensive unittest suite can be found with the source on the github
repository or with the source distribution on PyPI.

The documentation can be found on github pages, the source is on github and the
python package index page is here.


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

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

[Jakub Wilk]

* Thomas Goirand , 2013-10-25, 23:45:
OpenRC has been waiting in the NEW queue (targeting experimental, as this 
is what it is right now: experimental!) for more than a month. It'd be nice 
if someone from the FTP master team could review it, so that at least 
others can try it.


IANA ftp-master, but here's my quick review:

Please rename /sbin/rc to something else. We've had (unrelated) /usr/bin/rc 
in Debian for at least 18 years.


What is the rationale for the binary-or-shlib-defines-rpath override?

--
Jakub Wilk


--
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/20131028102822.ga7...@jwilk.net

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

[Didier 'OdyX' Raboud]

Le dimanche, 27 octobre 2013 08.49:59 Charles Plessy a écrit :
> I strongly recommend that the three current and former employees of
> Canonical refrain from voting: (…)

Frankly, I think this is going too far. Either we trust them to "do the 
right thing"™ or we don't.

In the first case, we should all "assume good faith" and let them do 
what they see best as tech-ctte members (and employees of their 
respective employers), including assessing the risk of people second-
guessing their votes or the timings of their votes, etc, etc. "Doing the 
right thing" could very well be to refrain from voting but that must be 
their individual decision, not a following of any recommendation.

In the latter case, we should appeal to §6.2.5 and ask the tech-ctte and 
the DPL to revoke their tech-ctte mandates.

As I don't think there's space for a middle ground ala "we trust some 
members of the tech-ctte but not others based on who pays their bills", 
I'm convinced that now is the time to empower the tech-ctte with our 
trust and let them collectively and individually decide on that matter.

Cheers, OdyX

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

Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

[Emmanuel Bourg]

Le 27/10/2013 16:30, Daniel Schepler a écrit :

> (To be honest, the 
> Java packages are such a tangled mess that I've given up on trying to 
> bootstrap that part of the archive for now -- and many of those do get pulled 
> into the minimal set of ca. 1473 source packages I get with my criteria.)

Hi Daniel, could you elaborate on the tangled mess of the Java packages?
As someone who cares about the Java packages in general I'd be
interested in hearing what could be improved.

Emmanuel Bourg


-- 
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/526e473d.7070...@apache.org

Re: Jessie release goal: DNSSEC as default recursive resolver

[Thijs Kinkhorst]

On Sat, October 26, 2013 18:52, Ondřej Surý wrote:
>> 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 think it's indeed very important that a default install uses the DHCP
provided DNS-servers or locally configured resolvers, because in many
networks that's the only way to reliably resolve things. dnssec-trigger
may provide that, but since it's 'experimental' and not even packaged for
Debian at all at this point, I think it's quite premature to make this a
release goal for Jessie.


Thijs


-- 
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/4b7a870487521e2cdb8b35bfd39bfecd.squir...@aphrodite.kinkhorst.nl

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

[Akhil Mohan]

Hi Clint,

I am Akhil Mohan, new to the list and eager to help everyone here in 
packaging latest releases of MySQL server.


Amongst the points highlighted by you, I think packaging MySQL 5.6 would 
be one of the priorities and I would like to participate in bringing up 
quality packages for the same.
I am already on #debian-mysql at OFTC and will try to make myself 
visible to alioth team.


Please let me know if you have any immediate pointers for me and I will 
try to contribute to the same.


Regards,
Akhil


On Friday 25 October 2013 09:02 PM, Clint Byrum wrote:

Greetings earthlings,

As some of you may know, I've been doing the bulk of the package
maintenance on the mysql package for a while now. It started as part of
my day job with Canonical, but since leaving Canonical it has been more
a labor of love for Debian.

I have love for other things too, such as my children, and seeing the
sun shine every once in a while. Thus, I have found almost no time for
packaging MySQL for Debian.

I am asking you, the Debian developers, to step up and help. I am
basically unable to contribute more than an hour a month now. There is a
new round of secret CVE bugs to fix, and some old bugs that need to be
handled. I think my October hour is about to be available, so I might
be able to address those, but after that, if I don't get any more help,
I'm done.

What can you do to help?

- Raise your hand and say you'll help
- Perhaps help us do this right (I suspect I should have an RFH bug)
- Join #debian-mysql on OFTC
- Join the alioth team and request svn access
- Triage bugs (src:mysql-5.5 and for oldstable src:mysql-5.1)
- Help package the latest patch releases from Oracle
- Help with MariaDB (James Page and Otto, thanks for doing this btw!)
- Help us migrate to git

Now, all of that said, please do not just pick up the package and run
off and do a bunch of things without first letting us know you're doing
it. There are people quietly working on some long term interesting
things and you may be duplicating or diverging heavily from their work.

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint





--
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/526e5355.7000...@oracle.com

Re: Imminent mass-bug-filing warning for multiarch:same bugs

[Jakub Wilk]

* Jenny Hopkins , 2013-10-25, 09:32:
Please include me in replies to the list, at hopkins.je...@gmail.com. I'll be 
away for the coming week, and then will file the bugs if nobody has objected.


Done.



DIFFS IN changelog.Debian.gz: binNMU.

Problem resolved by rebuilding packages using current sid sbuild tools.
Bugs will be filed by source package.



These should be fixed by binNMUs.


Source: dnsval_2.0-1.1 (2 packages affected)
libval-dev|2.0-1.1|./usr/bin/libval-config
libval-dev||2.0-1.1|./usr/include/validator/validator-config.h


#724749


Source: libguestfs_1:1.22.7-1 (2 packages affected)
libguestfs-gobject-dev|1:1.22.6-2|./usr/share/gtk-doc/html/guestfs/index.sgml
libguestfs-gobject-dev|1:1.22.6-2|./usr/share/gtk-doc/html/guestfs/annotation-glossary.html


#720031 


Source: lmdb_0.9.7-1 (21 packages affected)
liblmdb-dev|liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_mt_dbflag.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_txn.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_cursor.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_node.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_page.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_todo.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_debug.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_dbi_open.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_env.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_put.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/midl.c.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_Version.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/midl.h.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_compat.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_errors.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_idls.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_lmdb.h.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_readers.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb.c.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb.3.gz
liblmdb-dev|0.9.7-1|./usr/share/man/man3/mdb_internal.3.gz


#723665


Source: shibboleth-sp2_2.5.2+dfsg-2 (1 package affected)
libshibsp-dev|2.5.2+dfsg-2|./usr/include/shibsp/paths.h


#720036


Source: db5.3_5.3.21-2 (1 package affected)
libdb5.3|5.3.21-2|./usr/share/doc/libdb5.3/build_signature_amd64.txt


#720029


Source: db6.0_6.0.19-3 (1 package affected)
libdb6.0|6.0.19-3|./usr/share/doc/libdb6.0/build_signature_amd64.txt


#720030


Source: ruby2.0_2.0.0.299-2 (1 package affected)
libruby2.0|2.0.0.299-2|./usr/lib/ruby/gems/2.0.0/specifications/default/io-console-0.4.2.gemspec


#724974

--
Jakub Wilk


--
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/20131028121738.ga1...@jwilk.net

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

[Rene Engelhard]

Hi,

On Fri, Oct 25, 2013 at 08:32:23AM -0700, Clint Byrum wrote:
> As some of you may know, I've been doing the bulk of the package
> maintenance on the mysql package for a while now. It started as part of
> my day job with Canonical, but since leaving Canonical it has been more
> a labor of love for Debian.
[...]
> I am asking you, the Debian developers, to step up and help. I am
> basically unable to contribute more than an hour a month now. There is a
> new round of secret CVE bugs to fix, and some old bugs that need to be
> handled. I think my October hour is about to be available, so I might
> be able to address those, but after that, if I don't get any more help,
> I'm done.
> 
> What can you do to help?
> 
> - Raise your hand and say you'll help

*raises hand*. 
I am not sure how much because LibreOffice keeps me busy at times, but I would
like to help in  the other time.

> - Perhaps help us do this right (I suspect I should have an RFH bug)
> - Join #debian-mysql on OFTC
> - Join the alioth team and request svn access
> - Triage bugs (src:mysql-5.5 and for oldstable src:mysql-5.1)
> - Help package the latest patch releases from Oracle
> - Help with MariaDB (James Page and Otto, thanks for doing this btw!)
> - Help us migrate to git

I am not sure because LibreOffice keeps me busy at times, but I would
like to help.

Regards,

Rene


-- 
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/20131028121911.gf29...@rene-engelhard.de

Re: Please assume good faith

[David Kalnischkies]

On Sat, Oct 26, 2013 at 4:31 AM, Nikolaus Rath  wrote:
> David Kalnischkies  writes:
>> On Fri, Oct 25, 2013 at 11:31 PM, Nikolaus Rath  wrote:
>>> Thorsten Glaser  writes:
 Lars Wirzenius  liw.fi> writes:
> I write a backup program. It uses its own storage format, and people
> sometimes ask if they could use tar files instead. But I am evil
> incarnate and FORCE them to use my own storage format instead. Should
 […]
> can be, and I think that the storage format I've developed is better
> than storing backups in tar files. I truly, deeply feel that using my
> format makes the program better, and that offering tar as a choice
> would be pretty much disastrous, because almost all of the features I

 This *is* bad because if there is an existing userbase with tar (which
 isn’t true in the obnam case, sure, but would be true if you were to
 try forbidding all other backup programs in Debian) this will break
 their use cases, and *that* is what the systemd situation is all
 about.
>>>
>>> I don't understand this point of view. Even if there is an existing
>>> userbase, I don't think that would obligate me (as the author) in any
>>> way to support them in the future. […]
>>
>> You are not forced of course, but if you have (or aim to have) a userbase
>> consisting of more than just a few people you might want to consider to not
>> alienate them because you are a nice fellow (or aim to be one).
>
> Yes, that's certainly what I do in practice. But I do not understand how
> you make the jump from this to:
>
>> That isn't meant to be advocating to never change anything, but you better
>> have really really really good reasons to do it OR you accept that people
>> start to distrust you and avoid you like the plague even if you have
>> invented the cure for the common cold this time.
>
> Is that really how you'd feel toward me if I stopped working on a piece
> of software? By being nice to you for a limited time I get your distrust
> and avoidance afterwards? I don't think that's a healthy attitude for
> open source, because it means that if you want to get along with people,
> you better not release any of your code in the first place (at least
> everyone will still be neutral to you then).

Maybe. The difference is how you have communicated what your software is
supposed to achieve. "Just scratching my own itch here" is far different
from "all your base are belong to us".

You say later on that APT is doing what you need. Would you like that to
change? Do you really think you could use an old version for long?
(lets be crazy and announce that apt is hard-depending on bsd jails now)
If you think trust isn't a healthy 'currency' in volunteer communities I
wonder what you are using…

I have the luxury of being able to delegate such (to me) ultimately boring
decisions like which init system is allowed to start my tiling window
manager to others I trust and are far more capable in that area. Others
on this list obviously can't or we wouldn't have such a battle, so it
might be interesting to find an answer why they can't and learn from it
(beside from those who think fighting is fun maybe).

As usual: "War does not determine who is right – only who is left."


>> And based on that we don't have enough people to maintain one APT¹, I doubt
>> you find enough for two, so a "just fork it" sounds nice in theory, but
>> just because you have a million users doesn't mean you have a million
>> developers willing to work on it…
>
> No, but that's really a problem (or non-problem) of the millions of
> users. If no one is interested in working on apt, isn't that a sign that
> apt is really good enough for most of its millions of users?
>
> At least this is the reason that I'm not working on apt. For me it works
> perfectly, so I spend my time working on things that really bug me
> rather than working on apt.

That is nice to hear, but given that the answer to the question which package
owned the last two open RC-bugs against Debian wheezy and which one has the
most open bugreports in general in the BTS is "apt" I somehow doubt its true
for everyone around here.

Its more a sign for a) capable contributors believing that they have to
be deities (pun intended) to work on APT, b) users trusting that those
deities are not stabbing them in the back and c) the universal hope for
having always at least one more active deity than deities hit by a bus…
Lets just hope that works out just as 'well' as it does for other teams.


Best regards

David Kalnischkies


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

Re: systemd effectively mandatory now due to GNOME

[Olav Vitters]

On Sun, Oct 27, 2013 at 07:12:21PM -0400, The Wanderer wrote:
> (As far as I can tell this is the actual root of the problem, at least
> for this iteration of the argument: the fact that logind now requires
> systemd.)

That's due to cgroups change. There seem to be 2 other potential
implementations of the same cgroups daemon. Once they're a bit mature
and if technically feasible, (no clue) it might be an idea to just push
for making logind work with *a* cgroups manager. Not just systemd. But
logind was never meant to be separate, so not sure how future proof that
would be.

>From GNOME side, we're ok for pushing for something like this. But then
someone first needs to make it feasible and support it. To be really
clear: bulk of work should be done outside of GNOME/systemd.

> >* Gnome is said to work fine even on platforms that don't have
> >systemd installed. Does this mean that systemd is optional?
> 
> My understanding from what I've read is that it "works fine" except in
> that the features which the ConsoleKit-or-logind dependency provides
> aren't available. That's derived from indirect statements from several
> people in various parts of the discussion; if I'm wrong on that, someone
> please correct me.

We still support ConsoleKit, but GNOME without systemd results in less
features unless you maintain those parts yourself. Gentoo recently
decided that was too basic and didn't want to maintain choice themselves.
This meant that they see GNOME requiring systemd. It is kind of
unfortunate the delay in feedback from various distributions from
upstream work+decisions. E.g. Gentoo decided this based on GNOME 3.8
integration, while we released 3.10 and now focussing on 3.12.

-- 
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/20131028122604.ga2...@bkor.dhs.org

Re: let's split the systemd binary package

[Olav Vitters]

On Sat, Oct 26, 2013 at 12:14:57AM +0100, Kevin Chadwick wrote:
> > E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit,
> > you'll notice it is NOT maintained.
> 
> XFCE *needs* neither and in fact the vast vast majority of users do
> not either.

I check the spec files for Fedora, Mageia, openSUSE. They all seem to
require logind. For Arch, seems as well, but not sure (difficult to
verify). For Debian it is a recommends.

Needs neither seems to be true based on the recommends, but "vast
majority" seems incorrect. I do wonder what breaks though :P

-- 
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/20131028122854.gb2...@bkor.dhs.org

Re: systemd effectively mandatory now due to GNOME

[Tollef Fog Heen]

]] Brian May 

> On 28 October 2013 07:52, Tollef Fog Heen  wrote:
> 
> > >  - /lib/udev/rules.d/99-systemd.rules - udev rules that will be active on
> > >any system with /sys/fs/cgroup/systemd present (because of logind,
> > this
> > >directory is not a good proxy for whether pid1 == systemd).
> >
> > That's a bug that it checks for the wrong directory.  That's a trivial
> > bugfix to change.
> 
> Has a bug been reported? Does a bug need to be reported for this to get
> fixed?

I've committed a fix for this to the git repo so it'll be part of the
next upload.  No need to report a bug.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/8761shy106@qurzaw.varnish-software.com

Re: Jessie release goal: DNSSEC as default recursive resolver

[Adam Borowski]

On Mon, Oct 28, 2013 at 01:01:13PM +0100, Thijs Kinkhorst wrote:
> On Sat, October 26, 2013 18:52, Ondřej Surý wrote:
> > we can adopt dnssec-trigger
> 
> I think it's indeed very important that a default install uses the DHCP
> provided DNS-servers or locally configured resolvers, because in many
> networks that's the only way to reliably resolve things. dnssec-trigger
> may provide that

It might be worse.  Some ISPs use an equivalent of:
iptables [...] --dport 53 -j REDIRECT (or DNAT)
to answer all queries locally.  Reasons vary: reigning in Androids
hard-coded for 8.8.8.8, censorship, hijacking NSDOMAIN for ads, etc.

My personal story: years ago, a local garden-variety ISP (~300 users) had a
problem because of computer shop which, in machines sold or repaired there,
set DNS settings to those of a national near-monopoly ISP (for some cargo
cult reasons).  Then, one day, that national ISP turned off recursion for
outside IPs.  "Teh internet broke".  The local ISP's guys came to me, as
blaming the computer shop would end up just in losing customers because
"your internet doesn't work and you lie blaming others -- easily proven
by connecting that computer elsewhere".  I proposed and implemented the
above redirect which neatly fixed the problem.

It's obvious what will happen if that redirected to DNS server blocks
DS/RRSIG/NSEC/...  queries (like typical crap home routers do).  And even
worse, this scenario is indistinguishable from some actual attacks DNSSEC
guards against.

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


-- 
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/20131028142952.ga8...@angband.pl

Bug#728111: ITP: papyrus -- DICOM compatible file format library

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: papyrus
  Version : 3.7.1
  Upstream Author : UIN
* URL : http://www.expasy.ch/UIN/html1/projects/papyrus/papyrus.html
* License : GPL
  Programming Lang: C
  Description : DICOM compatible file format library

 PAPYRUS 3.0 file format based on the new DICOM 3.0 Standard addresses the open
 interchange of medical images in files or on removable storage media. This
 specific implementation of the DICOM standard is intended as a generic solution
 for interchange of multi-modality medical images on removable media. It can
 also be used for convenient exchange of image data between different computer
 systems through industry standard file transfer mechanisms. Finally it can also
 be used for storage and archival of medical image data in a DICOM compatible
 format.


-- 
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/20131028145849.25970.92230.report...@vostrodell.malat.net

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

[Thomas Goirand]

On 10/27/2013 07:49 AM, Charles Plessy wrote:
> 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.

I don't agree with this view. A lot of the development in Debian is
driven by Canonical as well, and the opinion of Canonical / Ubuntu
counts for me. Having some people from Canonical involve in the vote is
simply representative of the active DDs as well, and what makes Debian
(I'm not sure if it is on the same proportion, but I don't think we
should go that far in this reasoning either...). In other words, *if
there's was* conflict of interest in the voters (I don't think there
is), then we could as well consider that Debian also has a conflict of
interest toward Canonical too, so it wouldn't have been a bad thing
after all.

Though as Didier wrote, I do trust them, I "assume good faith", and will
let them do their best. I also think this is really a bad topic which
shouldn't even have been raised in this list. This is very
disrespectful. It has been fed by trolls who aren't doing anything in
Debian and who are used to do such things in other communities (yes,
Uoti, I'm pointing at you... among others). And it has gone a way too
far already.

No doubt that the tech-ctte is facing a very difficult decision, maybe
one of the hardest in the history of that entity. It is now obvious to
me that there is no good answer to the problem we are facing, and that
the tech-ctte decision, whatever it will be, wont satisfy everyone. So I
just hope that everyone will realize that, and respect whatever decision
they will take.

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/526e7f29.7050...@debian.org

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

[Ian Jackson]

Joey Hess writes ("Re: [ANNOUNCE] git-deb: a Git importer for Debian packages"):
> Note that you can use dgit clone any package without being a Debian
> developer. You only need an alioth account in order to dgit push.

Sadly this is not true.  The reason is that the information dgit needs
is only available by sshing into a machine with access to the
ftpmaster database (!)

The information needed by dgit should be public, but is not.

Ian.


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

SD cards (was Re: Proposal: switch default desktop to xfce)

[Thorsten Glaser]

Luca Capello  pca.it> writes:

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

Right, but that’s not an excuse to not boot from it. After all,
hda, sda, xvda, vda, mmcblk0, etc. are not usually connected to
a USB bus, either.

(I think this ends this sub-thread, there’s nothing we can do
about it after all, just for completeness. Followup-To: poster)

bye,
//mirabilos


-- 
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/loom.20131028t180633-...@post.gmane.org

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

[Thorsten Glaser]

Lucas Nussbaum  debian.org> writes:

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

I agree.

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

In my perception, it’s the other way round: a CTTE decision will be
seen as dictated from a small group, and the possible conflict of
interest has been raised, no matter whether it indeed matters in
the CTTE decision or not, people are saying it’s fishy.

On the other hand, a majority decision (well, one that wins by the
Condorcet method) will also disagree with some amount of DDs, but
is at least somewhat base-democratic, and every DD will be able to
affect the outcome. (Maybe not everyone should, but people who know
absolutely nothing about the subject of an election should just not
vote then.)

So I think that people would rather grudgingly accept a GR outcome
but not accept a CTTE decision on something like this that easily.

Also, why have people been shying back from GRs like they are a
plague? They are a good, and _the_, way to ask the people that
make up Debian for their opinion. As someone else said in one of
these threads: they don’t eat babies. I think “base democracy” is
a much lesser evil than “parlamentarian democracy” (even if both
usually end up beating minorities).

Finally, I believe strongly that the CTTE request is badly worded,
because the decision on whether we require support for more than
one (the “default”) init system must be decided either before or
at the same time as the default is going to be decided. With a GR,
I could express it as ordered preferences (for example, preference
for “support them all”, before sysvinit-only, before upstart-only,
before NOTA, before systemd-only).

This is strong enough that I’d like to see the CTTE outcome that
they suggest doing the GR after all (which would _also_ remove
the Canonical issue-or-maybe-not from peoples’ minds).

(Also, do remember that any decisive outcome other than “support
multiple ones including systemd” and “systemd-only” will need to
lead to the removal of GNOME from Debian. I won’t miss it, but
just saying.) Whatever CTTE and, maybe, the DDs voting in the GR
should it be done, do, it’ll change Debian as we know it, I’d say.

bye,
//mirabilos


-- 
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/loom.20131028t181513-...@post.gmane.org

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

[Ian Jackson]

Thorsten Glaser writes ("Re: Bug#727708: tech-ctte: Decide which init system to 
default to in Debian."):
> Finally, I believe strongly that the CTTE request is badly worded,
> because the decision on whether we require support for more than
> one (the “default”) init system must be decided either before or
> at the same time as the default is going to be decided. With a GR,
> I could express it as ordered preferences (for example, preference
> for “support them all”, before sysvinit-only, before upstart-only,
> before NOTA, before systemd-only).

The TC certainly won't restrict ourselves to choosing between the
options from the two main current camps.

If you would like to make a counterproposal, please do go to the
Debate page on the wiki and set out what you think should be done and
why.

Ian.


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

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

>  you need something with big buttons
> that is finger-friendly, 

I'm surprised how much accuracy a capacitive multitouch mobile has when
in touchscreen terms it is actually extremely poor (3-4mm) exacerbated
by them not responding to nails (conductive), a trade-off for size and
multitouch. Many have much better accuracy (infra-red, resistive) and
certainly will have multitouch too in the future. Websites having big
buttons represented by tiny ones visually on Android is certainly true
due to this.

> My conclusion is that the right UI to choose is quite machine-specific
> and also user-specific.

The 10 touch Baanto has very good accuracy ( < mm) and is an example of
an external infra-red that actually doesn't work with Linux due to an
indirectly related bug last time I checked even though it is alleged to
by Baanto.

Some accurate single touch resistive touches also work as a standard
mouse though they require detection and the movement being inverted,
but it would be a very simple driver. The supplier had died but it
seems to have been revived recently.

-- 
___

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

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

[Ian Jackson]

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

If you're counting me in those 3, I would like to clarify something.

As everyone knows, I left Canonical a number of years ago.  I quit,
after a number of disagreements (some public, but many more private)
with some of the senior staff, because of some very unfortunate
behaviour by my management at Canonical.  Obviously this is not the
kind of thing one makes a lot of noise about, but much of what
happened was no fun for me at all and I'm certainly no Canonical
shill.

For what it's worth, I have complete confidence in Steve and Colin.
(I have known Colin for a very long time as a friend, from well before
either of us got involved with Canonical.)

Ian.


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

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

[Neil McGovern]

On Mon, Oct 28, 2013 at 05:23:33PM +, Thorsten Glaser wrote:
> Also, why have people been shying back from GRs like they are a
> plague? They are a good, and _the_, way to ask the people that
> make up Debian for their opinion. As someone else said in one of
> these threads: they don’t eat babies. I think “base democracy” is
> a much lesser evil than “parlamentarian democracy” (even if both
> usually end up beating minorities).
> 

Debian is not a democracy. See, amongst others:
http://www.debian.org/doc/manuals/developers-reference/developer-duties#voting
https://www.google.co.uk/search?q=debian+is+not+a+democracy

Neil
-- 


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> Right.  Whichever init system we pick, I do expect the next step to be to
> drop the requirement to maintain sysvinit backwards-compatibility;

While I'm not sure from your mail whether you meant to suggest otherwise, I do
think that whatever we decide for jessie, we should continue the requirement of
sysvinit compatibility for at least one release after we ship with some more
modern init system.

Also, since all alternative init implementations under consideration do
support sysv-style init scripts, I think that whatever init system we
(well, you, the TC) end up choosing, the requirement in policy should be
that a package should ship either some init configuration for the
default init system, or a sysv-style init script. In fact, I think we
should continue to encourage the latter, in cases where it does make
sense (e.g., when a given daemon doesn't have any init system specific
features that could be enabled), since that will help our non-Linux
ports without significantly impacting performance of the new init
system.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/20131028172214.ga11...@master.debian.org

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

[Alexander Wirt]

Wouter Verhelst schrieb am Monday, den 28. October 2013:

> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right.  Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;
> 
> While I'm not sure from your mail whether you meant to suggest otherwise, I do
> think that whatever we decide for jessie, we should continue the requirement 
> of
> sysvinit compatibility for at least one release after we ship with some more
> modern init system.
> 
> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.
It will also make backporting much easier.

Alex
 


-- 
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/20131028174046.gc9...@hawking.credativ.lan

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

[Thorsten Glaser]

Stefano Zacchiroli  debian.org> writes:

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

This means that you just don’t vote if you don’t know about it,
it doesn’t mean that polling among these who know is bad.

> 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 this specific case, what’s “related packages”? For example, if I want
to insist that sysvinit keeps being supported, but the GNOME people still
hard-depend on systemd, and neither side would possibly let me “in”… this
“just work on it” is, in reality, not possible. (Also, I have no interest
in working on either GNOME or systemd, I just want them to not intrude on
“my soil” and don’t want to intrude on theirs, unless – which they (they
seem to blend together, anyway) currently do – they tread on mine.)

Things like this are *not* technical issues that can easily be solved
by submitting patches.

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

Not as badly worded as currently. But I assume CTTE would collect
arguments, possibly from this thread. That’s why I’ve agreed to
wait, even though several others would support the GR right now.

bye,
//mirabilos


-- 
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/loom.20131028t182608-...@post.gmane.org

Re: Proposal: switch default desktop to xfce

[Wouter Verhelst]

Op 25-10-13 14:45, Adam Sampson schreef:
> Steve McIntyre  writes:
> 
>> We *could* just drop all the CD sets and be done with it, just keeping
>> the netinst CD and the DVDs. Is that what people really want?
> 
> As a longtime Debian user, that would suit me fine -- I've not done a
> Debian installation using anything other than netinst (or debootstrap)
> in years.
> 
> I'd be interested to know what the use cases for the full stack of CDs
> currently are...

The last time I used the full stack of CDs where there was no decent
alternative option was when I was helping a customer prepare a set of
installation instructions for a code escrow situation.

Since one of the requirements there was the ability to produce a 100%
bit-for-bit equal system, anything that used "download the current
version from the Internet" was out -- we had to provide actual media
(CDs, at the time).

That was over five years ago, though. Today, I doubt I'd still try to
use CDs, probably at least DVDs instead.

Having said that, I do think that providing a limited number of CD
install images is useful for those cases of retrocomputing where
installing off DVD is difficult. Other than that...

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/526ea410.5090...@debian.org

Re: Proposal: switch default desktop to xfce

[Kevin Chadwick]

> > OK. I suggest that we *try* that for now.  
> 
> If we try, what will be the criteria for assessing whether the
> experiment has been successful (and hence worth keeping for Jessie) or a
> failure (and hence reverting it)?

I think it should be considered that there has been much improvement
upto 4.10 and 4.11 even has some useful multi desktop improvements
(above and below) so it would be better if 4.10 or higher was the
assessed version.

-- 
___

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

Re: Proposal: switch default desktop to xfce

[Olaf Titz]

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

You would surely make _your app_ unsuitable for use as a default.

Olaf


-- 
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/e1vaql1-0001z1...@bigred.inka.de

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

[Thomas Goirand]

On 10/28/2013 06:28 PM, Jakub Wilk wrote:
> * Thomas Goirand , 2013-10-25, 23:45:
>> OpenRC has been waiting in the NEW queue (targeting experimental, as
>> this is what it is right now: experimental!) for more than a month.
>> It'd be nice if someone from the FTP master team could review it, so
>> that at least others can try it.
> 
> IANA ftp-master, but here's my quick review:
> 
> Please rename /sbin/rc to something else. We've had (unrelated)
> /usr/bin/rc in Debian for at least 18 years.

Outch! This bites hard. Maybe you being the maintainer of the "rc"
package is why you saw this immediately! :)

Though that's annoying, because upstream must extensively uses "rc". All
OpenRC commands are in fact using /sbin/rc. For example, /bin/rc-status
(which shows what  is a symlink to /bin/rc, and then /sbin/rc finds out
that it has been called by using /bin/rc-status, so it prints the status.

I'm not sure how hard it will be to fix, though I don't expect it's
going to be just-a-simple-rename... :(

> What is the rationale for the binary-or-shlib-defines-rpath override?

Probably OpenRC doesn't work if that isn't done, because it is loaded
very early in the boot process (I'm really not so sure about this one,
it would need more investigation, and I always delayed that one...).

Thomas


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

Re: Proposal: switch default desktop to xfce

[Wouter Verhelst]

Op 25-10-13 12:10, Thomas Goirand schreef:
> On 10/25/2013 07:52 AM, Paul Wise wrote:
>> On Fri, Oct 25, 2013 at 7:47 AM, Christoph Anton Mitterer wrote:
>>
>>> Debian is the "Universal OS", isn't it?
>>
>> Part of being a 'Universal OS' is being useful to as many people as
>> possible, including people who don't know what a "desktop" is and
>> people who don't have the ability to choose a desktop. Artificially
>> limiting the range of people exposed to, using or working on Debian
>> isn't a good idea.
> 
> It's not as if those users would just stay, stuck on the screen forever,
> then give-up installing Debian because they don't know what to answer.
> They will eventually choose an option, and move on to the next screen,
> even if they don't understand what they are doing.

There's a limited number of times people are prepared to do that ("move
on without understanding what they're doing") before they will give up
and move on -- either to another distribution, or away from Linux
entirely. That can't be the goal.

We do need a default desktop, and I happen to think that having several
"variants" of Debian ("Debian Gnome", "Debian KDE", "Debian XFCE", etc,
rather than "KDE alternate CD 1", which is somewhat more involved and
therefore less clear for non-native speakers) that only differ in their
default choice of desktop would be a feature, not a bug. We can then
make the "choice of default desktop" be something as simple as a symlink
(or equivalent) on our download pages.

I do agree with Russ that several people do not seem to understand that
the difference between "kubuntu" and "xubuntu" is no more than the
default set of packages -- in fact, I've had to explain that fact
several times to different customers.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/526ea941.7080...@debian.org

Re: let's split the systemd binary package

[Kevin Chadwick]

> > > E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit,
> > > you'll notice it is NOT maintained.  
> > 
> > XFCE *needs* neither and in fact the vast vast majority of users do
> > not either.  
> 
> I check the spec files for Fedora, Mageia, openSUSE. They all seem to
> require logind. For Arch, seems as well, but not sure (difficult to
> verify). For Debian it is a recommends.
> 

So all the systemd using Distro's!

How about Gentoo, Slackware, LFS and many many others?

> Needs neither seems to be true based on the recommends, but "vast
> majority" seems incorrect. I do wonder what breaks though :P

By vast majority I was meaning user requirements and not distro
packagers expectations, user requirements is actually the metric which
should count the most and most users do not need session tracking, it
can actually get in the way (one user using many logins, shutdown, usb
access etc.).

User requirements are normally automatically reflected by unix
developers but RedHats enterprise requirements and extensive dev time
have the potential to swing that even if they rectify it from time to
time.


p.s. Whoever decided to use non unique names in gdm over unique
usernames for user selection must have had a strange thought process
going on.

-- 
___

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

Re: Proposal: switch default desktop to xfce

[Wouter Verhelst]

Op 25-10-13 15:43, Olav Vitters schreef:
> On Fri, Oct 25, 2013 at 01:41:23PM +0100, Neil Williams wrote:
>> There is no good reason other than "that's the way GNOME has been
>> written". So change the code and get GNOME to behave properly.
> 
> Because you raise this again:
> - No maintenance on ConsoleKit since 1.5 years, despite me/GNOME raising
>   this as an issue end of Jan 2012
> - XFCE relies on either ConsoleKit or logind
> 
> Concretely, who will "change the code"? I mean a name and something in
> the git log of ConsoleKit (or fork it and call it something else).

What's wrong with "whoever needs this fooKit thing, whatever it is"?
Deciding to drop support for "code I don't personally use, but other
people depend on" is just wrong on so many levels.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/526eacee.4000...@debian.org

Re: Jessie release goal: DNSSEC as default recursive resolver

[Thomas Goirand]

On 10/28/2013 10:29 PM, Adam Borowski wrote:
> On Mon, Oct 28, 2013 at 01:01:13PM +0100, Thijs Kinkhorst wrote:
>> On Sat, October 26, 2013 18:52, Ondřej Surý wrote:
>>> we can adopt dnssec-trigger
>>
>> I think it's indeed very important that a default install uses the DHCP
>> provided DNS-servers or locally configured resolvers, because in many
>> networks that's the only way to reliably resolve things. dnssec-trigger
>> may provide that
> 
> It might be worse.  Some ISPs use an equivalent of:
> iptables [...] --dport 53 -j REDIRECT (or DNAT)
> to answer all queries locally.  Reasons vary: reigning in Androids
> hard-coded for 8.8.8.8, censorship, hijacking NSDOMAIN for ads, etc.
> 
> My personal story: years ago, a local garden-variety ISP (~300 users) had a
> problem because of computer shop which, in machines sold or repaired there,
> set DNS settings to those of a national near-monopoly ISP (for some cargo
> cult reasons).  Then, one day, that national ISP turned off recursion for
> outside IPs.  "Teh internet broke".  The local ISP's guys came to me, as
> blaming the computer shop would end up just in losing customers because
> "your internet doesn't work and you lie blaming others -- easily proven
> by connecting that computer elsewhere".  I proposed and implemented the
> above redirect which neatly fixed the problem.
> 
> It's obvious what will happen if that redirected to DNS server blocks
> DS/RRSIG/NSEC/...  queries (like typical crap home routers do).  And even
> worse, this scenario is indistinguishable from some actual attacks DNSSEC
> guards against.

Gosh... This makes me think about China Telecom adding their own
advertizing on sites you visit and that they don't control, by adding
some broken javascript using their "transparent" proxy server... (not
sure if they continue to do this crap). :(

So, as per the replies we've read, it seems that the only way to
implement DNSSEC would be to first check if it works, and if it doesn't,
fallback to the locally provided recursive DNS server. And that must be
considering the use case where we do a setup in an environment where
DNSSEC works, then the laptop is plugged in one of these broken
networks, and the local resolver doesn't anymore. Otherwise our users
would blame Debian on this (for the same reason that above, you wouldn't
blame the repair shop...).

So, all this leads to believe we'd need a simple way to be able to
switch between a local DNSSEC enabled recursive resolver and a
my-isp-is-broken-provided-DNS. This can't be transparent to the user,
otherwise, what's the point of having DNSSEC if we don't know if it's
activated or not?

So at the end, I'm thinking (out loud): the only way would be to have
the desktop to show if DNSSEC is activated or not. Something like a
$desktop-applet or something. Has anyone ever wrote such software?

Thomas


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

Re: let's split the systemd binary package

[Andrey Rahmatullin]

On Mon, Oct 28, 2013 at 05:58:16PM +, Kevin Chadwick wrote:
> How about Gentoo, Slackware, LFS and many many others?
What's that?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

[Wouter Verhelst]

Op 25-10-13 19:32, Sune Vuorela schreef:
> Why not consolidate on shared code rather than having several bits
> providing the similar functionality for fairly simple tasks ?

That's a (very!) fair argument, but there's nothing in that argument
which means it absolutely totally *has* to be part of a pid1

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/526eafeb.3010...@debian.org

Re: Jessie release goal: DNSSEC as default recursive resolver

[Kevin Chadwick]

> So, as per the replies we've read, it seems that the only way to
> implement DNSSEC would be to first check if it works, and if it doesn't,
> fallback to the locally provided recursive DNS server.

I still think a switch on/off (whatever the default) should be
considered because if anyone decides to depend on the (limited) trust
but trust all the same that DNSSEC provides then the fact that it falls
back to an untrusted mechanism when it can be easily DOS'd may lead to a
false sense of security which is worse than no security.

-- 
___

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

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

[Olav Vitters]

On Mon, Oct 28, 2013 at 05:23:33PM +, Thorsten Glaser wrote:
> (Also, do remember that any decisive outcome other than “support
> multiple ones including systemd” and “systemd-only” will need to
> lead to the removal of GNOME from Debian. I won’t miss it, but
> just saying.) Whatever CTTE and, maybe, the DDs voting in the GR
> should it be done, do, it’ll change Debian as we know it, I’d say.

The init system is just the first in various questions that needs
answering. Ubuntu uses Upstart and GNOME runs on Ubuntu. The problem is
the ConsoleKit vs logind (among others). The init system is related to
this, but not the same. You could choose Upstart and reimplement logind.

I find the continuous framing of ConsoleKit vs logind as "init system"
problem to highlight that a technical answer is needed. People who look
at the implications and provide a technical answer for that as well.
Currently if you only think of this as an "init system" issue, then you
could go for whatever; sysvinit, OpenRC, Upstart, systemd, etc.

At the moment the lack of making any decision means that things are
decided for you. E.g. from what I've been reading (and I could have this
totally wrong):
- Kwin might support Wayland by being a Weston plugin
- logind will soon contain VT switching logic
- Weston will soon depend on (unreleased) logind (for VT switching)

The question is not really about the init system, it is various other
bits. ConsoleKit maintenance for instance. Provide maybe an alternative
for logind and you make things a bit easier.

That a few people from the technical committee are from Canonical is IMO
logical. Obviously Canonical will have influence and people are biased.
Bias to me is just preferring something. I think it would be good to
have a well researched answer. I like the phrase "best decision at the
time". Sometimes it is better to choose the best *now* instead of doing
nothing. That maybe a long time later you would've made a different
decision is usually worth it.

-- 
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/20131028184450.ga25...@bkor.dhs.org

Re: Proposal: switch default desktop to xfce

[Olav Vitters]

On Mon, Oct 28, 2013 at 07:41:47PM +0100, Wouter Verhelst wrote:
> That's a (very!) fair argument, but there's nothing in that argument
> which means it absolutely totally *has* to be part of a pid1

Most of systemd is not in pid1. This was explained by a blog references
on debian-devel a while ago.

-- 
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/20131028184643.gb25...@bkor.dhs.org

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

[Kevin Chadwick]

> since that will help our non-Linux
> ports

and embedded Linux, especially deep embedded systems such as cortex and
blackfin which is coming along fairly nicely 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/8034.2587...@smtp127.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

[Olav Vitters]

On Mon, Oct 28, 2013 at 07:29:02PM +0100, Wouter Verhelst wrote:
> Op 25-10-13 15:43, Olav Vitters schreef:
> > On Fri, Oct 25, 2013 at 01:41:23PM +0100, Neil Williams wrote:
> >> There is no good reason other than "that's the way GNOME has been
> >> written". So change the code and get GNOME to behave properly.
> > 
> > Because you raise this again:
> > - No maintenance on ConsoleKit since 1.5 years, despite me/GNOME raising
> >   this as an issue end of Jan 2012
> > - XFCE relies on either ConsoleKit or logind
> > 
> > Concretely, who will "change the code"? I mean a name and something in
> > the git log of ConsoleKit (or fork it and call it something else).
> 
> What's wrong with "whoever needs this fooKit thing, whatever it is"?
> Deciding to drop support for "code I don't personally use, but other
> people depend on" is just wrong on so many levels.

GNOME has not removed support for ConsoleKit. Without continued
maintenance a project will die. Plus this code will bitrot if not
properly maintained.

So to paraphrase what you said: GNOME is right on so many levels. :P

-- 
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/20131028185008.gc25...@bkor.dhs.org

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

[Christoph Anton Mitterer]

For those who haven't seen it, Lennart has posted some of his comments
about all this on G+:
https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: let's split the systemd binary package

[Olav Vitters]

On Mon, Oct 28, 2013 at 05:58:16PM +, Kevin Chadwick wrote:
> > > > E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit,
> > > > you'll notice it is NOT maintained.  
> > > 
> > > XFCE *needs* neither and in fact the vast vast majority of users do
> > > not either.  
> > 
> > I check the spec files for Fedora, Mageia, openSUSE. They all seem to
> > require logind. For Arch, seems as well, but not sure (difficult to
> > verify). For Debian it is a recommends.
> > 
> 
> So all the systemd using Distro's!
> 
> How about Gentoo, Slackware, LFS and many many others?
> 
> > Needs neither seems to be true based on the recommends, but "vast
> > majority" seems incorrect. I do wonder what breaks though :P
> 
> By vast majority I was meaning user requirements and not distro
> packagers expectations, user requirements is actually the metric which
> should count the most and most users do not need session tracking, it
> can actually get in the way (one user using many logins, shutdown, usb
> access etc.).

You said vast vast majority, you do the work! At the moment it seems
you're just changing goalpost as you go along. I don't play such games.
I showed I did research on what I understood. If you are so sure about
the needs of the "vast vast majority", it is up to *you* to show proof.
I'm not interested though.

-- 
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/20131028190319.gd25...@bkor.dhs.org

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

[Kevin Chadwick]

> > 
> > IANA ftp-master, but here's my quick review:
> > 
> > Please rename /sbin/rc to something else. We've had (unrelated)
> > /usr/bin/rc in Debian for at least 18 years.  
> 
> Outch! This bites hard. Maybe you being the maintainer of the "rc"
> package is why you saw this immediately! :)
> 
> Though that's annoying, because upstream must extensively uses "rc". All
> OpenRC commands are in fact using /sbin/rc. For example, /bin/rc-status
> (which shows what  is a symlink to /bin/rc, and then /sbin/rc finds out
> that it has been called by using /bin/rc-status, so it prints the status.
> 
> I'm not sure how hard it will be to fix, though I don't expect it's
> going to be just-a-simple-rename... :(

Could this problem be explained. As long as they are in separate
directories and called explicitly does that matter?

Is it because on BSD, binaries in /sbin would be found if just rc
rather than /usr/bin/rc was used?

-- 
___

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

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

[Mirosław Baran]

Christoph Anton Mitterer  wrote:
>For those who haven't seen it, Lennart has posted some of his comments
>about all this on G+:
>https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf

And the RH PR circus has already started around it.

Lennart's g+ note is written in his usual half-truth/half-omission mode. Not 
helpful at all.

– jubal


-- 
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/04eff1e2-e227-4e7c-8c7d-defcf62f2...@email.android.com

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

[Christoph Anton Mitterer]

On Mon, 2013-10-28 at 19:23 +, Mirosław Baran wrote:
> And the RH PR circus has already started around it.
> Lennart's g+ note is written in his usual half-truth/half-omission mode. Not 
> helpful at all.
I guess just stating something like this, without real technical
arguments why he is wrong or tells half-truth... is probably not much
better anti-systemd-PR, is it?


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Jessie release goal: DNSSEC as default recursive resolver

[Wouter Verhelst]

Op 28-10-13 19:28, Thomas Goirand schreef:
> So, as per the replies we've read, it seems that the only way to
> implement DNSSEC would be to first check if it works, and if it doesn't,
> fallback to the locally provided recursive DNS server.

This feels upside down to me.

There is nothing in DNSSEC which makes it inherently incompatible with
using DNS forwarders. Talking to the root DNS servers is fun and all,
but there's really no good reason why you shouldn't use the large DNS
cache on your ISP's recursive DNS server.

There's also no reason why you _need_ a local DNS server to be able to
do DNSSEC resolving; you can theoretically use a stub resolver (though
I'm not sure if there's a stub resolver in Debian which supports doing so).

Now, if your local DNS server ignores requests for RRSIG records, or
sabotages DNSSEC in other ways, it might make sense to try to bypass
them, possibly by running a local caching DNS server. But that should
not be the first thing to do.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/526ebe2d.5080...@debian.org

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

[Paul Tagliamonte]

On Mon, Oct 28, 2013 at 07:01:05PM +, Kevin Chadwick wrote:
> Could this problem be explained. As long as they are in separate
> directories and called explicitly does that matter?

Please see the nodejs vs node thread(s).


Cheers,
  Paul

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


signature.asc
Description: Digital signature

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

[Olav Vitters]

On Mon, Oct 28, 2013 at 07:23:11PM +, Mirosław Baran wrote:
> 
> 
> Christoph Anton Mitterer  wrote:
> >For those who haven't seen it, Lennart has posted some of his comments
> >about all this on G+:
> >https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
> 
> And the RH PR circus has already started around it.
> 
> Lennart's g+ note is written in his usual half-truth/half-omission
> mode. Not helpful at all.

Aside from ack that it he really believes in systemd (duh!): I've seen
various technical bits in this Google+ post. I see none in your reply,
only a dismissal.

-- 
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/20131028193740.gk29...@bkor.dhs.org

Re: let's split the systemd binary package

[Kevin Chadwick]

> You said vast vast majority, you do the work! At the moment it seems
> you're just changing goalpost as you go along.

Not at all. I meant functions of a desktop that the average users use
all along.

So the vast vast majority of users such as laptop users do not need
session tracking but may want suspend, but that is not a big issue at
all to fix even without changing any code, just a little config.

I don't see how you confused this from the following myself?
___

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

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


-- 
___

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

(Doug McIlroy)

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


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

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

[Tollef Fog Heen]

]] Thorsten Glaser 

> (Also, do remember that any decisive outcome other than “support
> multiple ones including systemd” and “systemd-only” will need to
> lead to the removal of GNOME from Debian. I won’t miss it, but
> just saying.)

No, it won't necessarily lead to that.  It might just as well lead to
«somebody volunteers to maintain logind outside of the systemd code
base».  Not because they love logind or systemd, but because they love
GNOME and would like it to have the abilities logind gives it.

Nobody has said that's an impossible task.  I've said it's a task I'm
not willing to do, which is not at all the same thing.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m24n81i1xq@rahvafeir.err.no

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

[Kevin Chadwick]

> > >For those who haven't seen it, Lennart has posted some of his comments
> > >about all this on G+:
> > >https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf  
> > 
> > And the RH PR circus has already started around it.
> > 
> > Lennart's g+ note is written in his usual half-truth/half-omission
> > mode. Not helpful at all.  
> 
> Aside from ack that it he really believes in systemd (duh!): I've seen
> various technical bits in this Google+ post. I see none in your reply,
> only a dismissal.

Perhaps this is why Google who use Ubuntu have released their
apparently very good cgroup handler which they have a huge amount
invested in.

I totally agree with the session bus when it is the right tool but the
system bus and especially it's run as root/suid bit (system-services)
going away would actually be a plus for me and many who care about
security.

RedHat said years ago programmers can be guaranteed and depend on the
system bus ALWAYS being available, which is just rediculous!

PID1 may not contain a high percentage of what systemd does but as it
tries to do everything that means nothing, it is still > 10 times the
size (hundreds of kilobytes, who knows how many lines) larger than init
and I'm sure upstart to the point that it takes ages to boot due to cpu
usage on some embedded systems(see the buildroot list). I'll say no
more to prevent the usual "Turing Complete" bullshit argument popping
up but as complex as you choose is a good thing.

-- 
___

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

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

[Kevin Chadwick]

Please lets see what is around the corner before giving merit to
these scare tactics especially for a Gnome desktop whose user base has
and is rapidly declining.


-- 
___

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

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

[Paul Tagliamonte]

On Mon, Oct 28, 2013 at 08:20:28PM +, Kevin Chadwick wrote:

Kevin, please change your tone on Debian lists. Your behavior is
starting to border on malicious. If this continues, I will request that
you get removed from the Debian lists. I'm sure others would join me.

You're showing a lack of respect to your peers on this list.

Change your tone.

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


signature.asc
Description: Digital signature

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

[Tollef Fog Heen]

]] Ian Jackson 

> For what it's worth, I have complete confidence in Steve and Colin.
> (I have known Colin for a very long time as a friend, from well before
> either of us got involved with Canonical.)

To the extent you want to raise a conflict of interest, I believe being
the maintainer of one of the options is a larger conflict of interest
than who signs your paycheck.  (Steve is the upstart maintainer, for
those who didn't know.)

Both Colin and Steve are excellent developers.  I see no need for any of
them to recuse themselves because of their employer.  Whether Steve
should recuse himself due to him being the maintainer of one of the
packages is something I leave to him and the CTTE.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m28uxdi2g9@rahvafeir.err.no

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

[Kevin Chadwick]

> I'll say no
> more to prevent the usual "Turing Complete" bullshit argument popping
> up but as complex as you choose is a good thing.

And I forgot to say you can choose to make the Linux kernel as simple
or complex as you like so taht's another falsity that he should have
allowed comments to contradict on his myths page. 

Much effort has been made to do so and I hope it stays that way or we
won't see debian and Linux on the toasters of the future like we can
have Linux today.

No matter the responses, you will be glad to hear! ;-) I am switching
off now from these threads as I can't afford the time and no-one needs a
repeat of this.

-- 
___

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

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

[Cyril Brulebois]

Kevin Chadwick  (2013-10-28):
> Please lets see what is around the corner before giving merit to these
> scare tactics especially for a Gnome desktop whose user base has and
> is rapidly declining.

Please refrain from continuing with that kind of chatter. It doesn't
really help. Quite the contrary.

(Also, setting an attribution line with the name of the person you're
quoting would be a nice idea.)

KiBi.


signature.asc
Description: Digital signature

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

[Kevin Chadwick]

On Mon, 28 Oct 2013 16:40:09 -0400
Paul Tagliamonte wrote:

> Kevin, please change your tone on Debian lists. Your behavior is
> starting to border on malicious. If this continues, I will request that
> you get removed from the Debian lists. I'm sure others would join me.
> 
> You're showing a lack of respect to your peers on this list.
> 
> Change your tone.

Well if I have offended anyone I apologise as that has not been my
attention and I'm sure you would like me if you met me and realise
this. At the same time I see little point in pussy footing around. I
admit some of the pro systemd arguments got me more wound up than
they should have yesterday.

I would also have thought that a debian developer swearing at me off
list is hardly respecting your peers either and of more concern than
my 'TONE'.

'Keep it technical is a very good point though' and also brought up off
list. It just get's a bit tiresome to include it when you have done it
before.


-- 
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/92224.823...@smtp106.mail.ir2.yahoo.com

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

[Paul Tagliamonte]

On Mon, Oct 28, 2013 at 08:43:13PM +, Kevin Chadwick wrote:
> Well if I have offended anyone I apologise as that has not been my
> attention and I'm sure you would like me if you met me and realise
> this.

I have no doubt, and I wasn't offended, I'm just growing tired of your
disrespect for others.

> At the same time I see little point in pussy footing around.

I mean, no offense, but I've never seen you involved in Debian before
now, which means, you likely don't understand some of the subtle
cultural and social aspects. I get this. Don't assume you know
everything.

> I admit some of the pro systemd arguments got me more wound up than
> they should have yesterday.

Indeed.

> I would also have thought that a debian developer swearing at me off
> list is hardly respecting your peers either and of more concern than
> my 'TONE'.

I said your peers. I don't claim that DDs have the most respect for
others, and I try to call everyone (regardless of membership) on their
shit tone on MLs.

> 'Keep it technical is a very good point though' and also brought up off
> list. It just get's a bit tiresome to include it when you have done it
> before.

Perhaps a sign you've said all you need to.

Cheers,
  Paul

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


signature.asc
Description: Digital signature

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

[Kevin Chadwick]

previously on this list Cyril Brulebois contributed:

> 
> Please refrain from continuing with that kind of chatter. It doesn't
> really help. Quite the contrary.
> 

Fine but whether intended upstream or not, it cannot be argued with as
truth.

> (Also, setting an attribution line with the name of the person you're
> quoting would be a nice idea.)

I don't see why it matters as the reference headers are there and some
even get annoyed (not me) about posting their email address to be
picked up by robots but no problem it wasn't intended to remove it
completely anyway.


-- 
___

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

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

[Steven Chamberlain]

On Mon, 28 Oct 2013 16:40:09 -0400 Paul Tagliamonte wrote:
>> Change your tone.

Then please, try to show a better example of how that is done, instead
of this:

On Mon, 28 Oct 2013 17:07:59 -0400, Paul Tagliamonte wrote:
> I mean, no offense, but I've never seen you involved in Debian before
> [...]
> I try to call everyone (regardless of membership) on their
> s*** tone on MLs.

I think I'd rarely call anyone on anything, but none of Kevin's comments
sounded nearly as rude to me as that.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.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/526ede7a.6030...@pyro.eu.org

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

[Gunnar Wolf]

Kevin Chadwick dijo [Mon, Oct 28, 2013 at 08:43:13PM +]:
> > Kevin, please change your tone on Debian lists. Your behavior is
> > starting to border on malicious. If this continues, I will request that
> > you get removed from the Debian lists. I'm sure others would join me.
> > 
> > You're showing a lack of respect to your peers on this list.
> > 
> > Change your tone.
> 
> Well if I have offended anyone I apologise as that has not been my
> attention and I'm sure you would like me if you met me and realise
> this. At the same time I see little point in pussy footing around. I
> admit some of the pro systemd arguments got me more wound up than
> they should have yesterday.
> 
> I would also have thought that a debian developer swearing at me off
> list is hardly respecting your peers either and of more concern than
> my 'TONE'.
> 
> 'Keep it technical is a very good point though' and also brought up off
> list. It just get's a bit tiresome to include it when you have done it
> before.

Hi Kevin,

I am not personally bothered by your tone per se — But there is a
threshold quite easier to measure: Up to now, in this particular
thread (right now amounting 118 messages), you have posted 11
messages. That is, almost exactly 10% of a very much flamey
thread. That pattern by itself should prompt you to asking whether you
are giving enough thought to the arguments, or just answering in a
trigger-happy fashion.

Thanks for not taking this personally!


-- 
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/20131028224035.gm30...@gwolf.org

Bug#728160: ITP: lime-forensics -- lime-forensics driver, a memory dumper (DKMS)

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: lime-forensics
  Version : 1.1-r17
  Upstream Author : Joe Sylve 
* URL : http://code.google.com/p/lime-forensics
* License : GPL2
  Programming Lang: C
  Description : lime-forensics driver, a memory dumper (DKMS)

 LiME (Linux Memory Extractor, formerly DMD) is a Loadable Kernel
 Module (LKM), which allows the acquisition of volatile memory (RAM)
 from Linux and Linux-based devices, such as those powered by Android.
 In others words, you can use it to get a memory image from a machine.
 .
 The tool supports acquiring memory either to the file system of the
 device or over the network. LiME is unique in that it is the first
 tool that allows full memory captures from Android devices. It also
 minimizes its interaction between user and kernel space processes
 during acquisition. It will produce memory captures that are more
 forensically sound than those of other tools designed for Linux
 memory acquisition.
 .
 This package provides the source code for the lime-forensics kernel
 modules to be build with.dkms.
 .
 Kernel source or headers are required to compile these modules.


-- 
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/20131029002543.12403.4820.report...@libra.gabcmt.eb.mil.br

Bug#728162: ITP: django-oauth2-provider -- Provide OAuth2 access to django application

[Kouhei Maeda]

Package: wnpp
Severity: wishlist
Owner: Kouhei Maeda 

* Package name: django-oauth2-provider
  Version : 0.2.6
  Upstream Author : Alen Mujezinovic
* URL : https://github.com/caffeinehit/django-oauth2-provider
* License : MIT
  Programming Lang: Python
  Description : Provide OAuth2 access to django application

 django-oauth2-provider is a Django application that provides customizable
 OAuth2 authentication for your Django projects.
 The default implementation makes reasonable assumptions about the allowed grant
 types and provides clients with two easy accessible URL endpoints.


-- 
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/20131029003947.7494.89948.report...@vmdeb.cyberagent.co.jp

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

[Russ Allbery]

Wouter Verhelst  writes:

> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.

Well, I've said this before, but I think it's worth reiterating.  Either
upstart or systemd configurations are *radically better* than init scripts
on basically every axis.  They're more robust, more maintainable, easier
for the local administrator to fix and revise, better on package upgrades,
support new capabilities, etc.

I believe that much of the benefit for adopting a new init system is
dropping init scripts and using a much better configuration language.  If
we're not going to take advantage of that benefit, it calls into question
whether we should change init systems at all.

In other words, I don't think it would make any sense at all to
standardize on upstart or systemd and then ask people to continue to write
init scripts in the long run (transition issues aside).  Getting rid of
init scripts is not the whole point, but it's a huge part of it.

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

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

[Steven Chamberlain]

Hi,

On Sun, 27 Oct 2013 02:47:56 +0800 Thomas Goirand wrote:
> Note that OpenRC already works on some (non-Debian) BSD platforms, and
> that it should be trivial to have it to build on kFreeBSD and Hurd,

And so I came up with the attached patch which gets it building on
GNU/kFreeBSD, and it passed whatever tests are run during build.  I
actually chose Linux implementations for most things, which are really
provided by GNU libc or /proc.

Actually quite amazing how painless that was, though I most certainly
don't expect it to be functional yet.  (For example, I expect it still
needs to know about linprocfs, linsysfs, tmpfs and maybe devfs).

I look forward to seeing OpenRC in the Debian archive.  Thanks!

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/etc/rc.conf.GNU-kFreeBSD b/etc/rc.conf.GNU-kFreeBSD
new file mode 100644
index 000..e138e3a
--- /dev/null
+++ b/etc/rc.conf.GNU-kFreeBSD
@@ -0,0 +1,12 @@
+##
+# GNU/kFreeBSD SPECIFIC OPTIONS
+
+# This is the subsystem type. Valid options on GNU/kFreeBSD:
+# ""- nothing special
+# "jail"- FreeBSD jails (not yet implemented)
+# If this is commented out, automatic detection will be used.
+#
+# This should be set to the value representing the environment this file is
+# PRESENTLY in, not the virtualization the environment is capable of.
+#rc_sys=""
+
diff --git a/mk/os-GNU-kFreeBSD.mk b/mk/os-GNU-kFreeBSD.mk
new file mode 100644
index 000..9fc9313
--- /dev/null
+++ b/mk/os-GNU-kFreeBSD.mk
@@ -0,0 +1,10 @@
+# Copyright (c) 2008 Roy Marples 
+# Released under the 2-clause BSD license.
+
+# Generic definitions
+
+PKG_PREFIX?=	/usr/local
+SFX=		.BSD.in
+
+CPPFLAGS+=	-D_BSD_SOURCE -D_XOPEN_SOURCE=700
+LIBDL=		-Wl,-Bdynamic -ldl
diff --git a/mk/os.mk b/mk/os.mk
index 3e18962..6b2d428 100644
--- a/mk/os.mk
+++ b/mk/os.mk
@@ -3,7 +3,7 @@
 
 # Generic definitions
 
-_OS_SH=		uname -s
+_OS_SH=		uname -s | tr '/' '-'
 _OS:= 		$(shell ${_OS_SH})
 OS?= 		${_OS}
 include ${MK}/os-${OS}.mk
diff --git a/src/librc/librc-daemon.c b/src/librc/librc-daemon.c
index 982da35..7a860c6 100644
--- a/src/librc/librc-daemon.c
+++ b/src/librc/librc-daemon.c
@@ -30,7 +30,7 @@
 
 #include "librc.h"
 
-#if defined(__linux__)
+#if defined(__linux__) || defined (__GLIBC__)
 static bool
 pid_is_exec(pid_t pid, const char *exec)
 {
diff --git a/src/rc/mountinfo.c b/src/rc/mountinfo.c
index eaace13..1006a0c 100644
--- a/src/rc/mountinfo.c
+++ b/src/rc/mountinfo.c
@@ -39,7 +39,7 @@
 #  include 
 #  define statfs statvfs
 #  define F_FLAGS f_flag
-#elif defined (__linux__)
+#elif defined (__linux__) || defined (__GLIBC__)
 #  include 
 #endif
 
@@ -265,7 +265,7 @@ find_mounts(struct args *args)
 	return list;
 }
 
-#elif defined (__linux__)
+#elif defined (__linux__) || defined (__GLIBC__)
 static struct mntent *
 getmntfile(const char *file)
 {
diff --git a/src/rc/rc-logger.c b/src/rc/rc-logger.c
index 468225f..e8fb0ff 100644
--- a/src/rc/rc-logger.c
+++ b/src/rc/rc-logger.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 
-#ifdef __linux__
+#if defined(__linux__) || defined(__GLIBC__)
 #  include 
 #elif defined(__NetBSD__) || defined(__OpenBSD__)
 #  include 
diff --git a/src/rc/runscript.c b/src/rc/runscript.c
index e504e4a..f14db11 100644
--- a/src/rc/runscript.c
+++ b/src/rc/runscript.c
@@ -52,7 +52,7 @@
 #include 
 #include 
 
-#ifdef __linux__
+#if defined(__linux__) || defined(__GLIBC__)
 #  include 
 #elif defined(__NetBSD__) || defined(__OpenBSD__)
 #  include 

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

[Brian May]

On 29 October 2013 12:21, Russ Allbery  wrote:

> In other words, I don't think it would make any sense at all to
> standardize on upstart or systemd and then ask people to continue to write
> init scripts in the long run (transition issues aside).  Getting rid of
> init scripts is not the whole point, but it's a huge part of it.


My understanding is that init scripts will still be required for FreeBSD
and The Hurd.

Which is unfortunate. I often encounter init scripts that have race
conditions or are otherwise broken. Restarting a simple daemon becomes a
challenge to debug the supposedly good init script first.

If the majority switched to systemd, then it would be up to the minority to
maintain the initd scripts. I don't see this working very well.
-- 
Brian May 

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

[Russ Allbery]

Brian May  writes:
> On 29 October 2013 12:21, Russ Allbery  wrote:

>> In other words, I don't think it would make any sense at all to
>> standardize on upstart or systemd and then ask people to continue to
>> write init scripts in the long run (transition issues aside).  Getting
>> rid of init scripts is not the whole point, but it's a huge part of it.

> My understanding is that init scripts will still be required for FreeBSD
> and The Hurd.

I would not assume that.  At least, I personally don't think that
switching to upstart or systemd as a default but requiring that everyone
provide both files for that system and init scripts for Hurd and kFreeBSD
to be a good outcome, since I don't think that will be something at which
Debian will be successful.

There are various other options, including not changing away from sysvinit
or someone porting the necessary support to Hurd and kFreeBSD.  Or, of
course, dropping Hurd and kFreeBSD, although I'm sure that no one wants
that outcome.

> Which is unfortunate. I often encounter init scripts that have race
> conditions or are otherwise broken. Restarting a simple daemon becomes a
> challenge to debug the supposedly good init script first.

> If the majority switched to systemd, then it would be up to the minority
> to maintain the initd scripts. I don't see this working very well.

Exactly.

Many of the existing init scripts are of poor quality in edge case
behavior precisely because writing a robust init script is exceedingly
difficult.  I think we have to ask whether this is something that we
should expect Debian packagers to continue to spend their time on.

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

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

[Ben Hutchings]

On Mon, 2013-10-28 at 19:38 -0700, Russ Allbery wrote:
> Brian May  writes:
> > On 29 October 2013 12:21, Russ Allbery  wrote:
> 
> >> In other words, I don't think it would make any sense at all to
> >> standardize on upstart or systemd and then ask people to continue to
> >> write init scripts in the long run (transition issues aside).  Getting
> >> rid of init scripts is not the whole point, but it's a huge part of it.
> 
> > My understanding is that init scripts will still be required for FreeBSD
> > and The Hurd.
> 
> I would not assume that.  At least, I personally don't think that
> switching to upstart or systemd as a default but requiring that everyone
> provide both files for that system and init scripts for Hurd and kFreeBSD
> to be a good outcome, since I don't think that will be something at which
> Debian will be successful.
> 
> There are various other options, including not changing away from sysvinit
> or someone porting the necessary support to Hurd and kFreeBSD.  Or, of
> course, dropping Hurd and kFreeBSD, although I'm sure that no one wants
> that outcome.
[...]

I do.  I think non-Linux ports make more sense as derivative
distributions.  This gives them the freedom to drop packages that aren't
worth porting, work around Linux-isms as necessary, improve integration
with their own kernel, and release on their own schedule - rather than
trying to make all the crap in Debian build.  (Remember, 90% of
everything is crap.)

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949


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

Re: let's split the systemd binary package

[Philipp Kern]

On 2013-10-28 10:58, Kevin Chadwick wrote:

By vast majority I was meaning user requirements and not distro
packagers expectations, user requirements is actually the metric which
should count the most and most users do not need session tracking, it
can actually get in the way (one user using many logins, shutdown, usb
access etc.).

User requirements are normally automatically reflected by unix
developers but RedHats enterprise requirements and extensive dev time
have the potential to swing that even if they rectify it from time to
time.


I'm not sure why our enterprise users don't count as users as well. My 
guess is that both Canonical and RedHat have some demanding customers 
that want basic features like accurate screensaver locking (which seems 
surprisingly hard) and proper isolation between users to be working...


So RH also pushes for multi-seat, where I agree that it's kind of an odd 
use case currently, but which could've saved a bunch of machines if it 
were implemented properly.


Kind regards
Philipp Kern


--
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/6cd39e535210d00357a6e714a077a...@hub.kern.lc