Re: PPAs for Debian

2011-05-03 Thread Stefano Zacchiroli
On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote:
> That depends on what you mean by 'issue'.  I think exactly the issues that 
> concern some people in Debian about packages of 'poor quality' being 
> generated 
> in an uncontrolled PPA system are happening with regularity in Ubuntu.  
> Although it doesn't happen every week or anything, it's happened more often 
> than I can recall that someone files a bug in Ubuntu about broken PPA 
> packages 
> done by some random non-developer.  I believe Debian is quite correct to be 
> concerned about the potential for user confusion and damage to Debian's 
> reputation for high quality work.
> 
> PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I 
> think are quite another.

AOL. I think that for Project needs, PPAs accessible only to DDs + DMs
would be a good compromise to avoid "random uploads". It also seems sane
in order to avoid the risk of DOS-ing buildds. It's not too constraining
either as, after all, we won't (and simply can't) block users out there
to set up their own package repositories by means other than PPA.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature


Re: PPAs for Debian

2011-05-03 Thread Mike Hommey
On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote:
> On Wednesday, May 04, 2011 12:16:54 AM Paul Tagliamonte wrote:
> > On Wed, May 4, 2011 at 12:02 AM, Julien Valroff  wrote:
> > > Le mercredi 04 mai 2011 à 00:02:01 (+0200 CEST), René Mayorga a écrit :
> > >> On Tue, May 03, 2011 at 11:30:41PM +0200, Stefano Zacchiroli wrote:
> > >> > After all, in that  respect what is the difference between that and
> > >> > unofficial APT repositories that many of us already maintain at
> > >> > people.d.o/~something or something.debian.net? Do you want to shut
> > >> > them down as well?
> > >> 
> > >> no, I was expressing over the PPA as an official services that allow
> > >> users to upload any package without any quality control.
> > > 
> > > AFAIU, only DD and DM could create PPA and upload to them. If this is not
> > > the case, then I share your fears.
> > 
> > Usage of the PPA system on LP requires that you agree to the usage
> > terms (not unlike machine usage policies for Debian).
> > 
> > We let non-MOTU upload to their own PPAs (has their name in the URL),
> > and if nonfree (or malicious) packages are uploaded, they can have PPA
> > rights removed.
> > 
> > There's been one issue I can recall, and it was only a very very
> > slight DFSG technicality.
> 
> That depends on what you mean by 'issue'.  I think exactly the issues that 
> concern some people in Debian about packages of 'poor quality' being 
> generated 
> in an uncontrolled PPA system are happening with regularity in Ubuntu.  
> Although it doesn't happen every week or anything, it's happened more often 
> than I can recall that someone files a bug in Ubuntu about broken PPA 
> packages 
> done by some random non-developer.  I believe Debian is quite correct to be 
> concerned about the potential for user confusion and damage to Debian's 
> reputation for high quality work.
> 
> PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I 
> think are quite another.  I'd hate to see Debian make the same mistake that 
> Canonical did in this regard.

Add to that that allowing random people to upload packages to be built
on Debian build daemons is a recipe to have the buildds compromised.

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/20110504055747.gb3...@glandium.org



Carol Brown has invited you to open a Google mail account

2011-05-03 Thread Carol Brown
I've been using Gmail and thought you might like to try it out. Here's an
invitation to create an account.


  You're Invited to Gmail!

Carol Brown has invited you to open a Gmail account.

Gmail is Google's free email service, built on the idea that email can be
intuitive, efficient, and fun. Gmail has:

 *Less spam*
Keep unwanted messages out of your inbox with Google's innovative
technology.

*Lots of space*
Enough storage so that you'll never have to delete another message.

*Built-in chat*
Text or video chat with Carol Brown and other friends in real time.

*Mobile access*
Get your email anywhere with Gmail on your mobile phone.

You can even import your contacts and email from Yahoo!, Hotmail, AOL, or
any other web mail or POP accounts.

Once you create your account, Carol Brown will be notified of your new Gmail
address so you can stay in touch. Learn
moreor get
started
!
Sign 
up

Google Inc. | 1600 Ampitheatre Parkway | Mountain View, California 94043


Re: glibc: causes segfault in Xorg

2011-05-03 Thread Steve M. Robbins
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:

> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
> which is fixed (sort of) by commit 0354e355 (2011-04-01).

Oh my word.  So glibc 2.13 breaks random binaries that happened to
incorrectly use memcpy() instead of memmove()?  What's wrong with the
glibc developers (and Ulrich Drepper in particular)?

I'm with Linus on this: let's just revert to the old behaviour.  A
tiny amount of clock cycles saved isn't worth the instability.

Thanks,
-Steve

P.S.  I tried rebuilding glibc myself locally, but gcc also segfaults
in the process :-(



signature.asc
Description: Digital signature


Re: PPAs for Debian

2011-05-03 Thread Scott Kitterman
On Wednesday, May 04, 2011 12:16:54 AM Paul Tagliamonte wrote:
> On Wed, May 4, 2011 at 12:02 AM, Julien Valroff  wrote:
> > Le mercredi 04 mai 2011 à 00:02:01 (+0200 CEST), René Mayorga a écrit :
> >> On Tue, May 03, 2011 at 11:30:41PM +0200, Stefano Zacchiroli wrote:
> >> > After all, in that  respect what is the difference between that and
> >> > unofficial APT repositories that many of us already maintain at
> >> > people.d.o/~something or something.debian.net? Do you want to shut
> >> > them down as well?
> >> 
> >> no, I was expressing over the PPA as an official services that allow
> >> users to upload any package without any quality control.
> > 
> > AFAIU, only DD and DM could create PPA and upload to them. If this is not
> > the case, then I share your fears.
> 
> Usage of the PPA system on LP requires that you agree to the usage
> terms (not unlike machine usage policies for Debian).
> 
> We let non-MOTU upload to their own PPAs (has their name in the URL),
> and if nonfree (or malicious) packages are uploaded, they can have PPA
> rights removed.
> 
> There's been one issue I can recall, and it was only a very very
> slight DFSG technicality.

That depends on what you mean by 'issue'.  I think exactly the issues that 
concern some people in Debian about packages of 'poor quality' being generated 
in an uncontrolled PPA system are happening with regularity in Ubuntu.  
Although it doesn't happen every week or anything, it's happened more often 
than I can recall that someone files a bug in Ubuntu about broken PPA packages 
done by some random non-developer.  I believe Debian is quite correct to be 
concerned about the potential for user confusion and damage to Debian's 
reputation for high quality work.

PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I 
think are quite another.  I'd hate to see Debian make the same mistake that 
Canonical did in this regard.

Scott K


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


Re: PPAs for Debian

2011-05-03 Thread Paul Tagliamonte
On Wed, May 4, 2011 at 12:02 AM, Julien Valroff  wrote:
> Le mercredi 04 mai 2011 à 00:02:01 (+0200 CEST), René Mayorga a écrit :
>> On Tue, May 03, 2011 at 11:30:41PM +0200, Stefano Zacchiroli wrote:
>> > After all, in that  respect what is the difference between that and 
>> > unofficial APT
>> > repositories that many of us already maintain at people.d.o/~something
>> > or something.debian.net? Do you want to shut them down as well?
>>
>> no, I was expressing over the PPA as an official services that allow users to
>> upload any package without any quality control.
>
> AFAIU, only DD and DM could create PPA and upload to them. If this is not
> the case, then I share your fears.

Usage of the PPA system on LP requires that you agree to the usage
terms (not unlike machine usage policies for Debian).

We let non-MOTU upload to their own PPAs (has their name in the URL),
and if nonfree (or malicious) packages are uploaded, they can have PPA
rights removed.

There's been one issue I can recall, and it was only a very very
slight DFSG technicality.

>
> Cheers,
> Julien
>
> --
>  .''`.   Julien Valroff ~  ~ 
>  : :'  :  Debian Developer & Free software contributor
>  `. `'`   http://www.kirya.net/
>   `-     4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1
>

Cheers,
Paul

-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq


--
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/BANLkTikZoQCZsO2G3=--rbzgdtpauc3...@mail.gmail.com



Re: PPAs for Debian

2011-05-03 Thread Julien Valroff
Le mercredi 04 mai 2011 à 00:02:01 (+0200 CEST), René Mayorga a écrit :
> On Tue, May 03, 2011 at 11:30:41PM +0200, Stefano Zacchiroli wrote:
> > After all, in that  respect what is the difference between that and 
> > unofficial APT
> > repositories that many of us already maintain at people.d.o/~something
> > or something.debian.net? Do you want to shut them down as well?
> 
> no, I was expressing over the PPA as an official services that allow users to
> upload any package without any quality control.

AFAIU, only DD and DM could create PPA and upload to them. If this is not
the case, then I share your fears.

Cheers,
Julien

-- 
  .''`.   Julien Valroff ~  ~ 
 : :'  :  Debian Developer & Free software contributor
 `. `'`   http://www.kirya.net/
   `- 4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1


signature.asc
Description: Digital signature


Re: Procedure for re-activating my DD status?

2011-05-03 Thread Cyril Brulebois
Hi,

Mark Johnson  (03/05/2011):
> However, I wasn't able to find any info on how to rejoin the
> organization in the standard documents. Do I simply go through the
> New Maintainer application process as I did initially?

might be that it's a bit uncommon, and maybe under-documented; anyway,
I had that in mind:
  http://lists.debian.org/debian-devel-announce/2007/02/msg8.html

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Matthias Klose

On 05/04/2011 12:24 AM, Cyril Brulebois wrote:

Hi,

(not a gcc maintainer)

Charles Plessy  (04/05/2011):

I just got a bug from you explaining some changes (= more FTBFS)
about 4.6.1.  Will there be similar 4.6.x changes in the future ?


my reading of it is that to prevent too many FTBFSes while introducing
4.6 in Debian, some changes were delayed (“reverted through Debian
patches”) until 4.6.1 is released and uploaded.

Assuming you're talking about -Wunused-*, those are mentioned on the
upstream upgrading / porting page:
   http://gcc.gnu.org/gcc-4.6/changes.html

Quoting:
| New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings
| were added for C, C++, Objective-C and Objective-C++. These warnings
| diagnose variables respective parameters which are only set in the
| code and never otherwise used. Usually such variables are useless and
| often even the value assigned to them is computed needlessly,
| sometimes expensively. The -Wunused-but-set-variable warning is
| enabled by default by -Wall flag and -Wunused-but-set-parameter by
| -Wall -Wextra flags.

I don't think more changes are planned for the 4.6.x series; you'll
have to wait for 4.7 to get more changes.


yes, thanks for the clarification. bugs for these kind of errors are now filed, 
see [1], although I was a bit sloppy scanning the build logs, so there are some 
false positives.


  Matthias

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-werror;users=debian-...@lists.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/4dc084bd.9000...@debian.org



Re: PPAs for Debian

2011-05-03 Thread Simon McVittie
On Tue, 03 May 2011 at 14:46:11 -0600, René Mayorga wrote:
> On Sat, Apr 30, 2011 at 12:56:15PM +0200, Stefano Zacchiroli wrote:
> > I'd even dare to say that having something like PPA for
> > Debian is a priority. 
> 
> I do not agree on this, if the package is good enough and has somebody willing
> to maintain it, the package may belong to the archive.

As I understand it, the value of PPAs (or similar) for Debian would be that
they solve the problem of "we only have one experimental".

For instance, if upstream stable branch 0.2.x is in testing, a freeze is in
progress, the current upstream stable branch is 0.4.x and they're already
making 0.5.x development releases (projects on 6-month release cycles, like
KDE, GNOME and Telepathy, can easily get into this situation), maintainers
currently end up using unstable for 0.2.x, and having to decide which is more
useful for experimental - preparing packaging for the 0.4.x stable branch,
or getting early testing for 0.5.x.

With a PPA-like thing, you could replace experimental with gnome-stable
and gnome-devel PPAs (or whatever), and have both available at the same time.

S


-- 
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/20110503223916.ga10...@reptile.pseudorandom.co.uk



Procedure for re-activating my DD status?

2011-05-03 Thread Mark Johnson
Hi All,

I've got a handful of orphaned docbook and xml related that I'd like to
maintain [0], as well to to add some new DITA [1] packages so that we can
eventually get the DITA Open Toolkit [2] into the archive.

However, I wasn't able to find any info on how to rejoin the organization in
the standard documents. Do I simply go through the New Maintainer
application process as I did initially?

It'd be nice to get my old username back...

Thanks,
Mark

[0] Formerly as m...@debian.org:
http://qa.debian.org/developer.php?login=m...@debian.org

[1] Brief summary: http://www.ibm.com/developerworks/xml/library/x-dita1/
 Specs, DTDs,
schemas: http://docs.oasis-open.org/dita/v1.2/spec/DITA1.2-spec.html

[2] http://dita-ot.sourceforge.net/
-- 

Mark Johnson  
GPG fp: DBEA FA3C C46A 70B5 F120  568B 89D5 4F61 C07D E242


Re: Qt3 looking for adopters (orphaned now)

2011-05-03 Thread Ana Guerrero
On Sun, May 01, 2011 at 07:56:26PM +0200, Ana Guerrero wrote:
> 
> Hi,
> 
> kdelibs3 was removed recently from the archive and the last tiny bit
> of KDE 3 remaining, aRts, will be removed quite soon.
> 
> This means the KDE team is not longer interested in Qt3 and we are looking 
> for new maintainer(s). 
> 
> Personally, I would have gone for removing Qt3 too but the following concerns
> have been raised:
> 
> - latest LSB 4.1 still needs Qt3
> - some software using Qt3 do not have any replacement (twinkle has mentioned
>   for several users). There is a list of packages using Qt 3 at [1] and 
>   even if Qt3 is kept in the archive, I am planning to do a QA round of all
>   the packages using Qt3.
> - there seem to be a lot of people using their Qt 3 software and Debian in 
>   scientific environments.
> 
> Qt 3 was EOL'ed in July 2007 [2], so if you decide to adopt Qt 3 you won't
> have any support by upstream. Also, if you adopt the package, please 
> coordinate with the KDE team so we can push some final changes.
> 
> If there are no adopters in the next 3 weeks, I will do an orphaning upload 
> (and file the O: bug) with the changes mentioned earlier.

Change of plans. Due the switch to GCC 4.6, 48 packages using Qt 3 failed to 
build
from source. This was already reported against Qt3 with a patch, see bug report 
#611255 (Thanks Riddell!) and Modestas did a quick upload fixing the issue
plus the other final issues we wanted to address. See changelog [1]

We took advantage of the upload to also orphan Qt3. Orphaning bug is #625502.

If you want Qt3 is wheezy (or any of the packages that need Qt3), please, step
up soon.

[1] http://lists.debian.org/debian-devel-changes/2011/05/msg00294.html

Ana


-- 
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/20110503222439.ga30...@pryan.ekaia.org



Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Cyril Brulebois
Hi,

(not a gcc maintainer)

Charles Plessy  (04/05/2011):
> I just got a bug from you explaining some changes (= more FTBFS)
> about 4.6.1.  Will there be similar 4.6.x changes in the future ?

my reading of it is that to prevent too many FTBFSes while introducing
4.6 in Debian, some changes were delayed (“reverted through Debian
patches”) until 4.6.1 is released and uploaded.

Assuming you're talking about -Wunused-*, those are mentioned on the
upstream upgrading / porting page:
  http://gcc.gnu.org/gcc-4.6/changes.html

Quoting:
| New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings
| were added for C, C++, Objective-C and Objective-C++. These warnings
| diagnose variables respective parameters which are only set in the
| code and never otherwise used. Usually such variables are useless and
| often even the value assigned to them is computed needlessly,
| sometimes expensively. The -Wunused-but-set-variable warning is
| enabled by default by -Wall flag and -Wunused-but-set-parameter by
| -Wall -Wextra flags.

I don't think more changes are planned for the 4.6.x series; you'll
have to wait for 4.7 to get more changes.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Kudos 2 ftp-masters team!

2011-05-03 Thread Yaroslav Halchenko
Just got 1 more package accepted, after waiting only 2 days!  I then
had a look at the NEW queue -- and I merely need to scroll! amazing

Thanks you guys for your work -- that is awesome that there is virtually
no queue backlog/waiting, and it motivates to package/upload even
more!

Cheers,
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


signature.asc
Description: Digital signature


Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Charles Plessy
Le Tue, May 03, 2011 at 05:21:06PM +0200, Matthias Klose a écrit :
> 
> GCC usually has a twelve months release cycle, so you'll see the
> next set of missing include headers in spring 2012, and in Debian,
> if unstable isn't frozen by this time.

Thanks for the information.

I just got a bug from you explaining some changes (= more FTBFS) about 4.6.1.
Will there be similar 4.6.x changes in the future ?  Is there a cross-distro
plan to focus on GCC 4.6, like linux-2.6.32 was singled out for long-term
maintaince ?

Perhpas these questions seem very basic, but I think that a bit of perspectives
would be helpful.

Cheers,

-- 
Charles


-- 
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/20110503221009.gb28...@merveille.plessy.net



Re: PPAs for Debian

2011-05-03 Thread René Mayorga
On Tue, May 03, 2011 at 11:30:41PM +0200, Stefano Zacchiroli wrote:
> On Tue, May 03, 2011 at 02:46:11PM -0600, René Mayorga wrote:
> > > Yes, absolutely. I'd even dare to say that having something like PPA for
> > > Debian is a priority. 
> > 
> > I do not agree on this, if the package is good enough and has somebody 
> > willing
> > to maintain it, the package may belong to the archive.
> 
> There are two views of PPAs, one is internal for developers, one is
> external for users.
> 
> The internal for developers is offering a lightweight framework to
> experiment with changes that would be otherwise unfeasible to experiment
> with (for a whole lot of reasons, e.g.: it's freeze time and you can't
> upload "dangerous" stuff; you can't use experimental because you're
> already using it with another development line; you want to show that
> you've valuable changes to offer also for packages you do not maintain
> and with which the legitimate maintainer disagree and want to be
> convinced you're right). According to that view, PPAs are nothing short
> of a "debhub" (see one of the first mails from Pierre Habouzit in this
> thread, who has surely described this concept better than me in this
> paragraph).
> 
> The view above is the one I see as a priority for Debian

Great, thanks for the clarification.

> After all, in that  respect what is the difference between that and 
> unofficial APT
> repositories that many of us already maintain at people.d.o/~something
> or something.debian.net? Do you want to shut them down as well?

no, I was expressing over the PPA as an official services that allow users to
upload any package without any quality control.

Cheers

--
René


signature.asc
Description: Digital signature


Re: PPAs for Debian

2011-05-03 Thread Yaroslav Halchenko
disagree with both of you, although indeed, unless explicitly
mentioned, PPAs should not be positioned as 'official', since they
are NOT.

we already have dozens of private repositories around, and it is not for
us to judge either they are of any use -- time and their use would show.
The role of PPAs as far as I see it to  

1. enable with ease construction of personal repositories, 

2. make them really easily available on Debian systems, 

3. CENTRALIZE their location under Debian's umbrella.   

Benefits would be numerous: from actually QAing (e.g. automatic
lintian, rebuilds etc) so that e.g. no sponsorship request is even
accepted unless package passes PPA QA, to possibly even serving them as
the possible venue for custom packaging work of the derivatives (thus
making it easier to put it into Debian proper).


On Tue, 03 May 2011, Andreas Barth wrote:
> > I do not agree on this, if the package is good enough and has somebody 
> > willing
> > to maintain it, the package may belong to the archive.

> Eh, the PPAs we are speaking about is like "new features to existing
> packages". Yes, we need to avoid PPAs which are just dead ends.


> Andi
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
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/20110503213954.gs16...@onerussian.com



Re: PPAs for Debian

2011-05-03 Thread Stefano Zacchiroli
On Tue, May 03, 2011 at 02:46:11PM -0600, René Mayorga wrote:
> > Yes, absolutely. I'd even dare to say that having something like PPA for
> > Debian is a priority. 
> 
> I do not agree on this, if the package is good enough and has somebody willing
> to maintain it, the package may belong to the archive.
> 
> If the package is on the archive it will get automatic and manual QA tests, 
> and
> it can take advantage on all the already existing tools(PTS, DDPO, BTS, etc).
> 
> but if we set yet another archive that will be open for anyone (like PPA) we 
> will
> get packages with low quality, and maybe some users blaming debian about the
> quality being dropped when they confuse this and think those are official 
> packages/repositories.

There are two views of PPAs, one is internal for developers, one is
external for users.

The internal for developers is offering a lightweight framework to
experiment with changes that would be otherwise unfeasible to experiment
with (for a whole lot of reasons, e.g.: it's freeze time and you can't
upload "dangerous" stuff; you can't use experimental because you're
already using it with another development line; you want to show that
you've valuable changes to offer also for packages you do not maintain
and with which the legitimate maintainer disagree and want to be
convinced you're right). According to that view, PPAs are nothing short
of a "debhub" (see one of the first mails from Pierre Habouzit in this
thread, who has surely described this concept better than me in this
paragraph).

The view above is the one I see as a priority for Debian, as it will
enable developers to experiment with important changes against the
inertia that plagues us (or "too big size", as put down by others in
this thread).

The user view is different, is about using PPAs to deliver non-official
packages to users. I agree that such a view might be plagued by the
problem you mention. Of course, being realistic, to have the above view
we will also need a way for the users to test packages as developers
themselves will need to test "forked" packages in the first place. As
long as it is clear that PPAs are not official Debian and it is not "too
easy" to get to them, I don't see a problem with it. After all, in that
respect what is the difference between that and unofficial APT
repositories that many of us already maintain at people.d.o/~something
or something.debian.net? Do you want to shut them down as well?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature


Re: Integrating aptosid?

2011-05-03 Thread Yaroslav Halchenko

On Tue, 03 May 2011, Alessandro Ghedini wrote:
> > Or am I missing some substantial design issue which is still lacking
> > from http://wiki.debian.org/Derivatives/Guidelines
> Sounds like the "Debian Pure Blends" [0] [1], with the difference that they
> seem to use tasks instead of metapackages if I understood it correclty. 

tasks are used to create the metapackages ;)

blends are indeed very very related indeed.  Historically though they
became of wider scope and deeper coverage, than I think many of
the derivatives, which are often just customized package selection +
design + custom installer/live-media.

So, theoretically, blends mechanism could be extended to actually
provide such customized installer + appearance or may be Debian
installer itself could be used out of the box to provide a selection
among blends and their tasks and even within the tasks, because some
tasks cover too much of the software instances, not reasonable to have
pre-installed them all at once.

But altogether the point is that indeed, it would be nice we somehow we
could bring derivatives communities closer to Debian so they do not
loose their originality/projects but infuse their work into Debian
meanwhile.

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
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/20110503213241.gr16...@onerussian.com



Re: PPAs for Debian

2011-05-03 Thread Andreas Barth
* René Mayorga (rmayo...@debian.org) [110503 22:52]:
> On Sat, Apr 30, 2011 at 12:56:15PM +0200, Stefano Zacchiroli wrote:
> > On Sat, Apr 30, 2011 at 12:07:24PM +0200, Andreas Barth wrote:
> > > 
> > > I think it would make quite sense to get something like e.g. ppa done for
> > > Debian. But thats something else than it's proposed here.
> > 
> > Yes, absolutely. I'd even dare to say that having something like PPA for
> > Debian is a priority. 
> 
> I do not agree on this, if the package is good enough and has somebody willing
> to maintain it, the package may belong to the archive.

Eh, the PPAs we are speaking about is like "new features to existing
packages". Yes, we need to avoid PPAs which are just dead ends.


Andi


-- 
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/20110503213151.gr15...@mails.so.argh.org



Bug#625499: ITP: libgeo-coder-googlev3-perl -- Perl module providing access to Google Maps v3 Geocoding API

2011-05-03 Thread USB
Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: libgeo-coder-googlev3-perl
  Version : 0.07
  Upstream Author : Slaven Rezic 
* URL : http://search.cpan.org/dist/Geo-Coder-Googlev3/
* License : Artistic
  Programming Lang: Perl
  Description : Perl module providing access to Google Maps v3 Geocoding API

Geo::Coder::GoogleV3 is a Perl module that provides access to Google's
Google Map API v3. Note that v3 does not require an apikey and the data
structure returned is different than previous versions of the API.

Check http://code.google.com/intl/en/apis/maps/documentation/geocoding/
for more information about Google's Geocoding API and especially usage
limits.

(This package is a dependency for the forthcoming WebGUI 7.10 release)



--
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/20110503211053.14972.79118.report...@deepthought.ius.cc



Re: Debian rolling: tentative summary

2011-05-03 Thread Steve McIntyre
Samuel Thibault wrote:
>Lucas Nussbaum, le Mon 02 May 2011 13:31:31 +0200, a écrit :
>> How we deal with freezes is the hard point in this discussion. I'm
>> personnally in favor of the "freeze rolling for 3 months, then fork
>> frozen and unfreeze rolling" plan, though it has some problems too
>> (it is not clear whether the required manpower really decreases at
>> the end of freezes).
>
>And what I'm afraid of is that a lot of developers will see this
>switching point as "ok, now it's debian-release's matter, I can again
>focus on rolling only"...

Ditto - that's exactly what I'd be worried about.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?


-- 
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/e1qhlvq-0007wy...@jack.mossbank.org.uk



Re: PPAs for Debian

2011-05-03 Thread René Mayorga
On Sat, Apr 30, 2011 at 12:56:15PM +0200, Stefano Zacchiroli wrote:
> On Sat, Apr 30, 2011 at 12:07:24PM +0200, Andreas Barth wrote:
> > 
> > I think it would make quite sense to get something like e.g. ppa done for
> > Debian. But thats something else than it's proposed here.
> 
> Yes, absolutely. I'd even dare to say that having something like PPA for
> Debian is a priority. 

I do not agree on this, if the package is good enough and has somebody willing
to maintain it, the package may belong to the archive.

If the package is on the archive it will get automatic and manual QA tests, and
it can take advantage on all the already existing tools(PTS, DDPO, BTS, etc).

but if we set yet another archive that will be open for anyone (like PPA) we 
will
get packages with low quality, and maybe some users blaming debian about the
quality being dropped when they confuse this and think those are official 
packages/repositories.

Cheers

--
René



signature.asc
Description: Digital signature


Bug#625490: ITP: libxml-feedpp-mediarss-perl -- Perl module providing Media RSS support for XML::FeedPP

2011-05-03 Thread USB
Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: libxml-feedpp-mediarss-perl
  Version : 0.02
  Upstream Author : Paul Driver 
* URL : http://search.cpan.org/dist/XML-FeedPP-MediaRSS/
* License : Artistic
  Programming Lang: Perl
  Description : Perl module providing Media RSS support for XML::FeedPP

XML::FeedPP::MediaRSS is a pure Perl library extending XML::FeedPP
to provide support for Yahoo's Media RSS extensions.

(This package is a dependency for the forthcoming WebGUI 7.10 release)



--
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/20110503195355.22218.42354.report...@deepthought.ius.cc



Re: Integrating aptosid?

2011-05-03 Thread Alessandro Ghedini
On Tue, May 03, 2011 at 12:23:45PM -0400, Yaroslav Halchenko wrote:
> FWIW my 1 cent: the idea is really sound although a bit idealistic,
> because it goes inline with my utopian future of Debian: many
> derivatives are just customizations of Debian with varying level of
> additional custom extensions (often DFSG-compliant thus candidates for
> inclusion into Debian proper) + installer or live-media options; i.e.
> they are using Debian package base and add some additional packages (or
> manual installations/customizations just because it might be easier at
> first)
> 
> So at the end, is there any objective show stopper to
> hypothetically have in a Debian metapackages like
> 
> N.B. couldn't come up with a good prefix, so let it be 'flavor'
> 
>  flavor-aptosid
>  flavor-mint
>  flavor-neurodebian
> ...
> 
> installation of which would simply tune existing plain Debian
> installation to actually become the derivative itself?
> 
> if only we could persuade and collaborate with derivatives authors to
> make this possible and easy.  Then derivative projects could concentrate
> on providing custom installers/live-media and everyone would be happy.
> 
> Or am I missing some substantial design issue which is still lacking
> from http://wiki.debian.org/Derivatives/Guidelines

Sounds like the "Debian Pure Blends" [0] [1], with the difference that they
seem to use tasks instead of metapackages if I understood it correclty. 

I don't know what's the state of the project though, maybe someone more 
involved in it can comment further.

Cheers

[0] http://wiki.debian.org/DebianPureBlends
[1] http://blends.alioth.debian.org/blends/

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


-- 
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/20110503194649.GA4814@PC-Ale.WAG300N



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Andreas Barth
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110503 11:47]:
> On 02/05/11 at 16:19 -0700, Russ Allbery wrote:
> > Lucas Nussbaum  writes:
> > 
> > > [ Note that my position is based on the assumption that we have a share
> > > of DDs interested in rolling similar to the share of DDs interested in
> > > stable releases. Unfortunately, it's very difficult to know where we
> > > stand regarding this. ]
> > 
> > I'm very dubious.  To take one example, if Debian stopped making stable
> > releases, it would no longer be usable at work, which would mean that my
> > ability to work in Debian would substantially decrease and quite possibly
> > go away completely.
> 
> Except for the sake of argumentation, I don't think that anybody
> considers seriously that Debian would stop making stable releases.
> The question is whether we want to provide a rolling release in addition
> to our stable releases.

<20110501133957.ga13...@rivendell.home.ouaza.com> sounds to me like we
will loose quite some man-power for making stable releases. This could
equally well mean we can't do some.

If it is guranteed that stable release don't become harder / uglier, I
don't think anybody has any reservations to adding new suites.
However, as long as the general impression is "making stable releases
will get way harder", that's different.


Andi


-- 
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/20110503192328.gq15...@mails.so.argh.org



Re: Debian rolling: tentative summary

2011-05-03 Thread sean finney
Hi Lucas,

On Tue, May 03, 2011 at 02:59:04PM +0200, Lucas Nussbaum wrote:
> I think that one of the conclusions of the discussion from the last few
> days is that the freeze "blockage" has very good features that many of
> us are not willing to give up, like the ability to focus the DDs on
> working on stable releases.

I do not think there was any such consensus.  There were people who
voiced valid concerns about this, and I believe there were also people
who provided counter arguments.  I do not recall any kind of consensus,
or even "choosing camps" on this issue beyond that, just that the thread
drifted away in another direction.  ISTR even seeing some hard data[1]
floating around about a declining number distinct contributions as the
freeze progressed, which would weigh pretty heavily against any argument
about "focusing DD's"[2].  DEP-10, while being otherwise lacking in
content, does describe this problem pretty well[3] as motivation for
exploring changes to the release process.

And beyond that, how does the exact same argument *not* apply to rolling
regarding DD time/focus?

Anyway, if you want to focus solely on the rolling related stuff, that's
fine.  I don't really have a vested opinion on it one way or another,
I just felt that your summary didn't have a full view of everything
discussed in this massive thread.

sean

[1] I don't recall if it was in the thread or on IRC, but the data was
taken from -changes/BTS statistics during the release process.
[2] That is to say, having a restriction that "you can only do foo",
especially in a volunteer project doesn't necessarily guarantee
that significantly more people will help with "doing foo" than
would otherwise.
[3] http://dep.debian.net/deps/dep10/



-- 
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/20110503172100.gb30...@cobija.connexer.com



Re: Reporting same bug in different packages

2011-05-03 Thread Ben Hutchings
On Tue, May 03, 2011 at 05:22:09PM +0200, Josselin Mouette wrote:
> Le mardi 03 mai 2011 à 15:56 +0200, Patrick Strasser a écrit : 
> > schrieb Patrick Strasser am 2011-05-03 15:23:
> > > [..] details in the bug report.
> > 
> > #625452
> 
> Congratulations, you have added yet another bug on the pile that no one
> ever reads, since there are no real maintainers for poppler.
 
Where is your RFH bug?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110503171909.gh2...@decadent.org.uk



Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope

2011-05-03 Thread Kurt Roeckx
On Tue, May 03, 2011 at 07:21:28AM +0200, Lucas Nussbaum wrote:
> (Ccing -devel@, since I have been asked about that by others)
> 
> On 03/05/11 at 01:16 +0200, Rene Engelhard wrote:
> > tag 624997 - wheezy
> > thanks
> > 
> > On Mon, May 02, 2011 at 02:39:43PM +0200, Lucas Nussbaum wrote:
> > > Source: writerperfect
> > > Version: 0.8.0-3
> > > Severity: serious
> > > Tags: wheezy sid
> > 
> > No. gcc 4.6 is not in wheezy. If you find gcc 4.6 FTBFSes please take
> > care on where and when this stuff actually takes place.
> > 
> > Grüße/Regards,
> 
> Note that the alternatives are:
> - tag it 'sid'. But then, I would need to determine the root cause of
>   each FTBFS, and when the status of the FTBFS changes in testing.
> - do not tag it. But then, it would be seen as affecting stable.
> 
> What I would need is a way to express "It FTBFS in sid. I know it
> doesn't FTBFS in stable, I don't know about wheezy."

Tagging it with wheezy *is* the correct thing to do.  If you're
tagging it with only sid it means that it can never affect
anything else than sid.  And since this is a bug caused by some
other package and you can't prevent that other package from
migrating to testing, you have to assume that it will affect
testing in the future.  Else when it does migrate to testing this
is a bug that nobody will care about since it only affects
unstable.


Kurt




-- 
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/20110503171141.ga6...@roeckx.be



Re: Debian rolling: tentative summary

2011-05-03 Thread Josselin Mouette
Le mardi 03 mai 2011 à 10:33 +0200, Milan P. Stanic a écrit : 
> IMHO Debian is for the people who understand computers and are willing
> to invest some time to learn and "user friendly" distributions are for
> other more or less laymen people.

Certainly not. Debian is the universal Operating System, and just
because it doesn’t ship with wobbly windows by default doesn’t mean it
shouldn’t be suitable for those who don’t want to learn.

-- 
Joss


--
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/1304441271.31471.22.camel@pi0307572



Re: OK, Re: need a server for debdelta repository

2011-05-03 Thread Stefano Zacchiroli
On Tue, May 03, 2011 at 06:03:42PM +0200, A Mennucc wrote:
> The debdelta repository  'debdeltas.debian.net' has a new home! I thank
> a lot 'md' for hosting it in ftp.linux.it; and also 'ansgar' ,
> 'formorer' for offering a host.
> 
> With a new server, the service should also be better: deltas should be
> available no more than 1 hour later than the corresponding deb. (*) So
> you should almost never see the message "delta is not present" (but you
> may see the message "delta is too big" ).

Good!, thanks for the news and for maintaining the service.

Out of curiosity, and given http://debdelta.debian.net has been around
for a long while now and is used (according to my exchanges with you)
regularly, do you have a plan for integration into debian.*org* proper?

In principle, it looks like a very useful service to users than they
should be able to enable triggering a switch into APT. Is there any
document describing that possibility, its drawbacks, showstoppers and,
more generally, the way forward?

Is the ongoing GSOC project [1] the only remaining block or… ?
(Yes, I'm also aware of [2], but it seems independent form actually
making easier for users to find and use the service.)

Cheers.

[1] http://wiki.debian.org/SummerOfCode2011#DebDelta_APT_Native_Integration
[2] http://lists.debian.org/debian-dpkg/2011/04/msg00060.html

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature


Re: Debian rolling: tentative summary

2011-05-03 Thread Russ Allbery
"Milan P. Stanic"  writes:

> I don't think that the Debian can beat Ubuntu in popularity on
> desktop/laptop field (not yet) and IMHO it should not even try that.

> IMHO Debian is for the people who understand computers and are willing
> to invest some time to learn and "user friendly" distributions are for
> other more or less laymen people.

Eh, I wouldn't say that.  I do think we should be careful to protect those
areas where we're strong and not sacrifice them, but we're actually pretty
good at doing multiple things at the same time.  If we can be great for
servers *and* for embedded systems *and* for desktops and laptops, so much
the better.  And being user-friendly to people who aren't sophisticated
computer users is a useful goal to keep in mind, even if we never quite
reach the level of distributions focusing solely on that, as long as it's
an option and not a mode required across the whole distribution.

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



Re: Reporting same bug in different packages

2011-05-03 Thread Josselin Mouette
Le mardi 03 mai 2011 à 17:23 +0200, Patrick Matthäi a écrit : 
> > Congratulations, you have added yet another bug on the pile that no one
> > ever reads, since there are no real maintainers for poppler.
> 
> Which doesn't mean, that there won't be a new maintainer in the future, 
> who is willed to address these bugs.

Yeah sure, and he might also be willing to do a bit of skiing in hell.

-- 
Joss


--
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/1304440848.31471.20.camel@pi0307572



Re: Integrating aptosid?

2011-05-03 Thread Yaroslav Halchenko
FWIW my 1 cent: the idea is really sound although a bit idealistic,
because it goes inline with my utopian future of Debian: many
derivatives are just customizations of Debian with varying level of
additional custom extensions (often DFSG-compliant thus candidates for
inclusion into Debian proper) + installer or live-media options; i.e.
they are using Debian package base and add some additional packages (or
manual installations/customizations just because it might be easier at
first)

So at the end, is there any objective show stopper to
hypothetically have in a Debian metapackages like

N.B. couldn't come up with a good prefix, so let it be 'flavor'

 flavor-aptosid
 flavor-mint
 flavor-neurodebian
...

installation of which would simply tune existing plain Debian
installation to actually become the derivative itself?

if only we could persuade and collaborate with derivatives authors to
make this possible and easy.  Then derivative projects could concentrate
on providing custom installers/live-media and everyone would be happy.

Or am I missing some substantial design issue which is still lacking
from http://wiki.debian.org/Derivatives/Guidelines


On Tue, 03 May 2011, Pierre Habouzit wrote:
> I know it's not simple, but it's not necessarily harder than making
> testing usable, I think Joss made a pretty good case about that on his
> blog.

> > Also, FYI, the aptosid development team is composed of 8 to 10 developers,
> > contributing to different things at different levels (info gathered on
> > #aptosid@OFTC).

> aptosid is just an example, I don't even know the distro, they may not
> be the best choice, I just try to find alternates ideas. Note that I
> don't think it takes more than 10 people to do the rolling distro like
> Joss propose it: snapshot unstable every month and fix the worst
> breakages. It takes more than 10 people to do the same in testing
> because each individual fix is tangled in the migration issue, hence
> rapidly needs to update things that are at first totally unrelated to be
> fixed too first.
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


--
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/20110503162344.gq16...@onerussian.com



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Russ Allbery
Lucas Nussbaum  writes:
> On 02/05/11 at 16:19 -0700, Russ Allbery wrote:

>> I'm very dubious.  To take one example, if Debian stopped making stable
>> releases, it would no longer be usable at work, which would mean that
>> my ability to work in Debian would substantially decrease and quite
>> possibly go away completely.

> Except for the sake of argumentation, I don't think that anybody
> considers seriously that Debian would stop making stable releases.  The
> question is whether we want to provide a rolling release in addition to
> our stable releases.

Yeah, sorry, I knew that's what you meant and should have said so
explicitly.

I'm totally fine with a rolling release if we can figure out how to add it
to the project without hurting stable.  I'm only speaking up to make clear
that yes, there really are people who are passionate about (and
passionately happy about) stable.  It sometimes feels in some of the
rolling testing discussions like DDs can start feeling like stable isn't a
useful product, since a lot of the input is from people for whom stable
isn't ideal (since people with problems talk more than people without
problems).  But it definitely is.

>> I realize that we're often not on the mailing lists jumping up and down
>> and advocating for our issues, in part because Debian works great for
>> us and not much needs to be changed, but please remember that there are
>> a *lot* of us using Debian on servers in large-scale production
>> environments.  And stable is our world.  It's EXTREMELY IMPORTANT.  It
>> is, in many cases, the reason why we were able to sell Debian in the
>> first place; if it weren't for Debian's exceptionally good stable
>> releases, we would probably all be running Red Hat.

> I assume that when you write 'us' or 'we' here, you mean 'Debian users
> in large-scale production environments'.

Yes, indeed.

> Again, I'm not diminishing the importance of stable releases. But I've
> always found it strange that, as a volunteer project, we are creating a
> product that is mainly used in professional environments.

I guess I don't find that to be any sort of conflict.  Many of us aren't
only volunteering as individual contributors to create things that we want
to run on our desktops.  We're also volunteering as system administrators,
developers, or similar sorts of IT roles to create things that we want to
run at work.  And I think in many cases (such as mine), our employers are
actually volunteering substantial amounts of our paid time to work on
Debian as well.

It's still a volunteer project.  One of the volunteers happens to be
Stanford University, donating staff time.  :)

> It is clear from the discussion that there would be consequences. Some
> would be negative, some positive. I think that we have now a pretty good
> understanding of the possibilities and their consequences. The remaining
> problem is to count DDs heads in the two camps:
> - "Let's focus on stable releases. A rolling release should not be
>provided officially by Debian."
> - "Let's see what we can do about rolling, provided we find a way to do it
>without diminishing the quality of our stable releases."

Well, I don't think anyone really objects to the second category and we'd
all consider ourselves to be in that category if it works.  Most of the
discussion, from where I sit, is over whether or not it's possible to do
that.  If we can have both, that's clearly the best possible outcome.

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



OK, Re: need a server for debdelta repository

2011-05-03 Thread A Mennucc
The debdelta repository  'debdeltas.debian.net' has a new home! I thank
a lot 'md' for hosting it in ftp.linux.it; and also 'ansgar' ,
'formorer' for offering a host.

With a new server, the service should also be better: deltas should be
available no more than 1 hour later than the corresponding deb. (*) So
you should almost never see the message "delta is not present" (but you
may see the message "delta is too big" ).

A.

ps: (* this is not true yet for debian-security , I need to do a bit of
work on that)




signature.asc
Description: OpenPGP digital signature


Re: Reporting same bug in different packages

2011-05-03 Thread Patrick Matthäi

Am 03.05.2011 17:22, schrieb Josselin Mouette:

Le mardi 03 mai 2011 à 15:56 +0200, Patrick Strasser a écrit :

schrieb Patrick Strasser am 2011-05-03 15:23:

[..] details in the bug report.


#625452


Congratulations, you have added yet another bug on the pile that no one
ever reads, since there are no real maintainers for poppler.


Which doesn't mean, that there won't be a new maintainer in the future, 
who is willed to address these bugs.



--
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/4dc01e02.10...@debian.org



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Mehdi Dogguy
On 03/05/2011 14:54, Lucas Nussbaum wrote:
> 
> What kind of guarantees are you looking for, exactly? Can you suggest
> ways to acquire them?
> 

- That it won't affect stable in bad ways.
- preventing removals from testing is a no-go.

Quite honestly, I see no reason to continue feeding this thread because
I realized (maybe quite late) that there were good arguments against
"frozen" and not much for it apart of hand-waving. It seems that those
who want to have "rolling" in Debian didn't even try to summarize what
made the success of other rolling distros, and what their users liked
there. We do need this kind of survey before even thinking about how to
do "rolling" in Debian… and we don't have this kind of data yet.

I don't know (yet) what other rolling distros Debian based offer to its
users that we don't. I don't know what made aptosid so popular. I don't
know what made Mint Debian popular? (and there are others). Did you even
try to gather those informations before even mentioning "rolling" for
Debian? How can we discuss about "rolling" in Debian if we don't have
that kind of data? You are always mentioning "potential users", but those
potential users might be today-users of aptosid or Mint Debian. So, we
should start from there, instead of just saying "No, but you'll see,
rolling will be cool", "it will make maintainers care about their
pacakges", "it won't affect stable because bla bla bla"…

So, I'll start document myself on this and I'll be back when I know enough
about this story. Sadly, I don't have much time to do this these days and
it might take some time. I'd be glad if others start to gather such
informations and put them somewhere so that we don't understand why is it
so important, and why users don't just use testing today.

I can't find the answers here and it seems that you're not able to give
them, because otherwise you would have used them already to say why
"rolling" will bring users, or what do "rolling" users like?

(The survey we need should "rolling"-topic specific, not about Debian in
general).

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4dc01f93.2010...@debian.org



Re: Reporting same bug in different packages

2011-05-03 Thread Josselin Mouette
Le mardi 03 mai 2011 à 15:56 +0200, Patrick Strasser a écrit : 
> schrieb Patrick Strasser am 2011-05-03 15:23:
> > [..] details in the bug report.
> 
> #625452

Congratulations, you have added yet another bug on the pile that no one
ever reads, since there are no real maintainers for poppler.

Cheers,
-- 
Joss


--
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/1304436129.22032.275.camel@pi0307572



Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Matthias Klose

On 05/03/2011 11:32 AM, Charles Plessy wrote:

the recent archive rebuild uncovered a large number of GCC 4.6 build failures
(that could been already forseen from Launchpad).  In the long run, I find very
impressive the contribution from the major Linux distribution to their upstreams
for keeping them up to date with recent toolchains.

However, given my experience of repetitive patching cycles with earlier GCC
updates, it would be pointless to spend a lot of energy updating our packages
now if it is only to realise in few weeks that the next GCC update would
require yet another header.


Please note that the bug reports for build failures with GCC 4.5 were filed 16 
months ago [1].  So you had the chance to address these in the previous release 
cycle too.  Lucas only had the resources for a rebuild test now, so that's why 
you didn't see these earlier (a rough list can be at [2]).  Results from the 
Ubuntu natty rebuild test did differ too much in package version numbers to be 
used for a bug filing in Debian [3].


I am sure the QA team would welcome rebuild tests on other architectures too. 
Feedback from some port maintainers about the usability of 4.6 is still 
outstanding, so I can't say which architecture will end up with which compiler 
version.


GCC usually has a twelve months release cycle, so you'll see the next set of 
missing include headers in spring 2012, and in Debian, if unstable isn't frozen 
by this time.


  Matthias

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.5;users=debian-...@lists.debian.org
[2] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.6;users=debian-...@lists.debian.org

[3] https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs (covering all ftbfs)


--
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/4dc01d62.3010...@debian.org



Re: network-manager as default? No!

2011-05-03 Thread Luca Capello
Hi there!

On Mon, 02 May 2011 03:03:51 +0200, Fernando Lemos wrote:
> 2011/5/1 Miroslav Suchý :
>> Dne 3.4.2011 18:08, Fernando Lemos napsal(a):
>>>
>>> * It doesn't have a good command-line interface
>>
>> It does have CLI interface. Those commands are bundled directly in
>> NetworkManager:
>> nm-cli
   ^^
nmcli, without the dash, for I do not know which reason (and I was
missing it because of that).

>> nm-tool
>> nm-online
>>
>> I'm not sure if this qualify as "good command-line interface" :)
>
> Those tools can't create or delete connections, which is kind of
> important, so no. ;-)

Exactly, I was enjoying the moment when I found out that NM has CLI
interfaces, then discovering that I could not do anything brought me
back to my old loved manual setup (yes, through ifup and wpasupplicant).

> That said, nothing prevents the creation of a decent command-line
> interface. There's cnetworkmanager, which wasn't working the last time
> I checked (API incompatibility with the Debian packages, might have
> been fixed by now). The DBus API is pretty straightforward, I use a
> bunch of scripts to create and delete wireless connections.

FWIW, nmcli is supposed to be the official NM CLI and it superseded
cnetworkmanager:

  

  

Thx, bye,
Gismo / Luca


pgpTZImGcziWh.pgp
Description: PGP signature


Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Jan Hauke Rahm
On Tue, May 03, 2011 at 01:31:24PM +0200, Pierre Habouzit wrote:
> On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote:
> > It is clear from the discussion that there would be consequences. Some
> > would be negative, some positive. I think that we have now a pretty good
> > understanding of the possibilities and their consequences. The remaining
> > problem is to count DDs heads in the two camps:
> > - "Let's focus on stable releases. A rolling release should not be
> >provided officially by Debian."
> > - "Let's see what we can do about rolling, provided we find a way to do it
> >without diminishing the quality of our stable releases."
> 
> FWIW I'm in neither. My camp would be: Please do not impede our way to
> produce stable releases in any ways, do whatever you want with rolling.

I'm sorry but I find that a lame request. If, in whatever circumstances,
Debian as a project decides to care about something beyond stable
releases, for instance something called rolling, it will as a matter of
fact use power of the project for such new thing and thus distract that
power from stable releases. Always. Saying that anyone can do anything
as long as it never interferes with what we have now is exactly the
definition of keeping the status-quo, i.e. preventing improvement.
Granted, it also prevents breakage.

> I've suggested integrating aptosid (or $derivative) people inside of
> Debian as a way to provide rolling, I know that Joss did so on planet
> too e.g. That has two very important advantages:
>   * it brings in new blood *now* (and not an hypothetical later) to
> actually take care of rolling (which doesn't make all my reservation
> moot but I reckon does lessen their scope significantly);
>   * it brings people who know how to do that and already have
> infrastructure to do so. We would just give them the opportunity to
> benefit from the larger and robust infrastructure we have, while
> taking their experience. Looks like it's win-win.

Have you asked *any* contributor of *any* project about why they didn't
put their efforts in Debian but instead into a different project?

aptosid for example claims that unstable is in fact usable by people not
too technically equiped. Debian (usually) claims, it isn't. They think,
it just needs a bit of fixing every now and then and there you go with a
fine rolling release. If we, however we could achieve it, integrated
aptosid in Debian, how would that be different to adding a rolling
release suite?

My actual point being, whether we contact developers of derivatives
first and then add rolling (or whatever it's going to be called), or add
such thing and then promote it to developers outside Debian hoping for
their interest and involvement isn't at all important while we're still
discussing if Debian wants to take care of something beyond stable
releases.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature


Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread The Fungi
On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote:
[...]
> I've always found it strange that, as a volunteer project, we are
> creating a product that is mainly used in professional
> environments.
[...]

I see that as a side effect. The same qualities of stable which lead
me to rely on it on for a vast number of servers in an ISP/data
center setting also make it an ideal platform for the servers which
host and provide services to the whole of the free software
community... much the same way that the volunteers who maintain
buildds, mirrors and the bulk of Debian's infrastructure are almost
certainly also enterprise, service provider or university technology
professionals by day.

The lessons learned in those environments help demonstrate what
technologies do and don't scale. A volunteer sysadmin managing a ton
of infrastructure for a large free software project is, given the
opportunity, going to choose a platform which requires as little
maintenance as possible. This increased efficiency maximizes the
impact of his or her contribution to the community. In many cases,
this is Debian's stable release.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110503135944.gc1...@yuggoth.org



Re: Reporting same bug in different packages

2011-05-03 Thread Patrick Strasser
schrieb Patrick Strasser am 2011-05-03 15:23:
> [..] details in the bug report.

#625452

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/ipp1j5$ahg$1...@dough.gmane.org



Bug#625453: ITP: args4j -- args4j is a small Java class library that makes it easy to parse command line options/arguments in your CUI application.

2011-05-03 Thread James Page
Package: wnpp
Severity: wishlist
Owner: James Page 


* Package name: args4j
  Version : 2.0.16
  Upstream Author : Kohsuke Kawaguchi 
* URL : http://java.net/projects/args4j
* License : MIT
  Programming Lang: Java
  Description : Java based command line parser.

args4j is a small Java class library that makes it easy to parse command line 
options/arguments in your CUI application.

This package is a dependency for packaging of Jenkins.



-- 
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/20110503134443.24082.60858.reportbug@hendrix.shouse.local



Re: Reporting same bug in different packages

2011-05-03 Thread Patrick Strasser
schrieb Patrick Strasser am 2011-05-02 19:20:

>> I want to report a bug, which occurs in two packages (okular, xpdf)
>> exactly the same way. It's a problem with rendering PDFs.
>> What would be the right way:
> 
>> * File two bugs and refer to each other in a additional message
>> * File one bug and refer to the second package

Thank you for the detailed answers! I found several other viewers with
the same problem,  so I'll file the bug under libpoppler5 and leave it
to the experts to find the right assignment.

> This works if it is for both okular and xpdf and bug resides in both of
> them.  Do you see thae same in evince?

Evince and some others works fine, details in the bug report.

>> If d.devel.general is the wrong group [...]

> http://www.debian.org/Bugs/Reporting states that “If you are unable to
> determine which package your bug report should be filed against, please
> send e-mail to the Debian user mailing list [0] asking for advice.”, and
> the translation of this page may point the user to a localized list.

Thanks, I read the guide, but missed that. Next time I know it ;-)

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/ipovjl$u3h$1...@dough.gmane.org



Re: Integrating aptosid?

2011-05-03 Thread Pierre Habouzit
On Tue, May 03, 2011 at 03:17:18PM +0200, Lucas Nussbaum wrote:
> On 03/05/11 at 15:05 +0200, Pierre Habouzit wrote:
> > aptosid is just an example, I don't even know the distro, they may not
> > be the best choice, I just try to find alternates ideas. Note that I
> > don't think it takes more than 10 people to do the rolling distro like
> > Joss propose it: snapshot unstable every month and fix the worst
> > breakages. It takes more than 10 people to do the same in testing
> > because each individual fix is tangled in the migration issue, hence
> > rapidly needs to update things that are at first totally unrelated to be
> > fixed too first.
> 
> By proposing to provide a snapshot every month, you are proposing a
> different point in the "quality/up-to-date-ness" compromise map. This
> compromise looks less appealling to me than the "rolling==testing" or
> the aptosid ones.
> 
> Also, are you aware of the monthly snapshots built by Michael Gilbert?
> See http://lists.debian.org/debian-devel/2011/04/msg00397.html

I don't advocate it, I'm just saying there are other options that
haven't been discussed yet. I don't really know which is better for the
user, I couldn't care less (I've already stated I'm fine with unstable
right? ;p). Though technically such a solution has less impact on our
current release workflow and I prefer it.
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.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/20110503131855.gq...@madism.org



Re: Integrating aptosid?

2011-05-03 Thread Lucas Nussbaum
On 03/05/11 at 15:05 +0200, Pierre Habouzit wrote:
> aptosid is just an example, I don't even know the distro, they may not
> be the best choice, I just try to find alternates ideas. Note that I
> don't think it takes more than 10 people to do the rolling distro like
> Joss propose it: snapshot unstable every month and fix the worst
> breakages. It takes more than 10 people to do the same in testing
> because each individual fix is tangled in the migration issue, hence
> rapidly needs to update things that are at first totally unrelated to be
> fixed too first.

By proposing to provide a snapshot every month, you are proposing a
different point in the "quality/up-to-date-ness" compromise map. This
compromise looks less appealling to me than the "rolling==testing" or
the aptosid ones.

Also, are you aware of the monthly snapshots built by Michael Gilbert?
See http://lists.debian.org/debian-devel/2011/04/msg00397.html

- Lucas


-- 
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/20110503131718.ga20...@xanadu.blop.info



Re: Integrating aptosid?

2011-05-03 Thread Pierre Habouzit
On Tue, May 03, 2011 at 03:05:34PM +0200, Pierre Habouzit wrote:
> On Tue, May 03, 2011 at 02:42:26PM +0200, Lucas Nussbaum wrote:
> > It's not as simple as "let's integrate aptosid". There are at least two
> > sides to this:
> > - integrate the developers community in Debian. They are probably very
> >   nice etc, but:
> >   1) they are not currently Debian contributors (even if some of them
> >  might be)
> 
> That's not a real issue.
> 
> >   2) they might not adhere to Debian's values
> 
> That would be one.
> 
> >   3) they decided to start a separate project, they might have good
> >  reasons to do it outside Debian
> 
> The most likely would be (1)
Or/and the impression that the idea has no support within Debian.

IOW I don't see real blockers here if we have the intention (and that
they agree).
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.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/20110503130724.gp...@madism.org



Re: Integrating aptosid?

2011-05-03 Thread Pierre Habouzit
On Tue, May 03, 2011 at 02:42:26PM +0200, Lucas Nussbaum wrote:
> On 03/05/11 at 13:31 +0200, Pierre Habouzit wrote:
> > I've suggested integrating aptosid (or $derivative) people inside of
> > Debian as a way to provide rolling, I know that Joss did so on planet
> > too e.g. That has two very important advantages:
> >   * it brings in new blood *now* (and not an hypothetical later) to
> > actually take care of rolling (which doesn't make all my reservation
> > moot but I reckon does lessen their scope significantly);
> >   * it brings people who know how to do that and already have
> > infrastructure to do so. We would just give them the opportunity to
> > benefit from the larger and robust infrastructure we have, while
> > taking their experience. Looks like it's win-win.
> > They probably have good ideas on what could be improved in Debian to
> > make their job easier, while *we* don't since we never tried.
> 
> It's not as simple as "let's integrate aptosid". There are at least two
> sides to this:
> - integrate the developers community in Debian. They are probably very
>   nice etc, but:
>   1) they are not currently Debian contributors (even if some of them
>  might be)

That's not a real issue.

>   2) they might not adhere to Debian's values

That would be one.

>   3) they decided to start a separate project, they might have good
>  reasons to do it outside Debian

The most likely would be (1)

> - integrate the technical processes inside Debian. We can't just add
>   aptosid as a new Debian suite: that would be the worst solution
>   (important overhead since Debian maintainers would have to care for
>   unstable, testing and aptosid, then). So we need to work out solutions
>   to reduce the overhead, and all the former discussion applies.

I know it's not simple, but it's not necessarily harder than making
testing usable, I think Joss made a pretty good case about that on his
blog.

> Also, FYI, the aptosid development team is composed of 8 to 10 developers,
> contributing to different things at different levels (info gathered on
> #aptosid@OFTC).

aptosid is just an example, I don't even know the distro, they may not
be the best choice, I just try to find alternates ideas. Note that I
don't think it takes more than 10 people to do the rolling distro like
Joss propose it: snapshot unstable every month and fix the worst
breakages. It takes more than 10 people to do the same in testing
because each individual fix is tangled in the migration issue, hence
rapidly needs to update things that are at first totally unrelated to be
fixed too first.
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.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/20110503130534.go...@madism.org



Integrating aptosid?

2011-05-03 Thread Lucas Nussbaum
On 03/05/11 at 13:31 +0200, Pierre Habouzit wrote:
> I've suggested integrating aptosid (or $derivative) people inside of
> Debian as a way to provide rolling, I know that Joss did so on planet
> too e.g. That has two very important advantages:
>   * it brings in new blood *now* (and not an hypothetical later) to
> actually take care of rolling (which doesn't make all my reservation
> moot but I reckon does lessen their scope significantly);
>   * it brings people who know how to do that and already have
> infrastructure to do so. We would just give them the opportunity to
> benefit from the larger and robust infrastructure we have, while
> taking their experience. Looks like it's win-win.
> They probably have good ideas on what could be improved in Debian to
> make their job easier, while *we* don't since we never tried.

It's not as simple as "let's integrate aptosid". There are at least two
sides to this:
- integrate the developers community in Debian. They are probably very
  nice etc, but:
  1) they are not currently Debian contributors (even if some of them
 might be)
  2) they might not adhere to Debian's values
  3) they decided to start a separate project, they might have good
 reasons to do it outside Debian
- integrate the technical processes inside Debian. We can't just add
  aptosid as a new Debian suite: that would be the worst solution
  (important overhead since Debian maintainers would have to care for
  unstable, testing and aptosid, then). So we need to work out solutions
  to reduce the overhead, and all the former discussion applies.

Also, FYI, the aptosid development team is composed of 8 to 10 developers,
contributing to different things at different levels (info gathered on
#aptosid@OFTC).

- Lucas


-- 
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/20110503124226.ga19...@xanadu.blop.info



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Lucas Nussbaum
On 03/05/11 at 13:31 +0200, Mehdi Dogguy wrote:
> On 03/05/2011 11:41, Lucas Nussbaum wrote:
> > It is clear from the discussion that there would be consequences. Some
> > would be negative, some positive. I think that we have now a pretty good
> > understanding of the possibilities and their consequences. The remaining
> > problem is to count DDs heads in the two camps:
> > - "Let's focus on stable releases. A rolling release should not be
> >provided officially by Debian."
> > - "Let's see what we can do about rolling, provided we find a way to do it
> >without diminishing the quality of our stable releases."
> > 
> 
> I hope my message will be clear here. But, I find your message quite
> subjective. Without reading your message or knowing your opinion on the
> subject, we can very easily guess that you prefer the second option.
> 
> I don't think that putting people in "camps" would resolve anything here.
> The first option is not about making it not officially provided by Debian,
> but there are people that are not convinced yet by the idea and some of
> them think that sacrificing stable for the sake of a hype is not a good
> idea especially with no evidence that it'll work. There are other
> arguments against and your two options really can't summarize all opinions
> and looks to me an easy way to diminish what has been said during all this
> thread.
> 
> And, no, I don't agree when you say "I think that we have now a pretty
> good understanding of the possibilities and their consequences". All this
> thread is about this issue particularly. We don't know yet the
> consequences that rolling would have on our stable releases. But, we can't
> simply adopt it without having any guarantee on its success. Because if it
> turns out that users still prefer $other, then we gained nothing but some
> burden within Debian and some bad consequences for Wheezy.

What kind of guarantees are you looking for, exactly? Can you suggest
ways to acquire them?

L.


-- 
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/20110503125405.gb19...@xanadu.blop.info



Re: Debian rolling: tentative summary

2011-05-03 Thread Lucas Nussbaum
On 03/05/11 at 13:38 +0200, sean finney wrote:
> Hi Lucas,
> 
> I appreciate your effort to try and sum things up.  However, I'd like
> to raise the point that the discussion was about more than just having a
> "rolling" and "user-oriented" testing release.
> 
> The feedback that started (or at least helped springboard) this massive
> thread was that "when we're releasing, everything else grinds to a halt,
> maybe it doesn't need to", followed by pondering whether there was a
> better way to manage this.  My initial proposal apparently smelled a bit
> like rolling, which got out people from both the pro- and con- rolling
> camps, and unfortunately it seems that a good deal of the discussion
> ended up splintering off in that direction.
> 
> While rolling may be one[1] way of addressing the freeze blockage, it's
> most likely not the only way to do so.  Over the weekend I took out a
> DEP to try and examine this underlying issue from a few different
> angles, including ideas that are rolling-like as well as aproaches that may
> be less so.

I think that one of the conclusions of the discussion from the last few
days is that the freeze "blockage" has very good features that many of
us are not willing to give up, like the ability to focus the DDs on
working on stable releases.

- Lucas


-- 
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/20110503125904.gc19...@xanadu.blop.info



Re: Reporting same bug in different packages

2011-05-03 Thread Amaya
Osamu Aoki wrote:
> On Mon, May 02, 2011 at 11:18:45PM +0200, Amaya wrote:
> > I guess I missed it (wonder how on earth...)
> 
> Because you looked at okular first.  

True :)

> okular uses libpoppler-qt4-3 which depends on libpoppler5.
> Even more convoluted for evince.

Absolutely!

-- 
 .''`.  Hate's no fun if you keep it to yourself
: :' : -- The life of David Gale
`. `'   
  `-Proudly running Debian GNU/Linux


-- 
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/20110503125849.GR3099@aenima



Re: need a server for debdelta repository

2011-05-03 Thread Alexander Wirt
A Mennucc schrieb am Tuesday, den 03. May 2011:

Hi, 

> the debdelta service is experiencing some problems.
> 
> There are two hosts involved: the first creates the deltas, and the
> second is a public http server 'bononia' that serves them (under a
> virtual host by the CNAME debdeltas.debian.net ).
> 
> Unfortunately, there is some strange problem, so that bononia is not
> correctly mirroring the delta repository... whole directories are
> missing (!); I noted this some time ago, I contacted the people who had
> setup the mirroring, but there was no answer.
> 
> What I am asking , as an emergency (and possible even temporary)
> solution, is a place where there are ~15GB of free disk space and an
> http server, so that I can transfer the repository of deltas there, and
> redirect 'debdeltas.debian.net' onto a virtual server at that place; and
> I would need an 'rsync' access so as to push new deltas (and delete
> old) when they are generated.
I should be able to give you shell access to one of my vm's
(mumble.snow-crash.org) if this is still needed. 

Alex


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



Re: Debian rolling: tentative summary

2011-05-03 Thread Martin Wuertele
* Cristian Henzel  [2011-05-03 10:51]:

> > Er, no. Those of us using Debian in corporate environments desire high
> > stability, long-term support and defined, not to short, periods between
> > releases. The 2 years with the security support for currently about 4
> > years from the release date on is good if even a bit on the short side.
> 
> I was just suggesting the shorter release cycles for stable thinking of the
> people that might want to run a stable release on newer hardware. Since I do 
> not
> run a corporate environment, I'm not familiar with the hardware that is 
> normally
> used nor with how much that hardware is supported by a 1-2 year old 
> distribution.

You either by a pool including spares with guaranteed 3/5/7 year
repleacements or you have exact hardware spec in the contract and
guaranteed supply for 3-5 years with thise specs and guaranteed
replacement guarantee for 3-7 years.

You don't want to have different hardware for 1+k users in 10+ countries
at 100+ locations with central administration wherever possible. Since
even several year old hardware is usually pretty fast enough for desktop
and local caching stuff you want too keep that running for 5-7 years
before starting a migration to the next generation of specs. In a
central facility there is one sample of each spec so you can do
debugging localy before rolling out changes.

In the data center side we heavily use virtualistion and the hardware
underneath is scheduled for a 3 to 5 year replacement schedule depending
on usage (with storage replacments on the lower end).

yours Martin


-- 
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/20110503123238.gi26...@anguilla.debian.or.at



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread sean finney
Hi Carsten,

A bit late on responding to your mails, but...

On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote:
> > > So if we tell users to use this repository, we're going to have
> > > some users (I upgrade my servers to testing during the freeze and I
> > > would enable it if it was generally advised for beta-testers).
> 
> The libpam-mount example was not a 100% fit because it went through
> testing-security and not through t-p-a.  The segfaulting package
> migrated to testing on the 28th of November 2008.  Just five months
> earlier the "Testing Security team" announced[1] on d-d-a that they
> provide nearly full security support (the kernel was missing at this
> time).

I'd say it's a very good fit for describing the type of problem; even if
it was t-s vs t-p-u, it's the same problem in terms of testing coverage.
Especially with software that's used in a wide variety of configurations
and environments, even what is seen as thorough review/testing on the
part of the maintainer could miss stuff like this.

> I doubt that generally advising to add t-p-a would significantly work
> out better than the testing-security announcement.

I'm thinking more and more that if we did do the "branch testing"
approach, it would need to be in tandem with changes to default
installation settings, "release upgrade" procedures, etc, to get more
people on board by default.

That said, I also think your discussion/suggestions regarding
"unstable-p-u" are really good.  While it may not necessarily
solve the "rolling" needs, it could solve the non-release standstill
issue by providing something more useful than experimental.

As you might or might not know, I took out DEP-10 over the weekend, to
explore different ways that we could parallelize the release management,
and plan to explore the details/problems/benefits of both of these ideas
(branch testing / unstable-p-u).  It would be awesome if I could get
some feedback/help from you along these lines.


sean


-- 
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/20110503120855.gb28...@cobija.connexer.com



Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope

2011-05-03 Thread Didier Raboud
Lucas Nussbaum wrote:

> Note that the alternatives are:
> - tag it 'sid'. But then, I would need to determine the root cause of
>   each FTBFS, and when the status of the FTBFS changes in testing.
> - do not tag it. But then, it would be seen as affecting stable.
> 
> What I would need is a way to express "It FTBFS in sid. I know it
> doesn't FTBFS in stable, I don't know about wheezy."

Wouldn't it be possible to introduce a "not-stable" or "not-in-squeeze" 
(better names welcome) tag for this purpose ?


-- 
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/ipoq8k$otp$1...@dough.gmane.org



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Josselin Mouette
Le lundi 02 mai 2011 à 16:19 -0700, Russ Allbery a écrit : 
> I realize that we're often not on the mailing lists jumping up and down
> and advocating for our issues, in part because Debian works great for us
> and not much needs to be changed, but please remember that there are a
> *lot* of us using Debian on servers in large-scale production
> environments.  And stable is our world.  It's EXTREMELY IMPORTANT.  It is,
> in many cases, the reason why we were able to sell Debian in the first
> place; if it weren't for Debian's exceptionally good stable releases, we
> would probably all be running Red Hat.

I fully concur.

And let me add that although it concerns less people, the same holds for
desktops.

-- 
Joss


--
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/1304423155.22032.244.camel@pi0307572



Re: Debian rolling: tentative summary

2011-05-03 Thread sean finney
Hi Lucas,

I appreciate your effort to try and sum things up.  However, I'd like
to raise the point that the discussion was about more than just having a
"rolling" and "user-oriented" testing release.

The feedback that started (or at least helped springboard) this massive
thread was that "when we're releasing, everything else grinds to a halt,
maybe it doesn't need to", followed by pondering whether there was a
better way to manage this.  My initial proposal apparently smelled a bit
like rolling, which got out people from both the pro- and con- rolling
camps, and unfortunately it seems that a good deal of the discussion
ended up splintering off in that direction.

While rolling may be one[1] way of addressing the freeze blockage, it's
most likely not the only way to do so.  Over the weekend I took out a
DEP to try and examine this underlying issue from a few different
angles, including ideas that are rolling-like as well as aproaches that may
be less so.


sean

[1] or, several, really, since there isn't just a single concrete rolling
implementation being proposed.


-- 
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/20110503113858.ga28...@cobija.connexer.com



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Mehdi Dogguy
On 03/05/2011 11:41, Lucas Nussbaum wrote:
> It is clear from the discussion that there would be consequences. Some
> would be negative, some positive. I think that we have now a pretty good
> understanding of the possibilities and their consequences. The remaining
> problem is to count DDs heads in the two camps:
> - "Let's focus on stable releases. A rolling release should not be
>provided officially by Debian."
> - "Let's see what we can do about rolling, provided we find a way to do it
>without diminishing the quality of our stable releases."
> 

I hope my message will be clear here. But, I find your message quite
subjective. Without reading your message or knowing your opinion on the
subject, we can very easily guess that you prefer the second option.

I don't think that putting people in "camps" would resolve anything here.
The first option is not about making it not officially provided by Debian,
but there are people that are not convinced yet by the idea and some of
them think that sacrificing stable for the sake of a hype is not a good
idea especially with no evidence that it'll work. There are other
arguments against and your two options really can't summarize all opinions
and looks to me an easy way to diminish what has been said during all this
thread.

And, no, I don't agree when you say "I think that we have now a pretty
good understanding of the possibilities and their consequences". All this
thread is about this issue particularly. We don't know yet the
consequences that rolling would have on our stable releases. But, we can't
simply adopt it without having any guarantee on its success. Because if it
turns out that users still prefer $other, then we gained nothing but some
burden within Debian and some bad consequences for Wheezy.

So, please do not use such simplistic conclusions.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,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/4dbfe7a5.60...@debian.org



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Pierre Habouzit
On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote:
> It is clear from the discussion that there would be consequences. Some
> would be negative, some positive. I think that we have now a pretty good
> understanding of the possibilities and their consequences. The remaining
> problem is to count DDs heads in the two camps:
> - "Let's focus on stable releases. A rolling release should not be
>provided officially by Debian."
> - "Let's see what we can do about rolling, provided we find a way to do it
>without diminishing the quality of our stable releases."

FWIW I'm in neither. My camp would be: Please do not impede our way to
produce stable releases in any ways, do whatever you want with rolling.

I've suggested integrating aptosid (or $derivative) people inside of
Debian as a way to provide rolling, I know that Joss did so on planet
too e.g. That has two very important advantages:
  * it brings in new blood *now* (and not an hypothetical later) to
actually take care of rolling (which doesn't make all my reservation
moot but I reckon does lessen their scope significantly);
  * it brings people who know how to do that and already have
infrastructure to do so. We would just give them the opportunity to
benefit from the larger and robust infrastructure we have, while
taking their experience. Looks like it's win-win.
They probably have good ideas on what could be improved in Debian to
make their job easier, while *we* don't since we never tried.

Just to say that your bipartisan view is a tad simplistic :)
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.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/20110503113123.gn...@madism.org



Re: Perl 5.12 transition in progress; uninstallable packages

2011-05-03 Thread Mehdi Dogguy
On 03/05/2011 12:02, Neil Williams wrote:
> 
> With such a large number of packages involved and the transition page
> being constructed from multiple dependency levels, is there a way of
> linking the transitions data from DDPO or having some other output
> which is organised on a per-developer / dd-list type layout?
> 

Considering the list of source packages available at [1]:

Daniel Leidert (dale) 
   openbabel (U)

Krzysztof Krzyzaniak (eloy) 
   libalias-perl (U)
   libastro-fits-cfitsio-perl (U)
   libcompress-raw-zlib-perl (U)
   libcrypt-des-perl (U)
   libdbd-sqlite2-perl (U)
   libhtml-parser-perl (U)
   libimage-librsvg-perl (U)
   liblist-moreutils-perl (U)
   libsearch-xapian-perl (U)
   libset-object-perl (U)
   libstring-crc32-perl (U)
   libterm-readline-gnu-perl (U)
   libtext-csv-xs-perl (U)
   libtime-piece-perl (U)

Krzysztof Krzyżaniak (eloy) 
   libcache-fastmmap-perl (U)
   libclass-c3-xs-perl (U)
   libclass-mop-perl (U)
   libcoro-perl (U)
   libdbd-mysql-perl (U)
   libdbd-pg-perl (U)
   libdbd-sqlite3-perl (U)
   libdevel-globaldestruction-perl (U)
   libfcgi-perl (U)
   libimager-perl (U)
   libipc-sharelite-perl (U)
   libjavascript-perl (U)
   libmoose-perl (U)
   libparams-validate-perl (U)
   libsub-current-perl (U)
   libsub-identify-perl (U)
   libsub-name-perl (U)
   libtokyocabinet-perl (U)
   libyaml-libyaml-perl (U)

Davide Puricelli (evo) 
   xchat

Felipe Augusto van de Wiel (faw) 
   eperl (U)
   wml (U)

Dario Minnucci (midget) 
   libalgorithm-permute-perl (U)

Loic Dachary (OuoU) 
   libtext-unaccent-perl

Stefan Hornburg (Racke) 
   courier
   mongodb-perl (U)
   safe-hole-perl

J.H.M. Dassen (Ray) 
   gnumeric

Ernesto Hernández-Novich (USB) 
   libdigest-jhash-perl (U)

Danai SAE-HAN (韓達耐) 
   libunicode-collate-perl (U)

Angel Abad 
   libautobox-perl (U)
   libclass-mop-perl (U)
   libdata-dump-streamer-perl (U)
   libdate-pcalc-perl (U)
   libindirect-perl (U)
   libjson-xs-perl (U)
   libscalar-string-perl (U)
   libvariable-magic-perl (U)

Russ Allbery 
   libafs-perl
   libauthen-krb5-admin-perl (U)
   libauthen-krb5-perl (U)
   libauthen-sasl-cyrus-perl (U)
   libheimdal-kadm5-perl
   libnet-ldapapi-perl (U)
   openldap (U)
   remctl
   webauth

Thomas Anders 
   net-snmp (U)

Micah Anderson 
   libcrypt-openssl-x509-perl (U)
   silc-client (U)

Stuart R. Anderson 
   ming

Don Armstrong 
   libimage-imlib2-perl
   libthreads-perl
   libthreads-shared-perl

maximilian attems 
   linux-2.6 (U)

Ernesto Nadir Crespo Avila 
   flow-tools (U)

Nicholas Bamber 
   libapache2-mod-perl2 (U)
   libclass-xsaccessor-perl (U)
   libcompress-raw-zlib-perl (U)
   libdatetime-perl (U)
   libdbd-mysql-perl (U)
   libdbd-odbc-perl (U)
   libdbi-perl (U)
   libdevel-bt-perl (U)
   libdevel-cover-perl (U)
   libdevel-nytprof-perl (U)
   libdevel-size-perl (U)
   libencode-hanextra-perl (U)
   libencode-jis2k-perl (U)
   libfile-spec-perl (U)
   libhtml-parser-perl (U)
   libhtml-template-pro-perl (U)
   libimager-perl (U)
   libio-aio-perl (U)
   libjavascript-minifier-xs-perl (U)
   libjavascript-perl (U)
   libjson-xs-perl (U)
   libnetaddr-ip-perl (U)
   libparams-validate-perl (U)
   libquota-perl (U)
   libsgml-parser-opensp-perl (U)
   libsocket-getaddrinfo-perl (U)
   libsub-prototype-perl (U)
   libxml-sax-expatxs-perl (U)
   libyaml-syck-perl (U)

Michael Banck 
   openbabel (U)

Jack Bates 
   libnet-dbus-perl

Roland Bauerschmidt 
   openldap (U)

Romain Beauxis 
   libfuse-perl

Axel Beckert 
   eperl (U)
   wml (U)

Dave Beckett 
   redland-bindings

Luciano Bello 
   imagemagick (U)

Hilko Bengen 
   hivex
   libsendmail-milter-perl

Christoph Berg 
   cyrus-imapd-2.2 (U)
   cyrus-imapd-2.4 (U)

Jay Berkenbilt 
   libxml-xerces-perl

Edward Betts 
   libdate-simple-perl (U)

Olly Betts 
   libsearch-xapian-perl (U)

Bastian Blank 
   libfile-spec-perl (U)
   libperlio-eol-perl
   linux-2.6 (U)
   redhat-cluster (U)

Jérémy Bobbio 
   silc-client (U)

Salvatore Bonaccorso 
   libclass-mop-perl (U)
   libcrypt-openssl-x509-perl (U)
   libdbd-sqlite3-perl (U)
   libdigest-sha-perl (U)
   libgtk2-perl (U)
   libmath-gmp-perl (U)
   libmoose-perl (U)
   libsearch-xapian-perl (U)
   libsys-virt-perl (U)
   libwww-curl-perl (U)

Salvatore Bonaccorso 
   libbsd-resource-perl (U)
   libdate-calc-perl (U)
   libforks-perl (U)
   libhtml-parser-perl (U)
   libmath-random-mt-perl (U)
   libnet-ssh2-perl (U)
   libpadwalker-perl (U)
   libposix-strptime-perl (U)
   libscalar-list-utils-perl (U)
   libtime-piece-perl (U)

Jay Bonci 
   libclass-date-perl (U)
   libcurses-perl (U)
   libdigest-md4-perl (U)
   libimager-perl (U)
   libipc-sharelite-perl (U)
   libparams-validate-perl (U)

Alan Boudreault 
   mapserver (U)

Emmanuel Bouthenot 
   weechat

Michael Bramer 
   liblinux-inotify2-perl

Joachim Breitner 
   libalias-perl (U)
   libastro-fits-cfitsio-perl (U)
   libfile-sync-perl (U)

David Bremner 
   highlight (U)

Marc 'HE' Brockschmidt 
   libastro-fits-cfits

Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Bernd Zeimetz
On 05/03/2011 12:09 PM, Didier Raboud wrote:
> Sandro Tosi wrote:
> 
>> Who do you expect to send such communication? the gcc maintainer? good
>> luck with that.
> 
> Do we really need that type of public bashing on -devel ? Your gripes with 
> Matthias are notorious enough to avoid the need to repeat them all over the 
> place, IHMO.

While we don't need this kind of bashing, the issue needs to be fixed
somehow, indeed.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 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/4dbfdd59.3030...@bzed.de



Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Didier Raboud
Sandro Tosi wrote:

> Who do you expect to send such communication? the gcc maintainer? good
> luck with that.

Do we really need that type of public bashing on -devel ? Your gripes with 
Matthias are notorious enough to avoid the need to repeat them all over the 
place, IHMO.


-- 
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/ipok8n$odb$1...@dough.gmane.org



Re: Perl 5.12 transition in progress; uninstallable packages

2011-05-03 Thread Neil Williams
On Tue, 3 May 2011 10:21:09 +0100
Dominic Hargreaves  wrote:

> Hi all,
> 
> On Sunday, in collaboration with the release team, I uploaded
> perl 5.12-6 to unstable. This necessarily causes around 400 packages
> to be uninstallable with the new perl. The release team will be
> scheduling binNMUs in due course; in the meantime, if you find such a
> package, there is no need to report a bug against it. The rebuilds will
> take a little time, so please be patient in the meantime.
> 
> The list of affected packages is available at
> 
> 

With such a large number of packages involved and the transition page
being constructed from multiple dependency levels, is there a way of
linking the transitions data from DDPO or having some other output
which is organised on a per-developer / dd-list type layout?

Even if it just results in the package names per-developer as a
separate page consisting of static list of links back to the transition
page for that package, it would help.

-- 


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



pgpGRRyIgUQjK.pgp
Description: PGP signature


Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Lucas Nussbaum
On 02/05/11 at 16:19 -0700, Russ Allbery wrote:
> Lucas Nussbaum  writes:
> 
> > [ Note that my position is based on the assumption that we have a share
> > of DDs interested in rolling similar to the share of DDs interested in
> > stable releases. Unfortunately, it's very difficult to know where we
> > stand regarding this. ]
> 
> I'm very dubious.  To take one example, if Debian stopped making stable
> releases, it would no longer be usable at work, which would mean that my
> ability to work in Debian would substantially decrease and quite possibly
> go away completely.

Except for the sake of argumentation, I don't think that anybody
considers seriously that Debian would stop making stable releases.
The question is whether we want to provide a rolling release in addition
to our stable releases.

> I realize that we're often not on the mailing lists jumping up and down
> and advocating for our issues, in part because Debian works great for us
> and not much needs to be changed, but please remember that there are a
> *lot* of us using Debian on servers in large-scale production
> environments.  And stable is our world.  It's EXTREMELY IMPORTANT.  It is,
> in many cases, the reason why we were able to sell Debian in the first
> place; if it weren't for Debian's exceptionally good stable releases, we
> would probably all be running Red Hat.
> 
> I went on about this at some length at the last DebConf as part of the
> enterprise track.

I assume that when you write 'us' or 'we' here, you mean 'Debian users
in large-scale production environments'. Again, I'm not diminishing the
importance of stable releases. But I've always found it strange that, as
a volunteer project, we are creating a product that is mainly used in
professional environments.

I think that the key information missing in this thread is simply:
| Do DDs want to consider the possibility to create a 'rolling release'
| product?

It is clear from the discussion that there would be consequences. Some
would be negative, some positive. I think that we have now a pretty good
understanding of the possibilities and their consequences. The remaining
problem is to count DDs heads in the two camps:
- "Let's focus on stable releases. A rolling release should not be
   provided officially by Debian."
- "Let's see what we can do about rolling, provided we find a way to do it
   without diminishing the quality of our stable releases."

 - Lucas


-- 
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/20110503094135.ga15...@xanadu.blop.info



Perl 5.12 transition in progress; uninstallable packages

2011-05-03 Thread Dominic Hargreaves
Hi all,

On Sunday, in collaboration with the release team, I uploaded
perl 5.12-6 to unstable. This necessarily causes around 400 packages
to be uninstallable with the new perl. The release team will be
scheduling binNMUs in due course; in the meantime, if you find such a
package, there is no need to report a bug against it. The rebuilds will
take a little time, so please be patient in the meantime.

The list of affected packages is available at


and more information about the transition is at


Thanks,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


-- 
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/20110503092109.gh4...@urchin.earth.li



Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Sandro Tosi
On Tue, May 3, 2011 at 11:32, Charles Plessy  wrote:
> However, given my experience of repetitive patching cycles with earlier GCC
> updates, it would be pointless to spend a lot of energy updating our packages
> now if it is only to realise in few weeks that the next GCC update would
> require yet another header.
>
> So can we have some perspectives and gross time frame, sent on
> debian-devel-announce@l.d.o, that we could also use as a reference when we 
> will
> forward the issue to our upstreams ?  For the packages I maintain, I would
> prefer to see – and help – these bugs fixed by new upstream release rather 
> than
> by patch.

Who do you expect to send such communication? the gcc maintainer? good
luck with that.

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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



Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)

2011-05-03 Thread Charles Plessy
Dear Lucas and everybody,

the recent archive rebuild uncovered a large number of GCC 4.6 build failures
(that could been already forseen from Launchpad).  In the long run, I find very
impressive the contribution from the major Linux distribution to their upstreams
for keeping them up to date with recent toolchains.

However, given my experience of repetitive patching cycles with earlier GCC
updates, it would be pointless to spend a lot of energy updating our packages
now if it is only to realise in few weeks that the next GCC update would
require yet another header.

So can we have some perspectives and gross time frame, sent on
debian-devel-announce@l.d.o, that we could also use as a reference when we will
forward the issue to our upstreams ?  For the packages I maintain, I would
prefer to see – and help – these bugs fixed by new upstream release rather than
by patch.

Have a nice day,

-- 
Charles Plessy
Illkirch-Graffenstaden, Alsace, France


-- 
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/20110503093212.gb12...@merveille.plessy.net



need a server for debdelta repository

2011-05-03 Thread A Mennucc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi there,

the debdelta service is experiencing some problems.

There are two hosts involved: the first creates the deltas, and the
second is a public http server 'bononia' that serves them (under a
virtual host by the CNAME debdeltas.debian.net ).

Unfortunately, there is some strange problem, so that bononia is not
correctly mirroring the delta repository... whole directories are
missing (!); I noted this some time ago, I contacted the people who had
setup the mirroring, but there was no answer.

What I am asking , as an emergency (and possible even temporary)
solution, is a place where there are ~15GB of free disk space and an
http server, so that I can transfer the repository of deltas there, and
redirect 'debdeltas.debian.net' onto a virtual server at that place; and
I would need an 'rsync' access so as to push new deltas (and delete
old) when they are generated.

TIA

a.

ps: I don't know exactly how much traffic deltas generate, I never had
a change at looking at the bononia logs.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2/wb8ACgkQ9B/tjjP8QKQEsgCeIBxEtFaGhUaNbFMRf8GJnxyN
7OsAn1k9vngEnCtAswj1UmckWRrq/j2+
=pzt4
-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/4dbfc1c1.8020...@debian.org



Re: Debian rolling: tentative summary

2011-05-03 Thread Milan P. Stanic
On Tue, 2011-05-03 at 09:47, Martin Wuertele wrote:
> * Cristian Henzel  [2011-05-03 08:12]:
> > I'm a bit new to Debian but just wanted to add my $0.02 to this discussion,
> > since it's something that I personally find very interesting.
> > Firstly, I think the question should be, "which users would be targeted by a
> > rolling release?" I don't think there are many people out who have the need 
> > for
> > *both* really stable and supported *and* up-to-date packages and this might 
> > not
> > even be possible without a huge team to work on it. IMHO the rolling release
> > should be targeted at people who want the latest stuff but don't care that 
> > much
> > about stability.
> > I had a quick talk on this with a couple of people on IRC where I suggested
> > starting with a 'clone' of the testing repository, and changing a couple of 
> > the
> > rules, like not having a freeze for example and maybe increasing the time it
> > takes packages to 'promote' from unstable into rolling. This might not make 
> > the
> > most stable configuration but I think it would be a good compromise between
> > having the latest packages and not having any really serious bugs. I for one
> > would only dislike bugs that cause a data loss or a non-operable system, and
> > from what I know these are pretty rare even in testing.
> > If it then would be also possible to decrease the release time of stable to
> > something around a year, I think this might make everyone happy, both the
> > 'stability freaks' and the average Joe.
> 
> Er, no. Those of us using Debian in corporate environments desire high
> stability, long-term support and defined, not to short, periods between
> releases. The 2 years with the security support for currently about 4
> years from the release date on is good if even a bit on the short side.

I agree. Debian shouldn't become yet another Ubuntu.

I converted all my servers to Debian stable and workstations to
testing/unstable thirteen years ago and I don't regret.

I don't think that the Debian can beat Ubuntu in popularity on
desktop/laptop field (not yet) and IMHO it should not even try that.

IMHO Debian is for the people who understand computers and are willing
to invest some time to learn and "user friendly" distributions are for
other more or less laymen people.

-- 
Kind regards,  Milan


-- 
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/20110503083301.ga13...@arvanta.net



Re: Re: Debian rolling: tentative summary

2011-05-03 Thread Cristian Henzel
> Er, no. Those of us using Debian in corporate environments desire high
> stability, long-term support and defined, not to short, periods between
> releases. The 2 years with the security support for currently about 4
> years from the release date on is good if even a bit on the short side.

I was just suggesting the shorter release cycles for stable thinking of the
people that might want to run a stable release on newer hardware. Since I do not
run a corporate environment, I'm not familiar with the hardware that is normally
used nor with how much that hardware is supported by a 1-2 year old 
distribution.


-- 

Best regards,
Mit freundlichen Grüßen,

Cristian Henzel


-- 
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/4dbfbce5.2050...@b3r3.info



Re: Debian rolling: tentative summary

2011-05-03 Thread Martin Wuertele
* Cristian Henzel  [2011-05-03 08:12]:

> I'm a bit new to Debian but just wanted to add my $0.02 to this discussion,
> since it's something that I personally find very interesting.
> Firstly, I think the question should be, "which users would be targeted by a
> rolling release?" I don't think there are many people out who have the need 
> for
> *both* really stable and supported *and* up-to-date packages and this might 
> not
> even be possible without a huge team to work on it. IMHO the rolling release
> should be targeted at people who want the latest stuff but don't care that 
> much
> about stability.
> I had a quick talk on this with a couple of people on IRC where I suggested
> starting with a 'clone' of the testing repository, and changing a couple of 
> the
> rules, like not having a freeze for example and maybe increasing the time it
> takes packages to 'promote' from unstable into rolling. This might not make 
> the
> most stable configuration but I think it would be a good compromise between
> having the latest packages and not having any really serious bugs. I for one
> would only dislike bugs that cause a data loss or a non-operable system, and
> from what I know these are pretty rare even in testing.
> If it then would be also possible to decrease the release time of stable to
> something around a year, I think this might make everyone happy, both the
> 'stability freaks' and the average Joe.

Er, no. Those of us using Debian in corporate environments desire high
stability, long-term support and defined, not to short, periods between
releases. The 2 years with the security support for currently about 4
years from the release date on is good if even a bit on the short side.

yours Martin


-- 
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/20110503074731.gh26...@anguilla.debian.or.at



Re: Bits from the Release Team - Kicking off Wheezy

2011-05-03 Thread Martin Wuertele
* Russ Allbery  [2011-05-03 01:20]:

> Lucas Nussbaum  writes:
> 
> > [ Note that my position is based on the assumption that we have a share
> > of DDs interested in rolling similar to the share of DDs interested in
> > stable releases. Unfortunately, it's very difficult to know where we
> > stand regarding this. ]
> 
> I'm very dubious.  To take one example, if Debian stopped making stable
> releases, it would no longer be usable at work, which would mean that my
> ability to work in Debian would substantially decrease and quite possibly
> go away completely.
> 
> I realize that we're often not on the mailing lists jumping up and down
> and advocating for our issues, in part because Debian works great for us
> and not much needs to be changed, but please remember that there are a
> *lot* of us using Debian on servers in large-scale production
> environments.  And stable is our world.  It's EXTREMELY IMPORTANT.  It is,
> in many cases, the reason why we were able to sell Debian in the first
> place; if it weren't for Debian's exceptionally good stable releases, we
> would probably all be running Red Hat.
> 
> I went on about this at some length at the last DebConf as part of the
> enterprise track.

+100 on this one.

yours Martin


-- 
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/20110503074025.gg26...@anguilla.debian.or.at



Primul top cu produse de top la preturi de top

2011-05-03 Thread TopulReducerilor
TopulReducerilor.com - un top cu produse de top la preturi de top! -  
http://www.topulreducerilor.com