Re: glibc: causes segfault in Xorg

[Josselin Mouette]

Le mercredi 04 mai 2011 à 14:58 +0100, Jon Dowland a écrit : 
> > So it's best if you consider unstable always in production-mode by default.
> 
> I disagree with this.  We expect *our* users of sid to use things like
> apt-listbugs and to be wary of blindly upgrading.  I think we should hold
> downstream distributions to higher standards.  If a downstream distribution
> blindly accepts a libc from sid and it doesn't do what they want, imho that's
> their fault.  Especially with a core package.
> 
> I'm concerned that this attitude, if adopted elsewhere, would paralyze Debian
> development, for fear of inconveniencing other distributions.

The point is not to paralyze Debian development, but you should never
upload to unstable a package that you *know* is broken. Uploading to
unstable means “this should be good enough for a stable release, but it
hasn’t been tested against the rest of the distribution”.

We usually don’t upload upstream development releases to unstable, yet I
don’t see this as “paralyzing Debian development”.

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


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

Re: A concrete proposal for rolling implementation

[Josselin Mouette]

Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : 
> > Could you please give a concrete example of where this would be needed?
> > I think all existing cases should be covered by uploading directly to
> > either t-p-u or unstable.
> 
> Use case:
> During freeze, there's a library transition in unstable, and a new
> upstream version in unstable. You want to get the new upstream version
> into rolling (not testing), but you can't because it would pull the
> whole transition.

You don’t need to pull the whole transition, that’s the point of my
proposal. You just need to put the library being transitioned and your
package. 

> So you need a way to upload the new upstream version linked against the
> libraries in rolling.

Alternatively, if testing is so broken you need that new upstream
version and it can build against the testing libraries, you can use
testing-proposed-updates - in all cases, for both testing and rolling, a
targeted fix being preferable.

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


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

Re: A concrete proposal for rolling implementation

[Raphael Hertzog]

Hi,

On Wed, 04 May 2011, sean finney wrote:
> It's an excellent idea.  Some of the initial feedback that I've gotten
> about DEP-10 (in particular some brainstorming on IRC with Carsten Hey)
> is pointing at ideas along these lines, and I hope to flush them out
> in a bit more detail RSN.  But I think it's particularly exciting that
> these two ideas (rolling, and dealing with freezes) might not conflict
> with each other, and perhaps complement one another.
> 
> One issue that would need to be addressed with experimental is that
> opening a migration route anywhere out of experimental might come as
> an unpleasant surprise to some, since there's a standing expectation
> that it's a pseudo-suite where we can put stuff that we don't necessarily
> want to try out in unstable.  Not an insurmountable problem (either we
> change that or introduce yet another psuedo-suite for this purpose),
> but worth note anyway.

Yeah, experimental is not really the good place. We really want in
rolling only packages where we have the assurance that they will land
in unstable the day after the release (so automatically and not with
a manual source upload).

So I'd favor some sort of unstable overlay that is not experimental.
It could be called "unstable-next" and could be auto-generated from
uploads targetting unstable that introduce a new upstream version.
That way by default unstable doesn't move forward with new upstream
version and can always be used to upload bugfixes targetting testing.

Auto-building in unstable-next would be like experimental, i.e. it
would be built in unstable so that it's still possible to pick
packages there in the rare case where a new upstream version is
desired late in the release cycle.

I like where this is going! :)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110505064610.gd30...@rivendell.home.ouaza.com

Re: A concrete proposal for rolling implementation

[Lucas Nussbaum]

On 04/05/11 at 22:19 +0200, Josselin Mouette wrote:
> Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : 
> > While I like the idea in general, I think that it should also be
> > possible to upload packages directly to rolling (through
> > rolling-proposed-updates). It will be useful in cases where neither the
> > package in testing, not the package in unstable, can be used to fix a
> > problem in rolling.
> 
> Adding this possibility is opening Pandora’s box. Once you allow this,
> people start using packages that are neither in unstable nor in testing,
> and they don’t help us working on our packages at all. This also adds an
> extra burden on maintainers who want to use this feature.
> 
> Could you please give a concrete example of where this would be needed?
> I think all existing cases should be covered by uploading directly to
> either t-p-u or unstable.

Use case:
During freeze, there's a library transition in unstable, and a new
upstream version in unstable. You want to get the new upstream version
into rolling (not testing), but you can't because it would pull the
whole transition.
So you need a way to upload the new upstream version linked against the
libraries in 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/20110505062334.ga3...@xanadu.blop.info

Re: glibc: causes segfault in Xorg

[Raphael Hertzog]

On Wed, 04 May 2011, Russ Allbery wrote:
> Jon Dowland  writes:
> > On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:
> 
> >> While I can sympathize with this (it's what I want as a developer),
> >> it's certainly not a good idea in Debian in general: we have many
> >> derivatives taking unstable/testing at various points in time, and we
> >> also want to make testing generally usable by end-users.
> 
> I don't think mixing unstable and testing here as if they're the same
> thing is warranted.  If we get common crashes, that's going to become an
> RC bug fairly quickly, and won't be propagated to testing.

Yeah, I would have liked to be able to respond: "OK for unstable, not OK for
testing". Unfortunately that's not the way it works.

We'll discover the problem in unstable fairly quickly but unfortunately
the bugs in the applications are already present in testing since the
change of behaviour of the library causes a regression in the application.

So ideally we should have in unstable the library with the new behaviour
and keep in testing the old behaviour until all the fixed applications
have made it to testing.

This is of course doable with "Breaks" once we know the affected
application (but that itself requires a lots of time) but it's a pain in
the case of something like libc6 that you want to see migrated soon enough
because it has the potential to make transitions very hard.

A way to implement this is to have a first upload with the change of
behaviour reverted, have it migrate quickly, do another upload and restore
the new behaviour and open an RC bug to keep this version out of testing.
Not very practical to say the least... (there's also the possibility to
have a t-p-u upload with the revert)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110505062832.gc30...@rivendell.home.ouaza.com

Re: A concrete proposal for rolling implementation

[Pierre Habouzit]

On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote:
> >   What to do during freezes
> >   -
> > I’m not sure we really need to do something different in times of
> > freeze. Our time would be better spent by reducing the freeze time and
> > making it more predictable; squeeze has been an awesome step in this
> > direction.
> >
> > If we want to do something different though, there is a simple recipe:
> > allow packages to be picked up from unstable, but also from
> > experimental. Again, no disruption: people can keep on breaking some
> > pieces of experimental, but if they want some other pieces to be useful
> > for rolling users, they just need to be committed to more carefulness
> > and to add them to the override file.
> 
> I also find this a very good implementation, although I would like a 'true'
> rolling release, without any freezes at all. I'm not sure how much extra work 
> it
> implies or how much sense it would make to have an exact clone of testing just
> without the freezes.

Not a lot, I don't expect it larger than having to place a dozen hints
usually, up to a small hundred during the peaks (100 is less than 1% of
our source packages).

Maintaining something like that isn't hard, it's already what the RM
Team does to follow testing migrations, and if rolling is generated
after testing is, the Rolling Team will benefit from the RT work so it's
just an incremental effort. Nothing wasted.

(And not wanting to finger point but I've read at least a certain RT
Member saying that he would even consider help a Rolling Team as he's
already doing that pinning on his workstation…)
-- 
·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/20110505055010.gb26...@madism.org

Re: A concrete proposal for rolling implementation

[Pierre Habouzit]

On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote:
> * Pierre Habouzit [2011-05-04 22:23 +0200]:
> > On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote:
> > > Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit :
> > > > While I like the idea in general, I think that it should also be
> > > > possible to upload packages directly to rolling (through
> > > > rolling-proposed-updates). It will be useful in cases where neither the
> > > > package in testing, not the package in unstable, can be used to fix a
> > > > problem in rolling.
> > >
> > > Adding this possibility is opening Pandora’s box. Once you allow this,
> > > people start using packages that are neither in unstable nor in testing,
> > > and they don’t help us working on our packages at all. This also adds an
> > > extra burden on maintainers who want to use this feature.
> > >
> > > Could you please give a concrete example of where this would be needed?
> > > I think all existing cases should be covered by uploading directly to
> > > either t-p-u or unstable.
> >
> > Agreed, the entry point for rolling is clearly just unstable + a force
> > hint. Why would you need to upload something to rolling that you
> > couldn't make enter through unstable?
> 
> If more new upstream versions are uploaded to unstable (because they are
> targeted at rolling), it raises the number of RC bugs needing to migrate
> to testing through t-p-u.  How would you ensure that they get enough
> testing before entering testing?

That's the point, you don't target rolling, your goal is still to make
stuff migrate into testing, rolling is just the extra few packages
testing needs to fix the most important breakages that happen (e.g. your
PAM example, or large migrations where dependencies across libraries are
too loose and break testing, Joss said it happens to gnome quite a lot
e.g.).

IOW to target rolling you target testing, IOW you help doing stable
stuff, isn't that nice?
-- 
·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/20110505054655.ga26...@madism.org

Re: glibc: causes segfault in Xorg

[Steve M. Robbins]

On Wed, May 04, 2011 at 01:34:15PM +0200, sean finney wrote:

> And furthermore, even if Debian chooses to "fix" this, upstreams will
> be forced to eventually cater to the default glibc behavior for every
> other libc distro out there that does not have their own "fix" (and
> non-libc OS's where this behavior already exists), 

That's fine: let others be the guinea pigs, then introduce the
optimized memcpy later when the rest of the world has adapted.

> so gains would be potentially limited.

For me, having a working system would be a great gain!


> That said, regressions do suck, especially when they take the form of
> heisenbugs.  But one could easily hack something LD_PRELOAD'able check
> for stuff like this without forcing a global change.

Sounds interesting.  What do you have in mind?

-Steve


signature.asc
Description: Digital signature

Re: glibc: causes segfault in Xorg

[Steve M. Robbins]

On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins"  wrote:
> 
> Hi,
> 
> > I'm with Linus on this: let's just revert to the old behaviour.  A
> > tiny amount of clock cycles saved isn't worth the instability.
> 
> Tiny amount?! The optimized memcpy() variants that break shitty code
> bring a 4 to 5x speedup on the processors they've been written for!

Though I didn't see any actual time measurements in the bug thread, I
am sure there is a speedup of some kind for the memcpy() call itself.
I'm not interested in that. 

I am interested to know the speedup -- measured in real-world
conditions -- for actual, popular applications.

But I'm really not interested that much.  I'm really interested in
having a running system.  Yes, even one with buggy software that
happens to be important to me.

Cheers,
-Steve


signature.asc
Description: Digital signature

Has anyone attempted a tomcat7 package?

[Ernesto Hernández-Novich]

I've been trying to build a tomcat7 package based on the existing
tomcat6 package. After fiddling with it for a while, I've managed to
"build" what looks like a working binary, but I get a backtrace when the
services starts.

The relevant part of the backtrace is

java.lang.NoClassDefFoundError: org/apache/tomcat/util/res/StringManager
at org.apache.catalina.startup.Catalina.(Catalina.java:80)
...
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:406)

meaning there's a missing class.

I found the reference to the class in build.xml however I have no idea
why it's not being built nor what should I do in debian/rules to install
it in its proper place. I've run ant manually and gotten the file to
build, and attempted putting it in tomcat's class search path, but the
problem persists.

If anyone is working on a tomcat7 package, or can shed light on what I'm
supposed to do next, I'd appreciate any pointers.

Thanks in advance!
-- 
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3


-- 
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/1304556130.4104.248.ca...@deepthought.ius.cc

Re: A concrete proposal for rolling implementation

[Fernando Lemos]

On Wed, May 4, 2011 at 6:40 PM, sean finney  wrote:
[...]
> On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote:
>> On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
>> >   What to do during freezes
>> >   -
>> > If we want to do something different though, there is a simple recipe:
>> > allow packages to be picked up from unstable, but also from
>> > experimental.
>>
[...]
>
> One issue that would need to be addressed with experimental is that
> opening a migration route anywhere out of experimental might come as
> an unpleasant surprise to some, since there's a standing expectation
> that it's a pseudo-suite where we can put stuff that we don't necessarily
> want to try out in unstable.  Not an insurmountable problem (either we
> change that or introduce yet another psuedo-suite for this purpose),
> but worth note anyway.

Indeed. I guess we could specify a flag in this overrides file that
says whether or not it's fine to fetch from experimental (defaulting
to off). That way it would be up to the maintainer to specify that
experimental is good and stable enough for rolling.

I really like this new proposal, nice job.

Regards,


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

Re: A concrete proposal for rolling implementation

[sean finney]

Hiya,

On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote:
> On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
> >   What to do during freezes
> >   -
> > If we want to do something different though, there is a simple recipe:
> > allow packages to be picked up from unstable, but also from
> > experimental.
> 
> Yes, absolutely. This seems straightforward, elegant, and useful as it
> encourages maintainer to push their changes to the Debian archive and
> make them visible and testable to rolling users, even when unstable is
> de facto closed.

It's an excellent idea.  Some of the initial feedback that I've gotten
about DEP-10 (in particular some brainstorming on IRC with Carsten Hey)
is pointing at ideas along these lines, and I hope to flush them out
in a bit more detail RSN.  But I think it's particularly exciting that
these two ideas (rolling, and dealing with freezes) might not conflict
with each other, and perhaps complement one another.

One issue that would need to be addressed with experimental is that
opening a migration route anywhere out of experimental might come as
an unpleasant surprise to some, since there's a standing expectation
that it's a pseudo-suite where we can put stuff that we don't necessarily
want to try out in unstable.  Not an insurmountable problem (either we
change that or introduce yet another psuedo-suite for this purpose),
but worth note anyway.


sean


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

Re: gtkpod packaging dependencies

[phantomjinx]

On 02/05/11 22: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
>

Hi Matteo,

Just found your question in gtkpod irc.

Not quite certain what you were asking about the copyrights. I think ...

The AUTHORS file in the gtkpod source is the most accurate record of all
the authors. Probably a couple more besides so always essential to add
the line about "others past and present".

Any other info then ask away.

Regards

PGR

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


-- 
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/4dc1c3c8.4030...@phantomjinx.co.uk

Re: A concrete proposal for rolling implementation

[Cristian Henzel]

>   What to do during freezes
>   -
> I’m not sure we really need to do something different in times of
> freeze. Our time would be better spent by reducing the freeze time and
> making it more predictable; squeeze has been an awesome step in this
> direction.
>
> If we want to do something different though, there is a simple recipe:
> allow packages to be picked up from unstable, but also from
> experimental. Again, no disruption: people can keep on breaking some
> pieces of experimental, but if they want some other pieces to be useful
> for rolling users, they just need to be committed to more carefulness
> and to add them to the override file.

I also find this a very good implementation, although I would like a 'true'
rolling release, without any freezes at all. I'm not sure how much extra work it
implies or how much sense it would make to have an exact clone of testing just
without the freezes.

-- 

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/4dc1bf92.7050...@b3r3.info

Re: A concrete proposal for rolling implementation

[Scott Kitterman]

On Wednesday, May 04, 2011 04:25:35 PM Stefano Zacchiroli wrote:
> On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
> >   What to do during freezes
> >   -
> > 
> > If we want to do something different though, there is a simple recipe:
> > allow packages to be picked up from unstable, but also from
> > experimental.
> 
> Yes, absolutely. This seems straightforward, elegant, and useful as it
> encourages maintainer to push their changes to the Debian archive and
> make them visible and testable to rolling users, even when unstable is
> de facto closed.

Does this mean Experimental should be renamed Unfrozen?

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/201105041658.32267.deb...@kitterman.com

Re: A concrete proposal for rolling implementation

[Carsten Hey]

* Pierre Habouzit [2011-05-04 22:23 +0200]:
> On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote:
> > Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit :
> > > While I like the idea in general, I think that it should also be
> > > possible to upload packages directly to rolling (through
> > > rolling-proposed-updates). It will be useful in cases where neither the
> > > package in testing, not the package in unstable, can be used to fix a
> > > problem in rolling.
> >
> > Adding this possibility is opening Pandora’s box. Once you allow this,
> > people start using packages that are neither in unstable nor in testing,
> > and they don’t help us working on our packages at all. This also adds an
> > extra burden on maintainers who want to use this feature.
> >
> > Could you please give a concrete example of where this would be needed?
> > I think all existing cases should be covered by uploading directly to
> > either t-p-u or unstable.
>
> Agreed, the entry point for rolling is clearly just unstable + a force
> hint. Why would you need to upload something to rolling that you
> couldn't make enter through unstable?

If more new upstream versions are uploaded to unstable (because they are
targeted at rolling), it raises the number of RC bugs needing to migrate
to testing through t-p-u.  How would you ensure that they get enough
testing before entering testing?

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/20110504204846.ga27...@furrball.stateful.de

Bug#625652: ITP: morfeusz -- morphological analyser of Polish

[Jakub Wilk]

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: morfeusz
  Version : 20110416
  Upstream Author : Zygmunt Saloni, Włodzimierz Gruszczyński,
Marcin Woliński, Robert Wołosz
* URL : http://sgjp.pl/morfeusz/
* License : BSD-2-clause
  Programming Lang: C++, Perl
  Description : morphological analyser of Polish

Lexeme is an abstract entity of language, a word in the dictionary 
sense. Word form is a word that has been interpreted — ascribed to a 
particular lexeme and described as for its grammatical function.


Morphological analysis consists in determining all forms of all lexemes 
for a particular word, that it is an exponent of. The context, in which 
the word has appeared, is not taken into consideration in this process. 


Morfeusz carries out a morphological analysis for Polish.

--
Jakub Wilk



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

Re: PPAs for Debian

[Pierre Habouzit]

On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote:
> PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I 
> think are quite another.  I'd hate to see Debian make the same mistake that 
> Canonical did in this regard.

PPA on Debian infrastructure should be limited to people with a key in
the keyring.

Though we should make the software available for people to build their
own PPA infrastructure easily.

-- 
·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/20110504203954.gb21...@madism.org

Re: A concrete proposal for rolling implementation

[Pierre Habouzit]

On Wed, May 04, 2011 at 10:17:03PM +0200, Stefano Zacchiroli wrote:
> If you want to go ahead with patching britney, by all means go ahead, as
> it might provide patches useful for the main brintey as well. But if you
> want to try some alternatives, we can probably help.

I don't think you need to patch britney at all. Just take the last
testing computed as a testing-britney output as a start, have a list of
force-hints to be processed, taken from unstable, and there you go. It's
just a new britney run.

Admitedly there is a small patch to be done, force hints in britney are
strictly versionned, for the rolling case one may want to have looser
way to express force hints (with version ranges e.g.), but that should't
be really hard.
-- 
·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/20110504202724.gb20...@madism.org

Re: A concrete proposal for rolling implementation

[Pierre Habouzit]

On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote:
> Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : 
> > While I like the idea in general, I think that it should also be
> > possible to upload packages directly to rolling (through
> > rolling-proposed-updates). It will be useful in cases where neither the
> > package in testing, not the package in unstable, can be used to fix a
> > problem in rolling.
> 
> Adding this possibility is opening Pandora’s box. Once you allow this,
> people start using packages that are neither in unstable nor in testing,
> and they don’t help us working on our packages at all. This also adds an
> extra burden on maintainers who want to use this feature.
> 
> Could you please give a concrete example of where this would be needed?
> I think all existing cases should be covered by uploading directly to
> either t-p-u or unstable.

Agreed, the entry point for rolling is clearly just unstable + a force
hint. Why would you need to upload something to rolling that you
couldn't make enter through unstable?
-- 
·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/20110504202329.ga20...@madism.org

Re: A concrete proposal for rolling implementation

[Josselin Mouette]

Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : 
> While I like the idea in general, I think that it should also be
> possible to upload packages directly to rolling (through
> rolling-proposed-updates). It will be useful in cases where neither the
> package in testing, not the package in unstable, can be used to fix a
> problem in rolling.

Adding this possibility is opening Pandora’s box. Once you allow this,
people start using packages that are neither in unstable nor in testing,
and they don’t help us working on our packages at all. This also adds an
extra burden on maintainers who want to use this feature.

Could you please give a concrete example of where this would be needed?
I think all existing cases should be covered by uploading directly to
either t-p-u or unstable.

Cheers,
-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: A concrete proposal for rolling implementation

[Stefano Zacchiroli]

On Wed, May 04, 2011 at 03:30:40PM +0200, Raphael Hertzog wrote:
> On Wed, 04 May 2011, Josselin Mouette wrote:
> > It starts from the following fact: if you want a testing system that
> > works correctly, you usually have to add APT lines for unstable, while
> > pinning them to only install specific packages you need to unbreak
> > what’s broken in unstable.

Thanks for the proposal, it looks really interesting!
A few comments and some potential help/directions are below.

> It doesn't need to be a pseudo-suite. It's a collection of packages taken
> in testing or unstable, it's not more complicated to make it a full suite.
> 
> And PR-wise, it's way better to avoid "testing" appearing in the
> sources.list.

I don't think that the name showing up in sources.list are important for
PR reasons. The "problem" with the current testing marketing (for those
who buy PR arguments) is not the sources.list line, but that the suite
is called that way everywhere and advertised solely as the developer /
internal suite that it is. If we advertise "rolling" with that name (and
proper explanation), what is in sources.list wouldn't really matter.

Still, having a single suite sounds more flexible: we will be able to
control the whole set of rolling packages server side, no matter what is
currently in testing. Not that I can imagine a reason for doing that
now, but having that flexibility sounds good. (And you have already
discussed that it is possible to have.)

> > The rolling suite would only exist for a subset of architectures (we
> > could start with powerpc, i386 and amd64), generated by picking up
> 
> Why powerpc? If we really take more than i386/amd64 for rolling, there
> are more users of armel than of powerpc.

Beside the specific choices of architectures, I'm not sure I see which
specific problem architectures bring into the game. For testing proper,
there are some architecture alignment rules that might make transition
more complex. But for rolling as it is being proposed here, it looks
like that with per-architecture overrides we can support whatever
architecture sets we please.

Are there other constraints than manpower for the overrides that I'm
overlooking?  (Note: I'm not arguing that we should have rolling for all
archs, I'm just trying to understand if I've overlooked some
constraints.)

> You still need some sort of britney to verify that the package is effectively
> installable in rolling, and to verify you're not breaking installability
> of other packages available in rolling.

If you only need installability test for binaries (and possibly even
satisfaiability of build-depends, which is currently not checked by
britney but used on buildds), edos-distcheck offers that out of the box.
It would most likely be way easier to setup than britney.  For some of
the other needs expressed by Joss, we (as in Mancoosi) have most of the
code ready as well, although not necessarily packaged yet. I need to
look at the details of what Joss had in mind, but we have code ready to
answers questions like "which package do I absolutely need to be
installable in that suite?".

If you want to go ahead with patching britney, by all means go ahead, as
it might provide patches useful for the main brintey as well. But if you
want to try some alternatives, we can probably help.

> > What do you think?
> +1 from me. Thank you for the proposal!

Ditto!

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: A concrete proposal for rolling implementation

[Lucas Nussbaum]

On 04/05/11 at 14:24 +0200, Josselin Mouette wrote:
> Hi,
> 
> during the recent discussions about rolling, a proposal was made in a
> blog comment, and after giving it some quick thoughts, most people I’ve
> talked with seem to think it is a good idea, so it’s time for it to be
> discussed at large.
> 
> It starts from the following fact: if you want a testing system that
> works correctly, you usually have to add APT lines for unstable, while
> pinning them to only install specific packages you need to unbreak
> what’s broken in unstable.
> 
> The idea is to make this process automatic. Let me elaborate.
> 
>   The new “rolling” suite
>   ---
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.
> 
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4
> ...
> The rolling suite would try to have a package that has *at least* this
> version. If it is found in testing, the package is removed from rolling.
> If otherwise it is found in unstable, the package is picked from
> unstable.
> 
> This way, when something is broken in testing and cannot be unbroken
> quickly, a maintainer who notices it could add (or make the people in
> charge add) the necessary packages to the override file. If, for a
> reason or another, an important bug fix or a security update doesn’t
> propagate to testing quickly enough, you can now just add it and the
> necessary dependencies to rolling, and people using it aren’t affected.
> Whenever the affected packages finally migrate to testing, the
> discrepancy between rolling and testing automatically disappears.
> 
> The reason for the “at least” version rule is that new uploads to
> unstable are supposed to fix the situation in testing anyway. I don’t
> think we should keep in rolling packages that are no longer in unstable.

While I like the idea in general, I think that it should also be
possible to upload packages directly to rolling (through
rolling-proposed-updates). It will be useful in cases where neither the
package in testing, not the package in unstable, can be used to fix a
problem in 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/20110504201222.ga31...@xanadu.blop.info

Re: glibc: causes segfault in Xorg

[Russ Allbery]

Jon Dowland  writes:
> On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:

>> While I can sympathize with this (it's what I want as a developer),
>> it's certainly not a good idea in Debian in general: we have many
>> derivatives taking unstable/testing at various points in time, and we
>> also want to make testing generally usable by end-users.

I don't think mixing unstable and testing here as if they're the same
thing is warranted.  If we get common crashes, that's going to become an
RC bug fairly quickly, and won't be propagated to testing.

>> So it's best if you consider unstable always in production-mode by
>> default.

> I disagree with this.  We expect *our* users of sid to use things like
> apt-listbugs and to be wary of blindly upgrading.  I think we should
> hold downstream distributions to higher standards.  If a downstream
> distribution blindly accepts a libc from sid and it doesn't do what they
> want, imho that's their fault.  Especially with a core package.

> I'm concerned that this attitude, if adopted elsewhere, would paralyze
> Debian development, for fear of inconveniencing other distributions.

+1

unstable is exactly the place to check this sort of thing, IMO.

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

Bug#625636: ITP: mccs -- multi-critera CUDF solver

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: mccs
  Version : 1.0
  Upstream Author : Claude Michel 
* URL : http://users.polytech.unice.fr/~cpjm/misc/mccs.html
* License : BSD
  Programming Lang: C
  Description : multi-critera CUDF solver
 mccs is a solver for package dependencies expressed in the CUDF
 format.  It takes as input a CUDF problem and computes the best
 solution according to a combination of optimization criteria chosen
 by the user. Basic criteria to be maximized or minimized may be
 selected from a list of pre-defined criteria, and these can be
 combined using using various aggregation operators. It relies on an
 Integer Programming solver or a Pseudo Boolean solver to achieve its
 task. The version of mccs distributed with this package uses cbc as 
 underlying solving engine, however, mccs may also be used together with
 other solvers like Cplex, Gurobi, Lpsolver, Glpk, SCIP or WBO.

-Ralf.



-- 
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/20110504181402.7218.70420.report...@seneca.free.fr

Re: Bits from the Release Team - Kicking off Wheezy

[Gunnar Wolf]

Marc 'HE' Brockschmidt dijo [Mon, May 02, 2011 at 09:15:38AM +0200]:
> > 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.

FWIW... Splitting developers' focus this way does not only mean some
of us are bound to ignore rolling (as we care about stable), but the
opposite - Some of us will ignore stable (as we package stuff that
caters better to rolling).

Of course, some packages could be hinted never to enter stable, or
stuff like that... But I do feel that, although I overall like the
rolling proposal, it is bound to dillute attention and, therefore,
overall QA.


-- 
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/20110504165042.ga16...@gwolf.org

Re: A concrete proposal for rolling implementation

[Ansgar Burchardt]

Hi,

Josselin Mouette  writes:
>   The new “rolling” suite
>   ---
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.
>
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4

I don't think this needs to be restricted to a subset of architectures
when you allow "rolling" to pick different versions[1] for each arch.

  [1] including none if the required version is not available in unstable

>   A concrete example
>   --
> Let’s imagine something that might happen soon (although of course we
> will try hard for it not to happen): a new version of nautilus migrates
> to testing, but it was missing a Breaks - it doesn’t work with the
> version of gnome-settings-daemon in testing. The new
> gnome-settings-daemon in unstable works, but it won’t migrate because
> there is a libgnomekbd transition in progress, and gnome-screensaver
> which is part of the transition doesn’t build on s390.
>
> In this case, we can just add libgnomekbd and gnome-settings-daemon to
> the override file. Users of the rolling suite will have the two versions
> of libgnomekbd available, and they can update their systems to a working
> state.

In this case, you could add the newer version to "rolling" for all
architectures except s390.  This way all users not using s390 could
already upgrade to the new version.

Ansgar


--
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/s2saaf2tqba@bistromathics.mathi.uni-heidelberg.de

Re: PPAs for Debian

[Scott Kitterman]

On Wednesday, May 04, 2011 12:34:45 PM Gunnar Wolf wrote:
> Paul Tagliamonte dijo [Wed, May 04, 2011 at 12:16:54AM -0400]:
> > > AFAIU, only DD and DM could create PPA and upload to them. If this is
> > > not the case, then I share your fears.
> > 
> > Usage of the PPA system on LP requires that you agree to the usage
> > terms (not unlike machine usage policies for Debian).
> > 
> > We let non-MOTU upload to their own PPAs (has their name in the URL),
> > and if nonfree (or malicious) packages are uploaded, they can have PPA
> > rights removed.
> 
> How do you ensure the identity of the uploaders? If my acount gets
> forbidden, what protection is there so I don't just create a new one?

This is no protection nor any identity checks for uploaders with the Launchpad 
PPAs.

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/201105041240.32799.deb...@kitterman.com

Re: PPAs for Debian

[Gunnar Wolf]

Marc 'HE' Brockschmidt dijo [Wed, May 04, 2011 at 10:42:31AM +0200]:
> (...)
> If anyone would have actually read the PPA proposal, they would know
> that uploads were and are intended to be restricted to DDs and DMs
> (which can break buildds anyway, if they want) and building should
> happen in throw-away chroots (not for security, but "don't mess with my
> system" reasons).

Oh... well, I took some time today to read through this gigantic
thread (expecting erupting flames but finding very interesting
discussions instead!), and had not reached this point. If Debian-PPAs
are to be limited to DDs and DMs (and I'd add non-uploading DDs), my
points about identifications can be perfectly ignored.


-- 
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/20110504163800.gg15...@gwolf.org

Re: PPAs for Debian

[Gunnar Wolf]

Paul Tagliamonte dijo [Wed, May 04, 2011 at 12:16:54AM -0400]:
> > AFAIU, only DD and DM could create PPA and upload to them. If this is not
> > the case, then I share your fears.
> 
> Usage of the PPA system on LP requires that you agree to the usage
> terms (not unlike machine usage policies for Debian).
> 
> We let non-MOTU upload to their own PPAs (has their name in the URL),
> and if nonfree (or malicious) packages are uploaded, they can have PPA
> rights removed.

How do you ensure the identity of the uploaders? If my acount gets
forbidden, what protection is there so I don't just create a new one?


-- 
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/20110504163445.gf15...@gwolf.org

Re: PPAs for Debian

[Gunnar Wolf]

Stefano Zacchiroli dijo [Sat, Apr 30, 2011 at 12:56:15PM +0200]:
> > I think it would make quite sense to get something like e.g. ppa done for
> > Debian. But thats something else than it's proposed here.
> 
> Yes, absolutely. I'd even dare to say that having something like PPA for
> Debian is a priority. 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.

Fully agree here.

> It happens that I've a recent update on this topic to share. There were
> some concerns about the need of something like a NEW queue for Debian's
> PPA, for legal reasons. I had a long phone call with SPI lawyer about
> this just yesterday. It turns out that there are a few provisions we
> should follow to stay on the safe side, but there is no specific blocker
> either. We can go ahead, individual maintainers will be responsible of
> what they upload / distribute via PPA.

Here I think we would be facing two different use cases, which impose
very different results:

• A PPA-like can be used by a Debian-related person (DD/DM/Dwhatever),
  and we trust the credentials they have already presented as personal
  identification (so what you stated can be held)

• But at least AFAICT, Canonical's PPAs allow also non-Ubuntu-related
  people to maintain their own repositories. That's a great way for
  them to start getting acquinted with the technical processes and get
  closer to becoming officialy affiliated. I have also seen it as a
  common distribution channel for independent projects.

The second use case might be what I feel as most attractive - Yes, I
maintain a couple of personal apt repos with things not really
suitable for Debian, some of which I could move to a PPA were it
available, but a non-Debianer might find it harder (and less
motivating) to learn the details of setting up his repo.

But we should then look into how we can ensure personal identification
- Would we keep the key reachability requirement? I think it's the
least we could do. If contributors cannot be identified, then I guess
responsability would fall upon the project, as infrastructure
providers, right?

Greetings,


-- 
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/20110504163132.ge15...@gwolf.org

Re: A concrete proposal for rolling implementation

[Pierre Habouzit]

On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote:
>   The new “rolling” suite
>   ---
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.

This is an excellente proposal which technically can be implemented this
way:

  - having a new britney instance, which is chained to the result of the
"testing" britney.

  - it is fed with a new hint file composed of "forced" migrations
(those are versionned), feeding the result of the testing britney
with sid.

  - result is a new release only made of testing or unstable packages.

If you find the people wanting to make up the rolling team, I think it's
a few hours work to setup (and overhead on the ftp servers would just be
minimal: a new suite and associated Packages files, nothing more).

Doing it this way:
  - leverages the same tools as what we have now (britney, dak);

  - only uses packages either in unstable or testing, which makes
rolling a glorified Pin-file hence people using rolling don't
diverge from the stable release work and are actually *worthwile*
bug reporters and gives more coverage on testing *excellent*.

  - benefits from the release work: e.g. if a package is removed from
testing, since rolling is recreated from that, it inherits that
(nothing prevents the rolling team to force it back for whichever
reason).

  - allows to take snapshots of rolling on a semi-regular basis (with
associated d-i releases). E.g. every 3 months or so. Those would be
alphas before the freeze, and betas during the freeze.


I like it a lot, I'm even finding it useful: it looks like it resolves
the rolling issues for people (wrt having something like a 'Usable'
testing), but doesn't really forks testing, only glorified pinning
managed at the project level instead of on each other's machines. But it
doesn't make those users worthless to the release team, quite the
contrary.

It could even turn-up to become a useful release tool.

I just love that proposal. At least something technical that makes
sense, thanks Joss.
-- 
·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/20110504161129.gh27...@madism.org

Re: A concrete proposal for rolling implementation

[Josselin Mouette]

Le mercredi 04 mai 2011 à 16:20 +0200, Raphael Hertzog a écrit : 
> A full suite can have 2 versions of the same source package and
> can contain both libgnomekbd4 and libgnomekbd7. It's not a problem.

OK, so I officially do not care a shit™.

> > What the britney-like thing could do is bring automatically all
> > dependencies that are actually necessary for the package to be
> > installable. But this could also make things more complicated, since
> > britney tests source packages, not binaries. You might bring a source in
> > rolling only for a runtime that is needed, but the development header
> > being uninstallable is not a problem. Britney would prevent that, while
> > it would still be a good move.
> 
> Yes, we could try to improve britney towards this.
> 
> But I'm not sure it's a good idea to pick only some binary packages from a
> source package. It happens often enough that the package lack a strict
> dependency that might be required and picking all the binaries from a
> source package limits the risk of upgrading them separately (and thus
> experiencing the bug).

Indeed. The appropriate result to obtain would be something like: “the
list of source packages you need to pull for a given binary package to
be installable”.

> > I’m not entirely sure, but I think it’s better to pick the update from
> > unstable instead of letting in rolling a package that is no longer
> > available somewhere else. It should make upgrades smoother, and it
> > should also be less work for maintainers, since it avoids having another
> > version from which problems can arise.
> 
> In that case, those updates should follow the same rules than for testing
> itself. It would be unreasonable to accept the new unstable upload
> immediately.

I don’t think it would be entirely unreasonable, since we’re already in
the case of a specific package we had to pull from unstable, to expect
the maintainer to be careful enough. Don’t forget that we’re talking
about probably a dozen of packages at a given time.
Of course, having a delay before accepting the package seems sensible
too, so it’s not like I really care.

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

Re: Bits from the Release Team - Kicking off Wheezy

[Pierre Habouzit]

On Tue, May 03, 2011 at 04:49:42PM +0200, Jan Hauke Rahm wrote:
> On Tue, May 03, 2011 at 01:31:24PM +0200, Pierre Habouzit wrote:
> > On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote:
> > > It is clear from the discussion that there would be consequences. Some
> > > would be negative, some positive. I think that we have now a pretty good
> > > understanding of the possibilities and their consequences. The remaining
> > > problem is to count DDs heads in the two camps:
> > > - "Let's focus on stable releases. A rolling release should not be
> > >provided officially by Debian."
> > > - "Let's see what we can do about rolling, provided we find a way to do it
> > >without diminishing the quality of our stable releases."
> > 
> > FWIW I'm in neither. My camp would be: Please do not impede our way to
> > produce stable releases in any ways, do whatever you want with rolling.
> 
> I'm sorry but I find that a lame request. If, in whatever circumstances,
> Debian as a project decides to care about something beyond stable
> releases, for instance something called rolling, it will as a matter of
> fact use power of the project for such new thing and thus distract that
> power from stable releases. Always. Saying that anyone can do anything
> as long as it never interferes with what we have now is exactly the
> definition of keeping the status-quo, i.e. preventing improvement.
> Granted, it also prevents breakage.

Huh, no, you can do lots of stuff that don't harm releasing a Stable…

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

That's not the same thing as creating ways inside of Debian to scatter
resources on too many projects. That would be irrational.

-- 
·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/20110504155811.gg27...@madism.org

Re: PPAs for Debian

[René Mayorga]

On Wed, May 04, 2011 at 08:28:00AM +0200, Stefano Zacchiroli wrote:
> On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote:
> > I believe Debian is quite correct to be 
> > concerned about the potential for user confusion and damage to Debian's 
> > reputation for high quality work.
> > 
> > PPAs as a developer tool are one thing, PPAs as a tool for random uploads, 
> > I 
> > think are quite another.
> 
> AOL. I think that for Project needs, PPAs accessible only to DDs + DMs

Maybe we should think about not use the «PPAs» name so there will be less 
confusion
about the kind of service being discussed, and in the long term will be less
confused for users as well

I recall «debhub» being used early, or maybe «DebSandBox».

Cheers

--
René


signature.asc
Description: Digital signature

Re: A concrete proposal for rolling implementation

[Cyril Brulebois]

Hi,

(you already know, but let's state that on dd@ too)

Josselin Mouette  (04/05/2011):
> during the recent discussions about rolling, a proposal was made in
> a blog comment, and after giving it some quick thoughts, most people
> I’ve talked with seem to think it is a good idea, so it’s time for
> it to be discussed at large.
> 
> It starts from the following fact: if you want a testing system that
> works correctly, you usually have to add APT lines for unstable,
> while pinning them to only install specific packages you need to
> unbreak what’s broken in unstable.

your proposal certainly makes a lot of sense. Having to quick-fetch
packages from unstable to avoid long-term breakages seems to be the
major issue for prospective testing users, and “automating” (whatever
the details) that pinning seems like an easy and non-disruptive (as
far as the testing process is concerned -- AFAICT, IMVHO, etc.) way
to fix that major usability issue.

Thank you for coming with that concrete proposal.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: A concrete proposal for rolling implementation

[Gunnar Wolf]

Piotr Ożarowski dijo [Wed, May 04, 2011 at 03:22:07PM +0200]:
> [Josselin Mouette, 2011-05-04]
> > This would be a pseudo-suite, like experimental. Except that while
> > experimental is built on top of unstable and filled manually by
> > maintainers, rolling would be built on top of testing and filled
> > semi-automatically. A rolling system would have typically 2 APT lines:
> > one for testing and one for rolling.
> 
> +1

I'll also state it: Josselin's proposal looks very interesting, simple
and compatible with what we have now!

> [...]
> >   What to do during freezes
> >   -
> > I’m not sure we really need to do something different in times of
> > freeze. Our time would be better spent by reducing the freeze time and
> > making it more predictable; squeeze has been an awesome step in this
> > direction.
> 
> I'm not interested in helping f.e. with Perl bugs so once the ones
> I care about are fixed, I just want to focus on Sid (i.e. upload new
> upstream versions, prepare new transitions etc.) - I can wait a month or
> two, but these long freezes demotivate me a lot.

For many bugs, it's not only that I'm not interested, but I'm also
disqualified. Of course, a long freeze can be demotivating, and it can
also cause a spike of work when we reopen unstable for "anything goes"
uploads.

In my case, I used this last freeze to redo the packaging for one of
my complex packages, and kept up-to-date with upstream via
experimental - So I was breaking stuff and keeping up to date at the
same time. It cannot always work like this, of course, I'm just
mentioning a way to keep the fun flowing while in freeze.

Now, long freezes are complicated, true. But I don't think keeping
unstable disconnected from (frozen|testing) will really help us. If
all uploads during the freeze have to go through t-p-u, we will lose a
bit of what gives coherence to the whole system.

I feel, as many others have stated, that the Squeeze release cycle was
quite a successful one, even with some erupting flames here and
there... Probably we should focus more on keeping the bug count lower
during the non-freezing period? That should surely lead to a shorter
freeze period.


-- 
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/20110504153025.gc15...@gwolf.org

Re: Qt3 looking for adopters

[Bastien ROUCARIES]

On Wed, May 4, 2011 at 1:55 PM, Ana Guerrero  wrote:
>> On Sun, May 1, 2011 at 7:56 PM, Ana Guerrero  wrote:
>> >
>> > Hi,
>> >
>> > kdelibs3 was removed recently from the archive and the last tiny bit
>> > of KDE 3 remaining, aRts, will be removed quite soon.
>> >
>> > This means the KDE team is not longer interested in Qt3 and we are looking
>> > for new maintainer(s).
>> >
>> > Personally, I would have gone for removing Qt3 too but the following 
>> > concerns
>> > have been raised:
>> >
>> > - latest LSB 4.1 still needs Qt3
>> > - some software using Qt3 do not have any replacement (twinkle has 
>> > mentioned
>> >  for several users). There is a list of packages using Qt 3 at [1] and
>> >  even if Qt3 is kept in the archive, I am planning to do a QA round of all
>> >  the packages using Qt3.
>> > - there seem to be a lot of people using their Qt 3 software and Debian in
>> >  scientific environments.
>> >
>> > Qt 3 was EOL'ed in July 2007 [2], so if you decide to adopt Qt 3 you won't
>> > have any support by upstream. Also, if you adopt the package, please
>> > coordinate with the KDE team so we can push some final changes.
>> >
>
> On Wed, May 04, 2011 at 01:29:39PM +0200, Bastien ROUCARIES wrote:
>> You miss qucs for instance.
>
> I did not mean to be exhaustive. All the packages using Qt3 have at least one
> person who consider them important or they would not be in the archive.
>
>> I suppose qt3 is near bug free ?
>>
>
> It has 21 bugs. The important point here is you would become also *upstream*.

No they are trinirty qt3 :)

Could you offer me sponsorship ?

Bastien
>
>> Could help to maintain but in team
>>
>
> There are plenty of one-person teams in Debian :-)
>
> Ana
>
>


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

Re: A concrete proposal for rolling implementation

[Goswin von Brederlow]

Josselin Mouette  writes:

> This way, when something is broken in testing and cannot be unbroken
> quickly, a maintainer who notices it could add (or make the people in
> charge add) the necessary packages to the override file. If, for a
> reason or another, an important bug fix or a security update doesn’t
> propagate to testing quickly enough, you can now just add it and the
> necessary dependencies to rolling, and people using it aren’t affected.
> Whenever the affected packages finally migrate to testing, the
> discrepancy between rolling and testing automatically disappears.

That sounds like a nice idea. Maybe call it hot-fix instead of rolling. :)

I would suggest one more thing though. Sometimes it is know that a
package breaks on upgrade and maybe even causes data loss. But the fix
might not be aparent or quick to implement. Maybe it would be nice if
one could then also remove or block a package so people won't upgrade to
the known bad version while the maintainer works on a fix.

Note: this would prbably require a full Packages file and people to only
add rolling to sources.list without also having testing.

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

Re: A concrete proposal for rolling implementation

[Raphael Hertzog]

On Wed, 04 May 2011, Josselin Mouette wrote:
> > It doesn't need to be a pseudo-suite. It's a collection of packages taken
> > in testing or unstable, it's not more complicated to make it a full suite.
> 
> It cannot be “just” a full suite. When you add a package coming from
> unstable, you must also keep the version that is already in testing. To
> follow on my example, if you allow libgnomekbd and gnome-settings-daemon
> from unstable, you still need libgnomekbd from testing, otherwise other
> packages will become uninstallable.

A full suite can have 2 versions of the same source package and
can contain both libgnomekbd4 and libgnomekbd7. It's not a problem.

> > And PR-wise, it's way better to avoid "testing" appearing in the
> > sources.list.
> 
> That’s really an implementation detail. If you really want to hide it,
> you just need to ensure rolling can have two versions of the same
> sources at the same time.

OK. Testing already can, so it should be ok for rolling too.

> > You still need some sort of britney to verify that the package is 
> > effectively
> > installable in rolling, and to verify you're not breaking installability
> > of other packages available in rolling.
> 
> If rolling is just an overlay on testing, I don’t think that’s
> necessary. The worst that could happen is that the version in rolling is
> uninstallable, but the version in testing would still be.

Yes but as long as it's uninstallable, the bug is not fixed for the user.
So while we did not break anything, we did not fix anything either.
:-)

> What the britney-like thing could do is bring automatically all
> dependencies that are actually necessary for the package to be
> installable. But this could also make things more complicated, since
> britney tests source packages, not binaries. You might bring a source in
> rolling only for a runtime that is needed, but the development header
> being uninstallable is not a problem. Britney would prevent that, while
> it would still be a good move.

Yes, we could try to improve britney towards this.

But I'm not sure it's a good idea to pick only some binary packages from a
source package. It happens often enough that the package lack a strict
dependency that might be required and picking all the binaries from a
source package limits the risk of upgrading them separately (and thus
experiencing the bug).

> > Once we diverged from testing, there's the question of what to do when the
> > package gets updated in unstable. By default the answer is "nothing"
> > unless the updated package fix a RC bug that is not present in testing
> > but that was introduced since then (and is now present in the rolling
> > version).
> 
> I’m not entirely sure, but I think it’s better to pick the update from
> unstable instead of letting in rolling a package that is no longer
> available somewhere else. It should make upgrades smoother, and it
> should also be less work for maintainers, since it avoids having another
> version from which problems can arise.

In that case, those updates should follow the same rules than for testing
itself. It would be unreasonable to accept the new unstable upload
immediately.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110504142011.ge24...@rivendell.home.ouaza.com

Re: glibc: causes segfault in Xorg

[Aurelien Jarno]

Le 04/05/2011 16:02, Goswin von Brederlow a écrit :
> Aurelien Jarno  writes:
> 
>> Le 04/05/2011 14:06, Raphael Hertzog a écrit :
>>> a nice behaviour, it would be way better to print
>>> a warning and fallback to a correct behaviour. Users can then report the
>>> problems without experiencing a non working-application.
>>
>> Printing a warning on a thing that is potentially used everywhere,
>> especially in scripts is not a good idea. It will simply corrupt the
>> data that the othe part of the script is waiting for, and that even on
>> stderr, a lot of scripts are not (correctly?) designed for that.
> 
> I don't see how this is different from the error reporting on duplicate
> free or memory list corruptions. So printing a warning does break a few

Duplicate free or memory prints an error and *aborts*, so the data it's
not propagated further. Printing a warning and continuing, means the
data is propagated further.

> bad scripts. Aborting will also break them, but it will break all the
> clean scripts and normal use cases too.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/4dc15e52.1070...@aurel32.net

Re: glibc: causes segfault in Xorg

[Goswin von Brederlow]

Aurelien Jarno  writes:

> Le 04/05/2011 14:06, Raphael Hertzog a écrit :
>> a nice behaviour, it would be way better to print
>> a warning and fallback to a correct behaviour. Users can then report the
>> problems without experiencing a non working-application.
>
> Printing a warning on a thing that is potentially used everywhere,
> especially in scripts is not a good idea. It will simply corrupt the
> data that the othe part of the script is waiting for, and that even on
> stderr, a lot of scripts are not (correctly?) designed for that.

I don't see how this is different from the error reporting on duplicate
free or memory list corruptions. So printing a warning does break a few
bad scripts. Aborting will also break them, but it will break all the
clean scripts and normal use cases too.

While not ideal I think I would prefer a error over aborting at least
for the time being.

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

Re: glibc: causes segfault in Xorg

[Jon Dowland]

On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:
> While I can sympathize with this (it's what I want as a developer), it's
> certainly not a good idea in Debian in general: we have many derivatives
> taking unstable/testing at various points in time, and we also want to make
> testing generally usable by end-users.
> 
> So it's best if you consider unstable always in production-mode by default.

I disagree with this.  We expect *our* users of sid to use things like
apt-listbugs and to be wary of blindly upgrading.  I think we should hold
downstream distributions to higher standards.  If a downstream distribution
blindly accepts a libc from sid and it doesn't do what they want, imho that's
their fault.  Especially with a core package.

I'm concerned that this attitude, if adopted elsewhere, would paralyze Debian
development, for fear of inconveniencing other distributions.

-- 
Jon Dowland


-- 
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/20110504135835.gb4...@deckard.alcopop.org

Re: A concrete proposal for rolling implementation

[Josselin Mouette]

Le mercredi 04 mai 2011 à 15:30 +0200, Raphael Hertzog a écrit : 
> On Wed, 04 May 2011, Josselin Mouette wrote:
> > It starts from the following fact: if you want a testing system that
> > works correctly, you usually have to add APT lines for unstable, while
> > pinning them to only install specific packages you need to unbreak
> > what’s broken in unstable.
> 
> I think you meant "what's broken in testing" (i.e. you take a few selected
> packages from unstable to fix bugs present in testing).

Yes, of course.

> It doesn't need to be a pseudo-suite. It's a collection of packages taken
> in testing or unstable, it's not more complicated to make it a full suite.

It cannot be “just” a full suite. When you add a package coming from
unstable, you must also keep the version that is already in testing. To
follow on my example, if you allow libgnomekbd and gnome-settings-daemon
from unstable, you still need libgnomekbd from testing, otherwise other
packages will become uninstallable.

> And PR-wise, it's way better to avoid "testing" appearing in the
> sources.list.

That’s really an implementation detail. If you really want to hide it,
you just need to ensure rolling can have two versions of the same
sources at the same time.

> > The rolling suite would only exist for a subset of architectures (we
> > could start with powerpc, i386 and amd64), generated by picking up
> 
> Why powerpc? If we really take more than i386/amd64 for rolling, there are
> more users of armel than of powerpc.

Yes, sure. It was just an example.

> You still need some sort of britney to verify that the package is effectively
> installable in rolling, and to verify you're not breaking installability
> of other packages available in rolling.

If rolling is just an overlay on testing, I don’t think that’s
necessary. The worst that could happen is that the version in rolling is
uninstallable, but the version in testing would still be.

What the britney-like thing could do is bring automatically all
dependencies that are actually necessary for the package to be
installable. But this could also make things more complicated, since
britney tests source packages, not binaries. You might bring a source in
rolling only for a runtime that is needed, but the development header
being uninstallable is not a problem. Britney would prevent that, while
it would still be a good move.

> Once we diverged from testing, there's the question of what to do when the
> package gets updated in unstable. By default the answer is "nothing"
> unless the updated package fix a RC bug that is not present in testing
> but that was introduced since then (and is now present in the rolling
> version).

I’m not entirely sure, but I think it’s better to pick the update from
unstable instead of letting in rolling a package that is no longer
available somewhere else. It should make upgrades smoother, and it
should also be less work for maintainers, since it avoids having another
version from which problems can arise.

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

AutoNotify: Returned mail: Data format error

[scalerts]

Message [o91db421774654d4eaeccd1845b56aa3d.pro] triggered rule [Anti-Virus 
Malware Scanning (1)] at 4:04:20 PM 5/4/2011

Sender: debian-devel@lists.debian.org
Recipient(s): mhan...@shb.com.sa
Subject: Returned mail: Data format error

Re: A concrete proposal for rolling implementation

[Piotr Ożarowski]

[Didier Raboud, 2011-05-04]
> While I agree with the demotivation stance, why can't those packages be 
> uploaded to experimental, fwiw ?

because that's not what experimental is for and it's harder to use it
(did you notice that python3.2 is in experimental or did someone gave
you proper apt-pinning rule when Squeeze was frozen?)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


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

Re: A concrete proposal for rolling implementation

[Raphael Hertzog]

Hi,

I came to the same conclusion than you after the discussion we had in
the comments of your article. I think it's the right approach. I still
have a few comments though.

On Wed, 04 May 2011, Josselin Mouette wrote:
> It starts from the following fact: if you want a testing system that
> works correctly, you usually have to add APT lines for unstable, while
> pinning them to only install specific packages you need to unbreak
> what’s broken in unstable.

I think you meant "what's broken in testing" (i.e. you take a few selected
packages from unstable to fix bugs present in testing).

> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.

It doesn't need to be a pseudo-suite. It's a collection of packages taken
in testing or unstable, it's not more complicated to make it a full suite.

And PR-wise, it's way better to avoid "testing" appearing in the
sources.list.

Also it means that the day where we have improved our processes in
unstable/testing so that rolling is no longer necessary, we can simply merge
testing and rolling in a single suite.

> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up

Why powerpc? If we really take more than i386/amd64 for rolling, there are
more users of armel than of powerpc.

> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4
> ...
> The rolling suite would try to have a package that has *at least* this
> version. If it is found in testing, the package is removed from rolling.
> If otherwise it is found in unstable, the package is picked from
> unstable.

You still need some sort of britney to verify that the package is effectively
installable in rolling, and to verify you're not breaking installability
of other packages available in rolling.

But yes the basic principle is to stay as close to testing as possible, to
get as much as possible fixed via testing (in particular when it's
possible to fix via an updated version pushed through t-p-u) and for the
rest to cherry-pick some updates from unstable.

Once we diverged from testing, there's the question of what to do when the
package gets updated in unstable. By default the answer is "nothing"
unless the updated package fix a RC bug that is not present in testing
but that was introduced since then (and is now present in the rolling
version).

>   Why I like it
>   -
> First of all, this idea doesn’t affect *at all* the current release
> process. It just takes people willing to maintain the override file -
> and we could even choose to let any DD modify it. And it’s much faster
> to modify such a file than telling every user from testing that they
> have to upgrade to the unstable version.

I don't believe in the "let any DD modify it" but there should be a simple
way for DD to evaluate and submit such requests of integration into
rolling.

> And just as importantly, I think it should just work. There’s very
> little chance that people get completely hosed systems like it happens
> sometimes for unstable. There are all chances that something broken in
> testing can be fixed by pulling a handful of packages from unstable.

I agree with this. There might some corner-cases where we might require
direct uploads into rolling but if we stick to i386/amd64, it's easy
enough to do even without specific support on the buildd side.

>   What to do during freezes
>   -

I leave that aside for now. Your proposal covers the need to push newer
upstream versions to users but doesn't respond to the desire of developers
to continue development. But it's really another discussion so I prefer to
not discuss it in that thread.

> What do you think?

+1 from me. Thank you for the proposal!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110504133040.gb24...@rivendell.home.ouaza.com

Re: A concrete proposal for rolling implementation

[Didier Raboud]

Piotr Ożarowski wrote:

> [Josselin Mouette, 2011-05-04]
>> This would be a pseudo-suite, like experimental. Except that while
>> experimental is built on top of unstable and filled manually by
>> maintainers, rolling would be built on top of testing and filled
>> semi-automatically. A rolling system would have typically 2 APT lines:
>> one for testing and one for rolling.
> 
> +1
> 
> [...]
>>   What to do during freezes
>>   -
>> I’m not sure we really need to do something different in times of
>> freeze. Our time would be better spent by reducing the freeze time and
>> making it more predictable; squeeze has been an awesome step in this
>> direction.
> 
> I'm not interested in helping f.e. with Perl bugs so once the ones
> I care about are fixed, I just want to focus on Sid (i.e. upload new
> upstream versions, prepare new transitions etc.) - I can wait a month or
> two, but these long freezes demotivate me a lot.

While I agree with the demotivation stance, why can't those packages be 
uploaded to experimental, fwiw ?



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

Re: A concrete proposal for rolling implementation

[Piotr Ożarowski]

[Josselin Mouette, 2011-05-04]
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.

+1

[...]
>   What to do during freezes
>   -
> I’m not sure we really need to do something different in times of
> freeze. Our time would be better spent by reducing the freeze time and
> making it more predictable; squeeze has been an awesome step in this
> direction.

I'm not interested in helping f.e. with Perl bugs so once the ones
I care about are fixed, I just want to focus on Sid (i.e. upload new
upstream versions, prepare new transitions etc.) - I can wait a month or
two, but these long freezes demotivate me a lot.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


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

Re: time based freezes

[Piotr Ożarowski]

[Abou Al Montacir, 2011-05-04]
> On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote:
> 
> > On 2011-04-24, Stefano Zacchiroli  wrote:
> > > Dear Release Team ... good luck in proposing a freeze month now :-)
> > 
> > I would propose mid september or mid-march.  That's just after 2nd patch
> > release of new set of releases by KDE.
> 
> 
> And why not new gnome release, or maybe new kernel version or even any
> other program packaged

because I'm too lazy to send 42 mails¹ every 2 years, specially when some
of recipients might start ignoring them after receiving two with
different dates and most other upstreams will not get such mails at all.

You can pick the release date of your favourite $foo package with
popcon=0, I really don't care as long as we can put "Debian freezes on
$month every $parity year" on http://www.debian.org/ and not change it
for next decade or so.

Upstream authors that care about Debian, will try to release new stable
version on time, the ones that don't will just do what they do now and
we'll deal with it the same way we handle it now.

[¹] even if created as 1 mail with 41 addresses in CC ;-P
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


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

Re: glibc: causes segfault in Xorg

[Thomas Preud'homme]

Le mercredi 04 mai 2011 14:23:19, Aurelien Jarno a écrit :
> Le 04/05/2011 14:06, Raphael Hertzog a écrit :
> > a nice behaviour, it would be way better to print
> > a warning and fallback to a correct behaviour. Users can then report the
> > problems without experiencing a non working-application.
> 
> Printing a warning on a thing that is potentially used everywhere,
> especially in scripts is not a good idea. It will simply corrupt the
> data that the othe part of the script is waiting for, and that even on
> stderr, a lot of scripts are not (correctly?) designed for that.

Is there a usertag to track the memcpy bugs?

Regards.


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

Re: glibc: causes segfault in Xorg

[Aurelien Jarno]

Le 04/05/2011 07:42, Steve M. Robbins a écrit :
> On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
> 
>> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
>> which is fixed (sort of) by commit 0354e355 (2011-04-01).
> 
> Oh my word.  So glibc 2.13 breaks random binaries that happened to
> incorrectly use memcpy() instead of memmove()?  What's wrong with the
> glibc developers (and Ulrich Drepper in particular)?
> 
> I'm with Linus on this: let's just revert to the old behaviour.  A
> tiny amount of clock cycles saved isn't worth the instability.
> 
> Thanks,
> -Steve
> 
> P.S.  I tried rebuilding glibc myself locally, but gcc also segfaults
> in the process :-(
> 

Are you sure it is something related? Which gcc version are you using?
Do you have a backtrace point to the same issue?

I am using this libc version for two months (on a CPU having ssse3
instruction set), it is also used by other distributions, so I find
strange it breaks something so common than gcc. For XOrg it can be due
to the difference in configuration, that's why the problem stayed unnoticed.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/4dc146eb.9000...@aurel32.net

A concrete proposal for rolling implementation

[Josselin Mouette]

Hi,

during the recent discussions about rolling, a proposal was made in a
blog comment, and after giving it some quick thoughts, most people I’ve
talked with seem to think it is a good idea, so it’s time for it to be
discussed at large.

It starts from the following fact: if you want a testing system that
works correctly, you usually have to add APT lines for unstable, while
pinning them to only install specific packages you need to unbreak
what’s broken in unstable.

The idea is to make this process automatic. Let me elaborate.

  The new “rolling” suite
  ---
This would be a pseudo-suite, like experimental. Except that while
experimental is built on top of unstable and filled manually by
maintainers, rolling would be built on top of testing and filled
semi-automatically. A rolling system would have typically 2 APT lines:
one for testing and one for rolling.

The rolling suite would only exist for a subset of architectures (we
could start with powerpc, i386 and amd64), generated by picking up
packages from unstable. Typically it would be generated from an override
file that looks like:
source-package version
xserver-xorg-video-ati 1.2.3-4
...
The rolling suite would try to have a package that has *at least* this
version. If it is found in testing, the package is removed from rolling.
If otherwise it is found in unstable, the package is picked from
unstable.

This way, when something is broken in testing and cannot be unbroken
quickly, a maintainer who notices it could add (or make the people in
charge add) the necessary packages to the override file. If, for a
reason or another, an important bug fix or a security update doesn’t
propagate to testing quickly enough, you can now just add it and the
necessary dependencies to rolling, and people using it aren’t affected.
Whenever the affected packages finally migrate to testing, the
discrepancy between rolling and testing automatically disappears.

The reason for the “at least” version rule is that new uploads to
unstable are supposed to fix the situation in testing anyway. I don’t
think we should keep in rolling packages that are no longer in unstable.

  A concrete example
  --
Let’s imagine something that might happen soon (although of course we
will try hard for it not to happen): a new version of nautilus migrates
to testing, but it was missing a Breaks - it doesn’t work with the
version of gnome-settings-daemon in testing. The new
gnome-settings-daemon in unstable works, but it won’t migrate because
there is a libgnomekbd transition in progress, and gnome-screensaver
which is part of the transition doesn’t build on s390.

In this case, we can just add libgnomekbd and gnome-settings-daemon to
the override file. Users of the rolling suite will have the two versions
of libgnomekbd available, and they can update their systems to a working
state.

  Why I like it
  -
First of all, this idea doesn’t affect *at all* the current release
process. It just takes people willing to maintain the override file -
and we could even choose to let any DD modify it. And it’s much faster
to modify such a file than telling every user from testing that they
have to upgrade to the unstable version.

And just as importantly, I think it should just work. There’s very
little chance that people get completely hosed systems like it happens
sometimes for unstable. There are all chances that something broken in
testing can be fixed by pulling a handful of packages from unstable.

  What to do during freezes
  -
I’m not sure we really need to do something different in times of
freeze. Our time would be better spent by reducing the freeze time and
making it more predictable; squeeze has been an awesome step in this
direction.

If we want to do something different though, there is a simple recipe:
allow packages to be picked up from unstable, but also from
experimental. Again, no disruption: people can keep on breaking some
pieces of experimental, but if they want some other pieces to be useful
for rolling users, they just need to be committed to more carefulness
and to add them to the override file.


What do you think?

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

Re: glibc: causes segfault in Xorg

[Aurelien Jarno]

Le 04/05/2011 14:06, Raphael Hertzog a écrit :
> a nice behaviour, it would be way better to print
> a warning and fallback to a correct behaviour. Users can then report the
> problems without experiencing a non working-application.

Printing a warning on a thing that is potentially used everywhere,
especially in scripts is not a good idea. It will simply corrupt the
data that the othe part of the script is waiting for, and that even on
stderr, a lot of scripts are not (correctly?) designed for that.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/4dc14537.8050...@aurel32.net

Re: glibc: causes segfault in Xorg

[Raphael Hertzog]

On Wed, 04 May 2011, Aurelien Jarno wrote:
> Le 04/05/2011 11:48, Raphael Hertzog a écrit :
> > So it's best if you consider unstable always in production-mode by
> > default.
> 
> So how do you plan to detect bugs if you never enable a feature?

Really abort()ing is not a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour. Users can then report the
problems without experiencing a non working-application.

When something like this is not possible, I'm afraid Debian unstable is
not a good place to experiment...

I know this answer is not entirely satisfactory but the truth is there
are other distributions which follow another developement model that are
better suited to experiment such things, for example Fedora.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110504120641.gb23...@rivendell.home.ouaza.com

Re: Qt3 looking for adopters

[Ana Guerrero]

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

On Wed, May 04, 2011 at 01:29:39PM +0200, Bastien ROUCARIES wrote:
> You miss qucs for instance.

I did not mean to be exhaustive. All the packages using Qt3 have at least one 
person who consider them important or they would not be in the archive.

> I suppose qt3 is near bug free ?
> 

It has 21 bugs. The important point here is you would become also *upstream*.

> Could help to maintain but in team
> 

There are plenty of one-person teams in Debian :-)

Ana


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

Re: Qt3 looking for adopters

[Bastien ROUCARIES]

You miss qucs for instance.

I suppose qt3 is near bug free ?

Could help to maintain but in team

Bastien

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


--
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=0qbMZi1hwt=mh3qy59pzn2dw...@mail.gmail.com

Re: glibc: causes segfault in Xorg

[sean finney]

On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins"  wrote:
> 
> Hi,
> 
> > I'm with Linus on this: let's just revert to the old behaviour.  A
> > tiny amount of clock cycles saved isn't worth the instability.
> 
> Tiny amount?! The optimized memcpy() variants that break shitty code
> bring a 4 to 5x speedup on the processors they've been written for!

And furthermore, even if Debian chooses to "fix" this, upstreams will
be forced to eventually cater to the default glibc behavior for every
other libc distro out there that does not have their own "fix" (and
non-libc OS's where this behavior already exists), so gains would be
potentially limited.

That said, regressions do suck, especially when they take the form of
heisenbugs.  But one could easily hack something LD_PRELOAD'able check
for stuff like this without forcing a global change.

my 0.02 $LC_MONETARY anyway,

sean


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

Re: Integrating aptosid?

[Andreas Tille]

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

Exactly (just uploaded metapackages for Debian Science generated from
tasks files :-)).
 
> blends are indeed very very related indeed.  Historically though they
> became of wider scope and deeper coverage, than I think many of
> the derivatives, which are often just customized package selection +
> design + custom installer/live-media.

The reasons why Blends have a focus on a certain workfield is that there
was simply no intend to generate a Debian derivative (the idea was just
to sit inside Debian).  However, I do not see a reason why the Blends
concept should not be enhanced to more general customisation.  That's
just a question of the content where you let the techniques (as well as
the conceptual ideas) work on.
 
> So, theoretically, blends mechanism could be extended to actually
> provide such customized installer + appearance...

Yes.

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

I'm for a long time in preference of this but that's a different topic.
 
> But altogether the point is that indeed, it would be nice we somehow we
> could bring derivatives communities closer to Debian so they do not
> loose their originality/projects but infuse their work into Debian
> meanwhile.

On Debian Med list we try to teach derivatives with the same focus as
Debian Med to use our Blends techniques (which also work for derivatives
as well). 

Kind regards

Andreas.

PS: Yaroslav, it was nice to read that you share the same dream (expressed in
your previous mail) as me. :-)

-- 
http://fam-tille.de


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

Re: glibc: causes segfault in Xorg

[Goswin von Brederlow]

Adam Borowski  writes:

> On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
>> I'm with Linus on this: let's just revert to the old behaviour.  A
>> tiny amount of clock cycles saved isn't worth the instability.
>
> I'd instead propose to sacrifice a tiny amount of cycles to check for
> overlapping and abort()ing so buggy code can be fixed.  Random instability
> is the worst kind of error, a clean crash is easy to fix.  Heck, we can even
> make a change just before wheezy is frozen to make it call memmove() when a
> breakage is detected.  Just please don't paper over the bugs until then.

+1.

Maybe do this in 2 steps: 1) give a warning on stderr, 2) abort.
If even gcc fails (see other mail in this thread) then aborting when we
don't need to doesn't seem like a good option.

Or have a env var to disable the abort() so one can work around it.

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

Re: Debian rolling: tentative summary

[Goswin von Brederlow]

Josselin Mouette  writes:

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

Which is why I don't want to completly split, as in not have the server
packages available in the desktop distribution. The way I imagine the
sparkly releases would contain a full package set or you would have

deb http://ftp.debian.org/debian stable main
deb http://ftp.debian.org/debian sparkly main

In both cases the "desktop distribution" would still have an apache and
postgresql and all that. Just not bleeding edge versions of those.

For the other way around, servers needing desktop components, the
components would still be there in the full release. The sparkly release
might have a newer version of libs but they must already be compatible
or have a new SONAME. So I would think there wouldn't be any (or at
least not many) problematic links between desktop and server parts.

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

So maybe throw away the lables like desktop and server and let the
sparkly release grow naturally. Lets start with an empty package set and
add packages that need a newer version. When there is a new KDE version
between stable releases then KDE can be added to sparkly. When there is
a new must have apache version then that can be added. There would have
to be some guidelines for when to add something and probably some nice
big flame wars. It would be something inbetween stable and volatile. But
I think with just a minimum of restrained on when to add a new version
the sparkly release would be a much smaller set of packages than a full
release and respectively less work to pull off.

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

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

[Goswin von Brederlow]

Steve Langasek  writes:

> On Mon, May 02, 2011 at 06:09:17PM +0200, Goswin von Brederlow wrote:
>> 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.

mrvn@book:~% less /var/lib/dpkg/info/libc6-dev-i386.list | grep include
/usr/include
/usr/include/gnu
/usr/include/gnu/stubs-32.h
/usr/include/i486-linux-gnu
/usr/include/sys
/usr/include/sys/vm86.h
/usr/include/sys/elf.h

Aparently not. But maybe that is just the biarch 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/87mxj2bvf4.fsf@frosties.localnet

Re: time based freezes

[Abou Al Montacir]

On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote:

> On 2011-04-24, Stefano Zacchiroli  wrote:
> > Dear Release Team ... good luck in proposing a freeze month now :-)
> 
> I would propose mid september or mid-march.  That's just after 2nd patch
> release of new set of releases by KDE.


And why not new gnome release, or maybe new kernel version or even any
other program packaged

I think that, the best choice is to follow a time based release content
definition which may be described by the following procedure.

1) Release team calls for a release content with a target date +/- 3
month.
2) DD answer each with his road map (bugs, new upstream releases, ...)
which should fit in for the date, within a month from the call date. 
3) Release team, compiling the information, fills bugs for new feature
and tag bugs for the next release.
4) DD confirm/infirm the tags within 1 month
5) Release team fixes the freeze date

BTW, if the freeze happens on a separate copy of testing (let's say
frozen), it will be great. Uploads should target frozen, be built into
it (not into unstable). Only bug fixes are allowed on it.

Cheers,


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

Re: glibc: causes segfault in Xorg

[Julien BLACHE]

"Steve M. Robbins"  wrote:

Hi,

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

Tiny amount?! The optimized memcpy() variants that break shitty code
bring a 4 to 5x speedup on the processors they've been written for!

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/87d3jyn4gx@sonic.technologeek.org

Processed: Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 625538 gnome-power-manager
Bug #625538 [general] general: Monitor turns off even if in gnome-screensaver 
and gnome-power i disalbe automatic turning off.
Bug reassigned from package 'general' to 'gnome-power-manager'.
> merge 370692 625538
Bug#370692: gnome-power-manager: DPMS Power Saving States Not Activated
Bug#625538: general: Monitor turns off even if in gnome-screensaver and 
gnome-power i disalbe automatic turning off.
Merged 370692 625538.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
370692: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370692
625538: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625538
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


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

Re: glibc: causes segfault in Xorg

[Aurelien Jarno]

Le 04/05/2011 11:48, Raphael Hertzog a écrit :
> On Wed, 04 May 2011, Adam Borowski wrote:
>> I'd instead propose to sacrifice a tiny amount of cycles to check for
>> overlapping and abort()ing so buggy code can be fixed.  Random instability
>> is the worst kind of error, a clean crash is easy to fix.  Heck, we can even
>> make a change just before wheezy is frozen to make it call memmove() when a
>> breakage is detected.  Just please don't paper over the bugs until then.
> 
> While I can sympathize with this (it's what I want as a developer), it's
> certainly not a good idea in Debian in general: we have many derivatives
> taking unstable/testing at various points in time, and we also want to
> make testing generally usable by end-users.
> 
> So it's best if you consider unstable always in production-mode by
> default.

So how do you plan to detect bugs if you never enable a feature?

Don't answer me "experimental", this is enabled in experimental for over
a month, and AFAIK it is also enabled in the latest Ubuntu release.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/4dc1281b.2030...@aurel32.net

new experimental debdelta feature --format=unzipped

[A Mennucc]

Dear all,
 
I just uploaded into experimental a new version 0.42exp of debdelta (
you may find some binaries also in [3] ).

This version adds an experimental feature : if you call
'debdelta-upgrade' with the option '--format=unzipped' , then in the
recreated deb the data.tar part will not be compressed.  This may speed
up the 'debdelta-upgrade' + 'apt-get upgrade' process. Indeed, writing
to hard disk is fast (let's say 5MB/sec, but usually much more); whereas
compressing random data with 'bzip2 -9' or 'lzma -9' is much slower
(let's say 2.0MB/sec and 1.5 MB/sec) ; and moreover the compressed data
is then decompressed by dpkg when installing; so avoiding the
compress/decompress should be a win/win (unless you run out of disk
space...).

Please test it and tell me what you think.
(Let me mention that old deltas in the server do not support this new
feature, so you may get some warnings for some days). (I also want to
thank Guillem Jover for proposing this idea, in a mail in
debian-dpkg@l.d.o).

(In the future, we may add an even more aggressive behavior, whereby the
data is directly piped from debdelta thru dpkg to the hard disk ; this
would be in the spirit of [2] ; I already adapted the deltas to support
this, but it needs  changes in APT and in dpkg , it may be done as  part
of [4] ).

A.

[1] http://debdelta.debian.net
[2] http://wiki.debian.org/SummerOfCode2010/StreamingPackageInstall
[3] http://debdelta.debian.net/squeeze-backports/
[4] http://wiki.debian.org/SummerOfCode2011/AptDebdeltaIntegration





signature.asc
Description: OpenPGP digital signature

Re: glibc: causes segfault in Xorg

[Raphael Hertzog]

On Wed, 04 May 2011, Adam Borowski wrote:
> I'd instead propose to sacrifice a tiny amount of cycles to check for
> overlapping and abort()ing so buggy code can be fixed.  Random instability
> is the worst kind of error, a clean crash is easy to fix.  Heck, we can even
> make a change just before wheezy is frozen to make it call memmove() when a
> breakage is detected.  Just please don't paper over the bugs until then.

While I can sympathize with this (it's what I want as a developer), it's
certainly not a good idea in Debian in general: we have many derivatives
taking unstable/testing at various points in time, and we also want to
make testing generally usable by end-users.

So it's best if you consider unstable always in production-mode by
default.

It's the same story than building applications/libraries with
DISABLE_DEPRECATED, it's good for developers but we should not enable
those in unstable/testing because we prefer not breaking packages that
have not been updated yet.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110504094833.gd22...@rivendell.home.ouaza.com

Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.

[Roger Leigh]

reassign 625538 gnome-power-manager
merge 370692 625538
thanks

This is a known bug in gnome-power-manager.


Regards,
Roger


On Wed, May 04, 2011 at 11:16:25AM +0200, Holger Levsen wrote:
> reassign 625538 gnome
> thanks
> 
> On Mittwoch, 4. Mai 2011, Alessandro Sardone wrote:
> > Package: general
> > Severity: normal
> > 
> > Even if through gnome-screensaver-preferences and gnome-power-preference I
> > disable the screensaver and the automatic turning off of the monitor, when
> > I'm away the monitor became blank and black.
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: 6.0.1
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
> > 'stable') Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
> > Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> 
> 
> 
> 
> -- 
> 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/201105041116.26614.hol...@layer-acht.org
> 

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: PPAs for Debian

[Roland Mas]

Marc 'HE' Brockschmidt, 2011-05-04 10:42:31 +0200 :

> Heya,
>
> Roland Mas  writes:
>> Mike Hommey, 2011-05-04 07:57:47 +0200:
>>> Add to that that allowing random people to upload packages to be built
>>> on Debian build daemons is a recipe to have the buildds compromised.
>>   My initial idea about how one would go about implementing them
>> involved very strict isolation of the builds (either with LXC or a more
>> heavy-handed virtualisation system).  Not going to be very efficient in
>> the slow path, but the scope of a compromise would be a temporary
>> environment that's going to be thrown away in a minute or so and never
>> reused.
>
> If anyone would have actually read the PPA proposal, they would know
> that uploads were and are intended to be restricted to DDs and DMs
> (which can break buildds anyway, if they want) and building should
> happen in throw-away chroots (not for security, but "don't mess with my
> system" reasons).

  Oh, we're in full agreement, no question about that :-) I'm sorry I
didn't read the proposal, I was only trying to debunk a misapprehension
(and, possibly, nudge implementers into a way that would be helpful in a
more general case than the Debian PPA, such as… other users of
FusionForge, for instance.  My view is that PPAs should be handled as a
particular case of a more general architecture for continuous
integration (or autobuilding) in the forge.  My point of view is biased,
but I'm pretty sure we could find other use cases for builds *besides*
packages.  Customized CD images, possibly, or datasets or tdebs or
whatnot.

Roland.
-- 
Roland Mas

Sauvez un arbre, tuez un castor.


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

Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.

[Holger Levsen]

reassign 625538 gnome
thanks

On Mittwoch, 4. Mai 2011, Alessandro Sardone wrote:
> Package: general
> Severity: normal
> 
> Even if through gnome-screensaver-preferences and gnome-power-preference I
> disable the screensaver and the automatic turning off of the monitor, when
> I'm away the monitor became blank and black.
> 
> 
> 
> -- System Information:
> Debian Release: 6.0.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
> 'stable') Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
> Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash




-- 
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/201105041116.26614.hol...@layer-acht.org

Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.

[Alessandro Sardone]

Package: general
Severity: normal

Even if through gnome-screensaver-preferences and gnome-power-preference I
disable the screensaver and the automatic turning off of the monitor, when I'm
away the monitor became blank and black.



-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20110504091116.3125.22239.report...@a.gmsa

Re: Reporting same bug in different packages

[Patrick Strasser]

schrieb Josselin Mouette am 2011-05-03 17:22:
> Le mardi 03 mai 2011 à 15:56 +0200, Patrick Strasser a écrit : 

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

Now that's really bad. Alternatives? Reporting upstream, reporting
against affected packages? Asking someone with PDF knowledge to have a
look at it?

Regards

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

Re: Bug#598406: ITP: vavoom -- The most advanced Doom/Heretic/Hexen/Strife source port around!

[Jon Dowland]

[ Cc: debian-devel-ga...@lists.debian.org FYI ]

On Tue, Sep 28, 2010 at 04:14:11PM -0300, gustavo panizzo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: gustavo panizzo 
> 
> 
> * Package name: vavoom
>   Version : 1.32-1
>   Upstream Author : Janis Legzdinsh  
> * URL : http://www.vavoom-engine.com
> * License : GPL

I think a careful licensing check will be needed, iirc.

>   Programming Lang: C++
>   Description : The most advanced Doom/Heretic/Hexen/Strife source port 
> around!
> 
> Vavoom is a source port based on sources of Doom, Heretic, Hexen and 
> a little bit from Quake. Supported platforms are Windows and Linux.
> Vavoom has a graphical launcher (vlaunch).

game-data-packager grew heretic support very recently (deng supports it too).
Hexen support is still needed.

> i intend to contact the games team regarding this package.

That would be awesome :-)  You would be very welcome and I encourage you to
join the team. You can request to join the team at


> The respective dsc file can be found at:
> http://mentors.debian.net/debian/pool/main/v/vavoom/vavoom_1.32-1.dsc

I'll try to take a look at it over the next week.


-- 
Jon Dowland


-- 
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/20110504085759.ga1...@deckard.alcopop.org

Re: glibc: causes segfault in Xorg

[Adam Borowski]

On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
> On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
> 
> > Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
> > which is fixed (sort of) by commit 0354e355 (2011-04-01).
> 
> Oh my word.  So glibc 2.13 breaks random binaries that happened to
> incorrectly use memcpy() instead of memmove()?

memcpy() has fat warnings about the areas not overlapping, and that's the
very purpose of that function: a memmove() that is faster but less safe.

> What's wrong with the glibc developers (and Ulrich Drepper in particular)?

Nothing wrong, it is exactly the same as new compilers breaking behaviour
forbidden by the standard that used to work before.

The only problem is the breakage happening rarely, and thus being able to
survive for long.

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

I'd instead propose to sacrifice a tiny amount of cycles to check for
overlapping and abort()ing so buggy code can be fixed.  Random instability
is the worst kind of error, a clean crash is easy to fix.  Heck, we can even
make a change just before wheezy is frozen to make it call memmove() when a
breakage is detected.  Just please don't paper over the bugs until then.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Re: PPAs for Debian

[Brian May]

On 4 May 2011 15:23, Scott Kitterman  wrote:

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

 I don't personally see this as an issue, I think it is clear that Ubuntu
hosted PPAs are not controlled by Ubuntu, and as such the quality may vary
widely. If you don't trust the person making the archive, don't use it. If
the files look seriously old, don't use it. As for bug reports, being filled
at at the wrong place, this will always be an issue with or without the
PPAs.

Also I believe anybody can already get an account and upload files to alioth
- I don't believe we have a problem with poor quality files being uploaded
by random developers. Or if this is an issue, maybe we should restrict
alioth to developers only too?

I personally use my Ubuntu PPA for my Django based libraries; I don't think
it is reasonable to put every Django application/library I
develop immediately in Debian main, but this does not imply that the quality
is lacking in these packages.

It makes sense to have a central system everyone can use, manually setting
up private repositories that support automatic uploads, autobuilding, etc,
is a reasonably complicated task, using time that could be better spent on
improving the quality of the packages.
-- 
Brian May 

Re: PPAs for Debian

[Marc 'HE' Brockschmidt]

Heya,

Roland Mas  writes:
> Mike Hommey, 2011-05-04 07:57:47 +0200:
>> Add to that that allowing random people to upload packages to be built
>> on Debian build daemons is a recipe to have the buildds compromised.
>   My initial idea about how one would go about implementing them
> involved very strict isolation of the builds (either with LXC or a more
> heavy-handed virtualisation system).  Not going to be very efficient in
> the slow path, but the scope of a compromise would be a temporary
> environment that's going to be thrown away in a minute or so and never
> reused.

If anyone would have actually read the PPA proposal, they would know
that uploads were and are intended to be restricted to DDs and DMs
(which can break buildds anyway, if they want) and building should
happen in throw-away chroots (not for security, but "don't mess with my
system" reasons).

Marc


pgpA4XuJtzDNF.pgp
Description: PGP signature

Re: Reporting same bug in different packages

[Josselin Mouette]

Le mardi 03 mai 2011 à 18:19 +0100, Ben Hutchings a écrit : 
> Where is your RFH bug?

I’m not the maintainer. I’m just one of the guys who happen to upload it
when it gets too outdated.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



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

Re: PPAs for Debian

[Roland Mas]

Mike Hommey, 2011-05-04 07:57:47 +0200 :

[...]

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

  My initial idea about how one would go about implementing them
involved very strict isolation of the builds (either with LXC or a more
heavy-handed virtualisation system).  Not going to be very efficient in
the slow path, but the scope of a compromise would be a temporary
environment that's going to be thrown away in a minute or so and never
reused.

Roland.
-- 
Roland Mas

Shyumiribirikku ga susunde imashyou ka ?
  -- Le Schmilblick en japonais


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