Bug#707673: ITP: gcc-4.8-doc -- documentation for the GNU compilers

[GUO Yixuan]

Package: wnpp
Severity: wishlist
Owner: Guo Yixuan 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: gcc-4.8-doc
  Version : 4.8.0-1
  Upstream Author : FSF
* URL : http://gcc.gnu.org/
* License : GFDL-1.3+, with invariant sections
  Programming Lang: Texinfo
  Description : documentation for the GNU compilers

This package contains manual pages and documentation in info and
html format, for the GNU compilers.

This documentation is licensed under the terms of the GNU Free
Documentation License, and contains invariant sections, so it can't be
part of Debian main.

ps. I'm maintaining gcc-4.4-doc-non-dfsg, gcc-4.6-doc, and gcc-4.7-doc
now. All the packaging work is in git[1].

[1]
http://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc.git;a=summary

Regards,

GUO Yixuan


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

Bug#707672: general: binary diffs of large packages

[Andrei POPESCU]

Control: reopen -1
Control: reassign -1 release-notes

On Vi, 10 mai 13, 02:43:28, ant wrote:
> Package: general
> Severity: wishlist
> 
> Dear Debian,
> 
>   At the end of a slow line it would still be nice to be able to download only
> the actual binary differences between versions of a package during an upgrade.
> Especially for larger packages.

As mentioned, this is already possible, but probably not documented 
enough (or in the right place?).
 
Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Processed: Re: Bug#707672: general: binary diffs of large packages

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #707672 {Done: Paul Wise } [general] general: binary diffs 
of large packages
Bug reopened
Ignoring request to alter fixed versions of bug #707672 to the same values 
previously set
> reassign -1 release-notes
Bug #707672 [general] general: binary diffs of large packages
Bug reassigned from package 'general' to 'release-notes'.
Ignoring request to alter found versions of bug #707672 to the same values 
previously set
Ignoring request to alter fixed versions of bug #707672 to the same values 
previously set

-- 
707672: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707672
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b707672.136817230119148.transcr...@bugs.debian.org

Re: Merging / and /usr (was: jessie release goals)

[Marc Haber]

On Thu, 9 May 2013 15:50:45 +0200, Philipp Kern 
wrote:
>On Thu, May 09, 2013 at 10:32:09AM +0200, Marc Haber wrote:
>> That's how I do it for new installs. However, this is vastly more
>> complex than the traditional setup, and it doesn't help for systems in
>> maintenance mode that, for example, cannot be changed because of
>> service level agreements and certifications.
>
>And such systems are upgraded to a new release? That'd be surprising.

Such systems are sometimes unfrozen and upgraded instead of being
re-installed.

>> Using Debian happens beyond single-user home desktop settings, you
>> know.
>
>I'm pretty sure he knows, so that remark seems unnecessary.

Why does he ignore those users then in his argumentation?

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


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

Re: Merging / and /usr (was: jessie release goals)

[Marc Haber]

On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 09, "Bernhard R. Link"  wrote:
>> Or in other words: to make essential functionality not available if
>> /usr is broken.
>Again: this is not we are discussing. Essential functionality is moving 
>to /usr anyway

Which is a really really bad thing. Some anonymous upstream is forcing
us to decrease the reliability of our systems. I really hate that
idea.

>> Having a seperate / means you have an instant rescue image that has
>> just the right kernel and tools you need to repair the rest of your
>> system.
>OK, so you could have an even *smaller* / with a *real* independent 
>rescue image like grml in /boot.

Having the rescue image _this_ independent is not really desireable
since one would probably have to deal with outdated or non-existing
rescue tools in the independent image while the correct software in
the correct version is on the system's own / file system.

>> You also have one small filesystem with all the important
>> stuff like /etc in it while the boring large distro stuff is in
>> another partition. You also have a partition border between
>> most of the random stuff and the important stuff.
>Indeed, if the content of /{bin,sbin,lib} is moved to /usr you can have 
>a small filesystem with all the important stuff like /etc in it and the 
>boring large distro stuff (like 100 MB of kernel modules for each 
>kernel, currently in /lib) in another partition.

But I'll have the fsck version that is guaranteed to fit my /usr file
system in the big /usr file system, so I'll be forced to use an fsck
from a rescue image which might not be the current one, possibly
causing even more damage.

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


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

Re: wheezy postmortem re rc bugfixing

[Ivo De Decker]

Hi,

On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
> Other steps to take as preventative measures:

>  * Make it a *MUST* that all transitions, no matter how small, are
> checked with the release team starting from as soon as the freeze is
> announced (not just after it starts) such that uploads which start a
> transition could be pushed into DELAYED or REJECTed automatically. (Not
> easy to implement this one, I know.)

This could be implemented by building uploads to unstable against testing
instead of unstable.

Currently problematic uploads to unstable don't affect users of testing
because they will not migrate, but they do affect development of testing
(which is done in unstable), because they will prevent reverse
build-dependencies from migrating.

If uploads to unstable were built against testing, uncoordinated uploads of
build-dependencies would not affect development, because they would not be
used by the autobuilders until they were allowed to migrate to testing. They
would still be used (and tested) by developers running unstable on their
systems.

To allow developers to adapt their packages to newer versions of
build-dependencies, they should be able to selectively choose
build-dependencies from unstable. A similar setup is already implemented for
experimental (which builds against unstable by default, unless the
build-dependencies explicitly specify packages from experimental). Newer
versions of build-dependencies could also be specified for binNMU's, to allow
rebuilds for transitions.


The implementation of PPA's might allow individual developers to build their
packages against testing and move these to unstable.

Cheers,

Ivo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130510092334.ga...@ugent.be

Bug#707687: ITP: nemo-fileroller -- File Roller integration for Nemo

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: nemo-fileroller
  Version : 1.8.0
  Upstream Author : Linux Mint Project 
* URL : https://github.com/linuxmint/nemo-extensions/
* License : GPL-3 vs LGPL-2+ (COPYING vs source headers)
  Programming Lang: C
  Description : File-Roller integration for Nemo

Nemo File-Roller is an extension that integrates the File-Roller service with
Nemo.

The copyright needs to be clariefied, because COPYING (GPL-3) differs from the
statement of the source code file headers (LPGL-2+).


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

Bug#707688: ITP: libmodule-faker-perl -- build fake dists for testing CPAN tools

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libmodule-faker-perl
  Version : 0.014
  Upstream Author : Ricardo Signes 
* URL : https://metacpan.org/release/Module-Faker/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : build fake dists for testing CPAN tools

 Module::Faker is a tool for building fake CPAN modules and, perhaps more
 importantly, fake CPAN distributions. These are useful for running tools that
 operate against CPAN distributions without having to use real CPAN
 distributions. This is much more useful when testing an entire CPAN instance,
 rather than a single distribution, for which see CPAN::Faker.


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

Re: Merging / and /usr (was: jessie release goals)

[Marco d'Itri]

On May 10, Marc Haber  wrote:

> Having the rescue image _this_ independent is not really desireable
> since one would probably have to deal with outdated or non-existing
> rescue tools in the independent image while the correct software in
> the correct version is on the system's own / file system.
I doubt that this is going to be a problem in practice, but if it 
happens to be then I am sure that the grub glue package(s) can be easily 
enanched to keep the rescue image up to date.

> But I'll have the fsck version that is guaranteed to fit my /usr file
> system in the big /usr file system, so I'll be forced to use an fsck
> from a rescue image which might not be the current one, possibly
> causing even more damage.
People use live CDs for rescue all the time, do you have some data which 
show that this is actually a problem in real life and not an imaginary 
problem?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#707691: ITP: mr.rescue -- Mr. Rescue is an arcade styled 2d action game centered around evacuating civilians from burning buildings. The game features fast paced fire extinguishing action and lots

[Steven Hamilton]

Package: wnpp
Severity: wishlist
Owner: Steven Hamilton 

* Package name: mr.rescue
  Version : 1.01
  Upstream Author : Tangram Games 
* URL : http://tangramgames.dk
* License : Zlib, BY-NC-SA 3.0 Unported License, Custom Public Domain
  Programming Lang: Lua, Love2d
  Description : Mr. Rescue is an arcade styled 2d action game centered 
around evacuating civilians from burning buildings. The game features fast 
paced fire extinguishing action and lots of throwing people around in 
pseudo-randomly generated levels.


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

Proposed releas goal: Optionally merge /usr

[Helmut Grohne]

On Fri, May 10, 2013 at 11:48:37AM +0200, Marco d'Itri wrote:
[ reiterating the same arguments seen numerous times before ]

I suggest that we leave practical implications of the /usr merge aside
for a moment. The pros and cons have been discussed at lengths. If there
is value in further arguments, please explain that to me.

What issues would Debian face if it were to support both models (for a
time, e.g. jessie)? During that time frame we can gather actual data on
whether this feature is actually used by users and what kinds of
workflows it breaks. Is it really useful to continue discussing whether
it is desirable instead of just doing it? I can try to phrase it as a
release goal to see, whether we can get consensus on it.

Make sure that Debian can be installed with merged /usr and with
separated /usr.

As far as I can see it meets the requirement to be "smart" and affects a
significant number of packages (due to file conflicts with /bin/$foo
/usr/bin/$foo). The first two (independent) steps to getting there is
updating the initramfs to mount /usr (in the works) and to drop
compatibility symlinks /usr/bin/$foo -> /bin/$foo.

This target may be more work that just switching to merged /usr, but
there is no (perceived) consensus on the latter. If there is no
consensus on this (or a similar) goal either, we can stop the discussion
immediately as no change is going to happen. Note that I am not an
advocate for this goal.

Helmut


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

Téléchargement Nouveautés Artistes

[so-much]

NEWSLETTER 



Boutique











Bienvenue à la newsletter de la maison de disques So Much
Distribution, Distribution Numérique, Téléchargement MusiqueDécouvrez notre 
espace boutique pour acheter les CDs de nos Artistes.Bonne visite... 







NOUVEAUTE A TELECHARGER 



Ricardo BarryBaby-Dance-(Romain-Garden-Edit)Téléchargement sur qobuzMAI 2013 

 

Eric MorenaSous le ciel étoiléNouvel Album à télécharger sur amazon :" Sous le 
ciel étoilé ".Disponible dans les bacs le 21 Mai 2013

 

Lynda CraftCount to three 123..Nouvel Album :" Count to three 123.. ".En 
téléchargement sur amazon Mars 2013

 

Marco AttaliL'album il le SiffleNouvel Album :" L'album il le Siffle 
".Disponible en téléchargement sur Qobuz AVRIL 2013

 

VoodooWildernessNouvel Album :" WILDERNESS ".Disponible dans les bacs 



Copyright © 2008 So Much | Tous droits réservés | Mentions légales | Webdesign 
Crea2Web.com| Désinscription

Re: wheezy postmortem re rc bugfixing

[Neil Williams]

On Fri, 10 May 2013 11:24:30 +0200
Ivo De Decker  wrote:

> Hi,
> 
> On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
> > Other steps to take as preventative measures:
> 
> >  * Make it a *MUST* that all transitions, no matter how small, are
> > checked with the release team starting from as soon as the freeze is
> > announced (not just after it starts) such that uploads which start a
> > transition could be pushed into DELAYED or REJECTed automatically. (Not
> > easy to implement this one, I know.)
> 
> This could be implemented by building uploads to unstable against testing
> instead of unstable.

The whole point with a transition is that a library is updated in
unstable and, for the updated library to migrate, it's reverse
dependencies in unstable need to migrate to that updated library by
being built against the version of that library in unstable. Otherwise,
migration is blocked because reverse dependencies already in testing
become uninstallable. There may be source code changes required in those
reverse dependencies. There needs to be time for this to happen and
then for all affected packages to migrate. There's no point building
packages against testing as, at the critical stage, the version of the
library to which the packages are meant to transition is *not* in
testing.

If those reverse dependencies are to be rebuilt at all, the rebuild
needs to happen against the version which is trying to migrate - the
one in unstable.

Packages don't get rebuilt in testing - rebuilds go back through
unstable.

Problems arise from the number of reverse dependencies and when
transitions get blocked by other transitions because of some packages
which depend on two or more libraries already involved.

Rebuilding any of those against testing is pointless - the packages
need to be rebuilt against the new versions in unstable and, where
necessary, migrated to the updated API. Prior to those rebuilds, the
affected packages in testing and unstable were likely last built against
the version of the library already in testing - I see no point in
building them again for the same version. We have that build, it's that
build which needs to be replaced by a build against the version of the
transitioning library in unstable.

> Currently problematic uploads to unstable don't affect users of testing
> because they will not migrate, but they do affect development of testing
> (which is done in unstable), because they will prevent reverse
> build-dependencies from migrating.

The point is to keep testing installable, not to allow updated
applications into testing without having a transition at all. The
applications must transition and that must happen in unstable if
testing is to remain installable.

There is no point allowing applications using libfoo0 already in testing
to be rebuilt against libfoo0 (which no longer exists in unstable) when
the whole point is that it is the lack of a build of the applications
against libfoo1 which is blocking the migration of those applications
*and* libfoo1 into testing.

Any update, any new version of those applications, needs to be built
against libfoo1, the version in unstable. There would be no libfoo1 in
testing and no libfoo0 in unstable.

The exceptions to this are libraries which use the libfoo0-dev
mechanism, generally because there are so many reverse dependencies
that both versions need to exist not only in unstable but in testing
and stable too - think libgtk2.0-0 and libgtk3.0. That requires new
source packages for every SONAME change - something which is only worth
doing for packages like GTK.

> If uploads to unstable were built against testing, uncoordinated uploads of
> build-dependencies would not affect development, because they would not be
> used by the autobuilders until they were allowed to migrate to testing. They
> would still be used (and tested) by developers running unstable on their
> systems.

What builds the packages in unstable? I think you're only considering a
single architecture. Even just thinking of x86, there are just as many
i386 uploads as amd64 - something has to build amd64 uploads for i386
in unstable and vice versa. Those builds need to be against the
versions of dependencies in unstable - that is the job of the
autobuilders. Developers can't run unstable if there are no builds
other than uploads and unstable isn't just about x86 anyway.

Even if the intent is to rebuild uncoordinated uploads of applications
which would inadvertently tie two different transitions together, I see
no gain over simply waiting until the transitions are complete before
making the upload.

If you build against the version in testing, the application will
then have to be rebuilt against the version in unstable before the
application can migrate anyway. Where is the advantage?

If you allow the application to migrate, it will still have to
transition to the new library before the library itself can migrate. So
instead of one rebuild, you now have three. How d

Re: wheezy postmortem re rc bugfixing

[Neil Williams]

On Fri, 10 May 2013 11:24:30 +0200
Ivo De Decker  wrote:

> Hi,
> 
> On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
> > Other steps to take as preventative measures:
> 
> >  * Make it a *MUST* that all transitions, no matter how small, are
> > checked with the release team starting from as soon as the freeze is
> > announced (not just after it starts) such that uploads which start a
> > transition could be pushed into DELAYED or REJECTed automatically. (Not
> > easy to implement this one, I know.)
> 
> This could be implemented by building uploads to unstable against testing
> instead of unstable.

The whole point with a transition is that a library is updated in
unstable and, for the updated library to migrate, it's reverse
dependencies in unstable need to migrate to that updated library by
being built against the version of that library in unstable. Otherwise,
migration is blocked because reverse dependencies already in testing
become uninstallable. There may be source code changes required in those
reverse dependencies. There needs to be time for this to happen and
then for all affected packages to migrate. There's no point building
packages against testing as, at the critical stage, the version of the
library to which the packages are meant to transition is *not* in
testing.

If those reverse dependencies are to be rebuilt at all, the rebuild
needs to happen against the version which is trying to migrate - the
one in unstable.

Packages don't get rebuilt in testing - rebuilds go back through
unstable.

Problems arise from the number of reverse dependencies and when
transitions get blocked by other transitions because of some packages
which depend on two or more libraries already involved.

Rebuilding any of those against testing is pointless - the packages
need to be rebuilt against the new versions in unstable and, where
necessary, migrated to the updated API. Prior to those rebuilds, the
affected packages in testing and unstable were likely last built against
the version of the library already in testing - I see no point in
building them again for the same version. We have that build, it's that
build which needs to be replaced by a build against the version of the
transitioning library in unstable.

> Currently problematic uploads to unstable don't affect users of testing
> because they will not migrate, but they do affect development of testing
> (which is done in unstable), because they will prevent reverse
> build-dependencies from migrating.

The point is to keep testing installable, not to allow updated
applications into testing without having a transition at all. The
applications must transition and that must happen in unstable if
testing is to remain installable.

There is no point allowing applications using libfoo0 already in testing
to be rebuilt against libfoo0 (which no longer exists in unstable) when
the whole point is that it is the lack of a build of the applications
against libfoo1 which is blocking the migration of those applications
*and* libfoo1 into testing.

Any update, any new version of those applications, needs to be built
against libfoo1, the version in unstable. There would be no libfoo1 in
testing and no libfoo0 in unstable.

The exceptions to this are libraries which use the libfoo0-dev
mechanism, generally because there are so many reverse dependencies
that both versions need to exist not only in unstable but in testing
and stable too - think libgtk2.0-0 and libgtk3.0. That requires new
source packages for every SONAME change - something which is only worth
doing for packages like GTK.

> If uploads to unstable were built against testing, uncoordinated uploads of
> build-dependencies would not affect development, because they would not be
> used by the autobuilders until they were allowed to migrate to testing. They
> would still be used (and tested) by developers running unstable on their
> systems.

What builds the packages in unstable? I think you're only considering a
single architecture. Even just thinking of x86, there are just as many
i386 uploads as amd64 - something has to build amd64 uploads for i386
in unstable and vice versa. Those builds need to be against the
versions of dependencies in unstable - that is the job of the
autobuilders. Developers can't run unstable if there are no builds
other than uploads and unstable isn't just about x86 anyway.

Even if the intent is to rebuild uncoordinated uploads of applications
which would inadvertently tie two different transitions together, I see
no gain over simply waiting until the transitions are complete before
making the upload.

If you build against the version in testing, the application will
then have to be rebuilt against the version in unstable before the
application can migrate anyway. Where is the advantage?

If you allow the application to migrate, it will still have to
transition to the new library before the library itself can migrate. So
instead of one rebuild, you now have three. How d

Re: wheezy postmortem re rc bugfixing

[Josselin Mouette]

Le mercredi 08 mai 2013 à 16:51 +0100, Ian Jackson a écrit : 
> * Try to identify the main ways in which bugs can be "hard" (which
>might be technical, political, or a mixture)

One of the general problems I have been running into include several
(sometimes all) of the following patterns.

  * Few users affected by the bug, and they are not necessarily
skilled enough to test updated packages. 
  * Maintainers able to fix the affected packages not able (or
willing to setup something complex) to test the fix. 
  * Maintainers with not enough time to work on the release and more
focused on experimental. 
  * Consequences of poor upstream design choices. 
  * Upstream insisting (sometimes rightfully) that the only
reasonable fix is a major update incompatible with the freeze
policy, sometimes with an impact on dozens of other packages.

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


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

Re: Depends: libfoo:foreign ???

[Ben Hutchings]

On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote:
> On 2013-05-09 07:56, Paul Wise wrote:
> > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
> > 
> >> I just noticed that we have the first amd64 package in the archive that
> >> has dependencies on :i386 qualified libraries:
> >>
> >> Package: teamspeak-client
> > 
> > It appears that will block it from reaching testing:
> > 
> 
> Indeed, Britney does not support those annotations (at the moment?).  To
> avoid issues with this kind of thing, we made her consider such
> dependencies for unsatisfiable[1].
>   So for now anything using that form in Depends or Pre-Depends will not
> reach testing (without manual intervention from the Release team and I
> am not sure how likely "we" are to do that).
[...]

During this release cycle I'm hoping to get rid of the 'amd64' kernel
flavour in i386.  The linux-image-3.2.0-4-amd64 package is already
installable in wheezy with amd64 as a foreign arch.  However, the
linux-headers-*-amd64 packages are not, as they depend on a specific
major version of gcc (e.g. gcc-4.6). I think that a dependency on
'gcc-4.6 | gcc-4.6:i386' might fix that, but what would britney think of
it?

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison


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

Re: wheezy postmortem re rc bugfixing

[Piotr Ożarowski]

[Charles Plessy, 2013-05-09]
>   For a large number of packages if not all, we should allow the
> package maintainers to manually migrate their packages to Testing during the
> Freeze, within boundaries set on debian-devel-announce by the release team.

+1

or a soft freeze (as described above) a month (or two) before hard freeze
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


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

Re: Merging / and /usr (was: jessie release goals)

[Olav Vitters]

On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> You have a point here. The problem is that people need to change their
> operations, which is hard for many people, let alone the case when
> emergency manuals need to be changed just for the sake of satisfying
> Lennart.

There are various benefits, discussed before at length (here,
elsewhere). Suggesting/summarizing this as "satisfying Lennart" is a bit
telling.

-- 
Regards,
Olav


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

Re: Merging / and /usr (was: jessie release goals)

[Olav Vitters]

On Tue, May 07, 2013 at 10:23:52PM +, Thorsten Glaser wrote:
> Gah! Just because the other FLOS idiots are doing it doesn’t mean
> Debian should follow.

Do you also have technical objections or some kind of reasoning behind
this?

-- 
Regards,
Olav


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

Re: Depends: libfoo:foreign ???

[Niels Thykier]

On 2013-05-10 14:48, Ben Hutchings wrote:
> On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote:
>> On 2013-05-09 07:56, Paul Wise wrote:
>>> On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
>>>
 I just noticed that we have the first amd64 package in the archive that
 has dependencies on :i386 qualified libraries:

 Package: teamspeak-client
>>>
>>> It appears that will block it from reaching testing:
>>>
>>
>> Indeed, Britney does not support those annotations (at the moment?).  To
>> avoid issues with this kind of thing, we made her consider such
>> dependencies for unsatisfiable[1].
>>   So for now anything using that form in Depends or Pre-Depends will not
>> reach testing (without manual intervention from the Release team and I
>> am not sure how likely "we" are to do that).
> [...]
> 
> During this release cycle I'm hoping to get rid of the 'amd64' kernel
> flavour in i386.  The linux-image-3.2.0-4-amd64 package is already
> installable in wheezy with amd64 as a foreign arch.  However, the
> linux-headers-*-amd64 packages are not, as they depend on a specific
> major version of gcc (e.g. gcc-4.6). I think that a dependency on
> 'gcc-4.6 | gcc-4.6:i386' might fix that, but what would britney think of
> it?
> 
> Ben.
> 

As I understand the code, she ignores unsatisifiable dependencies in an
OR clause (as long as the result is not "empty").  That said, our test
case for this does not include alternatives.
  Though looking at the commit log, if she doesn't accept it (I think
she will, but...) you will get a big fat warning on the excuses page[1].
 If you want to know ahead of time, you are welcome to donate a test
case[2]. :)

~Niels

[1]
http://anonscm.debian.org/gitweb/?p=mirror/britney2.git;a=commitdiff;h=3e9c1acb8e3724c7f1cf10f4578a4082fb5c1756

[2] http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git

I think "t/multi-arch-depends" should serve as a good starting point.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518cf552.9080...@thykier.net

Re: Merging / and /usr (was: jessie release goals)

[Roger Leigh]

On Fri, May 10, 2013 at 03:04:34PM +0200, Olav Vitters wrote:
> On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> > You have a point here. The problem is that people need to change their
> > operations, which is hard for many people, let alone the case when
> > emergency manuals need to be changed just for the sake of satisfying
> > Lennart.
> 
> There are various benefits, discussed before at length (here,
> elsewhere). Suggesting/summarizing this as "satisfying Lennart" is a bit
> telling.

It's still entirely accurate though.  This is ultimately being driven by
uncooperative upstreams unwilling to maintain their stuff properly, and
this really means udev, and this is part of systemd for better or worse.
Well, worse.

Ensuring /usr is mounted at boot time is one thing.  It provides
certain very useful guarantees which we currently don't have.  Merging
/ and /usr is another matter entirely, and it's just one of several
increasingly bizarre and technically questionable decisions coming
from the Fedora camp of late.  What Fedora does is not necessarily
appropriate for Debian.  They have rather different pressures
influencing their decisions, and they are not all in our interest.

How are those udev replacement projects coming along?  Something else
to think about for jessie.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


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

Re: wheezy postmortem re rc bugfixing

[Scott Kitterman]

On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote:
> So I would like to suggest that we should have a thread where we:
> 
>  * Try to identify the main ways in which bugs can be "hard" (which
>might be technical, political, or a mixture)
> 
>  * Try to think of workflows which might overcome these problems

Currently there are formally two classes of RC bugs relative to a release, 
ignored and not ignored.  Informally not all RC bugs without the $RELEASE-
ignore tag are not the same and I think this ambiguity has been a source of 
uncertainty about where people should focus time (this applies both potential 
RC bug fixers and the release team, as I see it).  

Stated non-rigorously, active (not ignored) RC bugs can fall into several 
bins:

1.  Things that definitely must be fixed for release

2.  Things that must either be fixed or the package removed

3.  Not evaluated

4.  Will probably ignore, but not ready to make that call yet

If we had additional tags for #1 and #2 to communicate that the release team 
has evaluated a bug and concluded it's in the must fix category, then that 
would help people trying to fix RC bugs focus on the things that are known 
release issues.

I have seen release team discussions on bugs along the lines of "I will 
probably ignore that one, but I'm not ready to decide for sure yet".  I think 
release team members are rationally cautious about applying ignore tags 
because once that's done, it's pretty certain no one will look at it.  If 
there were a tag for will probably ignore then that would both be a clear 
indicator for RC bug fixers to perhaps focus elsewhere if it's not easy and 
perhaps help the release team avoid having to rediscuss bugs as much.

I've stayed away from suggesting any tag names.  I think we can adequately 
bikeshed that if there's some agreement the added granularity would be worth 
the added complexity.

Scott K


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

Re: Merging / and /usr (was: jessie release goals)

[Ben Hutchings]

On Fri, 2013-05-10 at 14:46 +0100, Roger Leigh wrote:
> On Fri, May 10, 2013 at 03:04:34PM +0200, Olav Vitters wrote:
> > On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> > > You have a point here. The problem is that people need to change their
> > > operations, which is hard for many people, let alone the case when
> > > emergency manuals need to be changed just for the sake of satisfying
> > > Lennart.
> > 
> > There are various benefits, discussed before at length (here,
> > elsewhere). Suggesting/summarizing this as "satisfying Lennart" is a bit
> > telling.
> 
> It's still entirely accurate though.  This is ultimately being driven by
> uncooperative upstreams unwilling to maintain their stuff properly, and
> this really means udev, and this is part of systemd for better or worse.
> Well, worse.

I don't think that's fair.  It's not udev itself, but the increasing
number of things that may be hooked into device events.

[...]
> How are those udev replacement projects coming along?  Something else
> to think about for jessie.

Apparently the eudev talk at FOSDEM was entertaining...

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison


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

Re: wheezy postmortem re rc bugfixing

[Neil Williams]

On Fri, 10 May 2013 10:03:46 -0400
Scott Kitterman  wrote:

> On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote:
> > So I would like to suggest that we should have a thread where we:
> > 
> >  * Try to identify the main ways in which bugs can be "hard" (which
> >might be technical, political, or a mixture)
> > 
> >  * Try to think of workflows which might overcome these problems
> 
> Currently there are formally two classes of RC bugs relative to a release, 
> ignored and not ignored.  Informally not all RC bugs without the $RELEASE-
> ignore tag are not the same and I think this ambiguity has been a source of 
> uncertainty about where people should focus time (this applies both potential 
> RC bug fixers and the release team, as I see it).  
> 
> Stated non-rigorously, active (not ignored) RC bugs can fall into several 
> bins:
> 
> 1.  Things that definitely must be fixed for release

A lot of these determinations could be assisted by some simple metrics.
From the sidelines of two releases, I've observed that release team
decisions on this kind of tag would likely involve things like the
Priority of the affected package, it's involvement in existing
transitions, the implications of `dak rm -Rn $package` on ries and the
history of the package (e.g. if this is going to lead to the fourth NMU
on this package since the freeze started). All of that data can be
automatically generated as part of the summary of the RC bug or the
package itself, then fed into the information visible to developers
reviewing the RC bug list.

The more of this triage process that can be automated, the more
developers can see a standard process being applied and the less work
the release team needs to do for every individual RC bug.

The release team need the ability to override the calculations but that
isn't a problem. The aim, IMHO, would be to reduce the workload by only
putting in an override where required or on explicit request by a
developer to investigate a particular bug/package. I'd like it to be
that only the release team can set the overrides, unlike BTS severity
or tags which requests people avoid ping-pong but cannot prevent it.

> 2.  Things that must either be fixed or the package removed

Quite possibly falls out of the triage data for 1.

I'd also like this to be tied to some automated removal process, just
like the one which was used towards the end of the wheezy freeze.
Maintainers ping'd about individual problems with a clear warning that
the package is at risk of removal if nothing is done, followed by
removal from testing if the bug isn't downgraded or fixed.

Again, obvious time limits, clear decisions and processes.

> I've stayed away from suggesting any tag names.  I think we can adequately 
> bikeshed that if there's some agreement the added granularity would be worth 
> the added complexity.

I think it would be a useful addition and something which does not need
to be restricted to solely within a freeze. We need more of this kind
of stuff running constantly (or at least starting a few weeks after the
previous stable release), with the time limits being adjusted as we
get closer and closer to freeze and then release.

-- 


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



pgpa3Wz6mK2Pv.pgp
Description: PGP signature

monkeysphere TLS client-side certs [was: Re: Developer repositories for Debian]

[Daniel Kahn Gillmor]

Raphaël wrote:

> I don't think that you're speaking of the same thing. I see no
> information about "X.509 client certificates" in Monkeysphere. It
> offers ways to validate the server certificate (if it's not signed by
> known CA) but it doesn't seem to offer any solution to manage client
> certificate.

There actually is functional TLS client-side cert validation via the
monkeysphere (checking identities against the OpenPGP WoT while keeping
the bits on the wire as standard X.509), but it is in a development
branch of mod_gnutls (not yet part of an official release).

If either Bdale or I have signed your key (probably true for many DDs
i've met at various debconfs) you can follow the steps at:

 https://demo.monkeysphere.info/

to see it in action.  That demo is currently configured to rely on
myself and bdale as certifying authorities, but the mechanism can be
configured with arbitrary authorities (including using gpg's concept of
marginal ownertrust), depending on the administrator's preferred
configuration.

I'm hoping to get a new release of mod_gnutls out relatively soon that
should include this capability in an official release.

Regards,

   --dkg

PS Please Cc me on any replies because i am currently too short on time
to drink directly from the firehose that is debian-devel :(


pgpTZqkiViu46.pgp
Description: PGP signature

Re: Debian development and release: always releasable (essay)

[Russ Allbery]

Paul Wise  writes:
> On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:

>> * Keep testing free of RC bugs.

> I keep packages I (co-)maintain free of RC bugs.

The point isn't what individual developers do, particularly developers who
are extremely well-engaged with the project.  The point is to find ways to
do this at another level up.  Obviously, given the number of RC bugs that
we had to fix *after* the freeze, this isn't already being done at the
level required for a timely release process.  I don't think we can solve
that problem by saying "well, developers really *should*."

>> * We should limit the number of packages we strongly care about for
>>   a release.

> I don't agree with this.

Care to expand the thought?

>> * Remove RC buggy packages sooner rather than later. An RC buggy
>>   package should be removed at soon as possible: when the bug

> The release team already do this using a semi-automated method.

But by and large they only do this on a large scale during the freeze, at
which point, in a way, it's too late.  We've already built a huge backlog
of work, and everyone is anxious to release.  I think we should be doing
this continuously during the release and much more aggressively than we've
been willing to do in the past.

I suspect, though, that mini-freezes whenever the RC bug count rises above
a certain level will be as effective or more so, since I know that package
removal very quickly involves deeply tangled dependencies, and one has to
sometimes remove vast swathes of packages to remove a particular RC-buggy
package.

>> We should have an explicit list of such reference installations and
>> declare them as crucial for the release:

> How about:

> all the tasks
> all the blends

That's certainly a good start, although I think it's worth asking the
blends maintainers whether all of the packages they include are
release-critical.  I don't think it captures all of the interesting use
cases, though; there are common patterns that we want Debian to support
that aren't captured in a task or a blend.

>> if they work, we can release, and if they don't, we can't.

> How would you define "work"?

> Presumably: no RC bugs, no piuparts issues?

I would limit it to just no RC bugs (and therefore no test failures where
we're pretty sure that test failure would indicate an RC bug).  If we feel
that piuparts is testing things that should be RC, that would certainly
include piuparts.

Bear in mind, however, that the core problem is that we don't keep testing
sufficiently free of RC bugs to be able to release in a timely fashion
after a freeze.  That means we're not dealing well with the bugs we
already have, so I would be a bit hestitant to create new classes of RC
bugs until we have that situation under control.  While looking for new
classes of bugs is something that we should always be open to, I think the
most important step is to try to catch the bugs we were already catching
earlier in the process and to be more aggressive about dealing with them.

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


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

Bug#707713: ITP: lua-lemock -- LeMock (Lua Easy Mock) for unit test

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: lua-lemock
  Version : 0.6
  Upstream Author : Tommy Petterson 
* URL : https://github.com/LuaDist/lemock/
* License : MIT
  Programming Lang: Lua
  Description : LeMock (Lua Easy Mock) for unit test

 LeMock is a mock creation module intended for use together
 with a unit test framework such as lua-unit. It is inspired by
 EasyMock (for Java), and strives to be easy to use.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlGNEisACgkQS/DSSd0S8lNrUgCfZr6yUBu5lNK44Tn2LLLhP/Io
MtsAn1DmxNmgzDWBPyEjcRRjw7DQiiXD
=cGyk
-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: http://lists.debian.org/20130510152843.2934.18348.reportbug@fiesta

Re: Merging / and /usr (was: jessie release goals)

[Marc Haber]

On Fri, 10 May 2013 11:48:37 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 10, Marc Haber  wrote:
>> Having the rescue image _this_ independent is not really desireable
>> since one would probably have to deal with outdated or non-existing
>> rescue tools in the independent image while the correct software in
>> the correct version is on the system's own / file system.
>I doubt that this is going to be a problem in practice, but if it 
>happens to be then I am sure that the grub glue package(s) can be easily 
>enanched to keep the rescue image up to date.

Additional work necessary to satisfy upstream's bizarre ideas. Why not
keeping things the way they are now? They work. No need to waste
developer time.

>> But I'll have the fsck version that is guaranteed to fit my /usr file
>> system in the big /usr file system, so I'll be forced to use an fsck
>> from a rescue image which might not be the current one, possibly
>> causing even more damage.
>
>People use live CDs for rescue all the time, do you have some data which 
>show that this is actually a problem in real life and not an imaginary 
>problem?

For example, a few years ago, I found myself in a (hoster provided)
rescue image with LVM 2 disabled in the kernel and needed to bootstrap
myself by installing grml[1] in a hastily made file system in the
former swap partition to access my disk.

Greetings
Marc

[1] back then booting grml from its .iso via grub was not possible
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


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

Re: Merging / and /usr (was: jessie release goals)

[Marco d'Itri]

On May 10, Marc Haber  wrote:

> Additional work necessary to satisfy upstream's bizarre ideas. Why not
> keeping things the way they are now? They work. No need to waste
> developer time.
Why make new releases? bo worked fine, there is no need for new features.

> >People use live CDs for rescue all the time, do you have some data which 
> >show that this is actually a problem in real life and not an imaginary 
> >problem?
> For example, a few years ago, I found myself in a (hoster provided)
> rescue image with LVM 2 disabled in the kernel and needed to bootstrap
> myself by installing grml[1] in a hastily made file system in the
> former swap partition to access my disk.
So this confirms that a live system like GRML is a good replacement for 
a rescue system, looks like we solved another use case.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Debianizing the Java world?

[Daniel Pocock]

I started a thread[1] on maven-user yesterday to try and understand
whether Maven's convenience with binary artifacts extrapolates to
convenience working with source

One of the first answers even suggested I should go and see the Debian
folks (the FTP master's reputation for keeping binary stuff out is known
far and wide)

I think this is a gap in what Maven currently offers, but Maven's
modular nature also makes it very easy to fill that gap, and it would be
interesting to try and do it the Debian way.

I just want to understand if I might be duplicating any existing efforts
though.

Specifically, I was thinking that some kind of Maven plugin could be
developed to scan the dependency graphs of projects and, where possible,
extract the SCM details from pom.xml manifests and then recursively (a)
clone their repositories, (b) branch each repo and remove binary
artifacts (junit.jar is a common example) and then (c) try to build
those clean branches and push the binary products into a local Maven
repository.

Presumably, something like this would involve developing a Maven plugin,
some automation with a tool like Jenkins, and developing an efficient
workflow for manually annotating packages (e.g. where the  data is
missing)

Some possible outcomes of this:
a) it could provide a framework for automatically generating Debian
packages, with something closer to DFSG friendliness than a direct link
to a public Maven repo
b) it could be used to make a Debian-friendly equivalent of the Eclipse
marketplace
c) It would also expose any non-free build tools or plugins that are
relied upon in the dependency graphs of larger open source Java projects.

Has anybody else seen any similar efforts, or relevant tools that may
contribute to this, etc?



1.
http://mail-archives.apache.org/mod_mbox/maven-users/201305.mbox/%3C518B6934.2010101%40pocock.com.au%3E


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518d4dc0.5080...@pocock.com.au

Re: Merging / and /usr (was: jessie release goals)

[Marc Haber]

On Fri, 10 May 2013 19:38:22 +0200, m...@linux.it (Marco d'Itri) wrote:
>So this confirms that a live system like GRML is a good replacement for 
>a rescue system, looks like we solved another use case.

You are trying to turn my word around. Bad style of discussion. EOD on
my part, it's another waste of time to reason with you.

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


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

encrypted popcon submissions

[Bill Allombert]

Dear developers,

I am considering activating encryption of popularity-contest submissions
using public key cryptography to protect popcon submission while in transit.

This means

- The popularity-contest package will include a public key that will be used to 
encrypt
report.

- The popcon.debian.org server will know the matching private key and use it to
decrypt report before storing them.

- The key will be changed for each stable Debian release.

The drawback is the computing cost on the server. Currently we are processing
about 25000 report each days, which would require about 2 hours of 'real' 
CPU time to decrypt, which is too much for popov.debian.org. On the other hand
this is easily parallelisable. 

So before I proceed we need to decide as a project whether this is a worthwhile
use of resource.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Barry Warsaw]

On May 03, 2013, at 04:38 PM, Josselin Mouette wrote:

>- source-only uploads
>They are pushed to the buildds, and the produced binaries
>(including arch:all) are put in a staging area (much like
>incoming.d.o). These binaries can be downloaded, but
>the .changes cannot (to forbid skipping the second step).

For the 13.04 release, Ubuntu made a change to its procedure whereby
source-only uploads to the development release (e.g. raring) actually go to
e.g. raring-proposed first.  The builds are attempted and only if they
succeed, pass their autopkgtests, *and* don't make the archive less
installable than before the new upload, are the packages copied over to the
release, e.g. raring.

In practice, I think this works very well.  No users are exposed to broken
packages, or new versions that introduce more installation problems, and
developers can upload source-only.  Mostly gone are the days since `apt-get
dist-upgrade` is a cross-your-fingers-toes-and-eyes crap shoot, and the in-dev
release is pretty darn usable even before the first alpha[1].

Devs should *still* build and test locally of course, but this provides a
great backstop, and it does make for a very quick and easy development cycle.

-Barry

[1] Even the first day after the stable release .


signature.asc
Description: PGP signature

Re: encrypted popcon submissions

[Ian Jackson]

Bill Allombert writes ("encrypted popcon submissions"):
> The drawback is the computing cost on the server. Currently we are
> processing about 25000 report each days, which would require about 2
> hours of 'real' CPU time to decrypt, which is too much for
> popov.debian.org. On the other hand this is easily parallelisable.

Is that using RSA ?  If so then perhaps EC El Gamal would perform
better, if it's available in the relevant versions of gnupg.

Ian.


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

Re: encrypted popcon submissions

[Peter Palfrader]

On Fri, 10 May 2013, Bill Allombert wrote:

> I am considering activating encryption of popularity-contest submissions
> using public key cryptography to protect popcon submission while in transit.

Do you think the benefits outweight the drawback that the admin no
longer can be certain we don't send anything we shouldn't?

> - The popcon.debian.org server will know the matching private key and use it 
> to
> decrypt report before storing them.

> The drawback is the computing cost on the server. Currently we are processing
> about 25000 report each days, which would require about 2 hours of 'real' 
> CPU time to decrypt, which is too much for popov.debian.org. On the other hand
> this is easily parallelisable. 

Why do you think this is too much for popov to handle?  And if it really
is, adding vCPUs is easy.

Why is transport encryption (ala https) not sufficient?

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130510204425.gg22...@anguilla.noreply.org

Bug#707740: general: fails with video Hi10p

[Yuuji Sakai]

Package: general
Severity: normal



-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_MX.utf8, LC_CTYPE=es_MX.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
os[Linux 2.6.32-5-amd64 x86_64] distro[Debian 6.0.7]
cpu[4 x AMD Phenom(tm) II X4 B55 Processor (AuthenticAMD) @ 3200MHz] 
mem[Physical: 3.6GB] disk[Total: 3.7TB] 
video[nVidia Corporation C61 [GeForce 7025 / nForce 630a]] 
sound[HDA-Intel - HDA NVidia]

hi


fails to convert a video Hi10P, style subs lost (DeVeDe for example 
http://i.imgur.com/LWkmHj2.jpg http://i.imgur.com/n9R4G.png 
http://i.imgur.com/zM0yDKZs.jpg), and show error in some programs to edit 
video as avidemux, subtitle editor

 open subtitle Editor
Archivo media no hallado.
file:///home/yuuji/Escritorio/battle1.mkv

Internal GStreamer error: negotiation problem. 
Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.

thank you


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

Re: encrypted popcon submissions

[Ian Jackson]

Peter Palfrader writes ("Re: encrypted popcon submissions"):
> Do you think the benefits outweight the drawback that the admin no
> longer can be certain we don't send anything we shouldn't?

This is a very good point but it can be easily dealt with: the
encrypted message should have two recipients, one of which is a key
whose private half is known to the administrator.  By default it would
be a key created for the popcon installation the first time it would
be used.

Then a suspicious administrator can use their private key to decrypt
the messages to see what's in them, and a well-organised administrator
can drop their public key into the popcon config so they can do it
with their own email client.

Ian.


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

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Barry Warsaw]

On May 05, 2013, at 01:12 AM, Roger Leigh wrote:

>There's definitely an open bug for adding this, and I'll be happy
>for it to be added.  It shouldn't be too hard to implement, though
>we would probably want to make it configurable whether the repeat
>build failing should fail the build as a whole.  We probably want
>to do the repeat after we've copied the built files out of the
>chroot.  We could probably also compare the file paths between
>the source and binary packages in the first and second builds;
>comparing the content itself is probably not realistic.

I'd love to have a --twice option in sbuild.  Should it be the default?
Perhaps, though I would probably --once for most of my build debugging, at
least until a single pass build works reliably.  Then I'd run it once more
with --twice before I blessed the local build.

-Barry


signature.asc
Description: PGP signature

Re: encrypted popcon submissions

[Jakub Wilk]

* Peter Palfrader , 2013-05-10, 22:44:

On Fri, 10 May 2013, Bill Allombert wrote:

I am considering activating encryption of popularity-contest 
submissions using public key cryptography to protect popcon submission 
while in transit.


I think encrypting popcon submissions in an excellent idea. Thanks for 
working on this. :)


Do you think the benefits outweight the drawback that the admin no 
longer can be certain we don't send anything we shouldn't?


Your popcon submission is stored in /var/log/popularity-contest, 
unencrypted. If you don't believe it's the only data that is sent to the 
popcon server, you can read the fine source (it's <400 lines of code). I 
don't suppose any of these is going to change.


What other kind of "certainty" did you have in mind?

--
Jakub Wilk


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

Re: encrypted popcon submissions

[Charles Plessy]

Le Fri, May 10, 2013 at 10:02:06PM +0200, Bill Allombert a écrit :
> 
> I am considering activating encryption of popularity-contest submissions
> using public key cryptography to protect popcon submission while in transit.

Hello Bill,

sorry if it is a naive question: by "public key cryptography", do you mean GPG
or TLS ?

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Debian development and release: always releasable (essay)

[Paul Wise]

On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:

> The point isn't what individual developers do, particularly developers who
> are extremely well-engaged with the project.  The point is to find ways to
> do this at another level up.  Obviously, given the number of RC bugs that
> we had to fix *after* the freeze, this isn't already being done at the
> level required for a timely release process.  I don't think we can solve
> that problem by saying "well, developers really *should*."

The problem this thread is trying to solve essentially comes down to
"people don't do enough work and we want them to do more". There are
various factors at play here; time, motivation, demotivation,
knowledge, confidence and probably more.

> Care to expand the thought?

The diversity of software in Debian is an advantage, I would prefer
that we strongly care about all packages for the release. I expect
that very few people in Debian and none/few of the QA or release team
members in recent years who share my opinion here though, I accept
that and avoid expressing this opinion in general. I also acknowledge
that we just don't have enough people to properly maintain all the
packages in Debian which means that my opinion is also unrealistic.

> But by and large they only do this on a large scale during the freeze, at
> which point, in a way, it's too late.  We've already built a huge backlog
> of work, and everyone is anxious to release.  I think we should be doing
> this continuously during the release and much more aggressively than we've
> been willing to do in the past.

Agreed, I've been poking various RT folks about this over the years,
mainly I suggested completely automated removals for all packages.
That was a bit extreme though since core packages like
apt/toolchain/etc can have RC bugs open for a long time.

> I suspect, though, that mini-freezes whenever the RC bug count rises above
> a certain level will be as effective or more so, since I know that package
> removal very quickly involves deeply tangled dependencies, and one has to
> sometimes remove vast swathes of packages to remove a particular RC-buggy
> package.

I think this is a much better idea than removals.

> That's certainly a good start, although I think it's worth asking the
> blends maintainers whether all of the packages they include are
> release-critical.  I don't think it captures all of the interesting use
> cases, though; there are common patterns that we want Debian to support
> that aren't captured in a task or a blend.

Agreed. Do you have any example use-cases that should block releases
but aren't in blends or tasks? Perhaps we need to start some new
blends or add new tasks.

> I would limit it to just no RC bugs (and therefore no test failures where
> we're pretty sure that test failure would indicate an RC bug).  If we feel
> that piuparts is testing things that should be RC, that would certainly
> include piuparts.

piuparts folks generally already file RC bugs as they are able.

> Bear in mind, however, that the core problem is that we don't keep testing
> sufficiently free of RC bugs to be able to release in a timely fashion
> after a freeze.  That means we're not dealing well with the bugs we
> already have, so I would be a bit hestitant to create new classes of RC
> bugs until we have that situation under control.  While looking for new
> classes of bugs is something that we should always be open to, I think the
> most important step is to try to catch the bugs we were already catching
> earlier in the process and to be more aggressive about dealing with them.

Ack.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debianizing the Java world?

[Paul Wise]

I think you want to discuss this on the debian-java list instead.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian development and release: always releasable (essay)

[Russ Allbery]

Paul Wise  writes:
> On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:

>> The point isn't what individual developers do, particularly developers
>> who are extremely well-engaged with the project.  The point is to find
>> ways to do this at another level up.  Obviously, given the number of RC
>> bugs that we had to fix *after* the freeze, this isn't already being
>> done at the level required for a timely release process.  I don't think
>> we can solve that problem by saying "well, developers really *should*."

> The problem this thread is trying to solve essentially comes down to
> "people don't do enough work and we want them to do more".  There are
> various factors at play here; time, motivation, demotivation, knowledge,
> confidence and probably more.

Well, sort of -- we are also proposing an alternative: not shipping those
packages with the next stable release, but making them available to users
in some other way.  So, people don't have to do more work, but instead of
then freezing for months so that everyone else in the project fixes those
packages, we pull them from stable early.  If keeping them in stable is
more work than anyone is willing to do, then they won't be in the release,
and we'll know that much earlier on.  Furthermore, what does need to be
done to keep them in stable will be clearer.

In other words, the proposal is an attempt to fail faster, instead of
accumulating work (which grows larger with each release of Debian) until
the freeze and then trying to fix it all then, across the entire project.

I see below that you generally agree with that part of the proposal
anyway, though.  :)

> The diversity of software in Debian is an advantage, I would prefer that
> we strongly care about all packages for the release. I expect that very
> few people in Debian and none/few of the QA or release team members in
> recent years who share my opinion here though, I accept that and avoid
> expressing this opinion in general. I also acknowledge that we just
> don't have enough people to properly maintain all the packages in Debian
> which means that my opinion is also unrealistic.

I do agree with this opinion (the breadth of Debian is why I'm using it
instead of Red Hat for work), but it's the second part that I'm worried
about.  I do think that some additional clarity and failing faster in
pulling things out of testing sooner will help people focus their efforts
and help with making tradeoff decisions.

> Agreed. Do you have any example use-cases that should block releases but
> aren't in blends or tasks? Perhaps we need to start some new blends or
> add new tasks.

I would need to do some research, since I'm not personally familiar with
everything that's in a blend or a task at the moment.  Just off the top of
my head, though, to pick an area of personal expertise, I don't think
there's an existing blend or task for a Kerberos KDC or, more generally,
an authentication and identity management infrastructure.  That's one that
I'd be willing to tackle creating a package list for if we went this
route.

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


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

Re: encrypted popcon submissions

[Paul Wise]

On Sat, May 11, 2013 at 8:40 AM, Charles Plessy wrote:

> sorry if it is a naive question: by "public key cryptography", do you mean GPG
> or TLS ?

He is talking about OpenPGP and gpg, TLS wouldn't be helpful since
popcon uses either SMTP or HTTP.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian development and release: always releasable (essay)

[Paul Wise]

On Sat, May 11, 2013 at 10:42 AM, Russ Allbery wrote:

> I would need to do some research, since I'm not personally familiar with
> everything that's in a blend or a task at the moment.  Just off the top of
> my head, though, to pick an area of personal expertise, I don't think
> there's an existing blend or task for a Kerberos KDC or, more generally,
> an authentication and identity management infrastructure.  That's one that
> I'd be willing to tackle creating a package list for if we went this
> route.

Sounds like something that would be suitable for a task package, I'm
not sure if d-i folks will be happy about including more tasks though.
This is a conversation we need to have anyway, blends folks have been
talking about ways to integrate blends with d-i (and Debian in
general), so we need better ways to expose blends and tasks in d-i
that cope with the large amount of diversity of usage we have in
Debian.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6EY7=2pt_w2zcannnajs+hpljhfvha1y+b-ipgrwpj...@mail.gmail.com

Re: Debian development and release: always releasable (essay)

[Helmut Grohne]

On Thu, May 09, 2013 at 08:49:51PM +0100, Lars Wirzenius wrote:
> * Remove RC buggy packages sooner rather than later. An RC buggy
>   package should be removed at soon as possible: when the bug
>   is identified, allow a bit of time for the bug to be verified
>   (was it actually an RC bug?), but after that, remove the package
>   from testing, preferably automatically.  If the package has
>   reverse dependencies, remove those as well. This keeps testing
>   releasable. The removed package can and will re-enter testing once
>   it gets fixed.

The value of package removal, is to clarify that the release will not
wait for this package. I fear that having a flaky testing distribution
with packages frequently removed and added again would cause problems on
its own merits. On the other hand maybe removal is not the thing we are
aiming for? I am aware of at least one case where a removal notice (the
actual removal never happened) caused a third party to fix a package,
because maintaining it himself would have been more work. Maybe making
those removal notices more visible would help getting further people
involved? What about feeding removal notices to planet.d.o? And yeah,
more of them should help as well. To that end improving the rc-alert
output (and making this utility more visible to end users) could improve
the situation as well.

>   To reduce the sting of optional packages missing the release, we
>   should consider whether we're willing to introduce new packages
>   in stable point releases.  Obviously, only packages that have
>   no new dependencies could be introduced that way, so things that
>   require newer versions of the packages already in stable would not
>   be eligible.  But it means that if a package was in the previous
>   stable but missed the current stable due to unresolved issues at
>   the time of the releease, we could still get it back in and it
>   wouldn't have to wait another year or two.

This idea has a negative side effect. If my pet package is missing from
a stable release I am probably tempted to wait with upgrading, because
there is a chance for it to be reintroduced. This even applies if the
package does not end up being added due to the scarce availability of
time machines. The current policy of not extending a stable release
actually provides a benefit: clarity.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130511055427.ga19...@alf.mars

Re: Debian development and release: always releasable (essay)

[Andreas Tille]

Hi

On Fri, May 10, 2013 at 07:42:21PM -0700, Russ Allbery wrote:
> Paul Wise  writes:
> > Agreed. Do you have any example use-cases that should block releases but
> > aren't in blends or tasks? Perhaps we need to start some new blends or
> > add new tasks.
> 
> I would need to do some research, since I'm not personally familiar with
> everything that's in a blend or a task at the moment.  Just off the top of
> my head, though, to pick an area of personal expertise,

>From my point of view one main point in Blends is that you can (if you
care enough) assemble some manpower behind a certain set of packages.
For Debian Med I have some proof of this statement which are those ten
developers that inserted "yes" in the column "DD because Debian Med
exists" in the developers questionaire I did[1].  In other words:
Because there is a Blend we do have the people working on its packages.

I admit that running a Blend is also extra work to explain it to people
but extra manpower of 10 people (which is one per year of the projects
life time) was worth the effort.

> I don't think
> there's an existing blend or task for a Kerberos KDC or, more generally,
> an authentication and identity management infrastructure.  That's one that
> I'd be willing to tackle creating a package list for if we went this
> route.

IMHO this could be kick-started from Debian Enterprise.

Kind regards

  Andreas.

[1] https://wiki.debian.org/DebianMed/Developers 

-- 
http://fam-tille.de


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

Re: can someone explain what is happen on line one from this listing?

[Mailbox]

Hello all,

i aks this list because i will now more about the "lost Interrupt 0x50) 
error.
A faulty hard disk, makes other Logentries and this disk are replace by 
the vendor this disk is a new/refurbished disk.


I have test with other Serverhardware what is happen if i put out the 
power cabel from the disk. it is interesting but in all my test/hacks i 
never have see a "lost interrupt"


why i loos this interrupt?

bye

Paulo

Am 09.05.2013 20:43, schrieb Istimsak Abdulbasir:


It seems you have a faulty hard disk.

Istimsak abdulbsir

On May 9, 2013 7:47 AM, "Mailbox" > wrote:


Hello Developer Group,

can someone explain what is happen on line one from this listing?

why i loos the interrupt?

what is the Status 0x50?

has someone a idea in which Documentation an can finde more
informations about 0x50?

May  7 19:39:57 lxhs110a kernel: [316946.812055] ata2: lost
interrupt (Status 0x50)
May  7 19:39:57 lxhs110a kernel: [316946.812072] ata2: exception
Emask 0x10 SAct 0x0 SErr 0x4405 action 0xf
May  7 19:39:57 lxhs110a kernel: [316946.812116] ata2: SError: {
PHYRdyChg CommWake DevExch }
May  7 19:39:57 lxhs110a kernel: [316946.812156] ata2: hard
resetting link
May  7 19:39:58 lxhs110a kernel: [316947.536038] ata2: SATA link
up 1.5 Gbps (SStatus 113 SControl 300)
May  7 19:39:58 lxhs110a kernel: [316947.560823] ata2.00:
configured for UDMA/133
May  7 19:39:58 lxhs110a kernel: [316947.560831] end_request: I/O
error, dev sdb, sector 25141733
May  7 19:39:58 lxhs110a kernel: [316947.560876] md: super_written
gets error=-5, uptodate=0
May  7 19:39:58 lxhs110a kernel: [316947.560880] raid1: Disk
failure on sdb4, disabling device.
May  7 19:39:58 lxhs110a kernel: [316947.560881] raid1: Operation
continuing on 1 devices.
May  7 19:39:58 lxhs110a kernel: [316947.560962] ata2: EH complete
May  7 19:39:58 lxhs110a kernel: [316947.595196] RAID1 conf printout:
May  7 19:39:58 lxhs110a kernel: [316947.595198]  --- wd:1 rd:2
May  7 19:39:58 lxhs110a kernel: [316947.595201]  disk 0, wo:1,
o:0, dev:sdb4
May  7 19:39:58 lxhs110a kernel: [316947.595203]  disk 1, wo:0,
o:1, dev:sda4
May  7 19:39:58 lxhs110a kernel: [316947.608009] RAID1 conf printout:
May  7 19:39:58 lxhs110a kernel: [316947.608011]  --- wd:1 rd:2
May  7 19:39:58 lxhs110a kernel: [316947.608013]  disk 1, wo:0,
o:1, dev:sda4

thanks
Paulo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org


with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org 
Archive: http://lists.debian.org/518b8c73.20...@ai-t.eu