date:20140912

Hi,

Steve Langasek:
> I understand that software (especially desktop software) not coping with
> online updates is an existing problem.

Not only that. What _do_ you do when version 2 of $SUPPORTING_PACKAGE
implements a broken/superseded API or protocol? You limp along; you either
cannot start any new $DEPENDING_PROGRAMs or, when the supporter has been
restarted, all the dependants instantly break. Unless you restart them too.

We do some restarting for libc updates, but in a haphazard way (we don't
shut them down _while_ updating, only for some daemons) and for no other
package.

> The question is whether we - collectively - think moving to offline
> updates is an acceptable way to address this problem.

The problem is that an offline updater is an attractive nuisance.

It solves a specific problem which is now rare, precisely because we don't
solve it and therefore spend time and effort to prevent the "offline
update" non-solution from spreading.

> raise that question is now, /before/
> it becomes an entrenched assumption and leaves our users with no choice but
> to use it because their desktops become unusably broken if you apply package
> updates while they're running.
> 
The problem is that some already do.
Tried updating firefox ^W iceweasel lately?

The irony here is that firefox already has a perfectly capable method of
realising that there's a newer version available, and of re-exec'ing itself
without any data loss.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912081856.gc19...@smurf.noris.de

Re: rc bugs

2014-09-12 Thread Arto Jantunen

Brian May  writes:
> My reading of the criteria is it depends on your interpretation of "makes
> unrelated software on the system break". What does "unrelated" mean?  In
> this case it seems they are related as package Y depends on package X. Or
> maybe it means "unrelated" as in generated from different source
> packages?

If there is a dependency (a relationship) between the packages they are
by definition not "unrelated". This keeps coming up, and should probably
be added to the documentation of severity levels..

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egvhdymg@kirika.int.wmdata.fi

Re: PackageKit cleanup: Do you use these functions?

2014-09-12 Thread Philip Hands

Matthias Urlichs  writes:

> Hi,
>
> Steve Langasek:
>> I understand that software (especially desktop software) not coping with
>> online updates is an existing problem.
>
> Not only that. What _do_ you do when version 2 of $SUPPORTING_PACKAGE
> implements a broken/superseded API or protocol? You limp along; you either
> cannot start any new $DEPENDING_PROGRAMs or, when the supporter has been
> restarted, all the dependants instantly break. Unless you restart them too.
>
> We do some restarting for libc updates, but in a haphazard way (we don't
> shut them down _while_ updating, only for some daemons) and for no other
> package.
>
>> The question is whether we - collectively - think moving to offline
>> updates is an acceptable way to address this problem.
>
> The problem is that an offline updater is an attractive nuisance.
>
> It solves a specific problem which is now rare, precisely because we don't
> solve it and therefore spend time and effort to prevent the "offline
> update" non-solution from spreading.

We should also not underestimate the feeling of control that online
updates provide to users.  I've often been told by new users that them
deciding to click the "Updates Available" (or whatever it says) button,
and upgrading their system, made them feel like they were in control of
the computer for the first time in their lives.

We should not discard that lightly.

We should also not exchange bugs of the form "I upgraded the software on
my computer, which I think included an ugrade of $foo, and now $bar
stopped working" for "$bar stopped working when I ran it" [while not
quite thinking: "I would mention the fact that I rebooted last night if
I though that was relevant, but I cannot imagine it is, so I won't"]

It's all too easy for individual developers to think that only allowing
upgrades during reboots will be much safer for their particular
application, so where's the harm?

I'm sure that the folks at Microsoft are now very aware of the resulting
harm, having been fighting to get away from the need for multiple
reboots per upgrade for years -- Let's learn from their mistakes and not
even start down that road.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

pgpd6CiKLSWTE.pgp
Description: PGP signature

ppc64 not in any-powerpc ?

2014-09-12 Thread Mathieu Malaterre

I could not find the answer anywhere. Why is arch:ppc64 not in the
`any-powerpc` definition ? I would have guessed arch:ppc64 to be very
close to arch:powerpc...

Thanks,


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsw2esmUxU=G2NajhFWENpYTKzCVhAO6BQvepvLP=_a...@mail.gmail.com

Re: Allow encfs into jessie?

2014-09-12 Thread Agustin Martin

On Thu, Sep 11, 2014 at 04:06:06PM -0400, Harlan Lieberman-Berg wrote:
> On Thu, 2014-09-11 at 19:33 +0200, Eduard Bloch wrote:
> > I though Jan has just described one. For example, taking a 10 year old
> > CD with backups from your safe and trying to get the data back.
> 
> Another option would be to take the same approach that TrueCrypt did
> under (potentially) the same circumstances, and allow encfs into jessie
> - but only for read-only containers.  That way, people can recover their
> data easily, but there's no risk of perpetuating a completely broken
> encryption layer.
> 
> That'd be the best of both worlds, in my opinion.

Note that some people have encfs encrypted HOME dirs by means of things like
libpam-encfs. I do not think they will enjoy having their HOME partition
suddenly become RO, even if can be recovered with the new package. They
should of course be warned loudly that an old encryption layer is in use,
with some potential risks.

Another option would be a jessie encfs-ro package conflicting with encfs,
but neither providing nor replacing it, so no new volumes are created. 
encfs would be kept out of jessie and once fixed it would manage to replace
encfs-ro. However, the drawback is that the old encryption layer would
still be present in upgraded systems until fix happens and reaches a stable
release. 

I do not have a clear opinion about what is better.

Regards,

-- 
Agustin

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912101355.ga13...@agmartin.aq.upm.es

Re: ppc64 not in any-powerpc ?

On 12/09/14 10:48, Mathieu Malaterre wrote:
> I could not find the answer anywhere. Why is arch:ppc64 not in the
> `any-powerpc` definition ? I would have guessed arch:ppc64 to be very
> close to arch:powerpc...

That would be like making any-i386 include (linux-)amd64 or (linux-)x32,
which we don't do either. any-i386 only includes (linux-)i386,
kfreebsd-i386, hurd-i386, and any future IA32 ports.

(A concrete example of something that would be broken by including ppc64
in any-powerpc: imagine a package that has "Architecture: any-i386
any-armel any-powerpc ..." because it doesn't care what kernel it is
compiled for, but it has an architectural assumption that ints, longs
and pointers are all the same size. ppc64 does not have that property.)

If we had a kfreebsd-powerpc or hurd-powerpc port, those would fit in
any-powerpc: the same processor as (linux-)powerpc, but a different
kernel/ABI. (linux-)ppc64 is part of any-ppc64 instead.

There might be situations where it would be useful to have a way to
spell "any member of the x86 family", "any member of the PowerPC
family", "any member of the ARM family" and "any member of the MIPS
family", but we currently don't.

S

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412c87b.9050...@debian.org

Re: ppc64 not in any-powerpc ?

2014-09-12 Thread Andrey Rahmatullin

On Fri, Sep 12, 2014 at 11:48:26AM +0200, Mathieu Malaterre wrote:
> I could not find the answer anywhere. Why is arch:ppc64 not in the
> `any-powerpc` definition ? I would have guessed arch:ppc64 to be very
> close to arch:powerpc...
any means "any OS", not "any arches for this hardware"
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912101719.ga11...@belkar.wrar.name

Bug#761276: ITP: python-xstatic-font-awesome -- Font Awesome XStatic support

2014-09-12 Thread Thomas Goirand

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-xstatic-font-awesome
  Version : 4.1.0
  Upstream Author : Radomir Dopieralski 
* URL : https://github.com/stackforge/xstatic-font-awesome
* License : Expat, OFL-1.1
  Programming Lang: Python
  Description : Font Awesome XStatic support

 XStatic is a Python web development tool for handling required static data
 files from external projects, such as CSS, images, and JavaScript. It provides
 a lightweight infrastructure to manage them via Python modules that your app
 can depend on in a portable, virtualenv-friendly way instead of using embedded
 copies.
 .
 This package contains the Python 2.x module support for the Font Awesome.
 See the description of the fonts-font-awesome package.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140912104119.16762.74655.report...@buzig.gplhost.com

Re: PackageKit cleanup: Do you use these functions?

2014-09-12 Thread Matthias Klumpp

2014-09-12 1:49 GMT+02:00 Cameron Norman :
> El mié, 10 de sep 2014 a las 5:34 , Matthias Klumpp 
> escribió:
>> [...]
>
> What are the options?
>
> I would like if apps could say somehow (maybe an extension to the AppStream
> format?) whether they need offline updates, or if online is fine, so that it
> is only when needed. Also, an option to ignore apps' preferences and just do
> always offline or always online should be present (in PK's configuration).
That would probably be an overkill, although details like that could
theoretically be stored in the AppStream/DEP-11 metadata.

> Is this how the feature has been implemented? Do you think upstream (and you
> as an AppStream supporter / developer) would be enthusiastic about adding
> this, if it is not the status quo?
Possible, but unlikely - I don't think it's needed.

Here is a brief explanation about what actually happens when
"offline-updates" are enabled:
the online-updaters will work as always, even PackageKit is able to
perform online-updates like it always did. But if a desktop like GNOME
(and I am really only talking about desktops here) recognizes updates,
it will tell PackageKit to download updates locally. Whan that is
done, the user is notified about available updates (and might be asked
for reboot), or the shutdown button simple gets an "reboot & update"
sign.
Now, if the user reboots, the system enters a special mode where
updates are installed using PK (progress is shown on Plymouth), then
it reboots again and enters the desktop.
Now, in case an offline-update was prepared and the user does an
online-update, the "reboot & install updates" sign will simply vanish,
and everything will behave like it always did.
This feature is meant for unexperienced users, so, as Steve pointed
out, it would have to be default - but even if it was, it would be
pretty non-invasive.
Currently, GNOME-Software makes heavy use of offline-updates, and I
don't know of anything else which does (except for the cli tools).

The problem with restarting applications and subsystems is that you
never know if the loose state information if you just restart them
(e.g. Inkscape going down on upgrade would be pretty annoying). Also,
if e.g. a bug in a shared library gets fixed which is used by many
programs, you would have to re-execute quite a lot of stuff. On
servers, I expect people to handle that and know about this, but for
desktop users, I see some value in offline-updating.
Restarting the whole system is a pretty pragmatic solution for the
problem, you have to restart to use a new kernel as well anyway.

One thing I personally disagree with is how this is implemented
technically at time (we have systemd, which can reliably enter
different targets (runlevels) and ensure services are started and
stopped properly, but we still reboot twice "for safety reasons"), but
Lennart has a different opinion (and admittedly some valid points
about his position).

Relevant things to read:
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates

One thing I want to highlight again is that this would be a pretty
non-invasive change for users used to the existing behaviour, and that
the decision to use it lies by the Debian desktop teams (KDE/GNOME)
and their upstreams, which implement it or not.
What I want to do for Jessie+1 is implement this reliably - it should
better be working properly than being half-usable.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


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

Re: Allow encfs into jessie?

2014-09-12 Thread Jan Niehusmann

Hi Holger,

On Thu, Sep 11, 2014 at 06:42:32PM +0200, Holger Levsen wrote:
> I (probably too briefly) skimmed though the bug report, but couldn't find a 
> usecase where an encrypted filestem container with broken crypto could be 
> useful. Could you elaborate, please?

As far as I understand the EncFS Security Audit, encfs is not using
'broken crypto'. The conclusion of the audit states it quite clearly:

"EncFS is probably safe as long as the adversary only gets one copy of
the ciphertext and nothing more. EncFS is not safe if the adversary
has the opportunity to see two or more snapshots of the ciphertext at
different times. EncFS attempts to protect files from malicious
modification, but there are serious problems with this feature."
(from https://defuse.ca/audits/encfs.htm)

A common use case for disk encryption is to protect a lost or stolen
laptop. And the adversary is not some powerful agency, but a curious
person browsing through the hard disk before formatting it.

I see no reason to assume that encfs is not good enough for that use
case, at the moment.

Of course, the crypto should be improved ASAP, as attacks to crypto
only get better.

Regards,
Jan

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140912114636.ga2...@jannic.reliablesolutions.de

Re: PackageKit cleanup: Do you use these functions?

2014-09-12 Thread Guido Günther

On Fri, Sep 12, 2014 at 01:43:01PM +0200, Matthias Klumpp wrote:
[..snip..]
> The problem with restarting applications and subsystems is that you
> never know if the loose state information if you just restart them
> (e.g. Inkscape going down on upgrade would be pretty
> annoying). Also,

Why should it go down? It's mapped into memory already. There can be
problems with plugins but it would make more sense to think about
these details than resorting to rebooting (twice!). Btrfs could show a way
forward here.

> if e.g. a bug in a shared library gets fixed which is used by many
> programs, you would have to re-execute quite a lot of stuff. On
> servers, I expect people to handle that and know about this, but for
> desktop users, I see some value in offline-updating.

We have at least three tools in Debian for that checkrestart,
needrestart and whatmaps. We need to improve here to handle user
sessions better but again let's not switch to the sledgehammer without
having even tried.

> Restarting the whole system is a pretty pragmatic solution for the
> problem, you have to restart to use a new kernel as well anyway.

There KSplice among others.
Cheers,
 -- Guido

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912120334.ga30...@bogon.m.sigxcpu.org

Re: ppc64 not in any-powerpc ?

2014-09-12 Thread Mathieu Malaterre

On Fri, Sep 12, 2014 at 12:17 PM, Andrey Rahmatullin  wrote:
> On Fri, Sep 12, 2014 at 11:48:26AM +0200, Mathieu Malaterre wrote:
>> I could not find the answer anywhere. Why is arch:ppc64 not in the
>> `any-powerpc` definition ? I would have guessed arch:ppc64 to be very
>> close to arch:powerpc...
> any means "any OS", not "any arches for this hardware"
> https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec

Thanks all.

I got confused with `wine` package which was built on x32 and
powerpcspe, I guess those were forced by the uploaders.

-M


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsxC6t_HOAT3q88=xntty1+on33u2pgcrfnby7et7-h...@mail.gmail.com

Re: Trimming priority:standard

2014-09-12 Thread Adam Sampson

Josh Triplett  writes:

> Now that libc-bin contains C.UTF-8, which we should make the default
> locale, [...]

It would be nice to get Debian's support for C.UTF-8 pushed to upstream
glibc. At present, it's patched in by some (not all) distributions,
which means that upstream authors can't rely on it being available.
For some of my software it'd be really useful to have a predictable
UTF-8 locale for running tests, etc.

There's a glibc RFE bug filed in response to a Fedora discussion:
  https://sourceware.org/bugzilla/show_bug.cgi?id=17318

-- 
Adam Sampson  

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/y2afvfx6phh@cartman.at.offog.org

Re: ppc64 not in any-powerpc ?

2014-09-12 Thread Jakub Wilk


* Mathieu Malaterre , 2014-09-12, 14:03:
I could not find the answer anywhere. Why is arch:ppc64 not in the 
`any-powerpc` definition ? I would have guessed arch:ppc64 to be very 
close to arch:powerpc...

any means "any OS", not "any arches for this hardware"
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec


No, "any" means "it's confusing". :-P


Thanks all.

I got confused with `wine` package which was built on x32


Because any-amd64 matches x32. (I kid you not.)


and powerpcspe,


Because any-powerpc matches powerpc.


I guess those were forced by the uploaders.


I don't think so.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912121708.ga2...@jwilk.net

Re: Trimming priority:standard

2014-09-12 Thread Simon Josefsson

Josh Triplett  writes:

> - make-guile.  More of a question than a recommendation for a change,
>   but why is this standard and make optional, rather than the other way
>   around?

Is this mostly about naming?  GNU Make has guile-support by default, so
I would say that 'make' should be with Guile and if desired for some
reason, there could be a 'make-noguile' that is built without guile.

A bigger question: is 'make' really necessary in priority:standard?
Presumably anything requiring it will depend on it.

> - mlocate.  We don't need a "locate" in standard; anyone who actually
>   uses locate (and wants the very significant overhead of running a
>   locate daemon) can easily install this.

+1

It is for desktops.

> - nfs-common and rpc-bind.  Anyone using NFS can install these, but NFS
>   is not anywhere close to common enough to appear in priority standard.

+1

Right now rpcbind is listening on the network in a default jessie
install, and I don't like that.

/Simon

signature.asc
Description: PGP signature

Re: upgrades must not change the installed init system

On Mon, 8 Sep 2014, Vincent Danjean wrote:

> When Debian switched the default syslog implementation (to rsyslog),
> upgrades did not change already installed syslog implementation.

They most definitely did not do that, right.

The only one which did was GRUB → GRUB 2, which required the
user to install grub-legacy before doing the dist-upgrade…
needless to say, this broke some headless server setups I had
heard about. (Before you shout “release notes”, most people I
know run testing or unstable. While issues should be expected
there, random unannounced (or! announced) breakage should not.)

>   But, as soon as systemd has unit files that replaces init scripts,
> these ones are not used anymore. And any customization (such as "exit 0")
> done in them is then lost. I'm wrong ?

No, you’re right. Worse, “exit 0” in the /etc/default/* files
are ignored, too. Shell scripts in /etc/default/* now break, too.

Which reminds me… (fup in the BTS).

> I find very difficult to fix it for now. And nearly any customization
> of init scripts is lost without a word during the upgrade. Enabling

… and other things, such as syslog config.

And those new techniques for debugging are foreign to
• LPI certified admins
• experienced Debian admins
• experienced *buntu admins
• experienced Unix admins (maybe except Solaris)
etc.

So yes, an upgrade shall not change the init system.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121437160.7...@tglase.lan.tarent.de

Re: ppc64 not in any-powerpc ?

2014-09-12 Thread Johannes Schauer

Hi,

Quoting Simon McVittie (2014-09-12 12:18:35)
> There might be situations where it would be useful to have a way to spell
> "any member of the x86 family", "any member of the PowerPC family", "any
> member of the ARM family" and "any member of the MIPS family", but we
> currently don't.

There is something that spells "some members of the ARM family":

$ dpkg-architecture -aarm -iany-arm && echo yes || echo no
yes
$ dpkg-architecture -aarmel -iany-arm && echo yes || echo no
yes
$ dpkg-architecture -aarmhf -iany-arm && echo yes || echo no
yes

It it doesn't match arm64 though.

$ dpkg-architecture -aarm64 -iany-arm && echo yes || echo no
no


The common fallacy is that the "foo" in "any-foo" is the name of a Debian
architecture while in fact it is the name of the CPU which is mapped to one or
more Debian architectures by /usr/share/dpkg/triplettable

This is even done wrongly by apt itself. See #748936.

cheers, josch


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912131108.3685.97213@hoothoot

Re: systemd, again

On Mon, 8 Sep 2014, Simon McVittie wrote:

> systemd is compatible with LSB (i.e. sysvinit) init scripts. So is Upstart.

If LSB were == sysvinit, and not just a subset of it, we’d
have had *much* less troubles at work during the forced move
to insserv even with file-rc.

(Spoiler: cow-orkers, especially those more versed in the
RPM worlds, do not write LSB compliant init scripts manually.)

And then there’s the deviation between LSB and Debian SYSV
init script exit codes… (but Debian’s is saner).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121501590.7...@tglase.lan.tarent.de

Re: PackageKit cleanup: Do you use these functions?

On 12/09/14 12:43, Matthias Klumpp wrote:
> Now, if the user reboots, the system enters a special mode where
> updates are installed using PK (progress is shown on Plymouth), then
> it reboots again and enters the desktop.

I've done some work on a similar feature for unattended-upgrades
, which hasn't been merged by the
maintainer yet, but is used in SteamOS. The major design difference
there is that the upgrade is carried out during shutdown instead of
having to boot into a special mode, so you don't have to reboot twice.

We did consider applying upgrades during startup, but then you have to
worry about whether all the necessary things got restarted afterwards
(which is impossible for e.g. the kernel in any case); if you do it
during shutdown, everything is about to be terminated anyway, so it
doesn't matter whether processes with old libraries mapped are still
hanging around.

FWIW, we never considered *not* rebooting for upgrades - if it works,
great, but working out all the corner cases, and diagnosing new ones
when they happen, just didn't seem an efficient use of anyone's time.

> Now, in case an offline-update was prepared and the user does an
> online-update, the "reboot & install updates" sign will simply vanish,
> and everything will behave like it always did.
> This feature is meant for unexperienced users, so, as Steve pointed
> out, it would have to be default - but even if it was, it would be
> pretty non-invasive.

I think this is a significant point. The sort of people who read
debian-devel are the sort of people who can assess the severity of a
security flaw on a scale from "drop everything and fix it now" to "apply
eventually"; interpret checkrestart output; restart the necessary
things; and recognise the symptoms of an online update to an application
that cannot actually cope with online updates (and file bugs where
appropriate).

However, those people are not Debian's only audience. If I tried to
explain all that to my parents, they'd never apply security updates.
"When your computer says it has downloaded security updates, reboot next
time it's convenient" is far easier to explain - it might sometimes be
overkill, but doing too much is better than not doing enough.

> Also,
> if e.g. a bug in a shared library gets fixed which is used by many
> programs, you would have to re-execute quite a lot of stuff.

As much as I want to agree with the general philosophy that in an ideal
world every piece of software would support re-exec'ing itself, we do
not live in that ideal world. In an ideal world libraries wouldn't break
ABI either, but they do; in an ideal world libraries and applications
wouldn't have security flaws that need stable-updates, but they do. As
much as I'd like people to implement all the subtleties of re-exec'ing
from an arbitrary older version, it doesn't seem realistic to expect it
to happen (and when it does, it'll be wrong - because as a first
approximation, code that you don't test doesn't work, and upgrading from
version < X to version >= X is the sort of thing you only do once or
infrequently).

When a significant or "core" enough bug has been fixed (e.g. Heartbleed,
or a libc flaw), I would personally advocate ignoring checkrestart and
friends, and rebooting anyway, even on a server: there is value in
knowing for sure that everything that needs restarting has definitely
been restarted, and whatever tool you used to find the necessary things
to restart didn't miss any. "Obviously correct" is better than
"reasonably sure to be correct".

S

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412f527.7060...@debian.org

Re: PackageKit cleanup: Do you use these functions?

On Thu, 11 Sep 2014, Ansgar Burchardt wrote:

> Well, online updates do break software from time to time on my system.

I’ve had to do unattended updates of our old Kubuntu desktop at work
at shutdown time as well, due to breakage involved in upgrading them
while being in use (especially the desktop software, most noteworthy
Mozilla ware).

Sometimes, rebooting (or, at least, logging out then in again) after
upgrades that touch “desktop” components is better.

Funnily enough, this isn’t so much true for server systems, where we
just restart the dæmons affected, and occasionally want a new kernel
if even that.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.140912150.7...@tglase.lan.tarent.de

Re: Seeking help with OpenVPN scripts and systemd

On Thu, 11 Sep 2014, Gergely Nagy wrote:

> OpenVPN works just fine with systemd. Its init script does not, but for

Yes, but for many installations, its init script is what is
required for the VPN to “work”.

> There is no problem with that, at all.

Right, no problem except that remote machines are no longer
maintainable because nobody can get into them because the
VPN does not work. Sure, no problem at all. Remember ax25-node?

So yes, a Conflicts is definitely appropriate until such time
as this is fixed…

… except: why do you write unit files anyway, if the initscript
works? The systemd apologetists say systemd can run existing
SYSV initscripts “just fine”.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121525230.7...@tglase.lan.tarent.de

Re: PackageKit cleanup: Do you use these functions?

2014-09-12 Thread Matthias Klumpp

2014-09-12 15:35 GMT+02:00 Thorsten Glaser :
> On Thu, 11 Sep 2014, Ansgar Burchardt wrote:
>
>> Well, online updates do break software from time to time on my system.
>
> I’ve had to do unattended updates of our old Kubuntu desktop at work
> at shutdown time as well, due to breakage involved in upgrading them
> while being in use (especially the desktop software, most noteworthy
> Mozilla ware).
>
> Sometimes, rebooting (or, at least, logging out then in again) after
> upgrades that touch “desktop” components is better.
>
> Funnily enough, this isn’t so much true for server systems, where we
> just restart the dæmons affected, and occasionally want a new kernel
> if even that.
I fully agree with that, and Simons analysis. I will talk to the
relevant people again, maybe we can get offline-updates happen on
shutdown afterall...
Cheers,
Matthias


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

Re: Trimming priority:standard

On Fri, 12 Sep 2014, Josh Triplett wrote:

> > * dc: a RPN calculator is pretty esoteric, bc is for "normal people".
> 
> Just filed a bug for that one.
> 
> I'd actually argue that both bc and dc should become "optional".

*no*!

bc is the standard Unix calculator, normally a dc frontend,
and used in *a lot* of scripts.

I’m ambiguous about GNU dc (since GNU bc does not use it,
and I’ve seen fewer – still not none – scripts using it),
but if there is no bc or ed on a system, it’s Windows or
something.

And yes, bc is also the primary interactive calculator,
for things beyond what $((…)) can do.

> > * telnet: dead for 19 years.  Used only by those who misspell 'nc' and hope
> >   for no 0xff bytes.

> Also, it's sad that "netcat-traditional" is priority important, rather
> than "netcat-openbsd", which has far more useful features (for instance,

Agreed that netcat-openbsd (*not* netcat-traditional!) should
supersede telnet (because of 0xFF, but also because nc is
line-buffered and telnet is unbuffered), but again, removing
telnet is against the expectations of most Unix users.

> > On the other hand, I'd nominate 'locales' for priority:important.  Needed
> > for working UTF-8 support.
> 
> Not needed; just set LANG=C.UTF-8, provided by libc-bin (Essential:
> yes).  We should do that by default.

Agree. And if that should ever *not* be enough, “locales” also
isn’t and you need “locales-all” instead. (I’ve seen random PHP
webapplications break if locales-all was not installed, with
segfaults and all…)

> - at.  Trivially installed by anyone actually using it, but we don't
>   need one more daemon running on everyone's system just to watch for
>   jobs via a service that almost nobody uses.

Eh sorry? at+cron are standard Unix.

> - bc, along with dc, as mentioned above.

Absolutely no.

> - host, a transitional package.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645437

Right, but bind9-host is really heavy…

> - bsd-mailx.  Any package that uses this will depend on it.  Very few
>   people use this as a mail reader, and it's trivially installed for
>   people who have scripts that invoke it (rather than the more common
>   case of invoking sendmail).  And this doesn't work at all without an
>   installed or configured MTA, another good reason to give it the boot.

Agreed; prio:standard should probably not pull in this (and,
via it (and only it, IIRC), one of the MTAs, the discussion
of which to choose is political).

But then, an MTA configured to listen and deliver locally,
and send mails out, belongs to a standard system…

> - procmail.  Anyone using this can trivially install it, but it's far
>   from common, and it wouldn't be shocking for a system (particularly a
>   system other than a mail server) to not have it preinstalled.

Agreed. procmail seems to be a GNU phenomenon anyway; I’ve
not seen it on a non-GNU OS, unless the admin or a user was
already a fan of it.

> - w3m.  Very few people use text-based web browsers, and we should not
>   have one in standard.

At least not w3m but lynx, which is the standard text browser;
w3m is also really… weird to use.

> - make-guile.  More of a question than a recommendation for a change,
>   but why is this standard and make optional, rather than the other way
>   around?

oO this is new…

> - mlocate.  We don't need a "locate" in standard; anyone who actually
>   uses locate (and wants the very significant overhead of running a
>   locate daemon) can easily install this.

Disagree, locate should be there.

> - nfs-common and rpc-bind.  Anyone using NFS can install these, but NFS
>   is not anywhere close to common enough to appear in priority standard.

ACK.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121542260.7...@tglase.lan.tarent.de

Re: ppc64 not in any-powerpc ?

On Fri, 12 Sep 2014, Jakub Wilk wrote:

> Because any-amd64 matches x32. (I kid you not.)

> Because any-powerpc matches powerpc.

powerpcspe?

These are probably bugs in dpkg and related tools,
and massively unexpected.

On Fri, 12 Sep 2014, Simon McVittie wrote:

> There might be situations where it would be useful to have a way to
> spell "any member of the x86 family", "any member of the PowerPC
> family", "any member of the ARM family" and "any member of the MIPS
> family", but we currently don't.

Please keep this at don’t – there aren’t so many variants of
processors around (arm, i386, ppc, possibly MIPS), but these
that are differ enough (bit sizes, ABIs, endianness even!)
that they are very well considered different architectures.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121551510.7...@tglase.lan.tarent.de

Re: PackageKit cleanup: Do you use these functions?

On 12/09/14 14:29, Simon McVittie wrote:
> In an ideal world libraries wouldn't break
> ABI either, but they do; in an ideal world libraries and applications
> wouldn't have security flaws that need stable-updates, but they do. As
> much as I'd like people to implement all the subtleties of re-exec'ing
> from an arbitrary older version, it doesn't seem realistic to expect it
> to happen

... and if given the choice between upstreams spending N hours on
implementing re-exec so their security updates are less disruptive, or
spending N hours on security hardening / defensive programming so their
security updates are less frequent or less urgent, I'd prefer the latter :-)

S

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412fb19.9070...@debian.org

Re: Trimming priority:standard

2014-09-12 Thread Theodore Ts'o

On Thu, Sep 11, 2014 at 07:41:19PM -0700, Russ Allbery wrote:
> 
> > * telnet: dead for 19 years.  Used only by those who misspell 'nc' and hope
> >   for no 0xff bytes.
> > * wamerican: what use is a wordlist with no users?
> 
> Both of these fall under the "anyone familiar with UNIX would go 'where
> the hell is X' if the package isn't installed" provision, I think.  Yes,
> nc is better than telnet, but telnet is part of a *lot* of people's finger
> memory, and I think removing the package violates the principle of least
> surprise here.  It's not very large.

A large number of these packages would fall into this category.
Arguably this would include dc and m4.  (Trivia fact: dc predates the
C programming language, and it has macros, conditionals, and looping
constructs.  :-)

That being said, if there are Debian users who are not Unix-heads,
they aren't going to miss any of these.  What if we create a tasksel
task called "Unix" that installs these traditional Unix commands from
the BSD 4.x era?  It would include dc, m4, /usr/dict/words, telnet,
etc.

> wamerican provides /usr/share/dict/words, which is widely used in a
> variety of strange places you wouldn't expect, like random test suites.

True, but that's a developer thing.  The argument can be used for m4
and dc as well --- that they can be used all sorts of places you don't
expect. 

- Ted

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912135601.ga23...@thunk.org

Bug#761289: ITP: ntpstat -- show network time protocol (ntp) status

2014-09-12 Thread Thomas Goirand

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: ntpstat
  Version : 0.0.0.1
  Upstream Author : Daniel Huckstep 
* URL : https://github.com/darkhelmet/ntpstat
* License : GPL-2
  Programming Lang: C
  Description : show network time protocol (ntp) status

 This program uses an NTP mode 6 control message, which is the same as that
 used by the ntpq command. The ntpdc command uses NTP mode 7, details of
 which are elusive. For details on the format of NTP control message, see
 http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140912140237.26034.41641.report...@buzig.gplhost.com

Re: Trimming priority:standard

On 12/09/14 14:56, Theodore Ts'o wrote:
> What if we create a tasksel
> task called "Unix" that installs these traditional Unix commands from
> the BSD 4.x era?  It would include dc, m4, /usr/dict/words, telnet,
> etc.

I was just about to suggest that myself. at, cron, an MTA, and locate
seem good candidates for that task too.

(Admittedly, cron has to be Priority:important anyway, to support
logrotate - until/unless someone adds a logrotate.timer for systemd, and
makes its cron job early-return if systemd is pid 1.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412ff5f.5040...@debian.org

Re: Trimming priority:standard

Le 12/09/2014 15:49, Thorsten Glaser a écrit :
> On Fri, 12 Sep 2014, Josh Triplett wrote:
[...]
> bc is the standard Unix calculator, normally a dc frontend,
> and used in *a lot* of scripts.
[...]
> Eh sorry? at+cron are standard Unix.
[...]
> But then, an MTA configured to listen and deliver locally,
> and send mails out, belongs to a standard system…

Hi,

I agree that all those tools belong to a standard UNIX system. However,
is that among our goals to provide people with a standard UNIX system by
default? Do our users care?

These tools really make sense only for a subset of our users (mostly,
network administrators). Our desktop users don't care for any of those,
as long as they are pulled in transparently when required by the stuff
they actually use.

The same holds for telnet: most users have no clue what to do with it.

As an example, on my laptop, nobody ever uses any of theses tools. I
don't read local mail. I send mail using SMTP. I don't write that many
shell scripts, using higher end languages that don't need bc for doing
maths. I do care for locate, though.

Not that I care much personally about trimming prio:standard, but why
not move a lot of this stuff to a "standard UNIX-like" task (or whatever
you want to call it) instead?

Kind regards, Thibaut.

signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

On Tue, 9 Sep 2014, Mathieu Parent wrote:

> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init

These are the Linux bootloaders I came up within less than
five minutes of searching the ’net:

• Acronis OS Selector
• AiR-Boot
• AKernelLoader
• AMIBOOT
• APEX
• ARAnyM LILO
• ARCBOOT
• Barebox
• Boot Camp
• BootIt Next Generation
• BootKey
• BOOTSTRA.TTP
• BootX
• BURG
• CFE
• coreboot
• EFI
• ELILO
• Emile
• EXTLINUX
• FreeLoader 
• GRUB 1
• GRUB 2
• GRUB4DOS
• Gujin
• Gummiboot
• Kexecboot
• LILO
• LOADLIN.EXE
• MasterBooter
• PALO
• Penguin
• PMON
• PXELINUX
• Qi
• quik
• Redboot
• rEFInd
• rrload
• SILO
• Smart Boot Manager
• SYSLINUX
• TFTPLILO
• U-Boot
• XOSL
• Yaboot
• YAMON

I’ve heard of barely half of them, and have had personal
experience with half of that, but that still makes for a
dozen booloaders I know of.

Many of these require the user to copy out the kernel and
initrd from the Linux-controlled space, for example into
NAND flash or a FAT partition or a HFS partition or the
host filesystem or whatever.

So: No. Not a solution.

https://julien.danjou.info/media/images/blog/2014/unacceptable.jpg

bye,
//mirabilos

PS: Thanks, Julien!
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121610190.7...@tglase.lan.tarent.de

Re: Trimming priority:standard

On Fri, 12 Sep 2014, Thibaut Paumard wrote:

> I agree that all those tools belong to a standard UNIX system. However,
> is that among our goals to provide people with a standard UNIX system by

This is not about “by default”, but it *is* the definition
of priority:standard in Debian.

And yes, it’s reasonable.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121622480.7...@tglase.lan.tarent.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

On Tue, 9 Sep 2014, Ansgar Burchardt wrote:

> We could delay the transition-on-upgrade by one release, but the
> migration from sysvinit to systemd on a Jessie -> Jessie+1 upgrade will
> probably end up less tested (though systemd itself would probably be
> more tested by then).

Nobody says jessie+1 will not permit running sysvinit any more,
and the CTTE rulings explicitly did not touch that topic which
implies some amount of scepsis.

Plus, sysvinit must probably be kept for non-linux arches anyway
(the Hurd people are happy enough to have even that much), so we
can keep it working for the linux arches too.

> Having only some systems switch to a different init system on upgrade
> seems potentially confusing to me.

Agreed, which just persuaded me to believe that even people
running GNOME should not be switched on upgrade, but rather
required to switch first (or after the upgrade), so that no
existing Debian system is auto-switched to systemd.

> That said, it would be nice if
> systemd-sysv could check for common problems on installation and issue a

Agree.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121625330.7...@tglase.lan.tarent.de

Re: Trimming priority:standard

Le 12/09/2014 16:23, Thorsten Glaser a écrit :
> On Fri, 12 Sep 2014, Thibaut Paumard wrote:
> 
>> I agree that all those tools belong to a standard UNIX system. However,
>> is that among our goals to provide people with a standard UNIX system by
> 
> This is not about “by default”, but it *is* the definition
> of priority:standard in Debian.

No, it's not. The actual definition is very vague and does not refer to
UNIX at all:

standard

These packages provide a reasonably small but not too limited
character-mode system. This is what will be installed by default if the
user doesn't select anything else. It doesn't include many large
applications.

https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

Kind regards, Thibaut.


-- 
* Dr Thibaut Paumard   | LESIA/CNRS - Table équatoriale (bât. 5)   *
* Tel: +33 1 45 07 78 60   | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17   | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France)   *



smime.p7s
Description: Signature cryptographique S/MIME

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

On Wed, 10 Sep 2014, Nick Phillips wrote:

> Debian has a good and hard-earned reputation for not messing up
> sysadmins' changes

Agreed. This is about the only thing I can currently use to
argue for use of Debian over *buntu in some places.

> So, is it actually feasible to provide such a prompt?

Not with debconf. Short of patching the apt in stable (and
aptitude, and cupt, and and and…) there is nothing that can
reliably show such a prompt.

The consequence is easy: show a debconf prompt on upgrade
that recomments the admin to “sudo apt-get install systemd-sysv”
and never ever switch a system automatically.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121631200.7...@tglase.lan.tarent.de

Re: Trimming priority:standard

2014-09-12 Thread Steve McIntyre

Simon McVittie wrote:
>On 12/09/14 14:56, Theodore Ts'o wrote:
>> What if we create a tasksel
>> task called "Unix" that installs these traditional Unix commands from
>> the BSD 4.x era?  It would include dc, m4, /usr/dict/words, telnet,
>> etc.
>
>I was just about to suggest that myself. at, cron, an MTA, and locate
>seem good candidates for that task too.

+1. Makes a lot of sense, I agree. Maybe also move across:

bind9-host
dnsutils
host
bsd-mailx
lsof (?)
patch (?)
procmail
time (?)
whois

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...


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

Re: Trimming priority:standard

Le 12/09/2014 16:33, Thibaut Paumard a écrit :
> Le 12/09/2014 16:23, Thorsten Glaser a écrit :
>> On Fri, 12 Sep 2014, Thibaut Paumard wrote:
>>
>>> I agree that all those tools belong to a standard UNIX system. However,
>>> is that among our goals to provide people with a standard UNIX system by
>>
>> This is not about “by default”, but it *is* the definition
>> of priority:standard in Debian.
> 
> No, it's not. The actual definition is very vague and does not refer to
> UNIX at all:

My bad. It's the "important" priority that mentions UNIX.



-- 
* Dr Thibaut Paumard   | LESIA/CNRS - Table équatoriale (bât. 5)   *
* Tel: +33 1 45 07 78 60   | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17   | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France)   *



smime.p7s
Description: Signature cryptographique S/MIME

Re: Trimming priority:standard

On Fri, 12 Sep 2014, Thibaut Paumard wrote:

> No, it's not. The actual definition is very vague and does not refer to

Oh, my bad. I confused this with priority:important then.

So we should probably *raise* the priority of things like
bc, ed, etc. to "important".

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409121637170.7...@tglase.lan.tarent.de

Re: Trimming priority:standard

Le 12/09/2014 16:37, Thorsten Glaser a écrit :
> On Fri, 12 Sep 2014, Thibaut Paumard wrote:
> 
>> No, it's not. The actual definition is very vague and does not refer to
> 
> Oh, my bad. I confused this with priority:important then.
> 
> So we should probably *raise* the priority of things like
> bc, ed, etc. to "important".

That, or change Policy to reflect current expectations. Perhaps those
priorities don't make that much sense nowadays.

Debian has really become the Universal OS by know, tasks are better
suited to represent what is considered "important", "standard" or
"optional" in different fields of endeavor.

Kind regards.

signature.asc
Description: OpenPGP digital signature

Re: Trimming priority:standard

2014-09-12 Thread Edward Allcutt


On Fri, 12 Sep 2014, Josh Triplett wrote:

* telnet: dead for 19 years.  Used only by those who misspell 'nc' and hope
  for no 0xff bytes.


A slight exaggeration. A client that uses the actual telnet protocol is 
still invaluable for managing various fairly stupid devices.



Given the rarity of telnet for login, and the common use of telnet for a
text connection to random ports, how insane would it be to make
interactive invocation of telnet default to being clean and transparent
(without the crazy escape characters), and require an explicit option to
*enable* non-transparent operation?


I'd regard that as highly inconvenient. More inconvenient than retraining 
fingers to nc (although I'm biased since I've already done that).


Regardless, this is in no way an argument for keeping telnet in standard.

--
Edward Allcutt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.02.1409121556060.18...@pandora.retrosnub.co.uk

Re: Seeking help with OpenVPN scripts and systemd

2014-09-12 Thread Axel Wagner

Can anyone please just read the rest of this thread before continuing
this flamewar? The original question was asked, answered and the answer
was deemed satisfactory.

Best,

Axel Wagner


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/8738bwooq0.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: ppc64 not in any-powerpc ?

2014-09-12 Thread Andrey Rahmatullin

On Fri, Sep 12, 2014 at 03:11:08PM +0200, Johannes Schauer wrote:
> The common fallacy is that the "foo" in "any-foo" is the name of a Debian
> architecture while in fact it is the name of the CPU which is mapped to one or
> more Debian architectures by /usr/share/dpkg/triplettable
Indeed, maybe we need to spell this more explicitly in the Policy?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Trimming priority:standard

2014-09-12 Thread Josh Triplett

On Fri, Sep 12, 2014 at 02:36:09PM +0200, Simon Josefsson wrote:
> Josh Triplett  writes:
> 
> > - make-guile.  More of a question than a recommendation for a change,
> >   but why is this standard and make optional, rather than the other way
> >   around?
> 
> Is this mostly about naming?  GNU Make has guile-support by default, so
> I would say that 'make' should be with Guile and if desired for some
> reason, there could be a 'make-noguile' that is built without guile.

No, I think it makes sense for "make" to not have Guile support, and
"make-guile" to have Guile.  That way, the version of "make" pulled in by
existing dependencies (and build-essential) does not guarantee Guile
support, and packages depending on Guile support must depend on
make-guile explicitly.

I more wondered whether the default version of Make in stanard should
have Guile support.  However...

> A bigger question: is 'make' really necessary in priority:standard?
> Presumably anything requiring it will depend on it.

...I think this makes more sense: *neither* version of Make should have
priority standard.  Bug filed.

> > - mlocate.  We don't need a "locate" in standard; anyone who actually
> >   uses locate (and wants the very significant overhead of running a
> >   locate daemon) can easily install this.
> 
> +1
> 
> It is for desktops.
> 
> > - nfs-common and rpc-bind.  Anyone using NFS can install these, but NFS
> >   is not anywhere close to common enough to appear in priority standard.
> 
> +1
> 
> Right now rpcbind is listening on the network in a default jessie
> install, and I don't like that.

Exactly.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912164158.GA3271@thin

Re: Trimming priority:standard

2014-09-12 Thread Theodore Ts'o

On Fri, Sep 12, 2014 at 03:12:47PM +0100, Simon McVittie wrote:
> 
> (Admittedly, cron has to be Priority:important anyway, to support
> logrotate - until/unless someone adds a logrotate.timer for systemd, and
> makes its cron job early-return if systemd is pid 1.)

It's inevitable that systemd will subsume cron, with an incompatible
configuration file format.  :-)

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912171230.gb23...@thunk.org

Re: Trimming priority:standard

2014-09-12 Thread Jakub Wilk


* Theodore Ts'o , 2014-09-12, 13:12:
It's inevitable that systemd will subsume cron, with an incompatible 
configuration file format.  :-)


I'm looking forward for systemd-mta.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912171850.ga8...@jwilk.net

Re: Trimming priority:standard

2014-09-12 Thread Theodore Ts'o

One thought... there will probably be trademark concerns with "unix".[1]
So we might have to choose a name for the tasksel task to be someting
like "unix-like".

[1] http://www.unix.org/trademark.html

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912171923.gc23...@thunk.org

On 09/12/2014 06:46 AM, Jan Niehusmann wrote:
> A common use case for disk encryption is to protect a lost or stolen
> laptop. And the adversary is not some powerful agency, but a curious
> person browsing through the hard disk before formatting it.
>
> I see no reason to assume that encfs is not good enough for that use
> case, at the moment.

There is, of course, also the problem of: what will people replace it
with? I would suggest that some level of protection is better than
none, and that the most likely outcome of removing encfs is no
protection at all for a majority of users.

Probably the most common suggestion, and only real option I am aware of,
is ecryptfs. (LUKS and dm_crypt solve different problems.) Compared to
encfs, ecryptfs is extremely difficult to use. For instance, by
default, unlike encfs, you cannot change the password of ecryptfs data
because the passphrase is directly transformed into the encryption key.
After poring over poorly-documented things, I found a suggestion of how
to work around this:

1) Generate an encryption key with

od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | \
sed "s/^000//" | sed "s/\s*//g"

2) Pipe (I think!) the output from the above into
ecryptfs-wrap-passphrase to encrypt it

3) Before mounting, run ecryptfs-insert-wrapped-passphrase-into-keyring
pointing to the file saved in step 2

4) Save your precise mount options; in my case,
ecryptfs_unlink_sigs,ecryptfs_fnek_sig=longstringhere,ecryptfs_key_bytes=32,ecryptfs_cipher=aes,ecryptfs_sig=anotherlongstring

5) Use those precise mount options later

(These steps are rough; they may need a little tweaking but are close to
the mark.)

This is not friendly. At all.

Additionally, although the ecryptfs audit at
https://defuse.ca/audits/ecryptfs.htm produces fewer red flags than the
encfs audit did, still its conclusion says "there are some red flags
indicating it was not designed by a cryptographer."

I also found mysterious bugs attempting to share the decrypted view of
an ecryptfs volume using NFS. Finally, encfs has an interesting reverse
crypto mode where it presents an encrypted FUSE view over a plaintext
mountpoint.

I can't find anything in the ecryptfs manpages about whether they're
using SHA or MD5, but this RedHat bug from 2009 suggests it's using MD5.
https://bugzilla.redhat.com/show_bug.cgi?id=490918 I do not know
immediately why this was a red flag in encfs but not ecryptfs.

I should also note that even if the authenticity features of encfs are
less than perfect, it doesn't mean the package is useless. A person
may, for instance, care more about the encryption than MAC features.
>From what I can see, ecryptfs doesn't even have MAC at all.

Let's warn people about things, of course, but drop something that's
useful if not perfect? I don't think so.

Encryption, for a lot of people, is making onesself a harder target.
Let's face it, encfs, ecryptfs, dm_crypt, anything like that is probably
not going to completely protect a running Internet-connected machine
from every possible well-funded adversary, since once the encrypted data
is mounted, it is accessible until the machine is turned off. Physical
keyloggers, social engineering, etc. can also be a threat. None of
these tools is perfect, but they are all an *improvement*. If a laptop
is stolen from a coffee table by an opportunistic thief, and I know its
screen was locked and the data on it was encrypted by one of the above
tools, I can pretty much rest easy that at least my data is safe.

Transparent encryption can be an important layer of data security, but
it must not start or stop there for those truly concerned about it.

John

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5413261c.20...@complete.org

Re: Trimming priority:standard

On 12/09/14 18:19, Theodore Ts'o wrote:
> One thought... there will probably be trademark concerns with "unix".[1]
> So we might have to choose a name for the tasksel task to be someting
> like "unix-like".

Perhaps

task-traditional -- Traditional Unix utilities

? Or Un*x if you're that worried.

(The ambiguous meaning of "tradition" - either "well-established
practices that all right-thinking people should follow" or "obsolete
things that are only here because they always used to be" - is entirely
intentional. :-)

S

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54132d0a.1000...@debian.org

Re: Trimming priority:standard

2014-09-12 Thread Don Armstrong

On Thu, 11 Sep 2014, Russ Allbery wrote:
> wamerican provides /usr/share/dict/words, which is widely used in a
> variety of strange places you wouldn't expect, like random test
> suites.

If size is an issue, I'd also be OK with migrating wamerican-small to
standard (0.5M installed), and wamerican (1M installed) to optional.

This would also require some work besides just changing priority, as
whatever package is in standard should not depend on dictionaries
common, and manage the symlink itself; wamerican currently does this.

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

He no longer wished to be dead. At the same time, it cannot be said
that he was glad to be alive. But at least he did not resent it. He
was alive, and the stubbornness of this fact had little by little
begun to fascinate him -- as if he had managed to outlive himself, as
if he were somehow living a posthumous life.
 -- Paul Auster _City of Glass_


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912173254.gr7...@rzlab.ucr.edu

Re: Trimming priority:standard

2014-09-12 Thread Joey Hess

Theodore Ts'o wrote:
> One thought... there will probably be trademark concerns with "unix".[1]
> So we might have to choose a name for the tasksel task to be someting
> like "unix-like".

Or we could just call it "standard system".

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Trimming priority:standard

2014-09-12 Thread Josh Triplett

Theodore Ts'o wrote:
> On Fri, Sep 12, 2014 at 03:12:47PM +0100, Simon McVittie wrote:
> > 
> > (Admittedly, cron has to be Priority:important anyway, to support
> > logrotate - until/unless someone adds a logrotate.timer for systemd, and
> > makes its cron job early-return if systemd is pid 1.)
> 
> It's inevitable that systemd will subsume cron, with an incompatible
> configuration file format.  :-)

There's already a systemd-cron generator, which consumes crontab and
cron.d files and generates .timer units.

(And .timer is a perfectly compatible configuration file format: it's
compatible with .service file syntax. ;)  Which is actually rather
useful, since you can then use all the same syntax to control the
launched program.)

- Josh Triplett

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912174837.GA1348@jtriplet-mobl1

Re: Trimming priority:standard

2014-09-12 Thread Barry Warsaw

On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote:

>I'm looking forward for systemd-mta.

It's inevitable. ;)

http://catb.org/jargon/html/Z/Zawinskis-Law.html

-Barry


signature.asc
Description: PGP signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

2014-09-12 Thread Marc Haber

On Fri, 12 Sep 2014 16:27:58 +0200, Thorsten Glaser
 wrote:
>Nobody says jessie+1 will not permit running sysvinit any more,
>and the CTTE rulings explicitly did not touch that topic which
>implies some amount of scepsis.

sysvinit init scripts will suffer heavy bitrot in jessie+1.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xsy7p-0001vt...@swivel.zugschlus.de

Re: ppc64 not in any-powerpc ?

2014-09-12 Thread Johannes Schauer

Hi,

Quoting Andrey Rahmatullin (2014-09-12 18:14:55)
> On Fri, Sep 12, 2014 at 03:11:08PM +0200, Johannes Schauer wrote:
> > The common fallacy is that the "foo" in "any-foo" is the name of a Debian
> > architecture while in fact it is the name of the CPU which is mapped to one 
> > or
> > more Debian architectures by /usr/share/dpkg/triplettable
> Indeed, maybe we need to spell this more explicitly in the Policy?

Either that (footnote 99 [1] gives some more explanation) or change the meaning
of architecture wildcards into something more intuitive like os-debianarch as
it is probably understood by most developers because the existing values for
"cpu" happen to be (or used to be) debian architecture names.

Another relevant bug about this topic is #694630. I think this and the apt bug
#748936 give a good overview about how the current system works, why it exists
and how alternatives could/should look like.

Lintian successfully warns when things like "any-armel" are used in an attempt
to let the second part be a debian architecture instead of a cpu name, so we
don't have many of these in the archive. This is the relevant thread where I
tried to identify packages with invalid architecture wildcards:
http://lists.debian.org/2014052314.20924.60609@hoothoot

cheers, josch

[1] https://www.debian.org/doc/debian-policy/footnotes.html#f99

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912225415.3685.31745@hoothoot

Re: Allow encfs into jessie?

2014-09-12 Thread Brian May

On 13 September 2014 02:58, John Goerzen  wrote:

> is ecryptfs.  (LUKS and dm_crypt solve different problems.)  Compared to
>

Do you trust ecryptfs?

https://defuse.ca/audits/ecryptfs.htm says "eCryptfs appears to have a
better crypto design than EncFS [4], but there are some red flags
indicating that it was not designed by a cryptographer, and has not
received enough security review. It should be safe to use, but more
auditing would be a good idea."

I can't see any security audit for dm_crypt. I see google results that
suggest LUKS has been audited, but not the report.
-- 
Brian May

Re: Trimming priority:standard

2014-09-12 Thread John Goerzen

On 09/12/2014 02:27 PM, Barry Warsaw wrote:
> On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote:
>
>> I'm looking forward for systemd-mta.
>
> It's inevitable. ;)
>
> http://catb.org/jargon/html/Z/Zawinskis-Law.html
>
> -Barry
Just wait for systemd-emacs.  It would obsolete... all of gnuserv!

Bug#761343: ITP: piqi -- Universal schema language for JSON, XML, Protocol Buffers

2014-09-12 Thread Matthew Maurer

Package: wnpp
Severity: wishlist
Owner: Matthew Maurer 

* Package name: piqi
  Version : 0.6.8
  Upstream Author : Anton Lavrik 
* URL : http://piqi.org
* License : Apache-2.0
  Programming Lang: OCaml
  Description : Universal schema language for JSON, XML, Protocol Buffers

 Piqi is a universal schema language and a collection of tools built
 around it.
 The Piqi language can be used to define schemas for JSON, XML, Google
 Protocol Buffers and some other data formats.
 This package includes "piqi" command-line program that exposes some
 of the tools:
 - for validating, pretty-printing and converting data between JSON,
   XML, Protocol Buffers and Piq formats.
 - for working with the schemas, such as converting definitions between
   Piqi (.piqi) and Protocol Buffes (.proto), and "compiling" Piqi
   definitions into one of the supported portable data representation
   formats (JSON, XML, Protocol Buffers).
 Other Piqi sub-projects include:
 - A multi-format (JSON, XML, Protocol Buffers) data serialization
   system for Erlang and OCaml.
 - Piq -- a human-friendly typed data representation language. It is
   designed to be more convenient for viewing and editing data compared
   to JSON, XML, CSV, S-expressions and other formats.
 - Piqi-RPC -- an RPC-over-HTTP system for Erlang. It provides a simple
   way to expose Erlang services via JSON, XML and Protocol Buffers
   over HTTP.
 The Piqi project was inspired by Google Protocol Buffers and designed to
 be largely compatible with it. Like Protocol Buffers, Piqi relies on
 type definitions and supports schema evolution. The main differences is
 that Piqi has a richer data model, high-level modules, standard mappings
 to JSON and XML, and comes with a powerful data representation format
 (Piq). Also, Piqi is a lot more extensible.

This package is useful as the primary gateway between OCaml/Erlang code and
Protocol Buffer serialized data. As such, it is important to keeping those two
languages able to speak efficiently to others.

Additionally, piqi is a dependency of piqi-ocaml, and piqi-erlang, which
provides the runtime libraries used by OCaml and Erlang respectively 
to access Protocol Buffers via piqi.

My hope is that long term maintenance could be supported by the OCaml Team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140913025218.1798.68215.reportbug@1159102519a3

Re: Trimming priority:standard

2014-09-12 Thread Manoj Srivastava

Hi, 

  Huh. I have been waiting for emacs/lisp/systemd.el

  Manoj 

On September 12, 2014 7:49:45 PM PDT, John Goerzen  
wrote:
>On 09/12/2014 02:27 PM, Barry Warsaw wrote:
>> On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote:
>>
>>> I'm looking forward for systemd-mta.
>>
>> It's inevitable. ;)
>>
>> http://catb.org/jargon/html/Z/Zawinskis-Law.html
>>
>> -Barry
>Just wait for systemd-emacs.  It would obsolete... all of gnuserv!

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

Hi,

Marc Haber:
> sysvinit init scripts will suffer heavy bitrot in jessie+1.
> 
Possibly. But let's get Jessie out the door first …
-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140913035810.ge19...@smurf.noris.de

Re: Trimming priority:standard

Hi,

Edward Allcutt:
> On Fri, 12 Sep 2014, Josh Triplett wrote:
> >>* telnet: dead for 19 years.  Used only by those who misspell 'nc' and hope
> >>  for no 0xff bytes.
> 
> A slight exaggeration. A client that uses the actual telnet protocol is
> still invaluable for managing various fairly stupid devices.
> 
So use "nc -t" if you need it. Better to make the unsafe behavior explicit.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140913040434.gf19...@smurf.noris.de

Re: Seeking help with OpenVPN scripts and systemd