-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 10 Jun 2024 16:14:09 +0900
Source: r-cran-backports
Architecture: source
Version: 1.5.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Charles Plessy
Changes:
r-cran-backports
On 2024-02-26 John Goerzen wrote:
> Hi folks,
> As a person that frequently uploads to bookworm-backports, I am
> wondering how we are handling the time_t transition there?
> The picture of synchronization with testing is a little complicated over
> there. If you change the defa
Hi folks,
As a person that frequently uploads to bookworm-backports, I am
wondering how we are handling the time_t transition there?
The picture of synchronization with testing is a little complicated over
there. If you change the default build flags, you produce unexpected
surprises over
> > > Kind regards, Ilari Jääskeläinen.
> > >
> > > I wonder if you could explain *why* you need this so immediately
> > > and
> > > also
> > > why you asked all the Debian developers at once, please.
> > >
>
> Hi Ilari,
>
>
you need this so immediately and
> > also
> > why you asked all the Debian developers at once, please.
> >
Hi Ilari,
It may be that you are unlucky. Buster is now in Long Term Support (LTS) as
the oldstable distribution. The decision has been taken to close
buster-back
On Thu, Mar 23, 2023 at 07:45:57AM +0200, ijaaskelai...@outlook.com wrote:
> Kind regards, Ilari Jääskeläinen.
I wonder if you could explain *why* you need this so immediately and also
why you asked all the Debian developers at once, please.
There may be a better way to request that Debian
Kind regards, Ilari Jääskeläinen.
> > Reviving this thread that's more than a year old...
> >
> > [...]
> >
> > Known issues that still need to be addressed:
> >
> > * backport from testing rather than unstable
> > * rename the suite from bullseye-backports to something that do
:
* backport from testing rather than unstable
* rename the suite from bullseye-backports to something that does't
clash with the official backports (version strings are already different)
* finish processing the rest of the archive
* better sanity checking to prevent too many dependencies from being
> Watching the talk[0] on automatically providing packages for new
> upstream releases and new upstream git snapshots, I wondered if the same
> tooling could be used to automatically provide stable backports
> for packages in unstable/testing.
>
> There's probably a large number
.
There are alternatives to the debomatic hardware listed here:
https://wiki.debian.org/Hardware/Wanted#Available_hardware
thanks for reply
I did a local debomatic server, did and tested the changes to fix
bullseye/stable build and add bullseye-backports and prepared a PR to
make faster update them: https
://wiki.debian.org/Hardware/Wanted#Available_hardware
thanks for reply
I did a local debomatic server, did and tested the changes to fix
bullseye/stable build and add bullseye-backports and prepared a PR to
make faster update them: https://github.com/debomatic/instances/pull/10
On Wed, 2022-03-23 at 11:13 +0100, Fabio Fantoni wrote:
> Is there someone else who has access to those servers and can please fix?
AFAIK Luca Falavigna is the only one with access.
There are alternatives to the debomatic hardware listed here:
is not possible build for bullseye and bullseye-backports, I
wrote a mail to Luca Falavigna (dktrkranz) but in latest months didn't
replied me.
Is there someone else who has access to those servers and can please fix?
I suppose that conf files used in these servers are stored here:
https
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 20 Dec 2021 14:15:42 +0100
Source: r-cran-backports
Architecture: source
Version: 1.4.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
Changes:
r-cran-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 28 Nov 2021 18:03:25 +0530
Source: r-cran-backports
Architecture: source
Version: 1.4.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Nilesh Patra
Changes:
r-cran-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 08 Nov 2021 16:30:58 +0100
Source: ruby-backports
Architecture: source
Version: 3.21.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team
Changed-By: Daniel Leidert
Changes:
ruby-backports (3.21.0-2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 05 Nov 2021 19:49:47 +0100
Source: ruby-backports
Architecture: source
Version: 3.21.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team
Changed-By: Daniel Leidert
Closes: 996132
Changes:
ruby-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 01 Nov 2021 21:56:45 +0530
Source: r-cran-backports
Architecture: source
Version: 1.3.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Nilesh Patra
Changes:
r-cran-backports
parts knows some of this? I
agree it's a bug in those packages, but I think it would significantly affect
backportability.
This is somewhat orthogonal to the process of actually backporting, but it
might impact the success chances or fitness of backported packages (if they end
up pulling in a lot
: GPL-2
Programming Lang: Shell (bash)
Description : tool locally to mirror a Debian release, including backports
Debian releases a major revision of its operating system about every
two years and a minor revision approximately quarterly, but these
revisions exclude Debian backports. Debia
On 30.08.21 15:49, Jelmer Vernooij wrote:
> I think one of the main challenges here is to make sure that the
> dependencies for packages in unstable/testing are correct.
Why wouldn't they be correct, though? If it's less strict than it should
be, then that is a bug. And if it's too strict,
Hi Lucas,
On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
> Watching the talk[0] on automatically providing packages for new
> upstream releases and new upstream git snapshots, I wondered if the same
> tooling could be used to automatically provide stable backports
>
Hey Lucas
On 2021/08/27 15:04, Lucas Nussbaum wrote:
Oh I wasn't thinking about uploading to the official backports suite.
In the same spirit as the fresh-{releases,snapshots} suites provided by
janitor, I was thinking about an automatically-generated backports
suite.
That sounds great
On Fri, Aug 27, 2021 at 03:04:34PM +0200, Lucas Nussbaum wrote:
> > uploading to -backports also implies the promise to keep maintaining that
> > backport until the next release is out... I'm not sure that part of the
> > upload should be automated nor forgotten ;)
> Oh I
On 27/08/21 at 12:54 +, Holger Levsen wrote:
> On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
> > There's probably a large number of packages that just require a
> > rebuild (+ test with autopkgtest) to be backported.
>
> uploading to -backports als
On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
> There's probably a large number of packages that just require a
> rebuild (+ test with autopkgtest) to be backported.
uploading to -backports also implies the promise to keep maintaining that
backport until the next release
po = dict(origin='Debian Backports', codename='buster backports')
| buster = dict(origin='Debian', codename='buster')
|
| # origin: bullseye
| # target: buster-backports
| # Packages from buster can be used to satisfy build dependencies
| rr = RebuildResol
upstream git snapshots, I wondered if the same
tooling could be used to automatically provide stable backports
for packages in unstable/testing.
There's probably a large number of packages that just require a
rebuild (+ test with autopkgtest) to be backported.
Additionally, one could imagine
package is using deprecates the old API, which in turn breaks the
> package. Do we have documented conventions that where the fixed package
> should be uploaded to: stable-proposed-updates or backports?
>
Usually you need to backport the relevant patch, instead of uploading
a new upstream version to stable.
--
Shengjing Zhu
be uploaded to: stable-proposed-updates or backports?
Yes, absolutely stable updates, as documented in both the dev-ref and
backports site.
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> Backports are about additional features that are only offered in a
documented conventions that where the fixed package
should be uploaded to: stable-proposed-updates or backports?
Thanks,
Yao Wei
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 05 Jan 2021 11:30:26 +0100
Source: r-cran-backports
Architecture: source
Version: 1.2.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
Changes:
r-cran-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 20 Nov 2020 11:25:28 +0100
Source: r-cran-backports
Architecture: source
Version: 1.2.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
Changes:
r-cran-backports
Hello Félix,
Am 20.09.20 um 11:33 schrieb Félix Sipma:
> Hello Emilio and others,
>
> On 2020-09-10 19:32+0200, Emilio Pozuelo Monfort wrote:
>> I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that
>> goes
>> well I'll start uploading things to buster (coordinating with
On 20/09/2020 11:33, Félix Sipma wrote:
> Hello Emilio and others,
>
> On 2020-09-10 19:32+0200, Emilio Pozuelo Monfort wrote:
>> I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that
>> goes
>> well I'll start uploading things to buster (coordinating with the SRMs).
>
>
Hello Emilio and others,
On 2020-09-10 19:32+0200, Emilio Pozuelo Monfort wrote:
I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that goes
well I'll start uploading things to buster (coordinating with the SRMs).
Was the build successful? Did you also try to build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 18 Sep 2020 08:32:03 +0200
Source: r-cran-backports
Architecture: source
Version: 1.1.10-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
Changes:
r-cran-backports
Hi. Any progress here?
Or any way to help?
Am 01.09.20 um 19:17 schrieb Moritz Muehlenhoff:
>> It may be more future-proof, in case we need it for a future
>> rustc for the next ESR bump.
>
> My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to
> be proven wrong :-) So
gt;
>>> Yes please upload your LLVM9 and wasi-libc backports.
>>
>> fwiw I started to look at this and have an LLVM 10 backport ready. Should we
>> go
>> with that instead?
>
> I'm fine either way.
>
>> It may be more future-proof, in case we n
On Wed, 2 Sep 2020 at 08:34, Moritz Muehlenhoff wrote:
> On Wed, Sep 02, 2020 at 05:25:28AM +0900, Mike Hommey wrote:
> > Note Firefox doesn't need wasi-libc at the moment. Neither does
> > thunderbird AFAICT.
>
> Not Firefox/Thunderbird itself, but rustc in the versions needed by ESR 78
> build
On Wed, Sep 02, 2020 at 05:25:28AM +0900, Mike Hommey wrote:
> Note Firefox doesn't need wasi-libc at the moment. Neither does
> thunderbird AFAICT.
Not Firefox/Thunderbird itself, but rustc in the versions needed by ESR 78
build depends on it.
Cheers,
Moritz
have a look at it.
> > >
> > > Yes please upload your LLVM9 and wasi-libc backports.
> >
> > fwiw I started to look at this and have an LLVM 10 backport ready. Should
> > we go
> > with that instead?
>
> I'm fine either way.
>
> >
On Tue, Sep 01, 2020 at 04:35:42PM +0200, Emilio Pozuelo Monfort wrote:
> On 01/09/2020 14:05, Christoph Martin wrote:
> > Hi,
> >
> > I am not shure if I can help, but I can try and have a look at it.
> >
> > Yes please upload your LLVM9 and wasi-libc backp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 01 Sep 2020 16:56:58 +0200
Source: r-cran-backports
Architecture: source
Version: 1.1.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
Changes:
r-cran-backports
On 01/09/2020 14:05, Christoph Martin wrote:
> Hi,
>
> I am not shure if I can help, but I can try and have a look at it.
>
> Yes please upload your LLVM9 and wasi-libc backports.
fwiw I started to look at this and have an LLVM 10 backport ready. Should we go
with that instead?
Hi,
I am not shure if I can help, but I can try and have a look at it.
Yes please upload your LLVM9 and wasi-libc backports.
Regards
Christoph
Am 31.08.20 um 20:26 schrieb Moritz Mühlenhoff:
>
>> I think we can reuse the same approach as before, by staging uploads
>> in -p
ll have to do some toolchain backports as usual.
> >
> > Has someone started to look at this?
> >
> > I have taken a quick look and it looks like we need rustc 1.41 and cargo
> > 0.31.
> > We currently have:
> >
> > rustc | 1.34.2+dfsg1-1~
Hello everyone, My name is Rodrigo and I would like to know if there is
any date for the mesa3d package to enter buster-backports, because I
have an AMD Radeon video card and the current version of the buster is
18.3.6, but it doesn't work on my card, at least the OpenCL option.
Your message dated Thu, 30 Jul 2020 13:15:22 +0200
with message-id <20200730111521.3es5upqv2hu4b...@percival.namespace.at>
and subject line Re: Bug#867400: general: backports suite-names can't be
properly used in sources.list
has caused the Debian Bug report #867400,
regarding general: bac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 29 Jun 2020 16:30:55 +0200
Source: r-cran-backports
Architecture: source
Version: 1.1.8-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Dylan Aïssi
Changes:
r-cran-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 23 May 2020 09:17:21 +0200
Source: r-cran-backports
Architecture: source
Version: 1.1.7-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Dylan Aïssi
Changes:
r-cran-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 08 Apr 2020 10:19:25 +0200
Source: r-cran-backports
Architecture: source
Version: 1.1.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Dylan Aïssi
Changes:
r-cran-backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 07 Feb 2020 12:19:04 -0500
Source: ruby-backports
Architecture: source
Version: 3.16.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers
Changed-By: Utkarsh Gupta
Changes:
ruby-backports
r requirements for packages that are being uploaded
>there?
>>
>> buster-fasttrack suite:
>>
>> If a package cannot be part of a stable release because we cannot
>provide
>> security updates for the entire stable lifecylce then that package
>cannot be
>> in
part of a stable release because we cannot provide
> security updates for the entire stable lifecylce then that package cannot be
> in testing or backports. Those packages get security updates along with new
> upstream versions and such software can be in FastTrack.
Does the package need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 07 Oct 2019 09:25:30 +0200
Source: r-cran-backports
Binary: r-cran-backports
Architecture: source
Version: 1.1.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz wrote:
Hi Lucaus,
Given that backports are a no-go, I hope that
<http://fasttrack.debian.net/> will make quick progress and turn
into an
official service soon.
basically a good idea, but
I'm part of the Fast Track team and I'
Hi,
On 02/10/19 at 23:23 +0200, Bernd Zeimetz wrote:
> > Given that backports are a no-go, I hope that
> > http://fasttrack.debian.net/ will make quick progress and turn into an
> > official service soon.
>
> basically a good idea, but
> - what are your requirements
Just few answers derived from common sense:
On Thursday, 3 October 2019 7:23:41 AM AEST Bernd Zeimetz wrote:
> - how do you want to avoid that this service becomes a mess?
We don't have a perfect solution for this problem in the official backports
either. Sometimes there is just enough t
Hi Lucaus,
> Given that backports are a no-go, I hope that
> http://fasttrack.debian.net/ will make quick progress and turn into an
> official service soon.
basically a good idea, but
- what are your requirements for packages that are being uploaded there?
- how do you want
t want to reopen the debate about policy for backports and
inclusion into testing, that was already discussed at length.
But it saddens me a bit that Debian is not providing a solution to our
users other than to install unofficial packages (from me, or directly
from upstream).
Given that backports are
upported in
> oldstable-security
> after October, someone needs to step up to take care of backports to a
> Stretch point
> release before October 22nd (or in case of poor timing, we can also release
> build
> dependency updates via stretch-security).
There hasn't been any visib
On 2019, ജൂലൈ 28 6:36:21 PM IST, Phil Morrell wrote:
>On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
>> I think STS (Short term support) will fit nicely with LTS. If there
>is
>> no serious objections, I'd go with this.
>
>As debconf is finishing, though I don't know if either
On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
> I think STS (Short term support) will fit nicely with LTS. If there is
> no serious objections, I'd go with this.
As debconf is finishing, though I don't know if either of you attended
this year, has there been any progress on this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 17 Jul 2019 16:58:07 +0200
Source: r-cran-backports
Binary: r-cran-backports
Architecture: source
Version: 1.1.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian R Packages Maintainers
Changed-By: Andreas Tille
On Wed, Jul 10, 2019 at 11:42:40AM +0200, Julien Cristau wrote:
> buster-backports exists. AIUI this is an apt bug when dealing with
> empty repos. (Although why are you setting default-release to
> buster-backports?)
JFTR: Yes it is an apt "bug" in that empty reposit
kage (what package? they don't exist) from a
> > repo that doesn't exist.
> >
>
> I tried a package that is not in backports, it was just for test (for an
> automation tool I use)
> It should fail with a *package not found* , but should not fail about
> buster-backports
Le mer. 10 juil. 2019 à 11:35, Andrey Rahmatullin a
écrit :
> On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote:
> > I tried a package that is not in backports, it was just for test (for an
> > automation tool I use)
> > It should fail with a *package no
On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote:
> I tried a package that is not in backports, it was just for test (for an
> automation tool I use)
> It should fail with a *package not found* , but should not fail about
> buster-backports being non available.
I
tried to install a package (what package? they don't exist) from a
> repo that doesn't exist.
>
>
> I tried a package that is not in backports, it was just for test (for an
> automation tool I use)
> It should fail with a *package not found* , but should not fail about
> b
I tried a package that is not in backports, it was just for test (for an
automation tool I use)
It should fail with a *package not found* , but should not fail about
buster-backports being non available.
Is the problem linked to buster-backports not existing yet ? Is backports
repo not created automatical
On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote:
> So, am I doing something wrong?
You tried to install a package (what package? they don't exist) from a
repo that doesn't exist.
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi,
it may be a silly question, but doing some tests on a Debian buster, I got
errors trying to install a package from buster-backports.
I added to sources.list.d info to set buster-backports but i get this error:
E: The value 'buster-backports' is invalid for APT::Default-Release
t rust/cargo needs a lot more attention.
> If we want to continue to have Firefox/Thunderbird supported in
> oldstable-security
> after October, someone needs to step up to take care of backports to a
> Stretch point
> release before October 22nd (or in case of poor timing, w
was already updated wrt Rust/Cargo for ESR 60, so there's at least no
requirement to bootstrap stage0 builds this time.
If we want to continue to have Firefox/Thunderbird supported in
oldstable-security
after October, someone needs to step up to take care of backports to a Stretch
point
release
Hi Dominik,
On 26/12/18 2:16 am, Dominik George wrote:
> Heisann, alle sammen,
>
> as announced in the recent thread about maintaining, I hereby propose a
> repository that allows making “backports” of packages available to users
> of the stable distribution, if those
On Tue, 2 Apr 2019 23:50:14 -0400
Thomas Walker wrote:
> So 3 of the 25 releases under archive.debian.org/debian have 'Valid-Until'
> tags, the rest do not. It works quite well for its original purpose, to
> indicate whether a repo mirror is stale, but anyone relying on 'Valid-Until'
> to
On Tue, Apr 02, 2019 at 10:19:47PM +0200, Joerg Jaspert wrote:
> On 15360 March 1977, Thomas Walker wrote:
>
> >Hi, I've noticed that previous release's backports have the
> >'Valid-Until' tag removed when they are moved to archive.debian.org
> >but that seems to have n
On 15360 March 1977, Thomas Walker wrote:
Hi, I've noticed that previous release's backports have the
'Valid-Until' tag removed when they are moved to archive.debian.org
but that seems to have not happened with 'jessie-backports' (which has
a 'Valid-Until' that is well past expiration). I fully
Hi, I've noticed that previous release's backports have the 'Valid-Until' tag
removed when they are moved to archive.debian.org but that seems to have not
happened with 'jessie-backports' (which has a 'Valid-Until' that is well past
expiration).
I fully understand that backports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 25 Feb 2019 08:59:10 -0300
Source: ruby-backports
Architecture: source
Version: 3.11.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers
Changed-By: Lucas Kanashiro
Closes: 918600
Changes
the point of
> jessie-backports (and of much of what we do in Debian) is to help
> Debian's users. In this case I was a user who had something go wrong,
> but I was in the unusually fortunate situation of being able (due to
> my personal skills, my support network, and my availabl
s to install kernels,
so that they keep getting updated when ABI level is bumped, and to
resolve dependencies.
> My aim was to share my experience, because I guess the point of
> jessie-backports (and of much of what we do in Debian) is to help
> Debian's users. In this case I was a user
Firstly, thanks for taking the time to read what I wrote. (Thanks
also for Sam for his helpful perspective.)
Stepping back a bit, and firmly putting my `user' hat on:
My aim was to share my experience, because I guess the point of
jessie-backports (and of much of what we do in Debian
>>>>> "Rhonda" == Rhonda D'Vine writes:
>> installer image to have the jessie-backports kernel and modules,
>> but that is not relevant to this tale.)
Rhonda> I don't really follow - you now can get rid of that special
Rhonda>
Hi,
On 2/13/19 1:09 PM, Ian Jackson wrote:
> I would like to recount a situation. I'm not sure where, if anywhere,
> the root bug(s) lie, but I am inclined to say that a big part of the
> problem was a change to the contents of jessie-backports. I would be
> interested
On February 13, 2019 4:07:45 PM UTC, Ansgar wrote:
>More importantly Jessie has reached end-of-life[1]. Please do not
>expect related suites (such as -security, -backports, -proposed-
>updates, -updates) to continue working after this.
-security and -updates are part of the LTS sou
Ansgar writes ("Re: Removal of linux-base from jessie-backports broke Xen
upstream CI"):
> More importantly Jessie has reached end-of-life[1]. Please do not
> expect related suites (such as -security, -backports, -proposed-
> updates, -updates) to continue working after
On Wed, 2019-02-13 at 12:46 +, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
> Xen upstream CI"):
> > Jessie backports doesn't exist anymore. For some time now. It is already on
> > its way to archive.d.o.
>
On Wed, 13 Feb 2019, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
> Xen upstream CI"):
> > Jessie backports doesn't exist anymore. For some time now. It is already on
> > its way to archive.d.o.
>
> Thanks
Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
Xen upstream CI"):
> Jessie backports doesn't exist anymore. For some time now. It is already on
> its way to archive.d.o.
Thanks are due to to folks on #debian-uk who pointed out this
announcement (fr
On Wed, 13 Feb 2019, Ian Jackson wrote:
> Introduction
>
>
> I would like to recount a situation. I'm not sure where, if anywhere,
> the root bug(s) lie, but I am inclined to say that a big part of the
> problem was a change to the contents of jessie-b
Introduction
I would like to recount a situation. I'm not sure where, if anywhere,
the root bug(s) lie, but I am inclined to say that a big part of the
problem was a change to the contents of jessie-backports. I would be
interested to hear what the backports team and ftpmaster have
Hi Dominik,
happy new year to you and everybody.
I read your proposal, and the whole discussion with great interest.
In brief, I think that it would be wise to uncouple the fast-paced
("fast-forwards" ?) repository that you propose from the stable backports,
and I hope that you wi
On Mon, Dec 31, 2018 at 1:06 PM Ben Hutchings wrote:
> At the risk of bikeshedding, some alternate names that might be less
> confusing:
>
> - fresh-apps
> - evergreen
> - rolling-apps
At further risk of bikeshedding, how about "sideports"?
1. Uses a metaphor ra
On 1/1/19 3:42 PM, Scott Leggett wrote:
> To continue the bikeshedding, what about "express"? Seems quite fitting
> as the packages don't make the usual stop through testing...
I think STS (Short term support) will fit nicely with LTS. If there is
no serious objections, I'd go with this.
term is used a lot in the sense of
> > > > 'rolling releases' by other distributions, and also in discussions
> > > > about
> > > > constantly usable testing.
> > >
> > > Well, it only makes things clear as the packages in this repo
dy to avoid reusing volatile). I think we can
> > > > take the setup discussions offlist.
> > >
> > > Please don't name it 'rolling'. This term is used a lot in the sense of
> > > 'rolling releases' by other distributions, and also in discussions
>
in the sense of
>> 'rolling releases' by other distributions, and also in discussions
>> about
>> constantly usable testing.
>
> Well, it only makes things clear as the packages in this repo will be rolling.
... as packages do in unstable, testing and ${stable}-backports
1 - 100 of 441 matches
Mail list logo
