debian testing daily build: installing GRUB/Bootloader failing!!

[André Verwijs]

debian testing daily build:  installing GRUB/Bootloader and initramfs  
failing!!

i will try to generate logfiles and report as bug.

more info later..
thanks

debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[André Verwijs]

debian testing daily build:  installing GRUB/Bootloader and initramfs  
failing!!

i will try to generate logfiles and report as bug.

more info later..
thanks

debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[André Verwijs]

debian testing daily build:  installing GRUB/Bootloader and initramfs 
failing!!

i will try to generate logfiles and report as bug.

more info later..
thanks

Re: debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[Gioele Barabucci]

On 17/09/23 09:46, André Verwijs wrote:
debian testing daily build:  installing GRUB/Bootloader and initramfs 
failing!!


Probably you stumbled upon this problem: https://bugs.debian.org/1040899

The root cause has (hopefully) been fixed by the Debian Installer team 
and will be released soon: https://bugs.debian.org/1031183


Regards,

--
Gioele Barabucci

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Peter Pentchev]

On Sun, Sep 17, 2023 at 09:31:03AM +0530, Hideki Yamane wrote:
> On Sat, 16 Sep 2023 13:34:02 +0200
> Guillem Jover  wrote:
> > That's not correct. dpkg-deb is doing multi-threaded xz decompression
> > since 1.21.13, and dpkg-source is doing multi-threaded xz compression
> > and decompression since 1.21.14.
> > 
> > Also the Ubuntu zstd implementation did not have multi-threaded support
> > at all, the one implemented in dpkg 1.21.18 does have explicit
> > multi-threaded support for _compression_, but AFIUI (from zstd code and
> > its API being used in libdpkg) not for decompression.
> 
>  Thank you, that was my fault, correct information is very welcoming.
>  
>  Is there any plan to improve zstd implementation in dpkg?

FWIW, if people think that it would be beneficial for libzstd to be
built against libpthread (which seems to be the only way it supports
multithreaded operation right now), this could be arranged - I just
never thought anybody wanted that until now.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Stephan Verbücheln]

If you want to open that debate (again?), one should probably switch to
lzip. It uses the same LZMA compression like xz, but has a way more
sane file format.

Also note that the (pretended) multi-threading-capability of xz is
mostly based on its improper file format[1]:

> The xz-utils manual says that LZMA2 is an updated version of LZMA to
> fix some practical issues of LZMA. This wording suggests that LZMA2
> is some sort of improved LZMA algorithm. (After all, the 'A' in LZMA
> stands for 'algorithm'). But LZMA2 is a container format that divides
> LZMA data into chunks in an unsafe way. 

Regards

[1] https://www.nongnu.org/lzip/xz_inadequate.html


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

Re: /usr-merge and filesystem bootstrap

[Helmut Grohne]

Hi Aurelien,

On Fri, Sep 15, 2023 at 12:02:35AM +0200, Aurelien Jarno wrote:
> Answering for the glibc package.

Thanks.

> On 2023-09-12 20:15, Helmut Grohne wrote:
> > Once the Priority:required set only has that exception set left
> > unconverted, I will prepare patches for the entire exception set and
> > upload it coherently in one dinstall window.
> > 
> > That exception set is:
> >  * base-files
> >  * bash
> >  * coreutils maybe
> >  * dash
> >  * libc6
> >  * util-linux
> 
> Do you mean you plan to upload source+binaries for all the above
> packages and for all architectures? How do you plan to handle ports
> architectures? 

My initial idea was doing source-only uploads and letting buildds
perform all of the builds. Of course that leaves the possibility of
buildds producing their packages "late" for the next dinstall. If that
happens, the relevant architecture will fail debootstrap unstable. That
is unfortunate, but it does happen occasionally and I think it is a
reasonable risk to accept here. Once all relevant builds are done,
debootstrap will work again. There are a number of things I can do to
minimize the risk. For one thing, I can ask DSA when the cronjob for
updating buildd chroots happens and align the uploads closely after such
a cronjob. For another, I can coordinate with the buildd people and ask
for help (e.g. prioritizing builds) on their side. Then I can mail
d-devel and announce a concrete point in time asking developers to not
upload packages on that particular day (e.g. using the delayed queue) to
temporarily reduce the buildd load. Quite probably, debootstrap will
temporarily break on some architectures. I hope that this is acceptable
and that minimizing the downsides is good enough.

Does that answer your question?

> >  * Are you fine in principle with me NMUing your package after having
> >reviewed the promised patch?
> 
> Yes, with the condition that help is provided to fix the bugs resulting
> from moving files from / to /usr in the glibc packages.

It is sad to see that this no longer goes without saying. Yes, I will
actively look for possible fallout and allocate time for dealing with
it.

> >  * Do you readily see any flaw in the proposed transition already?
> 
> I haven't looked at the details besides the changes you described above.

Thank you. We'll get into details once there are patches.

Unfortunately, testing patches right now is difficult, because this work
depends on all other (required) packages having been converted, which in
turn is blocked in buildds being merged. Hoping that this is less work
if done later, I've prioritized other matters for now and reach out to
you now as a means of informing and gathering consent.

There will certainly be a few more mails about this and there will be
time after me having sent patches and provided details on how I tested
them.

Helmut

RE: debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[André Verwijs]

thank you Gioele,


yes i did got this bug to.
but with  https://bugs.debian.org/1040899 is trying to install  Debian 
13, with is VERY unstable and alpha stage,


i hope debian 12 can be fixed...


thank you
André

Bug#1052117: ITP: frappe-bench -- CLI to manage Multi-tenant deployments for Frappe apps

[Arun Mathai]

Package: wnpp
Severity: wishlist
Owner: Arun Mathai 
X-Debbugs-Cc: debian-devel@lists.debian.org, m...@arunmathaisk.in

* Package name: frappe-bench
  Version : 5.17.2
* URL : https://github.com/frappe/bench
* License : GPL-3
  Programming Lang: Python
  Description : CLI to manage Multi-tenant deployments for Frappe apps

Bench is a command-line utility that helps you to install, update, and manage 
multiple sites for Frappe/ERPNext applications on *nix systems for development 
and production.

lpr/lpd

[Thorsten Alteholz]

Hi everybody,

as you might have heard during the Debconf talk of Till, cups3 and CPDB 
(Common Printing Dialog Backends) are waiting at the gates.
Maybe this is a good opportunity to get rid of some old legacy stuff. Is 
there anybody or do you know anybody who is using the old BSD lpr/lpd 
stuff?  I don't mean the lp/lpr commands that are provided by cups but 
the old lpd spooler from package lpr.


  Thorsten

Re: lpr/lpd

[Christoph Biedl]

Thorsten Alteholz wrote...

> Maybe this is a good opportunity to get rid of some old legacy stuff. Is
> there anybody or do you know anybody who is using the old BSD lpr/lpd
> stuff?

Well, not me. But the thing that puzzles me is the popcon numbers:
lpr has 755, lprng 233.

Assuming most of these installation were not done deliberately but are
rather by-catch, or: Caused by some package that eventually draws them
in, via a dependency that has "lpr" (or "lprng") in the first place
instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
have no idea. And there's little chance to know.

Christoph


signature.asc
Description: PGP signature

Re: lpr/lpd

[Russ Allbery]

Christoph Biedl  writes:

> Well, not me. But the thing that puzzles me is the popcon numbers:  lpr
> has 755, lprng 233.

> Assuming most of these installation were not done deliberately but are
> rather by-catch, or: Caused by some package that eventually draws them
> in, via a dependency that has "lpr" (or "lprng") in the first place
> instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
> have no idea. And there's little chance to know.

It at least used to be that you could print directly to a remote printer
with lpr and a pretty simple /etc/printcap entry that you could write
manually.  I used to use that mechanism to print to an office printer
until I discovered rlpr, which is even better for that use case.  It's
possible some of those installations are people doing that, rather than
via dependencies or other things (in which case they probably should move
to rlpr).

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

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Julian Andres Klode]

On Fri, Sep 15, 2023 at 04:05:50PM -0700, Steve Langasek wrote:
> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> > With the provision that I know next to nothing about pam - if I
> > understood correctly how it works, why not simply do both? Ship the
> > default file in the package under both /usr and /etc. Then, you get
> > the semantics you want with local changes tracking, and /etc wins over
> > the defaults. And we can have a working, bootable Debian container
> > with only /usr. As far as I've been told, pam is the only blocker
> > there - for a minimal image of course, but that's still quite a good
> > achievement. Wouldn't this work, or am I missing something?
> 
> While I have applications downstream which also care about empty /etc, the
> current situation is that this wouldn't help because almost all the
> PAM application configs in Debian reference one or more of
> common-{account,auth,password,session,session-noninteractive} which are
> constructed at package install time and therefore are inappropriate to ship
> in /usr.

I do not believe the files being constructed at install time makes them
inappropriate to ship in /usr, We have precedence for doing that, 
compiled bytecode for python is essentially the same case.

If you follow the argument for /usr to its logical conclusion of being
the complete image, you end up moving state of the image (as opposed to
the system) from /var/lib to /usr as well, for example /var/lib/dpkg and
/var/lib/apt/extended_states.

To my knowledge, similar changes are already implemented in higher
paced distributions.

Potentially there should be a /usr/var to encapsulate image state
as opposed to image data but that's somewhat bikeshedding.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Joerg Jaspert]

On 16988 March 1977, Hideki Yamane wrote:

 Today I want to propose you to change default compression format in 
 .deb,

 {data,control}.tar."xz" to ."zst".
 I want to hear your thought about this.


Negative.


# Compared to past change to xz proposal (in DebConf12)
  * More bandwidth
  * More CPUs
  * More storage bandwidth


Get us actual numbers please on how much a full Debian mirror would 
increase in size.

Also consider services like snapshots.

I do not think wasting space is any good idea.


## More bandwidth
 According to https://www.speedtest.net/global-index, broadband 
 bandwidth

 in Nicaragua becomes almost 10x


And elsewhere it may have gone up a different factor.
Still, there are MANY places where its still bad.


 And, xz cannot use multi core CPUs for decompression but zstd can.
 It means that if we use xz, we just get 2x CPU power, but change to 
 zst,

 we can get more than 10x CPU power than 2012.


In ideal conditions, maybe, but still, thats the first (to me) good 
reason. IMO not good enough to actually do it.



  - Not sure how repository size will be, need an experiment


And keep in mind the repository is mirrored a trillion times, stored in
snapshots, burned into images here and there, so any "small" increase in
size actually means a *huge* waste in the end.

If we switch formats, going to something that's at least as good as the
one we currently have should be the goal. (And I do not mean something
like "its code/algorithm is bad", really, that argument is dead before
it begins even).

Now, thats for .debs. There might be a better argument when talking
about the index files in dists/, they are read so much more often, it
*may* make more sense there.

--
bye, Joerg

Re: /usr-merge and filesystem bootstrap

[Aurelien Jarno]

Hi,

On 2023-09-17 13:31, Helmut Grohne wrote:
> Hi Aurelien,
> 
> On Fri, Sep 15, 2023 at 12:02:35AM +0200, Aurelien Jarno wrote:
> > Answering for the glibc package.
> 
> Thanks.
> 
> > On 2023-09-12 20:15, Helmut Grohne wrote:
> > > Once the Priority:required set only has that exception set left
> > > unconverted, I will prepare patches for the entire exception set and
> > > upload it coherently in one dinstall window.
> > > 
> > > That exception set is:
> > >  * base-files
> > >  * bash
> > >  * coreutils maybe
> > >  * dash
> > >  * libc6
> > >  * util-linux
> > 
> > Do you mean you plan to upload source+binaries for all the above
> > packages and for all architectures? How do you plan to handle ports
> > architectures? 
> 
> My initial idea was doing source-only uploads and letting buildds
> perform all of the builds. Of course that leaves the possibility of
> buildds producing their packages "late" for the next dinstall. If that
> happens, the relevant architecture will fail debootstrap unstable. That
> is unfortunate, but it does happen occasionally and I think it is a
> reasonable risk to accept here. Once all relevant builds are done,
> debootstrap will work again. There are a number of things I can do to
> minimize the risk. For one thing, I can ask DSA when the cronjob for
> updating buildd chroots happens and align the uploads closely after such
> a cronjob. For another, I can coordinate with the buildd people and ask
> for help (e.g. prioritizing builds) on their side. Then I can mail
> d-devel and announce a concrete point in time asking developers to not
> upload packages on that particular day (e.g. using the delayed queue) to
> temporarily reduce the buildd load. Quite probably, debootstrap will
> temporarily break on some architectures. I hope that this is acceptable
> and that minimizing the downsides is good enough.
> 
> Does that answer your question?

Yes, it does. So while it is important to minimize as much as possible
the time where all those packages are not in sync, it can be slightly
more than a single dinstall, maybe it's something to mention.

Another alternative might be to ask the ftpmasters to skip a dinstall.
Even skipping the push to the mirrors without skipping the dinstall
might be enough.

To answer your questions:
- It's indeed possible to prioritize builds to minimize the out-of-sync
  time as much as possible, but it might not be guaranteed on all
  architectures to be within a single dinstall.
- For buildd administrated by DSA, the cronjob to generate chroots is
  setup to run at 22:13 UTC every Wednesdays and Sundays.

> > >  * Do you readily see any flaw in the proposed transition already?
> > 
> > I haven't looked at the details besides the changes you described above.
> 
> Thank you. We'll get into details once there are patches.
> 
> Unfortunately, testing patches right now is difficult, because this work
> depends on all other (required) packages having been converted, which in
> turn is blocked in buildds being merged. Hoping that this is less work
> if done later, I've prioritized other matters for now and reach out to
> you now as a means of informing and gathering consent.

Thanks for doing that.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1052135: ITP: check-build -- Check whether some example programs can be compiled and built

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team 
, r...@debian.org

* Package name: check-build
  Version : 0.1.0
  Upstream Contact: Peter Pentchev 
* URL : https://gitlab.com/ppentchev/check-build
* License : BSD-2-clause
  Programming Lang: Python
  Description : Check whether some example programs can be compiled and 
built

  The `check-build` tool can be used to build and test different
  programs in a temporary build directory. The programs are listed in
  a TOML configuration file, along with the commands to build and
  test them.

A bundled copy of the check-build library is used in the libzstd
autopkgtest to make sure that the C library's -dev package contains
enough files so that a program that uses the library can be built.
It will be removed in the next libzstd upload as soon as this package
hits the archive.

I will maintain this package as part of the Debian Python Team.


signature.asc
Description: PGP signature

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Christoph Biedl]

Stephan Verbücheln wrote...

> If you want to open that debate (again?), one should probably switch to
> lzip. It uses the same LZMA compression like xz, but has a way more
> sane file format.

Besides the fact dpkg already has zstd support while lzip is missing, so
that was a way bigger changes: In case you've missed that, lzip is not a
mine field in Debian, it's completely burnt ground. It's better to never
mention it.

Christoph



signature.asc
Description: PGP signature

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[M. Zhou]

On Sun, 2023-09-17 at 22:16 +0200, Joerg Jaspert wrote:
> 
> I do not think wasting space is any good idea.
> 
> > ## More bandwidth
> >  According to https://www.speedtest.net/global-index, broadband 
> >  bandwidth
> >  in Nicaragua becomes almost 10x
> 
> And elsewhere it may have gone up a different factor.
> Still, there are MANY places where its still bad.

I fully agree. I forgot to mention this point in my other response
in the thread.

The thing is, while the average bandwidth do increase as time goes
by, the bottom-1% will not likely increase like that.

In many corners in the world, people are still using poor and
expensive network. Those networks might be even metered.
Significantly bloating up the mirror size will directly increase
the metered network bill for those people. I was one of them.

It will also increase the pressure on mirror hosting.
Some universities host linux mirrors on their own. Debian is always
the most bulky repository to mirror. They are not always commercially
supported -- sometimes supported only by volunteer's funds.
A significantly bloated up debian mirrors can make their life more
difficult. Things can be worse if they the uploading bandwidth is
limited of even metered. I was one of such hosts.

I know, this is a difficult trade-off between Debian's accessibilty
and software performance.

> >  And, xz cannot use multi core CPUs for decompression but zstd can.
> >  It means that if we use xz, we just get 2x CPU power, but change
> > to 
> >  zst,
> >  we can get more than 10x CPU power than 2012.
> 
> In ideal conditions, maybe, but still, thats the first (to me) good 
> reason. IMO not good enough to actually do it.
> 
> >   - Not sure how repository size will be, need an experiment
> 
> And keep in mind the repository is mirrored a trillion times, stored
> in
> snapshots, burned into images here and there, so any "small" increase
> in
> size actually means a *huge* waste in the end.
> 
> If we switch formats, going to something that's at least as good as
> the
> one we currently have should be the goal. (And I do not mean
> something
> like "its code/algorithm is bad", really, that argument is dead
> before
> it begins even).
> 
> Now, thats for .debs. There might be a better argument when talking
> about the index files in dists/, they are read so much more often, it
> *may* make more sense there.
> 

Re: lpr/lpd

[Simon Richter]

Hi,

On 18.09.23 04:29, Russ Allbery wrote:


It at least used to be that you could print directly to a remote printer
with lpr and a pretty simple /etc/printcap entry that you could write
manually.  I used to use that mechanism to print to an office printer
until I discovered rlpr, which is even better for that use case.  It's
possible some of those installations are people doing that, rather than
via dependencies or other things (in which case they probably should move
to rlpr).


Yes, that's basically how I use it. Pretty much all existing printers 
with network interfaces support the BSD lpr protocol still, and accept 
PostScript or PDF. People in Germany are likely to have a FritzBox DSL 
router, which conveniently allows you to export USB printers that way too.


And yes, it is quicker for me to copy another printcap entry and swap 
out the host name than it is to find out how to authenticate to CUPS, 
set up the printer, print a test page then remove and recreate it 
because the generated "short" name I need to pipe data into lpr isn't 
short. I will definitely be looking into rlpr.


I think those packages are probably still useful to someone, I guess 
several universities will be running these because they are small and 
robust, and can just leave a job in the queue if there is a temporary 
problem rather than mark the printer as offline and any jobs queued to 
it as paused.


Oddly specific rant, I know, but it's "small" things like that that can 
break a use case completely, and that's why we usually ship alternative 
implementations for everything, and why a lot of seemingly small changes 
are controversial: they break non-standard use cases.


   Simon


OpenPGP_signature
Description: OpenPGP digital signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Simon Richter]

Hi,

On 18.09.23 05:16, Julian Andres Klode wrote:


If you follow the argument for /usr to its logical conclusion of being
the complete image, you end up moving state of the image (as opposed to
the system) from /var/lib to /usr as well, for example /var/lib/dpkg and
/var/lib/apt/extended_states.


The way I understood it, images cannot be updated. Instead, users will 
build or receive a new image, and quickly "reboot" into that by having 
running services transfer their state over to new instances.


   Simon

Bug#1052140: ITP: node-html-webpack-plugin -- node-webpack plugin to create HTML files

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: node-html-webpack-plugin
  Version : 5.5.3
  Upstream Contact: JS Foundation
  
* URL : https://github.com/jantimon/html-webpack-plugin
* License : JavaScript
  Programming Lang: Expat
  Description : node-webpack plugin to create HTML files

node-html-webpack-plugin is a node-webpack plugin that simplifies
creation of HTML files to serve a node-webpack bundle.This is
especially useful for bundles that include a hash in the filename
which changes every compilations

It's a build dependency of node-jupyterlab. Will be maintained under JS
Team umbrella.