date:20130512

On 05/11/2013 06:53 PM, Tollef Fog Heen wrote:
> ]] Johannes Schauer 
>
>> Maybe the puppet question can just be solved by introducing an openstack 
>> task?
> puppet isn't important because it's used by/part of openstack (which I
> don't think it is?)
Puppet isn't used by OpenStack. Though it's used by operators to setup
some OpenStack based cloud.

I don't think there's the need of an OpenStack task. There is already
"openstack-meta-packages" that I created, which helps setting-up
either a "controler" node, or a compute node. Having it used as part
of a custom CD would be nice though (I've been looking at using
live-build to do that, though I failed to find enough time to do it yet).

I know very little about blends. Maybe it is something I should have
a look into? Would it be a good idea to use a task instead of my
openstack-meta-packages?

Cheers,

Thomas

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

Bug#707964: ITP: libarchive-extract-perl -- A generic archive extracting mechanism

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libarchive-extract-perl
  Version : 0.68
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/Archive-Extract
* License : Perl
  Programming Lang: Perl
  Description : A generic archive extracting mechanism

Archive::Extract is a generic archive extraction mechanism.
It allows you to extract any archive file of the type .tar, .tar.gz, .gz,
.Z, tar.bz2, .tbz, .bz2, .zip, .xz,, .txz, .tar.xz or .lzma without having
to worry how it does so, or use different interfaces for each type by using
either perl modules, or commandline tools on your system.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately. The perl 5.18 packages
will depend on, recommend or suggest deprecated modules for one release
cycle, as appropriate.


-- 
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/20130512113847.9878.8611.report...@callisto.larted.org.uk

Bug#707966: ITP: libb-lint-perl -- Perl lint

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libb-lint-perl
  Version : 1.17
  Upstream Author : Ricardo SIGNES 
* URL : https://metacpan.org/release/B-Lint
* License : Perl
  Programming Lang: Perl
  Description : Perl lint

The B::Lint module is equivalent to an extended version of the -w option of
perl. It is named after the program lint which carries out a similar
process for C programs.


-- 
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/20130512114400.10300.2161.report...@callisto.larted.org.uk

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

On 05/12/2013 02:03 AM, Antonio Terceiro wrote:
> You can't assume that just because something works today, it will work
> forever.

True, though it's been at least 2 release cycle (maybe 3?) that this
set of packages were maintained quite well. I don't remember
seeing complains or bad bugs. Do you?

> Having such tests in place will help to automatically catch
> regressions if they arise.

My point is: I don't think so, and I think we are better off focusing
on other (real?) problems.

Thomas

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

Bug#707967: ITP: libcpanplus-dist-build-perl -- CPANPLUS plugin to install packages that use Build.PL

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libcpanplus-dist-build-perl
  Version : 0.70
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/CPANPLUS-Dist-Build
* License : Perl
  Programming Lang: Perl
  Description : CPANPLUS plugin to install packages that use Build.PL

CPANPLUS::Dist::Build is a distribution class for Module::Build related
modules. Using this package, you can create, install and uninstall perl
modules. It inherits from CPANPLUS::Dist.

Normal users won't have to worry about the interface to this module, as it
functions transparently as a plug-in to CPANPLUS and will just Do The Right
Thing when it's loaded.


-- 
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/20130512114733.10410.40177.report...@callisto.larted.org.uk

Re: parsable copyright format 1.0 (jessie release goals)

On 05/12/2013 06:43 PM, Sune Vuorela wrote:
> On 2013-05-12, Thomas Goirand  wrote:
>> archive to know what kind of license we're using. If we all work
>> a bit on our own packages, it should be fine, and at some
>> point, we should move forward. But does anyone think it is
>> too much work? I would understand that point of view.
> It is too much work for far too little gain. What *is* the gain?
> What is the gain of copyright files?

Being able to write tools to extract the license of any given package.
For example, we could see packages.d.o exposing the license of
any giving software. That would be really nice! A way better than
just linking to the copyright file. Or being able to build statistics,
or extract a subset of packages using this or that license. This
has already been done in the past, but this would make it a lot
more easy to do.

> I fought quite hard against the copyright file format but was promised
> that it wouldn't be something required.

At least *I* never did such promise.

Thomas

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

Bug#707968: ITP: libcpanplus-perl -- API & CLI access to the CPAN mirrors

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libcpanplus-perl
  Version : 0.9136
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/CPANPLUS
* License : Perl
  Programming Lang: Perl
  Description : API & CLI access to the CPAN mirrors

The CPANPLUS library is an API to the CPAN mirrors and a collection of
interactive shells, commandline programs, etc, that use this API.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated
modules for one release cycle, as appropriate.


-- 
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/20130512115123.10508.34303.report...@callisto.larted.org.uk

Re: parsable copyright format 1.0 (jessie release goals)

2013-05-12 Thread Sune Vuorela

On 2013-05-12, Thomas Goirand  wrote:
> Being able to write tools to extract the license of any given package.
> For example, we could see packages.d.o exposing the license of
> any giving software. That would be really nice! A way better than
> just linking to the copyright file. Or being able to build statistics,
> or extract a subset of packages using this or that license. This
> has already been done in the past, but this would make it a lot
> more easy to do.

How many hours of developer time is it worth to spend to accomplish
these, in my opinion,  real fringe use cases ?

/Sune


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

Bug#707971: ITP: libfile-checktree-perl -- run many filetest checks on a tree

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libfile-checktree-perl
  Version : 4.42
  Upstream Author : Ricardo SIGNES 
* URL : https://metacpan.org/release/File-CheckTree
* License : Perl
  Programming Lang: Perl
  Description : run many filetest checks on a tree

File::CheckTree provides a convenient way to provide a recipe of tests
on filesystem trees in a hierachical way, using the single validate()
function.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512120723.10605.41034.report...@callisto.larted.org.uk

Bug#707973: ITP: liblog-message-simple-perl -- Simplified interface to Log::Message

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: liblog-message-simple-perl
  Version : 0.10
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/Log-Message-Simple
* License : Perl
  Programming Lang: Perl
  Description : Simplified interface to Log::Message

This module provides standardized logging facilities using the Log::Message
module.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512121013.10951.18593.report...@callisto.larted.org.uk

Bug#707975: ITP: liblog-message-perl -- A generic message storing mechanism

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: liblog-message-perl
  Version : 0.08
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/Log-Message
* License : Perl
  Programming Lang: Perl
  Description : A generic message storing mechanism

Log::Message is a generic message storage mechanism. It allows you to store
messages on a stack -- either shared or private -- and assign meta-data to
it. Some meta-data will automatically be added for you, like a timestamp and
a stack trace, but some can be filled in by the user, like a tag by which to
identify it or group it, and a level at which to handle the message (for
example, log it, or die with it)

Log::Message also provides a powerful way of searching through items by
regexes on messages, tags and level.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512121429.11072.28920.report...@callisto.larted.org.uk

Bug#707979: ITP: libmodule-pluggable-perl -- automatically give your module the ability to have plugins

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libmodule-pluggable-perl
  Version : 4.7
  Upstream Author : Simon Wistow 
* URL : https://metacpan.org/release/Module-Pluggable
* License : Perl
  Programming Lang: Perl
  Description : automatically give your module the ability to have plugins

Provides a simple but, hopefully, extensible way of having 'plugins' for
your module. Essentially all it does is export a method into your namespace
that looks through a search path for .pm files and turn those into class
names. Optionally it instantiates those classes for you.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512121743.11191.79471.report...@callisto.larted.org.uk

Bug#707981: ITP: libobject-accessor-perl -- interface to create per object accessors

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libobject-accessor-perl
  Version : 0.46
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/Object-Accessor
* License : Perl
  Programming Lang: Perl
  Description : interface to create per object accessors

Object::Accessor provides an interface to create per object accessors (as
opposed to per Class accessors, as, for example, Class::Accessor provides).
You can choose to either subclass this module, and thus using its accessors
on your own module, or to store an Object::Accessor object inside your own
object, and access the accessors from there. See the SYNOPSIS for examples.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512122403.11365.42705.report...@callisto.larted.org.uk

Bug#707984: ITP: libpod-latex-perl -- Convert Pod data to formatted Latex

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libpod-latex-perl
  Version : 0.61
  Upstream Author : Tim Jenness 
* URL : https://metacpan.org/release/Pod-LaTeX
* License : Perl
  Programming Lang: Perl
  Description : Convert Pod data to formatted Latex

Pod::LaTeX is a module to convert documentation in the Pod format into Latex.
The pod2latex command uses this module for translation.

Pod::LaTeX is a derived class from Pod::Select.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512123106.11487.7676.report...@callisto.larted.org.uk

Bug#707985: ITP: libterm-ui-perl -- Term::ReadLine UI made easy

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libterm-ui-perl
  Version : 0.34
  Upstream Author : Chris Williams 
* URL : https://metacpan.org/release/Term-UI
* License : Perl
  Programming Lang: Perl
  Description : Term::ReadLine UI made easy

Term::UI is a transparent way of eliminating the overhead of having to
format a question and then validate the reply, informing the user if the
answer was not proper and re-issuing the question.

Simply give it the question you want to ask, optionally with choices the
user can pick from and a default and Term::UI will DWYM.

For asking a yes or no question, there's even a shortcut.

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated  
modules for one release cycle, as appropriate.


-- 
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/20130512123401.11650.37750.report...@callisto.larted.org.uk

Bug#707988: ITP: libtext-soundex-perl -- Implementation of the soundex algorithm

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libtext-soundex-perl
  Version : 3.04
  Upstream Author : Ricardo SIGNES 
* URL : https://metacpan.org/release/Text-Soundex
* License : BSDish
  Programming Lang: Perl
  Description : Implementation of the soundex algorithm

This module implements the original soundex algorithm developed by Robert
Russell and Margaret Odell, patented in 1918 and 1922, as well as a
variation called "American Soundex" used for US census data, and current
maintained by the National Archives and Records Administration (NARA).

This module is being deprecated from the perl base distribution in
5.18.0, so it is planned to package it separately to provide continuity.
The perl 5.18 packages will depend on, recommend or suggest deprecated
modules for one release cycle, as appropriate.


-- 
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/20130512124458.11725.11914.report...@callisto.larted.org.uk

Re: /bin/sh (was Re: jessie release goals)

2013-05-12 Thread Joerg Jaspert

On 13209 March 1977, Marc Haber wrote:
>>Like for everything in Debian, this is bound to someone killing
>>the concept of a default Desktop. It is indeed a shame that
>>nobody worked on that.
> What is planned to do so? I surely hope that we don't end up building
> Kebian, Gebian and Xebian Images, which has always striked (stricken?)
> me as an utter waste.

Not sure when you did it last (or rleigh or zigo) - but: Take a look at
what CDs we over.

What you hope - we already do. We have CDs which default to KDE, XFCE or
LXDE for those who dislike the GNOME feature-removitis.

-- 
bye, Joerg
 vorlon: would it be less subtle if we replaced red, green and
 yellow with black, white and a shade of grey?
 aj: "and this is what a necrotic port looks like"?
 vorlon: the arch qualification table, halloween edition?
 vorlon: "i heard a faint pinging, and went to the firewall and what
 greeted my eyes? AN m68k RISED FROM THE GRAVE!!!"


-- 
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/87ip2oe1y9@gkar.ganneff.de

Re: idea: generalized soft dependencies

2013-05-12 Thread David Kalnischkies

On Thu, May 9, 2013 at 9:24 PM, Eugene V. Lyubimkin  wrote:
> tl;dr: I would want to be able to differentiate between, for example,
>
> - "install this or your system will break (unless you did special things so 
> it does not)";
> - "install this unless you know you'll never need this feature";
> - "this things is worth installing by default".

What I mean is that you either have to define the values for these classes
or maintainer A will write 70% and B 80% to transport the same meaning.
And these classes need to be defined really well. E.g. your second class
is the same as the third class (for me, others will see it differently)
as a package for a feature I will need at some point is well worth to be
installed and a package worth to be installed is one providing a feature
I will need …

Currently we have 3 slots we can place dependencies in. Providing 100 slots
isn't going to fix the problem of not having a deterministic entity placing
the dependencies in the correct slot. For all practical proposes we have an
infinite amount of entities deciding based on their current state/experience
which causes new experiences forming a self-feeding reinforcement loop.

>> > Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
>>
>> So supposedly on 50% of all desktops iceweasel is installed which can
>> in turn be used by the software having this dependency. Great, but I still
>> have no idea why 50% installed it and 50% don't.
>
> It was an example of maintainer guessing that half of users of some
> software will want also iceweasel installed, provided the computer "is
> desktop".

Yeah, and what I meant is that this doesn't give me any new useful info.
That iceweasel does something useful in combination with this package is
clear just by listing it here. That its not a Recommends tells me that it
is not part of what upstream/the maintainer considers a "usual installation",
but it is in no way telling me why 50% install it – and whats the propose of
an annotation if it isn't going to help me?

>> Which 50% group I am part of? The tag desktop might give a hint, but
>> such tags need to be defined and carry a meaning. A tag like "laptop"
>> tells me that it will help with powersaving (which would probably be the
>> better tag name, as I will like want to install it on my phone too),
>> "printing" is useless if I don't have a printer, "online" and "streaming"
>> might not be the best ideas if I have no internet connection at all …
>> That's a lot harder of course, but caries way more useful information as
>> I have no idea how many people don't have their own nuclear power plant,
>> highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
>> that in my area (and I would probably still be wrong), but not on a global
>> scale.
>
> I don't propose any specific attribute. I propose to have an ability to later
> discuss and standardize these attributes.
>
>> > Soft-Depends: debdelta {10%,text:"to enable automatic delta downloading"}
>>
>> While this solves the why, we have a new problem: Translations
>> And these texts are quickly written in a way a user can't use:
>> What the hell is a "delta"? -> debian-l10n-english to the rescue!?
> [...]
>
> You speak about problems of a specific example attribute. We might use
> text: attribute, we might not use is. Unless your point is say that
> (all) attributes don't help (and therefore the proposal doesn't make the
> situation better), this is not what proposal is about.

Yes, I speak about this specific type of attributes, namely such which have
free text in them. If I want a free-form documentation of why it could be
useful to install this or that we have documentation for that, starting with
the long description. Attributes should be limited to something which can be
evaluated by a package manager automatically to help the user, not another
blob of text nobody is going to read (and understand).

I do this because its out of question that a package manager needs to help
a user more to manage the ever-growing pool of packages to choose from.
(At least I highly doubt there is anyone thinking we don't need to.)

The question is how and my personal impression is that this is neither
solved by adding 97 new classes of (soft-)dependencies nor by free-form
text and I outline why I think this in the hope that I am either convinced
of the opposite or that we find something else which would work.

>> Of course, this doesn't work if wget is used instead of debdelta in the
>> example as wget is used by a lot of stuff, but always for the same task:
>> So annotating all dependencies on wget with the tag use:downloading just
>> feels wrong. And the package wget is already tagged with use:downloading,
>> we just don't make proper use of this so far.
>
> Sounds like I had not enough good example if you feel this was about
> 'use:downloading'. The idea of this example was not to repeat packages
> descriptions, but say how the soft dependency will help

Re: idea: generalized soft dependencies

2013-05-12 Thread Michael Banck

On Sun, May 12, 2013 at 03:53:06PM +0200, David Kalnischkies wrote:
> >> > Soft-Depends: debdelta {10%,text:"to enable automatic delta downloading"}
> >>
> >> While this solves the why, we have a new problem: Translations
> >> And these texts are quickly written in a way a user can't use:
> >> What the hell is a "delta"? -> debian-l10n-english to the rescue!?
> > [...]
> >
> > You speak about problems of a specific example attribute. We might use
> > text: attribute, we might not use is. Unless your point is say that
> > (all) attributes don't help (and therefore the proposal doesn't make the
> > situation better), this is not what proposal is about.
> 
> Yes, I speak about this specific type of attributes, namely such which have
> free text in them. If I want a free-form documentation of why it could be
> useful to install this or that we have documentation for that, starting with
> the long description. Attributes should be limited to something which can be
> evaluated by a package manager automatically to help the user, not another
> blob of text nobody is going to read (and understand).

Couldn't the package manager display the commends for a particular 
Recommends or Suggests (provided comments are allowed for those fields,
if not we should maybe allow them and also propagate them into the 
binary package metadata).  Those comments could then be translated as 
well.


Michael


-- 
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/20130512143007.gd31...@nighthawk.chemicalconnection.dyndns.org

Re: jessie release goals

2013-05-12 Thread Daniel Schepler

Maybe we could have a release goal of dropping as many lib32* and lib64*
packages as possible in favor of multi-arch.  (And also as many package
dependencies on libc6-[i386|amd64] as possible, which would in addition
mean limiting some packages to arch:i386 if they currently provide a fake
arch:amd64 package with an i386 binary.)

Of course, to completely get rid of everything including libc6-* and
lib32gcc1, etc., we'd need special configuration on the buildds to continue
building gcc with multilib support; and the GCC maintainer has expressed
resistance to being that radical even if we could get this buildd support.
-- 
Daniel Schepler

Re: jessie release goals

2013-05-12 Thread Cyril Brulebois

Daniel Schepler  (12/05/2013):
> Maybe we could have a release goal of dropping as many lib32* and
> lib64* packages as possible in favor of multi-arch.  (And also as
> many package dependencies on libc6-[i386|amd64] as possible, which
> would in addition mean limiting some packages to arch:i386 if they
> currently provide a fake arch:amd64 package with an i386 binary.)

If you really want to push m-a any further, you really want to get
dpkg able to co-install binNMU'd m-a packages.

(Actually, you probably want the latter even without the former.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: jessie release goals

2013-05-12 Thread Matthias Klose

Am 12.05.2013 16:18, schrieb Daniel Schepler:
> Maybe we could have a release goal of dropping as many lib32* and lib64*
> packages as possible in favor of multi-arch.  (And also as many package
> dependencies on libc6-[i386|amd64] as possible, which would in addition
> mean limiting some packages to arch:i386 if they currently provide a fake
> arch:amd64 package with an i386 binary.)
> 
> Of course, to completely get rid of everything including libc6-* and
> lib32gcc1, etc., we'd need special configuration on the buildds to continue
> building gcc with multilib support; and the GCC maintainer has expressed
> resistance to being that radical even if we could get this buildd support.

Well, GCC should keep building with a sane amount of effort.  And that currently
means not depending on a "foreign" architecture on the buildds.  So before this
can happen:

 - get dpkg ready to accept b-d's on foreign architectures.

 - get GCC ready to search for gcc_lib_dir for foreign multilibs.
   and get this submitted upstream before getting it to the Debian
   packages.

 - find a solution for multilibs which are not fully supported architectures,
   but only partial ports, or ports maintained outside the archive.

 - get the buildd infrastructure ready.

 - find a solution that GCC's b-d's may not be installable anymore with
   the current approach to binNMUs.

It is wrong to drop the current multilib support before these are implemented
and in place.

So what do you commit to work on?

I don't think that there are that many packages where you can or should drop
multilib support.  So it would be wrong to drop multilib support for zlib (GCC,
gdb), ncurses, readline, expat (gdb) now.  And there are not that many more
packages providing multilib support.

  Matthias


-- 
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/518faff2.50...@debian.org

Re: /bin/sh (was Re: jessie release goals)

On 05/12/2013 09:56 PM, Joerg Jaspert wrote:
> Not sure when you did it last (or rleigh or zigo) - but: Take a look at
> what CDs we over.
>
> What you hope - we already do. We have CDs which default to KDE, XFCE or
> LXDE for those who dislike the GNOME feature-removitis.
Which is very different from being able to select, in d-i,
what desktop you want (for example using the netinst CD).

Thomas


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

Re: parsable copyright format 1.0 (jessie release goals)

2013-05-12 Thread Steve Langasek

On Sun, May 12, 2013 at 07:52:25PM +0800, Thomas Goirand wrote:

> > I fought quite hard against the copyright file format but was promised
> > that it wouldn't be something required.

> At least *I* never did such promise.

I certainly did make the point that having a standard, machine-parseable
copyright format available does not imply that it's mandatory to use it.  I
stand by this position, and am opposed to any efforts to make this mandatory
until there is very good tooling for generating these files painlessly that
the project has a high degree of confidence in.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

signature.asc
Description: Digital signature

Re: parsable copyright format 1.0 (jessie release goals)

2013-05-12 Thread Lars Wirzenius

On Sun, May 12, 2013 at 09:20:46AM -0700, Steve Langasek wrote:
> On Sun, May 12, 2013 at 07:52:25PM +0800, Thomas Goirand wrote:
> 
> > > I fought quite hard against the copyright file format but was promised
> > > that it wouldn't be something required.
> 
> > At least *I* never did such promise.
> 
> I certainly did make the point that having a standard, machine-parseable
> copyright format available does not imply that it's mandatory to use it.  I
> stand by this position, and am opposed to any efforts to make this mandatory
> until there is very good tooling for generating these files painlessly that
> the project has a high degree of confidence in.

I agree with my DEP5 co-driver.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20130512163258.gt2...@havelock.liw.fi

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

2013-05-12 Thread Stéphane Glondu

Le 11/05/2013 20:05, Aron Xu a écrit :
> An easy example is that, on Solaris, there is a something called boot
> environment (BE), which is essentially snapshots of the combination of
> /usr and /boot, users can switch between different BEs easily without
> affecting any user data. Without /usr merge, doing such work could be
> much more complicated because user data and system data is mixed in
> the file system's hierarchy, it's hard to make sure switching between
> different snapshots won't change user data. While if such thing is
> done properly, then user won't be bothered about messing up the system
> on upgrades or experiments anymore. They can switch among different
> working environments easily, without dealing with the odds caused by
> multi-boot.

What about /etc ? /var ? both contain data that can mess up with a
running system...

-- 
Stéphane


--
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/518fc4b0.70...@debian.org

Re: jessie release goals

2013-05-12 Thread Daniel Schepler

On Sun, May 12, 2013 at 8:06 AM, Matthias Klose  wrote:

> Am 12.05.2013 16:18, schrieb Daniel Schepler:
> > Maybe we could have a release goal of dropping as many lib32* and lib64*
> > packages as possible in favor of multi-arch.  (And also as many package
> > dependencies on libc6-[i386|amd64] as possible, which would in addition
> > mean limiting some packages to arch:i386 if they currently provide a fake
> > arch:amd64 package with an i386 binary.)
> >
> > Of course, to completely get rid of everything including libc6-* and
> > lib32gcc1, etc., we'd need special configuration on the buildds to
> continue
> > building gcc with multilib support; and the GCC maintainer has expressed
> > resistance to being that radical even if we could get this buildd
> support.
>
> Well, GCC should keep building with a sane amount of effort.  And that
> currently
> means not depending on a "foreign" architecture on the buildds.  So before
> this
> can happen:
>
>  - get dpkg ready to accept b-d's on foreign architectures.
>
>  - get GCC ready to search for gcc_lib_dir for foreign multilibs.
>and get this submitted upstream before getting it to the Debian
>packages.
>

I didn't need to do anything special on this back when I did the proof of
concept.  All I had to do was adjust the /32/libgcc_s.so symlink
created in the packaging to point to the multiarch location.

>
>  - find a solution for multilibs which are not fully supported
> architectures,
>but only partial ports, or ports maintained outside the archive.
>

That case could continue to use multilib without creating the (admittedly
minor) redundancy that multilib + multiarch creates.

>
>  - get the buildd infrastructure ready.
>
>  - find a solution that GCC's b-d's may not be installable anymore with
>the current approach to binNMUs.
>

OK, that's a good point that I hadn't thought of before.  So, it does make
sense to keep libc6-i386 and lib32gcc1 if only for cross-architecture
version skew issues.  But I also think for most users it would make sense
to allow for the option of satisfying gcc-multilib's dependencies using
multiarch, and to make this the default option on multiarch systems.
Though that would probably involve adding alternatives somewhere which
might be more trouble than it's worth...

>
> It is wrong to drop the current multilib support before these are
> implemented
> and in place.
>
> So what do you commit to work on?
>
> I don't think that there are that many packages where you can or should
> drop
> multilib support.  So it would be wrong to drop multilib support for zlib
> (GCC,
> gdb), ncurses, readline, expat (gdb) now.  And there are not that many more
> packages providing multilib support.
>

Umm, maybe this is a stupid question, but why would we need to support
uploading packaged cross-compiled versions of gdb?  As for the others you
listed, I've gotten by just fine on x32 without any lib[32|64]z1 etc.
packages.

(Also, on a side note: do you have any idea why expat provides lib64expat1
but no lib32expat1?)
-- 
Daniel Schepler

Re: jessie release goals

2013-05-12 Thread Tollef Fog Heen

]] Vincent Lefevre 

> I agree for these services (though Apache is useless after just
> being installed, as one just has a dummy web page).

So useful, since you can then put files into the docroot and serve those
files. (An analogy to your example could be an imap server being
useless, since there's no mail to be fetched on a freshly installed
server.)

> But not for postfix, which can reject mail by default without an
> initial configuration. Since it is not working by default, and loses
> mail, the daemon shouldn't be enabled by default.

IIRC, postfix defaults to local mail only, listening on localhost only,
so how it would reject mail by default, I'm not sure?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehdc16rl@xoog.err.no

Re: /bin/sh (was Re: jessie release goals)

2013-05-12 Thread Andrei POPESCU

On Du, 12 mai 13, 23:12:48, Thomas Goirand wrote:
> Which is very different from being able to select, in d-i,
> what desktop you want (for example using the netinst CD).

This is already possible (from the boot menu).

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

Re: jessie release goals

2013-05-12 Thread Philip Hands

Hi Vincent,

Vincent Lefevre  writes:
...
> I agree for these services (though Apache is useless after just
> being installed, as one just has a dummy web page). But not for
> postfix, which can reject mail by default without an initial
> configuration. Since it is not working by default, and loses
> mail, the daemon shouldn't be enabled by default.

I don't know about you, but I find it quite reassuring to be able to
confirm that the first half of an install is going pretty well when I
get to see the "useless" dummy page from Apache.  I'd imagine someone
installing their first web server would also find that reassuring (I
still remember grinning broadly when first seeing it).  If it were also
their first Debian server, then forcing them to find an extra ON switch
after installing apache just seems like an extra and unneeded barrier.

I think that anyone that needs to bring up a mail server on an IP
address that is being battered by important mail is going to need to be
aware of _many_ of the assumptions behind the software they use,
including this one.

The "should it run on install?" question is a matter of taste and
judgement, which is why it is not the case with rsyncd.

The current state of rsyncd is probably my fault (as initial packager of
rsync). One _could_ have an rsyncd package, containing just a commented
out example /etc/rsyncd.conf and the init.d script, but I don't really
see the point.  If ...ENABLE=false settings are banned in defaults files
(as I've come to think they should be) then in the case of rsyncd, one
could make the running of the daemon conditional on the existence of the
$RSYNC_CONFIG_FILE file (which is not shipped in the package).

The RedHat assumptions on this issue make me as unhappy as the Debian
ones appear to make you unhappy.  I suggest that this is just a matter
of taste.

If you'd prefer a coffee, it does little good to complain about the
taste of the drinks on offer from our tea appreciation society.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

pgp2WR8uX4M9L.pgp
Description: PGP signature

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

2013-05-12 Thread Игорь Пашев

2013/5/12 Stéphane Glondu :

> What about /etc ? /var ? both contain data that can mess up with a
> running system...

All go into a snapshot.

That's why I stand for moving /var/lib/mysql and similar things out of /var


--
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/CALL-Q8yaNGi2Nv5g+7OX-GRHakMh68eUePrD+MvJc6=kfhz...@mail.gmail.com

Re: /bin/sh (was Re: jessie release goals)

2013-05-12 Thread Helmut Grohne

On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> This is utter bullshit and you should already know it. Systemd is much
> more reliable as a whole than any other implementation. I have yet to
> see a use case where it is not better.

With all due respect, this might be utter bullshit, but is at least
[citation needed]. I have yet to see a failing pid 1 (be that sysv,
upstart or systemd). Acquiring data on failure modes of any of those
systems appears like a difficult task and d-devel might not be the best
place to discuss that.

> But regardless, we don???t need more than one init system. We just need a
> good one. This is completely unrelated to GNOME. The bunch of idiots who
> try to pin it down on GNOME, Fedora or the Illuminati look like just
> another group of conspiracy theories lunatics.

The problem is not that people disagree on that a good init system is
needed, but about what good comprises. Some people believe that a good
init system should run on all supported architectures including
kfreebsd-*. By this particular metric sysv init still outperforms
systemd. In fact for every combination of init systems you will find a
metric where one outperforms the other.

And this is where choice makes sense IF the benefits outweigh its costs.
Unfortunately that if is a very tough question.

Let me therefore direct a question to those in favour of a switchable
/bin/sh:

What are the benefits of using shells other than dash for /bin/sh? (as
opposed to other viable mechanisms to select a shell such as the shebang
of your scripts)

Answers I've seen so far:
 * Backwards compatibility with systems that still use bashisms.
 * Users who want to choose /bin/sh to satisfy some belief in
   superiority.

Summaries or references to previous discussion appreciated.

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/20130512174058.ga29...@alf.mars

Re: parsable copyright format 1.0 (jessie release goals)

2013-05-12 Thread Steve McIntyre

Sune wrote:
>
>I fought quite hard against the copyright file format but was promised
>that it wouldn't be something required.
>I do think it is sad that people are already changing minds now.

Agreed. It's a nice-to-have for the the people that care, but that's
all.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim."  [ seen in ucam.chat ]


-- 
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/e1ubao0-kw...@mail.einval.com

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

On Thu, May 9, 2013 at 3:49 PM, Lars Wirzenius wrote:
> The wheezy freeze has been much too long. At ten months, it's four
> months longer than what we've gotten used to in several previous
> releases. Had we managed to keep the freeze at six months, it would
> still have been too long. I believe there is something wrong in how
> we develop Debian, and how we do releases, and that by fixing them,
> we can have much shorter releases, with an increase in their quality.

I disagree that there is something fundamentally wrong with how
development is done.  The primary problems with this cycle were that
there were something like 400 or 500 extra rc bugs due to a concerted
effort to report all serious issues found via piuparts, and then the
existential problem of not enough rc squashers, which in and of itself
is not all that rewarding.  You address the former with the more
automated testing comment below.  The latter could possibly be
addressed by bring in more DDs, and that means doing better with
-mentors.

Anyway, those are the two problems that I believe need focus.

> We should aim for a short freeze, perhaps as short as two weeks,
> and certainly not longer than two months. This would remove the
> frustration, and fix the other problems related to a long freeze.
> However, to achieve a short freeze, we need to change how develop
> Debian.

A certain freeze length is inevitable simply because it takes a
certain time minimum for people to test and find all of the
significant compatibility issues with the set of software chosen to be
a part of the release.  Debian's high quality standard cannot be met
with a two-week testing period.  Somewhere between 3 and 6 months is
much more reasonable.

> The fundamental change is to start keeping our "testing" branch
> as close to releasable as possible, at all times. For individual
> projects, this corresponds to keeping the master or trunk branch
> in version control ready to be released. Practitioners of agile
> development models, for example, do this quite successfully, by
> applying continuous integration, automatic testing, and by having
> a development culture that if there's a severe bug in master,
> fixing that gets highest priority.

There are simply too many rc bugs all the time.  Jessie is already
over 500 after one week of development:
http://bugs.debian.org/release-critical

That, I think is the real problem.  How did testing go from a minimal
(70-ish) rc bug wheezy release to over 500 in one week?  Why didn't
britney prevent the migration of all those rc-buggy packages?

> Imagine a continuous integration system for Debian: for every new
> package upload to unstable, it builds and tests all the reference
> installations.  If all builds succeed, and all tests pass, the package
> can be moved into testing at once. When you, a developer, upload a
> new package, you get notified about test results, and testing migration,
> within minutes.

I am in total agreement.  This would be wonderful.

Best wishes,
Mike


-- 
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/CANTw=MMbJe=Hp4NP0a374X7PeLTQf=eqtruujeph-asyzwc...@mail.gmail.com

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

2013-05-12 Thread Russ Allbery

Michael Gilbert  writes:

> I disagree that there is something fundamentally wrong with how
> development is done.  The primary problems with this cycle were that
> there were something like 400 or 500 extra rc bugs due to a concerted
> effort to report all serious issues found via piuparts, and then the
> existential problem of not enough rc squashers, which in and of itself
> is not all that rewarding.

This is what we say every release, for various values of "piuparts"
(archive-wide rebuilds, license audits, etc.).  And then every release we
have the same problem.  Let's be sure that we're not just trying the same
thing over and over again and expecting different results.

> A certain freeze length is inevitable simply because it takes a certain
> time minimum for people to test and find all of the significant
> compatibility issues with the set of software chosen to be a part of the
> release.  Debian's high quality standard cannot be met with a two-week
> testing period.  Somewhere between 3 and 6 months is much more
> reasonable.

Six months would be an improvement, but I think it's still much too long,
long enough to have negative distortive effects.  I think three months is
a better target to aim for.  (That said, if we could reliably get the
release freeze down to six months, that would certainly be a worthwhile
improvement.)

> There are simply too many rc bugs all the time.  Jessie is already over
> 500 after one week of development:
> http://bugs.debian.org/release-critical

Right.  Which is why we should immediately (for definitions of immediately
that involve the release team taking a much-deserved break, but not for
definitions of immediately that mean "six months from now") freeze testing
again until we're back down under 50-100 RC bugs, whether via fixes and
transitions or whether by kicking out a bunch of packages.  Now is also
the ideal time to kick packages out of testing so that people are aware
that they're in trouble very early in the release cycle.

We always have this surge immediately after the release, but we don't
stomp on it immediately.  We therefore get up to 1000 RC bugs before we
know it, and never get back on top of them without a long and horribly
painful freeze.

> That, I think is the real problem.  How did testing go from a minimal
> (70-ish) rc bug wheezy release to over 500 in one week?  Why didn't
> britney prevent the migration of all those rc-buggy packages?

Because they're not from migrations.  They're from transitions.  They're
all the "this is going to break with a new version of libc6" and the like
bugs that were filed before the release at priority important and were
mass-upgraded after the release.

This is fine and normal, but it means that we should not now be diving
into all new upstream, all the time development immediately.  We should
stop, take a breath, work through these transitions first, get that RC bug
count down to something releasonable again, and then tackle the next thing
that surges RC bug counts.

That's going to require some discipline.  We know from long experience
with the release process that we can use the bully pulpit until we're blue
in the face, but this is a huge project with a lot of developers, many of
whom just don't read mailing lists.  People will keep uploading unless we
put something in place that actually prevents them from doing so, such as
freezing testing migration right now except for pre-arranged transitions
and RC bug fixes.

(It's quite possible that, to implement this properly without drowning the
release team in work, we'll need better tools to manage that sort of
freeze and migration process.)

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

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

2013-05-12 Thread Marco d'Itri

On May 12, Stéphane Glondu  wrote:

> What about /etc ? /var ? both contain data that can mess up with a
> running system...
The goal (or at least, a possible one) is to be able to update the 
operating system (or to snapshot it) while keeping your data and 
configurations.
The most obvious of /var which is related to the OS is /var/lib/dpkg/, 
I expect that with some experience we will find out the best way to 
handle it when doing snapshots or system image upgrades.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: /bin/sh (was Re: jessie release goals)

2013-05-12 Thread John Paul Adrian Glaubitz


On 05/12/2013 07:40 PM, Helmut Grohne wrote:

With all due respect, this might be utter bullshit, but is at least
[citation needed]. I have yet to see a failing pid 1 (be that sysv,
upstart or systemd). Acquiring data on failure modes of any of those
systems appears like a difficult task and d-devel might not be the best
place to discuss that.


It's not PID 1 itself that is failing, but the daemons and scripts run 
by the init daemon. The init daemon therefore needs to be more 
intelligent and provide mechanisms to deal with crashed daemons.


Yes, System V Init has been working for the last three decades. However, 
we weren't running the very same kernel and plumber land on everything 
from a smart phone up to a large compute cluster.


systemd provides many useful features that help making systems on any 
scale more reliable and easier to maintain.


Of course, you don't care if daemon XYZ crashes on your desktop and 
you're notified immediately, you just reboot in the worst case. However, 
you *do* care if that happens to the NFS daemon on your home directory 
server or your httpd on your web server.


You also want to make sure that a single user won't be able to bring 
down a large login server (systemd's support for cgroups can do that) 
and you also want remote filesystems always to be mounted reliably when 
you reboot your system and not being a game of Russian roulette. I have 
observed both things happen several times on the network of my old 
university.


I also think it's important to have a proper system of resolving 
dependencies between daemons in a clean and well-defined, intrinsic way 
and not through hacky bash scripts where scripts like insserv already 
fail when my last FAI update created a .prefai_copy file of a script in 
/etc/init.d.


Socket-based activation is, in my humble opinion, the only proper way to 
have a proper means of determining dependencies and starting dependency 
chains of daemons in a reliable, reproducible and atomic way, e.g. 
either the whole chain runs or not. I don't think you can implement it 
with the same reliability and elegance using System V Init scripts.


Both Solaris, MacOS X and iOS have dropped the classical System V Init 
in favor of socket-based activation long time ago and I haven't heard 
anyone complaining that users got deprived of their choices. The design 
has proven itself and powers over 100 million iDevices.



The problem is not that people disagree on that a good init system is
needed, but about what good comprises. Some people believe that a good
init system should run on all supported architectures including
kfreebsd-*.


Ok, so could you please go ahead and make sure I can use things like 
launchd, ZFS and jails without any limitations on Linux?


Honestly, you simply can't expect every single package in Debian to run 
on any of the supported kernels. If systemd profits from the use of 
Linux-specific kernel features, which is a good thing in my humble 
opinion because Linux has many very advanced and useful features, it 
should use them.


I don't understand why these people who are so worried about systemd 
making the kfreebsd-* ports look bad don't go ahead and port launchd to 
it. launchd exists and is mature, is largely on feature par with systemd 
and has been released under a free license. systemd for the Linux ports, 
launchd for the kfreebsd-* kernels.



By this particular metric sysv init still outperforms
systemd. In fact for every combination of init systems you will find a
metric where one outperforms the other.


No, sysvinit has always been slower for me than systemd. The first thing 
I do after installing a new Debian box is replacing sysvinit with 
systemd. It's like using Internet Explorer to download Firefox on Windows.



Let me therefore direct a question to those in favour of a switchable
/bin/sh:

What are the benefits of using shells other than dash for /bin/sh? (as
opposed to other viable mechanisms to select a shell such as the shebang
of your scripts)


The difference between a shell and an init system is that the former is 
directly exposed to the user while the latter will only be visible to 
developers and admins most of the time. It makes sense to be able to 
customize your user interface, but I don't think it makes sense to be 
able to customize a core component like the init daemon.


I already think that it's a bit crazy (and geeky) that we have the 
capability in Debian to choose between different kernels, so I guess 
it's natural that we have discussions about being able to make choices 
for init as well :).


Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

[Testing] Mounting /usr in the initramfs

2013-05-12 Thread Roger Leigh

Hi folks,

Following on from previous discussion about this, I've been working on
the needed changes to initramfs-tools, initscripts and util-linux, and
it's now at the point where it's ready for wider testing and review.

** Note: do NOT test on a production system. **

While I've tested good number of scenarios, I can't guarantee it works
under all circumstances, so it does need testing on a wider range of
systems. I have tested local ext4 filesystems and NFS, but other
filesystem types would be very useful to test, as would LVM/MD etc.
Testing whether you can mount an encrypted /etc is also needed--this
was added so that you don't need to encrypt the whole rootfs. Testing
that it also works with alternative boot scripts like "live" is also
important.

All the needed packages are available from here:
http://people.debian.org/~rleigh/usrmount/

Feedback:
Any feedback is best directed to #652459

And any patches for initramfs-tools can be based on
git://anonscm.debian.org/users/rleigh/initramfs-tools.git (branch usrmount)

http://anonscm.debian.org/gitweb/?p=users/rleigh/initramfs-tools.git;a=shortlog;h=refs/heads/usrmount

Setting up:
Install at a minimum: initscripts, util-linux, initramfs-tools

The initramfs can fsck and mount /, /usr and /etc. / and /etc
are configured using the kernel command-line. The details for
/usr are obtained from /etc/fstab on the rootfs.

You shouldn't need to make any configuration changes at this
point; it is intended that it should work with any existing
setup.

After you've tested it to make sure it works, you could try
copying /etc to a separate volume and mounting it with
"etc=UUID=..." or "nfsetc=host:path etc=/dev/nfs" for NFS if
that's of interest.

Testing:
Reboot. You should see the rootfs (and /usr, if in fstab)
fscked and mounted prior to init starting. You can add the
"fastboot" (skip) "forcefsck" and "fsckfix" options to the
command-line to change the fsck behaviour.

Add break=bottom to the kernel command-line, and look in /sbin;
you should have fsck and the needed mount helpers for your
filesystem.

After boot, have a look at the mount order with mount:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,relatime,size=10240k,nr_inodes=126766,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102668k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sdb1 on /usr type ext4 (rw,relatime,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=385540k)

Notice that both / and /usr precede the /run/lock and /run/shm
filesystems mounted in early boot, verifying that they were indeed
both mounted in the initramfs. If /usr was mounted normally, it
would have appeared last. [We now also canonicalise the UUID=
and LABEL= options so it doesn't mess up the mount/df output and
is also compatible with the system mount(8).]

Things which might break:
Modules needed to mount non-rootfs filesystems aren't currently
handled specially. It may be the case that for esoteric setups
we don't have the module installed in the initramfs.

We copy the filesystem-specific fsck helper from /sbin. If
additional files are needed by particular helpers, they might
need special-casing.

Any comments would be gratefully received.

Regards,
Roger

--
.''`. 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/20130512183443.gg21...@codelibre.net

Bug#708045: ITP: metis -- Serial Graph Partitioning and Fill-reducing Matrix Ordering

2013-05-12 Thread Anton Gladky

Package: wnpp
Severity: wishlist
Owner: Anton Gladky 

* Package name: metis
  Version : 5.1.0
* URL : http://glaros.dtc.umn.edu/gkhome/metis/metis/overview
* License : Apache License, Version 2.0
  Description : Serial Graph Partitioning and Fill-reducing Matrix Ordering

METIS is a set of serial programs for partitioning graphs, partitioning finite 
element meshes, and producing fill reducing orderings for sparse matrices. 
The algorithms implemented in METIS are based on the multilevel 
recursive-bisection, multilevel k-way, and multi-constraint partitioning schemes

The new version of METIS is DFSG-compatible, that is why it is possible to
have this package in Debian. Metis will be maintained by Debian Science Team.


-- 
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/20130512184353.25203.945.report...@debian.home.debian

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

On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I disagree that there is something fundamentally wrong with how
>> development is done.  The primary problems with this cycle were that
>> there were something like 400 or 500 extra rc bugs due to a concerted
>> effort to report all serious issues found via piuparts, and then the
>> existential problem of not enough rc squashers, which in and of itself
>> is not all that rewarding.
>
> This is what we say every release, for various values of "piuparts"
> (archive-wide rebuilds, license audits, etc.).  And then every release we
> have the same problem.  Let's be sure that we're not just trying the same
> thing over and over again and expecting different results.

I am not saying that is going away with jessie.  In fact, I am totally
expecting another 400-500 serious or more piuparts bugs.  The reason
that I mention that as the biggest issue is that for one the concerted
effort to report all of those bugs is new, and could possibly be
identified as the catalyst for the +4 months compared to squeeze.

That is why I think the automated testing infrastructure needs to be
implement (as soon as possible) this cycle, in order to keep all
piuparts-broken packages from ever migrating to testing, resulting in
a later large amount of the rc count.

>> There are simply too many rc bugs all the time.  Jessie is already over
>> 500 after one week of development:
>> http://bugs.debian.org/release-critical
>
> Right.  Which is why we should immediately (for definitions of immediately
> that involve the release team taking a much-deserved break, but not for
> definitions of immediately that mean "six months from now") freeze testing
> again until we're back down under 50-100 RC bugs, whether via fixes and
> transitions or whether by kicking out a bunch of packages.

People just spent 10 months fixing issues in packages that were not
their own.  I don't think they want to be pulled away from the fun
stuff so quickly.

> Now is also
> the ideal time to kick packages out of testing so that people are aware
> that they're in trouble very early in the release cycle.

That would be good.

>> That, I think is the real problem.  How did testing go from a minimal
>> (70-ish) rc bug wheezy release to over 500 in one week?  Why didn't
>> britney prevent the migration of all those rc-buggy packages?
>
> Because they're not from migrations.  They're from transitions.  They're
> all the "this is going to break with a new version of libc6" and the like
> bugs that were filed before the release at priority important and were
> mass-upgraded after the release.

But those shouldn't affect testing yet, right?  All of that stuff
needs staging in unstable first.  Are bug filers not tagging their
reports correctly?  If so, that's quite misleading, and actually
should be quite easy although tedious to fix.

Best wishes,
Mike

-- 
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/CANTw=MMMXsirPPYLbhSe3Nwf5wEkb=5cdt5As=j3dmfy+bc...@mail.gmail.com

Re: Debianizing the Java world?

2013-05-12 Thread Bernd Zeimetz

On 05/11/2013 10:12 AM, Daniel Pocock wrote:
> On 11/05/13 04:35, Paul Wise wrote:
>> I think you want to discuss this on the debian-java list instead.
>>
> 
> The reason I posted here is that the concept is just as viable for other
> languages with their own distribution systems (e.g. R and Drupal both
> have their own package distribution mechanisms) and also because the
> Java issues go beyond those of us who develop in Java - e.g. people now
> use Eclipse for C++ and Python development.

Indeed, but then eclipses uses autofoo and distutils and not maven :)


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/518fe96a.5010...@bzed.de

Bug#708053: ITP: liburi-fromhash-perl -- module to build a URI from a set of named parameters

2013-05-12 Thread Oleg Gashev

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: liburi-fromhash-perl
  Version : 0.03
  Upstream Author : Dave Rolsky, 
* URL : https://metacpan.org/release/URI-FromHash/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to build a URI from a set of named parameters

 URI::FromHash provides a simple one-subroutine "named parameters" style
 interface for creating URIs. Underneath the hood it uses URI.pm, though
 because of the simplified interface it may not support all possible options
 for all types of URIs.
 .
 It was created for the common case where you simply want to have a simple
 interface for creating syntactically correct URIs from known components (like
 a path and query string). Doing this using the native URI.pm interface is
 rather tedious, requiring a number of method calls, which is particularly
 ugly when done inside a templating system such as Mason or TT2.


-- 
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/20130511142927.20252.50547.reportbug@debian.debian

Re: /bin/sh (was Re: jessie release goals)

2013-05-12 Thread Игорь Пашев

2013/5/12 John Paul Adrian Glaubitz :
> Honestly, you simply can't expect every single package in Debian to run on
> any of the supported kernels. If systemd profits from the use of
> Linux-specific kernel features, which is a good thing in my humble opinion
> because Linux has many very advanced and useful features, it should use
> them.


> I already think that it's a bit crazy (and geeky) that we have the capability 
> in Debian to choose between different kernels, so I guess it's natural that 
> we have discussions about being able to make choices for init as well :).

Yeah, that's quite easy ;-)
http://cgit.osdyson.org/rsyslog.git/tree/debian/rules#n55


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

Bug#708057: ITP: libmoosex-types-uri-perl -- URI related types and coercions for Moose

2013-05-12 Thread Oleg Gashev

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libmoosex-types-uri-perl
  Version : 0.03
  Upstream Author : Yuval Kogman 
* URL : https://metacpan.org/release/MooseX-Types-URI/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : URI related types and coercions for Moose

 This package provides Moose types for fun with URIs.
 .
 It has slightly DWIMier types than the URI classes have due to implementation
 details, so the types should be more forgiving when ducktyping will work
 anyway (e.g. URI::WithBase does not inherit URI).


-- 
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/20130511145914.20310.23116.reportbug@debian.debian

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

2013-05-12 Thread Russ Allbery

Michael Gilbert  writes:
> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:

>> Right.  Which is why we should immediately (for definitions of
>> immediately that involve the release team taking a much-deserved break,
>> but not for definitions of immediately that mean "six months from now")
>> freeze testing again until we're back down under 50-100 RC bugs,
>> whether via fixes and transitions or whether by kicking out a bunch of
>> packages.

> People just spent 10 months fixing issues in packages that were not
> their own.  I don't think they want to be pulled away from the fun
> stuff so quickly.

And that's why releases are so painful, at least IMO.

We have to break this cycle at some point or it will just get worse.  To
break the cycle, we're going to have to keep doing bug fixing after we're
exhausted of doing bug fixing so that we don't build up a huge backlog.

The good part is that if we actually can break that cycle, the freeze
will be much less painful and we won't be as sick of fixing bugs the next
time around.

Think of this in software development terms.  We're currently following a
development model where, immediately following a release, there's a nearly
complete free-for-all without much enforcement of bugs or regressions.  We
do that for a year, and then we try to stabilize the results.  Most free
software projects that used to follow this model (and there have been
quite a number of them) have had similar struggles with the extended
stabilization process this requires.  That's part of the shift towards
test-driven development, continuous integration, and constantly-usable
master branches.

>> Because they're not from migrations.  They're from transitions.
>> They're all the "this is going to break with a new version of libc6"
>> and the like bugs that were filed before the release at priority
>> important and were mass-upgraded after the release.

> But those shouldn't affect testing yet, right?  All of that stuff
> needs staging in unstable first.  Are bug filers not tagging their
> reports correctly?  If so, that's quite misleading, and actually
> should be quite easy although tedious to fix.

The bug affects the version of the package in testing.  I see what you're
saying, but I don't think this is something the BTS can represent.  And
those bugs *are* all release-critical: they have to be fixed before we can
release jessie, at least unless we're going to abort the transition, which
seems unlikely.

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

Re: Debianizing the Java world?

2013-05-12 Thread Florian Weimer

* Daniel Pocock:

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

I don't see how that's improving things by much.

The tough issue is porting all the things in your (personal part of
the) world to use a single version of each component (probably the
most recent version).  That also plagues the other language-specific
packaging frameworks.


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

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

On Sun, May 12, 2013 at 4:00 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
>
>>> Right.  Which is why we should immediately (for definitions of
>>> immediately that involve the release team taking a much-deserved break,
>>> but not for definitions of immediately that mean "six months from now")
>>> freeze testing again until we're back down under 50-100 RC bugs,
>>> whether via fixes and transitions or whether by kicking out a bunch of
>>> packages.
>
>> People just spent 10 months fixing issues in packages that were not
>> their own.  I don't think they want to be pulled away from the fun
>> stuff so quickly.
>
> And that's why releases are so painful, at least IMO.
>
> We have to break this cycle at some point or it will just get worse.  To
> break the cycle, we're going to have to keep doing bug fixing after we're
> exhausted of doing bug fixing so that we don't build up a huge backlog.
>
> The good part is that if we actually can break that cycle, the freeze
> will be much less painful and we won't be as sick of fixing bugs the next
> time around.

Or the project could end up in a perpetual freeze.  Every time the
floodgates are opened, another 1,000 bugs could get reported due to
all of the new transitions, and another freeze will need to happen to
get those down.

> Think of this in software development terms.  We're currently following a
> development model where, immediately following a release, there's a nearly
> complete free-for-all without much enforcement of bugs or regressions.  We
> do that for a year, and then we try to stabilize the results.  Most free
> software projects that used to follow this model (and there have been
> quite a number of them) have had similar struggles with the extended
> stabilization process this requires.  That's part of the shift towards
> test-driven development, continuous integration, and constantly-usable
> master branches.

Those other distributions have also given up on producing high-quality
releases.  Only Debian and RHEL remain in that category.

>>> Because they're not from migrations.  They're from transitions.
>>> They're all the "this is going to break with a new version of libc6"
>>> and the like bugs that were filed before the release at priority
>>> important and were mass-upgraded after the release.
>
>> But those shouldn't affect testing yet, right?  All of that stuff
>> needs staging in unstable first.  Are bug filers not tagging their
>> reports correctly?  If so, that's quite misleading, and actually
>> should be quite easy although tedious to fix.
>
> The bug affects the version of the package in testing.  I see what you're
> saying, but I don't think this is something the BTS can represent.  And
> those bugs *are* all release-critical: they have to be fixed before we can
> release jessie, at least unless we're going to abort the transition, which
> seems unlikely.

There is the "sid" tag, which indicates that the issue only affects
unstable.  Although I think a "triggered-by" function is needed in the
bts.  For example, bugs with "triggered-by gcc 4.8-0" would not be
marked as affected in suites that have gcc versions prior to 4.8-0
(i.e. jessie would not yet be affected by the gcc transition).

Best wishes,
Mike


-- 
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/CANTw=mo7tswbxi5jwhzy8woyy4v-4_0mhm1q91nnotxxq+y...@mail.gmail.com

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

2013-05-12 Thread Russ Allbery

Michael Gilbert  writes:

> Or the project could end up in a perpetual freeze.  Every time the
> floodgates are opened, another 1,000 bugs could get reported due to all
> of the new transitions, and another freeze will need to happen to get
> those down.

I would like to see us try it and see if that happens.  If that does
happen, I think that's a fascinating data point, and one that would be
well worth the few months of difficult process in order to confirm.
Knowing for certain whether or not that would be the outcome would be
wonderfully clarifying and helpful in narrowing the possible solution
space.

> On Sun, May 12, 2013 at 4:00 PM, Russ Allbery wrote:

>> Think of this in software development terms.  We're currently following
>> a development model where, immediately following a release, there's a
>> nearly complete free-for-all without much enforcement of bugs or
>> regressions.  We do that for a year, and then we try to stabilize the
>> results.  Most free software projects that used to follow this model
>> (and there have been quite a number of them) have had similar struggles
>> with the extended stabilization process this requires.  That's part of
>> the shift towards test-driven development, continuous integration, and
>> constantly-usable master branches.

> Those other distributions have also given up on producing high-quality
> releases.  Only Debian and RHEL remain in that category.

I don't believe that's true; in fact, it's the exact opposite of the
outcomes I've observed in practice.  Most projects that use test-driven
development, continuous integration, and constantly-usable master branches
maintain a significantly higher level of quality than the projects that
use development methodologies like Debian's (at the cost of forcing
disruptive changes to be done more slowly and with more planning, or to be
postponed if people aren't available to do them properly).

>> The bug affects the version of the package in testing.  I see what
>> you're saying, but I don't think this is something the BTS can
>> represent.  And those bugs *are* all release-critical: they have to be
>> fixed before we can release jessie, at least unless we're going to
>> abort the transition, which seems unlikely.

> There is the "sid" tag, which indicates that the issue only affects
> unstable.  Although I think a "triggered-by" function is needed in the
> bts.  For example, bugs with "triggered-by gcc 4.8-0" would not be
> marked as affected in suites that have gcc versions prior to 4.8-0
> (i.e. jessie would not yet be affected by the gcc transition).

If there are no RC bugs affecting the version of a package in testing,
that should mean that nothing has to be done to that package in order to
release.  If the package has to be fixed due to a transition that will be
in the next release, that is an RC bug affecting the version in testing
and should be counted accordingly.  The package cannot be left unchanged
and still go into the release, which is the definition of RC.

In other words, I see no point in doing what you describe.  So far as I
can tell, all it does is artificially lower the RC bug count in the graph,
while in no way reducing the amount of work that has to happen before
jessie is releasable.  In other words, it just hides a bunch of RC bugs
from the statistics without actually changing their RC status.  That seems
like an even worse state: we have just as much work to do but now we're
hiding that work from ourselves.

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

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