Re: Bits from the Release Team: trixie freeze started

Hi Paul, I used the release notes to upgrade a bookworm system to a trixie system. I like the new layout of the release notes, thanks for the layout upgrade :-) Overall it went very well, for the only real issue I run into, I filed a bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?b

Re: Bits from the Release Team: trixie freeze started

On Sun, Apr 13, 2025 at 10:45:56PM +0200, Rainer Dorsch wrote: > I am not a Debian developer, therefore I cannot create a pull request for > fixes > in the release notes myself, You absolutely can. One does *not* need to be a Debian Developer to send patches to the Debian BTS, or to create merg

Re: Bits from the Release Team: trixie freeze started

Hallo Paul, De unsubsribe werkt niet goed. Ik krijg elke keer nog mailtjes. Hoe kan ik mij hier uitschrijven? Groet Joop Op za 29 mrt 2025 om 09:13 schreef Paul Gevers : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi all, > > === trixie Transition and Toolchain freeze === > > We're

Re: Bits from the Release Team: trixie freeze started

Am 31. März 2025 11:55:53 MESZ schrieb Joop! <724j...@gmail.com>: >Hallo Paul, > >De unsubsribe werkt niet goed. Ik krijg elke keer nog mailtjes. Hoe kan ik >mij hier uitschrijven? > >Groet > >Joop > >Op za 29 mrt 2025 om 09:13 schreef Paul Gever

Re: Bits from the Release Team: trixie freeze dates

On 28/01/2025 12:37, Frank Guthausen wrote: On Tue, 28 Jan 2025 09:34:37 +0100 Emilio Pozuelo Monfort wrote: On 27/01/2025 23:15, Andrea Bolognani wrote: https://release.debian.org/trixie/freeze_policy.html Updated Almost - there are still the first three TBAs in the 2nd table row.

Re: Bits from the Release Team: trixie freeze dates

On Tue, 28 Jan 2025 09:34:37 +0100 Emilio Pozuelo Monfort wrote: > On 27/01/2025 23:15, Andrea Bolognani wrote: > > > >https://release.debian.org/trixie/freeze_policy.html > > Updated Almost - there are still the first three TBAs in the 2nd table row. -- kind regards Frank pgpFVLmM08Tzp.

Re: Bits from the Release Team: trixie freeze dates

On 27/01/2025 23:15, Andrea Bolognani wrote: On Wed, Jan 22, 2025 at 11:00:00PM +0100, Emilio Pozuelo Monfort wrote: Trying to follow our release cadence, we are going to start freezing trixie in March. As usual, it is our intention to have a short freeze, though with the short notice that may b

Re: Bits from the Release Team: trixie freeze dates

On Wed, Jan 22, 2025 at 11:00:00PM +0100, Emilio Pozuelo Monfort wrote: > Trying to follow our release cadence, we are going to start freezing > trixie in March. As usual, it is our intention to have a short freeze, > though with the short notice that may be hard. We apologize for not > coordinatin

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 he was talking about "Rele

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 De

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

El 17/12/23 a las 22:40, Steven Robbins escribió: 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

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 > mult

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 D

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 (as

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 for

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 th

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 on

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 a

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 maj

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 plea

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 autopkg

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 to

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 to

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 l

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 Full

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 als

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 individ

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 i

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. >> T

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 sho

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 c

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: 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 pac

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, Jon

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 r

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.) Fo

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 st

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 F

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 reques

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. >> Fr

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 th

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? https://udd.debian.or

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 easie

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

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 fr

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 team.

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 over numbers, even if it's just for >> > aesthetic re

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 /etc/debian_version) for comparisons.

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 spea

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 debian_vers

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 more comfortable than "debian10". >

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 s

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 should

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 have said "yes, including C." -- Russ A

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 accents: do you know wha

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 does

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, e

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" | LC_COLLATE

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 lowercase

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 -e

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 treated

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 orde

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 dictionary. Other symbols like Æ

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 ord

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 spot while ordering,

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 further diacriticals)

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 loca

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

On Mi, Apr 18, 2018 at 11:14:50 -0400, Michael Stone wrote: specifically, what locale sorts english words differently than LANG=C? Since English words (or texts) can have 8bit characters you may get a different sorting in in different locales. If you mean ASCII words I don’t know of any sort

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

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 locale... :) Can you please give an example for the sorting difference in

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

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 order", not everybody order letters the same way. really? there's more than one al

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

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 order", not everybody order letters the same way. > really? there's more than one alphabetical order for english words? yes, sorting depends on

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

On Wed, Apr 18, 2018 at 04:15:59PM +0200, Aurelien Jarno wrote: Please define "sorted order", not everybody order letters the same way. really? there's more than one alphabetical order for english words? Mike Stone

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

On 2018-04-17 22:34, Christoph Biedl wrote: > Also, choosing the names in sorted order (modulo wraparound) would > create a list in historic order of the releases, easing some assessment > when talking about releases. That's what Ubuntu does, although using Please define "sorted order", not everyb

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

Hi, When all people can complain about are the codenames, it means we are doing things fairly well :) On 18/04/18 08:20, Lars Wirzenius wrote: > On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote: >> No, users and, I suspect, a large part of admins and developers cannot >> easily say whi

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

On Wed, Apr 18, 2018 at 09:20:11AM +0300, Lars Wirzenius wrote: > > No, users and, I suspect, a large part of admins and developers cannot > > easily say which of two codenames is newer, and it doesn't matter what are > > those two codenames. Numeric versions are usually used to help with this, > >

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

On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote: > No, users and, I suspect, a large part of admins and developers cannot > easily say which of two codenames is newer, and it doesn't matter what are > those two codenames. Numeric versions are usually used to help with this, > but not so

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

On Tue, Apr 17, 2018 at 10:34:22PM +0200, Christoph Biedl wrote: > There are people who don't follow every single action in Debian, plain > stables users for example. For them it's helpful to tell the releases > apart easily as they might not have the precise names and their order in > mind. The fi

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

On 17.04.2018 22:34, Christoph Biedl wrote: > Also, choosing the names in sorted order (modulo wraparound) would > create a list in historic order of the releases, easing some assessment > when talking about releases. That's what Ubuntu does, although using > consecutive letters is nice but not nec

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

Emilio Pozuelo Monfort wrote... > We are about halfway through the buster development cycle, and a release > update was overdue. Thanks for all the updates, let's make this an exiting ride. But briefly bleating by boldly bringing balking bits ... > Future codenames > So we'll

Re: Bits from the Release Team: Architecture health check

On Thu, 30 Jan 2014, Thijs Kinkhorst wrote: > On Thu, January 30, 2014 08:20, Peter Palfrader wrote: > > On sparc, it's dies under load -- at least on smetana and spontini. Not > > on sompek and stadler though. schroeder and lebrun are also running > > squeeze kernels. > > At work we've seen r

Re: Bits from the Release Team: Architecture health check

On Thu, January 30, 2014 08:20, Peter Palfrader wrote: > On sparc, it's dies under load -- at least on smetana and spontini. Not > on sompek and stadler though. schroeder and lebrun are also running > squeeze kernels. At work we've seen regular kernel panics when we upgraded two sparc machines

  1   2   3   4   5   6   7   8   >