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
On 01/09/2020 19:17, Moritz Muehlenhoff wrote:
> 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-l
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
On Tue, Sep 01, 2020 at 07:17:29PM +0200, Moritz Muehlenhoff wrote:
> 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 p
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 backports.
>
> fwiw I started to look at th
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? It may be more fu
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 -proposed-updates (or o
[Adding debian-devel to the list]
On Sun, Aug 02, 2020 at 06:21:30PM +0200, Moritz Mühlenhoff wrote:
> > We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3
> > comes out. We have some time still, but if we want FF and TB to keep being
> > supported, we'll have to do some t
On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote:
> Hi,
> Firefox 68 will be the next ESR release series. With the release of Firefox
> 68.2
> on October 22nd, support for ESR 60 will cease.
>
> ESR 68 will require an updated Rust/Cargo toolchain and build dependencies not
> pres
On 02.07.19 22:45, Moritz Mühlenhoff wrote:
Hi,
> ESR 68 will require an updated Rust/Cargo toolchain and build dependencies not
> present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more).
> Stretch was already updated wrt Rust/Cargo for ESR 60, so there's at least no
> requiremen
On Sun, Mar 2, 2014 at 12:44 AM, Julien Cristau wrote:
> No, packages that aren't in testing only have their urgency ignored if
> it's more than medium. So they're candidates for migration after either
> 5 or 10 days.
Hmm, ok. Thanks for clarifying.
--
bye,
pabs
http://wiki.debian.org/PaulWis
On Fri, Feb 28, 2014 at 13:18:02 +0800, Paul Wise wrote:
> On Fri, Feb 28, 2014 at 1:14 PM, Thomas Goirand wrote:
>
> > AFAICT, it's 5 days now.
>
> The default urgency in dch is medium now, which britney interprets as
> 5 days for existing packages. Packages that aren't in testing have
> their
On Fri, Feb 28, 2014 at 1:14 PM, Thomas Goirand wrote:
> AFAICT, it's 5 days now.
The default urgency in dch is medium now, which britney interprets as
5 days for existing packages. Packages that aren't in testing have
their urgency ignored IIRC and migrate after 10 days.
--
bye,
pabs
http://w
On 02/28/2014 09:40 AM, Michael Gilbert wrote:
> On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote:
>>
>> [micah]
>>> it feels like a bit too aggressive pressure for my tastes. I've seen
>>> a lot of developers of packages who have found out their package will
>>> be removed from testing, but
On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote:
>
> [micah]
>> it feels like a bit too aggressive pressure for my tastes. I've seen
>> a lot of developers of packages who have found out their package will
>> be removed from testing, but don't have the time to resolve the
>> situation befor
Nick Phillips writes:
> And if the newer version, for example, has updated a database schema in
> a non-backward-compatible way?
The same problem would apply to testing, so there would be a very high
incentive to find a way to fix that for testing users. Backports users
would then benefit from
On Wed, 2014-02-26 at 09:47 +0100, Gerfried Fuchs wrote:
> Erm, no, not at all. A package in stable-bpo can't have a newer
> version than testing when we release. With the removal there can be two
> situations:
>
> * After fixing the issue that got the package removed from testing, the
>p
* Peter Samuelson [2014-02-26 18:36:10 CET]:
> [micah]
> > it feels like a bit too aggressive pressure for my tastes. I've seen
> > a lot of developers of packages who have found out their package will
> > be removed from testing, but don't have the time to resolve the
> > situation before it gets
[micah]
> it feels like a bit too aggressive pressure for my tastes. I've seen
> a lot of developers of packages who have found out their package will
> be removed from testing, but don't have the time to resolve the
> situation before it gets removed, resulting in much pulling of hair.
If only w
Hi.
* micah [2014-02-26 16:48:45 CET]:
> Gerfried Fuchs writes:
> > Remove from stable-bpo if it's not expected to come back in is what we
> > actually do, yes. And to have an overview of these situations I created
> > myself the diffstats page:
> > http://backports.debian.org/wheezy-backp
On Feb 26, 2014 10:49 AM, "micah" wrote:
> For example, say package X has been backported at version 1.0, version
> 2.0 is uploaded to sid, transitions to jessie and then has an RC bug
> that threatens removal.
If the RC bug is properly versioned, then the 1.0 upload, which isn't
affected, should
Gerfried Fuchs writes:
> Remove from stable-bpo if it's not expected to come back in is what we
> actually do, yes. And to have an overview of these situations I created
> myself the diffstats page:
> http://backports.debian.org/wheezy-backports/overview/
>
> Looking at the "not available" pa
Hi there.
* Paul Tagliamonte [2014-02-25 23:59:05 CET]:
> I'm sending to both -devel and backports. I'm not sure which is the
> correct list. If one's wrong, feel free to drop it in replies.
>
> I've been talking with a mentee about backporting procedures, and I've
> explained why we don't b
On Tue, Feb 25, 2014 at 3:33 PM, Paul Wise wrote:
>> What shall we do? Remove from stable-bpo? Hope an update comes around?
>> Does it make sense to revisit the rules? Does a wait until testing still
>> make sense (ok, waiting always makes sense, but beyond the 'let it
>> settle' thing)
>
> Autor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
Am 26.02.14 00:33, schrieb Paul Wise:
yes ... and the package installed from oldstable-backports is newer
then oldstable. This situation we have had sometimes in the past (eg.
php-suhosin).
The problem that a package, which is in stable-ba
On Wed, Feb 26, 2014 at 6:59 AM, Paul Tagliamonte wrote:
> However, with the new testing removals from the release team (which is
> totally great for creating an always releasable testing, many thanks for
> that), we can create a situation where stable-bpo has a newer version
> than testing when w
On Tue, 26 Mar 2013 19:02:25 +0100
Mike Gabriel wrote:
> >> Or is there any harm?
> >
> > stable stops being stable?
>
> Only happens if you install with -t wheezy-backports, doesn't it?
Yes, I think so and wrote as above.
--
Regards,
Hideki Yamane henrich @ debian.or.jp/org
http://w
Hi,
On Di 26 Mär 2013 16:12:36 CET Lennart Sorensen wrote:
On Tue, Mar 26, 2013 at 02:16:51PM +0900, Hideki Yamane wrote:
Hi,
On Mon, 18 Mar 2013 13:59:02 +0100
Gerfried Fuchs wrote:
> == For Users ==
>
> What exactly does that mean for you? For users of wheezy, the
> sources.list entry wi
On Tue, Mar 26, 2013 at 02:16:51PM +0900, Hideki Yamane wrote:
> Hi,
>
> On Mon, 18 Mar 2013 13:59:02 +0100
> Gerfried Fuchs wrote:
> > == For Users ==
> >
> > What exactly does that mean for you? For users of wheezy, the
> > sources.list entry will be different, a simple substitute of squeeze
Hi,
On Mon, 18 Mar 2013 13:59:02 +0100
Gerfried Fuchs wrote:
> == For Users ==
>
> What exactly does that mean for you? For users of wheezy, the
> sources.list entry will be different, a simple substitute of squeeze
> for wheezy won't work. The new format is:
>
> deb http://ftp.debian.org/d
On Fri, Jan 25, 2013 at 2:19 PM, Henrique de Moraes Holschuh
wrote:
> On Fri, 25 Jan 2013, Wookey wrote:
>> +++ martin f krafft [2013-01-25 16:06 +1300]:
>> > also sprach David Kalnischkies [2013.01.25.0020
>> > +1300]:
>> > > You can find much of the same discussion in the bugreport requesting
On Fri, 2013-01-25 at 11:19:00 -0200, Henrique de Moraes Holschuh wrote:
> Now, complete documentation of the Release files, where the tags you can use
> in repositories to get such nice functionality like ButAutomaticUpdates...
> Does anyone know where such a thing might dwell?
I don't think ther
On Fri, 25 Jan 2013, Wookey wrote:
> +++ martin f krafft [2013-01-25 16:06 +1300]:
> > also sprach David Kalnischkies [2013.01.25.0020
> > +1300]:
> > > You can find much of the same discussion in the bugreport requesting
> > > implementation of this feature in APT: #596097
> >
> > Thanks for th
+++ martin f krafft [2013-01-25 16:06 +1300]:
> also sprach David Kalnischkies [2013.01.25.0020
> +1300]:
> > You can find much of the same discussion in the bugreport requesting
> > implementation of this feature in APT: #596097
>
> Thanks for the pointer! I missed this discussion un^Wfortunate
martin f krafft schrieb am Friday, den 25. January 2013:
> also sprach Alexander Wirt [2013.01.25.2001 +1300]:
> > > Setting ButAutomaticUpdates certainly doesn't have enough pros to
> > > warrant this change, just like that. The way it was before does have
> > > a huge pro though: it's the way i
also sprach Alexander Wirt [2013.01.25.2001 +1300]:
> > Setting ButAutomaticUpdates certainly doesn't have enough pros to
> > warrant this change, just like that. The way it was before does have
> > a huge pro though: it's the way it's been for years. You know, never
> > change a winning team…
> t
martin f krafft schrieb am Thursday, den 24. January 2013:
> also sprach Joerg Jaspert [2013.01.24.2017 +1300]:
> > > And say that a year later 2.3 comes out and it's the bee's knees
> > > because it fully replaces 1.1 except that the configuration cannot
> > > be automatically migrated, and all
martin f krafft schrieb am Thursday, den 24. January 2013:
> Hey folks,
>
> For a while now, the backports archive sets "ButAutomaticUpdates:
> yes" in its Release file, causing packages in the archive to be
> pinned with priority 100, rather than 1 (which was previously the
> case).
>
> The eff
also sprach David Kalnischkies [2013.01.25.0020 +1300]:
> You can find much of the same discussion in the bugreport requesting
> implementation of this feature in APT: #596097
Thanks for the pointer! I missed this discussion un^Wfortunately.
Anyway, it seems that most people are in favour of this
On 24/01/13 07:48, martin f krafft wrote:
> also sprach Joerg Jaspert [2013.01.24.2017
> +1300]:
>>> And say that a year later 2.3 comes out and it's the bee's
>>> knees because it fully replaces 1.1 except that the
>>> configuration cannot be automatically migrated, and all the
>>> power users on
On Thu, Jan 24, 2013 at 6:39 AM, martin f krafft wrote:
> I think we ought to revert this change and turn off
> ButAutomaticUpgrades for the backports archive (and update
> apt_preferences(5)).
You can find much of the same discussion in the bugreport requesting
implementation of this feature in
also sprach Joerg Jaspert [2013.01.24.2017 +1300]:
> > And say that a year later 2.3 comes out and it's the bee's knees
> > because it fully replaces 1.1 except that the configuration cannot
> > be automatically migrated, and all the power users on #debian-devel
> > persuade you to backport it, wh
martin f krafft writes:
> also sprach Russ Allbery [2013.01.24.1856 +1300]:
>> I always understood that I had a responsibility as a backporter to
>> release security fixes as necessary, and if I wasn't going to do that,
>> I shouldn't upload the backport in the first place. I handle backport
>>
On 13101 March 1977, martin f. krafft wrote:
>> I always understood that I had a responsibility as a backporter to release
>> security fixes as necessary, and if I wasn't going to do that, I shouldn't
>> upload the backport in the first place. I handle backport security fixes
>> exactly the way t
also sprach Russ Allbery [2013.01.24.1856 +1300]:
> I always understood that I had a responsibility as a backporter to release
> security fixes as necessary, and if I wasn't going to do that, I shouldn't
> upload the backport in the first place. I handle backport security fixes
> exactly the way
On Thu, Jan 24, 2013 at 12:39 AM, martin f krafft wrote:
> Hey folks,
>
> For a while now, the backports archive sets "ButAutomaticUpdates:
> yes" in its Release file, causing packages in the archive to be
> pinned with priority 100, rather than 1 (which was previously the
> case).
>
> The effect o
martin f krafft writes:
> While this might seem like a good idea at first — like when
> a security fix reaches the backports archive
Indeed.
> I am sure we all agree that the
> deny-all-but-what-is-explicitly-allowed policy is the better one. So
> why did we make the switch?
Because of securit
On Thu, Oct 7, 2010 at 11:35, Ansgar Burchardt wrote:
> Sandro Tosi writes:
>
>> Just a note that using Send-To requires to add a bug control file to
>> each upload to bpo which I consider a huge overkill solution to that.
>
> reportbug's README.developers.gz suggests to use dpkg's Origin and Bug
Sandro Tosi writes:
> Just a note that using Send-To requires to add a bug control file to
> each upload to bpo which I consider a huge overkill solution to that.
reportbug's README.developers.gz suggests to use dpkg's Origin and Bugs
tags (see deb-control(5)) instead of Send-To. These fields c
On Wed, 06 Oct 2010, Sandro Tosi wrote:
> On Wed, Oct 6, 2010 at 15:33, Stefano Zacchiroli wrote:
> > On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote:
> >> >From a reportbug POV, it's not a big deal to redirect the reports for
> >> bpo packages to something different than sub...@b.d.o.
On Wed, Oct 6, 2010 at 15:33, Stefano Zacchiroli wrote:
> On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote:
>> >From a reportbug POV, it's not a big deal to redirect the reports for
>> bpo packages to something different than sub...@b.d.o. What I need to
>> know is:
>>
>> - the address
On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote:
> >From a reportbug POV, it's not a big deal to redirect the reports for
> bpo packages to something different than sub...@b.d.o. What I need to
> know is:
>
> - the address where to send the bugs
> - a regular expression (bonus points i
Hi all,
On Mon, Sep 27, 2010 at 10:14, Stefano Zacchiroli wrote:
> On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
>> On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
>> > From what concerns the BTS, Don's proposal in [2] (the main one, not
>> > the alternative solution) seems reason
On Tue, Sep 28, 2010 at 01:29:46PM +0200, Lucas Nussbaum wrote:
> On 28/09/10 at 09:16 +0200, Stefano Zacchiroli wrote:
> > On Tue, Sep 28, 2010 at 12:37:55AM +0200, Lucas Nussbaum wrote:
> > > > OK, thanks for the clarification. Still, we need to decide—sort of
> > > > now—whether we need to add s
On 28/09/10 at 09:16 +0200, Stefano Zacchiroli wrote:
> On Tue, Sep 28, 2010 at 12:37:55AM +0200, Lucas Nussbaum wrote:
> > > OK, thanks for the clarification. Still, we need to decide—sort of
> > > now—whether we need to add support in reportbug for mailing backport
> > > report bugs to the bpo li
On Tue, Sep 28, 2010 at 12:37:55AM +0200, Lucas Nussbaum wrote:
> > OK, thanks for the clarification. Still, we need to decide—sort of
> > now—whether we need to add support in reportbug for mailing backport
> > report bugs to the bpo list or not (and that might require some time, as
> > someone ne
On 27/09/10 at 10:14 +0200, Stefano Zacchiroli wrote:
> On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
> > On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
> > > From what concerns the BTS, Don's proposal in [2] (the main one, not
> > > the alternative solution) seems reasonable to me
On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
> On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
> > From what concerns the BTS, Don's proposal in [2] (the main one, not
> > the alternative solution) seems reasonable to me and others in the
> > thread. The proposal also seems to assu
On Thu, 23 Sep 2010, Joerg Jaspert wrote:
> Stepping in sideways here, but in case you can make use of them,
> backports is creating the same debversion info like the main
> archive. Want them synced to the bts?
Yes, please.
Don Armstrong
--
Whatever you do will be insignificant, but it is ver
>> From what concerns the BTS, Don's proposal in [2] (the main one, not
>> the alternative solution) seems reasonable to me and others in the
>> thread. The proposal also seems to assume a different Maintainer
>> field for the bpo package, as hinted above, am I wrong Don?
> Right. The idea here is
On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
> From what concerns the BTS, Don's proposal in [2] (the main one, not
> the alternative solution) seems reasonable to me and others in the
> thread. The proposal also seems to assume a different Maintainer
> field for the bpo package, as hinted above,
On 22/09/10 13:53, Stefano Zacchiroli wrote:
> Thinking about it, what we _conceptually_ need is pretty simple: a
> mechanism to declare who is the Maintainer of the bpo package and
> enforce its declaration. The responsibility of bpo maintenance will be
> on the declared bpo maintainer. If the def
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("nor
On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> On Tue, 07 Sep 2010, Steve Langasek wrote:
> > But when someone takes my package and uploads it somewhere other
> > than the main Debian archive, they incur *all* the responsibilities
> > of maintaining that package, including the res
On Wed, Sep 8, 2010 at 3:52 AM, Russ Allbery wrote:
> If there's any complexity in the backport, that's probably true. But I'll
> note here that for all the backports I do for my packages, all the changes
> in the backport are mechanical (and automated) and maintaining that in a
> VCS is just mo
Gerfried Fuchs writes:
> To me the solution is to see the person who does the backport as a part
> of the packaging team. There is the need for having a communication
> channel between the people anyway. Actually more and more packages are
> moved into team maintenance and I'm pretty puzzled abo
Bernd Zeimetz writes:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
>> I don't think it is. I have no problem with people backporting any of
>> my packages that are useful to them, but I shouldn't have to read bug
>> mail for them. I have enough bugs of my own.
> Chances are good that htese
On Tue, 07 Sep 2010, Steve Langasek wrote:
> But when someone takes my package and uploads it somewhere other
> than the main Debian archive, they incur *all* the responsibilities
> of maintaining that package, including the responsibility of
> appropriately triaging bug reports and forwarding them
On 2010-09-07, Bernd Zeimetz wrote:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
>> On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
>>> That I dont think it is. I think you not wanting t be bothered by
>>> backports of your packages is quite an exception,
>>
>> I don't think it
On Tue, Sep 07, 2010 at 07:05:29PM +0200, Bernd Zeimetz wrote:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
> > On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
> >> That I dont think it is. I think you not wanting t be bothered by
> >> backports of your packages is quite an except
On Tue, Sep 07, 2010 at 08:35:05PM +0200, Gerfried Fuchs wrote:
> I really would like to see us trying to work together more effectively
> instead of objecting to things right ahead without even knowing wether
> it is such a big relevant deal to make a fuzz about. IMHO it isn't, far
> from it.
We
Lucas Nussbaum schrieb am Tuesday, den 07. September 2010:
Hi,
> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > > relevant to backported packages still have to be reported to the
> > >
Hi!
* Simon McVittie [2010-09-06 19:33:34 CEST]:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> > What are the BTS limitations ?
>
> I assume the relevant limitation is that in the BTS' data model, each source
> package has a single maintainer, whereas the maintainer of a
Hi,
On Tue, Sep 07, 2010 at 02:38:32PM +0200, Raphael Hertzog wrote:
> On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider the maintenance model of backports. I would
> > personally prefer if we had the same r
On 09/07/2010 05:57 PM, Steve Langasek wrote:
> On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
>> That I dont think it is. I think you not wanting t be bothered by
>> backports of your packages is quite an exception,
>
> I don't think it is. I have no problem with people backporti
On 09/06/2010 10:46 PM, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport main
On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
> That I dont think it is. I think you not wanting t be bothered by
> backports of your packages is quite an exception,
I don't think it is. I have no problem with people backporting any of my
packages that are useful to them, but I s
On Tue, 07 Sep 2010, Sune Vuorela wrote:
> I'm not planning to ever provide backports of any of my packages, and
> while others are welcome to do it, I do not in any way want to be
> bothered by their bugs or upload emails or anything.
Which would call for filtering, not for keeping the bad status
Hi,
On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport ma
Hi,
On Dienstag, 7. September 2010, Sune Vuorela wrote:
> On 2010-09-07, Lucas Nussbaum wrote:
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider the maintenance model of backports. I would
> > personally prefer if we had the same rules of packages o
On 2010-09-07, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer =
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("nor
On Tue, Sep 7, 2010 at 1:46 PM, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider
Some other possibilities;
Move *-backports (and *-volatile) into the main archive like they are in Ubuntu.
Merge the backports website into www.de
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> On 06/09/10 at 20:32 +0300, Andrei Popescu wrote:
> > On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > > Because of limitations in the Debian Bug Tra
On 06/09/10 at 20:32 +0300, Andrei Popescu wrote:
> On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > relevant to backported packages still have
On 09/06/2010 07:33 PM, Simon McVittie wrote:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
>> Alexander Reichle-Schmehl writes ("Backports service becoming official"):
>>> Because of limitations in the Debian Bug Tracking System, any bugs
>>> relevant to backported packages still hav
On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > Because of limitations in the Debian Bug Tracking System, any bugs
> > relevant to backported packages still have to be reported to the
> > debian-backports [3]
On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > Because of limitations in the Debian Bug Tracking System, any bugs
> > relevant to backported packages still have to be reported to the
> > debian-backports [3] list, which
Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> Because of limitations in the Debian Bug Tracking System, any bugs
> relevant to backported packages still have to be reported to the
> debian-backports [3] list, which have now also been moved to
> lists.debian.org [4].
W
Hi,
On Mon, Sep 03, 2007 at 02:14:47PM +0100, Luis Matos wrote:
> this is meant for users to use not-in-backports situation, like testing
> newer software.
As Romain suggested already, a chroot is much better suited for that kind of
testing.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ Gnu
Seg, 2007-09-03 às 09:05 -0400, Roberto C. Sánchez escreveu:
> On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
> >
> > how about the development of tool on we could:
> >
> > - add the sid repos to sources.list
> > - with a simple command download every needed source package
> > (de
Seg, 2007-09-03 às 14:46 +0200, Sebastian Harl escreveu:
> Hi Luis,
>
> On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
> > how about the development of tool on we could:
> >
> > - add the sid repos to sources.list
>
> This should be done manually, it only has to be done once anywa
On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
>
> how about the development of tool on we could:
>
> - add the sid repos to sources.list
> - with a simple command download every needed source package
> (dependencies)
> - build the packages
> - install all the packages.
>
A fe
Hi Luis,
On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote:
> how about the development of tool on we could:
>
> - add the sid repos to sources.list
This should be done manually, it only has to be done once anyway.
> - with a simple command download every needed source package
> (de
Le Monday 03 September 2007 14:09:14 Luis Matos, vous avez écrit :
> is this doable?
Honnestly, it seems difficult and dangerous to automate that way.
when you backport a package there are plenty of reasons you should take care
of dependencies, in particular when there's a major upgrade at some
Hi,
On Sun Sep 02, 2007 at 17:46:56 -0400, Tim Hull wrote:
> Does this mean anything with regards to how backports will operate? I'm
> just curious, as you probably know from my past posts that I'm quite
> interested in stable release updates beyond simple security updates...
As member of the S
1 - 100 of 120 matches
Mail list logo
