GROMACS version

[Francesco Pietra-2]

Gromacs is available on lenny as version 3.3., while on squeeze
version 4.0 is provided. Assuming that version 4.0 will never be
provided for stable Debian:

I do not know which problems are faced by maintainers to provide
version 4.0 for lenny. If no problem exists (as obviously it is the
case), I am against this policy by Debian. What can I do with gromacs
version 4.0 on my desktop which runs on squeeze i386? while I would be
happy to save time in compiling version 4.o for the parallel machine,
running on amd64. In other words, computational software such as
gromacs makes sense only on parallel machines, and these are run on
stable debian. Who is running a number-crunching machine on squeeze?

thanks for attention to this (recurring) problem.

francesco pietra


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sylvestre Ledru-6]

Le vendredi 25 septembre 2009 à 09:04 +0200, Francesco Pietra a écrit :

> Gromacs is available on lenny as version 3.3., while on squeeze
> version 4.0 is provided. Assuming that version 4.0 will never be
> provided for stable Debian:
>
> I do not know which problems are faced by maintainers to provide
> version 4.0 for lenny. If no problem exists (as obviously it is the
> case), I am against this policy by Debian. What can I do with gromacs
> version 4.0 on my desktop which runs on squeeze i386? while I would be
> happy to save time in compiling version 4.o for the parallel machine,
> running on amd64. In other words, computational software such as
> gromacs makes sense only on parallel machines, and these are run on
> stable debian. Who is running a number-crunching machine on squeeze?

You should have a look to:
http://backports.org/

It is probably what you are looking for.

Sylvestre



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-3]

Hi Francesco!

Am Freitag, den 25.09.2009, 09:04 +0200 schrieb Francesco Pietra:
> Gromacs is available on lenny as version 3.3., while on squeeze
> version 4.0 is provided. Assuming that version 4.0 will never be
> provided for stable Debian:

This assumption is correct, unfortunately...

> I do not know which problems are faced by maintainers to provide
> version 4.0 for lenny. If no problem exists (as obviously it is the
> case), I am against this policy by Debian.

It's Debian's policy the stable releases do not contain newer software.
This is not going to change anytime soon. When Lenny was frozen before
it's release, GROMACS 3.3.3 was the most current version. When newer
versions are released after the freeze, they have no change of getting
into stable ever.

However, Sylvestre already pointed you to backports.org. This is a way
to deal with that: Rebuilding packages from Squeeze on Lenny. But you're
lost again, as not all software is in Backports, and GROMACS is one of
the packages missing.

> What can I do with gromacs version 4.0 on my desktop which runs on
> squeeze i386? while I would be happy to save time in compiling version
> 4.o for the parallel machine, running on amd64. In other words,
> computational software such as gromacs makes sense only on parallel
> machines, and these are run on stable debian.

Correct. I do backport GROMACS for Lenny for my personal use. I can make
my backported GROMACS packages accessible.

I also vaguely remember there has been a discussion about some "Debian
Science Backports" before. This would be a cool thing to have, maybe we
should pick up that discussion again. Though I fear we might lack the
manpower to do that currently. Can anyone catch me up on this?

> Who is running a number-crunching machine on squeeze?

Well, I do on some. ;)

Best regards
Manuel


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sylvestre Ledru-6]

Le vendredi 25 septembre 2009 à 11:07 +0200, Manuel Prinz a écrit :
> Hi Francesco!
[...]

> I also vaguely remember there has been a discussion about some "Debian
> Science Backports" before. This would be a cool thing to have, maybe we
> should pick up that discussion again. Though I fear we might lack the
> manpower to do that currently. Can anyone catch me up on this?
I am thinking about doing so for Scilab and its (reverse or not) dependencies.

> > Who is running a number-crunching machine on squeeze?
>
> Well, I do on some. ;)
Yep but as DD, you are not a good example ;)

Sylvestre



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steffen Moeller-3]

Sylvestre Ledru wrote:

> Le vendredi 25 septembre 2009 à 11:07 +0200, Manuel Prinz a écrit :
>> Hi Francesco!
> [...]
>
>> I also vaguely remember there has been a discussion about some "Debian
>> Science Backports" before. This would be a cool thing to have, maybe we
>> should pick up that discussion again. Though I fear we might lack the
>> manpower to do that currently. Can anyone catch me up on this?
> I am thinking about doing so for Scilab and its (reverse or not) dependencies.
>
>>> Who is running a number-crunching machine on squeeze?
>> Well, I do on some. ;)
> Yep but as DD, you are not a good example ;)

Me, too!

The question is indeed a valid one. For larger compute clusters, "stable"
indeed seems to mean "invariant". And while as scientists we always want the
very latest, we also want stable compute clusters. This is a dilemma.

Would there be a way to auto-backport packages that are flagged in this
respect? Similarly to some non-free packages being explicitly allowed to be
auto-built? Basically all packages in debian-science and debian-med are very
likely candidates, IMHO.

Many greetings

Steffen



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-3]

Am Freitag, den 25.09.2009, 12:23 +0200 schrieb Steffen Moeller:
> The question is indeed a valid one. For larger compute clusters, "stable"
> indeed seems to mean "invariant". And while as scientists we always want the
> very latest, we also want stable compute clusters. This is a dilemma.

Indeed. That's why I backport. It seems to be the best compromise. This
whole problem is intensified by the fact that bugs in old versions might
make results become void. So having the latest versions kind of becomes
a neccessity.

> Would there be a way to auto-backport packages that are flagged in this
> respect? Similarly to some non-free packages being explicitly allowed to be
> auto-built? Basically all packages in debian-science and debian-med are very
> likely candidates, IMHO.

Yes. I like the idea but we simply can't rebuild everything from the
task pages of these blends since there are also tools from KDE or GNOME
which would mean to backport quite a lot of unrelated stuff. Also,
packages with code in interpreted language can almost always be used
directly from testing. But I think auto-building could work for a
well-defined subset of packages.

If there is interest in this and several (~5?) developers would
volunteer in maintaining these backports, we should get our heads
together and try to build something like that. I could probably donate a
VM for this purpose, and would volunteer to talk to the backports.org
people. But given my time constraints at the moment, I will need support
from interested people (even non-DDs) to make this happen.

Best regards
Manuel



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steffen Moeller-3]

Hello,

Manuel Prinz wrote:
> Am Freitag, den 25.09.2009, 12:23 +0200 schrieb Steffen Moeller:

>> Would there be a way to auto-backport packages that are flagged in this
>> respect? Similarly to some non-free packages being explicitly allowed to be
>> auto-built? Basically all packages in debian-science and debian-med are very
>> likely candidates, IMHO.
>
> Yes. I like the idea but we simply can't rebuild everything from the
> task pages of these blends since there are also tools from KDE or GNOME
> which would mean to backport quite a lot of unrelated stuff.

You mean some packages are unportable? The blends should not have KDE or so
mentioned directly.

> Also,
> packages with code in interpreted language can almost always be used
> directly from testing. But I think auto-building could work for a
> well-defined subset of packages.

Hm. Should there not be a flag to explicitly indicate the backporting? And
where do we place the patches to the debian package that was aiming at Squeeze?

> If there is interest in this and several (~5?) developers would
> volunteer in maintaining these backports, we should get our heads
> together and try to build something like that. I could probably donate a
> VM for this purpose, and would volunteer to talk to the backports.org
> people. But given my time constraints at the moment, I will need support
> from interested people (even non-DDs) to make this happen.

We'd need the sysadmins of the HPC setups to step forward and assist in setting
things up, but neither you not me should maintain the effort. If there is
demand, then there should be volunteers also to run it.

Many greetings

Steffen (running only squeeze or sid on his machines)


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

[Reply-To set to debian-devel because this topic belongs here.]

On Fri, Sep 25, 2009 at 12:58:00PM +0200, Manuel Prinz wrote:
>
> Yes. I like the idea but we simply can't rebuild everything from the
> task pages of these blends since there are also tools from KDE or GNOME
> which would mean to backport quite a lot of unrelated stuff. Also,
> packages with code in interpreted language can almost always be used
> directly from testing. But I think auto-building could work for a
> well-defined subset of packages.

IMHO this problem is not really Debian Science or Blends related and the
idea to handle backports analog to non-free autobuilds sounds quite
reasonable - but in this case we *really* make it analog tp non-free which
works with a debian/control field

    XS-Autobuild: yes

So why not using a similar field

    XS-Autobackport: yes

?  Well, it's definitely not that easy but I see a quite large set of
packages (specifically in the Debian Science field) which perfectly
compiles against Build-Depends of stable.  If we could handle this set
automatically for a first shot and think later about those packages
which need Build-Depends which are not available in stable this would
be an interesting thing.

So in short: we should choose the "well-defined" subset of packages
which are candidates for autobackporting according to their feature to
be buildable inside stable and using an control field to mark the
packages that way.

Kind regards

        Andreas.

--
http://fam-tille.de
Klarmachen zum Ändern!


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Hommey]

On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way.

Shouldn't checking if Build-Depends are satisfiable in stable be enough?
And if it doesn't build that way, I'd say there's a bug in the package
anyways, because it should bump some build dependencies.

But I think it's more a matter of being meaningful to backport the
packages, than to be possible of doing so.

And if symbols files were more broadly used, I guess most packages
currently in squeeze could be installed on lenny without even being
rebuilt.

As a side note, some packages are "easily" backportable, in the sense
that they only require a few build-dependencies to be backported. This
is the case for xulrunner and iceweasel, where only sqlite needs to be
backported for the packages to be backportable.

Mike


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Roger Leigh-5]

On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > So in short: we should choose the "well-defined" subset of packages
> > which are candidates for autobackporting according to their feature to
> > be buildable inside stable and using an control field to mark the
> > packages that way.
>
> Shouldn't checking if Build-Depends are satisfiable in stable be enough?

No, not if the library names changed.  I have packages, such as
schroot which are buildable on at least oldstable, if not
further back, but due to (in this case) a Boost dependency, the
boost library version changes result in non-backward-compatible
build-deps.

FWIW, the idea of autobuilding the backports where possible is
a pretty good idea IMHO.


Regards,
Roger

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


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rene Engelhard]

Hi,

On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > So in short: we should choose the "well-defined" subset of packages
> > which are candidates for autobackporting according to their feature to
> > be buildable inside stable and using an control field to mark the
> > packages that way.
>
> Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> And if it doesn't build that way, I'd say there's a bug in the package
> anyways, because it should bump some build dependencies.

build-deps are not necessarily runtime deps. Especially if
stuff changed in the fs or for policy reasons and that is not reflected in the
build-deps because the change is not in the build-deps.

Same for depends.

Or do you (build-)depend on a newer menu for the menu changes stuff?
or will you depend or conflict against all myspell/hunspell dicts
in stable with ice*? No, you would want to revert that changes to run
on stable smoothly.

> As a side note, some packages are "easily" backportable, in the sense
> that they only require a few build-dependencies to be backported. This
> is the case for xulrunner and iceweasel, where only sqlite needs to be
> backported for the packages to be backportable.

Actually, xulrunner and iceweasel are bad examples, since they will
be involved in the hunspell dictionary location transition. A rebuild
will make them look in a location which does not even exist in stable.
(Yet that transition has to be done for squeeze)

Grüße/Regards,

Rene
--
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  rene@... | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Hommey]

On Fri, Sep 25, 2009 at 04:39:20PM +0200, Rene Engelhard wrote:

> Hi,
>
> On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> > On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > > So in short: we should choose the "well-defined" subset of packages
> > > which are candidates for autobackporting according to their feature to
> > > be buildable inside stable and using an control field to mark the
> > > packages that way.
> >
> > Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> > And if it doesn't build that way, I'd say there's a bug in the package
> > anyways, because it should bump some build dependencies.
>
> build-deps are not necessarily runtime deps.

Sure, and that's why rebuilding is required

> Especially if
> stuff changed in the fs or for policy reasons and that is not reflected in the
> build-deps because the change is not in the build-deps.

Surely, in such cases, the resulting binaries should depend on something
that is not in stable. In such case, either backport this what is not in
stable, or mark the package as not backportable.

> Same for depends.
>
> Or do you (build-)depend on a newer menu for the menu changes stuff?

Depending on the kind of changes, you probably should.

> or will you depend or conflict against all myspell/hunspell dicts
> in stable with ice*? No, you would want to revert that changes to run
> on stable smoothly.

In which case the package is simply not automatically backportable.

Anyways, I don't think this needs an extra control field, especially
considering this will end up being an "opt-in" field. If a field may be
necessary, probably an "opt-out" one would be better.

But I still think that checking for Build-Deps will give a first list
of potentially autobackportable packages, out of which a huge amount
will probably work out of the (autobuild) box, and only a few will need
some adjustments. And this lists really ought to be handled out of
debian/control, IMHO.

> > As a side note, some packages are "easily" backportable, in the sense
> > that they only require a few build-dependencies to be backported. This
> > is the case for xulrunner and iceweasel, where only sqlite needs to be
> > backported for the packages to be backportable.
>
> Actually, xulrunner and iceweasel are bad examples, since they will
> be involved in the hunspell dictionary location transition. A rebuild
> will make them look in a location which does not even exist in stable.
> (Yet that transition has to be done for squeeze)

Well, at least the *current* packages are just fine. But you are right
to point out these, because I do think we, as a whole, are not careful
enough at these details when disrupting the places where files are
installed vs. the according {build,} dependencies updates.

Mike


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Mike Hommey <mh@...> [090925 16:06]:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > So in short: we should choose the "well-defined" subset of packages
> > which are candidates for autobackporting according to their feature to
> > be buildable inside stable and using an control field to mark the
> > packages that way.
>
> Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> And if it doesn't build that way, I'd say there's a bug in the package
> anyways, because it should bump some build dependencies.

Often that is enough, but often things change in a way not expressable
(or not expressed) in Build-Depends.

For example backporting to etch means to change the menu item back to
the old layout for everything that has a menu item.

Between lenny and squeeze there might be similar changes. The difference
between calling install-info and having a trigger for that, for example.
As that is usually done using debhelper, that is no problem backporting
virtually all packages. But a package not using debhelper for this would
most likely not have any build-dependency avoiding a non-functional
package being produced in lenny.

Hochachtungsvoll,
        Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
        Niklaus Wirth


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Nicholas Breen]

On Fri, Sep 25, 2009 at 11:07:55AM +0200, Manuel Prinz wrote:
> However, Sylvestre already pointed you to backports.org. This is a way
> to deal with that: Rebuilding packages from Squeeze on Lenny. But you're
> lost again, as not all software is in Backports, and GROMACS is one of
> the packages missing.

And since IANADD, it's a bit of a hassle for me to put backports there.  I also
maintain backports for my own use, but until now, no one else had ever
expressed any interest in them; I'm happy to assist in making them more
generally available and continuously maintained.


--
Nicholas Breen (wearing the gromacs maintainer hat)
nbreen@...


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steffen Moeller-3]

Nicholas Breen wrote:

> On Fri, Sep 25, 2009 at 11:07:55AM +0200, Manuel Prinz wrote:
>> However, Sylvestre already pointed you to backports.org. This is a way
>> to deal with that: Rebuilding packages from Squeeze on Lenny. But you're
>> lost again, as not all software is in Backports, and GROMACS is one of
>> the packages missing.
>
> And since IANADD, it's a bit of a hassle for me to put backports there.  I also
> maintain backports for my own use, but until now, no one else had ever
> expressed any interest in them; I'm happy to assist in making them more
> generally available and continuously maintained.

Whow! This is quite an effort. Many thanks!
On http://backports.org/dokuwiki/doku.php?id=contribute it is mentioned that
also DDs need to request for their key to be accepted for backports.org.  For
non-DDs, the procedure seems to be that you place your package somewhere and
then someone of the backports-team fetches it. This should then be less work
for you than it is for regular DDs, right? :)

@Alex, should you read this, this thread on debian-science is about helping the
easily outdated scientific applications to enter backports.org. There was a
request for gromacs in backports.org, which Nicholas, its non-DD Debian
maintainer, would be prepared to maintain. Would you accept the Debian
Maintainers of a package to upload the same package also to backports.org, even
if they are not yet DDs ? This would make some sense to me and it would help
Debian at large, I think.

Many thanks and regards

Steffen





--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russell Coker]

On Sat, 26 Sep 2009, Rene Engelhard <rene@...> wrote:
> > Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> > And if it doesn't build that way, I'd say there's a bug in the package
> > anyways, because it should bump some build dependencies.
>
> build-deps are not necessarily runtime deps. Especially if
> stuff changed in the fs or for policy reasons and that is not reflected in
> the build-deps because the change is not in the build-deps.

The runtime dependencies should either be based on the versions of the
packages that were compiled against (in which case they should be correct
automaticall) or they will be based on some specific features (EG a new
version of a package containing /bin/foo adds a new command-line option
to /bin/foo) in which case an explicit versioned dependency should be
sufficient (failure to do so would be a bug in any case).  It should not be
THAT difficult to make a back-port build daemon refrain from building
packages if the runtime dependencies can never be satisfied.

--
russell@...
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen Gran]

This one time, at band camp, Andreas Tille said:
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way.

Sounds like you think it's a good idea.  Why not do it and let us know
how you get on?
--
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@... |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[Andreas Tille-5]

On Sat, Sep 26, 2009 at 09:24:46AM +0100, Stephen Gran wrote:
> Sounds like you think it's a good idea.  Why not do it and let us know
> how you get on?

One point for you beeing the first raising this killer argument. ;-)

Andreas.

--
http://fam-tille.de
Klarmachen zum Ändern!


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Hommey]

On Sat, Sep 26, 2009 at 05:40:58PM +1000, Russell Coker wrote:

> On Sat, 26 Sep 2009, Rene Engelhard <rene@...> wrote:
> > > Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> > > And if it doesn't build that way, I'd say there's a bug in the package
> > > anyways, because it should bump some build dependencies.
> >
> > build-deps are not necessarily runtime deps. Especially if
> > stuff changed in the fs or for policy reasons and that is not reflected in
> > the build-deps because the change is not in the build-deps.
>
> The runtime dependencies should either be based on the versions of the
> packages that were compiled against (in which case they should be correct
> automaticall) or they will be based on some specific features (EG a new
> version of a package containing /bin/foo adds a new command-line option
> to /bin/foo) in which case an explicit versioned dependency should be
> sufficient (failure to do so would be a bug in any case).  It should not be
> THAT difficult to make a back-port build daemon refrain from building
> packages if the runtime dependencies can never be satisfied.

But runtime dependencies can be the result of shlibs bumps, where the
runtime dependency will be different depending on the build-dep version
used at build time. So the selection should be done *after* having tried
at least once to build a package that has all its build-deps
satisfiable.

Mike


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Banck]

On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:

> On Fri, Sep 25, 2009 at 12:58:00PM +0200, Manuel Prinz wrote:
> >
> > Yes. I like the idea but we simply can't rebuild everything from the
> > task pages of these blends since there are also tools from KDE or GNOME
> > which would mean to backport quite a lot of unrelated stuff. Also,
> > packages with code in interpreted language can almost always be used
> > directly from testing. But I think auto-building could work for a
> > well-defined subset of packages.
>
> IMHO this problem is not really Debian Science or Blends related and the
> idea to handle backports analog to non-free autobuilds sounds quite
> reasonable - but in this case we *really* make it analog tp non-free which
> works with a debian/control field
>
>     XS-Autobuild: yes
>
> So why not using a similar field
>
>     XS-Autobackport: yes
>
> ?  Well, it's definitely not that easy but I see a quite large set of
> packages (specifically in the Debian Science field) which perfectly
> compiles against Build-Depends of stable.  If we could handle this set
> automatically for a first shot and think later about those packages
> which need Build-Depends which are not available in stable this would
> be an interesting thing.
>
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way.

One problem is that unlike non-free autobuilds, auto-backports should
happen once the package enters testing, not unstable.  Otherwise, users
tracking this auto-backports repository will basically track unstable
for the applications they use and will get burnt by zero-day
grey-paper-bag uploads or otherwise unstable software.

As such, a facility more like the binNMU triggers for the release-team/
buildd-maintainers might be better; i.e. wait till a package hits
testing, then evaluate its impact and trigger an auto-backport via
wanna-build something else.  Of course, at that point, doing a manual
backports.org upload is not too far off, effort-wise.


Michael


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...