Re: Bits from the Release Team - Kicking off Wheezy

[Mehdi Dogguy]

On 05/02/2011 12:10 AM, Lucas Nussbaum wrote:
> On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote:
>>> Benefits for Debian:
>>> - attract users who think that testing is only a development branch, and
>>>   want newer software than what one finds in stable. Those users are
>>>   likely to be rather advanced users (developers, free software
>>>   contributors), thus interesting to work with. Some of them could
>>>   become Debian contributors. And even if they don't, more users of
>>>   testing/rolling means more testers of the next stable release
>>>   [remember how the bug reporting rate of Ubuntu is higher than
>>>   Debian's -- some areas of Debian could use more testers].
>>
>>
>> I think those can use unstable,
> 
> But unstable is a development branch not targeted at being used by
> 'standard' users.
> 

I can also say exactly the same about testing ;) I don't think we can go
too far with this argument.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.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/4dbe55f1.9070...@dogguy.org

Re: Bits from the Release Team - Kicking off Wheezy

[Marc 'HE' Brockschmidt]

Hai!

Pierre Habouzit  writes:
> On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote:
>> Size is just one ingredient. There are plenty of other ways to diminish
>> barrier to deploy big changes in Debian: wider commit access rights,
>> larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly,
>> several Debian derivatives have decide to pursue those other ways and
>> one might argue that they have done so learning from Debian experience.)
>
> [...]
>
> Oh yes, you really want to "attract" new contributors ? build debhub.com
> (as in github) and force everyone to package stuff in there.

Ehm, forcing people to use a certain VCS is usually a good way to _lose_
contributors...

>   - PPA should focus on:
>   * co-installability when endurable;
>   * documented and working rollback to unstable (IOW downgrading a
> package to unstable when co-installability is not possible
> should work well enough, idealy using pinning and apt, but a
> documented procedure is good enough too).

Wait, that's a completely orthogonal problem. Rollbacks of package
upgrades is unsupported generally, trying to solve this at the same time
as the PPA issue is a bad idea. There's no reason to connect these
things.

Marc


pgpbX0AFHhhF9.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Marc 'HE' Brockschmidt]

Heya,

Raphael Hertzog  writes:
> I understand members of the release team feel particularly responsible to
> do various release-critical tasks that should have been done by the
> maintainers but haven't (for various reasons). And I guess that's the
> reason of your remark.
>
> But that's not scalable ultimately. So I think it's a good move to say
> we support testing and we expect every maintainer to take care of their
> packages there (as opposed to the current situation where too much of that
> work is left in the hands of the release team).

Saying that will not make people do it. We have also said that "we will
fix bugs in a frozen testing distribution", but that doesn't mean that
everyone does it. Raphael, just announcing that something should be done
doesn't get stuff done.

Marc


pgpz8I8A4urVI.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Pierre Habouzit]

On Mon, May 02, 2011 at 09:13:31AM +0200, Marc 'HE' Brockschmidt wrote:
> Hai!
> 
> Pierre Habouzit  writes:
> > On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote:
> >> Size is just one ingredient. There are plenty of other ways to diminish
> >> barrier to deploy big changes in Debian: wider commit access rights,
> >> larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly,
> >> several Debian derivatives have decide to pursue those other ways and
> >> one might argue that they have done so learning from Debian experience.)
> >
> > [...]
> >
> > Oh yes, you really want to "attract" new contributors ? build debhub.com
> > (as in github) and force everyone to package stuff in there.
> 
> Ehm, forcing people to use a certain VCS is usually a good way to _lose_
> contributors...

I'm not forcing the use of the VCS, more like some infrastructure to
host packages if you want, during the development, so that it's easier
to track, and not in its source-only form as what matters to users is
actually the binary form. Which is missing nowadays.

And I disagree, we may lose a few, but it can improve efficiency making
it a stable operation, and I think having more standardized ways to look
at packages and contribute to the packaging will lower the entry to
help. But to be fair, this was an idea I developped in a bout 2 hours of
time, it's bound to have deficiencies :)


-- 
·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/20110502071650.ga23...@madism.org

Re: Bits from the Release Team - Kicking off Wheezy

[Lucas Nussbaum]

On 02/05/11 at 08:19 +0200, Pierre Habouzit wrote:
> On Mon, May 02, 2011 at 12:10:42AM +0200, Lucas Nussbaum wrote:
> > On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote:
> > > > Benefits for Debian:
> > > > - attract users who think that testing is only a development branch, and
> > > >   want newer software than what one finds in stable. Those users are
> > > >   likely to be rather advanced users (developers, free software
> > > >   contributors), thus interesting to work with. Some of them could
> > > >   become Debian contributors. And even if they don't, more users of
> > > >   testing/rolling means more testers of the next stable release
> > > >   [remember how the bug reporting rate of Ubuntu is higher than
> > > >   Debian's -- some areas of Debian could use more testers].
> > > 
> > > 
> > > I think those can use unstable,
> > 
> > But unstable is a development branch not targeted at being used by
> > 'standard' users.
> 
> Well, assuming it's the case, what is missing in order to be usable by
> "mere" users?

IMHO, what is missing for unstable to be usable for mere users is what
the unstable->testing migrations provides: a maturation period that
allows severe bugs to be catched before they hit most users.

> Also note that testing as is has not enough security support, and read
> Carsten very good example of the PAM issues. How would CUT or rolling
> address those?

The PAM issue outlines how splitting the users and developers between
two branches (unstable and testing post-freeze in the PAM case) causes
problems.

However, we can make rolling without splitting the users and developers
between two branches during the whole freeze.

'rolling' is a statement by the project that we consider 'testing'
(renamed to 'rolling') to be usable by 'mere' users who want more
up-to-date software than what they find in our stable releases, or in
our derivatives.

'rolling' would be very similar to what we have in 'testing'. Yes, users
can already use testing or unstable, but then they have the reasonable
feeling that they are using a development branch and not something that
the project considers a 'product'.

Yes, it's mostly "PR bullshit", and I don't expect it to significantly
change Debian development processes. However, communication is necessary
if we want to attract new users. What might change is more attention
from developers to what happens in testing/rolling, which is probably a
good thing since a better testing/rolling makes it easier to create
stable releases from it.

Then, there's the discussion of what to do during freezes. There are
several options:
[A] we could decide not to do anything special: just freeze rolling for
~6 months, as we used to freeze testing. That might bore people who
like the constant flux of new upstream releases, but if we decide
that it's the only way to ensure high-quality stable releases, so be
it.
[B] we could decide to fork a 'frozen' branch when we freeze, and
continue to manage rolling using migrations from unstable. This clearly
makes it harder to create stable releases, since it splits the users
and developers base between two branches (less users => less bug
reports ; less developers => less bug fixing). It doesn't sound
reasonable to fork a 'frozen' branch, and then try to release it for
6 months.
[C] we could compromise. We could freeze rolling for 3 months, so that
most of the stabilization work occurs with a single active branch,
and then, for the final release preparation, fork 'frozen' off
'rolling', and unfreeze 'rolling'.

> I've used testing in the past, in the sarge era. I had to constantly
> install packages from unstable for it to work, and the result was a
> nightmare of apt-get installability. I've not used testing since, so
> /maybe/ it's better nowadays, I'd very much like to have some feedback
> from real and recent testing users if there are any, but if I trust my
> past experience, the gap to make testing usable is significant. So maybe
> making unstable usable isn't *that* much more significant, and is
> definitely more compatible with our current workflow.

I'm using testing, and don't share your views. But YMMV.  It's also
possible that the introduction of 'rolling' will result in slight
changes to the way we manage testing. For example, the 2/5/10 delays for
testing migrations are mostly arbitrary. It could make sense to refine
them on a case-by-case basis. The goal of those changes would be to
increase the usability of testing. I don't see any wrong with that.

> > > and if they use rolling, I think I
> > > already "proved" or at least explained why those don't contribute to the
> > > stable in being, but rather the N+1 one.
> > 
> > I think that you are mixing two things here:
> > 1) whether we want to turn testing into a rolling release
> > 2) what do do with the 'rolling' suite during freeze (fork a 'frozen'
> >   branch at the beginning of the freeze ? freeze rolling ? start by

Re: Bits from the Release Team - Kicking off Wheezy

[Bernhard R. Link]

* Pierre Habouzit  [110501 22:09]:
> Who are they? Unlike this constant handwaving, I've shared my experience
> (on #-devel), I'll repeat it here: at work we've like 10 Debian users,
> some with stable, the other with unstable. Why? Because we're
> developpers and if our software targets old stuff (RH5, it's as old as
> lenny), the latest gcc, valgrind, … are priceless tools, and we want
> them.

Also think about people that actually want to computer to work and
people administrating their computers. You do not hear much from those
users as Debian in its current shape in near to perfect for them.
It releases often enough that one has new software, not so often that
one can manage upgrades in the time (and users can adapt to changes,
anything changed is usually a big hassle for users). There is one
repository with all the packages, no hunting for sources, no evaluation
which of those sources have use usefull packages and which are crap,
and everything fits well together. And in the rare event something
newer is needed and one cannot wait one can get something from backports
and it still reasonably well fits together.

> I run unstable on my laptop and workstation for years, with almost daily
> dist-upgrades. Except for grub2 (and I've been stupid, I removed grub, I
> should have known better) I've had no serious issues for 5 years,

Agreed. Unstable is usually quite stable.

Bernhard R. Link


-- 
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/20110502072557.ga18...@pcpool00.mathematik.uni-freiburg.de

Re: Bits from the Release Team - Kicking off Wheezy

[Pierre Habouzit]

On Mon, May 02, 2011 at 09:20:29AM +0200, Lucas Nussbaum wrote:
> Yes, it's mostly "PR bullshit", and I don't expect it to significantly
> change Debian development processes. However, communication is necessary
> if we want to attract new users. What might change is more attention
> from developers to what happens in testing/rolling, which is probably a
> good thing since a better testing/rolling makes it easier to create
> stable releases from it.

Is that it, really? What's the point of the rename, forcing all the
testing users to sed their sources.list? Wow. Useful.

> [C] we could compromise. We could freeze rolling for 3 months, so that
> most of the stabilization work occurs with a single active branch,
> and then, for the final release preparation, fork 'frozen' off
> 'rolling', and unfreeze 'rolling'.

That's horrible to do because the end of the freeze is *exactly* when
people get demotivated, and that the last rush is mostly done by very
few people.

Doing that will make them feel even more alone, which is a great way to
burn them out even faster. I really don't like it.  I'd rather see ways
on how to make the freeze shorter been explored instead.

-- 
·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/20110502073027.gb23...@madism.org

Re: Bits from the Release Team - Kicking off Wheezy

[Lucas Nussbaum]

On 02/05/11 at 09:30 +0200, Pierre Habouzit wrote:
> On Mon, May 02, 2011 at 09:20:29AM +0200, Lucas Nussbaum wrote:
> > Yes, it's mostly "PR bullshit", and I don't expect it to significantly
> > change Debian development processes. However, communication is necessary
> > if we want to attract new users. What might change is more attention
> > from developers to what happens in testing/rolling, which is probably a
> > good thing since a better testing/rolling makes it easier to create
> > stable releases from it.
> 
> Is that it, really? What's the point of the rename, forcing all the
> testing users to sed their sources.list? Wow. Useful.

I'm sorry if you don't understand the interest of communication.
And of course, we would keep a testing->rolling symlink to avoid breaking
the world...

> > [C] we could compromise. We could freeze rolling for 3 months, so that
> > most of the stabilization work occurs with a single active branch,
> > and then, for the final release preparation, fork 'frozen' off
> > 'rolling', and unfreeze 'rolling'.
> 
> That's horrible to do because the end of the freeze is *exactly* when
> people get demotivated, and that the last rush is mostly done by very
> few people.

Isn't it partially done by very few people because the work doesn't
scale to many developers?
Anyway, the message that should be sent during the end of the freeze is:
The good thing to do is to help with the release. If you tried that, and
really cannot help anymore, then of course you are free to work on other
things, including rolling.

> Doing that will make them feel even more alone, which is a great way to
> burn them out even faster. I really don't like it.  I'd rather see ways
> on how to make the freeze shorter been explored instead.

Why would it be mutually exclusive? We could explore ways to make the
freeze shorter, and at the same time do rolling.

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/20110502074811.ga14...@xanadu.blop.info

Re: Crypto consolidation in debian ?

[Josselin Mouette]

Le dimanche 01 mai 2011 à 14:08 +0100, Roger Leigh a écrit : 
> This is something I can understand to an extent.  Having a single
> service providing access to the NSS databases would offer some
> advantages.  Unfortunately, I've only ever heard bad things about
> nscd.  If we could move to having a central service, rather than
> having every process load in a pile of extra libraries, I would
> probably be in favour of it.  If would make some things, such as
> NSS queries inside chroots, much more efficient and robust.
> 
> However... that's not the reality right now, and it never has been.

Ever heard of sssd?

I’m asking, because it does precisely the kind of things you are looking
for.

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


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

Wth "rolling"? (was: Bits from the Release Team - Kicking off Wheezy)

[Joerg Jaspert]

Hi

Picking one piece that really leaves me "WTF?" out of this
way-too-long-thread. Happens to be a post by Lucas, but could be anyone
else too.

> 'rolling' is a statement by the project that we consider 'testing'
> (renamed to 'rolling')

Why the heck do we start by renaming testing? This will seriously
disrupt service for anyone for DAYS. There are just too many places
tools are using "testing" hardcoded. Too many users having that in
sources.list. Too many things assuming there is "stable, testing,
unstable". And all of them would suddenly, out of nothing, have broken
systems and need to fix them.

If somehow rules for testing get changed (to be whatever rolling wants
to be), fine. Thats one thing.

But for what reason change the name? That's worse PR than usually
done by politicians, and they generally do the things noone with a brain
ever does. So why?

> Yes, it's mostly "PR bullshit", and I don't expect it to significantly
> change Debian development processes.

Then don't start with a change that WILL interrupt Debian development
for days, if not longer.

> However, communication is necessary if we want to attract new
> users.

Communication can be done now too, no need to change anything (besides
the pr foo) for this.




(From what I was able to follow in this mass attack of mails is, that
the best to do right now would be to regularly "release" testing into a
new suite, whatever it is named (including something of "beta" or
"alpha"). Those releases would come with a full d-i for that
suite, every other month. Or so. Updates to that suite go via testing,
as long as it works, or via a -p-u like thing later. Support for those
suites, from the team who wants to do it, is given "X months or til next
release, whichever is earlier". The exact way how packages move there,
how often its done, etc. need to be laid out in detail, but that scheme
would actually be simple to support from FTPMaster. EVEN if we would go
to have two new suites (one testing-1, one testing-2, to keep it around
a little longer. If thats a good idea, dont know). Main point still
would be "If there is someone doing the work for it.", like the release
team now does for testing. Coordinating a good package list, a d-i that
works, etc. is not a small amount to do.)

-- 
bye, Joerg
[Talking about Social Contract]:
We will not discriminate noone[...]
[So we discriminate anyone?]


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

Re: Bits from the Release Team - Kicking off Wheezy

[Martin Zobel-Helas]

Hi, 

On Sun May 01, 2011 at 21:53:58 +0200, Lucas Nussbaum wrote:
> On 01/05/11 at 20:51 +0200, Martin Zobel-Helas wrote:
> > Hi, 
> > 
> > On Sun May 01, 2011 at 20:02:51 +0200, Lucas Nussbaum wrote:
> > > 2. determine who is in support of each action plan, through a GR or a
> > > poll.
> > 
> > I don't think we need a GR for that. Those who are interested in rolling
> > releases could show that they are interested and just doing so (like
> > Norbert/formorer/Rhona/...  did with backports, like Joey Hess did with
> > testing-security, like Andi and me did with volatile, ...).
> > 
> > I am aware this might need changes in some of Debian's infrastructure,
> > but i am quite sure if you provide help/patches/... those will be
> > implemented.
> 
> I don't see how that could work.
> Iet's assume that the goal is to demonstrate the interest in the "rename
> testing to rolling" scenario, without even talking about what to do during
> freezes.
> 
> The first steps of the implementation will include:
> - rename testing to rolling. I don't see how ftpmasters would do it
>   without a consensus that this is something wanted by the project.
> - communicate officially, to the general public, that rolling is not
>   only a development branch, but also suited for use by the general
>   public (given known limitations). I don't see how the press team would
>   publish something like that without a consensus that it's what the
>   project thinks.
> 
> What was applicable for backports, testing-security or volatile is not
> applicable here, because the implications for the project are deeper.
> It's not about adding a suite with some different packages in the
> margin. It's about shifting developers' focus and user attention a bit.

No, it just needs that rolling is running on a different dak instance as
testing. The same we had for volatile, the same we had for backports.
The team (whoever that is) wo is interested in the rolling releases can
show it is worth the effort, then we can start thinking integrating it
back into the main archive.


Cheers,
Martin
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 GPG key http://go.debian.net/B11B627B  | 
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
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/20110502083130.gd13...@ftbfs.de

Re: Bits from the Release Team - Kicking off Wheezy

[Martin Bagge / brother]

On Sun, 1 May 2011, Stefano Zacchiroli wrote:
> weren't there. But as a matter of fact, chances are that those people
> wouldn't have been able to be Debian Developers today if it weren't
> for the GR.

As I was the very first to apply under the GR (not in the first batch of
accepts though) I just wanted to underline the truth in this.

I wouldn't have been on the line for applying for DD for years to come.
I most probably would have stayed with the project anyhow but the
membership couples me tighter to Debian now. I am more interested in
doing things for Debian now than before, and given that I have been
running mirrors for both FTP and debconf video streams since 2004 and
been a active contributor for the translations since 2007 (let's not
even count the time spent on advocacy for the project), the GR was a
warm fuzzy feeling of out reach and I like it.

-- 
brother
http://sis.bthstudent.se


-- 
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/4dbe70d6.3070...@bsnet.se

Re: Wth "rolling"? (was: Bits from the Release Team - Kicking off Wheezy)

[Lucas Nussbaum]

On 02/05/11 at 10:12 +0200, Joerg Jaspert wrote:
> Hi
> 
> Picking one piece that really leaves me "WTF?" out of this
> way-too-long-thread. Happens to be a post by Lucas, but could be anyone
> else too.
> 
> > 'rolling' is a statement by the project that we consider 'testing'
> > (renamed to 'rolling')
> 
> Why the heck do we start by renaming testing? This will seriously
> disrupt service for anyone for DAYS. There are just too many places
> tools are using "testing" hardcoded. Too many users having that in
> sources.list. Too many things assuming there is "stable, testing,
> unstable". And all of them would suddenly, out of nothing, have broken
> systems and need to fix them.
> 
> If somehow rules for testing get changed (to be whatever rolling wants
> to be), fine. Thats one thing.
> 
> But for what reason change the name? That's worse PR than usually
> done by politicians, and they generally do the things noone with a brain
> ever does. So why?

How much of that would apply if we renamed testing to rolling (because
it reinforces the PR message), but kept a symlink from testing to
rolling?

- 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/20110502092322.ga16...@xanadu.blop.info

Re: Bits from the Release Team - Kicking off Wheezy

[Lucas Nussbaum]

On 02/05/11 at 10:31 +0200, Martin Zobel-Helas wrote:
> Hi, 
> 
> On Sun May 01, 2011 at 21:53:58 +0200, Lucas Nussbaum wrote:
> > On 01/05/11 at 20:51 +0200, Martin Zobel-Helas wrote:
> > > Hi, 
> > > 
> > > On Sun May 01, 2011 at 20:02:51 +0200, Lucas Nussbaum wrote:
> > > > 2. determine who is in support of each action plan, through a GR or a
> > > > poll.
> > > 
> > > I don't think we need a GR for that. Those who are interested in rolling
> > > releases could show that they are interested and just doing so (like
> > > Norbert/formorer/Rhona/...  did with backports, like Joey Hess did with
> > > testing-security, like Andi and me did with volatile, ...).
> > > 
> > > I am aware this might need changes in some of Debian's infrastructure,
> > > but i am quite sure if you provide help/patches/... those will be
> > > implemented.
> > 
> > I don't see how that could work.
> > Iet's assume that the goal is to demonstrate the interest in the "rename
> > testing to rolling" scenario, without even talking about what to do during
> > freezes.
> > 
> > The first steps of the implementation will include:
> > - rename testing to rolling. I don't see how ftpmasters would do it
> >   without a consensus that this is something wanted by the project.
> > - communicate officially, to the general public, that rolling is not
> >   only a development branch, but also suited for use by the general
> >   public (given known limitations). I don't see how the press team would
> >   publish something like that without a consensus that it's what the
> >   project thinks.
> > 
> > What was applicable for backports, testing-security or volatile is not
> > applicable here, because the implications for the project are deeper.
> > It's not about adding a suite with some different packages in the
> > margin. It's about shifting developers' focus and user attention a bit.
> 
> No, it just needs that rolling is running on a different dak instance as
> testing. The same we had for volatile, the same we had for backports.
> The team (whoever that is) wo is interested in the rolling releases can
> show it is worth the effort, then we can start thinking integrating it
> back into the main archive.

What's the point?
Outside of freezes, rolling == testing. What's the point of running a
separate dak instance?
It would be about as efficient to collect statements of users saying "if
rolling existed, I would use it".

- 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/20110502100932.ga17...@xanadu.blop.info

Re: Wth "rolling"? (was: Bits from the Release Team - Kicking off Wheezy)

[Martin Wuertele]

* Lucas Nussbaum  [2011-05-02 11:32]:

> How much of that would apply if we renamed testing to rolling (because
> it reinforces the PR message), but kept a symlink from testing to
> rolling?

If you want that you need a GR as it overrides a delegate decision. 

And I predict I'm not the only one who will vote against that change
should that GR come.

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/20110502102825.gc26...@anguilla.debian.or.at

Debian rolling: tentative summary

[Lucas Nussbaum]

Hi,

Since I already sent too many mails in the 'rolling' discussion, I
decided to send one more.  Here is an attempt at a summary of what was
said so far. It might not be complete, it's probably a bit biased, but I
hope that it's still better than nothing.  When replying, please try to
focus on specific points, and change the subject accordingly.

Motivations
===
There's some user demand for rolling releases[1]. For evidence, one
can look at the usage of Debian testing or unstable which clearly
goes further than the Debian development community. Or at the
quickly growing market share of ArchLinux. Or at the interest in
LinuxMint and Aptosid. Or at the DPL's report of his
interactions with the press[2].

Debian's only official product is its stable releases. While it's a
clearly great and useful product, many users and developers don't
recognize themselves in it: it contains software that is too old for
their needs. The success of Ubuntu is related to this problem:
Ubuntu proposes a different compromise between stability and
up-to-date-ness.

While concurrencing Ubuntu with more frequent stable releases
(released every 6-months, for example) doesn't look like the right
thing to do, Debian is in a perfect position to provide a rolling
release with marginal additional work, since Debian already has
testing (and unstable) to build on.

The rolling discussion investigates how we could endorse the concept
of a rolling release, provided as a product in addition to stable
releases. This rolling release would be based on the current testing
branch.

Benefits for Debian:

  * Attract users who think that testing is only a development
branch, and want newer software than what one finds in stable.
Those users are likely to be rather advanced users (free
software developers and contributors), thus interesting to work
with (able to submit good-quality bug reports, etc). Some of
them could also become Debian contributors. And even if they
don't, more users of testing/rolling means more testers of the
next stable release [remember how the bug reporting rate of
Ubuntu is higher than Debian's -- some areas of Debian could use
more testers].

  * Give back to the free software world by providing a platform
where new upstream releases would quickly be available to users.
Since users would be able to test new upstream releases earlier,
they would be able to provide feedback to upstream devs earlier,
contributing to a shorter feedback loop. Debian is often
identified by upstream developers as the platform with releases
from two years ago. I would love to see Debian in a position to
contribute more to improviing the quality of the Free Software
world.

  * Get back some attention that is currently taken away from Debian
by derivatives. This is important to carry our political or
technical messages, which are not necessarily carried out by our
derivatives.

Current proposed plan for rolling
=
(Disclaimer: this is mostly my view. It is shared by others, but
some details might not be)

rolling is mostly about (external) communication. It is not expected
to change our development processes fundamentally.
It would be a statement by the project (through a GR, for example).
A very preliminary draft was proposed by Raphael Hertzog[3]:

  Title: Debian endorses usage of testing by end-users, and renames
  it to rolling

  The Debian project recognizes that the Debian testing
  distribution-initially created to make it easier to prepare and
  test the next stable release-has become a useful product of its
  own. It satisfies the needs of users who are looking for the
  latest stable versions of software and who can cope (or even
  appreciate) a system that's constantly evolving.

  The Debian project decides to endorse this usage and will strive
  to provide a good experience to users of "testing". To better
  communicate this policy change to our users, "testing" will be
  renamed "rolling".

Yes, it's mostly "PR bullshit", and I don't expect it to
significantly change Debian development processes. However,
communication is necessary if we want to attract new users. What
would change is more attention from developers to what happens in
testing/rolling, which is a good thing since a better
testing/rolling makes it easier to create stable releases from it.

Open questions
==
Most of the discussion is about the influence of the introduction of
`rolling' on Debian development processes, and in particular, on the
painful process resulting in stable releases. Many fear that, with
`rolling', it will be harder to get stable releases out.

The root question is: if we do `rolling', what do we do during
freezes? Several options have been mentioned in the thread:

 1. We could decide not to do anything special: just freeze rolling
for ~6 months, as we used to freeze testing. That might bore
people who like the 

Re: Debian rolling: tentative summary

[Samuel Thibault]

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

Samuel


-- 
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/20110502114205.gj5...@const.bordeaux.inria.fr

priti kashyap has invited you to open a Google mail account

[priti kashyap]

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!

priti kashyap 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 priti kashyap 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, priti kashyap 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

Debian desktop market focused release

[Abou Al Montacir]

On Mon, 2011-05-02 at 13:31 +0200, Lucas Nussbaum wrote:

> Benefits for Debian:
> 
>   * Attract users who think that testing is only a development
> branch, and want newer software than what one finds in stable.
> Those users are likely to be rather advanced users (free
> software developers and contributors), thus interesting to work
> with (able to submit good-quality bug reports, etc). Some of
> them could also become Debian contributors. And even if they
> don't, more users of testing/rolling means more testers of the
> next stable release [remember how the bug reporting rate of
> Ubuntu is higher than Debian's -- some areas of Debian could use
> more testers].
> 
>   * Give back to the free software world by providing a platform
> where new upstream releases would quickly be available to users.
> Since users would be able to test new upstream releases earlier,
> they would be able to provide feedback to upstream devs earlier,
> contributing to a shorter feedback loop. Debian is often
> identified by upstream developers as the platform with releases
> from two years ago. I would love to see Debian in a position to
> contribute more to improviing the quality of the Free Software
> world.

Hi all,

First, thank you for this message which summarizes huge mail thread. I
didn't personally read most of the mails, as these are hundreds. So,
please excuse me if I'm repeating something that was already said.

What about keeping the same schema, which is working well
(unstable==>testing==>stable), and just adding a new kind of parallel
release path (unstable==>testing==>desktop) which is a kind of short
cycle release targeting the desktop/laptop market.

Today, testing is quite good quality, but sometimes it get stuck and
cause headaches for a few days rendering PC non usable. So filtering
this kind of things should be easy especially for stable lesser quality
release.

I like Debian's logo quality's first and think we should keep this even
when going to the desktop market. So maybe we need to focus on this way
based on short cycle releases (in addition to the regular release
cycle).

One way is to have a second release team for this purpose. An maybe the
release team could monitor these desktop release in order to decide, the
best time, to base stable on a giver desktop version 


unstable==>testing==>desktop
  ||==>frozen==>stable

Just my two cents,

Cheers,


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

Re: Debian rolling: tentative summary

[Pierre Habouzit]

On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> Since I already sent too many mails in the 'rolling' discussion, I
> decided to send one more.  Here is an attempt at a summary of what was
> said so far. It might not be complete, it's probably a bit biased, but I
> hope that it's still better than nothing.  When replying, please try to
> focus on specific points, and change the subject accordingly.

That's a decent summary of what was said I think.

Though I feel that to make the discussion more solid, the following is
missing:

  - What are the problems you try to address with rolling? And no "the
users want it" isn't an answer, I'd reply "why do they want it" if
that's the answer I get.

  - Are we sure that rolling is the best way to address those problems?

  - What is rolling exactly ?


I'd add a few questions:
  - we acknowledged that some derivatives (e.g. aptosid) are doing the
work of stabilizing unstable. Isn't it a better way of doing things
in the sense that it doesn't harm testing a bit? IOW wouldn't it be
a better idea to somehow (with their consent) swallow a derivative
that seems to do what you want to instead of suffering NIH and
reinvent something a derivative does?

  - I'll stress again that testing is a release tool, and sometimes to
unblock large transitions it's easier to remove a package from the
distribution so that it doesn't block thousands of other, or because
the breakage it introduces is too large. This practice is very
important, and I remember the release team having strong
altercations with other DDs at the time whereas testing wasn't
targeted at users. What would it be if testing becomes more user
targetted? Should the removal policies be amended ? Beware, I think
it's a huge no-go for the release team.
-- 
·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/20110502124205.ge23...@madism.org

Re: Debian desktop market focused release

[Pierre Habouzit]

On Mon, May 02, 2011 at 02:40:21PM +0200, Abou Al Montacir wrote:
> On Mon, 2011-05-02 at 13:31 +0200, Lucas Nussbaum wrote:
> 
> > Benefits for Debian:
> > 
> >   * Attract users who think that testing is only a development
> > branch, and want newer software than what one finds in stable.
> > Those users are likely to be rather advanced users (free
> > software developers and contributors), thus interesting to work
> > with (able to submit good-quality bug reports, etc). Some of
> > them could also become Debian contributors. And even if they
> > don't, more users of testing/rolling means more testers of the
> > next stable release [remember how the bug reporting rate of
> > Ubuntu is higher than Debian's -- some areas of Debian could use
> > more testers].
> > 
> >   * Give back to the free software world by providing a platform
> > where new upstream releases would quickly be available to users.
> > Since users would be able to test new upstream releases earlier,
> > they would be able to provide feedback to upstream devs earlier,
> > contributing to a shorter feedback loop. Debian is often
> > identified by upstream developers as the platform with releases
> > from two years ago. I would love to see Debian in a position to
> > contribute more to improviing the quality of the Free Software
> > world.
> 
> Hi all,
> 
> First, thank you for this message which summarizes huge mail thread. I
> didn't personally read most of the mails, as these are hundreds. So,
> please excuse me if I'm repeating something that was already said.
> 
> What about keeping the same schema, which is working well
> (unstable==>testing==>stable), and just adding a new kind of parallel
> release path (unstable==>testing==>desktop) which is a kind of short
> cycle release targeting the desktop/laptop market.
> 
> Today, testing is quite good quality, but sometimes it get stuck and
> cause headaches for a few days rendering PC non usable. So filtering
> this kind of things should be easy especially for stable lesser quality
> release.
> 
> I like Debian's logo quality's first and think we should keep this even
> when going to the desktop market. So maybe we need to focus on this way
> based on short cycle releases (in addition to the regular release
> cycle).
> 
> One way is to have a second release team for this purpose. An maybe the
> release team could monitor these desktop release in order to decide, the
> best time, to base stable on a giver desktop version 
> 
> 
> unstable==>testing==>desktop
>   ||==>frozen==>stable

This is addressed in the thread, and some (me included) fear that it'll
squander resources and lessen quality. If you don't add new people to do
this extra work, then it means you'll make people do both, and they are
already overwhelmed with their current work.

Plus it splits the user base. It's all in the end of lucas mail FWIW.
-- 
·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/20110502124409.gf23...@madism.org

Re: Bits from the Release Team - Kicking off Wheezy

[Carsten Hey]

* Pierre Habouzit [2011-05-02 08:08 +0200]:
> On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote:
> > * Pierre Habouzit [2011-05-01 23:17 +0200]:
> > > The problem is, you need to entry points, one for testing as we know it,
> > > one for rolling.
> >
> > Actually, we need two entry points each, a default one and an
> > exceptional one.  The latter ideally requires a special permission from
> > a release team before an upload.  For testing these are unstable and
> > testing-proposed-updates.
>
> Urgh. Sounds a lot.

1st phase: - add unstable-proposed-updates
2nd phase: - create symlink rolling, pointing to testing
   - create symlink rolling-proposed-updates, pointing to
 testing-proposed updates
3rd phase: - freeze testing
   - make rolling and rolling-proposed-updates real suites

If rolling is supposed to be a subset of testing, making rolling and
rolling-proposed-updates real suites would need to happen earlier.

This completely ignores what seems to be the original motivation for
CUT.  Maybe there is a different solution to provide what d-i alpha and
beta releases need or reduce what they need.


> > > If you use t-p-u for testing and unstable for rolling, or unstable for
> > > testing and rolling-updates for rolling is just bikeshedding. The result
> > > is some of the users will use unstable and help testing, the other sort
> > > will run rolling-updates or rolling.
> > >
> > > So basically you split our users in two non overlapping sets, meaning
> > > that you divide coverage and tests.
> >
> > The result of this bikeshedding has an influence on how big these sets
> > are.
>
> I agree, the original sizes, I expect them to converge more or less to
> the same end result, which is what is important on the long term.

Many people just choose what's default.  d-i installing testing instead
of rolling by default would raise the number of the testing set.
Requiring users of unstable + -updates to add -updates manually to the
sources.list would in my opinion decrease this set of people.


> > > I'm interested about *why* they want it, not the mere fact that they
> > > do. Because when you know why they want it, maybe there will be better
> > > answers that don't make releasing even more brittle and burn even more
> > > people out.
> >
> > I guess it's mainly about new upstream versions (firefox, chromium,
> > gnome and so on) they read in the news about, saw on other computers or
> > really contain features useful for the users.
> >
> > Moving backports.org to backports.debian.org and enabling automatic
> > upgrades by default are steps in the right direction to address this
> > (except for desktop environments).

backports.debian.org does not fit here, it makes stable more attractive
for users that would otherwise run testing.

Making testing more attractive for users that would otherwise run
rolling could be done with "semi-official PPAs".


Carsten


-- 
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/20110502130302.gr5...@furrball.stateful.de

Re: Bits from the Release Team - Kicking off Wheezy

[Carsten Hey]

* Lucas Nussbaum [2011-05-02 09:20 +0200]:
> On 02/05/11 at 08:19 +0200, Pierre Habouzit wrote:
> > Also note that testing as is has not enough security support, and
> > read Carsten very good example of the PAM issues. How would CUT or
> > rolling address those?
>
> The PAM issue outlines how splitting the users and developers between
> two branches (unstable and testing post-freeze in the PAM case) causes
> problems.

In my opinion it outlines how migration through barely used suites
(e.g., *-updates) significantly raises the number of buggy packages
entering a frozen testing.

The need to use those suites is mostly caused by uploading new upstream
versions to unstable even though they will never reach the suite that
currently is testing.


> [C] we could compromise. We could freeze rolling for 3 months, so that
> most of the stabilization work occurs with a single active branch,
> and then, for the final release preparation, fork 'frozen' off
> 'rolling', and unfreeze 'rolling'.

The mentioned PAM issue happened four months after freeze.  Decreasing
the chances to catch critical bugs before they enter a frozen testing
does not seem to be the best idea, especially if it is done shortly
before we plan to release.


It would be great if we would find a clever way to be able to release
three months after freeze.

If we don't find a way to do so, we could:
 * Add a non-selfcontained suite to upload non-experimental packages not
   targeted at testing to.  This would lower the number of packages
   needing to go through testing-proposed-updates during freeze and
   could also serve as entry point for rolling.
 * Set up a dak instance for rolling and rolling-proposed-updates on
   rolling.debian.net, announce it and see if it works.
 * If it works, make rolling official.


Regards
Carsten


-- 
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/20110502135115.ga22...@furrball.stateful.de

Bug#625216: python-starpy -- Asterisk (AMI) protocols for Twisted Python

[Paul Belanger]

Package: wnpp
Severity: wishlist
Owner: Debian VoIP Team 
X-Debbugs-CC: debian-devel@lists.debian.org

  Package name: python-starpy
  Version : 1.0.0a13
  Upstream Author : Michael C. Fletcher 
  URL : http://www.vrplumber.com/programming/starpy/
  License : New BSD License (BSD-new)
  Description : Asterisk (AMI) protocols for Twisted Python

 A Twisted Python protocol that provides access to the Asterisk PBX's
 Manager Interface (AMI) and Fast Asterisk Gateway Interface (FastAGI).
 Together these allow you write both command and-control interfaces
 (used, for example to generate new calls) and to customize user
 interactions from the dial-plan.

Additionally, this is required for the Asterisk testsuite (automated 
test platform) and used extensively.


This package will be maintained as part of the pkg-voip team which 
already maintains asterisk.


--
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com & http://asterisk.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/4dbebc1a.3040...@digium.com

Re: PPAs for Debian

[Adnan Hodzic]

I too believe PPA for Debian is a "must have", I personally was
thinking of making my own repository where I would "store" packages
before having them pushed into Debian, even if it was for
experimental.

Putting packages on Ubuntu PPA just doesn't feel right, thus I fully
support this idea and would even help with realization of the same if
the time allows me.


Adnan

On Sat, Apr 30, 2011 at 1:04 PM, Andreas Barth  wrote:
> * Stefano Zacchiroli (lea...@debian.org) [110430 12:56]:
>> What we lack for that to become a reality is "just" the code. Marc and
>> Tollef had set up a nice proposal [1] for GSoC this year and were
>> willing to mentor it, but unfortunately no student has shown up. If
>> there are people willing to contribute some development cycles to Debian
>> (no need to be a DD), that's a wonderful opportunity.
>
> Yes, PPAs "just" need someone who does it. Not more, but also not
> less.
>
>
>
> 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/20110430110424.gh2...@mails.so.argh.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/BANLkTi=1DLcKb_b-axBucU-BBaevV=t...@mail.gmail.com

Re: Bits from the Release Team - Kicking off Wheezy

[Amaya]

George Danchev wrote:
> On Friday 29 April 2011 11:46:30 Lucas Nussbaum wrote:
> > - rename 'testing' to 'rolling' to make it clear that it's usable as
> >   a rolling release
> 
> It is also possible that a 'rename' brings no more value, but a
> confusion to the users for unpredictable amount of time.

100% agreed.

-- 
 .''`.  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/20110502151341.GF3099@aenima

Re: Bits from the Release Team - Kicking off Wheezy

[Amaya]

Holger Levsen wrote:
> Do you think a piuparts / policy workshop (or something) is useful at
> DebConf11?

Please! There's never "too much" chocolate, cheese or QA in Debconf :)

-- 
 .''`.  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/20110502152458.GG3099@aenima

Re: Bits from the Release Team - Kicking off Wheezy

[Stefano Zacchiroli]

On Sun, May 01, 2011 at 11:00:58PM +0200, Pierre Habouzit wrote:
> > First of all I think you should concede that the exercise you're asking
> > us to do cannot be done as easily as you did yours.
> I don't concede that. I've read your mail, and to sum up you say:

(Note that the "concede" was on a side aspect, not on the fact that I
was able---which clearly I was not---to convince you of my arguments.)

> So the next question is "why" your mail doesn't answer that. I still
> think that rolling is a bad idea, until you've proven me that it's the
> sole way to address a real life issue/need/itch.

Yes, you're right and I've no answer for that, because the way I've
interacted with people was in some aggregate form, which didn't permit
me to investigate more than that.  So, sorry, I give up on answering
this. But that doesn't stop me from seeing as perfectly reasonable the
use cases already mentioned several times in this thread
(e.g. <20110501200120.ga18...@gnu.kitenet.net> for a short version).
It's very clear to me that they are not enough to convince you and
others, but they are convincing for me.

We should probably stop here and agree to disagree.  Ultimately, we'll
be able to know who is right only if someone builds the thing and see
how many users actually use it.

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

[Roland Mas]

Stefano Zacchiroli, 2011-04-30 12:56:15 +0200 :

[...]

> What we lack for that to become a reality is "just" the code. Marc and
> Tollef had set up a nice proposal [1] for GSoC this year and were
> willing to mentor it, but unfortunately no student has shown up. If
> there are people willing to contribute some development cycles to
> Debian (no need to be a DD), that's a wonderful opportunity.

And if the system were to be integrated somewhat into Alioth, I'm pretty
sure the upstreams for FusionForge would be glad to offer guidance.  I
would, at any rate.

  It just so happens that there's going to be an Alioth sprint in a bit
less than three weeks.  Want to join us to discuss the matter and/or
start an implementation?  Head to
http://wiki.debian.org/Sprints/2011/AliothSprint (even if it's little
more than a skeleton so far).

Roland.
-- 
Roland Mas

Qu'est-ce qui est petit, jaune et vachement dangereux ?
Un canari avec le mot de passe de root.


-- 
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/87mxj5xg6r@mirexpress.internal.placard.fr.eu.org

Re: Bits from the Release Team - Kicking off Wheezy

[Stefano Zacchiroli]

On Sun, May 01, 2011 at 10:43:18PM +0200, Carsten Hey wrote:
> Testing also has just little protection against severe breakage if it is
> frozen and updates need to go through rarely used suites.  An example
> illustrates this quite well:

Thanks for this example Carsten. However, one example is not enough
evidence to say that testing provide little protection. We can always
find bad examples of this kind, for any suite. I'm pretty sure we can
find horror stories even for stable, but from that we cannot conclude
that the protection you get against horror stories in stable is lower
than the one you would get in testing or unstable.

> A 'frozen' requiring most updates to go through *-proposed-updates would
> make this quarantine period a lot less useful, and it would make
> circumstances like the one described above a lot more probable.

I do agree with this: any parallel path comes with its own risks of
reducing package testing.  Once more, for me this discussion is really
about two orthogonal aspects: the goal of having a user-targeted testing
(on which we might agree or disagree) and the specific way we choose to
achieve it (which might have issues as the one embodied by your
example).

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: Debian rolling: tentative summary

[Scott Kitterman]

On Monday, May 02, 2011 07:31:31 AM Lucas Nussbaum wrote:
...
> 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).
...

There is a ton of complexity hidden under these simple words.  There is also 
(that I can immediately think of):

 - How do we provide a reliable path for fixes to Testing once Unstable/Rolling 
have moved on?

 - How do we stitch Testing/Rolling back together after a release into the new 
Rolling?

 - How do we allow for more parallel transitions so that rolling can actually 
roll.

The first two points have gotten a lot of discussion.  The third one, not so 
much.

The Debian archive has gotten large enough with enough non-trivial 
intersections between groups of packages that transitions of almost any size 
need coordination and analysis to find an appropriate time to land in order to 
minimize deadlocks in Unstable -> Testing (or whatever you call it) 
transitions.

If you view this exercise as primarily a PR move to make Testing seem more 
attractive to users that want a rolling distribution, then I suggest we 
arrange things so it can actually roll.  

As an example, my desktop environment of choice (KDE) is still a year (and two 
major releases) out of date in Debian Unstable/Testing.  Current packages 
exist in Experimental, but can't get to Unstable let alone some theoretical 
Rolling because there's no transition window.  

I don't think that someone who is attracted to the idea of a Rolling release 
to get the latest and greatest would find this met their expectations.

Without solving the problem of the need to serialize transitions, I doubt 
Rolling will match the expectations such a change would engender and while 
there would no doubt be publicity, I'm skeptical it would be the good kind.

Scott K


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

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Goswin von Brederlow]

Steve Langasek  writes:

> On Sun, Apr 24, 2011 at 10:46:40PM +0100, Wookey wrote:
>> I expect the multiarch paths to replace the 'traditional
>> cross-compiling' paths in due course for all target architectures,
>> including ones that aren't Debian-suported (i.e currently
>> mingw-whatever-you-call-it, avr32, msp430), for both native use and
>> cross-compiling. Steve will have to explain to me why we might want to
>> use different paths for non-self-hosting arches. It seems to me that
>> having one canonical place to look for arch-dependent files is good
>> whether you want them for running or for (cross-)building.
>
> It's not that non-self-hosting archs should be treated differently from
> self-hosted archs, but that they should be treated the *same* including the
> requirement that multiarch directories be reserved for packages of the
> corresponding architecture... even if there is no support for such a
> corresponding architecture in dpkg or in the archive.  This future-proofs
> the packages for the time being so that if at a later date we *do* add these
> architectures to the archive as architectures, we don't end up with the
> maintainers of all the base libraries having to add lots of "Conflicts:
> libc6-msp430 [msp430]" style conflicts to ensure a smooth upgrade.

I think you are wrong there. True, the package would later have file
overwrite error and would need a Replaces or Conflicts for that (which
are quite trivial to set and cheap).

One the other hand the package should have a Conflicts or Breaks on the
same package anyway, at least as soon as there is a shlibs/symbols/abi
change. Lets assume libc6-msp430 uses the cross compiler dirs. Having
both libc6-msp430:all and libc6:msp430 would mean you have 2 versions of
a single library installed in 2 different directories. That means either
packages depending on libc6-msp430:all or packages depending on
libc6:msp430 will get the wrong library. That is best avoided on
principal even if there is no shlibs/symbols/abi difference (yet).

Also the libc6-msp430-dev:all and libc6-dev:msp430 packages will both be
using /usr/inlcude// and already trigger the problem you
fear.

So using multiarch dirs or cross-compile dirs a Conflicts should be
there either way. Add that the cross-compile dirs aren't allways unique
enough to work and using the multiarch dirs becomes the only sensible
option.

MfG
Goswin


-- 
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/87aaf5w0cy.fsf@frosties.localnet

Re: [RFC] Changing APT to pre-depend on ${shlibs:Depends}

[Goswin von Brederlow]

Steve Langasek  writes:

> On Thu, Apr 28, 2011 at 06:48:22PM +0200, Julian Andres Klode wrote:
>> > "We might some day later change the way apt works for upgrades" is not an
>> > argument for adding a pre-dependency now.
>
>> But that we do want to prevent a broken APT -- when using the common
>> "dpkg -i ...; apt-get install -f" idiom (where ... is APT) -- certainly
>> is an argument. 

I have to +1 this. "apt-get install -f" is frequently used to recover
from a broken upgrade. So it would be better if apt-get keeps working.

> Yeah.  I don't strongly disagree with this argument, but I also don't find
> it particularly persuasive.  apt already treats apt as special, I don't
> think it's very consistent to ask dpkg and other front ends to also treat
> apt specially (by way of Pre-Depends).

If apt already treats apt special then why not just have apt treat the
depends of apt as pre-depends? That way apt would first invoke dpkg with
all the pre-depends of apt and then later with apt itself ensuring the
order you wanted.

MfG
Goswin


-- 
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/8762ptvzy3.fsf@frosties.localnet

Re: Debian rolling: tentative summary

[Jan Hauke Rahm]

On Mon, May 02, 2011 at 02:42:05PM +0200, Pierre Habouzit wrote:
> On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote:
> > Hi,
> > 
> > Since I already sent too many mails in the 'rolling' discussion, I
> > decided to send one more.  Here is an attempt at a summary of what was
> > said so far. It might not be complete, it's probably a bit biased, but I
> > hope that it's still better than nothing.  When replying, please try to
> > focus on specific points, and change the subject accordingly.
> 
> That's a decent summary of what was said I think.
> 
> Though I feel that to make the discussion more solid, the following is
> missing:
> 
>   - What are the problems you try to address with rolling? And no "the
> users want it" isn't an answer, I'd reply "why do they want it" if
> that's the answer I get.

Not that I don't understand your asking for reasons but... doesn't look
having a large user base look somehow appealing to you? I think many DDs
care for such since working on Debian brings more fun if someone's
actually using it.

Anyways...

> I'd add a few questions:
>   - we acknowledged that some derivatives (e.g. aptosid) are doing the
> work of stabilizing unstable. Isn't it a better way of doing things
> in the sense that it doesn't harm testing a bit? IOW wouldn't it be
> a better idea to somehow (with their consent) swallow a derivative
> that seems to do what you want to instead of suffering NIH and
> reinvent something a derivative does?

How does such swallowing look like? Add a suite 'aptosid' or 'ubuntu'?

>   - I'll stress again that testing is a release tool, and sometimes to
> unblock large transitions it's easier to remove a package from the
> distribution so that it doesn't block thousands of other, or because
> the breakage it introduces is too large. This practice is very
> important, and I remember the release team having strong
> altercations with other DDs at the time whereas testing wasn't
> targeted at users. What would it be if testing becomes more user
> targetted? Should the removal policies be amended ? Beware, I think
> it's a huge no-go for the release team.

I think, those in favor of advertising testing or rolling or whatever
you call it have explained repeatedly that stable is still the primary
target for Debian. If at some point that may change, things can be
rethought but until then I don't think any such policy needs changing.

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

Serializing transitions

[Jan Hauke Rahm]

On Mon, May 02, 2011 at 11:48:27AM -0400, Scott Kitterman wrote:
> On Monday, May 02, 2011 07:31:31 AM Lucas Nussbaum wrote:
> ...
> > 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).
>  - How do we allow for more parallel transitions so that rolling can actually 
> roll.
> 
> The first two points have gotten a lot of discussion.  The third one, not so 
> much.

I think PPAs can be used to fix that. IIRC that was one of the reasons
they were brought into discussions in the first place last year (or
whenever that was). Weren't they?

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: Debian rolling: tentative summary

[Martin Wuertele]

* Jan Hauke Rahm  [2011-05-02 18:23]:

> Not that I don't understand your asking for reasons but... doesn't look
> having a large user base look somehow appealing to you? I think many DDs
> care for such since working on Debian brings more fun if someone's
> actually using it.

Why do you believe that this will increase our user base? It might, in
case less focus is put on stable, even reduce our user base (on the
coporate and server environment).

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/20110502162702.gd26...@anguilla.debian.or.at

Re: PPA

[Jan Hauke Rahm]

On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> >   build-dependencies not satisfiable in the target suite)
> 
> Why not just use one location - shouldn't be an issue unless you plan
> to have the same packages and version numbers in multiple PPAs. And
> that's something I recommend not to do.

I guess I'm misunderstanding you here, so please help me out. If a
package is being worked on in different PPAs regarding different
problems (thinking of serializing transitions for instanced but many
other examples apply), how can they share the same version number
without conflicting?

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: Debian rolling: tentative summary

[Jan Hauke Rahm]

On Mon, May 02, 2011 at 06:27:02PM +0200, Martin Wuertele wrote:
> * Jan Hauke Rahm  [2011-05-02 18:23]:
> 
> > Not that I don't understand your asking for reasons but... doesn't look
> > having a large user base look somehow appealing to you? I think many DDs
> > care for such since working on Debian brings more fun if someone's
> > actually using it.
> 
> Why do you believe that this will increase our user base? It might, in
> case less focus is put on stable, even reduce our user base (on the
> coporate and server environment).

Firstly, I'm not saying that. Secondly, that's one of the main arguments
to introduce said changes. The argument was (not that it wasn't written
out often enough) that derivatives provide something we don't: more
current software; some as rolling releases, some on scheduled releases
etc. The idea is, if we provide something similar, not the same of
course, users who care for such come to us. It's as simple as that.

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

[Pierre Habouzit]

On Mon, May 02, 2011 at 05:36:34PM +0200, Stefano Zacchiroli wrote:
> On Sun, May 01, 2011 at 11:00:58PM +0200, Pierre Habouzit wrote:
> > > First of all I think you should concede that the exercise you're asking
> > > us to do cannot be done as easily as you did yours.
> > I don't concede that. I've read your mail, and to sum up you say:
> 
> (Note that the "concede" was on a side aspect, not on the fact that I
> was able---which clearly I was not---to convince you of my arguments.)
> 
> > So the next question is "why" your mail doesn't answer that. I still
> > think that rolling is a bad idea, until you've proven me that it's the
> > sole way to address a real life issue/need/itch.
> 
> Yes, you're right and I've no answer for that, because the way I've
> interacted with people was in some aggregate form, which didn't permit
> me to investigate more than that.  So, sorry, I give up on answering
> this. But that doesn't stop me from seeing as perfectly reasonable the
> use cases already mentioned several times in this thread
> (e.g. <20110501200120.ga18...@gnu.kitenet.net> for a short version).
> It's very clear to me that they are not enough to convince you and
> others, but they are convincing for me.

Well I don't want to be convinced or not convinced, you misunderstood
why I'm asking that. I'm asking because I want to evaluate if rolling is
the sole answer we can bring to these people.

They say they want testing to be usable, but maybe what they want is
something that we can achieve without touching testing at all. So I'd
like to understand. There is absolutely no will on my end to be
convinced or not convinced, this was a genuine question for pure
technical considerations.
-- 
·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/20110502164258.gg23...@madism.org

Re: Debian rolling: tentative summary

[Martin Wuertele]

* Jan Hauke Rahm  [2011-05-02 18:31]:

> On Mon, May 02, 2011 at 06:27:02PM +0200, Martin Wuertele wrote:
> > * Jan Hauke Rahm  [2011-05-02 18:23]:
> > 
> > > Not that I don't understand your asking for reasons but... doesn't look
> > > having a large user base look somehow appealing to you? I think many DDs
> > > care for such since working on Debian brings more fun if someone's
> > > actually using it.
> > 
> > Why do you believe that this will increase our user base? It might, in
> > case less focus is put on stable, even reduce our user base (on the
> > coporate and server environment).
> 
> Firstly, I'm not saying that. Secondly, that's one of the main arguments
> to introduce said changes. The argument was (not that it wasn't written
> out often enough) that derivatives provide something we don't: more
> current software; some as rolling releases, some on scheduled releases
> etc. The idea is, if we provide something similar, not the same of
> course, users who care for such come to us. It's as simple as that.

I've read that arguement over and over. However the resources are
limited and I have not yet read an actual proposal or plan how to do
that without reducing the resources for the stable releases.

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/20110502164411.gf26...@anguilla.debian.or.at

Re: Bits from the Release Team - Kicking off Wheezy

[Stefano Zacchiroli]

On Mon, May 02, 2011 at 06:42:58PM +0200, Pierre Habouzit wrote:
> Well I don't want to be convinced or not convinced, you misunderstood
> why I'm asking that. I'm asking because I want to evaluate if rolling is
> the sole answer we can bring to these people.

Oh no, not at all, I apologize if that wasn't clear.  I did understand
very well why you were asking that, and I would love to have an
answer---coming from those (potential) users---to give you, but
unfortunately I don't have it.

I'll take care in the future of asking individuals which will bring up
with me the topic of CUT/rolling (no matter how non-representative that
could be) and will let you know.  In the meantime I've highlighted an
approximate way to ask them (the survey, which is unfortunately limited
by the non-scalability of surveys with open-ended answers), that's the
best I could do for now.

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: Debian rolling: tentative summary

[Jan Hauke Rahm]

On Mon, May 02, 2011 at 06:44:11PM +0200, Martin Wuertele wrote:
> * Jan Hauke Rahm  [2011-05-02 18:31]:
> 
> > On Mon, May 02, 2011 at 06:27:02PM +0200, Martin Wuertele wrote:
> > > * Jan Hauke Rahm  [2011-05-02 18:23]:
> > > 
> > > > Not that I don't understand your asking for reasons but... doesn't look
> > > > having a large user base look somehow appealing to you? I think many DDs
> > > > care for such since working on Debian brings more fun if someone's
> > > > actually using it.
> > > 
> > > Why do you believe that this will increase our user base? It might, in
> > > case less focus is put on stable, even reduce our user base (on the
> > > coporate and server environment).
> > 
> > Firstly, I'm not saying that. Secondly, that's one of the main arguments
> > to introduce said changes. The argument was (not that it wasn't written
> > out often enough) that derivatives provide something we don't: more
> > current software; some as rolling releases, some on scheduled releases
> > etc. The idea is, if we provide something similar, not the same of
> > course, users who care for such come to us. It's as simple as that.
> 
> I've read that arguement over and over. However the resources are
> limited and I have not yet read an actual proposal or plan how to do
> that without reducing the resources for the stable releases.

And I among others think that it won't affect stable as much as you
fear. There is already a bunch of DDs who don't care about servers and
use testing and/or unstable on all their systems. The mere fact that
Debian says "we care for stable" doesn't make anyone work for it. Just
like the mere saying that "testing/rolling is now supported as a rolling
release" doesn't make anyone care for it. There is just one way out: try
it and see if it works, of people care -- for both stable and rolling.

Improvement always means some risks of failure. Some are willing to take
that risk. Some aren't. What we need to see is whether there are enough
to go for it.

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: wanna-build / how to sort packages on buildds?

[Goswin von Brederlow]

Ingo Jürgensmann  writes:

> On Sun, 1 May 2011 01:36:38 +0200, Andreas Barth wrote:
>
>> Sometimes we have a few packages we don't want to build on a certain
>> buildds. Sometimes this is because this package needs lots of ram. Or
>> it takes quite long and would waste the parallel building a machine
>> supports. Or whatever else. Of course a package could be in more than
>> one category.
>
> Yes, you're facing basically the same problem I tried to address in
> 2000/2001 when doing my renderserver and later for what Multibuild was
> intended to do as well. ;-)
>
>> Now, what I would like to do is to write that down in a central file
>> with categories.
>
> I would recommend to use a database, really.
>
>> That is, to mark packages as "builds only with more than one gigabyte
>> of ram". And to mark buildds as "has 6 cores", "only ... ram" - so
>> that I don't need to copy entries from buildd to buildd, but just say
>> "that new machine is the same class as ...", and that's it.
>
> Another category would be "fast disk/raid". There are some packages
> with lots of disk accesses. When you can schedule those packages to a
> buildd that has faster disk access like in having multiple spindles
> for faster seeks, you can minimize build times as well. We faced that
> problem on m68k particularly on IDE vs SCSI disks on Amigas, as IDE
> was dog slow. Another example there was the faster disks on Amigas vs
> slower SCSI disks in Apple machines.
>
>> Now my question is just: How to do that efficient? I.e. how would
>> such
>> a configuration file look like, and how the code to distribute the
>> package on the most fitting buildd(s)? (I.e. it's better to waste 5
>> out of 6 cores than to not build a package at all, but a package
>> needing at least 1g ram can't build on a buildd with only 512mb - but
>> no package should starve in the end.)
>> Ideas? Suggestions? Code?
>
> Look at my update-buildd.net from Buildd.net, which I used to collect
> data from the buildds such as RAM, kernel, uptime, used swap and such
> (http://buildd.net/cgi/hostpackages.cgi?unstable_arch=m68k&searchtype=arrakis).
>  I
> store this information into the database and also the build times of
> the packages. With this dataset it should be possible to have the
> wanna-buildd schedule packages in such a way to minimize the build
> times because you can decide which buildd is the most suitable buildd
> for the next package.

I think different groups of factors have to be considered:

1) absolute requirements

I think there are only 2 absolute requirements:
  - ram size
  - disk size
And all buildds currently have enough disk space I think.

In the past we also had some sources that would crash one buildd but not
the other. No way to track that ahead of time though. But it should be
possible to report this to wanna-build.

Absolute requirement are absolute. If a buildd doesn't have the
requirement then wanna-build must never schedule the package to build
there. (Note: The buildd will just give it back with the current setup
so no biggy if wanna-build gets it wrong.)

2) important features

The most relevant feature I think is multiple cores and support of
DEB_BUILD_OPTIONS=parallel=x. This would be an attribute of both the
buildd and the source and one should try to match them. Build sources
which support parallel building preverably on systems with multiple
cores.

The I/O speed and the sources need for it could be another such
feature. But I'm not sure (other than the m68k special case) this is
relevant to such a degree that it makes sense tracking this
specifically.

Important features would be anything we can figure out and point to as
having a major influence on the build speed. And imho this should be
like "N times faster" to warrant the effort to track this for sources.

3) general performance

Buildds are different and build times will differ acordingly. I don't
think this can be properly quanitfied ahead of time and there are many
hidden factors interacting that would be impossible to quantify with
reasonable effort. But I think this can be measured and extrapolated
just fine. Keep a database of build times and do some statistical
analysis to rate the buildd speed in general and for specific
sources. With that you have a good aproximation of the time a source
will need to build on each buildd. Use that as weight when deciding
where to build a source.

Unlike items in 2), which would have to be manually tracked, this would
encompass any and all factors including unknown ones in
approximation. Some care would have to be taken that factors aren't
weighted twice, once from 2) and once here.

The build times for a parallel building source will differ greatly for
single and multi core systems. The difference in weigth this produces
might already be sufficient so that those sources prefer the multi core
systems (after a few versions). So tracking important features manually
might be wasted effort altogether.



My suggestion would be to impleme

Re: wanna-build / how to sort packages on buildds?

[Goswin von Brederlow]

Roger Leigh  writes:

> I just wanted to add that if you would like more statistics reporting
> for this purpose, I'll be happy to add that to sbuild.  Currently we
> only really report build time and disc space.  If you want additional
> data such as number of cores used, memory/swap usage and other resource
> usage, I'll be happy to add them to the sbuild summary stats.  Actually
> measuring those might be a bit trickier though, especially on machines
> running parallel builds.

Reporting the cummulative cpu time used and wall clock time should be
helpfull in detecting parallel builds. The more cpu time approached wall
clock * num cores the better it would be to build the package on multi
core systems.

MfG
Goswin


-- 
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/87vcxtuj8b.fsf@frosties.localnet

Re: PPA

[Andreas Barth]

* Jan Hauke Rahm (j...@debian.org) [110502 18:34]:
> On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > >   build-dependencies not satisfiable in the target suite)
> > 
> > Why not just use one location - shouldn't be an issue unless you plan
> > to have the same packages and version numbers in multiple PPAs. And
> > that's something I recommend not to do.
> 
> I guess I'm misunderstanding you here, so please help me out. If a
> package is being worked on in different PPAs regarding different
> problems (thinking of serializing transitions for instanced but many
> other examples apply), how can they share the same version number
> without conflicting?

Well, the combination of version number and package name needs to be
globally unique. Otherwise, consider what would happen if someone
reports a bug against a package/version, and we can't see which one it
was.

That doesn't mean two packages have the same version number - in
contrast, they don't. But as you usually can't coinstall different
versions of e.g. the same library, that's all fair.



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/20110502171647.gv2...@mails.so.argh.org

Re: PPA

[Jan Hauke Rahm]

On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> * Jan Hauke Rahm (j...@debian.org) [110502 18:34]:
> > On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > > * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > >   build-dependencies not satisfiable in the target suite)
> > > 
> > > Why not just use one location - shouldn't be an issue unless you plan
> > > to have the same packages and version numbers in multiple PPAs. And
> > > that's something I recommend not to do.
> > 
> > I guess I'm misunderstanding you here, so please help me out. If a
> > package is being worked on in different PPAs regarding different
> > problems (thinking of serializing transitions for instanced but many
> > other examples apply), how can they share the same version number
> > without conflicting?
> 
> Well, the combination of version number and package name needs to be
> globally unique. Otherwise, consider what would happen if someone
> reports a bug against a package/version, and we can't see which one it
> was.
> 
> That doesn't mean two packages have the same version number - in
> contrast, they don't. But as you usually can't coinstall different
> versions of e.g. the same library, that's all fair.

In other words, you're suggesting some kind of versioning scheme for
PPAs in order to avoid version conflicts?

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

[Andreas Barth]

* Joey Hess (jo...@debian.org) [110501 22:36]:
> The problem with the moving target is that it means that d-i betas begin
> to be broken as time goes on after their release, starting with the
> smallest boot images and moving up to the netinst images.

We could e.g. create an copy of testing at the time, so that the betas
will work for 3 weeks or so. Perhaps we should take an hour or so
during debconf and see where we arrive?


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/20110502172421.gn15...@mails.so.argh.org

Re: Bits from the Release Team - Kicking off Wheezy

[Andreas Barth]

* Marc 'HE' Brockschmidt (h...@ftwca.de) [110502 09:12]:
> Pierre Habouzit  writes:
> >   - PPA should focus on:
> >   * co-installability when endurable;
> >   * documented and working rollback to unstable (IOW downgrading a
> > package to unstable when co-installability is not possible
> > should work well enough, idealy using pinning and apt, but a
> > documented procedure is good enough too).
> 
> Wait, that's a completely orthogonal problem. Rollbacks of package
> upgrades is unsupported generally, trying to solve this at the same time
> as the PPA issue is a bad idea. There's no reason to connect these
> things.

One could say "from packages in ppa it is expected that they have
appropriate prerm-scripts to make that work". Doesn't mean it will
always do, but sounds good to me.


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/20110502172729.go15...@mails.so.argh.org

Re: PPA

[Andreas Barth]

* Jan Hauke Rahm (j...@debian.org) [110502 19:22]:
> On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> > > I guess I'm misunderstanding you here, so please help me out. If a
> > > package is being worked on in different PPAs regarding different
> > > problems (thinking of serializing transitions for instanced but many
> > > other examples apply), how can they share the same version number
> > > without conflicting?
> > 
> > Well, the combination of version number and package name needs to be
> > globally unique. Otherwise, consider what would happen if someone
> > reports a bug against a package/version, and we can't see which one it
> > was.
> > 
> > That doesn't mean two packages have the same version number - in
> > contrast, they don't. But as you usually can't coinstall different
> > versions of e.g. the same library, that's all fair.
> 
> In other words, you're suggesting some kind of versioning scheme for
> PPAs in order to avoid version conflicts?

No.

We started with "where can we take the package for building", and I
said "there should never be two different packages with same name and
version, so they all can be in one sources list".

There are different possibilities to resolve this - I'm not saying
that I have a perfect solution. But we need to make sure the
combination of package name and version is globally unique. As we do
today.


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/20110502173035.gw2...@mails.so.argh.org

Re: Debian rolling: tentative summary

[Goswin von Brederlow]

Pierre Habouzit  writes:

> On Mon, May 02, 2011 at 01:31:31PM +0200, Lucas Nussbaum wrote:
>> Hi,
>> 
>> Since I already sent too many mails in the 'rolling' discussion, I
>> decided to send one more.  Here is an attempt at a summary of what was
>> said so far. It might not be complete, it's probably a bit biased, but I
>> hope that it's still better than nothing.  When replying, please try to
>> focus on specific points, and change the subject accordingly.
>
> That's a decent summary of what was said I think.
>
> Though I feel that to make the discussion more solid, the following is
> missing:
>
>   - What are the problems you try to address with rolling? And no "the
> users want it" isn't an answer, I'd reply "why do they want it" if
> that's the answer I get.

I think "why do they want it" is the most important question.

As mentioned many users feel that the software in stable is too old. On
the other hand many users praise Debian for their long release cycle and
stable/old-stable support. Those two groups are clearly expressing
contradictory wishes. And maybe trying to find a solution that fits both
isn't the right thing.

To those users that want newer software my next question would be "What
software?". My feeling there is that it is only some software, allways
the same software and used for the same use case: KDE / Gnome /
Multimedia stuff for the Desktop.

Looking at the other group, those that cherish the slow release cycles
and excelent stability and security support, shows a a large bias
towards servers that are either completly headless or where people don't
care about the latest sparkly desktop hype. They need to run and keep
running without having to upgrade them every 6 month.


If my impression is right then maybe there is something to say for
having a desktop and a server flavour like other distributions. It would
be wastefull to have a rolling release with all sources included if the
users only need a subset. The desktop users only want the new sparkly
KDE / Gnome / Multimedia stuff. They do not care about the latest
coreutils or latest postgresql.

So my idea would be to split pakages into 3 groups: core, desktop and
server. We could then have "full" releases that update all sources
(core+desktop+server) and "sparkly" releases that only update desktop
[OK, so only 2 groups: long-term and short-term]. The desktop packages
for sparkly releases would be build against the core packages from the
last full release. They could be done as rolling releases or not. That
option remains open. The point would be to greatly reduce the number of
package updates involved in a sparkly release, to reduce it to those
packages that matter, and therefore reduce the work needed to pull it
off.

Note: yes, this isn't exactly like other distributions having a desktop
and server flavour. You would still have all the packages available in
every release. The up-to-date-ness would differ, not the amount of
installable packages.

MfG
Goswin


-- 
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/87r58huhz4.fsf@frosties.localnet

Re: wanna-build / how to sort packages on buildds?

[Scott Kitterman]

On Saturday, April 30, 2011 07:36:38 PM Andreas Barth wrote:
> Hi,
> 
> I have a problem I need to solve in perl within wanna-build:
> 
> Sometimes we have a few packages we don't want to build on a certain
> buildds. Sometimes this is because this package needs lots of ram. Or
> it takes quite long and would waste the parallel building a machine
> supports. Or whatever else. Of course a package could be in more than
> one category.
> 
> Now, what I would like to do is to write that down in a central file
> with categories.
> 
> That is, to mark packages as "builds only with more than one gigabyte
> of ram". And to mark buildds as "has 6 cores", "only ... ram" - so
> that I don't need to copy entries from buildd to buildd, but just say
> "that new machine is the same class as ...", and that's it.
> 
> Now my question is just: How to do that efficient? I.e. how would such
> a configuration file look like, and how the code to distribute the
> package on the most fitting buildd(s)? (I.e. it's better to waste 5
> out of 6 cores than to not build a package at all, but a package
> needing at least 1g ram can't build on a buildd with only 512mb - but
> no package should starve in the end.)
> 
> Ideas? Suggestions? Code?

If one could do something like:

wb gb libieee1284 mod-wsgi nflog-bindings zinnia . ia64 . !caballero

that would be a HUGE win.  My suggestion would be to start with something 
simple and declarative like that and then build the back end to automatically 
sort out the list of candidate buildd's after that.

Scott K


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

Re: wanna-build / how to sort packages on buildds?

[Andreas Barth]

* Scott Kitterman (deb...@kitterman.com) [110502 19:32]:
> If one could do something like:
> 
> wb gb libieee1284 mod-wsgi nflog-bindings zinnia . ia64 . !caballero

good idea. I'll consider how to do that.


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/20110502173620.gp15...@mails.so.argh.org

Re: Serializing transitions

[Scott Kitterman]

On Monday, May 02, 2011 12:26:05 PM Jan Hauke Rahm wrote:
> On Mon, May 02, 2011 at 11:48:27AM -0400, Scott Kitterman wrote:
> > On Monday, May 02, 2011 07:31:31 AM Lucas Nussbaum wrote:
> > ...
> > 
> > > 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).
> >  
> >  - How do we allow for more parallel transitions so that rolling can
> >  actually roll.
> > 
> > The first two points have gotten a lot of discussion.  The third one, not
> > so much.
> 
> I think PPAs can be used to fix that. IIRC that was one of the reasons
> they were brought into discussions in the first place last year (or
> whenever that was). Weren't they?

I think that's the theory, but AFAIK no one has sat down and mapped out how 
the whole process would work.  If Debian is going to have a true rolling 
release then someone needs to invest time in this.

Scott K


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

Re: Bits from the Release Team - Kicking off Wheezy

[Joey Hess]

Andreas Barth wrote:
> We could e.g. create an copy of testing at the time, so that the betas
> will work for 3 weeks or so. Perhaps we should take an hour or so
> during debconf and see where we arrive?

There is a spec for doing so, which aj mostly developed, at 
http://cut.debian.net/snapshots/implementation_plan/

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Wth "rolling"?

[Joerg Jaspert]

>> > 'rolling' is a statement by the project that we consider 'testing'
>> > (renamed to 'rolling')
>> Why the heck do we start by renaming testing? This will seriously
>> disrupt service for anyone for DAYS. There are just too many places
>> tools are using "testing" hardcoded. Too many users having that in
>> sources.list. Too many things assuming there is "stable, testing,
>> unstable". And all of them would suddenly, out of nothing, have broken
>> systems and need to fix them.

>> If somehow rules for testing get changed (to be whatever rolling wants
>> to be), fine. Thats one thing.

>> But for what reason change the name? That's worse PR than usually
>> done by politicians, and they generally do the things noone with a brain
>> ever does. So why?

> How much of that would apply if we renamed testing to rolling (because
> it reinforces the PR message), but kept a symlink from testing to
> rolling?

Most, only the user part goes away. OTOH if we just symlink rolling to
testing and keep the rest as is, then I don't care about rolling. And we
would have the same net effect. (And from FTP* discussions, the idea to
rename the suite for nothing (as this is) had, at best, a "braindead
stupid" idea as a response, so I guess this has to be a GR unless a
better argument than "it sounds nice in PR" comes up).


But you left out the other part I had, how to get stuff better for users
without all the useless PR games. What I see, we can have the stuff
behind this already. We can have regularly updated "releases" (call em
alpha or beta), including d-i and possibly updated packages, we can have
the users go over there. Without breaking the development chain we know
leads to another stable release.

It just needs people to not discuss but actually work on that.

And, double benefit, it would be in parallel to what we have now, not
forcefully killing one thing without knowing if the new thing has any
benefit[1]. And if it turns out better and helps us along, the worse thing
will die on its own. (I would *like* to see something like 2 to 4
"beta"-releases of testing a year go out, including a d-i and stuff). We
have the means to do it technically. We throw the manpower this would
need into discussions and GRs, hoping someone somewhere can be forced to
do it.


[1] Right now it is all blind guessing. "The users will love it". "The
maintainers will support their packages better"(WTF? Due to a
rename? Stop dreaming)

-- 
bye, Joerg
English side ruined! Must use French instructions! Le GRILL?? What the hell is 
that?


-- 
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/8762pt9e0o@gkar.ganneff.de

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Steve Langasek]

On Mon, May 02, 2011 at 06:09:17PM +0200, Goswin von Brederlow wrote:
> > It's not that non-self-hosting archs should be treated differently from
> > self-hosted archs, but that they should be treated the *same* including the
> > requirement that multiarch directories be reserved for packages of the
> > corresponding architecture... even if there is no support for such a
> > corresponding architecture in dpkg or in the archive.  This future-proofs
> > the packages for the time being so that if at a later date we *do* add these
> > architectures to the archive as architectures, we don't end up with the
> > maintainers of all the base libraries having to add lots of "Conflicts:
> > libc6-msp430 [msp430]" style conflicts to ensure a smooth upgrade.

> I think you are wrong there. True, the package would later have file
> overwrite error and would need a Replaces or Conflicts for that (which
> are quite trivial to set and cheap).

> One the other hand the package should have a Conflicts or Breaks on the
> same package anyway, at least as soon as there is a shlibs/symbols/abi
> change.

You have made this assertion repeatedly; I have repeatedly rejected this
assertion.  As long as multiarch remains a one-way transition, with biarch
or cross-compiler packages being replaced by multiarch packages (never the
other way around) and multiarch library paths always included first in the
search order, this is a non-issue and your proposed Conflicts are needless
complexity.

> Also the libc6-msp430-dev:all and libc6-dev:msp430 packages will both be
> using /usr/inlcude// and already trigger the problem you
> fear.

No, libc6-msp430-dev would use /usr//include as it does today.

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


--
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/20110502181047.gb31...@virgil.dodds.net

gtkpod packaging dependencies

[phantomjinx]

Hi,

Someone with the handle 'mfv' came into the gtkpod irc channel wondering
about gtkpod dependencies as he was packaging it for debian.

I have already produced an ubuntu ppa for the 2.0.1-beta so thought the
debian directory would be useful.

Please find attached.

(Not registered so please cc any replies. Thanks).

Regards

phantomjinx

-- 
"I know exactly who reads the papers ...

The Daily Mirror is read by people who think they run the country.

The Guardian is read by people who think they ought to run the country.

The Times is read by people who do actually run the country.

The Daily Mail is read by the wives of the people who run the country.

The Financial Times is read by the people who own the country.

The Morning Star is read by the people who think the country ought to be
run by another country.

The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister



gtkpod-debian.tar.gz
Description: GNU Zip compressed data

Re: Debian rolling: tentative summary

[Josselin Mouette]

Le lundi 02 mai 2011 à 19:31 +0200, Goswin von Brederlow a écrit : 
> To those users that want newer software my next question would be "What
> software?". My feeling there is that it is only some software, allways
> the same software and used for the same use case: KDE / Gnome /
> Multimedia stuff for the Desktop.
> 
> Looking at the other group, those that cherish the slow release cycles
> and excelent stability and security support, shows a a large bias
> towards servers that are either completly headless or where people don't
> care about the latest sparkly desktop hype. They need to run and keep
> running without having to upgrade them every 6 month.
> 
> If my impression is right then maybe there is something to say for
> having a desktop and a server flavour like other distributions. It would
> be wastefull to have a rolling release with all sources included if the
> users only need a subset. The desktop users only want the new sparkly
> KDE / Gnome / Multimedia stuff. They do not care about the latest
> coreutils or latest postgresql.

I’ve seen such arguments to split the distribution between desktop and
server components many times, but I still don’t buy them.

First of all, the line is very hard to draw. The desktop requires server
components (for example Apache binaries), and some daemons require
desktop components (like Glib). Where do you put a GUI to configure
iptables? or the necessary components to make remote desktops?

If you want to make a distinction between users, make it between those
who want stable things maintained in the long term and those who want
always the latest stuff. But there are desktop users in the former
category and web applications developers in the latter.

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

Re: gtkpod packaging dependencies

[David Paleino]

On Mon, 02 May 2011 19:54:14 +0100, phantomjinx wrote:

> Hi,
> 
> Someone with the handle 'mfv' came into the gtkpod irc channel wondering
> about gtkpod dependencies as he was packaging it for debian.

I put him in CC.

David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Reporting same bug in different packages

[Patrick Strasser]

Hello!

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
* Something different

If d.devel.general is the wrong group, I beg you all pardon and would be
thankful for naming a proper group.

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

Re: Reporting same bug in different packages

[Amaya]

Patrick Strasser wrote:
> I want to report a bug, which occurs in two packages (okular, xpdf)
> exactly the same way. It's a problem with rendering PDFs.

Thanks for spotting this bug. Your contribution to Debian is
appreciated.

> What would be the right way:
> * File two bugs and refer to each other in a additional message

I was curious and took a look at these packages' Depends: field, and
they do not share many dependencies. I was suspecting a library would be
culprit in the bad rendering, but this doesn't seem the case, so, IMHO,
I would file a bug with each viewer, so that each code gets fixed. 
Including a reference to the same bug happening with other PDF viewers
would also be fine. Going the extra mile, I'd try this misterious PDF on
other viewers (evince, epdfview...) and report bugs accordingly.
But I'd really try to figure out weather it's not actually a font
problem, or a different kind of issue (which would not belong in a
discussion in debian-devel). 

> If d.devel.general is the wrong group, I beg you all pardon and would
> be thankful for naming a proper group.

I'm inclined to believe that discussing propper BTS handling does belong
here, but I might be wrong, and if so, would like to be corrected.

-- 
 .''`.  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/20110502204659.GM3099@aenima

Re: Reporting same bug in different packages

[Mehdi Dogguy]

On 05/02/2011 10:46 PM, Amaya wrote:

Patrick Strasser wrote:

I want to report a bug, which occurs in two packages (okular, xpdf)
exactly the same way. It's a problem with rendering PDFs.


Thanks for spotting this bug. Your contribution to Debian is
appreciated.


What would be the right way:
* File two bugs and refer to each other in a additional message


I was curious and took a look at these packages' Depends: field, and
they do not share many dependencies. I was suspecting a library would be
culprit in the bad rendering, but this doesn't seem the case, so, IMHO,
I would file a bug with each viewer, so that each code gets fixed.


Well, both do use libpoppler5… which is a PDF rendering library.

My 2cents,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.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/4dbf1a33.7010...@dogguy.org

Re: Reporting same bug in different packages

[Amaya]

Mehdi Dogguy wrote:
> Well, both do use libpoppler5… which is a PDF rendering library.

I knew it! :) 
I guess I missed it (wonder how on earth...)

-- 
 .''`.  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/20110502211845.GP3099@aenima

Re: gtkpod packaging dependencies

[Matteo F. Vescovi]

Hi!

On 02/05/2011 20:54, phantomjinx wrote:
> Hi,
> 
> Someone with the handle 'mfv' came into the gtkpod irc channel wondering
> about gtkpod dependencies as he was packaging it for debian.

It was me :-) Sorry if I didn't wait long enough for your direct reply.

> I have already produced an ubuntu ppa for the 2.0.1-beta so thought the
> debian directory would be useful.

Thanks a lot, really. Your help is really appreciated.
I hope I'll find a sponsor to upload it soon to unstable.

> Please find attached.
> 
> (Not registered so please cc any replies. Thanks).

Same here.

> Regards
> 
> phantomjinx

Cheers,

mfv


--
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
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/4dbf20ac.9000...@revese.it

Re: Reporting same bug in different packages

[Osamu Aoki]

Hi,

On Mon, May 02, 2011 at 07:20:12PM +0200, Patrick Strasser wrote:
> Hello!
> 
> 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

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

See clone under http://www.debian.org/Bugs/server-control


> * File one bug and refer to the second package
> * Something different

But as I understand, actual PDF rendering is done in libpoppler5 for
these.  If you file one of it, it is more likely to be forwarded to
libpoppler5.   (I am one of xpdf maintainers)

Osamu



-- 
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/20110502225502.ga22...@debian.org

Re: Bits from the Release Team - Kicking off Wheezy

[Russ Allbery]

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.

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

Re: Reporting same bug in different packages

[Osamu Aoki]

Hi,

On Mon, May 02, 2011 at 11:18:45PM +0200, Amaya wrote:
> Mehdi Dogguy wrote:
> > Well, both do use libpoppler5… which is a PDF rendering library.
> 
> I knew it! :) 
> I guess I missed it (wonder how on earth...)

Because you looked at okular first.  

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

Osamu


-- 
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/20110502230414.gb22...@debian.org

Re: Reporting same bug in different packages

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Le 02/05/2011 16:46, Amaya a écrit :
> Patrick Strasser wrote:

>> If d.devel.general is the wrong group, I beg you all pardon and would
>> be thankful for naming a proper group.
> 
> I'm inclined to believe that discussing propper BTS handling does belong
> here, but I might be wrong, and if so, would like to be corrected.

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.

  0: debian-u...@lists.debian.org

Regards

David

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

iQIcBAEBCAAGBQJNvzzlAAoJELgqIXr9/gnyQeMP/1Wl9/XV5hoHu2uDVN11Wggo
I/5nvMF5aSW3rZNx/iwcfiSjfiCezp8AkutNfYfyK59oqq+J5hLPlQMCRwRf4vJj
nWc3si0A4d6UE1XQC+bZfJ9biSvtZMSVti+HIz1Qtvm6h4u6pOhT2bshLhgWOnVa
hR7rwxxyqVIOQyd3xHiNE9jkFMwEZ4MFWg8XL5ilVEUBqusoy6n7sNkHo0BVp+hC
B8i55fZUoDtmKbeHsKd7m/UvuntYTItu99/O2VDmjs1M5ecTxthtAmki8b48zPBd
JSLiSuQUNWzCmaxA15Puj8+8ufVwrLbOl0z8t1IGdMbhIUHmVz4Kq+8qiKB7eslo
G3pR16uTMllFwfLLPh3SJuLHbkdNLus5q5DiKnhzqYZimcOs6JBN0trPUkHsxKwK
G+pzSBHkQXc0mbUUrIicnMAqncaFOrOAyAm7cwZNrwTrHCp3fMsqDmviEPgefOPl
FgQ3NDzQqZ39drTMSt43N2nCYt/pFGzkmlt68ZXE6JsQVWGvKd/+ssRQUajqqGZ9
gfks3XOxj/4ejlkpGd4g0xBWA1xZFE1nJK8obwbZ7XgsMKsFZZNbPIUn2nq7APOy
QDo3l4R96hc7X+ygxJiMY+VTwnNkcQ1gaPgryKqEy5zG/cqdQNc64y6DNnHfiVdT
LrAOjjwL5RMhIalABo1h
=wfim
-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/4dbf3ce6.7010...@tilapin.org

Re: PPAs for Debian

[Brian May]

On 30 April 2011 20:56, Stefano Zacchiroli  wrote:

> Some FAQ on this topic:
>
> Q: Why don't you use Launchpad's PPA?
> A: Last time I looked into it (together with some Launchpad engineers at
>   past UDS), the PPA module was too tightly integrated with other
>   Launchpad parts to be deployable on Debian infrastructure
>

I don't think it is currently possible to use  Launchpad's PPA to build
against non-Ubuntu distributions (or that is the impression I get anyway).

Would really like to see a PPA based system that supports building against
Debian stable and unstable.
-- 
Brian May 

Re: PPAs for Debian

[Yaroslav Halchenko]

On Sat, 30 Apr 2011, Stefano Zacchiroli wrote:
> Yes, absolutely. I'd even dare to say that having something like PPA for
> Debian is a priority. It would be yet another way to enable people to
> experiment with big changes in Debian, showing their value, with minimum
> impact on the work of others.

+10

Also, because Debian is the mothership, we might be kind to the "kids"
and Debian PPA could carry a selection of derivatives' (e.g. Ubuntus)
releases, thus providing the ultimate PPA hosting.

Sorry if I have missed it -- do we have anywhere (wiki) a page outlining
design/concerns/etc about PPA implementation in Debian .  It might be
worth getting it out so we could collect our thoughts.

-- 
=--=
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/20110503030422.go16...@onerussian.com

Re: gtkpod packaging dependencies

[Chow Loong Jin]

Julien was also working on it at the same time, so I'm adding him to CC as well.

On 03/05/2011 05:22, Matteo F. Vescovi wrote:
> Hi!
> 
> On 02/05/2011 20:54, phantomjinx wrote:
>> Hi,
>>
>> Someone with the handle 'mfv' came into the gtkpod irc channel wondering
>> about gtkpod dependencies as he was packaging it for debian.
> 
> It was me :-) Sorry if I didn't wait long enough for your direct reply.
> 
>> I have already produced an ubuntu ppa for the 2.0.1-beta so thought the
>> debian directory would be useful.
> 
> Thanks a lot, really. Your help is really appreciated.
> I hope I'll find a sponsor to upload it soon to unstable.
> 
>> Please find attached.
>>
>> (Not registered so please cc any replies. Thanks).
> 
> Same here.
> 
>> Regards
>>
>> phantomjinx
> 
> Cheers,
> 
> mfv
> 
> 
> --
> Ing. Matteo F. Vescovi
> 


-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

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

[Lucas Nussbaum]

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

Doing more investigation than what I currently do is impossible for me.
There are currently 1231 packages failing to build in sid. Yesterday, I
filed about 300 bugs about such packages, but there are still 403
packages with no bug filed[1]. I think that the priority is to file those
bugs so maintainers get aware of it, not to increase the quality of my
bug reporting, sorry.

Btw, help is needed (as always). Required skills are:
- interest in QA
- good investigation skills
- willingness to handle tasks on a regular basis, and keep doing
  them for a long time
The scripts to analyze logs and generate bug reports are in Ruby, so
it's also better if you can work in this language, though it's not
completely necessary.

[1] My script classifies failures based on the "kind" of failure (fail
to install build-depends, GCC or linking errors, etc.) For some kind of
failures, it can extract the error message automatically, but for some
others, it's harder to extract the "interesting" part of the log.
Usually, I file the easy bugs (no manual editing) first.

- 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/20110503052128.ga8...@xanadu.blop.info

Re: Debian rolling: tentative summary

[Cristian Henzel]

Hello,


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.


-- 

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/4dbf97dd.4080...@b3r3.info