Backports Team delegation
=
I'm sorry for my mistake to copy-and-paste from last delegation text
while not remembering Rhonda changed her name. I'd like to immediately
fix the appointment for the Backports Team. The correct team member
list is:
- Alex
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 develo
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 th
essed:
* 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
ns in the loop.
>
> 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
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:
https://wiki.debian.org/Hardware/Wanted#Available_h
ually 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 he
s would be affected. Maybe piuparts 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 (i
: 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, experime
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
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 ;)
>
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 a
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 rel
='bullseye')
| buster_bpo = dict(origin='Debian Backports', codename='buster backports')
| buster = dict(origin='Debian', codename='buster')
|
| # origin: bullseye
| # target: buster-backports
| # Packages
eam 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 of packages that just require a
rebuild (+ test with autopkgtest) to be backported.
Addition
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
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 new
&
documented conventions that where the fixed package
should be uploaded to: stable-proposed-updates or backports?
Thanks,
Yao Wei
signature.asc
Description: PGP signature
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 the
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).
>
> Was
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 Thunderb
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 mayb
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 backport
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 -propo
#x27;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+dfs
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
- what are your 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
not be 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 pac
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
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
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 to avoid
I don'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 tha
ird 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, we can also release
> build
> dependency updates via stretch-security).
There hasn't been
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
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 repositorie
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-
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 not fo
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 don
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 ab
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 a
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
Seems that 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
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
re
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 pac
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 indi
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
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'
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
uess 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 av
to use meta packages 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.
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
Rhond
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 thi
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.
>
> T
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
announcemen
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
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
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 will
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.
signat
ng'. 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 package
gested already 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 distribution
#x27;. 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 will be rolling.
... as packages do in u
On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer wrote:
>Pirate Praveen:
>> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>>> If the problem is hardware and connectivity, then IMO you can easily
>>> find a sponsor for it. My company could well offer it for example
>>> (hosted in Geneva with very n
Pirate Praveen:
> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>> If the problem is hardware and connectivity, then IMO you can easily
>> find a sponsor for it. My company could well offer it for example
>> (hosted in Geneva with very nice connectivity to almost everywhere).
>>
>> Setting-up a repos
On 12/30/18 8:02 AM, Pirate Praveen wrote:
> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>>> If you know how to start with a new service at
>>> {volatile,fastpaced,whatever}.debian.net without having to reinvent the
>>> wheel for acceptign uploads, getting packages built, etc., please
>>> enlighten
On 12/30/18 12:47 AM, Wouter Verhelst wrote:
> On Wed, Dec 26, 2018 at 07:19:02PM +0100, Dominik George wrote:
>> - It costs a lot time that could better be used elsewhere.
>> - It costs extra money, which I for one do not have to spare.
>
> So ask someone who does and who would care about this
On 12/28/18 11:06 AM, Thomas Goirand wrote:
> If the problem is hardware and connectivity, then IMO you can easily
> find a sponsor for it. My company could well offer it for example
> (hosted in Geneva with very nice connectivity to almost everywhere).
>
> Setting-up a repository isn't hard. And
m sure that if you ask nicely, ftpmaster people would be happy to help
you out in setting up things, if you get stuck. After all, they did that
for backports initially, too, if I'm not mistaken...
[...]
> Don't get me wrong - I would not hesitate to go through it if it were
> for anyt
On 12/26/18 8:16 PM, Dominik George wrote:
>> For backports the general supportability assumption is that you provide a
>> sane upgrade path from stable to the backports and from the backport to the
>> next stable (optimally the same package). Once you take the presence of the
ins should get a ping of a higher release version, so
> if needed they can adopt it to experimental before it goes to unstable.
>
> This is a bit what i do for samba ( and debian )
>
> Just my suggest as community helper.
>
>
> Greetz,
>
> Louis
If you ca
On 12/27/18 3:06 PM, Dominik George wrote:
>> Basically you would like to build an architecture equivalent to Ubuntu's
>> PPA
>
> No. Please at least try reading the thread first - it was explicitly
> explained several times that this has absolutely nothing to do with the
> idea of PPAs.
Well, I
Thomas Goirand schrieb:
> And for a start, I don't think you really need a buildd network, just amd64
> is ok-ish.
Agreed. If there's actual demand for further architecture support,
it will appear naturally by people offering to do the necessary
setup.
Cheers,
Moritz
(Please reply to pkg-samba-maint only)
Le jeu. 27 déc. 2018 à 11:00, L.P.H. van Belle a écrit :
>
>
> Hai,
Hi,
> A very interesting thread this, since im doing this already for samba, my
> comments..
> If i may ..
>
> Im running a samba repo now for jessie and stretch. ( and ubuntu 18.04 )
> I
On 12/26/18 7:19 PM, Dominik George wrote:
> Hi,
>
>> 2. I am happy with the current charter of backports and I think it's
>> possible to move forward with fastpaced without having to change
>> that charter.
>
> Yep. That's exactly why the prop
ats this entirely.
This is *NOT* what the Debian Bikeshed proposal is about. They would
*not* be managed "by some person alone". Please do your homework, and
read the proposal, especially this one:
https://lists.debian.org/debian-devel/2013/05/msg00131.html
> No. The dpendencies
> Basically you would like to build an architecture equivalent to Ubuntu's
> PPA
No. Please at least try reading the thread first - it was explicitly
explained several times that this has absolutely nothing to do with the
idea of PPAs.
-nik
signature.asc
Description: PGP signature
Hi guys,
Trying to make sure I understand clearly this long thread here.
Basically you would like to build an architecture equivalent to Ubuntu's
PPA that users could add to their apt sources to get newer versions faster
instead of dealing with their apt preferences?
I personally like the curren
Den 27. desember 2018 12:30:33 CET, skrev Holger Levsen :
>On Wed, Dec 26, 2018 at 11:37:21PM +0100, Dominik George wrote:
>> As long as the package is in -volatile
>
>FYI: as long as this proposal is been presented with the name -volatile
>it's dead to me and saves me from reading mails in this th
1 - 100 of 402 matches
Mail list logo
