Re: Bits from the Release Team: Cambridge sprint update

Hi On 18-12-2023 11:29, Santiago Vila wrote: El 17/12/23 a las 22:40, Steven Robbins escribió: Does that mean ceasing the "ITP" messages in debian-devel? I'd certainly welcome that! I think he really meant debian-release, as this was "Bits from the Release Team" and

Re: Bits from the Release Team: Cambridge sprint update

Hi, On 18-12-2023 13:18, Antonio Terceiro wrote: Will reproducibility regressions block migration to testing? Not for the near future for 2 reasons: 1) contrary to autopkgtest where removal of the test "fixes" regression, it feels that currently blocking on regression would give maintainers

Re: Bits from the Release Team: Cambridge sprint update

On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote: > Reproducibility migration policy > > > The folks from the Reproducibility Project have come a long way since they > started working on it 10 years ago, and we believe it's time for the next step > in

Re: Bits from the Release Team: Cambridge sprint update

On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote: > During the wonderful mini-DebConf at Cambridge, the Release Team had a sprint > and other discussions. Some of the discussed topics are worth sharing, so here > we go. [...] > Reproducibility migration policy >

Re: Bits from the Release Team: Cambridge sprint update

to direct the traffic away Does that mean ceasing the "ITP" messages in debian-devel? I'd certainly welcome that! I think he really meant debian-release, as this was "Bits from the Release Team" and he was talking about "Release Team bugs", but yes, we have the same p

Re: Bits from the Release Team: Cambridge sprint update

On Saturday, December 16, 2023 12:23:46 P.M. CST Paul Gevers wrote: > Another topic we covered is the volume and purpose of our mail list > (debian-devel@lists.debian.org). We recognize that that list mostly just > mirrors BTS traffic. The BTS already archives all information, and there are >

Re: bits from the release team: are you ready to skate yet?

Hi, On 13-10-2022 17:32, Johannes Schauer Marin Rodrigues wrote: hrm... maybe I misunderstand but I thought your initial mail talked about build profiles (aka DEB_BUILD_PROFILES) and not build options (aka DEB_BUILD_OPTIONS). The policy section you cite is about DEB_BUILD_OPTIONS and not about

Re: bits from the release team: are you ready to skate yet?

Hi Paul, Quoting Paul Gevers (2022-10-13 17:25:36) > On 13-10-2022 14:20, Johannes Schauer Marin Rodrigues wrote: > > Quoting Paul Gevers (2022-10-13 10:00:42) > >> Please also consider supporting the nodoc build profile. We are aware > >> that nodoc is regularly used in a non-reproducible way

Re: bits from the release team: are you ready to skate yet?

Hi josch, On 13-10-2022 14:20, Johannes Schauer Marin Rodrigues wrote: Quoting Paul Gevers (2022-10-13 10:00:42) Please also consider supporting the nodoc build profile. We are aware that nodoc is regularly used in a non-reproducible way (as intended, but with this consequence), so checking

Re: bits from the release team: are you ready to skate yet?

Quoting Paul Gevers (2022-10-13 10:00:42) > Please also consider supporting the nodoc build profile. We are aware > that nodoc is regularly used in a non-reproducible way (as intended, > but with this consequence), so checking for correctness of this > profile may be a bit harder. Ideally, using

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Leandro Cunha wrote on 15/03/2022 at 23:18:37+0100: > Hi, > > On Tue, Mar 15, 2022 at 7:05 PM Pierre-Elliott Bécue wrote: >> >> >> Leandro Cunha wrote on 15/03/2022 at >> 22:57:39+0100: >> >> > On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue >> > wrote: >> > >> > Paul Gevers wrote

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Sorry, the follow-up mails loaded only after I wrote my response. Regards Stephan

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Did you mean 2023? Regards Stephan

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Hi, On Tue, Mar 15, 2022 at 7:05 PM Pierre-Elliott Bécue wrote: > > > Leandro Cunha wrote on 15/03/2022 at > 22:57:39+0100: > > > On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue > > wrote: > > > > Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: > > > > > Dear all, > > > > > > We

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Leandro Cunha wrote on 15/03/2022 at 22:57:39+0100: > On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue wrote: > > Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: > > > Dear all, > > > > We are currently considering the following dates as our freeze > > dates. If you are aware of

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue wrote: > > Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: > > > Dear all, > > > > We are currently considering the following dates as our freeze > > dates. If you are aware of major clashes of these dates with anything > > we depend on

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: > Dear all, > > We are currently considering the following dates as our freeze > dates. If you are aware of major clashes of these dates with anything > we depend on please let us know. We also like to stress again that we > really would like to

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Am Montag, 14. März 2022, 21:36:11 CET schrieb Paul Gevers: > 2022-01-12 - Milestone 1 - Transition and toolchain freeze > 2022-02-12 - Milestone 2 - Soft Freeze > 2022-03-12 - Milestone 3 - Hard Freeze - for key packages and > packages without

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Hi Paul, On Mo 14 Mär 2022 21:36:11 CET, Paul Gevers wrote: Dear all, We are currently considering the following dates as our freeze dates. If you are aware of major clashes of these dates with anything we depend on please let us know. We also like to stress again that we really would like

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

On Mon, Mar 14, 2022 at 09:43:15PM +0100, Jérémy Lal wrote: > > We are currently considering the following dates as our freeze > > dates. If you are aware of major clashes of these dates with anything > > we depend on please let us know. We also like to stress again that we > > really would like

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Hi, On Mon, Mar 14, 2022 at 6:23 PM Jameson Graef Rollins wrote: > > On Mon, Mar 14 2022, Paul Gevers wrote: > > We are currently considering the following dates as our freeze > > dates. If you are aware of major clashes of these dates with anything > > we depend on please let us know. We also

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

On Mon, Mar 14 2022, Paul Gevers wrote: > We are currently considering the following dates as our freeze > dates. If you are aware of major clashes of these dates with anything > we depend on please let us know. We also like to stress again that we > really would like to have a short Hard and

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

Hi Paul, These dates are in the past, was it intended for the dates to be in Janruay, February, and March of 2023 instead of 2022? Jesse On 2022-03-14 5:36 p.m., Paul Gevers wrote: > Dear all, > > We are currently considering the following dates as our freeze > dates. If you are aware of major

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

On Mon, Mar 14, 2022 at 9:36 PM Paul Gevers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Dear all, > > We are currently considering the following dates as our freeze > dates. If you are aware of major clashes of these dates with anything > we depend on please let us know. We

Bits from the Release Team: bookworm freeze dates (preliminary)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [Message resent because the year was wrong] Dear all, We are currently considering the following dates as our freeze dates. If you are aware of major clashes of these dates with anything we depend on please let us know. We also like to stress

Re: Bits from the Release Team: say hello to our studious bookworm

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2021-08-15 at 00:02 +0100, Jonathan Wiltshire wrote: > Hi, > > On 14th August 2021 we released Debian 11 "bullseye". > > There are too many people who should be thanked for their work on > getting > us to this point to list them all

Re: bits from the release team: bullseye freeze started and its architectures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, On 13-01-2021 21:18, Paul Gevers wrote: > [2] https://release.debian.org/buster/freeze_policy.html ^^ should of course have been bullseye: https://release.debian.org/bullseye/freeze_policy.html Paul

Re: Bits from the Release Team: ride like the wind, Bullseye!

On 2019, സെപ്റ്റംബർ 2 1:26:51 AM IST, Paul Gevers wrote: >Hi Pirate, and other interested parties, > >On 09-08-2019 08:22, Pirate Praveen wrote: >> On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers >wrote: >>> I can already trigger all the autopkgtests in unstable for packages >>> that >>> are

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi Pirate, and other interested parties, On 09-08-2019 08:22, Pirate Praveen wrote: > On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers wrote: >> I can already trigger all the autopkgtests in unstable for packages >> that >> are in experimental, so if you interested in this, please contact me. >>

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi, On 18-08-2019 04:46, Lisandro Damián Nicanor Pérez Meyer wrote: >> I can already trigger all the autopkgtests in unstable for packages that >> are in experimental, so if you interested in this, please contact me. > > **Yes please**. This will certainly help *a lot* specially for us that we >

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Sun, Aug 18, 2019 at 08:54:21AM +0100, Ian Jackson wrote: > > On 19/08/08 09:46, Paul Gevers wrote: > > > I think we should also try to improve the visibility towards reverse > > > dependencies that their autopkgtest is blocking other packages. I would > > > love tracker (and the old pts) to

Re: Bits from the Release Team: ride like the wind, Bullseye!

Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"): > My personal point of view (and because of this it might be biased) > is that the maintainers of the packages that ship autopkgtest should > be the reponsibles for any

Re: Bits from the Release Team: ride like the wind, Bullseye!

First of all sorry for the late late reply, I was hoping to find time to reply to this sooner :-/ On 19/08/08 09:46, Paul Gevers wrote: > Hi, > > On 07-08-2019 16:57, Ian Jackson wrote: > > Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release > >

Re: Bits from the Release Team: ride like the wind, Bullseye!

On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers wrote: >I can already trigger all the autopkgtests in unstable for packages >that >are in experimental, so if you interested in this, please contact me. >This would enable library maintainers to at least have an overview of >what would happen. I

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi, On 07-08-2019 16:57, Ian Jackson wrote: > Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: > ride like the wind, Bullseye!"): >> No, what I have been perceiving (and pretty please note that this is my >> personal "feeling")

Re: Bits from the Release Team: ride like the wind, Bullseye!

Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"): > No, what I have been perceiving (and pretty please note that this is my > personal "feeling") is that maintainers, specially library maintainers, have &

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi Paul! El sáb., 20 jul. 2019 16:42, Paul Gevers escribió: > Hi Lisandro, > > On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote: > >> All autopkgtest failures considered RC for bullseye > >> === > >> > >> From now on, all autopkgtest

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

On Tue, 23 Jul 2019 at 18:22:58 +0200, Johannes Schauer wrote: > Quoting Sean Whitton (2019-07-23 17:47:45) > > ICBW but I am pretty sure that sbuild builds the source package *outside* of > > the clean chroot. > > that is correct. Indeed the source package is the way how the sources are > copied

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Shengjing Zhu writes ("Re: Sorce only uploads with sbuild (was: Bits >from the Release Team)"): >> On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton > wrote: >> > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, >or >> > (easier

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Shengjing Zhu writes ("Re: Sorce only uploads with sbuild (was: Bits from the Release Team)"): > On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton > wrote: > > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or > > (easier) `dgit push-source`.

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

* W. Martin Borgert: " Re: Sorce only uploads with sbuild (was: Bits from the Release Team)" (Tue, 23 Jul 2019 17:30:22 +0200): > Quoting Sean Whitton : > > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or > > (easier) `dgit push-source`.

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

On Wed, Jul 24, 2019 at 12:46 AM Shengjing Zhu wrote: > > On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton > wrote: > > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or > > (easier) `dgit push-source`. > > > > Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`.

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton wrote: > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or > (easier) `dgit push-source`. > Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If sbuild doesn't include orig tarball in -2 source.changes, then

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

On Tue, Jul 23, 2019 at 08:18:05AM -0700, Sean Whitton wrote: > Hello, > > On Tue 23 Jul 2019 at 03:53pm +02, Mathias Behrle wrote: > > > Thanks a lot, could have found myself...:( > > TBH I didn't assume that such a bug could exist when we make source-only > > uploads manadatory. > > I find it

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Hello, On Tue 23 Jul 2019 at 06:22PM +02, Johannes Schauer wrote: > that is correct. Indeed the source package is the way how the sources are > copied into the chroot so sbuild cannot operate at all without having a source > package first. And that source package is built *outside* the chroot. >

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Hi, Quoting Sean Whitton (2019-07-23 17:47:45) > > I prefer to build only once, if possible, generating both binary and source > > .changes. Both in a clean chroot. Then I can try out my .debs and on > > success just sign and dput. Works fine for me with pbuilder. > ICBW but I am pretty sure that

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Hello, On Tue 23 Jul 2019 at 11:23AM -04, Boyuan Yang wrote: > To be honest, I *hate* building without clean chroot environment, no matter > it's a source-only upload, a -2 upload or anything else. Think of this: when > invoking sbuild, some command line options like "--source-only-changes -- >

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Quoting Sean Whitton : Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or (easier) `dgit push-source`. I prefer to build only once, if possible, generating both binary and source .changes. Both in a clean chroot. Then I can try out my .debs and on success just sign and

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

在 2019-07-23二的 08:18 -0700，Sean Whitton写道： > Hello, > > On Tue 23 Jul 2019 at 03:53pm +02, Mathias Behrle wrote: > > > Thanks a lot, could have found myself...:( > > TBH I didn't assume that such a bug could exist when we make source-only > > uploads manadatory. > > I find it helpful to think

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

Hello, On Tue 23 Jul 2019 at 03:53pm +02, Mathias Behrle wrote: > Thanks a lot, could have found myself...:( > TBH I didn't assume that such a bug could exist when we make source-only > uploads manadatory. I find it helpful to think of sbuild as a tool for producing binaries, and nothing else.

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

* Andrey Rahmatullin: " Re: Sorce only uploads with sbuild (was: Bits from the Release Team)" (Tue, 23 Jul 2019 15:46:08 +0500): > On Tue, Jul 23, 2019 at 12:22:02PM +0200, Mathias Behrle wrote: > > I tried that building as usual with sbuild with additional option > &

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

On Tue, Jul 23, 2019 at 12:22:02PM +0200, Mathias Behrle wrote: > I tried that building as usual with sbuild with additional option > --source-only-changes and uploaded, but now get REJECTS with e.g. > > tryton-server_5.0.6-2.dsc: Refers to non-existing file > 'tryton-server_5.0.6.orig.tar.gz' >

Sorce only uploads with sbuild (was: Bits from the Release Team)

Hi all, in Bits from the Release Team I am told > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi Lisandro, On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote: >> All autopkgtest failures considered RC for bullseye >> === >> >> From now on, all autopkgtest failures will be considered release-critical for >> bullseye. So if your

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Fri, 12 Jul 2019 at 08:17, Adam Borowski wrote: > On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote: > > You indeed missed someone (for obvious reasons): I'd like to thank > > the release team for their excellent work! > > +1 > +lots > > On Sun, 07 Jul 2019 02:47:00 +0100,

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote: > You indeed missed someone (for obvious reasons): I'd like to thank > the release team for their excellent work! +1 > On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote: > > The release of buster also means the bullseye

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote: > There are too many people who should be thanked for their work on getting us > to > this point to list them all individually, and we would be sure to miss some. > Nevertheless, we would like to particularly thank the installer team,

Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Hello, On Tue 09 Jul 2019 at 08:45AM -04, Roberto C. Sánchez wrote: > Why is it, then, that binary-NEW still applies if there have been no > source files added/removed? (A SONAME bump possibly being necessitated > by some change that does not involve adding/removing/renaming source > files.)

Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

On Tue, Jul 09, 2019 at 01:33:49PM +0100, Sean Whitton wrote: > Hello, > > On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote: > > > I would go even further and drop the (manual) NEW queue for binary-NEW > > packages. > > Is there a good reason why new binary packages need manual processing

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hello, On Tue 09 Jul 2019 at 12:16AM +02, Marco d'Itri wrote: > On Jul 07, Jonathan Wiltshire wrote: > >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? >> A: Yes (preferably with other changes, not just a version bump). > Is there any good reason why we

Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Hello, On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote: > I would go even further and drop the (manual) NEW queue for binary-NEW > packages. > Is there a good reason why new binary packages need manual processing by > the FTP team? Couldn't this be fully automated? The three things the

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Tue, Jul 09, 2019 at 12:16:53AM +0200, Marco d'Itri wrote: > On Jul 07, Jonathan Wiltshire wrote: > > > Q: I already did a binary upload, do I need to do a new (source-only) > > upload? > > A: Yes (preferably with other changes, not just a version bump). > Is there any good reason why we

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Jul 07, Jonathan Wiltshire wrote: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). Is there any good reason why we still do not have an interface to allow developers to self-service

Re: Bits from the Release Team: ride like the wind, Bullseye!

> No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need

NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]

Am 07.07.19 um 15:43 schrieb Ben Hutchings: > On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: > [...] >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is about to >> begin. >>

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

Am Mo., 8. Juli 2019 um 09:14 Uhr schrieb Thomas Goirand : > > On 7/8/19 12:34 AM, Scott Kitterman wrote: > > As long as your build-depends are properly versioned, why can't you just > > upload all the source and let wanna-build sort it out? > > > > Scott K > > This means that I have to baby-sit

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

On 7/8/19 12:34 AM, Scott Kitterman wrote: > As long as your build-depends are properly versioned, why can't you just > upload all the source and let wanna-build sort it out? > > Scott K This means that I have to baby-sit the Debian archive and upload everything in the correct order, waiting

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

On Sunday, July 7, 2019 6:30:58 PM EDT Thomas Goirand wrote: > On 7/7/19 3:16 PM, Holger Levsen wrote: > > Hi, > > > > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: > >> Shortly before the end of the 6th July, we released Debian 10, "buster". > > > > *yay* *yay* & *yay*! >

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

On 7/7/19 3:16 PM, Holger Levsen wrote: > Hi, > > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: >> Shortly before the end of the 6th July, we released Debian 10, "buster". > > *yay* *yay* & *yay*! > >> No binary maintainer uploads for bullseye >>

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi! [snip with a huge yay!] > All autopkgtest failures considered RC for bullseye > === > > From now on, all autopkgtest failures will be considered release-critical for > bullseye. So if your package has failing autopkgtests, now is a good time to

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi, On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: > Shortly before the end of the 6th July, we released Debian 10, "buster". *yay* *yay* & *yay*! > No binary maintainer uploads for bullseye > = > > The release of buster also means

Re: Bits from the Release Team: buster freeze update

On Wed, Apr 17, 2019 at 08:44:20AM +1000, Hugh McMaster wrote: > > At the time of writing 150 release-critical bugs affect buster. This is the > > number which needs to reach zero before the release can take place. > > > What’s the easiest way to get a list of these RC bugs?

Re: Bits from the Release Team: buster freeze update

在 2019-04-17三的 08:44 +1000，Hugh McMaster写道： > Hi Jonathan, > > On Mon, 15 Apr 2019 at 7:38 am, Jonathan Wiltshire wrote: > > At the time of writing 150 release-critical bugs affect buster. > > This is the > > number which needs to reach zero before the release can take place. > > What’s the

Re: Bits from the Release Team: buster freeze update

Hi Jonathan, On Mon, 15 Apr 2019 at 7:38 am, Jonathan Wiltshire wrote: > At the time of writing 150 release-critical bugs affect buster. This is the > number which needs to reach zero before the release can take place. What’s the easiest way to get a list of these RC bugs? Hugh

Bits from the Release Team: buster freeze update

Hi, In this issue: - Architectures - RC bugs status - Upgrade testing - Release notes - Responding to unblock requests Architectures = Debian buster will ship with the same set of architectures as Debian stretch did. RC bugs status == At the time of writing 150

Re: Bits from the Release Team: Debian 10 'buster' is frozen; let's get it in shape

It’s minutes ago - 10 days for migration. Ondrej -- Ondřej Surý > On 12 Mar 2019, at 22:55, Milan Kupcevic wrote: > >> On 3/12/19 3:53 PM, Paul Gevers wrote: >> >> Just like we announced in our freeze policy [1], the full freeze of >> buster started today, some minutes ago. This means that

Re: Bits from the Release Team: Debian 10 'buster' is frozen; let's get it in shape

On 3/12/19 3:53 PM, Paul Gevers wrote: > Just like we announced in our freeze policy [1], the full freeze of > buster started today, some minutes ago. This means that from now on > (well, practically already 10 days ago) all migrations to testing will > require manual approval by the release

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

On 20 April 2018 at 15:46, Marvin Renich wrote: > Package: base-files > Version: 10.1 > Severity: wishlist > > * Stephan Seitz [180420 07:38]: >> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote: >> > But being human I prefer names

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

* Emilio Pozuelo Monfort [180420 11:00]: > On 20/04/18 16:46, Marvin Renich wrote: > > I would also like /etc/debian_version to contain both number and name, > > but I suspect there is some resistance to this on the grounds that > > scripts may be using $(cat

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

Marvin, > I have often wanted to have on my system a text file containing the > correspondence between code name and release number. This appears to be already in the archive in a number of places. For example, in `debdate`, `debian-handbook` or even in the `debian- timeline` package if you

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

On 20/04/18 16:46, Marvin Renich wrote: > I would also like /etc/debian_version to contain both number and name, > but I suspect there is some resistance to this on the grounds that > scripts may be using $(cat /etc/debian_version) for comparisons. > Perhaps /etc/debian_codename? Since

Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

Package: base-files Version: 10.1 Severity: wishlist * Stephan Seitz [180420 07:38]: > On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote: > > But being human I prefer names over numbers, even if it's just for > > aesthetic reason - "buster" is just

Re: Bits from the release team: full steam ahead towards buster

On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote: But being human I prefer names over numbers, even if it's just for aesthetic reason - "buster" is just more comfortable than "debian10". No, it’s not. I know that my systems are running Debian 8 or 9, but I always have to think if

Re: Bits from the release team: full steam ahead towards buster

On 2018-04-19 23:00, Christoph Biedl wrote: Philipp Kern wrote... Turns out that this is a terrible idea. Because? People will start to rely on names for sorting again. Regardless if it's the right thing technically people are people and will use what tools they have available. We

Re: Bits from the release team: full steam ahead towards buster

Russ Allbery writes: > Adam Borowski writes: >> Thus, there are locales where a purely ASCII word sorts differently >> when capitalized and when not. > Yes, including en_US. Just to head off the noise of the corrections for this error, this last should

Re: Bits from the release team: full steam ahead towards buster

Adam Borowski writes: > On Wed, Apr 18, 2018 at 10:19:46AM -0700, Russ Allbery wrote: >> That said, nearly all US English writers will just omit the accents >> anyway. At least US English (I can't speak for UK) really aggressively >> drops accent marks. > About dropping

Collation discrepencies between locales [was: Re: Bits from the release team: full steam ahead towards buster]

On 19/04/2018 22:45, Holger Levsen wrote: > I now wondered if it's not only en_GB.utf8 which is "different", but also > the NZ and US variants sort like that (and so differently than C)... not > sure if en_FR.utf8 exist, but using it, it sorts differently / like C ;) > > (probably because it

Re: Bits from the release team: full steam ahead towards buster

Philipp Kern wrote... > Turns out that this is a terrible idea. Because? > We should use numeric values for > sorting. (And Ubuntu now does the same thing on the technical side.) From a technical point of view there is no need for codenames at all. But being human I prefer names over numbers,

Re: Bits from the release team: full steam ahead towards buster

On Thu, Apr 19, 2018 at 09:35:25AM +1200, Ben Caradoc-Davies wrote: > In the C locale, all uppercase letters are sorted before all lowercase > letters: > > $ echo -e "buster\nStretch" | LC_COLLATE=C sort > Stretch > buster > > In en_GB, by comparison: > > $ echo -e "buster\nStretch" |

Re: Bits from the release team: full steam ahead towards buster

On Wed, Apr 18, 2018 at 10:19:46AM -0700, Russ Allbery wrote: > That said, nearly all US English writers will just omit the accents > anyway. At least US English (I can't speak for UK) really aggressively > drops accent marks. About dropping accents: do you know what can upcase('i') and

Re: Bits from the release team: full steam ahead towards buster

On Mi, Apr 18, 2018 at 08:52:25 +0300, Adrian Bunk wrote: On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote: specifically, what locale sorts english words differently than LANG=C? Estonian (et_EE) sorts z between s and t. Boah, thanks for all the examples. I didn’t know you could

Re: Bits from the release team: full steam ahead towards buster

On 19/04/18 03:11, Stephan Seitz wrote: Can you please give an example for the sorting difference in different locales if you only have english words (and I would say it means only ASCII in this case)? In the C locale, all uppercase letters are sorted before all lowercase letters: $ echo

Re: Bits from the release team: full steam ahead towards buster

Hi Gunnar, > > Can you please give an example for the sorting difference in different > > locales if you only have english words (and I would say it means only ASCII > > in this case)? […] > But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary > school, "ch" and "ll" were

Re: Bits from the release team: full steam ahead towards buster

On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote: > On Wed, Apr 18, 2018 at 02:47:11PM +, Holger Levsen wrote: > > > >yes, sorting depends on the locale... :) > > specifically, what locale sorts english words differently than LANG=C? Czech (cs_CZ) for one. % cat animals cheetah

Re: Bits from the release team: full steam ahead towards buster

On Wed, Apr 18, 2018 at 11:14:50AM -0400, Michael Stone wrote: > On Wed, Apr 18, 2018 at 02:47:11PM +, Holger Levsen wrote: > > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote: > > > On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote: > > > > Please define "sorted

Re: Bits from the release team: full steam ahead towards buster

Matthew Crews writes: > As far as diacritics go, American English is practically devoid of > them. Where they are present, native (American) English speakers > basically ignore them, so the words résumé (n) and resume (v) share the > same spot in any given English

Re: Bits from the release team: full steam ahead towards buster

On Wed, Apr 18, 2018 at 11:19:05AM -0500, Gunnar Wolf wrote: Stephan Seitz dijo [Wed, Apr 18, 2018 at 05:11:47PM +0200]: On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote: > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote: > > really? there's more than one alphabetical

Re: Bits from the release team: full steam ahead towards buster

Matthew Crews dijo [Wed, Apr 18, 2018 at 01:10:06PM -0400]: > On April 18, 2018 9:19 AM, Gunnar Wolf wrote: > > But why would ü not be part of the sorting? Yes, that was my example > > before you censored my thought process - In Spanish, [áéíóú] and > > [aeiou] share the same

Re: Bits from the release team: full steam ahead towards buster

On April 18, 2018 9:19 AM, Gunnar Wolf wrote: > But why would ü not be part of the sorting? Yes, that was my example > before you censored my thought process - In Spanish, [áéíóú] and > [aeiou] share the same spot while ordering, as do ñ and n, as do u and > ü (and we have no

Re: Bits from the release team: full steam ahead towards buster

Stephan Seitz dijo [Wed, Apr 18, 2018 at 05:11:47PM +0200]: > On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote: > > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote: > > > really? there's more than one alphabetical order for english words? > > yes, sorting depends on the

  1   2   3   4   5   6   7   8   9   >