Re: Bits from the Release Team: Cambridge sprint update

[Paul Gevers]

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 "Release Team bugs",


Yes, I was talking about d-release. Somehow this mistake slipped in and 
wasn't caught during the review.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bits from the Release Team: Cambridge sprint update

[Paul Gevers]

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 
the wrong incentive to *not* make their packages reproducible, as there 
would be no way back.
2) there are still infrastructure hiccups that would hit maintainers of 
reproducible packages unequally hard, while we'd want the opposite if 
we'd have a choice.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bits from the Release Team: Cambridge sprint update

[Antonio Terceiro]

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 Debian. Several weeks ago, we enabled a migration policy in our migration
> software that checks for regression in reproducibility. At this moment, that 
> is
> presented as just for info, but we intend to change that to delays in the not
> so distant future. We eventually want all packages to be reproducible. To
> stimulate maintainers to make their packages reproducible now, we'll soon 
> start
> to apply a bounty for reproducible builds, like we've done with passing
> autopkgtests for years. We'll reduce the bounty for successful autopkgtests at
> that moment in time.

Will reproducibility regressions block migration to testing?


signature.asc
Description: PGP signature

Re: Bits from the Release Team: Cambridge sprint update

[Holger Levsen]

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
> 
> 
> 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 Debian. Several weeks ago, we enabled a migration policy in our migration
> software that checks for regression in reproducibility. At this moment, that 
> is
> presented as just for info, but we intend to change that to delays in the not
> so distant future. We eventually want all packages to be reproducible. To
> stimulate maintainers to make their packages reproducible now, we'll soon 
> start
> to apply a bounty for reproducible builds, like we've done with passing
> autopkgtests for years. We'll reduce the bounty for successful autopkgtests at
> that moment in time.

\o/ and hooray and yay and much looking forward to that! and thanks for 
acknowledging
our work and many thanks to *everyone* contributing so that we've come this far 
by now!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"I like beautiful people. I don't care about their looks."


signature.asc
Description: PGP signature

Re: Bits from the Release Team: Cambridge sprint update

[Santiago Vila]

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 archives all information, and there are
multiple ways anyone can subscribe to the Release Team bugs, so this
mirroring seems unnecessary. More importantly it inhibits the list from
being a more useful discussion channel that we like it to be. Hence, we'll
try to work with the BTS maintainers 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 problem here in -devel, so IMHO splitting
this list would also make sense.

Thanks.

Re: Bits from the Release Team: Cambridge sprint update

[Steven Robbins]

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
> multiple ways anyone can subscribe to the Release Team bugs, so this
> mirroring seems unnecessary. More importantly it inhibits the list from
> being a more useful discussion channel that we like it to be. Hence, we'll
> try to work with the BTS maintainers to direct the traffic away 

Does that mean ceasing the "ITP" messages in debian-devel?  
I'd certainly welcome that!

-Steve


signature.asc
Description: This is a digitally signed message part.

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

[Paul Gevers]

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

As far as I know, build profiles are not documented in policy at all yet. The
bug for that is https://bugs.debian.org/757760

Am I missing something?


Ok, maybe I mixed things up a bit. In the end, what matters for the 
Release Team is that we (potentially; in the future) want to *use* 
 declared Build-Dependencies to figure out what we consider key 
packages. Building documentation is important, but if we can choose 
between not building documentation and not building at all, we prefer 
the former (exceptions exist, as always).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Johannes Schauer Marin Rodrigues]

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 intended,
> >> but with this consequence), so checking for correctness of this
> >> profile may be a bit harder. Ideally, using the profile would just
> >> make documentation binaries virtually empty.
> > 
> > No. Ideally, using the nodoc profile would make documentation binaries not 
> > be
> > emitted at all. This then also makes checking for correctness a lot easier
> > because then all binary packages built with the nodoc profile will be
> > bit-by-bit identical if your source package builds reproducibly.
> 
> Policy [1] says something else:
> """
> This option does not change the set of binary packages generated by the 
> source package, but documentation-only binary packages may be nearly 
> empty when built with this option.
> """
> I suggest you try and get policy updated.
> 
> [1]
> https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options

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

As far as I know, build profiles are not documented in policy at all yet. The
bug for that is https://bugs.debian.org/757760

Am I missing something?

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Paul Gevers]

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 correctness of this
profile may be a bit harder. Ideally, using the profile would just
make documentation binaries virtually empty.


No. Ideally, using the nodoc profile would make documentation binaries not be
emitted at all. This then also makes checking for correctness a lot easier
because then all binary packages built with the nodoc profile will be
bit-by-bit identical if your source package builds reproducibly.


Policy [1] says something else:
"""
This option does not change the set of binary packages generated by the 
source package, but documentation-only binary packages may be nearly 
empty when built with this option.

"""
I suggest you try and get policy updated.

[1] 
https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Johannes Schauer Marin Rodrigues]

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 the profile would just
> make documentation binaries virtually empty.

No. Ideally, using the nodoc profile would make documentation binaries not be
emitted at all. This then also makes checking for correctness a lot easier
because then all binary packages built with the nodoc profile will be
bit-by-bit identical if your source package builds reproducibly.

This can be achieved by adding this to the binary package stanza in d/control:

Package: foo-doc
Architecture: all
Build-Profiles: 

Then, in d/rules you can surround code that creates the foo-doc package with a
conditional like this one:

ifneq (,$(filter foo-doc,$(shell dh_listpackages)))
# do stuff needed to build foo-doc
endif

Using dh_listpackages you also automatically catch other cases in which foo-doc
might not get built other than the nodoc build profile being active, for
example for an arch:any-only build.

Also, do not forget to add the build dependencies necessary to build foo-doc to
Build-Depends-Indep instead of keeping them in Build-Depends if your foo-doc
package is Architecture:all.

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Pierre-Elliott Bécue]

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 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 have a short Hard and Full Freeze (counting in
>> >  > weeks, rather than months), so please plan accordingly. If serious
>> >  > delays turn up during any of the Freeze steps, we rather (partially or
>> >  > completely) thaw bookworm again than staying frozen for a long time.
>> >  >
>> >  > 2023-01-12  - Milestone 1 - Transition and toolchain freeze
>> >  > 2023-02-12  - Milestone 2 - Soft Freeze
>> >  > 2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
>> >  > packages without autopkgtests
>> >  > To be announced - Milestone 4 - Full Freeze
>> >  >
>> >  > On behalf of the Release Team,
>> >
>> >  Hi,
>> >
>> >  OOC, isn't that a bit "too short"? We started to work again in August
>> >  2021, it'll be less than two years until the freeze.
>> >
>> > Less than 1 year to go to milestone 1 starts in January.
>>
>> I was referring to the delay between the end of the freeze and the next
>> hard freeze.
>
> Ok. Debian has been releasing versions every 2 years for a long time.
> I was looking at the site here to remember the dates.
> It is a cycle that is being continued.
>
> https://www.debian.org/releases/

I always have been under the impression it was around 2.5 years between
releases, but indeed, this impression was false.

Thanks!
-- 
PEB


signature.asc
Description: PGP signature

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

[Stephan Verbücheln]

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

Regards
Stephan

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

[Stephan Verbücheln]

Did you mean 2023?

Regards
Stephan

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

[Leandro Cunha]

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 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 Freeze (counting in
> >  > weeks, rather than months), so please plan accordingly. If serious
> >  > delays turn up during any of the Freeze steps, we rather (partially or
> >  > completely) thaw bookworm again than staying frozen for a long time.
> >  >
> >  > 2023-01-12  - Milestone 1 - Transition and toolchain freeze
> >  > 2023-02-12  - Milestone 2 - Soft Freeze
> >  > 2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
> >  > packages without autopkgtests
> >  > To be announced - Milestone 4 - Full Freeze
> >  >
> >  > On behalf of the Release Team,
> >
> >  Hi,
> >
> >  OOC, isn't that a bit "too short"? We started to work again in August
> >  2021, it'll be less than two years until the freeze.
> >
> > Less than 1 year to go to milestone 1 starts in January.
>
> I was referring to the delay between the end of the freeze and the next
> hard freeze.
>
> --
> PEB

Ok. Debian has been releasing versions every 2 years for a long time.
I was looking at the site here to remember the dates.
It is a cycle that is being continued.

https://www.debian.org/releases/

-- 
Cheers,
Leandro Cunha
Software Engineer and Debian Contributor

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

[Pierre-Elliott Bécue]

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 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 Freeze (counting in
>  > weeks, rather than months), so please plan accordingly. If serious
>  > delays turn up during any of the Freeze steps, we rather (partially or
>  > completely) thaw bookworm again than staying frozen for a long time.
>  >
>  > 2023-01-12  - Milestone 1 - Transition and toolchain freeze
>  > 2023-02-12  - Milestone 2 - Soft Freeze
>  > 2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
>  > packages without autopkgtests
>  > To be announced - Milestone 4 - Full Freeze
>  >
>  > On behalf of the Release Team,
>
>  Hi,
>
>  OOC, isn't that a bit "too short"? We started to work again in August
>  2021, it'll be less than two years until the freeze.
>
> Less than 1 year to go to milestone 1 starts in January.

I was referring to the delay between the end of the freeze and the next
hard freeze.

-- 
PEB


signature.asc
Description: PGP signature

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

[Leandro Cunha]

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 please let us know. We also like to stress again that we
> > really would like to have a short Hard and Full Freeze (counting in
> > weeks, rather than months), so please plan accordingly. If serious
> > delays turn up during any of the Freeze steps, we rather (partially or
> > completely) thaw bookworm again than staying frozen for a long time.
> >
> > 2023-01-12  - Milestone 1 - Transition and toolchain freeze
> > 2023-02-12  - Milestone 2 - Soft Freeze
> > 2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
> > packages without autopkgtests
> > To be announced - Milestone 4 - Full Freeze
> >
> > On behalf of the Release Team,
>
> Hi,
>
> OOC, isn't that a bit "too short"? We started to work again in August
> 2021, it'll be less than two years until the freeze.
>
>
Less than 1 year to go to milestone 1 starts in January.

-- 
Cheers,
Leandro Cunha
Software Engineer and Debian Contributor

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

[Pierre-Elliott Bécue]

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 have a short Hard and Full Freeze (counting in
> weeks, rather than months), so please plan accordingly. If serious
> delays turn up during any of the Freeze steps, we rather (partially or
> completely) thaw bookworm again than staying frozen for a long time.
>
> 2023-01-12  - Milestone 1 - Transition and toolchain freeze
> 2023-02-12  - Milestone 2 - Soft Freeze
> 2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
> packages without autopkgtests
> To be announced - Milestone 4 - Full Freeze
>
> On behalf of the Release Team,

Hi,

OOC, isn't that a bit "too short"? We started to work again in August
2021, it'll be less than two years until the freeze.

I'm fine with that, but I wonder if we shouldn't keep with a bit larger
timelines.

Cheers!
-- 
PEB


signature.asc
Description: PGP signature

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

[Eike]

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 autopkgtests

That's already done?
Or in Decembre, in three days?
Or, most likely, 2023?

Stay safe,
Eike


signature.asc
Description: This is a digitally signed message part.

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

[Mike Gabriel]

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 have a short Hard and Full Freeze (counting in
weeks, rather than months), so please plan accordingly. If serious
delays turn up during any of the Freeze steps, we rather (partially or
completely) thaw bookworm again than staying frozen for a long time.

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 autopkgtests
To be announced - Milestone 4 - Full Freeze

On behalf of the Release Team,
Paul


These dates look wrong by one year... (or are we already in Milestone  
3 phase now???).


Shock in the morning...

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpDteM5leRQu.pgp
Description: Digitale PGP-Signatur

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

[Andrey Rahmatullin]

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 have a short Hard and Full Freeze (counting in
> > weeks, rather than months), so please plan accordingly. If serious
> > delays turn up during any of the Freeze steps, we rather (partially or
> > completely) thaw bookworm again than staying frozen for a long time.
> >
> > 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 autopkgtests
> > To be announced - Milestone 4 - Full Freeze
> Is it possible to adopt ISO8601 dates like -MM-DD please (to avoid
> heart attacks) ?
Do you think these phases are so short that they are 1 day each? :)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Leandro Cunha]

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 like to stress again that we
> > really would like to have a short Hard and Full Freeze (counting in
> > weeks, rather than months), so please plan accordingly. If serious
> > delays turn up during any of the Freeze steps, we rather (partially or
> > completely) thaw bookworm again than staying frozen for a long time.
> >
> > 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 autopkgtests
> > To be announced - Milestone 4 - Full Freeze
>
> Have not all of these dates already past?  Or are these milestones over
> three consecutive days in December of this year?
>
> jamie.
>

He sent an email with the corrected dates.
Debian release occurs every 2 years.
The last release one was last year.
The next one will be next year.

-- 
Cheers,
Leandro Cunha
Software Engineer and Debian Contributor

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

[Jameson Graef Rollins]

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 Freeze (counting in
> weeks, rather than months), so please plan accordingly. If serious
> delays turn up during any of the Freeze steps, we rather (partially or
> completely) thaw bookworm again than staying frozen for a long time.
>
> 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 autopkgtests
> To be announced - Milestone 4 - Full Freeze

Have not all of these dates already past?  Or are these milestones over
three consecutive days in December of this year?

jamie.

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

[Jesse Smith]

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 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 Freeze (counting in
> weeks, rather than months), so please plan accordingly. If serious
> delays turn up during any of the Freeze steps, we rather (partially or
> completely) thaw bookworm again than staying frozen for a long time.
>
> 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 autopkgtests
> To be announced - Milestone 4 - Full Freeze
>
> On behalf of the Release Team,
> Paul
>
>
>

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

[Jérémy Lal]

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 also like to stress again that we
> really would like to have a short Hard and Full Freeze (counting in
> weeks, rather than months), so please plan accordingly. If serious
> delays turn up during any of the Freeze steps, we rather (partially or
> completely) thaw bookworm again than staying frozen for a long time.
>
> 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 autopkgtests
> To be announced - Milestone 4 - Full Freeze
>
> On behalf of the Release Team,
> Paul
>

Is it possible to adopt ISO8601 dates like -MM-DD please (to avoid
heart attacks) ?

Jérémy

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

[Brian Thompson]

-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 individually, and we would be sure
> to
> miss some.  Nevertheless, we would like to particularly thank the
> installer
> team, the buildd and ftp teams, the CD team, the publicity team, the
> webmasters, the Release Notes editors, porters and all the bug
> squashers,
> NMUers, package maintainers and translators who have contributed to
> making
> bullseye a great release of which we should all be proud.
> 
> First point release
> ===
> 
> As on previous occasions, we anticipate that the first point release
> for
> bullseye will occur in approximately one month's time.
> 
> Please co-ordinate fixes which you would like to see included in the
> point
> release with the Stable Release Managers (SRMs) via a "pu" bug against
> the
> release.debian.org pseudopackage, including a debdiff of the current
> and
> proposed source packages. Remember to use reportbug unless you enjoy
> crafting the metadata by hand.
> 
> Autopkgtests continue to be crucial to migration
> 
> 
> Following the release of bullseye, we can confirm that autopkgtests
> (when
> provided) will continue to be considered across all architectures for
> migration to bookworm. In other words, the tests need to succeed on
> all
> release architectures for your package to migrate.
> 
> Start working on bookworm
> =
> 
> With the start of the bookworm release cycle, you can now upload to
> unstable those changes you've been holding off during the freeze.
> Please do
> not rush to upload everything all at once, in order to manage load on
> the
> buildds etc.  Automatic testing migration is not yet re-enabled, but
> that
> will happen during the next few days.
> 
> As with bullseye, we would ask that you co-ordinate particularly large
> transitions or changes; if your plans involve major toolchain changes
> or
> otherwise have the potential to cause problems in unstable for a long
> time
> (e.g. due to FTBFS issues), please talk to us. We know that there are
> a
> large number of changes which have been waiting for the release to
> happen
> and we're keen not to stand in the way of those but would also like to
> avoid a number of larger transitions becoming entangled.
> 
> That's it for now; it is time for the celebrations to begin, whether
> at a
> Release Party[1] or otherwise. :-)
> 
> 

Thank you everyone for all your hard work!
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEYccETHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfacLD/9hOuSji6aJQprXk05lvJ+mKHhnhCV9
jX6eEN9exJ4v+gtbD62PYoegqUScVCMYR/B49Je4CKIqlh+9EmcjwnURSBtZPA3F
dP0wgO2zU9j5P4wwCdLEtY5pKYD5Guxl4pqDEvasuoJqV+1RMtyiHC6X8DUeQgJS
O1QtpYgukZEsCaAcQIXFPsI3x3wgMKjiT9WNYLvccknwkEqXikZnvA2T+Dpkijsx
N4MidaOf0syVD1bh3X6uiB+r2WbLdT8j0zJ8Og5dqTWsT011PKnMCf4H8z6PIxwp
RsMokIabZdn1ul99PTTILPMAMD2oV8E8XMzI49++00PH5bJ14xsHBnIbguaxuDa6
aeOyCNZoWn5gKknEsG0LOkAoagkzvaUUq+ZEBOEKeqbuQDPZU9aMMrlH4gsQVXfJ
LEa2h7DNSkShK7NTFugYDaRmec4YFs8CkS7BhbhEvWXaZHMYOaWBcxpzoFaxrJiQ
KQfrjxlE/ddI8JFy+KsAQdmM8jE40vNeFf6H/XXrY3Zj6s5rFG87wqaxGW+iVuV/
1BqpLhXsn8mQN9W+FPHc9zTEco1vDo3fwvDatEWktkNJM/zk2TURG/VBATBd1N+z
kansOpHtQ0grEDlhVcYhKBF8XnpmphGGKt4NGN+RE6MYsSa/tErt/bgD6HksVcVa
o/HMNFHI8J+PJw==
=fGSa
-END PGP SIGNATURE-

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

[Paul Gevers]

-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



-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl//WMYACgkQnFyZ6wW9
dQqPcAf/UfIMBsPfM9zQCqkBbEyBis7wc9UKALF3j6TJHMojEXW1I3KPd3m5A3rh
Tgf7HMxRKZlWhs4QUrN1jvth7LWZG0L0RAmEoSROenBCXJF3HVJMgJw+n7pRSsfC
iuUlmkURiv9Wy82qqdNWQ4bBGejiJX+7IqpWBj9zLUNIxFM/SjKk4xU8IJClzy+D
2/xVdsxPLjzHrBQ+S/U4EtyD6O91Ru9HkdS7a842sMVH+VCUnbohPEPv9k/I3pEJ
zF4Y0ZbZKbvjrOFcXbM+JVNsJDcQLGxQioBOsVz85e1g11cZC781DXhWwYXp2VBL
7SE5mUJdR4nwpMguQ/dJa8cUFeF37Q==
=gug6
-END PGP SIGNATURE-




OpenPGP_signature
Description: OpenPGP digital signature

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

[Pirate Praveen]

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 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 could even activate this by default.
>> 
>> Yes, please do this by default so we can have a better picture of the
>transition.
>
>It's not running 100% automatically and it has a bit (600 tests) of
>backlog, but it's here already:
>https://release.debian.org/britney/pseudo-excuses-experimental.html
>
>I'll cron it probably tomorrow evening.
>
>Paul

Thanks a lot, it is really helpful for transitions. Now I can see a list of 
packages blocking gitlab upload to unstable in one place.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Paul Gevers]

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.
>> This would enable library maintainers to at least have an overview of
>> what would happen. I could even activate this by default.
> 
> Yes, please do this by default so we can have a better picture of the 
> transition.

It's not running 100% automatically and it has a bit (600 tests) of
backlog, but it's here already:
https://release.debian.org/britney/pseudo-excuses-experimental.html

I'll cron it probably tomorrow evening.

Paul



signature.asc
Description: OpenPGP digital signature

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

[Paul Gevers]

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
> prepare new releases on experimental.

Soon. Figuring out some details on our side.

> Perhaps derailing the thread a little, but other "pretty nice stuff to have" 
> as
> a Debian service would be something that allows rebuilds of rdeps of stuff in
> experimental.

I can think of two existing services, albeit both need a bit of
scripting on your side:
1) porterboxes (see e.g.
   https://lists.debian.org/msgid-search/20190614222919.gc24...@grep.be)
2) http://debomatic-amd64.debian.net/ (and other archs).

> But yes, once again I can't nor will force anyone into doing it :-)

Nor do you need to in my opinion. Yes, running on your own hardware is a
pity.

Paul



signature.asc
Description: OpenPGP digital signature

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

[Mattia Rizzolo]

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 show this on their page. (Working on
> > > such a patch is on my TODO list, except not at the top).
> 
> I already made grep-excuses print this information.  It has been very
> helpful to me.  Maybe we should make --autopkgtests the default ?

I think no: --autopkgtests requires quite a bit more computation and
connecting to udd and whatnot, I don't think that should be the default.
Especially because udd-mirror is starting to be under-dimensioned so
it's sometimes quite slow to serve responses (like in the times when its
importing a new dump).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Ian Jackson]

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 breackage it might occur on them because:
> 
> - They added autopkgtests, so they are showing an intent on
>   reviewing them when they fail.
> - They will certainly know their packages better than the library
>   maintainer, and thus they have more chances to get the root of the
>   issue sooner. Of course that might mean finding a bug in the
>   library, but that's just ok.

In the general case the proper investigation of a bug might need
involvement from both people, collaboratively.  That involves a kind
of ping pong on a technical level.

> 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 show this on their page. (Working on
> > such a patch is on my TODO list, except not at the top).

I already made grep-excuses print this information.  It has been very
helpful to me.  Maybe we should make --autopkgtests the default ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

[Lisandro Damián Nicanor Pérez Meyer]

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 
> > 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
> >> even more and more "stuff to care for".
> > 
> > I can see why you feel that way.
> > 
> > I think maybe we need to make it easier for the maintainer of a
> > widely-used library to push some of this out to depending packages.
> 
> I agree with this.
> 
> > (And I speak as a maintainer of a leaf package with a thorough
> > autopkgtest suite which often blocks the migration of my
> > dependencies.)
> > 
> > Lisandro, would it meet your needs if you had free licence to file RC
> > bugs against all packages which were blocking your migration, before
> > you had done the investigation yourself ?

It might help, but I'm not certain. The bug may or may not be in the library on
in the leaf packages. Filing bugs may start a ping pong of "it's your fault"
bugs between maintainers.

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 breackage it might occur on them because:

- They added autopkgtests, so they are showing an intent on reviewing them when
  they fail.
- They will certainly know their packages better than the library maintainer,
  and thus they have more chances to get the root of the issue sooner. Of course
  that might mean finding a bug in the library, but that's just ok.

Note that the principle I'm basing myself is "we can't force a maintainer to do
stuff". So whoever adds autopkgtests to their packages must be the one who
starts the debugging when something fails, not the other side.

Pretty please don't get me wrong: in an ideal world everyone should start
digging the issue. But Debian being volunteer-based simply can't get to that
point, except by forcing maintainers to do even more stuff.

> > I think the effect would be that a maintainer of a dependent package
> > would have to engage with the situation and if they did nothing for
> > long enough, the autoremoval would kick in.  Then your library would
> > be able to migrate.
> 
> Obviously this only works if the reverse dependency isn't also a key
> package. So, in any case, please contact the release team early if you
> experience problems, we can help.
> 
> > This seems similar to the approach we take with (say) new compilers,
> > which trigger FTBFS bugs in depending packages.  The compiler
> > maintainers do not investigate the issues - they file bugs, which
> > eventually become RC, and then the depending packages must either be
> > fixed our autoremoved.
> 
> 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 show this on their page. (Working on
> such a patch is on my TODO list, except not at the top).
> 
> > (Of course some library maintainers would prefer to do some
> > investigation first.)
> 
> 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
prepare new releases on experimental.

> This would enable library maintainers to at least have an overview of
> what would happen. I could even activate this by default.
> 
> We also have an Outreachy intern working on a self-service corner on
> ci.d.n, so that more testing can be done if people want it.

Perhaps derailing the thread a little, but other "pretty nice stuff to have" as
a Debian service would be something that allows rebuilds of rdeps of stuff in
experimental. It can be on just one powerful arch (amd64 possibly?). In this way
we libs maintainers would not need to use or personal resources in rebuilding
stuff. Says someone from Argentina who has a 10+years old machine as main
machine and a quite devaluated (and devaluating) currency. I think Ubuntu has
something along this idea.

But yes, once again I can't nor will force anyone into doing it :-)

Cheers, Lisandro.

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

[Pirate Praveen]

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 could even activate this by default.

Yes, please do this by default so we can have a better picture of the 
transition. Though for many libraries we also need to rebuild reverse build 
dependencies. I have been using salsa.debian.org/ruby-team/meta/build for this. 
Right now I'm interested in libgit2, grpc and protobuf transitions.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Paul Gevers]

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") is that maintainers, specially library maintainers, have
>> even more and more "stuff to care for".
> 
> I can see why you feel that way.
> 
> I think maybe we need to make it easier for the maintainer of a
> widely-used library to push some of this out to depending packages.

I agree with this.

> (And I speak as a maintainer of a leaf package with a thorough
> autopkgtest suite which often blocks the migration of my
> dependencies.)
> 
> Lisandro, would it meet your needs if you had free licence to file RC
> bugs against all packages which were blocking your migration, before
> you had done the investigation yourself ?
>
> I think the effect would be that a maintainer of a dependent package
> would have to engage with the situation and if they did nothing for
> long enough, the autoremoval would kick in.  Then your library would
> be able to migrate.

Obviously this only works if the reverse dependency isn't also a key
package. So, in any case, please contact the release team early if you
experience problems, we can help.

> This seems similar to the approach we take with (say) new compilers,
> which trigger FTBFS bugs in depending packages.  The compiler
> maintainers do not investigate the issues - they file bugs, which
> eventually become RC, and then the depending packages must either be
> fixed our autoremoved.

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 show this on their page. (Working on
such a patch is on my TODO list, except not at the top).

> (Of course some library maintainers would prefer to do some
> investigation first.)

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 could even activate this by default.

We also have an Outreachy intern working on a self-service corner on
ci.d.n, so that more testing can be done if people want it.

Paul



signature.asc
Description: OpenPGP digital signature

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

[Ian Jackson]

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
> even more and more "stuff to care for".

I can see why you feel that way.

I think maybe we need to make it easier for the maintainer of a
widely-used library to push some of this out to depending packages.

(And I speak as a maintainer of a leaf package with a thorough
autopkgtest suite which often blocks the migration of my
dependencies.)

Lisandro, would it meet your needs if you had free licence to file RC
bugs against all packages which were blocking your migration, before
you had done the investigation yourself ?

I think the effect would be that a maintainer of a dependent package
would have to engage with the situation and if they did nothing for
long enough, the autoremoval would kick in.  Then your library would
be able to migrate.

This seems similar to the approach we take with (say) new compilers,
which trigger FTBFS bugs in depending packages.  The compiler
maintainers do not investigate the issues - they file bugs, which
eventually become RC, and then the depending packages must either be
fixed our autoremoved.

(Of course some library maintainers would prefer to do some
investigation first.)

Ian.

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

[Lisandro Damián Nicanor Pérez Meyer]

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 failures will be considered
> release-critical for
> >> bullseye. So if your package has failing autopkgtests, now is a good
> time to
> >> start looking for a fix
> >
> > Now this raises some questions for me. Now I maintain a (huge) library
> > (hello Qt!). I do an unstable upload and package A starts failing it's
> > autopkgtests. In this case:
> >
> > - How does this failure affects the uploaded library (imagine we have
> > a transition, as it will always be Qt's case due to private headers).
>
> By default, the migration to testing will be blocked, exactly like we
> have been doing the last half year.
>
> > - What's expected from the maintainers of the library?
>
> It is expected that you communicate (e.g. via a bug report filed against
> both packages like I have been doing for over a year now, see examples
> on [1]) with the maintainers of the package to see why the test starts
> failing. Together, you should be able to work out which package needs to
> adapt. Either the autopkgtest found a real issue in your library which
> you need to fix, or the package needs to adapt to the new status of your
> library, either by fixing the package itself, or its autopkgtest. The
> migration of your library will be stalled to give the package time to be
> adapted. Of course that needs to happen within a reasonable amount of
> time, so if it takes to long, or you and the maintainers of the package
> can't agree on who should adapt what, contact the release team.
>
> Just to be clear, in case you got confused by it, if the package
> *already* fails in testing, it isn't a concern for packages that just
> trigger that autopkgtest, only for the package with the failing
> autopkgtest.
>
> I wonder if you were thinking of something else? If so, please elaborate.
>


First of all thanks for replying and sorry for not doing so sooner, I
clearly missed it.

No, what I have been perceiving (and pretty please note that this is my
personal "feeling") is that maintainers, specially library maintainers,
have even more and more "stuff to care for". Also please don't get me
wrong, I do understand that this is indeed with the idea of improving
Debian. But the amount of work needed to maintain the same stuff I have
been working with this last years take more and more time, to the point
that sometimes I feel it gets into pair with a payed job.

Once again please remember it's my personal point of view, and if something
above doesn't seems quite right it might be my not so good English ;-)

Again, thanks a lot for replying.

Cheers, Lisandro.

>

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

[Paul Gevers]

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 package has failing autopkgtests, now is a good time to
>> start looking for a fix
> 
> Now this raises some questions for me. Now I maintain a (huge) library
> (hello Qt!). I do an unstable upload and package A starts failing it's
> autopkgtests. In this case:
> 
> - How does this failure affects the uploaded library (imagine we have
> a transition, as it will always be Qt's case due to private headers).

By default, the migration to testing will be blocked, exactly like we
have been doing the last half year.

> - What's expected from the maintainers of the library?

It is expected that you communicate (e.g. via a bug report filed against
both packages like I have been doing for over a year now, see examples
on [1]) with the maintainers of the package to see why the test starts
failing. Together, you should be able to work out which package needs to
adapt. Either the autopkgtest found a real issue in your library which
you need to fix, or the package needs to adapt to the new status of your
library, either by fixing the package itself, or its autopkgtest. The
migration of your library will be stalled to give the package time to be
adapted. Of course that needs to happen within a reasonable amount of
time, so if it takes to long, or you and the maintainers of the package
can't agree on who should adapt what, contact the release team.

Just to be clear, in case you got confused by it, if the package
*already* fails in testing, it isn't a concern for packages that just
trigger that autopkgtest, only for the package with the failing autopkgtest.

I wonder if you were thinking of something else? If so, please elaborate.

Paul

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org



signature.asc
Description: OpenPGP digital signature

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

[Michael Hudson-Doyle]

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, Jonathan Wiltshire wrote:
> > > 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 to do source-only
> uploads if
> > > you want them to reach bullseye.
>
> > But this part not so much.
> >
> > Forcing hundreds of maintainers to do two uploads for a new package
> > seems to me like the wrong solution for the conflicting interests of
> > the ftp team (wants to see binary packages for review in NEW) and the
> > release team (doesn't want to see binary packages in testing not
> > built by buildds).
>

FWIW in Ubuntu, packages go through NEW as source and then as soon as they
build they go back through as binaries. It seems to work OK.


> There's also a third concern: we need a way to bootstrap B-Depend cycles.
> Such as a self-hosting compiler, cyclical dependencies within an ecosystem,
> importing a whole new architecture, etc.
>

But the ban is only on developer-built binaries in testing. So you can
upload with binaries to unstable, then once they are published make a
source-only upload, the binaries from which will migrate. Sure it's an
extra upload or two but it's not that complicated really.

> I hope that there will be a better solution for this dilemma in the
> > not too distant future. If throwing away binaries is too problematic,
> > as Niels mentioned, maybe SomeThing™ could build a binary package for
> > the ftp-masters for source-only uploads to NEW. Or people knowing the
> > whole infrastructure better than me have smarter ideas :)
>
> The -ports team has an "unreleased" suite that buildds can use both for
> Deps and B-Deps, and people can use before patches are upstreamed.
> Something of this kind could be done for binary uploads.
>
> Some dude named Ken Thompson had an insightful comment here, but that's
> the easiest solution for now.
>

Well there's no getting away from that.

Cheers,
mwh

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

[Adam Borowski]

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 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 to do source-only uploads 
> > if
> > you want them to reach bullseye.

> But this part not so much.
>  
> Forcing hundreds of maintainers to do two uploads for a new package
> seems to me like the wrong solution for the conflicting interests of
> the ftp team (wants to see binary packages for review in NEW) and the
> release team (doesn't want to see binary packages in testing not
> built by buildds).

There's also a third concern: we need a way to bootstrap B-Depend cycles. 
Such as a self-hosting compiler, cyclical dependencies within an ecosystem,
importing a whole new architecture, etc.

> I hope that there will be a better solution for this dilemma in the
> not too distant future. If throwing away binaries is too problematic,
> as Niels mentioned, maybe SomeThing™ could build a binary package for
> the ftp-masters for source-only uploads to NEW. Or people knowing the
> whole infrastructure better than me have smarter ideas :)

The -ports team has an "unreleased" suite that buildds can use both for
Deps and B-Deps, and people can use before patches are upstreamed.
Something of this kind could be done for binary uploads.

Some dude named Ken Thompson had an insightful comment here, but that's
the easiest solution for now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄

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

[gregor herrmann]

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, the
> buildd and ftp teams, the CD team, the publicity team, the webmasters, the
> Release Notes editors, porters and all the bug squashers, NMUers, package
> maintainers and translators who have contributed to making buster a great
> release of which we should all be proud.

You indeed missed someone (for obvious reasons): I'd like to thank
the release team for their excellent work!
 
> 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 to do source-only uploads if
> you want them to reach bullseye.

That's great news.
 
>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>  do I need to do a new (source-only) upload for it to reach bullseye?
>   A: Yes. We also suggest going through NEW in experimental instead of 
> unstable
>  where possible, to avoid disruption in unstable.

But this part not so much.
 
Forcing hundreds of maintainers to do two uploads for a new package
seems to me like the wrong solution for the conflicting interests of
the ftp team (wants to see binary packages for review in NEW) and the
release team (doesn't want to see binary packages in testing not
built by buildds).

I hope that there will be a better solution for this dilemma in the
not too distant future. If throwing away binaries is too problematic,
as Niels mentioned, maybe SomeThing™ could build a binary package for
the ftp-masters for source-only uploads to NEW. Or people knowing the
whole infrastructure better than me have smarter ideas :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

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

[Sean Whitton]

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

For the addition to the binary package namespace to be reviewed.

> Following on that, what about a package that does add/remove source
> files (perhaps many) without a SONAME bump or other change that results
> in a new binary package?

Same again.

> It seems like reviewing the package name space on introduction of a new
> binary package and an additional review of a SONAME bump are good things
> and the binary-NEW criteria seem to fit.  However, the "there might be
> new source files with licensing issues" does not seem to be a good fit
> for binary-NEW criteria.  Not to say that it matters much in the context
> of binary-NEW.  But if catching potential licensing issues associated
> with large source changes is in fact something which the FTP team wishes
> to be able to do, it probably warrants a different filter than "adds a
> new binary package to the archive" in order to be effective.

The FTP team can't check every single upload, so I guess that at some
point someone decided that checking every binary-NEW upload was a
sensible compromise.

More sophisticated filtering on what gets checked would probably be a
good idea, but that would need someone to implement it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Roberto C . Sánchez]

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 by
> > the FTP team? Couldn't this be fully automated?
> 
> The three things the FTP team check[1] are worth doing again for
> binary-NEW packages.  In order: there are often lots of new files in an
> upload that ends up in binary-NEW so there might be licensing issues; a
> new binary package means a new member of the binary package namespace;
> it's good to have a second pair of eyes look at your SONAME bump etc.
> 
> [1]  https://ftp-master.debian.org/REJECT-FAQ.html right at the top
> 
I've always wondered about this.

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

Following on that, what about a package that does add/remove source
files (perhaps many) without a SONAME bump or other change that results
in a new binary package?

It seems like reviewing the package name space on introduction of a new
binary package and an additional review of a SONAME bump are good things
and the binary-NEW criteria seem to fit.  However, the "there might be
new source files with licensing issues" does not seem to be a good fit
for binary-NEW criteria.  Not to say that it matters much in the context
of binary-NEW.  But if catching potential licensing issues associated
with large source changes is in fact something which the FTP team wishes
to be able to do, it probably warrants a different filter than "adds a
new binary package to the archive" in order to be effective.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

[Sean Whitton]

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 still do not have an interface to allow
> developers to self-service request a binNMU of a package?
> It would solve this and other problems.

My impression from talking to wanna-build people is that there are
sufficiently many subtleties involved in correctly scheduling binNMUs
that costly (in terms of buildd and human time) mistakes would be
likely.

Unless the interface only let you do very simple binNMU requests of
single packages, in which case it might not be worth implementing.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

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 FTP team check[1] are worth doing again for
binary-NEW packages.  In order: there are often lots of new files in an
upload that ends up in binary-NEW so there might be licensing issues; a
new binary package means a new member of the binary package namespace;
it's good to have a second pair of eyes look at your SONAME bump etc.

[1]  https://ftp-master.debian.org/REJECT-FAQ.html right at the top

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Adam Borowski]

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 still do not have an interface to allow 
> developers to self-service request a binNMU of a package?
> It would solve this and other problems.

Main reason being trying to get rid of binNMUs, to be replaced by
changelog-only source uploads (for a number of reasons, such as not working
on arch:all packages, fragile wrt dependencies, breaking multiarch when
every arch is not in sync, requiring tricky tracking of rebuilds --
especially for archs in a different wanna-build such as -ports, especially
tricky tracking for unofficial ports, etc).

There's no convenient tooling for sourceful "bin"NMUs yet, but the
maintainer can already do that by hand.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄

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

[Marco d'Itri]

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 request a binNMU of a package?
It would solve this and other problems.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Matthias Klose]

> 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 to do source-only uploads if
> you want them to reach bullseye.

[...]

>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>  do I need to do a new (source-only) upload for it to reach bullseye?
>   A: Yes. We also suggest going through NEW in experimental instead of 
> unstable
>  where possible, to avoid disruption in unstable.

I think this is bad advice, because with long running builds, you'll get stuck
in NEW twice, once doing the upload in experimental, and then doing the source
only upload to unstable, because your binary packages got already removed, and
the builds from the buildds land in NEW again.  So if you want to enforce that,
it would be better to avoid that extra work on the FTP team, and the package
uploaders.

Matthias

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

[Michael Biebl]

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.
>> From now on, we will no longer allow binaries uploaded by maintainers to
>> migrate to testing. This means that you will need to do source-only uploads 
>> if
>> you want them to reach bullseye.
> 
> I support this move in principle, but:
> 
>>   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).
>>
>>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>>  do I need to do a new (source-only) upload for it to reach bullseye?
>>   A: Yes. We also suggest going through NEW in experimental instead of 
>> unstable
>>  where possible, to avoid disruption in unstable.
> [...]
> 
> This is not going to fly for src:linux.  We can't stage ABI bumps in
> experimental as we typically have a different upstream versions in
> unstable and experimental.  We even need to do ABI bumps in stable from
> time to time.
> 
> I think that the requirement to upload binary packages for binary-NEW
> (but not source-NEW) needs to go.

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?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Lisandro Damián Nicanor Pérez Meyer]

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
> start looking for a fix

Now this raises some questions for me. Now I maintain a (huge) library
(hello Qt!). I do an unstable upload and package A starts failing it's
autopkgtests. In this case:

- How does this failure affects the uploaded library (imagine we have
a transition, as it will always be Qt's case due to private headers).
- What's expected from the maintainers of the library?

Thanks, Lisandro.

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

[Holger Levsen]

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 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 to do source-only uploads if
> you want them to reach bullseye.
> 
> 
>   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).
> 
>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>  do I need to do a new (source-only) upload for it to reach bullseye?
>   A: Yes. We also suggest going through NEW in experimental instead of 
> unstable
>  where possible, to avoid disruption in unstable.

whh, that's *totally* awesome news! loving it.

> All autopkgtest failures considered RC for bullseye

also very yay!

exciting times ahead!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bits from the Release Team: buster freeze update

[Andrey Rahmatullin]

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.org/bugs/?release=buster=ign=ign=ign=ign=ign=ign=7=7=1=id=asc=html

Consider adding other filters too.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bits from the Release Team: buster freeze update

[Boyuan Yang]

在 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 easiest way to get a list of these RC bugs?

Visiting  https://bugs.debian.org/release-critical/other/testing.html
should be the best way.

--
Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Re: Bits from the Release Team: buster freeze update

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

[Ondřej Surý]

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 from now on
>> (well, practically already 10 days ago) all migrations to testing will
>> require manual approval by the release team. 
> 
> 
> Are we in full freeze since "some minutes ago" or since "10 days ago"?
> 
> 
> Milan
> 

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

[Milan Kupcevic]

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. 


Are we in full freeze since "some minutes ago" or since "10 days ago"?


Milan



signature.asc
Description: OpenPGP digital signature

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

[Dimitri John Ledkov]

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 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 stretch is 9 or was it jessie.
>>
>> I have to look up the name not the number.
>
> I have often wanted to have on my system a text file containing the
> correspondence between code name and release number.  I know this is one
> more thing for the base-files maintainer to do during an already busy
> period just before release, but if he is willing, it would be nice to
> have a file, suggested to be /usr/share/doc/base-files/debian_releases,
> that contains each code name with its Debian release number, as well as
> the code name for the current testing release.
>
> I know this info is in the Debian wiki, but having it in a local text
> file is more convenient.  I would also be okay if this were a text file
> in debian-history, but I find that solution less satisfactory than being
> in base-files which is essential/required.
>
> 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_version contains
> codename/sid for testing and unstable, debian_codename could just
> contain the codename.
>
> Santiago, if you are willing to do either or both of these, I would
> appreciate it, but I certainly understand if it is just one too many
> things to remember during release prep.  If you don't want
> debian_releases in base-files, I'll reassign this bug to debian-history.

Have you tried $ debian-distro-info at all?

There are multiple bindings to it. there is csv file at
/usr/share/distro-info/debian.csv

And one can call it in many helpful ways:

$ debian-distro-info --testing
buster

$ debian-distro-info --series buster -r
10

Fix released by distro-info package? It lets you query things about
all the releases. There is ubuntu-distro-info to check all the Awesome
Animals too

-- 
Regards,

Dimitri.

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

[Marvin Renich]

* 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.
> > Perhaps /etc/debian_codename?  Since debian_version contains
> > codename/sid for testing and unstable, debian_codename could just
> > contain the codename.
> 
> You already have that information in /etc/os-release and the lsb_release 
> command.

Thanks much!  I completely missed that.

Closing the bug now.  Sorry for the noise.

...Marvin

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

[Chris Lamb]

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 speak XML.. Naturally, these are not as
convienent as a simple text file, so I am simply pointing them out.

> I would also like /etc/debian_version to contain both number and name

[…]

To avoid conflation of topics, this sounds like this should be a
separate wishlist bug, at least in the first instance.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

[Emilio Pozuelo Monfort]

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_version contains
> codename/sid for testing and unstable, debian_codename could just
> contain the codename.

You already have that information in /etc/os-release and the lsb_release 
command.

Cheers,
Emilio

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

[Marvin Renich]

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".
> 
> No, it’s not. I know that my systems are running Debian 8 or 9, but I always
> have to think if stretch is 9 or was it jessie.
> 
> I have to look up the name not the number.

I have often wanted to have on my system a text file containing the
correspondence between code name and release number.  I know this is one
more thing for the base-files maintainer to do during an already busy
period just before release, but if he is willing, it would be nice to
have a file, suggested to be /usr/share/doc/base-files/debian_releases,
that contains each code name with its Debian release number, as well as
the code name for the current testing release.

I know this info is in the Debian wiki, but having it in a local text
file is more convenient.  I would also be okay if this were a text file
in debian-history, but I find that solution less satisfactory than being
in base-files which is essential/required.

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_version contains
codename/sid for testing and unstable, debian_codename could just
contain the codename.

Santiago, if you are willing to do either or both of these, I would
appreciate it, but I certainly understand if it is just one too many
things to remember during release prep.  If you don't want
debian_releases in base-files, I'll reassign this bug to debian-history.

...Marvin

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

[Stephan Seitz]

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 stretch is 9 or was it jessie.


I have to look up the name not the number.

Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

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

[Philipp Kern]

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 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, even if it's just for
aesthetic reason - "buster" is just more comfortable than "debian10".
However, above all is the rule "do not confuse". Starting two
consecutive releases with the same letter does. Adding a third one 
makes

it worse.


I'm fine with that.

Kind regards
Philipp Kern

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

[Russ Allbery]

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 Allbery (r...@debian.org)   

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

[Russ Allbery]

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 what can upcase('i') and
> lowercase('I') be?  Even this is not invariant.

Yes?  Not sure that's super-relevant here, but that's a rather notorious
edge case in the Turkish locale.

> Thus, there are locales where a purely ASCII word sorts differently when
> capitalized and when not.

Yes, including en_US.

-- 
Russ Allbery (r...@debian.org)   

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

[Clément Hermann]

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 doesnt exist, thus the default, C, is used.)

Indeed, it doesn't exist. At least , for fr_* locale, it seems to be
consistent both in the different charsets available (e.g. fr_FR and
fr_FR.UTF-8) and country (fr_BE, fr_CA, fr_CH, fr_FR and fr_LU).

Actually I thought the localization had been made consistently with the
apparition of unicode locales, that is, fr_* locale would all give the
same result regardless of the charset (but older fr_FR for instance
might give a different order than before the apparition of the unicode
variant). I may be wrong - one would probably have to check the code in
GNU libc to be sure.

However, Note that the generation of locale matters: at first I thought
fr_FR and fr_BE where behaving differently, but after uncommenting all
fr_* locales in /etc/locale.gen, everything became consistent.


Cheers,

-- 
nodens

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

[Christoph Biedl]

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, even if it's just for
aesthetic reason - "buster" is just more comfortable than "debian10".
However, above all is the rule "do not confuse". Starting two
consecutive releases with the same letter does. Adding a third one makes
it worse.

Christoph



signature.asc
Description: PGP signature

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

[Holger Levsen]

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=en_GB.utf8 sort
> buster
> Stretch

wow, madness. thanks.

(maybe just mild madness... :)

> -- 
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand

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 doesnt exist, thus the default, C, is used.)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

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

[Adam Borowski]

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('I')
be?  Even this is not invariant.

Thus, there are locales where a purely ASCII word sorts differently when
capitalized and when not.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄

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

[Stephan Seitz]

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 sort so 
differently.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

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

[Ben Caradoc-Davies]

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 "buster\nStretch" | LC_COLLATE=C sort
Stretch
buster

In en_GB, by comparison:

$ echo -e "buster\nStretch" | LC_COLLATE=en_GB.utf8 sort
buster
Stretch

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

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

[Chris Lamb]

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 as single letters (sorted
> respectively between "c" and "d", and between "l" and "m".

What happens if a letter is not really defined in that alphabet?

For example, the Croatian alphabet has no "Q" (whilst it's locale
probably does, otherwise madness..).


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

[Miroslav Kure]

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
dino
horse
jackal

% LC_COLLATE=cs_CZ sort animals
dino
horse
cheetah
jackal

"ch" belongs between "h" and "i".

-- 
Miroslav Kure

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

[Adrian Bunk]

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 order", not everybody order letters the same way.
> > > really? there's more than one alphabetical order for english words?
> > 
> > yes, sorting depends on the locale... :)
> 
> specifically, what locale sorts english words differently than LANG=C?

Estonian (et_EE) sorts z between s and t.

> Mike Stone

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[Russ Allbery]

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 Æ and ß
> will be changed to ae and ss, and the like, and then sorted accordingly.

The above is the answer to the question "where does English sort
differently than LC_ALL=C."  The sorting behavior for résumé will vary
between the C locale and a proper en_US (or, I believe, en_GB) locale.

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.  They normally don't survive more than a few years
into adoption of a word into the general vocabulary.  I almost never see
someone write résumé instead of resume in regular US business contexts.
(Some of this is because US keyboards are generally not set up to make
handling the accents easy, and most US typists have never learned how to
create those characters quickly, so it's a lot easier to just leave them
off.)

-- 
Russ Allbery (r...@debian.org)   

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

[Michael Stone]

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 order for english words?
> yes, sorting depends on the locale... :)

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)?

I know that there are differences if you have words containing non-ASCII
characters like ü.


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). I understand that German
sorts äöü at the end.

But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
school, "ch" and "ll" were treated as single letters (sorted
respectively between "c" and "d", and between "l" and "m". So,
thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
and lobster < llama < manatee.


So, in the context of naming releases that are ordered by the first 
letter of the name, this seems to be a complete non-issue? We can safely 
assume that initial letters a

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

[Gunnar Wolf]

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, as do ñ and n, as do u and
> > ü (and we have no further diacriticals). I understand that German
> > sorts äöü at the end.
> > 
> > But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
> > school, "ch" and "ll" were treated as single letters (sorted
> > respectively between "c" and "d", and between "l" and "m". So,
> > thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
> > and lobster < llama < manatee.
> 
> Not speaking as a programmer, but as a native American English
> speaker...
> 
> Your example is incorrect sorting behavior in English. Although
> Spanish might sort their words that way, English does not have
> double-character letters; ch and ll are treated as c then h, and l
> then l, for purposes of sorting. Therefore in English, it is correct
> that we sort cheetah < cow < dinosaur, and llama < lobster <
> manatee.
> (...)

Right - I was giving an example where a Latin-alphabet-using language
might sort differently than the C locale.

FWIW I *believe* we don't do that anymore in Spanish. But old
dictionaries did have this behavior. So, point in case – If you want
to sort, use numbers.

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

[Matthew Crews]

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). I understand that German
> sorts äöü at the end.
> 
> But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
> school, "ch" and "ll" were treated as single letters (sorted
> respectively between "c" and "d", and between "l" and "m". So,
> thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
> and lobster < llama < manatee.

Not speaking as a programmer, but as a native American English speaker...

Your example is incorrect sorting behavior in English. Although Spanish might 
sort their words that way, English does not have double-character letters; ch 
and ll are treated as c then h, and l then l, for purposes of sorting. 
Therefore in English, it is correct that we sort cheetah < cow < dinosaur, and 
llama < lobster < manatee.

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 Æ and ß will be changed to ae and ss, and the 
like, and then sorted accordingly.

So if you are sorting words with an American English locale, and it diverges 
from this behavior, it is wrong.

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

[Gunnar Wolf]

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 locale... :)
> 
> 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)?
> 
> I know that there are differences if you have words containing non-ASCII
> characters like ü.

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). I understand that German
sorts äöü at the end.

But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
school, "ch" and "ll" were treated as single letters (sorted
respectively between "c" and "d", and between "l" and "m". So,
thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
and lobster < llama < manatee.

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

[Stephan Seitz]

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 sorting difference.

Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

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

[Stephan Seitz]

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 different 
locales if you only have english words (and I would say it means only 
ASCII in this case)?


I know that there are differences if you have words containing non-ASCII 
characters like ü.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

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

[Michael Stone]

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 alphabetical order for english words?


yes, sorting depends on the locale... :)


specifically, what locale sorts english words differently than LANG=C?

Mike Stone

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

[Holger Levsen]

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 the locale... :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

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

[Michael Stone]

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

[Aurelien Jarno]

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 everybody order letters the same way.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

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

[Emilio Pozuelo Monfort]

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 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 much in Debian.
> 
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
> 
> I think it would be a good habit for others as well, especially in
> public-facing communication.

That's a very good point, particularly for announcements. I'll try to keep it in
mind.

Cheers,
Emilio

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

[Andrey Rahmatullin]

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,
> > but not so much in Debian.
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
Unfortunately there is also a lot of tools where this would be helpful.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Lars Wirzenius]

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 much in Debian.

I've been developing a habit of writing both number and codename:
Debian 9 (stretch) and Debian 42 (billgates).

I think it would be a good habit for others as well, especially in
public-facing communication.

signature.asc
Description: This is a digitally signed message part

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

[Andrey Rahmatullin]

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 first letter is a fairly simple way to aid this.
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 much in Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Philipp Kern]

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 necessary in my opintion. And yes,
> sid is a problem then. It would hit us in around the year 2055. I expect
> to be stable by then. Stable six feet under.

Turns out that this is a terrible idea. We should use numeric values for
sorting. (And Ubuntu now does the same thing on the technical side.)

Kind regards
Philipp Kern

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

[Christoph Biedl]

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 see three consecutives releases starting with the letter "b":
buster, bullseye, bookworm - quite funny and I reckon it's no
coincidence. However, it's bad idea.

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 first letter is a fairly simple way to aid this.

Also, people who do any kind of work related to releases would likely
use the names as an identifier, directory and screen session names in my
case. Different starting letters speed up tab completion and similar
matching procedures. Just another letter to type (or even two for buster
vs. bullseye) might sound like nothing, but in the long run it shows.
I might switch to the release numbers then which gives a sad feeling of
loosing some color in the work.


Probably it's too late to revert the decision. But for future codenames
I'm asking you to choose names in a way these aspects are considered as
well - and I regret I never sent this mail right after the buster and
bullseye name announcement as I wanted to.

So, please use names that are really easy to tell apart. Having unique
initial letters among all supported release is an essential part of
it. Taking also the symlinks into account was worth a consideration
although this would block any name starting with "e", "o", "s", "t", or
"u".

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 necessary in my opintion. And yes,
sid is a problem then. It would hit us in around the year 2055. I expect
to be stable by then. Stable six feet under.

Christoph


signature.asc
Description: PGP signature

Re: Bits from the Release Team: Architecture health check

[Peter Palfrader]

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 regular kernel panics when we upgraded two sparc
 machines two wheezy; installing the 3.11 kernel from backports resolved
 the issue.

Just tried 3.12 from bp on smetana - didn't survive a day.

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140131120811.gb3...@anguilla.noreply.org

Re: Bits from the Release Team: Architecture health check

[Lucas Nussbaum]

On 29/01/14 at 19:41 +0100, Niels Thykier wrote:
 Recursive auto-removals temporarily suspended
 ===
 
 We have received complaints that package maintainers felt surprised
 and inadequately warned, when their packages were removed due to a(n
 indirect) dependency being removed.  Therefore, we have decided to
 temporarily suspend removals of packages that have reverse
 dependencies until a push-notification is in place.
 
 As soon as this issue is resolved, we will re-enable recursive
 automatic removals.
 
 This issue is currently tracked as #734396.
 
 Auto-removals now listed on the PTS
 ===
 
 Thanks to the work of Ivo De Decker and Paul Wise, the PTS will now
 display a warning for packages that are about to be auto-removed from
 testing.

I still need to blog about this, but there are two other means
that could qualify as push-notification for planned removals:

 * Debian Maintainer Dashboard (http://udd.debian.org/dmd/) lists
   them in the TO-DO section, and provides an RSS feed.

 * how-can-i-help lists them (for locally installed packages, but it's
   possible to provide a list of additional packages to monitor). Run
   it in cron if you want to get emails. (see the man page)

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140130082016.gb13...@xanadu.blop.info

Re: Bits from the Release Team: Architecture health check

[Thijs Kinkhorst]

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 two wheezy; installing the 3.11 kernel from backports resolved
the issue.


Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/7190f22bb241d6403daac29922f4b1ae.squir...@aphrodite.kinkhorst.nl

Re: Bits from the Release Team: Architecture health check

[Yaroslav Halchenko]

On Wed, 29 Jan 2014, Niels Thykier wrote:
  * sparc
- We have seen no improvements.  Therefore, out of date
  binaries on sparc will no longer prevent packages from 
  migrating to testing and Britney will be allowed to break
  existing packages in testing on sparc.
- We will review sparc again in about 2 months; should porters
  have stepped up and resolved the concerns we had about sparc
  we will consider undoing this change.  Otherwise, we will
  remove sparc from testing as well.

FWIW -- from my pragmatic PoV -- quite a few times the problems with
FTBFS unittests on sparc were legit bugs which were not exercised by
unittests on more popular architectures (who would test all possible
boundary conditions, right? ;-)).  That would be pity if sparc
goes away :-/

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140130024948.gu5...@onerussian.com

Re: Bits from the Release Team: Architecture health check

[Niels Thykier]

On 2014-01-30 03:49, Yaroslav Halchenko wrote:
 
 On Wed, 29 Jan 2014, Niels Thykier wrote:
  * sparc
- We have seen no improvements.  Therefore, out of date
  binaries on sparc will no longer prevent packages from 
  migrating to testing and Britney will be allowed to break
  existing packages in testing on sparc.
- We will review sparc again in about 2 months; should porters
  have stepped up and resolved the concerns we had about sparc
  we will consider undoing this change.  Otherwise, we will
  remove sparc from testing as well.
 
 FWIW -- from my pragmatic PoV -- quite a few times the problems with
 FTBFS unittests on sparc were legit bugs which were not exercised by
 unittests on more popular architectures (who would test all possible
 boundary conditions, right? ;-)).

Hi,

Indeed, that is great when architectures catch legitimate bugs and there
are porters to help fix them (or, at least, cluebat maintainers into
fixing them).  But when there are no active porters, the port becomes a
chain that drags us down.
  For the record, we (sort of) have a similar problem with poorly
maintained packages - but there we can at least setup an automated
system to remove most of the problems for us.

 That would be pity if sparc goes away :-/
 

If you feel that way, I recommend that you (bribe someone to) help the
port.  At the current time, there are two major issues with sparc.

 * Make gcc-defaults use at least gcc-4.8 as default compiler.
   - Of course, this presumes that gcc-4.8 works on sparc and does not
 horribly break all builds on the architecture.
 * Have the sparc kernels in stable fixed
   - Currently, DSA are forced to use kernels from oldstable.  Probably
 anyone using sparc/Wheezy are forced to that, but so far we only
 heard complaints from DSA[1].
   - Even if you don't care for sparc in testing, this problem affects
 our ability to support sparc in stable.
   - To be honest, I am impressed DSA haven't just yelled We veto
 sparc for Jessie until the stable kernels are fixed.

But until that happens, sparc in testing will slowly degrade - so I
recommend you decide and act quickly.


Let it be no secret: If there is no visible progress on salvaging sparc
in the next two months (like there wasn't for ia64 or sparc in the past
two), then I will most likely be on the side encouraging the removal of
sparc from testing.

~Niels

[1] I forgot the actual details of why it is broken.  I believe it was
something down the lines of doesn't boot at all.  Anyway, I am sure
the DSA can remind me on that if needed be.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e9f788.3040...@thykier.net

Re: Bits from the Release Team: Architecture health check

[Tollef Fog Heen]

]] Niels Thykier 

- To be honest, I am impressed DSA haven't just yelled We veto
  sparc for Jessie until the stable kernels are fixed.

Apart from the yelling bit, I believe that's basically what we've done.

[...]

 Let it be no secret: If there is no visible progress on salvaging
 sparc in the next two months (like there wasn't for ia64 or sparc in
 the past two), then I will most likely be on the side encouraging the
 removal of sparc from testing.

Also, arches not in testing don't get stable releases, which means
they're likely to lose buildds and porter boxes once oldstable is no
longer supported. We don't want to run testing or unstable on those
machines for obvious reasons.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ha8m2aua@qurzaw.varnish-software.com

Re: Bits from the Release Team: Architecture health check

[Peter Palfrader]

On Thu, 30 Jan 2014, Niels Thykier wrote:

  * Have the sparc kernels in stable fixed
- Currently, DSA are forced to use kernels from oldstable.  Probably
  anyone using sparc/Wheezy are forced to that, but so far we only
  heard complaints from DSA[1].

 [1] I forgot the actual details of why it is broken.  I believe it was
 something down the lines of doesn't boot at all.  Anyway, I am sure
 the DSA can remind me on that if needed be.

No, that was ia64 on our mckinley systems.

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.

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140130072048.gq3...@anguilla.noreply.org

Re: Bits from the release team (freeze time line)

[Russ Allbery]

Niels Thykier ni...@thykier.net writes:

 Britney changes
 ===

 We have deployed a change in Britney that causes her to pay more
 attention to essential packages.  In particular, all packages now have
 to be co-installable with the essential set.  Previously, a package
 could conflict with a essential package.  It would still be considered
 installable by Britney as long as the transitive dependency closure of
 the package did not (explicitly) require the essential package it
 conflicted with.

This has implications for upstart, doesn't it?  It still conflicts with
sysvinit, which is essential.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sitf7an3@windlord.stanford.edu

Re: Bits from the release team (freeze time line)

[Josh Triplett]

On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote:
 Britney changes
 ===
 
 We have deployed a change in Britney that causes her to pay more
 attention to essential packages.  In particular, all packages now have
 to be co-installable with the essential set.  Previously, a package
 could conflict with a essential package.  It would still be considered
 installable by Britney as long as the transitive dependency closure of
 the package did not (explicitly) require the essential package it
 conflicted with.

Here's the complete list of packages in latest unstable that would
violate this new criterion:

~$ aptitude search '?conflicts(?essential)'
p   systemd-sysv- system and service manager - SysV links
p   upstart - event-based init daemon

This new criterion would seem to make life difficult for the maintainers
of these and other potential future alternatives to the current set of
essential packages.

In addition to the small mountain of discussion ongoing about init
system defaults, there has also been some discussion on the specific
topic of this conflict (specifially, whether the package named
sysvinit should drop the Essential flag, or whether it should become a
metapackage depending on multiple alternative providers of /sbin/init).
The latter discussion unfortunately seems to have been deferred in favor
of the former.

Perhaps, in light of the pending tech-ctte decision of doom, it might
make sense to defer enabling this new criterion until at least that
point, to ensure that the maintainers of these two packages can continue
to maintain them and provide upgraded versions?  (To the extent other
external factors have not already prevented proper maintenance of those
packages, such as the unmodified packaging of new upstream versions with
useful new features.)

Or, will there be a testing migration exception for packages which
already exist in testing, which both of these do?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131226182342.GA5655@leaf

Re: Bits from the release team (freeze time line)

[Steve Langasek]

On Thu, Dec 26, 2013 at 10:03:12AM -0800, Russ Allbery wrote:
 Niels Thykier ni...@thykier.net writes:

  We have deployed a change in Britney that causes her to pay more
  attention to essential packages.  In particular, all packages now have
  to be co-installable with the essential set.  Previously, a package
  could conflict with a essential package.  It would still be considered
  installable by Britney as long as the transitive dependency closure of
  the package did not (explicitly) require the essential package it
  conflicted with.

 This has implications for upstart, doesn't it?  It still conflicts with
 sysvinit, which is essential.

On Thu, Dec 26, 2013 at 10:23:42AM -0800, Josh Triplett wrote:

 Here's the complete list of packages in latest unstable that would
 violate this new criterion:

 ~$ aptitude search '?conflicts(?essential)'
 p   systemd-sysv- system and service manager - SysV links
 p   upstart - event-based init daemon

 This new criterion would seem to make life difficult for the maintainers
 of these and other potential future alternatives to the current set of
 essential packages.

Well, the fix is known; I was waiting for feedback on
http://lists.debian.org/debian-devel/2013/11/msg00389.html before
uploading, but there hasn't been any except for ratholing about openrc. 
I'll go ahead and upload the fixed sysvinit to NEW today.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature