Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Matthias Urlichs]

Hi,

Jean-Yves Avenard:
> Including rename of constants (code enums id for example).

Another nail in libav's coffin, then.

IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.

> Keeping your own static version is the only reasonable approach.

That may be OK on Windows. However, a proper Linux distribution is supposed
to be an integrated whole and not a haphazard collection of programs, each
bringing along their own copy of core libraries and their own un- or
semi-fixed security problems.

-- 
-- 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/20140810070126.gr1...@smurf.noris.de

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andrew Kelley]

On Sun, Aug 10, 2014 at 12:01 AM, Matthias Urlichs 
wrote:

> Jean-Yves Avenard:
> > Including rename of constants (code enums id for example).
>
> Another nail in libav's coffin, then.
>
> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for another release or two.


High quality libraries must iterate on their API. Especially for a library
trying to solve such a complex problem as audio and video encoding and
decoding for every codec and format. It is unreasonable to expect no
incompatible changes. Also both ffmpeg and libav codebases have a lot of
legacy cruft. Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Matthias Urlichs]

Hi,

Andrew Kelley:
> It is unreasonable to expect no incompatible changes.

When somebody renames constants, a compatibility #ifdef or two is not too
much to ask, IMHO.

> Libav is making a more concentrated effort at improving this,
> and the evolving API is a side-effect of that.

That begs the question whether they're still essentially the same library,
i.e. whether it's at all reasonable to expect code built using FFmpeg to
work with libav. Consequently, Debian should at least include it, even
if it really _is_ too late to switch (which I'm not conviced of).

-- 
-- 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/20140810074303.gb1...@smurf.noris.de

Bug#757647: ITP: python-lz4 -- Python interface to the lz4 compression library

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: python-lz4
Version: 0.7.0
Upstream Author: Steeve Morin 
URL: http://pypi.python.org/pypi/lz4
License: BSD-3-clause
Description: Python interface to the lz4 compression library
 This package provides bindings for the liblz4 compression library.
 .
 LZ4 is a very fast lossless compression algorithm, providing compression
 speed at 400 MB/s per core, scalable with multi-cores CPU. It also
 features an extremely fast decoder, with speed in multiple GB/s per core,
 typically reaching RAM speed limits on multi-core systems.



Initial packaging is available from 

http://anonscm.debian.org/gitweb/?p=collab-maint/python-lz4.git


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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Jean-Yves Avenard]

Hi

On 10 August 2014 17:01, Matthias Urlichs  wrote:
> Hi,
>
>
> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for another release or two.
>

Then it becomes unreasonable for a piece of software to be compatible
with multiple version of the same library, and support all of those.

When a used come to use complaining that something is broken, that a
file doesn't play or what else. It's a moot point trying to expect
them to understand that the issue is due to a 3rd party library.

MythTV aimed to be an appliance-like application. You install it and
you forget about it.


-- 
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/CANpj82JkPYGbXDC+mkEkACrYZ0H01+6Ng_UniPZ_bvHMG07p=q...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andrew Kelley]

On Sun, Aug 10, 2014 at 1:48 AM, Jean-Yves Avenard 
wrote:

> Then it becomes unreasonable for a piece of software to be compatible
> with multiple version of the same library, and support all of those.
>

IMO it's not worth the effort to support multiple versions of the same
library. If you want to use an old library, use an old version of the
software.

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Jean-Yves Avenard]

On 10 August 2014 18:53, Andrew Kelley  wrote:
> IMO it's not worth the effort to support multiple versions of the same
> library. If you want to use an old library, use an old version of the
> software.

In our case, we have very long release cycles. Usually only once a
year at best. We have users on virtually all platforms. We can't
assume the OS/distribution it will be running on will have the library
we're hoping for.

In the perfect world, sure all platforms would all be running the same
versions of a given lib at a given time... In practice it never
happens.


-- 
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/CANpj82L-GU18cPF=euuukhpknpdy_cvk+ax2w89ydmwksb4...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Peter B.]

On 08/08/2014 09:22 PM, Matthias Urlichs wrote:
> We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
> hate to report some intractable codec bug which Upstream closes with
> an "it works with FFmpeg" comment

Oh, btw, just a few days ago, that's exactly what happened on kdenlive [1].
A developer posted the following statement on an issue which is open for
more than 1.5 years now:

[quote]
Confirm this is a libav problem, use builds with ffmpeg or wait debian
(&derivatives) to bring ffmpeg back
[/quote]

Just thought this might fit here...


Regards,
Pb


== References:
[1] http://www.kdenlive.org/mantis/view.php?id=2943#c10195


-- 
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/53e7388b.8030...@das-werkstatt.com

Time to drop debcheck on optional/extra and arch:all?

[Neil Williams]

The distinction between optional and extra is commonly ignored and yet
debcheck continues to add reports to the PTS about packages which
have dependencies which crossover from optional into extra.

Do we care about any distinction between optional and extra any longer?
From previous conversations with some members of the ftp team, it seems
to be regarded as either irrelevant or historical legacy.

Is it in any way relevant to how Debian is installed, maintained or
used?

If not, can we remove this feature from debcheck? 

Personally, I can't see that it's worth "fixing" the actual priorities
of packages which are priority optional but have dependencies on
packages which are priority extra. So shouldn't debcheck just not
report these "issues" any longer? Other priorities are probably worth
checking but IMHO optional and extra may as well be considered as a
single set within debcheck.

There's also the issue of debcheck handling of Arch:all packages which
depend on architecture-dependent packages with a limited set of
architectures. It isn't helpful for the PTS to have "issues" reported
about an Arch:all package on non-linux ports depending on a package
which is only available on linux:any. It seems that debcheck is taking
a very simplistic view of that and should really only report if an
architecture-dependent package depends on a package which is not
available on the same arch.

A QA nag tool which is so commonly ignored is possibly not even worth
running.

-- 


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



signature.asc
Description: PGP signature

Re: Time to drop debcheck on optional/extra and arch:all?

[Paul Wise]

On Sun, Aug 10, 2014 at 7:31 PM, Neil Williams wrote:

> Do we care about any distinction between optional and extra any longer?

I would say no we don't and suggest these steps:

Remove it from policy:

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

Get dak to override all extra packages to optional.

Drop extra handling from debcheck.

> There's also the issue of debcheck handling of Arch:all packages which
> depend on architecture-dependent packages with a limited set of
> architectures. It isn't helpful for the PTS to have "issues" reported
> about an Arch:all package on non-linux ports depending on a package
> which is only available on linux:any. It seems that debcheck is taking
> a very simplistic view of that and should really only report if an
> architecture-dependent package depends on a package which is not
> available on the same arch.

I think this illustrates a couple of minor deficiencies wrt Debian and
arch-independent packages. There isn't any way to have depends that
should be only for certain arches. There isn't any way to restrict
which arches list arch-independent packages in their package lists.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Michael Niedermayer]

On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
[...]

> ... and was designed by a larger
> group instead of libswresample which was basically one person (and
> literally appeared in git out of nowhere).

For the record:
$ git shortlog libswresample/ | grep '^[^ ]'
Alexander Strasser (1):
Andreas Cadhalpun (1):
Andrew Wason (1):
Carl Eugen Hoyos (4):
Clément Bœsch (45):
Derek Buitenhuis (1):
Hendrik Leppkes (1):
James Almer (19):
Justin Ruggles (4):
Lou Logan (2):
Mans Rullgard (3):
Martin Storsjö (1):
Marton Balint (2):
Matt Oliver (2):
Michael Niedermayer (308):
Nicolas George (8):
Paul B Mahol (4):
Reimar Döffinger (3):
Rob Sykes (7):
Ronald S. Bultje (15):
Stefano Sabatini (6):
Timothy Gu (10):
jamal (2):

$ git shortlog libavresample/ | grep '^[^ ]'
Anton Khirnov (25):
Derek Buitenhuis (2):
Diego Biurrun (22):
Hendrik Leppkes (1):
James Almer (2):
Janne Grunau (5):
John Stebbins (2):
Justin Ruggles (71):
Luca Barbato (1):
Mans Rullgard (4):
Martin Storsjö (6):
Michael Niedermayer (97):
Peter Meerwald (1):
Reimar Döffinger (2):
Ronald S. Bultje (2):
Thilo Borgmann (1):
Tim Walker (2):


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Kieran Kunhya]

On 10 August 2014 13:38, Michael Niedermayer  wrote:
> On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
> [...]
>
>> ... and was designed by a larger
>> group instead of libswresample which was basically one person (and
>> literally appeared in git out of nowhere).

http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b5875b91113a0f3de6ad61e9ff8b74b81de94760

There was no mailing list discussion and initial bugs had to be
discussed on ffmpeg-cvs. It appeared out of nowhere and there was no
discussion about the API. Many of the contributors were cleaning the
inline asm up or various other fixes or had worked on the original
resample code.

The comparison you make is highly misleading. On the other hand
libavresample was developed by consensus and the API discussed
beforehand.


-- 
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/cak+ulv4crhyvmfohmdlixdnsmyvezknplqartx3hpr-hkcv...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reinhard Tartler]

On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs  wrote:
> Hi,
>
> Jean-Yves Avenard:
>> Including rename of constants (code enums id for example).
>
> Another nail in libav's coffin, then.

That's one way to see it. To me, this makes mythtv unsuitable for
inclusion into Debian. Let me explain why:

> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for another release or two.

This is exactly what Libav is doing: The deprecation process for
symbols, APIs, enums, etc. takes *years*, because so many software
packages in Debian and else where use them, and it is so believably
painful to change them. Just have a look at the last two Libav
transitions, and the massive amount of patches it took to get packages
fixed and eventually to get Debian to the new Libav release.

Now enter FFmpeg.

FFmpeg has a significant higher release frequency, (it seems to me
about every 3-4 months), so that you would get a deprecation cycle
that is considerably less than a year. In practice, the deprecation
cycle more or less seems to match Libav's cycle, because at least
right now, FFmpeg  tracks Libav's API. If that were not the case (and
I promise you FFmpeg would stop tracking Libav as soon as it replaces
Libav in Debian), I can almost guarantee [1] you that FFmpeg would
very much prefer to resume to the deprecation cycle the project
before: None, i.e., every piece of software is expected to keep up
with FFmpeg's master branch for reasons Jean-Yves outlines.

[1] at least statements such as
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html
strongly suggest this (at least if you have followed  the
libavresample/libswresample mess).

>> Keeping your own static version is the only reasonable approach.
>
> That may be OK on Windows. However, a proper Linux distribution is supposed
> to be an integrated whole and not a haphazard collection of programs, each
> bringing along their own copy of core libraries and their own un- or
> semi-fixed security problems.
>

BTW Jean-Yves outlines an approach that used to be very common on the
past: Pick some particular snapshot of FFmpeg and maintain that in a
downstream project, and expect users to use that because it is too
much effort to keep up with FFmpeg's release frequency. Prominent
examples of projects that did this (and actually, still do) include
xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess
I was talking about in my previous email: dozens of embedded
code-copies that were accepted into the Debian archive.

Over many years, I've spearheaded a significant effort in Debian with
packaging and in upstream with introducing a release culture in FFmpeg
(as release manager) to get to somewhat same release frequencies, so
that downstream projects at least had a chance to agree on common
versions of FFmpeg. At the time of the split, I was worried that this
work would have been in vain. Considering that most active developers
of FFmpeg at that time (which coincidentally supported my approach to
release management and frequency) joined what is now known as Libav, I
continued my work as upstream release manager in Libav, because I
consider Libav as much more suited for Debian than FFmpeg. Today, I
still firmly believe that this was the right move for Debian as a
project.

I do strongly believe that projects that require people to use FFmpeg
actually mean to use their own private fork (cf. the mythtv debacle),
and given the amount of packages in Debian, it would significantly
much more effort to "port" (or "patch" as Andreas is phrasing it) them
to some common version of FFmpeg than doing what we are doing now:
Making sure they work with the version of Libav's libavcodec.so
implementation. This thread has shown a couple of examples that
support this argument: Mythtv, but also mplayer that claims to work
with a system libavcodec.so, which is true as long as it matches the
version that is was built against. This is what makes mplayer so hard
to package, and was ultimately the reason why I requested mplayer's
removal (which is more than ironic, given that back then, I fought
with ftp-master for many years to get it included into Debian in the
first place).

On a related note: Most  Libav developers are very tired of the
constant flamewars and defamation attempts that arises from FFmpeg.
Over years, Libav tries to convinced everyone by providing usable
software releases. Nevertheless, this particular debate is very
worrisome: The silence from the Libav camp seems to not to be taken as
consent. Quite the contrary is true.

How to proceed from here? TBH, I'm not sure. Ideally, both projects
would find some common ground and "just merge" (however that would
technically look like). However, this very debate within Debian shows
that this is unlikely to happen anytime soon: There is way to much
disagreement on very fundamental questions that require agreement
within a free software project, and the hostile and 

Not the only one. Was: Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 09 August 2014 18:46:09 Steve Langasek wrote:
[snip] 
> Which according to elsewhere in my mailbox, you've dealt with by uploading a
> 10-day delayed NMU.  This is unacceptable.  The NMU process always requires
> that you send your NMU diff to the BTS for review by the maintainer
> *first*. When doing a delayed NMU, it's reasonable to send this diff to the
> BTS at the same time.  Here, you have failed to send this NMU diff at all,
> and the only notification has been an easily-overlooked mail from the
> ftp-master queue software.
> 
> Maintainers should not have to go grubbing around in the delayed queue to
> find out what's been uploaded.  The NMUer is responsible for sending the NMU
> diff to the maintainer.
> 
> I have removed pam_1.1.3-8.1_amd64.changes from the delayed queue.  If you
> have changes that you would like to see included in this package, please
> send them to the BTS where they belong.

Interesting, because yesterday I've got a patch [0] (cool, thanks a lot!) but 
stating that the package has been NMUed and uploaded to delayed/5. So, even 5 
less days than in your case.

Less than 5 minutes later, the package entered the archive [1].

So, what am I supposed to do here?

Doko: I *really* appreciate the fact that you sent a patch, but *please* 
respect your fellow DDs.

[0] 
[1] 

-- 
Una sola bomba nuclear puede arruinar el resto de tu día.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#757687: ITP: ruby-request-store -- per-request global variable storage for Rack-based web servers

[Caitlin Matos]

Package: wnpp
Severity: wishlist
Owner: Caitlin Matos 

* Package name: ruby-request-store
  Version : 1.0.8
  Upstream Author : Steve Klabnik 
* URL : http://github.com/steveklabnik/request_store
* License : MIT/Expat
  Programming Lang: Ruby
  Description : per-request global variable storage for Rack-based web
servers

RequestStore gives you per-request global storage of variables for Rack-
compliant web servers. It is intended as an alternative to Thread.current, to
avoid bugs in threaded server implementations. RequestStore supports Rails 3+
out-of-the-box, but can be configured for use in Rails 2.x and non-Rails
environments.

This package is a new dependency for ruby-gon.

It will be maintained within the Debian Ruby 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/20140810132304.27605.92347.reportbug@crunchbang

Rebuilding the archive with new build flags

[Romain Francoise]

Hi all,

A few weeks ago I mentioned on -devel[1] that dpkg-buildflags would be
switching from -fstack-protector to -fstack-protector-strong, a new GCC
4.9 feature. This change has now landed in unstable with dpkg 1.17.11.

Moritz tells me that the Security Team can request binNMUs for a set of
packages that have been identified as security-sensitive[2] if they
don't get rebuilt with the new flag by the time we freeze for jessie.

However, I think it would be better to ensure maximum coverage of the
archive by rebuilding everything that can benefit from the flag, i.e.
all the packages that use dpkg-buildflags via debhelper >= 9 or cdbs,
and produce arch:any binaries.

Has this kind of mass binNMU been attempted before? Who would I need to
talk to to get this done at least on amd64 and i386 before the freeze?

Thanks,

[1]: https://lists.debian.org/debian-devel/2014/06/msg00453.html
[2]: http://anonscm.debian.org/viewvc/secure-testing/hardening/
-- 
Romain Francoise 
http://people.debian.org/~rfrancoise/


signature.asc
Description: PGP signature

Re: Not the only one. Was: Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues

[Matthias Klose]

Am 10.08.2014 um 15:25 schrieb Lisandro Damián Nicanor Pérez Meyer:
> Interesting, because yesterday I've got a patch [0] (cool, thanks a lot!) but 
> stating that the package has been NMUed and uploaded to delayed/5. So, even 5 
> less days than in your case.
> 
> Less than 5 minutes later, the package entered the archive [1].
> 
> So, what am I supposed to do here?
> 
> Doko: I *really* appreciate the fact that you sent a patch, but *please* 
> respect your fellow DDs.

The first thing you can do is to stop assuming bad faith, instead of assuming a
mistake. I wouldn't have sent an email to the bug report and then uploading the
package by intent. So sorry about the unplanned immediate upload.

I wasn't aware that we are still supposed to do delayed/10 uploads, now that the
default priority for uploads is medium.

The issue was filed on May 4, with severity important and tagged for jessie. No
reaction. The severity was raised on May 30 to serious. No reaction.  Instead
some severity ping-pong was played on other issues.  No reaction on a RC issue
for over two months?

  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/53e77933.9000...@debian.org

Re: Not the only one. Was: Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues

[Manuel A. Fernandez Montecelo]

Hi,

2014-08-10 14:25 Lisandro Damián Nicanor Pérez Meyer:

On Saturday 09 August 2014 18:46:09 Steve Langasek wrote:
[snip]

Which according to elsewhere in my mailbox, you've dealt with by uploading a
10-day delayed NMU.  This is unacceptable.  The NMU process always requires
that you send your NMU diff to the BTS for review by the maintainer
*first*. When doing a delayed NMU, it's reasonable to send this diff to the
BTS at the same time.  Here, you have failed to send this NMU diff at all,
and the only notification has been an easily-overlooked mail from the
ftp-master queue software.

Maintainers should not have to go grubbing around in the delayed queue to
find out what's been uploaded.  The NMUer is responsible for sending the NMU
diff to the maintainer.

I have removed pam_1.1.3-8.1_amd64.changes from the delayed queue.  If you
have changes that you would like to see included in this package, please
send them to the BTS where they belong.


Interesting, because yesterday I've got a patch [0] (cool, thanks a lot!) but
stating that the package has been NMUed and uploaded to delayed/5. So, even 5
less days than in your case.

Less than 5 minutes later, the package entered the archive [1].

So, what am I supposed to do here?

Doko: I *really* appreciate the fact that you sent a patch, but *please*
respect your fellow DDs.

[0] 
[1] 



I agree that in the case that Steve is complaining about, the NMUer
should have sent the diff.  It was probably an oversight, I probably
wouldn't be so concerned as Steve about it as to send an email to
debian-devel@, or maybe yes...

In this case of qtwebkit, I agree that it *could* have been sent to
delayed, especially since KDE team is generally active and so on (and
because it was mentioned in the e-mail).

But on the other hand, a FTBFS bug in an important package such as
qtwebkit, reported 3 months ago and set to priority serious more than
2 months ago, with no replies from the maintainers, and being a quite
trivial fix as it is (not a patch changing behaviour, just silencing
compiler warnings about unused functions), I think that there also
perfectly justificable to upload straight away instead of to DELAYED.

I for one agree with the guidelines as stated here, and Matthias
respected them:

http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

 "Upload fixing only release-critical bugs older than 7 days, with no
  maintainer activity on the bug for 7 days and no indication that a
  fix is in progress: 0 days"


I appreciate that the team is busy and all, but adding the changes
from a NMUdiff is not too much extra job in my experience (if that's
what you find annoying about it?).


Cheers.
--
Manuel A. Fernandez Montecelo 


--
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/20140810140842.ga19...@lugh.itsari.org

Re: Not the only one. Was: Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues

[gregor herrmann]

On Sun, 10 Aug 2014 15:52:51 +0200, Matthias Klose wrote:

> I wasn't aware that we are still supposed to do delayed/10 uploads, now that 
> the
> default priority for uploads is medium.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines
recommends:

* Upload fixing only release-critical bugs older than 7 days, with no
  maintainer activity on the bug for 7 days and no indication that a
  fix is in progress: 0 days

* Upload fixing only release-critical bugs older than 7 days: 2 days

* Upload fixing only release-critical and important bugs: 5 days

* Other NMUs: 10 days

So I think DELAYED/10 would indeed have been unneeded here.
 

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tracy Chapman: Almost


signature.asc
Description: Digital Signature

Re: Not the only one. Was: Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 10 August 2014 15:52:51 Matthias Klose wrote:
> Am 10.08.2014 um 15:25 schrieb Lisandro Damián Nicanor Pérez Meyer:
> > Interesting, because yesterday I've got a patch [0] (cool, thanks a lot!)
> > but stating that the package has been NMUed and uploaded to delayed/5.
> > So, even 5 less days than in your case.
> > 
> > Less than 5 minutes later, the package entered the archive [1].
> > 
> > So, what am I supposed to do here?
> > 
> > Doko: I *really* appreciate the fact that you sent a patch, but *please*
> > respect your fellow DDs.
> 
> The first thing you can do is to stop assuming bad faith, instead of
> assuming a mistake. I wouldn't have sent an email to the bug report and
> then uploading the package by intent. So sorry about the unplanned
> immediate upload.
> 
> I wasn't aware that we are still supposed to do delayed/10 uploads, now that
> the default priority for uploads is medium.
> 
> The issue was filed on May 4, with severity important and tagged for jessie.
> No reaction. The severity was raised on May 30 to serious. No reaction. 
> Instead some severity ping-pong was played on other issues.  No reaction on
> a RC issue for over two months?

I stand corrected. My public apologies for this, specially to you Matthias.

Maybe I need some VACs :)


-- 
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
  Unknown - http://www.linfo.org/q_unix.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Time to drop debcheck on optional/extra and arch:all?

[Russ Allbery]

Paul Wise  writes:
> On Sun, Aug 10, 2014 at 7:31 PM, Neil Williams wrote:

>> Do we care about any distinction between optional and extra any longer?

> I would say no we don't and suggest these steps:

> Remove it from policy:

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

> Get dak to override all extra packages to optional.

> Drop extra handling from debcheck.

Agreed.

> I think this illustrates a couple of minor deficiencies wrt Debian and
> arch-independent packages. There isn't any way to have depends that
> should be only for certain arches.

Yes, which is because of the deeper problem that architecture restrictions
in dependency fields are a preprocessor feature instead of a feature of
the dependency system.  So you can use architecture-specific dependencies,
but only for architecture-specific packages.  (Hm.  I see that isn't
documented in Policy at all -- I do have this right, don't I?)

Elevating architecture-specific dependencies to a first-class part of the
syntax seems like a good long-term improvement to me, although of course
everything that parses dependency fields will need to be updated, which is
daunting.

> There isn't any way to restrict which arches list arch-independent
> packages in their package lists.

That would be very nice.

-- 
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: https://lists.debian.org/87r40omgei@windlord.stanford.edu

Re: Time to drop debcheck on optional/extra and arch:all?

[Ansgar Burchardt]

Hi,

Russ Allbery  writes:
> Paul Wise  writes:
>> I think this illustrates a couple of minor deficiencies wrt Debian and
>> arch-independent packages. There isn't any way to have depends that
>> should be only for certain arches.
>
> Yes, which is because of the deeper problem that architecture restrictions
> in dependency fields are a preprocessor feature instead of a feature of
> the dependency system.  So you can use architecture-specific dependencies,
> but only for architecture-specific packages.  (Hm.  I see that isn't
> documented in Policy at all -- I do have this right, don't I?)

It is documented in section 7.1: "This means that architecture
restrictions must not be used in binary relationship fields for
architecture-independent packages (Architecture: all)".

Ansgar


-- 
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/87ppg846lv@deep-thought.43-1.org

Re: Time to drop debcheck on optional/extra and arch:all?

[Neil Williams]

found 477990 3.9.5.0
thanks

On Sun, 10 Aug 2014 20:09:35 +0800
Paul Wise  wrote:

> On Sun, Aug 10, 2014 at 7:31 PM, Neil Williams wrote:
> 
> > Do we care about any distinction between optional and extra any
> > longer?
> 
> I would say no we don't and suggest these steps:
> 
> Remove it from policy:
> 
> https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
>

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477990

Fri, 25 Apr 2008 23:39:50 -0700

That's quite an old bug. Time it is resolved?

-- 


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



signature.asc
Description: PGP signature

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Kees de Jong]

Why are we discussing CD/DVD sizes? Why not just use an USB
netinstall? It's then possible to download and install the stuff you
need, if you don't want to use a lot of bandwidth then choose no
desktop environment or XFCE/LXDE. But if you can spare some more time
then you can install GNOME/KDE. Seems like a good deal. And USB sticks
are cheaper (also easier to reuse) so I don't get the 'hurting
developing countries' argument.


-- 
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/CAAH150ZMiVBtY21Es06y3djZrQ+=eAEYDenLJJoYby=ajos...@mail.gmail.com

Bug#757720: ITP: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix

[Oxan van Leeuwen]

Package: wnpp
Severity: wishlist
Owner: Oxan van Leeuwen 

* Package name: postsrsd
  Version : 1.1
  Upstream Author : Timo Röhling 
* URL : https://github.com/roehling/postsrsd
* License : GPL-2+
  Programming Lang: C
  Description : Sender Rewriting Scheme (SRS) lookup table for Postfix

PostSRSd provides Sender Rewriting Scheme (SRS) support for Postfix via 
TCP-based lookup tables. SRS is needed if your mail server acts as a forwarder, 
and the mail originates from a server with Sender Policy Framework (SPF) 
enabled. 


-- 
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/debian-devel

Re: Bug#757555: pam: CVE-2014-2583 pam_timestamp directory traversal issues

[Michael Gilbert]

control: tag -1 patch

On Sat, Aug 9, 2014 at 9:46 PM, Steve Langasek wrote:
> Which according to elsewhere in my mailbox, you've dealt with by uploading a
> 10-day delayed NMU.  This is unacceptable

Sorry for not getting the nmu mail out in a timely manner, but real
life got in the way.

What is not acceptable is the assumed bad faith and the misguided
attempt at public shaming (after only half a day) without considering
the possibility of RL events or other benign possibilities.  A simple
"hey, what's going on with this thing I'm seeing in deferred" mail
directed at me would have been the kind thing to do.

> I have removed pam_1.1.3-8.1_amd64.changes from the delayed queue.  If you
> have changes that you would like to see included in this package, please
> send them to the BTS where they belong.

The proposed patch is now attached.  I plan to upload that to
delayed/5 after about a week or so to give you lots of additional time
for review (way more than the normal nmu process requires).

Best wishes,
Mike
diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
--- pam-1.1.8/debian/changelog
+++ pam-1.1.8/debian/changelog
@@ -1,3 +1,13 @@
+pam (1.1.8-3.1) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix CVE-2013-7041: case-insensitive comparison used for verifying
+passwords in the pam_userdb module (closes: #731368).
+  * Fix CVE-2014-2583: multiple directory traversal issues in the
+pam_timestamp module (closes: 757555)
+
+ -- Michael Gilbert   Sat, 09 Aug 2014 09:50:42 +
+
 pam (1.1.8-3) unstable; urgency=low
 
   * debian/rules: On hurd, link libpam explicitly with -lpthread since glibc
diff -u pam-1.1.8/debian/patches-applied/series pam-1.1.8/debian/patches-applied/series
--- pam-1.1.8/debian/patches-applied/series
+++ pam-1.1.8/debian/patches-applied/series
@@ -23,0 +24,2 @@
+cve-2013-7041.patch
+cve-2014-2583.patch
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/cve-2013-7041.patch
+++ pam-1.1.8/debian/patches-applied/cve-2013-7041.patch
@@ -0,0 +1,44 @@
+From 57a1e2b274d0a6376d92ada9926e5c5741e7da20 Mon Sep 17 00:00:00 2001
+From: "Dmitry V. Levin" 
+Date: Fri, 24 Jan 2014 22:18:32 +
+Subject: pam_userdb: fix password hash comparison
+
+Starting with commit Linux-PAM-0-77-28-g0b3e583 that introduced hashed
+passwords support in pam_userdb, hashes are compared case-insensitively.
+This bug leads to accepting hashes for completely different passwords in
+addition to those that should be accepted.
+
+Additionally, commit Linux-PAM-1_1_6-13-ge2a8187 that added support for
+modern password hashes with different lengths and settings, did not
+update the hash comparison accordingly, which leads to accepting
+computed hashes longer than stored hashes when the latter is a prefix
+of the former.
+
+* modules/pam_userdb/pam_userdb.c (user_lookup): Reject the computed
+hash whose length differs from the stored hash length.
+Compare computed and stored hashes case-sensitively.
+Fixes CVE-2013-7041.
+
+Bug-Debian: http://bugs.debian.org/731368
+
+--- a/modules/pam_userdb/pam_userdb.c
 b/modules/pam_userdb/pam_userdb.c
+@@ -222,12 +222,15 @@ user_lookup (pam_handle_t *pamh, const char *database, const char *cryptmode,
+ 	  } else {
+ 	cryptpw = crypt (pass, data.dptr);
+ 
+-	if (cryptpw) {
+-	  compare = strncasecmp (data.dptr, cryptpw, data.dsize);
++	if (cryptpw && strlen(cryptpw) == (size_t)data.dsize) {
++	  compare = memcmp(data.dptr, cryptpw, data.dsize);
+ 	} else {
+ 	  compare = -2;
+ 	  if (ctrl & PAM_DEBUG_ARG) {
+-		pam_syslog(pamh, LOG_INFO, "crypt() returned NULL");
++		if (cryptpw)
++		  pam_syslog(pamh, LOG_INFO, "lengths of computed and stored hashes differ");
++		else
++		  pam_syslog(pamh, LOG_INFO, "crypt() returned NULL");
+ 	  }
+ 	};
+ 
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/cve-2014-2583.patch
+++ pam-1.1.8/debian/patches-applied/cve-2014-2583.patch
@@ -0,0 +1,47 @@
+From 9dcead87e6d7f66d34e7a56d11a30daca367dffb Mon Sep 17 00:00:00 2001
+From: "Dmitry V. Levin" 
+Date: Wed, 26 Mar 2014 22:17:23 +
+Subject: pam_timestamp: fix potential directory traversal issue (ticket #27)
+
+pam_timestamp uses values of PAM_RUSER and PAM_TTY as components of
+the timestamp pathname it creates, so extra care should be taken to
+avoid potential directory traversal issues.
+
+* modules/pam_timestamp/pam_timestamp.c (check_tty): Treat
+"." and ".." tty values as invalid.
+(get_ruser): Treat "." and ".." ruser values, as well as any ruser
+value containing '/', as invalid.
+
+Fixes CVE-2014-2583.
+
+Reported-by: Sebastian Krahmer 
+
+--- a/modules/pam_timestamp/pam_timestamp.c
 b/modules/pam_timestamp/pam_timestamp.c
+@@ -158,7 +158,7 @@ check_tty(const char *tty)
+ 		tty = strrchr(tty, '/') + 1;
+ 	}
+ 	/* Make sure the tty wasn't actually a directory (no basename). */
+-	if (strlen(tty) == 0) {
++	if (!strlen(tty) || !strcmp(tty, ".") || !strcmp(tty

Re: Time to drop debcheck on optional/extra and arch:all?

[Jakub Wilk]

* Neil Williams , 2014-08-10, 12:31:
The distinction between optional and extra is commonly ignored and yet 
debcheck continues to add reports to the PTS about packages which have 
dependencies which crossover from optional into extra.


Do you mean the "debcheck" link in the "links" box? Or is there another 
place where debcheck pops out on PTS that I can't see?



Do we care about any distinction between optional and extra any longer?


I like "extra". If it was used in a policy-compliant way, it would be 
more useful than "standard", "important" or "required". But if we decide 
to kill it, I'm not going to cry over it.


However, I don't think we should take any decision before we understand 
what is the problem size. That is, what is the number of packages that 
would have to have their priority adjusted to make all extra<->optional 
priority inversions go away? I assume that would be mostly 
s/extra/optional/ changes.


A QA nag tool which is so commonly ignored is possibly not even worth 
running.


Being wildly ignored is a common property of all QA tools...

And the tool popularity doesn't depend only on the quality of its 
checks, but also on the way the results are delivered to maintainers.


debcheck is never going to be successful if the maintainer has to find 
the link in the PTS jungle, and then they are presented with something 
as concise as this:

https://qa.debian.org/debcheck.php?dist=unstable&package=awesome
To add insult to injury, most likely the maintainer can't do much about 
the reported problems themselves, because they should be fixed by 
ftp-masters and maintainers of the dependent packages.


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

Re: Reverting to GNOME for jessie's default desktop

[David Weinehall]

On Fri, Aug 08, 2014 at 11:10:50AM +0200, Jonas Smedegaard wrote:
> 
> The issue here really is "how big is it?" rather than "hos many disks 
> [of which kind] does it fit onto?".
> 
> "unable to fit on a single image" is not only about use of said storage 
> devices for installation, but also an indication more generally of how 
> much data needs to be transfered on average for a usable installation.
> 
> Quite a few places in the World have poor and/or expensive internet 
> access.  Larger default desktop will hurt the most in developing 
> countries: non-techies gets discourages to use Debian at all, or when 
> using it may apply security fixes less often.

In all cases where I'm stuck with expensive (and/or slow) Internet
I sure as hell pick the netinst image and download the minimum set of
packages I need, rather than a whole CD image on the offhand chance that
I might need everything on it (which is exceedingly unlikely).

If, on the other hand, I download a CD-image somewhere else to burn it
and then bring it home, the image will always be full CD-size (or are
you suggesting that we start distributing half-empty CD-images?).

So, as long as GNOME fits on the first installation CD I see no reason
not to prefer it over XFCE.


Kind regards, David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20140810205944.gc2...@hirohito.acc.umu.se

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi Reinhard,

On 10.08.2014 15:10, Reinhard Tartler wrote:

On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs  wrote:

IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.


This is exactly what Libav is doing: The deprecation process for
symbols, APIs, enums, etc. takes *years*, because so many software
packages in Debian and else where use them, and it is so believably
painful to change them. Just have a look at the last two Libav
transitions, and the massive amount of patches it took to get packages
fixed and eventually to get Debian to the new Libav release.

Now enter FFmpeg.


FFmpeg also has a deprecation process and keeps deprecated features 
around longer than Libav. For example, avcodec_encode_video, 
av_close_input_file and avcodec_decode_audio3 are still present in 
FFmpeg, but already removed from Libav.



FFmpeg has a significant higher release frequency, (it seems to me
about every 3-4 months), so that you would get a deprecation cycle
that is considerably less than a year.


The deprecation cycle is not related to the release frequency, as many 
FFmpeg release are API/ABI backwards compatible with the previous one.



In practice, the deprecation
cycle more or less seems to match Libav's cycle, because at least
right now, FFmpeg  tracks Libav's API. If that were not the case (and
I promise you FFmpeg would stop tracking Libav as soon as it replaces
Libav in Debian), I can almost guarantee [1] you that FFmpeg would
very much prefer to resume to the deprecation cycle the project
before: None, i.e., every piece of software is expected to keep up
with FFmpeg's master branch for reasons Jean-Yves outlines.


I think you won't be able to keep that promise, because it wouldn't make 
much sense to stop merging changes from Libav (especially, if they are 
useful) after doing it for such a long time. Even in the unlikely event 
that this might happen, there is no reason to change the handling of 
deprecations.



[1] at least statements such as
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html
strongly suggest this (at least if you have followed  the
libavresample/libswresample mess).


I'm understanding this mail differently: What Michael is explaining is 
that it is more difficult for FFmpeg to change things in libavresample 
than in libswresample, because Libav is unlikely to merge back changes, 
but FFmpeg tries to be compatible with Libav.


In reality, there hasn't been any backwards incompatible change in 
libswresample (still soversion 0), but there has been one in 
libavresample (now at soversion 1).



Keeping your own static version is the only reasonable approach.


That may be OK on Windows. However, a proper Linux distribution is supposed
to be an integrated whole and not a haphazard collection of programs, each
bringing along their own copy of core libraries and their own un- or
semi-fixed security problems.



BTW Jean-Yves outlines an approach that used to be very common on the
past: Pick some particular snapshot of FFmpeg and maintain that in a
downstream project, and expect users to use that because it is too
much effort to keep up with FFmpeg's release frequency.


It is easy to 'keep up' with releases that are API/ABI compatible, which 
many FFmpeg releases are.
One doesn't even have to recompile dependent programs (if they are not 
buggy), one can just install the new version of the libraries.



Prominent
examples of projects that did this (and actually, still do) include
xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess
I was talking about in my previous email: dozens of embedded
code-copies that were accepted into the Debian archive.


As you must know, xine-lib and xbmc are - and mplayer was - compiled 
against the system version of Libav in Debian.



Over many years, I've spearheaded a significant effort in Debian with
packaging and in upstream with introducing a release culture in FFmpeg
(as release manager) to get to somewhat same release frequencies, so
that downstream projects at least had a chance to agree on common
versions of FFmpeg. At the time of the split, I was worried that this
work would have been in vain.


It appears your work has not have been in vain, as FFmpeg's current 
release culture takes into account that any backwards incompatible API 
change means a lot of work for everyone using it. I believe this is 
handled now much better than in the times before the 0.5 release.


If you are unhappy with how the releases are managed in FFmpeg, you can 
always send your concerns to ffmpeg-devel (and I think you still have 
commit rights for FFmpeg's git repository as well).



Considering that most active developers
of FFmpeg at that time (which coincidentally supported my approach to
release management and frequency) joined what is now known as Libav, I
continued my work as upstream release manager in Libav, because I
consider Libav as much more

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Joel Rees]

2014/08/08 18:14 "Yves-Alexis Perez" :
>
> [...]
>
> Put it another way, Xfce (and other DEs) have been hurt by the various
> enforced transitions (ConsoleKit,
> hal/devicekit-power/upower/upower-0.99), yes. Combined with the lack of
> resources, that means it lays behind the people who decided those
> transitions.
>
> Regards,
> --
> Yves-Alexis

As a user trying to find to participate more, can I put a huge "+1" on that?

(Lots of things I'd like to help with on XFCE, among other things, but the
recent transitions have been eating what time I might have had, plus a bit
of work time I can't afford.)

--
Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Theodore Ts'o]

On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote:
> 
> High quality libraries must iterate on their API. Especially for a library
> trying to solve such a complex problem as audio and video encoding and
> decoding for every codec and format. It is unreasonable to expect no
> incompatible changes. Also both ffmpeg and libav codebases have a lot of
> legacy cruft. Libav is making a more concentrated effort at improving this,
> and the evolving API is a side-effect of that.

I beg to differ.  My definition of a "high quality library" is one
where careful design is taken into account when designing the
ABI/API's in the first place, and which if absolutely necessary, uses
ELF symbol versioning to maintain ABI compatibility.

There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
where we've been able to maintain full ABI compatibility even while
adding new features --- including in the case of libext2fs, migrating
from 32-bit to 64-bit block numbers.  And if you're careful in your
design and implementation, the amount of cruft required can be kept to
a very low minimum.

- 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/20140810214333.ga22...@thunk.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Ben Hutchings]

On Sun, 2014-08-10 at 23:02 +0200, Andreas Cadhalpun wrote:
[...]
>   * dvswitch: Still uses CodecID (and also avcodec_encode_video, but
> that is still present in FFmpeg.) [3]
[...]

dvswitch was also broken by the removal of support for downscaled
decoding of DV video.  I don't know whether that change is specific to
libav or was also made in FFmpeg.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Re: Reverting to GNOME for jessie's default desktop

[Joel Rees]

2014/08/08 6:58 "Jordi Mallach" :
>
> Hi Debian,
>
> It's been around 9 months since tasksel changed (for real) the default
> desktop for new installs. At the time of the change, it was mentioned
> the issue would be revisited before the freeze, around debconf time.
>
> Well, it's roughly that time. :) So I'd like to plainly request GNOME is
> reinstated as the default desktop environment for a number of reasons.

First thought: Since systemd has been chosen as the one true way of the
future, it seems only obvious that GNOME should be the default desktop.

> Accessibility: GNOME continues to be the only free desktop environment
that
> provides full accessibility coverage, right from login screen. While it’s
true
> GNOME 3.0 was lacking in many areas, and GNOME 3.4 (which we shipped in
wheezy)
> was just barely acceptable thanks to some last minute GDM fixes, GNOME
3.12
> should have ironed out all of the issues and our non-expert understanding
is
> that a11y support is now on par with what GNOME 2.30 from squeeze offered.

There are a number of regular participants on debian-user who have a11y
needs. Would it be too much to ask, to ask them whether GNOME meets their
needs?

> Downstream health: The number of active members in the team taking care of
> GNOME in Debian is around 5-10 persons, while it is 1-2 in the case of
Xfce.
> Being the default desktop draws a lot of attention (and bug reports) that
only
> a bigger team might have the resources to handle.

It has been mentioned in the past, but developers work on what they want to
work on. That may or may not be related to whether a particular DE is
appropriate for general rcommendation.

> Upstream health: While GNOME is still committed to its time-based release
> schedule and ships new versions every 6 months, Xfce upstream is,
> unfortunately, struggling a bit more to keep up with new plumbing
technology.
> Only very recently it has regained support to suspend/hibernate via
logind, or
> support for Bluez 5.x, for example.

Should consider the reasons for the breakage, as well.

> Community: GNOME is one of the biggest free software projects, and is
lucky to
> have created an ecosystem of developers, documenters, translators and
users
> that interact regularly in a live social community. Users and developers
gather
> in hackfests and big, annual conferences like GUADEC, the Boston Summit,
or
> GNOME.Asia. Only KDE has a comparable community, the rest of the free
desktop
> projects don’t have the userbase or manpower to sustain communities like
this.

With a community that big, would it be unreasonable to ask them to maintain
their own distro? Or perhaps their own liveCD? Eh, well, liveSD.

> Localization: Localization is more extensive and complete in GNOME.  Xfce
has
> 18 languages above 95% of coverage, and 2 at 100% (excluding English),
GNOME
> has 28 languages above 95%, 9 of them being complete (excluding English).

LOL.

No, seriously, is there any meaning to the claim of "complete"?

I've seen a lot of bad Japanese translation, recently, that, if I had more
time, I'd file bugs on.

> Documentation: Documentation coverage is extensive in GNOME, with most of
the
> core applications providing localized, up to date and complete manuals,
> available in an accessible format via the Help reader.

See above. Documentation and translation have something in common here.
Particularly since documentation should be translation from technical
language to the more common vernacular.

> Hardware: GNOME 3.12 will be one of the few desktop environments to
support
> HiDPI displays, now very common on some laptop models. Lack of support for
> HiDPI means non-technical users will get an unreadable desktop by
default, and
> no hints on how to fix that.
>
> Security: GNOME is more secure. There are no processes launched with root
> permissions on the user’s session. All everyday operations (package
management,
> disk partitioning and formatting, date/time configuration…) are
accomplished
> through PolicyKit wrappers.
>
> Privacy: One of the latest focuses of GNOME development is improving
privacy,
> and work is being done to make it easy to run GNOME applications in
isolated
> containers, integrate Tor seamlessly in the desktop experience, better
disk
> encryption support and other features that should make GNOME a more secure
> desktop environment for end users.
>
> Popularity: One of the metrics discussed by the tasksel change proponents
> mentioned popcon numbers. 8 months after the desktop change, Xfce does
not seem
> to have made a dent on install numbers.  The Debian GNOME team doesn’t
feel
> popcon’s data is any better than a random online poll though, as it’s an
opt-in
> service which the vast majority of users don’t enable.
>
> systemd embracing: One of the reasons to switch to Xfce was that it didn’t
> depend on systemd. But now that systemd is the default, that shouldn’t be
a
> problem. Also given ConsoleKit is deprecated and dead upstream, KDE and
Xfce
> a

Re: Reverting to GNOME for jessie's default desktop

[Russ Allbery]

Joel Rees  writes:

> First thought: Since systemd has been chosen as the one true way of the
> future, it seems only obvious that GNOME should be the default desktop.

That doesn't seem at all obvious to me.  I don't think those two things
are particularly related.  Lots of people use systemd without being fans
of, or particularly interested in, GNOME, myself included.

-- 
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: https://lists.debian.org/87wqagj7bq@windlord.stanford.edu

Re: Reverting to GNOME for jessie's default desktop

[Joel Rees]

(Sure wish I could get drivers for this Acer tablet so I could get replace
the vendor-constricted Android with a real OS and get software that
wouldn't misinterpret what my fingers do on the screen. But, then, I
suppose I should go to the trouble of booting up a regular computer for
this.)

2014/08/11 7:32 "Joel Rees" :
>
> 2014/08/08 6:58 "Jordi Mallach" :
>
> >
> > Hi Debian,
> >
> > It's been around 9 months since tasksel changed (for real) the default
> > desktop for new installs. At the time of the change, it was mentioned
> > the issue would be revisited before the freeze, around debconf time.
> >
> > Well, it's roughly that time. :) So I'd like to plainly request GNOME is
> > reinstated as the default desktop environment for a number of reasons.
>
> First thought: Since systemd has been chosen as the one true way of the
future, it seems only obvious that GNOME should be the default desktop.
>
> > Accessibility: GNOME continues to be the only free desktop environment
that
> > provides full accessibility coverage, right from login screen. While
it’s true
> > GNOME 3.0 was lacking in many areas, and GNOME 3.4 (which we shipped in
wheezy)
> > was just barely acceptable thanks to some last minute GDM fixes, GNOME
3.12
> > should have ironed out all of the issues and our non-expert
understanding is
> > that a11y support is now on par with what GNOME 2.30 from squeeze
offered.
>
> There are a number of regular participants on debian-user who have a11y
needs. Would it be too much to ask, to ask them whether GNOME meets their
needs?
>
> > Downstream health: The number of active members in the team taking care
of
> > GNOME in Debian is around 5-10 persons, while it is 1-2 in the case of
Xfce.
> > Being the default desktop draws a lot of attention (and bug reports)
that only
> > a bigger team might have the resources to handle.
>
> It has been mentioned in the past, but developers work on what they want
to work on. That may or may not be related to whether a particular DE is
appropriate for general rcommendation.
>
> > Upstream health: While GNOME is still committed to its time-based
release
> > schedule and ships new versions every 6 months, Xfce upstream is,
> > unfortunately, struggling a bit more to keep up with new plumbing
technology.
> > Only very recently it has regained support to suspend/hibernate via
logind, or
> > support for Bluez 5.x, for example.
>
> Should consider the reasons for the breakage, as well.
>
> > Community: GNOME is one of the biggest free software projects, and is
lucky to
> > have created an ecosystem of developers, documenters, translators and
users
> > that interact regularly in a live social community. Users and
developers gather
> > in hackfests and big, annual conferences like GUADEC, the Boston
Summit, or
> > GNOME.Asia. Only KDE has a comparable community, the rest of the free
desktop
> > projects don’t have the userbase or manpower to sustain communities
like this.
>
> With a community that big, would it be unreasonable to ask them to
maintain their own distro? Or perhaps their own liveCD? Eh, well, liveSD.
>
> > Localization: Localization is more extensive and complete in GNOME.
 Xfce has
> > 18 languages above 95% of coverage, and 2 at 100% (excluding English),
GNOME
> > has 28 languages above 95%, 9 of them being complete (excluding
English).
>
> LOL.
>
> No, seriously, is there any meaning to the claim of "complete"?
>
> I've seen a lot of bad Japanese translation, recently, that, if I had
more time, I'd file bugs on.
>
> > Documentation: Documentation coverage is extensive in GNOME, with most
of the
> > core applications providing localized, up to date and complete manuals,
> > available in an accessible format via the Help reader.
>
> See above. Documentation and translation have something in common here.
Particularly since documentation should be translation from technical
language to the more common vernacular.
>
> > Hardware: GNOME 3.12 will be one of the few desktop environments to
support
> > HiDPI displays, now very common on some laptop models. Lack of support
for
> > HiDPI means non-technical users will get an unreadable desktop by
default, and
> > no hints on how to fix that.

I'm thinking this sounds like an argument for postponing freeze.

> > Security: GNOME is more secure. There are no processes launched with
root
> > permissions on the user’s session. All everyday operations (package
management,
> > disk partitioning and formatting, date/time configuration…) are
accomplished
> > through PolicyKit wrappers.

With the volume of new code, can such claims be serious?

> > Privacy: One of the latest focuses of GNOME development is improving
privacy,
> > and work is being done to make it easy to run GNOME applications in
isolated
> > containers, integrate Tor seamlessly in the desktop experience, better
disk
> > encryption support and other features that should make GNOME a more
secure
> > desktop environment for end users.

TOR has what to do with real priv

Re: Reverting to GNOME for jessie's default desktop

[Joel Rees]

On Mon, Aug 11, 2014 at 7:49 AM, Joel Rees  wrote:

(Having booted up a real OS, but still using Google's webmail fake MUA. heh.)

> [...]
> 2014/08/11 7:32 "Joel Rees" :
>> 2014/08/08 6:58 "Jordi Mallach" :
>>
>> [...]
>> > systemd embracing: One of the reasons to switch to Xfce was that it
>> > didn’t
>> > depend on systemd. But now that systemd is the default, that shouldn’t
>> > be a
>> > problem. Also given ConsoleKit is deprecated and dead upstream, KDE and
>> > Xfce
>> > are switching or are planning to switch to systemd/logind.
>
> Isn't this essentially the sum of your thesis

That is, isn't this your thesis, in sum?

>> > In addition to this, moving to Xfce now would mean yet another
>> > transition to
>> > a new desktop (if we consider GNOME 2.x → 3.x a transition, which it
>> > is),
>> > which would mean a new round of adapation for users installing Debian
>> > from
>> > scratch, and only after two years after getting used to the GNOME 3
>> > workflow.
>> > jessie's GNOME 3.x release should be a lot more polished than what we
>> > shipped
>> > with wheezy, which means many of the rough edges and annoyances people
>> > may
>> > have found when upgrading from squeeze are probably now ironed out.

So, we should move, yet again, before any CDs get burned, lest anyone
doubt debian's allegiance to the one-true-and-coming-OS?

(I should have held my tongue on that, I suppose, since these are the
dev lists, and I am making some serious requests below.)

>> > Many members of the Debian GNOME team feel shipping Xfce by default
>> > would
>> > mean regressing in a few key areas like, as mentioned before,
>> > accessibility,
>> > localisation and documentation of the default set of applications. We
>> > are wary
>> > about the state of some features of the current default with respect
>> > to power management and bluetooth, for example. These features are
>> > driven by,
>> > and working since day 1, by GNOME 3.12.
>> >
>> > Jordi
>> > --
>> > Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
>> > jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
>> > GnuPG public key information available at http://oskuro.net/

Two years from now, your list of reasons might make sense.

Right now, there has been no time to gather the sort of statistics
needed to support your assertions.

But, and I mean this seriously, since debian has made the move to
systemd, it seems to me that your assertions are superfluous. It makes
no sense not to make Gnome3 the default DE.

That means, I think, that it also makes no sense to have a CD install
image other than netinstall.

It would be nice if the install media made DE options a little more
accessible than is currently the case.

I'm not sure if my memories here are from debian, but it seems to me
that it used to be fairly easy to select, say, a desktop productivity
set of initial packages and then go in and change the DE from Gnome2
to XFCE.

Last time I tried the easy install, I didn't see any way to do that,
and I ended up having to remove Gnome3 and install XFCE after the
first boot.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


--
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/caar43iofaofevnotsmnrbatqmwnvgm5p7ah_rqj1n4gvcdg...@mail.gmail.com

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Cameron Norman]

El dom, 10 de ago 2014 a las 11:39 , Kees de Jong 
 escribió:

Why are we discussing CD/DVD sizes? Why not just use an USB
netinstall? It's then possible to download and install the stuff you
need, if you don't want to use a lot of bandwidth then choose no
desktop environment or XFCE/LXDE. But if you can spare some more time
then you can install GNOME/KDE. Seems like a good deal. And USB sticks
are cheaper (also easier to reuse) so I don't get the 'hurting
developing countries' argument.


CDs are cheap and easy to distribute and customize (with the Debian 
logo and artwork). Yes, we all have a number of 1+ GB USB drives that 
could easily fit GNOME, but are we willing to give those away or sell 
them cheaply? Being able to distribute a Debian CD that does not need 
an internet connection to try out or install is really beneficial for 
gaining users.


elementary OS is hitting this issue with how expensive it is to make 
customized USB drives (with their logo and stuff). I think the best 
chance they have of being able to sell USB drives in their online store 
is just the elementary coloring (a distinctive light blue).


netinstall is difficult for unreliable or limited bandwidth network 
connections (luckily it is perfect for me, someone who uses GNOME and 
has a good internet connection :)


Best regards,
--
Cameron Norman

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/10/2014 02:39 PM, Kees de Jong wrote:

> Why are we discussing CD/DVD sizes? Why not just use an USB
> netinstall? It's then possible to download and install the stuff you
> need, if you don't want to use a lot of bandwidth then choose no
> desktop environment or XFCE/LXDE. But if you can spare some more time
> then you can install GNOME/KDE. Seems like a good deal. And USB
> sticks are cheaper (also easier to reuse) so I don't get the 'hurting
> developing countries' argument.

With netinst, you incur the bandwidth cost at install time, once for
every install.

With a larger install image which includes all the packages needed for a
more comprehensive install (whether CD, DVD or otherwise), you incur the
bandwidth cost up once front, and then never again (until it's time to
update to a new install-image version anyway).

If you're only going to do one install, then yes, the netinst image
probably makes more sense for a bandwidth-limited environment.

But if you're going to do multiple installs, using one of the larger and
more comprehensive prebuilt install images almost certainly makes more
sense than using netinst.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJT6AhUAAoJEASpNY00KDJrn7wQAKwL0NtO1eyDinasWL0UkOhG
QVgLjlkWLrOdnQFYOl+YT9EsOT79Jmip8Ym2ySQid/DG6UpSDgP0eOf9owqZeZ8Y
/ARaNdkP1e6//k49XvhQFetTDPOCBvNMucRvPljK3UJdj5E4yu+UhrffYez89Wfk
lPauNO6mUUPpmkCuwsNeQ0Z5b6tPw1VaMovuBFP2fshBMXW/4aWyGUBibdzkqhYO
Qwj6NKBj78liaSJAWFFxw92HSYbLzs6uGTlW7f9tPPw5Mv5BRdB0d6yN2cdCf391
RUzcFVgudnUzq8st9Kf0vrvbnnTtEoV1oIqDfAN4mzmF3Psh7b6lMjaH2h5F+n+V
1GNmjoco8gE0U1gZvb9KdcTFNzYv7jnISVx6vHK7mOY6UJts/GRpM8dW8Pps7WET
9aPDc6JwdI5+/IiBHn/5mf3moFFbLMZTI41aX9jSawoHNPC9hkcC3VeXYc+hxyZS
ABWU2GswFTy+R8u9QO1AsqgVoV9K5RsyeQK9O+yKTVWgcy5bXOt4r5SbzVmJrDLN
tAA3jIn9HBtLVp4I8KJWFg0c89uPENRqgQkIq7iAGIy6dsASGFctRAMUsxEilp2E
1iDqGpKRRIiDbzQonSJ7LwSV+TqDqHEnU9dUm7OB4yqcgVVd5+Dw8w59dJ0VIkJR
5Copesh0itb2ucAX9Kjd
=/d+b
-END PGP SIGNATURE-


-- 
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/53e80854.8030...@fastmail.fm

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Anthony F McInerney]

Would the people who are claiming that blank cdr are cheaper than dvdr,
especially in third world countries, please cite sources (shops, price
checkers etc) of the price of say 5 pack or 10 pack, even up to 50pack of
CD's, vs the same amount of DVD's, from those third world countries. Is the
price of a small pack of DVD's really worth making the decision on a DE for
debian?

If people have old CD only machines i would not like to attempt to get
kernel 3.16 +drivers +userland working on that. I've been in that situation
plenty of times, where woody or potato are better simply because the
drivers had been deprecated. Lets not go into the 256/512MB of ram that the
CD only computer has and how much gnome or xfce is going to chew up and
bring the machine to a crawl as soon you try to do anything and it hits
swap.

DVD readers/writers are cheaper now than CD readers/writers ever were.
The only argument you have left is bandwidth, and fortunately DVD's can be
sent in the post. Also we are probably only talking about a 100MB or 200MB
more.

I'd rather a nice debian installer with everything included, rather than
trying to 'cut stuff out' just so it 'fits'. There's simply no need for
that.

The real issue at hand should not be derailed by "does it work with 1995
technology"

As for the topic, the assumption of "let's switch back to gnome now", how
quaint.

Firstly, it should be "Let's choose the default DE for Jessie".

Secondly, why haven't the lxde and kde developers been included on the list
for this discussion?
Even with the init choice, the outsiders were given a chance to speak up
(E17 anyone?)

Thirdly, and more importantly the state of gnome itself in testing/jessie
repositories, let alone sid, even with a larger team, the mismatched
package versions, the first movement from 3.8 to 3.12, means it's barely
been looked at let alone tested, those that do attempt to test it come into
irc regular to complain about it.

So can we not have our DE chosen on the merit of 20 cents, and instead
decide which DE is best for technical reasons, usability, accessibility or
interface and start customising it pronto? (ie, still need to decide on a
default theme)

For reference i do not use XFCE or GNOME as my default DE, i have attempted
to use sid and testing in a vm to test gnome3 recently and just gave up,
that obviously might have changed in the last few weeks.