Hello:
As the initial trigger of these interventions, may I ask if anything
has been done to provide version 4.0 of GROMACS for amd64 lenny?
thanks
francesco pietra
On Fri, Sep 25, 2009 at 2:56 PM, Andreas Tille andr...@an3as.eu wrote:
[Reply-To set to debian-devel because this topic belongs
On Sat, Sep 26, 2009 at 05:40:58PM +1000, Russell Coker wrote:
On Sat, 26 Sep 2009, Rene Engelhard r...@debian.org 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
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
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
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
On Sat, 26 Sep 2009, Rene Engelhard r...@debian.org 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
[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
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.
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
Andreas Tille andr...@an3as.eu wrote:
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
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
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
* Mike Hommey m...@glandium.org [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
Frank Küster wrote:
For some teTeX (or older TeXLive?) packages, I've used a
sarge-backport (or whatever the stable version was) target in
debian/rules. It added a changelog entry with backport version number,
and it switched some patches and build-deps (in particular, poppler
wasn't
14 matches
Mail list logo
