Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Ian Campbell]

(just the list, other cc'd dropped)

On Mon, 2021-04-12 at 19:35 +0200, Samuel Thibault wrote:
> Petter Reinholdtsen, le lun. 12 avril 2021 07:34:38 +0200, a ecrit:
> > Sad to hear the patch has been ignored for several years.
> 
> Please do not confuse "ignore" with "terribly understaffed".

I wonder if there is anything which a 3rd party could be found to do
via the Freexian project thing[0] which would reduce the overall burden
and free up some of the limited time contributors (of which I am long
lapsed :-() have? e.g. automate some time consuming manual work, setup
automated testing infra, that sort of thing?

Ian.

[0] https://salsa.debian.org/freexian-team/project-funding
 

Processing of debian-installer-netboot-images_20210415_source.changes

[Debian FTP Masters]

debian-installer-netboot-images_20210415_source.changes uploaded successfully 
to localhost
along with the files:
  debian-installer-netboot-images_20210415.dsc
  debian-installer-netboot-images_20210415.tar.xz
  debian-installer-netboot-images_20210415_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

debian-installer-netboot-images_20210415_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 15 Apr 2021 13:23:35 +0200
Source: debian-installer-netboot-images
Architecture: source
Version: 20210415
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Levsen 
Changes:
 debian-installer-netboot-images (20210415) unstable; urgency=medium
 .
   * Team upload.
   * Update for debian-installer 20210415 release.
Checksums-Sha1:
 a5ca2b527035f3a0d66d26f2801dfc47493b8742 2525 
debian-installer-netboot-images_20210415.dsc
 1092cd8132c10e9de1ca01d252e21fb04a9d2a76 7552 
debian-installer-netboot-images_20210415.tar.xz
 2e94b2c1be762c295ecad3a1ab106bf201533e53 5842 
debian-installer-netboot-images_20210415_source.buildinfo
Checksums-Sha256:
 78d64b79491ccfcc64113614a3af101272525f769d3cf0b4096d718bc3676451 2525 
debian-installer-netboot-images_20210415.dsc
 fb785d522204248a811e378c7e216a9d70e2f7ecec2fa9d156b1647d8238bc57 7552 
debian-installer-netboot-images_20210415.tar.xz
 16e1c89c94ebb2265e3865eecbdf4557f34c97f891a02e2734b76ca9feca689f 5842 
debian-installer-netboot-images_20210415_source.buildinfo
Files:
 44cb0751cc5a950b1bc6c8caa553d644 2525 misc optional 
debian-installer-netboot-images_20210415.dsc
 26ca8bf56e87530e50dd814c6f0b901a 7552 misc optional 
debian-installer-netboot-images_20210415.tar.xz
 05437386dbeac0e93c4c2ac1dfd899ba 5842 misc optional 
debian-installer-netboot-images_20210415_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmB5UFMACgkQCRq4Vgaa
qhymbw/9GiumYteCoNy+IYQOINXWUzleUXukg9BUKcTsUNwc0YG3EcdnOLeJ3GAZ
vssFdID0WxLT7T2xjk5P2ZMiN2kymG4UKTqimoqQvy7YrR9vb/N5weIITm2wPotr
MtPsHcxwD5PWmjdtiEKY0NfquoeDpW12iIS5MIP2OUOgXb/at8o9N9XK+Bo4hntK
6dawr8u1oTebWazzUocbKqt+rZfaEf5TncwtgOrkLXXjCYY3B5gGUYlIx0S5nVKg
zue1n0EIIOZHhf3zqHz83uh5GCbXgaDw03mRv0o95+2HcVp4LgrgZSP9GZy+Ghwu
6e6BtIt5z7HuO8Hm6Hl3zxB7s2sJHagTgqYBNFbqOP0Mpsf8Jxbi6qWs/QwIGyBK
vklGxDY6Ez+yE6q90fJBe1ZC/MpNkCjXdpjHnxTV64B6+SL2TJ9T3hZcj5G+a7Mx
AWOE1l9OKIQN7NdLHTsDq2bnJxrzma1x7OqRxsm7OV5rapYnqj2sCPS7eupRabQ2
wMe8p9xg2VcyLC0+Po3VlKnVT7HOp1LbfDeX/L2oP/RONpApKkwHdCUe5MFTsmtw
YN8SUqzj2B4aY/0vDmFuBUqah7IxMM/pce5ycONCv62LODFDgSKuA7qvSqjqAn6m
t8trhpauS5mS7K8FN9a1Z7BSyP2hb2W3wY6I9hDB/+AAgYe64mc=
=cNQe
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Bug#985956: Merge request submittted to initramfs-tools

[Ben Hutchings]

On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote:
> Hello,
> 
> Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:
> > Quite a few people are negatively affected by this bug, and one can expect a
> > lot more to be if Debian 11 goes to release without the inclusion of
> > mdio-bcm-unimac.ko in the netinst ARM64 ISOs.
> > 
> > I have created an initramfs-tools merge request to attempt to fix the
> > problem, which can be found at:
> > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46
> 
> AIUI initramfs-tools rules are not used to build the nic-modules
> udeb, it'd rather be happening in the linux package, in
> debian/installer/modules/nic-modules, which indeed doesn't include
> drivers/net/mdio/.
> 
> Linux maintainers, do you know more on this issue?

Yes that's correct.  This should be fixed in both initramfs-tools (for
normal system boot) and linux (for installation).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#985956: Merge request submittted to initramfs-tools

[Pete Batard]

On 2021.04.16 14:04, Ben Hutchings wrote:

On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote:

Hello,

Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:

Quite a few people are negatively affected by this bug, and one can expect a
lot more to be if Debian 11 goes to release without the inclusion of
mdio-bcm-unimac.ko in the netinst ARM64 ISOs.

I have created an initramfs-tools merge request to attempt to fix the
problem, which can be found at:
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46


AIUI initramfs-tools rules are not used to build the nic-modules
udeb, it'd rather be happening in the linux package, in
debian/installer/modules/nic-modules, which indeed doesn't include
drivers/net/mdio/.

Linux maintainers, do you know more on this issue?


Yes that's correct.  This should be fixed in both initramfs-tools (for
normal system boot) and linux (for installation).


I can try to submit a pull request for linux if needed, but I may need 
some guidance.


My take is that we want to add and explicit:

  CONFIG_MDIO_BCM_UNIMAC=m

to debian/config/arm64/config and add a:

  drivers/net/mdio/*

line to debian/installer/modules/nic-modules.

In other words, something like this patch:
https://salsa.debian.org/pbatard/linux/-/commit/855c728e4757bdcb4ceba054fc2b5b1da214b8ab

Does this approach look correct? Or do we need something different?

Regards,

/Pete

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Charles Curley]

On Fri, 16 Apr 2021 08:49:34 +0100
Ian Campbell  wrote:

> > 
> > Please do not confuse "ignore" with "terribly understaffed".  
> 
> I wonder if there is anything which a 3rd party could be found to do
> via the Freexian project thing[0] which would reduce the overall
> burden and free up some of the limited time contributors (of which I
> am long lapsed :-() have? e.g. automate some time consuming manual
> work, setup automated testing infra, that sort of thing?

Thanks for bringing this up.

I am a long time Debian user (Linux since 1993, Debian only for the
last decade or so). I have had little idea how things work in the
Debian community and am just beginning to explore it.

Along with Freexian, perhaps the occasional Call for Volunteers to get
specific things done would shake loose some volunteers? These could go
out on the various user-level mailing lists such as debian-user.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Processed: Tagging/merging #930684/#968927

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 968927 important
Bug #968927 [debootstrap] debootstrap in docker: may umount the docker 
instance's /proc
Severity set to 'important' from 'normal'
> merge 968927 930684
Bug #968927 [debootstrap] debootstrap in docker: may umount the docker 
instance's /proc
Bug #968927 [debootstrap] debootstrap in docker: may umount the docker 
instance's /proc
Marked as found in versions debootstrap/1.0.114.
Bug #930684 [debootstrap] pbuilder: creation of build env fails when run inside 
Docker container
Marked as found in versions debootstrap/1.0.123.
Merged 930684 968927
> tags 930684 +patch
Bug #930684 [debootstrap] pbuilder: creation of build env fails when run inside 
Docker container
Bug #968927 [debootstrap] debootstrap in docker: may umount the docker 
instance's /proc
Added tag(s) patch.
Added tag(s) patch.
> tags 930684 +pending
Bug #930684 [debootstrap] pbuilder: creation of build env fails when run inside 
Docker container
Bug #968927 [debootstrap] debootstrap in docker: may umount the docker 
instance's /proc
Added tag(s) pending.
Added tag(s) pending.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
930684: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930684
968927: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968927
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#985956: Merge request submittted to initramfs-tools

[Pete Batard]

I can try to submit a pull request for linux if needed, but I may need 
some guidance.


I'm going to drop trying to submit a pull request for the linux package 
for the time being, as I can't quite seem to manage to get the required 
process to insert CONFIG_MDIO_BCM_UNIMAC=m where it should appear.


Besides, I am not sure this is needed in the first place, since BMCGENET 
Kconfig should have MDIO_BCM_UNIMAC set by default 
(https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/broadcom/Kconfig#L78)


Thus, I'm going to leave people who are more familiar with Debian linux 
configuration with the action of ensuring that mdio-bcm-unimac.ko does 
get included in the install image.


Apologies for not being to being able to help further on this...

/Pete

Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

[Nicholas D Steeves]

Control: affects -1 release-notes

Hi Arnaud!

Adding src:docker.io maintainers and Shengjing Zhu (recent uploader) to
CC list.

Arnaud Rebillout  writes:

> Hello Nicholas! Thanks for your feedback here, see replies below.
>

You're welcome :-)

> On Sun, 11 Apr 2021 11:51:20 -0400 Nicholas D Steeves 
>  wrote:
>
>  > I'm not sure that systemd-detect-virt and your patch are
>  > forward-compatible in light of
[snip]
>  > This makes it sounds like ".dockerenv" may be deprecated and later
>  > removed.
>
> That's a good point, but it's also a 5 years old comment, and the 
> .dockerenv file is still present these days.
>
> I would think that if Docker plans to remove it, they will issue a more 
> formal deprecation warning that will give us enough time to fix things 
> on our side. Also the fact that systemd checks for this file gives me 
> more confidence that it's not just me doing something fancy here: it 
> seems that this is the "de facto" solution to detect docker containers.
>
> FWIW, it's also the most common solution on Q&A sites like 
> stackoverflow. Other people do that, because there is no better solution 
> provided apparently. Unless I missed it.
>

Yes, I agree; It appears to be the defacto solution, and might very well
be the only solution for Bullseye in the sense that "perfect is the
enemy of the good", ie: that it's better to solve this issue in a
non-future compatible way to solve a bonafide issue in Bullseye; Later,
a future alternative to /.dockerenv can be documented in Debian.NEWS
and/or release-notes for Bookworm.

>  > Cgroup v2 is also mounted at /sys/fs/cgroup, so I wonder if the original
>  > check should be rewritten to check for something under this path instead
>  > of mountinfo?  Also, using this /sys/fs/cgroup method, I'm not sure if
>  > it's better debootstrap style to express the OR logical operator in the
>  > regex or a shell "||" (ie: seems to be needed because the tree under
>  > /sys/fs/cgroup is different between v1 and v2).
>
> I just had a quick look in /sys/fs/cgroup from within a container. 
> Nothing obvious stands out, there's no file named docker, and nothing in 
> the content of those files mentions docker. I'll attach the output below.
>
> I will CC Tianon, as he was the author of the comment mentioned above, 
> and he might know better, 5 years after :)
>
> In short, Tianon, if you're reading those lines, our question is: what 
> would be the right way to detect that we're running from within a docker 
> container, apart from checking for the existence of the file 
> `/.dockerenv` ???
>

Thank you for this investigation!  I was also unable to find an
alternative is_running_in_docker cgroupv2 check using /sys/fs/cgroup.
Hopefully one of the src:docker.io maintainers knows!  I've also added
"affects release-notes" (and filed separate release-notes bugs) to
defend against a worst-case scenario where this bug isn't resolved in
time.


Regards,
Nicholas


signature.asc
Description: PGP signature

Processed: Re: Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

[Debian Bug Tracking System]

Processing control commands:

> affects -1 release-notes
Bug #985481 [debootstrap] debootstrap: Detection of docker container is broken 
with cgroup v2
Added indication that 985481 affects release-notes

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

Re: Sponsor tasksel upload

[Cyril Brulebois]

Holger Wansing  (2021-04-15):
> Could someone upload tasksel 3.66 for me, please?

Done with a source+binaries upload, thanks!

bullseye's lintian spots those when building the source package, but
that doesn't seem quite important at this stage, so I definitely won't
block on it:

W: tasksel source: national-encoding debian/po/es.po
W: tasksel source: national-encoding debian/po/hr.po
W: tasksel source: national-encoding debian/po/pl.po

> Since I only have DM upload rights, I cannot do this, because this
> upload adds new packages.

Oh, that part totally slipped my mind. I'd be happy to advocate you if
you ever decide to start the NM process.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature