Processed: Re: Bug#1031376: tzdata 2022g-3 removed /etc/timezone without a proper transition, breaking multiple packages

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1031376 [release.debian.org] tzdata 2022g-3 removed /etc/timezone without 
a proper transition, breaking multiple packages
Ignoring request to alter tags of bug #1031376 to the same tags previously set
> severity -1 normal
Bug #1031376 [release.debian.org] tzdata 2022g-3 removed /etc/timezone without 
a proper transition, breaking multiple packages
Ignoring request to change severity of Bug 1031376 to the same value.

-- 
1031376: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031376
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#1031376: tzdata 2022g-3 removed /etc/timezone without a proper transition, breaking multiple packages

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1031376 [release.debian.org] tzdata 2022g-3 removed /etc/timezone without 
a proper transition, breaking multiple packages
Added tag(s) moreinfo.
> severity -1 normal
Bug #1031376 [release.debian.org] tzdata 2022g-3 removed /etc/timezone without 
a proper transition, breaking multiple packages
Severity set to 'normal' from 'important'

-- 
1031376: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031376
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031376: tzdata 2022g-3 removed /etc/timezone without a proper transition, breaking multiple packages

[Paul Gevers]

Control: tags -1 moreinfo
Control: severity -1 normal

Hi Daniel,

On 16-02-2023 01:11, Daniel Leidert wrote:

I ask you to
find a reasonable approach to deal with this for the Bookworm release.


That's not how we normally work. Please come with concrete proposals and 
we can evaluate them.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Russ Allbery]

"Theodore Ts'o"  writes:
> On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote:

>> You argue about shared libraries for non-packaged binaries.  I think we
>> mostly don't care about that, and again, I think that's at least a
>> generally recognized thing that came out of our focus on packages and
>> package dependencies.

> Note that package dependencies doesn't allow a binary created on Debian
> N to work on Debian N-1.  It just *prevents* the package from being
> installed on Debian N-1.  If you care about allowing the package to be
> instaslled on Debian N-1, that's what build chroots are for.  That's how
> we create packages for backports, after all.

> I'm making a similar argument for mkfs and bootable images for older
> distributions.  Just as you use a build chroot when you build a package
> for Debian N-1, you should use a chroot when building a bootable image
> for Debian N-1.  And that means using the chroot for *everything*; not
> just installing the grub bootloader, but also running mkfs.

Regardless of which analogy feels more correct here, the reality on the
ground is that using a current mke2fs to create file systems for older
Debian versions, unlike running new binaries on old systems, is something
that used to work.  People have been doing that and relied on it working.
We've made a change that broke it.  That change has benefits and
justifications as all changes do, but from the perspective of the people
with that use case, it's a regression.  So we should either document it or
revert it, and I think the debate is over which of those two to do.
Ideally we do this with an eye to what reduces this problem in the future.

It had never occurred to me before that the version of the system on which
I run mke2fs would matter as long as I didn't pick a newer file system
type (ext5 or something).  Now I know!  Until today, I had no idea ext4
even *had* "incompat" features or that mke2fs could make file systems that
grub couldn't understand.  I'm sure this is well-documented in the ext4
world (although ext4(5) could both be advertised a bit more prominently
and be more explicit about this problem, IMO).  I'd just never had any
reason to seek out that documentation, since creating file systems with
the defaults has always just worked for me.

In that sense, it's a testament to the maintenance quality of ext4, but
the result of mke2fs just working all these years is that most users do
not read the details of the ext4 man page since they've never needed to.
That would make me lean towards making documentation a large part of the
solution here.  I'm sure I'm not alone in having no idea that the version
or configuration of mk2efs mattered at this level unless I'd changed the
defaults.  It seems like we'd save people a lot of future trouble if we
could find ways to communicate to system constructors that the file system
needs to be built from a chroot.

In other words, if this is a compatibility rule that is important when
using these tools, it needs to be WAY more prominently documented than it
is right now.  That that feels more important to me than adding a
one-release backward-compatibility guarantee.  A lot of environments
regularly use oldstable or even oldoldstable for specific applications, so
we'd still break people's use cases if they don't know about the need to
build file systems from a chroot.  Given that this will presumably happen
again in the future since it's apparently a normal part of ext4
development, it's not a one-time problem and it's something that we
somehow have to communicate to users to avoid ongoing fragility.

It feels to me (not a release team member!) like the strongest argument
for making a change other than documentation is the proximity to the
release at which the change was made (which is indeed quite late in the
release process for this critical of a component of the operating system).
But I'm also not sure that matters to most of our users?  I think most
users are only going to care when stable is released; people doing
production work on unstable or testing already know that they're signing
up for occasional breakage.  So the proximity-to-release argument to me
feels most relevant if this change is specifically a problem for the
release process and would hold up things Debian itself needs to do, due to
(for example) it being difficult to change tooling so that file systems
are generated from a chroot.  I have no idea if that's the case.

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

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote:
> 
> You argue about shared libraries for non-packaged binaries.
> I think we mostly don't care about that, and again, I think that's at
> least a generally recognized thing that came out of our focus on
> packages and package dependencies.

Note that package dependencies doesn't allow a binary created on
Debian N to work on Debian N-1.  It just *prevents* the package from
being installed on Debian N-1.  If you care about allowing the package
to be instaslled on Debian N-1, that's what build chroots are for.
That's how we create packages for backports, after all.

I'm making a similar argument for mkfs and bootable images for older
distributions.  Just as you use a build chroot when you build a
package for Debian N-1, you should use a chroot when building a
bootable image for Debian N-1.  And that means using the chroot for
*everything*; not just installing the grub bootloader, but also
running mkfs.

(Note that using the sid grub bootloader while using the sid's
mkfs.ext4 would work in this particular case, but if you want a pure
"Bullseye" image which is identical to what running the Bullseye d-i
would create, then you should run Bullseye's mkfs, not sid's mkfs.)

  - Ted

Bug#1031376: tzdata 2022g-3 removed /etc/timezone without a proper transition, breaking multiple packages

[Daniel Leidert]

Package: release.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

A recent upload of tzdata [1] removes the file /etc/timezone from user's
computers. This broke multiple packages of the ruby-team (samizdat and
ruby-et-orbi being two of them). A quick search on codesearch.d.o [2] for the
usage of the file reveals more packages that are likely affected. While the
change itself is not unreasnable, it has a bad timing, and since it went
unannounced, multiple package require fixing now for Bookworm. I ask you to
find a reasonable approach to deal with this for the Bookworm release.

[1] 
https://tracker.debian.org/news/1418475/accepted-tzdata-2022g-3-source-into-unstable/
[2] https://codesearch.debian.net/search?q=%2Fetc%2Ftimezone=1

Regards, Daniel

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPtdMMACgkQS80FZ8KW
0F11txAAxzQK/ackamzXJT8RChyY+EurntwQaMCuS6GzgVV/cdHEklSUzT51XAWk
Su4C3umDtcjmBQgMNqP94umV/Xp32zHJboVxC1RDmjxcK0CoWlgVNiCtNOO7K/sm
3t+oIMlsIsFbjxsJaCKuW1Q7Ob+ebJ9cEUI7y59zt0hWKxtgeqBeDbrgyuwguW/y
THigG9PnF4ObosO8HV8EgvdREl5GjynYALLlEv1quWX9lc6JKgt8uTW8+txjsE0o
jRiz7iXxHZdPwnVV10WFZM3MXO5Nbibe0YDd4lRIqBC58owE8KmeDv3eDpdl5vyA
CLBDlFUyq5gysgpte7veN0OMUh0HCL5akFc1EBda6xwI5+PqehQoULaTKvmSZ25A
HcY15c6eLJ+qPVYWZC7XFsnYH9ETOtRhkiuKEOxuVsKq+dwgaX1PYQiSo/OHqmXF
cOQQ7R0Mwc6CNnDVVbFHerUdS8Ur42MRm7OkaFfoBP/qkIBjjNBxlMgmkuV0GZw6
pLkTltK+ITooSXBh4307uo0qybq6QesE81NEbMGAB94yTSi1YIn0yXikd1JT2PYR
tdvxn9z1X6ssmAUSiy9y9q6wFqv/GTTGSXe33ieRGah11OD+oP1GcLx5ESo7W9Cz
IhHCX0nQxdS1EQbSnl6ZkM4ephqZ/41P4z+2MQLoHAJyBNNyMSo=
=ASWO
-END PGP SIGNATURE-

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Theodore" == Theodore Ts'o  writes:

Theodore> On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>> 
>> I.E. I think your question of "for how long" has a very simple
>> answer based on our history: if we care about stability in this
>> instance it's for +/-1 Debian release.
>> 
>> I'm struggling trying to figure out whether we should commit to
>> that stability.

Theodore> I recogniuze that there are precedents that go in both
Theodore> directions.  We have *never* required that shared library
Theodore> linkages created in Debian N work in Debian N-1.  Sure,
Theodore> there are workarounds that you can use (e.g., compiling
Theodore> with -static), but I've listed workarounds for mke2fs as
Theodore> well.

For what it's worth, I don't think the shared library situation is at
all analogous.
We've basically decided that we care about shared libraries as they
interact with packages, and we've invented a whole bunch of dependency
logic to deal with them.
Which is to say we've explicitly turned shared libraries into a special
case.

You argue about shared libraries for non-packaged binaries.
I think we mostly don't care about that, and again, I think that's at
least a generally recognized thing that came out of our focus on
packages and package dependencies.

Which is to say that I think shared libraries are such a special case in
Debian you cannot use them to argue for or against anything else.

You make some good arguments based on other things.  I just don't want
us using shared library handling as a precedent for anything other than
shared libraries, so I am arguing against it.

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
> 
> I.E. I think your question of "for how long" has a very simple answer
> based on our history: if we care about stability in this instance it's
> for +/-1 Debian release.
> 
> I'm struggling trying to figure out whether we should commit to that
> stability.

I recogniuze that there are precedents that go in both directions.  We
have *never* required that shared library linkages created in Debian N
work in Debian N-1.  Sure, there are workarounds that you can use
(e.g., compiling with -static), but I've listed workarounds for mke2fs
as well.

In other cases, we may have gone out of our way to provide these sorts
of transitions.

> I also think it would be reasonable for the project to decide we care
> about this stability, and that we want bullseye grub to work with a
> filesystem made on sid.

Well, I agree that it's a Distribution level decision.  And if the
distribution decides that we should acccomodate this particular case
case, we can certainly make a Debian-specific change to the
/etc/mke2fs.conf config file which doesn't enable metadata_csum_seed
by default.

> I understand you do not support that stability decision.

The argument I would make is that it is a case by case decision, and
not a global one where *all* all generated objects created by Debian N
have to work in Debian N-1.  For example, this is most manifestly
*not* true for any shared library compiled by default that uses glibc.
And I don't personally consider vmdb2 to be important enough to be
worth this kind of solicitude when we haven't done it for shared
library lankage --- just based on the popcon statistics if nothing
else.

But, if the release team belives that a note in the release notes is
not sufficient, I can certainly change the default for Debian.  The
*reason* why the default features can be configured in
/etc/mke2fs.conf is because distributions or individual users might
want to make different decisions about the defaults than the upstream
maintainer of e2fsprogs.  So I'll certainly abide by the ruling of the
release team in this matter, and I guess if Daniel doesn't like the
decision they make, he can always appeal this to the Debian TC.

The appeal chain on this one seems pretty clear.  As the Debian
maintainer for the e2fsprogs package; I have my opinion on how this
can be resolved.  Daniel has appelaed this to release team, and if
necessary, he can appeal to the Technical Committee, and he can ever
try to organize a Debian GR if he feels so strongly about the issue.

Given that there are some *very* easy workarounds, which I have
listed, just as there are simple workarounds for creating a binary for
Bookworm that will work for Bullseye, I really do believe this is a
tempest in a teacup.

Best regards,

- Ted

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Theodore" == Theodore Ts'o  writes:
 the answer to your "how long" is that packages
>> should also work with the kernel from the previous and the kernel
>> from the next Debian release.

Theodore> This isn't a problem with the kernel.

I don't think that was Adrian's point.
I think Adrian was making an analogy and suggesting that filesystems
made by bookworm should be usable by bullseye and by the release after
bookworm--usable by the bootloaders etc.
Or at least that would be a reasonable thing to do based on stability
guarantees we've made in other cases.

I.E. I think your question of "for how long" has a very simple answer
based on our history: if we care about stability in this instance it's
for +/-1 Debian release.

I'm struggling trying to figure out whether we should commit to that
stability.
I do find this change after the transition freeze to be kind of late.  I
understand it's not a traditional transition.
But for example you're not leaving a lot of time for asking programs
like vmdb2 or fai-diskimage to adjust how they call fsck.
If you made this change a few months ago, it would be reasonable to file
bugs against those packages and ask them to adjust how they call
mkfs.ext4.

I want to stress that I'm not  affiliated with the release team; my
opinion here has no official weight.
But I would ask you to consider that it is kind of late to make  a
change in the required filesystem features for bookworm and suggest a
more orderly process would be to make the change in the next release and
give packages that need to build vm images a chance to adjust.

I also think it would be reasonable for the project to decide we care
about this stability, and that we want bullseye grub to work with a
filesystem made on sid.
I understand you do not support that stability decision.


signature.asc
Description: PGP signature

Bug#1031361: marked as done (unblock: grub2/2.06-8)

[Debian Bug Tracking System]

Your message dated Wed, 15 Feb 2023 19:16:18 +0100
with message-id 
and subject line Re: Bug#1031361: unblock: grub2/2.06-8
has caused the Debian Bug report #1031361,
regarding unblock: grub2/2.06-8
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hey folks!

Please unblock package grub2

We have a slew of bug fixes that we want in bookworm:

  * Fix an issue in an f2fs security fix which caused mount
failures. Closes: #1021846. Thanks to программист некто for helping
to debug the problem!
  * Switch build-deps from gcc-10 to gcc-12. Closes: #1022184
  * Include upstream patch to enable EFI zboot support on arm64.
Closes: #1026092
  * grub-mkconfig: Restore umask for the grub.cfg. CVE-2021-3981
Closes: #1001414
  * postinst: be more verbose when using grub-install to install onto
devices.
  * /etc/default/grub: Fix comment about text-mode console.
Fixes #845683
  * grub-install: Don't install the shim fallback program when called
with --removable. Closes: #1016737
  * grub-install: Don't use our grub CD EFI image for --removable.
Closes: #1026915. Thanks to Pascal Hambourg for the patch.
  * Ignore some new ext2 flags to stay compatible with latest mke2fs
defaults. Closes: #1030846

Several of these are major issues for people affected, particularly
#1030846. We'd like to get the new version in to work with the next
d-i release please. Kibi is already aware!

unblock grub2/2.06-8
--- End Message ---
--- Begin Message ---
On 2023-02-15 17:16:46 +, Steve McIntyre wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hey folks!
> 
> Please unblock package grub2
> 
> We have a slew of bug fixes that we want in bookworm:
> 
>   * Fix an issue in an f2fs security fix which caused mount
> failures. Closes: #1021846. Thanks to программист некто for helping
> to debug the problem!
>   * Switch build-deps from gcc-10 to gcc-12. Closes: #1022184
>   * Include upstream patch to enable EFI zboot support on arm64.
> Closes: #1026092
>   * grub-mkconfig: Restore umask for the grub.cfg. CVE-2021-3981
> Closes: #1001414
>   * postinst: be more verbose when using grub-install to install onto
> devices.
>   * /etc/default/grub: Fix comment about text-mode console.
> Fixes #845683
>   * grub-install: Don't install the shim fallback program when called
> with --removable. Closes: #1016737
>   * grub-install: Don't use our grub CD EFI image for --removable.
> Closes: #1026915. Thanks to Pascal Hambourg for the patch.
>   * Ignore some new ext2 flags to stay compatible with latest mke2fs
> defaults. Closes: #1030846
> 
> Several of these are major issues for people affected, particularly
> #1030846. We'd like to get the new version in to work with the next
> d-i release please. Kibi is already aware!

Thanks for the 3 RC bug fixes. It should migrate in the next migration
run.

Cheers
-- 
Sebastian Ramacher--- End Message ---

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Wed, Feb 15, 2023 at 11:47:08AM +0200, Adrian Bunk wrote:
> 
> For normal library dependencies
>   Depends: libc6 (>= 2.34)
> will do the right thing automatically.

Sure, but dependencies only apply if you are using building packages.
If you are not building packages, but just moving binaries between
distribution versions --- which is analogous to what is going on here
when someone moves a file system from one distro version to another.
For example:

% echo 'int main() { printf("Hello, world\n"); return 0; }' > /tmp/foo.c ; gcc 
-w -o /tmp/foo /tmp/foo.c ; /tmp/foo ; schroot -c bullseye-amd64 /tmp/foo
Hello, world
/tmp/foo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found 
(required by /tmp/foo)

> e2fsprogs adding Breaks against older versions of bootloaders and other 
> software that lacks support for the new default might be a good idea.
> 
> The situtation is different when a relationship cannot be reliably 
> expressed by package dependencies.

Unfortunately, package dependencies won't address the concern raised
by Daniel.  The mkfs.ext4, debootstrap, etc., are being run on a one
version of the distro, such as for example sid or Bookworm, but then
when the grub bootloader is installed --- presumably in a chroot, so
that you get the Bullseye grub on a Bullseye VM image --- it won't
know that the base file system was built on Sid or Bookworm.  Of
course, if you run the mkfs.ext4 in a Bullseye chroot, everything will
work *just* *fine*.  It's just that this isn't Daniel's workflow.

> For the kernel the answer to your "how long" is that packages should 
> also work with the kernel from the previous and the kernel from the
> next Debian release.

This isn't a problem with the kernel.  For the ext4 feature that
Daniel cited, metadata_csum_seed was first supported in 4.4 kernel
(note that Debian *stretch* used the 4.9 kernel and 4.4 was first
released in 2016 --- six years ago).  On the file system utility side,
e2fsprogs 1.43 also support for metadata_csum_seed (again, support
going back to stretch).

The xfs bigtime feature, which was similarly enabled in Bookworm, was
supported in the kernel the xfsprogs for **many** years.  In general,
file system developers do understand the concern of needing to wait
before enabling a feature by default in mke2fs.conf.

The issue here is in grub support.  Part of the issue is that
admittedly, file system developers don't worry as much about
bootloaders as much as we do for kernels and the file system
utilities.  The other is that the grub2 upstream simply hasn't been as
responsive or quick at doing releases.  The fix landed in grub2
upstream in June of 2021.  So all distributions tend to carry large
number of grub2 cherry-picks.

> If the feature stays enabled by default in bookworm:
> Everyone using grub is an x86 thing, for embedded ARM it is more common 
> to use a once ported ancient u-boot on your hardware forever.[1]
> A bug against the release-notes pseudo-package with text describing
> the incompatibility and possible workarounds would be appreciated.

Would you prefer that we repurpose (and retitle) this bug, or open a
new one?

Here's a quick rough draft of what that text might look like, at least
for the ext4 metadata_csum_seed.  (If it's helpful, I can try to also
write a blurb for XFS, although I'd want to run it by the XFS kernel
maintainer, Darrick Wong first.)

 cut here ---

In the Bookworm release, the mkfs.ext4 will enable the orphan_file and
metadata_csum_seed feature.  The orphan_file feature significantly
improves performance for workloads which are truncated or deleting
files in parallel.  The orphan_file feature is an ext4 "compat"
feature, so file systems with the orphan_file feature can be mounted
on older kernels who do not understand the orphan_file feature, so
long as the file system was cleanly unmounted.  If the file system was
not cleanly unmounted (for example, due to a crash or power failure),
the file system must be fsck'ed or mounted on a Bookworm system before
the file system is transferred to an older system.

The metadata_csum_seed feature allows the file system UUID to
be modified without needing to update all of the file system metadata,
which is often important in VM context where root file systems are
cloned from read-only images, and having unique UUID's is important to
avoid confusion when the block device might be mounted on another
whose root file system is similarly cloned from the same base image.

The metadata_csum_seed feature is an ext4 "incompat" feature, which
means that the kernel must understand the feature before it will be
able mount a file system with that feature.  Fortunately, the Linux
kernels starting with 4.4 (and the Debian 9.0 "stretch" release)
support the metadata_csum_seed feature.  So data disks formatted with
metadata_csum_seed can be mounted on systems with older distro
versions without concerns in nearly all case.

Unfortunately, grub2 support for the metadata_csum_seed 

Bug#1031361: unblock: grub2/2.06-8

[Steve McIntyre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hey folks!

Please unblock package grub2

We have a slew of bug fixes that we want in bookworm:

  * Fix an issue in an f2fs security fix which caused mount
failures. Closes: #1021846. Thanks to программист некто for helping
to debug the problem!
  * Switch build-deps from gcc-10 to gcc-12. Closes: #1022184
  * Include upstream patch to enable EFI zboot support on arm64.
Closes: #1026092
  * grub-mkconfig: Restore umask for the grub.cfg. CVE-2021-3981
Closes: #1001414
  * postinst: be more verbose when using grub-install to install onto
devices.
  * /etc/default/grub: Fix comment about text-mode console.
Fixes #845683
  * grub-install: Don't install the shim fallback program when called
with --removable. Closes: #1016737
  * grub-install: Don't use our grub CD EFI image for --removable.
Closes: #1026915. Thanks to Pascal Hambourg for the patch.
  * Ignore some new ext2 flags to stay compatible with latest mke2fs
defaults. Closes: #1030846

Several of these are major issues for people affected, particularly
#1030846. We'd like to get the new version in to work with the next
d-i release please. Kibi is already aware!

unblock grub2/2.06-8

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Shengjing Zhu]

On Wed, Feb 15, 2023 at 9:23 PM Adrian Bunk  wrote:
> > And regarding make golang-go the first alternative, currently we have:
> > + Build-Depends golang-any | golang-go | gccgo
> > + golang-any Depends golang-go | gccgo-go
> > Is there anything we can improve for aspcud resolver?
>
> The resolver is not to blame for a bug in the build dependencies.
>
> In unstable and experimental only the first alternative is considered,
> therefore
>   Build-Depends: golang-go | ...
> would instruct the resolver to install golang-go.
>
> Safest would be to not offer any alternatives in the build dependencies,
> instead create a profile for bootstrapping golang-go from gccgo.

I now created #1031351, which I think is the underlying problem.
Let's keep discussion there and reduce the noise in this unblock request.

-- 
Shengjing Zhu

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Adrian Bunk]

On Wed, Feb 15, 2023 at 09:05:28PM +0800, Shengjing Zhu wrote:
> On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu  wrote:
> >
> > On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> > >
> > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > > >...
> > > > The package currently FTBFS on i386/experimental but it won't be 
> > > > problem on
> > > > unstable.
> > > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > > which has a bug https://github.com/golang/go/issues/51850.
> > > > But on unstable the dep-resolver is apt, and will choose old golang-go 
> > > > to
> > > > bootstrap.
> > > >...
> > >
> > > I gave it back on the affected architectures with an extra-depends on
> > > golang-go, which confirmed that the package builds there.
> > >
> > > But relying on resolver behaviour is incredibly fragile, please make
> > > golang-go the only (or at least the first) alternative in the build
> > > dependencies.
> >
> > In theory gccgo should be able to bootstrap golang-go.
> > And we do use gccgo to build golang-go on ppc64, and haven't met any
> > problem so far.
> > The new affected arch is because of lack of exercise, so nobody is
> > aware of this.
> > Now they are tracked at #1031349.
> >
> 
> And regarding make golang-go the first alternative, currently we have:
> + Build-Depends golang-any | golang-go | gccgo
> + golang-any Depends golang-go | gccgo-go
> Is there anything we can improve for aspcud resolver?

The resolver is not to blame for a bug in the build dependencies.

In unstable and experimental only the first alternative is considered,
therefore
  Build-Depends: golang-go | ...
would instruct the resolver to install golang-go.

Safest would be to not offer any alternatives in the build dependencies,
instead create a profile for bootstrapping golang-go from gccgo.

> Shengjing Zhu

cu
Adrian

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Adrian Bunk]

On Wed, Feb 15, 2023 at 08:53:13PM +0800, Shengjing Zhu wrote:
> On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> >
> > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > >...
> > > The package currently FTBFS on i386/experimental but it won't be problem 
> > > on
> > > unstable.
> > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > which has a bug https://github.com/golang/go/issues/51850.
> > > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > > bootstrap.
> > >...
> >
> > I gave it back on the affected architectures with an extra-depends on
> > golang-go, which confirmed that the package builds there.
> >
> > But relying on resolver behaviour is incredibly fragile, please make
> > golang-go the only (or at least the first) alternative in the build
> > dependencies.
> 
> In theory gccgo should be able to bootstrap golang-go.
>...

That misses my point, which is that when there are several options
the package should define and ensure which one is used.

Every buildd and every QA build and every build elsewhere should use the 
same tools for building the package.

Otherwise people might end up wasting hours and days trying to 
understand why a package that built in unstable failed to build
somewhere else (in experimental or reproducible builds or in
a derivative distribution or elsewhere).

Or even worse, if for some reason the package builds but produces 
different binaries and then someone tries to debug why this happened.
That shouldn't happen, but these are absolutely nasty and time-consuming
bugs.

> Shengjing Zhu

cu
Adrian

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Shengjing Zhu]

On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu  wrote:
>
> On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> >
> > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > >...
> > > The package currently FTBFS on i386/experimental but it won't be problem 
> > > on
> > > unstable.
> > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > which has a bug https://github.com/golang/go/issues/51850.
> > > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > > bootstrap.
> > >...
> >
> > I gave it back on the affected architectures with an extra-depends on
> > golang-go, which confirmed that the package builds there.
> >
> > But relying on resolver behaviour is incredibly fragile, please make
> > golang-go the only (or at least the first) alternative in the build
> > dependencies.
>
> In theory gccgo should be able to bootstrap golang-go.
> And we do use gccgo to build golang-go on ppc64, and haven't met any
> problem so far.
> The new affected arch is because of lack of exercise, so nobody is
> aware of this.
> Now they are tracked at #1031349.
>

And regarding make golang-go the first alternative, currently we have:
+ Build-Depends golang-any | golang-go | gccgo
+ golang-any Depends golang-go | gccgo-go
Is there anything we can improve for aspcud resolver?

-- 
Shengjing Zhu

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Shengjing Zhu]

On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
>
> On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> >...
> > The package currently FTBFS on i386/experimental but it won't be problem on
> > unstable.
> > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > which has a bug https://github.com/golang/go/issues/51850.
> > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > bootstrap.
> >...
>
> I gave it back on the affected architectures with an extra-depends on
> golang-go, which confirmed that the package builds there.
>
> But relying on resolver behaviour is incredibly fragile, please make
> golang-go the only (or at least the first) alternative in the build
> dependencies.

In theory gccgo should be able to bootstrap golang-go.
And we do use gccgo to build golang-go on ppc64, and haven't met any
problem so far.
The new affected arch is because of lack of exercise, so nobody is
aware of this.
Now they are tracked at #1031349.

--
Shengjing Zhu

Bug#1031339: marked as done (unblock: thunderbird/102.7.2-1)

[Debian Bug Tracking System]

Your message dated Wed, 15 Feb 2023 12:06:01 +
with message-id 
and subject line unblock thunderbird
has caused the Debian Bug report #1031339,
regarding unblock: thunderbird/102.7.2-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1031339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031339
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: thunderb...@packages.debian.org
Control: affects -1 + src:thunderbird

Please unblock package thunderbird

[ Reason ]
Due some planed traveling on my side I packaged the release candidate
for Thunderbird 102.7.1-1 before the real final release on Mozilla did
happen. I typically use the release candidate once it is available and
normally this works without problems, but not this time for 102.7.1.

Mozilla did encounter OAuth issues for user of O365 and did prepare a
new release candidate which I was not able to pick up directly.

This ended in an really delayed upload of the "fixed" Debian version
1:102.7.1+1-1 on 2023-02-07.
And shortly after my upload Mozilla released one more new version
102.7.2 which is now sitting unstable and due the date 12th February
migration time is extended to 10 days.

The next ESR version of Thunderbird (102.8.0) will get released today
but I wanted to see first the version 102.7.2-1 get migrated to tested
so users of testing do not need to wait even longer for a fixed version
of Thunderbird which is working again with O365 before I do a new upload
of the next ESR version.

[ Impact ]
Users in testing need to wait for a fixed Debian version for 

CVE-2023-0430: Revocation status of S/Mime signature certificates was
   not checked
(https://bugzilla.mozilla.org/show_bug.cgi?id=1810760)

[ Tests ]
I provided some testbuild for the real upstream version 102.7.1 before
started to upload the final version for the archive. Affected user
confirmed the fixed OAuth functionality.

[ Risks ]
There are no special risks as users confirmed the usability of the fixed
version in Debian.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]
Currently nothing to add here.

unblock thunderbird/102.7.2-1
--- End Message ---
--- Begin Message ---
Unblocked.--- End Message ---

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Adrian Bunk]

On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
>...
> The package currently FTBFS on i386/experimental but it won't be problem on
> unstable.
> The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> which has a bug https://github.com/golang/go/issues/51850.
> But on unstable the dep-resolver is apt, and will choose old golang-go to
> bootstrap.
>...

I gave it back on the affected architectures with an extra-depends on 
golang-go, which confirmed that the package builds there.

But relying on resolver behaviour is incredibly fragile, please make 
golang-go the only (or at least the first) alternative in the build 
dependencies.

cu
Adrian

Bug#1031339: unblock: thunderbird/102.7.2-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: thunderb...@packages.debian.org
Control: affects -1 + src:thunderbird

Please unblock package thunderbird

[ Reason ]
Due some planed traveling on my side I packaged the release candidate
for Thunderbird 102.7.1-1 before the real final release on Mozilla did
happen. I typically use the release candidate once it is available and
normally this works without problems, but not this time for 102.7.1.

Mozilla did encounter OAuth issues for user of O365 and did prepare a
new release candidate which I was not able to pick up directly.

This ended in an really delayed upload of the "fixed" Debian version
1:102.7.1+1-1 on 2023-02-07.
And shortly after my upload Mozilla released one more new version
102.7.2 which is now sitting unstable and due the date 12th February
migration time is extended to 10 days.

The next ESR version of Thunderbird (102.8.0) will get released today
but I wanted to see first the version 102.7.2-1 get migrated to tested
so users of testing do not need to wait even longer for a fixed version
of Thunderbird which is working again with O365 before I do a new upload
of the next ESR version.

[ Impact ]
Users in testing need to wait for a fixed Debian version for 

CVE-2023-0430: Revocation status of S/Mime signature certificates was
   not checked
(https://bugzilla.mozilla.org/show_bug.cgi?id=1810760)

[ Tests ]
I provided some testbuild for the real upstream version 102.7.1 before
started to upload the final version for the archive. Affected user
confirmed the fixed OAuth functionality.

[ Risks ]
There are no special risks as users confirmed the usability of the fixed
version in Debian.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]
Currently nothing to add here.

unblock thunderbird/102.7.2-1

Processed: unblock: thunderbird/102.7.2-1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:thunderbird
Bug #1031339 [release.debian.org] unblock: thunderbird/102.7.2-1
Added indication that 1031339 affects src:thunderbird

-- 
1031339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031339
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Tue, Feb 14, 2023 at 08:46:53PM -0500, Theodore Ts'o wrote:
>...
> I will draw the analogy of building a program which links against
> glibc for Bookworm resulting in a binary that will not run on Buster.
> We expect that, and we tell people to use build chroots.  This is not
> something which is actionable, and we don't hold back glibc updates
> just because you can no longer build on Debian 10.0 something that
> won't work on Debian 9.0, or 8.0.
>...
> We can change the default for mke2fs.conf file for Debian.  I don't
> think it's warranted, and I'm not aware of any other distribution
> doing this.  The fact that file system featuers that fix certain
> problems (such as the 2038 bug) will cause older versions the
> distribution to fail to accept that file system is always going to be
> the case.  So how long do we hold back some new feature?  A year?  Two
> years?  Five years?  Ten years?  Again, we don't do this with shared
> library linkages; we just tell people to use a build chroot.
>...
> So if we are to hold e2fsprogs and xfsprogs to the standard that a
> file system created by default must work on all older Debian and
> Ubuntu distributions to some arbitrary point in history,
>...

A rule of thumb is that any combination/mix of packages permitted by the 
package manager from two adjacent Debian releases should work whenever 
reasonably possible, since this reduces problems for our users during 
an upgrade, when using backports, or when temporarily going back to the 
version of a package from the previous stable due to a regression.

For normal library dependencies
  Depends: libc6 (>= 2.34)
will do the right thing automatically.

e2fsprogs adding Breaks against older versions of bootloaders and other 
software that lacks support for the new default might be a good idea.

The situtation is different when a relationship cannot be reliably 
expressed by package dependencies.

For the kernel the answer to your "how long" is that packages should 
also work with the kernel from the previous and the kernel from the
next Debian release.

Some time ago there was a discussion regarding Qt in Debian 10 using the
getrandom syscall that was not available in the kernel in Debian 8.
This was not considered supported (or supportable) since Debian 8 and
Debian 10 are not adjacent releases, but Qt in Debian 10 using a feature
not supported by the kernel in Debian 9 might have resulted in a lot of
problems when still running the old kernel during or after an upgrade
from Debian 9 to Debian 10.

If the feature stays enabled by default in bookworm:
Everyone using grub is an x86 thing, for embedded ARM it is more common 
to use a once ported ancient u-boot on your hardware forever.[1]
A bug against the release-notes pseudo-package with text describing
the incompatibility and possible workarounds would be appreciated.

> Best regards,
> 
>   - Ted

cu
Adrian

[1] u-boot in bullseye does already "support" metadata_csum_seed
by refusing to write to filesystems that have it enabled:

https://salsa.debian.org/debian/u-boot/-/commit/2e7365518acdb8fb6e9be332c8a6c57b457188d9