Can we distribute pre-built locales to speed up image generation?
Hello everybody, In the course of generating singularity/apptainer Debian images at work, I wanted to make all locales available to the users. Running locale-gen on everything from /usr/share/i18n/SUPPORTED only adds ~60 Mb to the image, which is small compared to the image total size and the available storage in my use case. However, generating all of them at image creation time is by far the most time-consuming and earth-heating stage. The description of the locales package mentions that in the past they were distributed pre-built. I was wondering if it was recently considered to provide pre-built locales again, either in a separate package or in one of the system images that we distribute, in the interest of embracing language diversity. It has been a long time I have not posted here, and I am not subscribed at the moment. Please CC me! Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Can we distribute pre-built locales to speed up image generation?
On Tue, 01 Aug 2023 at 16:43:59 +0900, Charles Plessy wrote: > In the course of generating singularity/apptainer Debian images at work, > I wanted to make all locales available to the users. If you install locales-all, does that do what you want? > Running locale-gen on everything from /usr/share/i18n/SUPPORTED only > adds ~60 Mb to the image locales-all has Installed-Size: 227M, I don't know why that differs so much from your estimate. > I was wondering if it was recently > considered to provide pre-built locales again, either in a separate > package Is locales-all not that package? smcv
[solved] Re: Can we distribute pre-built locales to speed up image generation?
> > I was wondering if it was recently considered to provide pre-built > > locales again, either in a separate package Le Tue, Aug 01, 2023 at 09:37:23AM +0100, Simon McVittie a écrit : > Is locales-all not that package? Exactly! Thank you so much and sorry for the noise. > locales-all has Installed-Size: 227M, I don't know why that differs so > much from your estimate. I was reporting the size of the Singularity image, which must be compressed in some way. A minimal image containing the hello package and locales-all is ~90M. Cheers, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Can we distribute pre-built locales to speed up image generation?
Hi Charles, On Tue, Aug 01, 2023 at 04:43:59PM +0900, Charles Plessy wrote: > In the course of generating singularity/apptainer Debian images at work, > I wanted to make all locales available to the users. On an un-related note, are you using signularity-container package from debian archive itself? I recently did some work to get it into fasttrack. https://micronews.debian.org/2023/1686751737.html Best, Nilesh signature.asc Description: PGP signature
Re: Can we distribute pre-built locales to speed up image generation?
> Hi Charles, > > On Tue, Aug 01, 2023 at 04:43:59PM +0900, Charles Plessy wrote: >> In the course of generating singularity/apptainer Debian images at work, >> I wanted to make all locales available to the users. I sthere a maliling list where we can speak about these singuarity/apptainer applications ? At work they want us to build these singularity/apptainer, distributed via https://cernvm.cern.ch/fs/ Cheers Fred
Re: Can we distribute pre-built locales to speed up image generation?
Le Tue, Aug 01, 2023 at 11:56:28AM +0200, PICCA Frederic-Emmanuel a écrit : > > I sthere a maliling list where we can speak about these singuarity/apptainer > applications ? I wouln't mind debian-hpc@l.d.o, but I do not know about the opinion of the other subscribers? Cheers, -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Can we distribute pre-built locales to speed up image generation?
Le Tue, Aug 01, 2023 at 03:18:18PM +0530, Nilesh Patra a écrit : > > https://micronews.debian.org/2023/1686751737.html Thanks ! I was using sid but just switched to fasttrack thanks to your message. Cheers, -- Charles
Debian 5.19.11-1 (2022-10-03) x86_64 GNU/Linux: NFSv3 Input/output error while cat , 5.14 or below ok
Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** *** What led up to the situation?*** Upgrading to kernel 5.19 and trying to read a small file from directory on the NFS server. *** What exactly did you do (or not do) that was effective (or ineffective)?*** server: WinNFSd.exe -log on "F/Kernel5.19/NFS" client: mount -t nfs 192.168.0.21:/F/Kernel5.19/NFS /mnt/img -o noatime,nfsvers=3 cd /mnt/img/GPCImageV4.0 cat parts *** What was the outcome of this action?*** "Input/output error." terminal interface stuck *** What outcome did you expect instead?*** Files can be read normal ( This good outome happens with kernel 5.14 and older ) ***Issue Details*** I have encountered a problem while using the WinNFSd.exe tool as a server, sharing directory on Windows 10, and with Debian 11 ( kernel version 5.19 ) as client utilizing the NFSv3 protocol for mounting. The mounting process completes without any errors, and can successfully access the directory info using the "ls" or "ls -l". However, when I attempt to access the directory contents using the "cat" command, I receive an error message stating "Input/output error." I can also read the content of newly created files using cat when they are created on the client side using touch. However, if a file is created on the server side, the client can see the newly created file and get the file information with ls, but encounters an "Input/output error" when trying to read its contents with cat. That's the strange part confused me, seems like problems with access control? Additionally, after a certain period of time, the terminal interface becomes unresponsive stuck when attempting to access the mounted directory. I'm uncertain about the exact cause triggering this issue, as the timing appears to be random. Sometimes, it takes several minutes for the unresponsiveness to occur, while in other instances, I can work for up to half an hour without any issues. Interestingly, downgrading the kernel version to 5.14 or BELOW resolves this problem. In fact, using the same network environment, mounted directory, and mounting parameters, I tested kernel versions 6.1, 5.18, 5.15, 5.14, 5.10, and 4.19. Out of these versions, only the first three presented this issue, while the latter three low versions were able to read the contents of files within the NFS shared directory without any problems. The attachments are the message log during the testing process. ---Here are the specific details of the problematic test environment : ***Server:*** --Operating System: Windows 10 --NFS Server Tool: WinNFSd.exe 2.4.0 ***Client:*** --Operating System: Debian 11.0 --Kernel Version: Linux gpc 5.19.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1~bpo11+1 (2022-10-03) x86_64 GNU/Linux ***Protocol:*** --NFS Version: NFSv3 nfs-common/oldstable,now 1:1.3.4-6 amd64 [installed] rpcbind/oldstable,now 1.2.5-9 amd64 [installed,automatic] ***Mount CMD*** root@gpc:mount -t nfs 192.168.0.21: /F/Kernel5.19/NFS /mnt/img -o noatime,nfsvers=3 ***Observations:*** root@gpc:/mnt/img# ls -l total 4 drwxrwxrwx 1 root root 4096 Jul 28 2023 GPCImageV4.0 root@gpc:/mnt/img/GPCImageV4.0# ls -l total 2400393 -rwxrwxrwx 1 root root 1529 Jul 26 18:54 blkdev.list -rwxrwxrwx 1 root root 1424 Jul 26 18:54 blkid.list -rwxrwxrwx 1 root root 13562 Jul 26 18:54 clonezilla-img -rwxrwxrwx 1 root root 300 Jul 26 18:54 dev-fs.list -rwxrwxrwx 1 root root 4 Jul 26 18:54 disk -rwxrwxrwx 1 root root 1207 Jul 26 18:54 efi-nvram.dat -rwxrwxrwx 1 root root 201 Nov 2 2022 GantryConfiguration.xml -rwxrwxrwx 1 root root 22373 Jul 26 18:54 Info-dmi.txt -rwxrwxrwx 1 root root 236 Jul 26 18:54 Info-img-id.txt -rwxrwxrwx 1 root root 61 Jul 26 18:54 Info-img-size.txt -rwxrwxrwx 1 root root 27602 Jul 26 18:54 Info-lshw.txt -rwxrwxrwx 1 root root 1592 Jul 26 18:54 Info-lspci.txt -rwxrwxrwx 1 root root 1539 Jul 26 18:54 Info-OS-prober.txt -rwxrwxrwx 1 root root 200 Jul 26 18:54 Info-packages.txt -rwxrwxrwx 1 root root 96 Jul 26 18:54 Info-saved-by-cmd.txt -rwxrwxrwx 1 root root 4724 Jul 26 18:54 Info-smart.txt -rwxrwxrwx 1 root root 35 Jul 26 18:54 parts -rwxrwxrwx 1 root root 2158265 Jul 26 18:54 sda1.vfat-ptcl-img.gz -rwxrwxrwx 1 root root 2210653199 Jul 26 18:54 sda2.ext4-ptcl-img.gz -rwxrwxrwx 1 root root 225310835 Jul 26 18:53 sda3.ext4-ptcl-img.gz -rwxrwxrwx 1 root root 4227536 Jul 26 18:52 sda4.ext4-ptcl-img.gz -rwxrwxrwx 1 root root 7246389 Jul 26 18:52 sda5.ext4-ptcl-img.gz -rwxrwxrwx 1 root root 2314988 Jul 26 18:52 sda6.ext4-ptcl-img.gz -rwxrwxrwx 1 root root 5948542 Jul 26 18:52 sda7.ext4-ptcl-img.gz -rwxrwxrwx 1 root root 37 Jul 26 18:54 sda-chs.sf -rwxrwxrwx 1 root root 17408 Jul 26 18:54 sda-gpt-1st -rwxrwxrwx 1 root root 16384 Jul 26 18:54 sda-gpt-2nd -rwxrwxrwx 1 root root 17920 Jul 26 18:54 sda-gpt.gdisk -rwxrwxrwx 1 root root 967 Jul 26 18:54 sda-gpt.sgdisk -rwxrwxrwx 1 root root 512 Jul 26 18:54 sda-mbr -rwxrwxrwx 1 root r
Re: Can we distribute pre-built locales to speed up image generation?
Quoting Charles Plessy (2023-08-01 09:43:59) > Hello everybody, > > In the course of generating singularity/apptainer Debian images at work, > I wanted to make all locales available to the users. > > Running locale-gen on everything from /usr/share/i18n/SUPPORTED only > adds ~60 Mb to the image, which is small compared to the image total > size and the available storage in my use case. However, generating all > of them at image creation time is by far the most time-consuming and > earth-heating stage. > > The description of the locales package mentions that in the past they > were distributed pre-built. I was wondering if it was recently > considered to provide pre-built locales again, either in a separate > package or in one of the system images that we distribute, in the > interest of embracing language diversity. > > It has been a long time I have not posted here, and I am not subscribed > at the moment. Please CC me! Are you perhaps looking for the package locales-all? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1042827: ITP: priv-wrapper -- library to disable resource limits and other privilege dropping
Package: wnpp Severity: wishlist Hi! I am planning to package priv-wrapper: https://cwrap.org/priv_wrapper.html priv_wrapper aims to help running processes which are dropping privileges or are restricting resources in test environments. A disabled call always succeeds (i.e. returns 0) and does nothing. The system call pledge exists only on OpenBSD. It is similar in spirit as the rest of the cwrap projects -- see https://cwrap.org/ -- and several seems to be packaged in Debian: https://tracker.debian.org/pkg/nss-wrapper https://tracker.debian.org/pkg/uid-wrapper https://tracker.debian.org/pkg/socket-wrapper https://tracker.debian.org/pkg/pam-wrapper The license appears to be GPLv3+. /Simon signature.asc Description: PGP signature
Re: Debian 5.19.11-1 (2022-10-03) x86_64 GNU/Linux: NFSv3 Input/output error while cat , 5.14 or below ok
Hello! Despite I'm not maintainer nor developer I'd suggest to install latest Linux image package from "bullseye-backports" channel - "6.1.27" for now. вт, 1 авг. 2023 г. в 16:43, Chenguang Zhang : > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > *** What led up to the situation?*** > Upgrading to kernel 5.19 and trying to read a small file from directory on > the NFS server. > *** What exactly did you do (or not do) that was effective (or > ineffective)?*** > server: > WinNFSd.exe -log on "F/Kernel5.19/NFS" > client: > mount -t nfs 192.168.0.21:/F/Kernel5.19/NFS /mnt/img -o noatime,nfsvers=3 > cd /mnt/img/GPCImageV4.0 > cat parts > *** What was the outcome of this action?*** > "Input/output error." > terminal interface stuck > *** What outcome did you expect instead?*** > Files can be read normal ( This good outome happens with kernel 5.14 and > older ) > > ***Issue Details*** > I have encountered a problem while using the WinNFSd.exe tool as a server, > sharing directory on Windows 10, and with Debian 11 ( kernel version 5.19 ) > as client utilizing the NFSv3 protocol for mounting. The mounting process > completes without any errors, and can successfully access the directory info > using the "ls" or "ls -l". However, when I attempt to access the directory > contents using the "cat" command, I receive an error message stating > "Input/output error." > > I can also read the content of newly created files using cat when they are > created on the client side using touch. However, if a file is created on the > server side, the client can see the newly created file and get the file > information with ls, but encounters an "Input/output error" when trying to > read its contents with cat. That's the strange part confused me, seems like > problems with access control? > > Additionally, after a certain period of time, the terminal interface becomes > unresponsive stuck when attempting to access the mounted directory. I'm > uncertain about the exact cause triggering this issue, as the timing appears > to be random. Sometimes, it takes several minutes for the unresponsiveness to > occur, while in other instances, I can work for up to half an hour without > any issues. > > Interestingly, downgrading the kernel version to 5.14 or BELOW resolves this > problem. In fact, using the same network environment, mounted directory, and > mounting parameters, I tested kernel versions 6.1, 5.18, 5.15, 5.14, 5.10, > and 4.19. Out of these versions, only the first three presented this issue, > while the latter three low versions were able to read the contents of files > within the NFS shared directory without any problems. > > The attachments are the message log during the testing process. > > ---Here are the specific details of the problematic > test environment : > ***Server:*** > --Operating System: Windows 10 > --NFS Server Tool: WinNFSd.exe 2.4.0 > > ***Client:*** > --Operating System: > Debian 11.0 > --Kernel Version: > Linux gpc 5.19.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 5.19.11-1~bpo11+1 (2022-10-03) x86_64 GNU/Linux > > ***Protocol:*** > --NFS Version: NFSv3 > nfs-common/oldstable,now 1:1.3.4-6 amd64 [installed] > rpcbind/oldstable,now 1.2.5-9 amd64 [installed,automatic] > > ***Mount CMD*** > root@gpc:mount -t nfs 192.168.0.21:/F/Kernel5.19/NFS /mnt/img -o > noatime,nfsvers=3 > > ***Observations:*** > root@gpc:/mnt/img# ls -l > total 4 > drwxrwxrwx 1 root root 4096 Jul 28 2023 GPCImageV4.0 > > root@gpc:/mnt/img/GPCImageV4.0# ls -l > total 2400393 > -rwxrwxrwx 1 root root 1529 Jul 26 18:54 blkdev.list > -rwxrwxrwx 1 root root 1424 Jul 26 18:54 blkid.list > -rwxrwxrwx 1 root root 13562 Jul 26 18:54 clonezilla-img > -rwxrwxrwx 1 root root 300 Jul 26 18:54 dev-fs.list > -rwxrwxrwx 1 root root 4 Jul 26 18:54 disk > -rwxrwxrwx 1 root root 1207 Jul 26 18:54 efi-nvram.dat > -rwxrwxrwx 1 root root 201 Nov 2 2022 GantryConfiguration.xml > -rwxrwxrwx 1 root root 22373 Jul 26 18:54 Info-dmi.txt > -rwxrwxrwx 1 root root 236 Jul 26 18:54 Info-img-id.txt > -rwxrwxrwx 1 root root 61 Jul 26 18:54 Info-img-size.txt > -rwxrwxrwx 1 root root 27602 Jul 26 18:54 Info-lshw.txt > -rwxrwxrwx 1 root root 1592 Jul 26 18:54 Info-lspci.txt > -rwxrwxrwx 1 root root 1539 Jul 26 18:54 Info-OS-prober.txt > -rwxrwxrwx 1 root root 200 Jul 26 18:54 Info-packages.txt > -rwxrwxrwx 1 root root 96 Jul 26 18:54 Info-saved-by-cmd.txt > -rwxrwxrwx 1 root root 4724 Jul 26 18:54 Info-smart.txt > -rwxrwxrwx 1 root root 35 Jul 26 18:54 parts > -rwxrwxrwx 1 root root 2158265 Jul 26 18:54 sda1.vfat-ptcl-img.gz > -rwxrwxrwx 1 root root 2210653199 Jul 26 18:54 sda2.ext4-ptcl-img.gz > -rwxrwxrwx 1 root root 225310835 Jul 26 18:53 sda3.ext4-ptcl-img.gz > -rwxrwxrwx 1 root root 4227536 Jul 26 18:52 sda4.ext4-ptcl-img.gz > -rwxrwxrwx 1 root root 7246389 Jul 26 18:52 sda5.ext4-ptcl-img.gz > -rwxrwxrwx 1 root root 2314988 Jul 26 18:
Bug#1042861: ITP: git-credential-azure -- A Git credential helper for Azure Repos
Package: wnpp Severity: wishlist Owner: M Hickford X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com * Package name: git-credential-azure Version : 0.1.0 * URL : https://github.com/hickford/git-credential-azure * License : Apache2 Programming Lang: Go Description : A Git credential helper for Azure Repos git-credential-azure is a Git credential helper that authenticates to Azure Repos (dev.azure.com). Azure Repos is part of Azure DevOps.
