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"
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
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
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
> =
rs 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
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
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
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
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
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
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
Sorry, the follow-up mails loaded only after I wrote my response.
Regards
Stephan
Did you mean 2023?
Regards
Stephan
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
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
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
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
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
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
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
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
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
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
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
-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 agai
-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
-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
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
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
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
>
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
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
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
> >
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
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")
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
>
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
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
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
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`.
* 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`.
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`. I
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
`dpkg-
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
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.
>
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
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 --
> f
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 dput.
在 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 of
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.
* 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
> >
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'
> P
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 by
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
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
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
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,
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
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
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
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
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
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
> 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
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
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 th
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 for
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*!
> >
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
>> ===
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
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
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
在 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
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
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 rel
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
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.
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
* 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.
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
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
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".
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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 Æ
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
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,
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)
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
1 - 100 of 840 matches
Mail list logo
