Re: partman, growlight, discoverable partitions, and fun

[Luca Boccassi]

On Sun, 2021-09-26 at 12:45 +0200, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 9/26/21 12:40, Luca Boccassi wrote:
> > Does libparted support the discoverable partitions spec?
> 
> I'm not sure, this thread is the first time I have heard about discoverable
> partitions. I have read up first what the motivations for these are and
> how useful they would be for Debian.
> 
> Also, since parted is maintained by RedHat, I would expect that this feature
> would land in parted soon as well.
> 
> Adrian

If the question is "why does X not use libparted", "does not support
discoverable parts spec" is a good enough answer for me.

-- 
Kind regards,
Luca Boccassi


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

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

Hello Nick!

On 9/26/21 16:29, Nick Black wrote:
> I'd be delighted to support them -- as in, I am honestly eager
> to add ATARI support; that sounds awesome -- I just need some
> way to test the implementations, either via someone running it
> on the environment, or getting access to such a machine.

There are emulators available for Atari such as Aranym. And emulators
available for Amiga such as fs-uae. FWIW, parted should contain everything
needed to be able to implement your own support for these partition tables.

>> I think it makes little sense to not use libparted as it already supports
>> all common and less common partition types and reimplementing everything
>> that libparted makes little sense to me.
> 
> parted did not have ZFS support when I embarked on this project
> (it appears to have it now). i would not be opposed to
> leveraging libparted if it presents a definite advantage;
> supporting more partition types, so long as it exposes an API i
> can easily work with, would be such an advantage.

Well, using a missing feature in the past against parted that is present
there is not such a good argument against using it, to be honest.

> i do note that libparted2 is 621K in the archive, whereas
> growlight itself is only 555K. it is of course possible that
> all that weight is desirable functionality.

I think 70k more disk space is not really a concern.

> with that said, i would *still want to test on the target
> environment*, to make sure i'm using libparted correctly there.
> so that necessity remains.

I thought you didn't depend on libparted?

> would this allay your concerns?

No, not really. I consider a partitioning tool to be too important
to be replaced by an unproven solution.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

Hello!

On 9/27/21 12:46, Luca Boccassi wrote:
>> Also, since parted is maintained by RedHat, I would expect that this feature
>> would land in parted soon as well.
>>
> If the question is "why does X not use libparted", "does not support
> discoverable parts spec" is a good enough answer for me.

Not for me, though. Debian has always followed the philosophy to be a universal
operating system, which also meant that we can't (immediately) use all the new
technologies and features that other distributions or upstream projects develop.

For example, we don't use systemd-homed or systemd-firstboot either. That 
doesn't
mean Debian is per se worse off. It just means Debian tries to cater different 
use
cases and follows different concepts.

It's different for distributions like Fedora or openSUSE which focus on a very
limited set of targets and use cases. That's why they can quickly adopt to all
the new features and technologies that upstream projects like systemd develop.

I'm not saying that one philosophy is better than the other. I'm just saying 
that
Debian is not like these other distributions.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: partman, growlight, discoverable partitions, and fun

[Florian Lohoff]

On Sun, Sep 26, 2021 at 10:50:35AM +0200, Adam Borowski wrote:
> On Sun, Sep 26, 2021 at 01:41:18AM -0400, nick black wrote:
> > Marco d'Itri left as an exercise for the reader:
> > > And the preseeding syntax is as powerful as it is inconvenient.
> 
> > > Implementing support for more partition formats, if missing, should be 
> > > rather easy.
> > > But which ones do we need for architectures which are not actually dead?
> > 
> > So, as I responded to Adrian [0], the only missing partition
> > types appear to be amiga, atari, and sun. Adding them ought be
> > simple enough, though I'd need testers with the hardware, or
> > access to the hardware.
> 
> I'd start with asking porters of m68k and sparc64 whether today's systems
> even run anything but Linux.  I think there's little point in keeping compat
> with 80s' OSes.
> 
> At a risk of drawing ire of m68k/sparc64 folks, I'd also suggest not putting
> your tuits there until this millenium's hardware is covered well.

This might be needed for booting purposes. 80ies Workstations tend to
have ROMs/BIOSes much like UEFI today and may even be booting files from
a Filesystem on a specific partition and thus disk label type.

So you are not breaking compatibility with 80ies OSes but
the platform as a whole.

Flo
-- 
Florian Lohoff f...@zz.de
  Any sufficiently advanced technology is indistinguishable from magic.


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[Luca Boccassi]

On Mon, 2021-09-27 at 13:06 +0200, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 9/27/21 12:46, Luca Boccassi wrote:
> > > Also, since parted is maintained by RedHat, I would expect that this 
> > > feature
> > > would land in parted soon as well.
> > > 
> > If the question is "why does X not use libparted", "does not support
> > discoverable parts spec" is a good enough answer for me.
> 
> Not for me, though. Debian has always followed the philosophy to be a 
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects 
> develop.
> 
> For example, we don't use systemd-homed or systemd-firstboot either. That 
> doesn't
> mean Debian is per se worse off. It just means Debian tries to cater 
> different use
> cases and follows different concepts.
> 
> It's different for distributions like Fedora or openSUSE which focus on a very
> limited set of targets and use cases. That's why they can quickly adopt to all
> the new features and technologies that upstream projects like systemd develop.
> 
> I'm not saying that one philosophy is better than the other. I'm just saying 
> that
> Debian is not like these other distributions.
> 
> Adrian

Even if that interpretation would work as an excuse to never do
anything, and I'm not really sure it does, this specification has been
published in 2014 [0] so even by Debian standard it's old stuff. It's
older than Debian Jessie, which was EOL'd last year. If libparted can't
keep up with 7 years old stuff that in the meantime was implemented in
util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
and so on, then to me it sounds like a tool in maintenance mode:
perfectly fine and adequate for existing tools and programs, but not
quite the best choice for new tools developed from scratch.

-- 
Kind regards,
Luca Boccassi

[0]
https://cgit.freedesktop.org/wiki/www/log/Specifications/DiscoverablePartitionsSpec.mdwn


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

Bug#995168: ITP: libppix-utils-perl -- utility functions for PPI

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libppix-utils-perl
  Version : 0.003
  Upstream Author : Dan Book 
* URL : https://metacpan.org/release/PPIx-Utils
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : utility functions for PPI

PPIx::Utils is a collection of utility functions for working with PPI
documents. The functions are organized into submodules, and may be imported
from the appropriate submodule or via this module.

These functions were originally from Perl::Critic::Utils and related modules,
and have been split off to this distribution for use outside of Perl::Critic.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: partman, growlight, discoverable partitions, and fun

[Holger Levsen]

On Sat, Sep 25, 2021 at 06:49:53PM -0400, Nick Black wrote:
> So the only ones covered by partman and not covered by growlight would be:
> amiga, atari, sun,
> and mac (if mac is not the same as APM). I don't see any difficulty in
> adding these four, so long
> as there's someone with an Amiga or ATARI who'd be willing to test them
> out. If there are no such
> people, is it that important?

those ancient hardwares are not important to Debian, we have ceased to support
them years ago.

some people OTOH support them on Debian Ports and some of these people are very
vocal about the need of supporting architectures there. In my opinion they 
should 
only be heard if they also offer to do the work needed to keep those ancient
architectures alive. (and so far I've not even read an offer to help *testing*
such code there and also no offer to help developing such code...)

blocking progress on main Debian architectures because of some unsupported 
ancient
hardwares seems more problematic to me than not supporting those ancient
plattform.


-- 
cheers,
Holger

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

It's not about saving the climate or the planet, it's about saving us, the
children and grandchildren. The planet will survive anyway.


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

> On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> 
> Even if that interpretation would work as an excuse to never do
> anything, and I'm not really sure it does, this specification has been
> published in 2014 [0] so even by Debian standard it's old stuff.

That’s not what I said so. You’re trying to dismiss my opinion as completely 
invalid now by trying to frame it such that I am against progress. I am not.

> It's
> older than Debian Jessie, which was EOL'd last year. If libparted can't
> keep up with 7 years old stuff that in the meantime was implemented in
> util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> and so on, then to me it sounds like a tool in maintenance mode:
> perfectly fine and adequate for existing tools and programs, but not
> quite the best choice for new tools developed from scratch.

Whether a tool that was developed new from scratch is automatically better is 
not a given. The burden of proof is on the person trying to introduce the new 
software, not on the people maintaining the current set of software.

And claiming that parted is in pure maintenance mode is not true either. It has 
a paid developer working on the project and is receiving updates and 
improvements.

Whether growlight is better and more suitable for Debian needs to be 
technically proven, not just by arguing that it’s the newer project.

Adrian

Re: partman, growlight, discoverable partitions, and fun

[Luca Boccassi]

On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote:
> 
> > On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> > 
> > Even if that interpretation would work as an excuse to never do
> > anything, and I'm not really sure it does, this specification has been
> > published in 2014 [0] so even by Debian standard it's old stuff.
> 
> That’s not what I said so. You’re trying to dismiss my opinion as completely 
> invalid now by trying to frame it such that I am against progress. I am not.

You dismissed it because it's "new technology":

> Not for me, though. Debian has always followed the philosophy to be a 
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects 
> develop.

I simply pointed out that it's a 7 years old spec that saw an entire
LTS Debian version (8, we are now at 11) being released and EOL'ed
since the time it was published. If this is too new to consider, then
so are all Debian releases newer than Wheezy.

> > It's
> > older than Debian Jessie, which was EOL'd last year. If libparted can't
> > keep up with 7 years old stuff that in the meantime was implemented in
> > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> > and so on, then to me it sounds like a tool in maintenance mode:
> > perfectly fine and adequate for existing tools and programs, but not
> > quite the best choice for new tools developed from scratch.
> 
> Whether a tool that was developed new from scratch is automatically better is 
> not a given. The burden of proof is on the person trying to introduce the new 
> software, not on the people maintaining the current set of software.
> 
> And claiming that parted is in pure maintenance mode is not true either. It 
> has a paid developer working on the project and is receiving updates and 
> improvements.
> 
> Whether growlight is better and more suitable for Debian needs to be 
> technically proven, not just by arguing that it’s the newer project.
> 
> Adrian

Of course. But jumping in and saying "you should use X instead of Y",
you can't pretend that nobody asks questions such as "ok, but does libX
support this very much related and relevant 7 years old specification
that other comparable tools support", no matter how awkward it is for
libX.

-- 
Kind regards,
Luca Boccassi


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

Re: partman, growlight, discoverable partitions, and fun

[Lennart Sorensen]

On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
> Whether a tool that was developed new from scratch is automatically better is 
> not a given. The burden of proof is on the person trying to introduce the new 
> software, not on the people maintaining the current set of software.
> 
> And claiming that parted is in pure maintenance mode is not true either. It 
> has a paid developer working on the project and is receiving updates and 
> improvements.
> 
> Whether growlight is better and more suitable for Debian needs to be 
> technically proven, not just by arguing that it’s the newer project.

I would have thought that if libparted was missing 1 or 2 features,
it would make more sense to add those features than to write a new tool
duplicating most of the functionality.

Well unless working with the maintainers of libparted is imposible.
There are a few projects like that but I don't remember ever seeing
complains about libparted.  Now you have two tools both missing some
features.  Hardly an improvement.

-- 
Len Sorensen

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

> On Sep 27, 2021, at 3:41 PM, Luca Boccassi  wrote:
> 
> On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote:
>> 
 On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
>>> 
>>> Even if that interpretation would work as an excuse to never do
>>> anything, and I'm not really sure it does, this specification has been
>>> published in 2014 [0] so even by Debian standard it's old stuff.
>> 
>> That’s not what I said so. You’re trying to dismiss my opinion as completely 
>> invalid now by trying to frame it such that I am against progress. I am not.
> 
> You dismissed it because it's "new technology":
> 
>> Not for me, though. Debian has always followed the philosophy to be a 
>> universal
>> operating system, which also meant that we can't (immediately) use all the 
>> new
>> technologies and features that other distributions or upstream projects 
>> develop.

You’re reducing my argument to the word “new” which is definitely not my point. 
As you can see from the rest of my message my primary point is that Debian 
follows a different philosophy meaning that we don’t always adopt technologies 
that other distributions use.

Fedora and openSUSE are much more similar to each other than Debian is to both.

> I simply pointed out that it's a 7 years old spec that saw an entire
> LTS Debian version (8, we are now at 11) being released and EOL'ed
> since the time it was published. If this is too new to consider, then
> so are all Debian releases newer than Wheezy.

Yes, but the age was never my argument. My argument was that replacing such a 
fundamental software component like the partitioning tool in an installer is 
something that has to be justified by technical merits and by weighing pros and 
cons against each other.

The fact that’s it’s newer or has the single feature X is not sufficient in my 
opinion. Especially when there is no proof yet that getting support for 
discoverable partitions justifies the loss of features that parted has.

>>> It's
>>> older than Debian Jessie, which was EOL'd last year. If libparted can't
>>> keep up with 7 years old stuff that in the meantime was implemented in
>>> util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
>>> and so on, then to me it sounds like a tool in maintenance mode:
>>> perfectly fine and adequate for existing tools and programs, but not
>>> quite the best choice for new tools developed from scratch.
>> 
>> Whether a tool that was developed new from scratch is automatically better 
>> is not a given. The burden of proof is on the person trying to introduce the 
>> new software, not on the people maintaining the current set of software.
>> 
>> And claiming that parted is in pure maintenance mode is not true either. It 
>> has a paid developer working on the project and is receiving updates and 
>> improvements.
>> 
>> Whether growlight is better and more suitable for Debian needs to be 
>> technically proven, not just by arguing that it’s the newer project.
>> 
>> Adrian
> 
> Of course. But jumping in and saying "you should use X instead of Y",
> you can't pretend that nobody asks questions such as "ok, but does libX
> support this very much related and relevant 7 years old specification
> that other comparable tools support", no matter how awkward it is for
> libX.

I was not the one that was making this request, it was Nick. I’m perfectly fine 
with the status quo.

Again, the party introducing the new solution should provide the arguments to 
convince the maintainers of the existing solution.

For example, a convincing argument would be a demonstration installation ISO 
which let’s others interested in the project test it and check whether it 
delivers the improvements that were promised.

I don’t think that this is such an extraordinary requirement to ask for.

Also, I would be interested to know what approaches are currently used in 
Fedora, Arch, Gentoo and openSUSE (I will check that later myself when I’m back 
at the computer).

Adrian 

Bug#995177: ITP: libsql-abstract-pg-perl -- PostgreSQL features for SQL::Abstract

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsql-abstract-pg-perl
  Version : 1.0
  Upstream Author : Sebastian Riedel 
* URL : https://metacpan.org/release/SQL-Abstract-Pg
* License : Artistic-2.0
  Programming Lang: Perl
  Description : PostgreSQL features for SQL::Abstract

SQL::Abstract::Pg extends SQL::Abstract with a few PostgreSQL features used
by Mojo::Pg.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: partman, growlight, discoverable partitions, and fun

[Marco d'Itri]

On Sep 27, John Paul Adrian Glaubitz  wrote:

> Not for me, though. Debian has always followed the philosophy to be a 
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects 
> develop.
It never meant that.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#995182: ITP: libsql-abstract-classic-perl -- module to generate SQL from Perl data structures - classic version

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsql-abstract-classic-perl
  Version : 1.91
  Upstream Author : Peter Rabbitson 
* URL : https://metacpan.org/release/SQL-Abstract-Classic
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to generate SQL from Perl data structures - classic 
version

SQL::Abstract::Classic is a low-impact fork of SQL::Abstract v1.81 and nearly
identical to it. This module exists to preserve the ability of users to opt
into the new way of doing things in the quickly evolving SQL::Abstract
according to their own schedules.

SQL::Abstract and SQL::Abstract::Classic are Perl modules that allow
developers to generate SQL from Perl data strutures, inspired by
DBIx::Abstract. The intent of these modules is to provide abstract SQL
generation methods, allowing one to generate SQL while retaining complete
control over the statement handles.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: partman, growlight, discoverable partitions, and fun

[Metztli Information Technology]

On 9/27/21 4:01 AM, John Paul Adrian Glaubitz wrote:

Hello Nick!

On 9/26/21 16:29, Nick Black wrote:

I'd be delighted to support them -- as in, I am honestly eager
to add ATARI support; that sounds awesome -- I just need some
way to test the implementations, either via someone running it
on the environment, or getting access to such a machine.

There are emulators available for Atari such as Aranym. And emulators
available for Amiga such as fs-uae. FWIW, parted should contain everything
needed to be able to implement your own support for these partition tables.


I think it makes little sense to not use libparted as it already supports
all common and less common partition types and reimplementing everything
that libparted makes little sense to me.

parted did not have ZFS support when I embarked on this project
(it appears to have it now). i would not be opposed to
leveraging libparted if it presents a definite advantage;
supporting more partition types, so long as it exposes an API i
can easily work with, would be such an advantage.

Well, using a missing feature in the past against parted that is present
there is not such a good argument against using it, to be honest.


i do note that libparted2 is 621K in the archive, whereas
growlight itself is only 555K. it is of course possible that
all that weight is desirable functionality.

I think 70k more disk space is not really a concern.


with that said, i would *still want to test on the target
environment*, to make sure i'm using libparted correctly there.
so that necessity remains.

I thought you didn't depend on libparted?


would this allay your concerns?

No, not really. I consider a partitioning tool to be too important
to be replaced by an unproven solution.

Growlight seems like an adequate tool for Debian expert option as it has 
potential to enable additional flexibility and extensibility for file 
system options which may not offered in the current set of Parted 
utilities. For instance, the current Growlight string/option 'enter 
filesystem name' could be re-implemented, with a couple lines of code, 
into something like 'enter plugin override'


< https://metztli.it/bullseye/gl/gl-reiser4-plugin-override.png >

etc., for other filesystems.


Also Growlight may reduce at least a subset of UDEB modules needed for 
each file system supported by Debian, thus reducing complexity. For 
instance, it was relatively straightforward to add support for reiser4 
-- as compared to initial efforts developing substantial code for a 
partman-[filesystem] UDEB module.


< https://metztli.it/bullseye/gl/growlight-reiser4.png >

In other words, even if there is no compelling reason to update d-i at 
the moment, Growlight has potential to decrease complexity in the long run.


Just a point of view from an outsider, of course, I do not want anyone 
'to have a cow' for refusing to potentially move away from their place 
of comfort and/or entertaining a perspective that may be considered 'taboo.'



Best Professional Regards.

--

Jose R R
http://metztli.it 
-
Download Metztli Reiser4: Debian Buster w/ Linux 5.13.14 AMD64
-
feats ZSTD compression https://sf.net/projects/metztli-reiser4/ 


-
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/ 


---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/ 

Bug#995183: ITP: libmarc-schema-perl -- specification of the MARC21 format as Perl data structures

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmarc-schema-perl
  Version : 0.09
  Upstream Author : Johann Rolschewski 
* URL : https://metacpan.org/release/MARC-Schema
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : specification of the MARC21 format as Perl data structures

MARC::Schema defines a set of MARC21 fields and subfields to validate
Catmandu::MARC records.

For a more detailed description of the (default) schema see MARC21 structure
in JSON: https://pkiraly.github.io/2018/01/28/marc21-in-json/.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#995184: ITP: libmarc-parser-xml-perl -- parser for MARC XML records

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmarc-parser-xml-perl
  Version : 0.03
  Upstream Author : Johann Rolschewski 
* URL : https://metacpan.org/release/MARC-Parser-XML
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : parser for MARC XML records

MARC::Parser::XML is a lightweight, fault tolerant parser for MARC XML
records. Tags, indicators and subfield codes are not validated against the
MARC standard. The resulting data structure is optimized for usage with the
Catmandu data tool kit.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: Future of /usr/bin/which in Debian?

[Jonathan Dowland]

Michael Stone wrote:

I think it doesn't matter how many which implementations are in debian.
If you want something with specific portable semantics, just use command
-v. The remaining consumers of which are either programs that (ipso
facto) don't care about semantic corner cases or are humans who want to
use which just because, and probably have strong opinions on how it
should behave (as, apparently, you do).


*I* don't; in Clint's categorization¹ I fall into (d) "wants there to be
exactly one version of `which` (except for all the shell builtins) so
that alternatives won't confuse and complicate things". The point I've
tried to make (too clumsily I guess) is the process of choosing one
should not be shoot-from-the-hip: there should be some consideration as
to which `which` would be the best fit for Debian. I hadn't seen any
evidence of that, until,

On Tue, Sep 21, 2021 at 05:41:49PM -0400, Nicholas D Steeves wrote:

I also think it may be more reasonable to prefer (by default, using the
alternatives mechanism) the more LSBish one (in this case GNU) rather
than the potentially more simple, clean, and full-featured one (BSD).


^ this is an example of exactly what I would have hoped took place to
decide upon which `which` we provided.


Thankfully we have the /etc/alternatives and Provides mechanisms to
affirm user choice in such cases, and I think most of us will agree this
is a totally equitable and reasonable compromise :-)


Unless there's a really compelling reason for there to be more than one
`which`, we could avoid the burden of alternatives entirely.


I should get off my soapbox now.


¹ Message-ID: 

--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Bug#995189: RFH: isc-dhcp

[Martin-Éric Racine]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: affects -1 src:isc-dhcp

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The ISC DHCP suite has a lenghty list of bug reports that have been left 
unattended. Some bugs date back to DHCP 3 or even earlier.

Additionally, recent upstream releases are still unpackaged. One release came 
out well ahead of the Bullseye freeze, a bug report requesting its packaging 
was filed, but it remains unanswered.

Leaving a package with a priority Important in such utter state of neglect is 
unacceptable.

At this point, it has become clear that, at the very least, its maintainers 
need help, hence why I filed this WNPP bug.

- -- Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFR/noACgkQrh+Cd8S0
17apRA/9EnsfZnMsWBz07360Z8fqdoZWteKo3Weqfa7lhfVXqHaaWKR1k83uY3gO
DEP+NGdDqMs5LVhQ4eDvEeMze2utCx52C2GFHebksI1QyaGruj9PSEu0j5CIBlKu
v/fXdk9BXk3oQ4bJoKM8HBifNVx/ICb1X/4wdr78dy4ZYQLB+XLkbQ5DGn/UJ4mr
VQctq/uxjFFY1zD+C5Mu7jG/X8eEbSXcshtMkxcoO3GW0c/Bmmy7Rm2exs1zHOkX
fAiULeThKPJkpYgbiw6+iPZiJqWeeoDtXo8gInuw8riP3sua9PxhEwKnZBEcACJ3
BAT5ethXxAhC5Ecd+pzuqzlTrP9FYDqPyie3If0A9XK1sDPsnnn5yERWeuAn8L2E
7tZ5BAuBCEskQ+Z9Q1MqgK8/yeabzZRzmd2VCy+FXMfENjhDeGm1YefPSD80mebG
UGVbN1MC9274pv6oomPkM6fQidIcbUIZDlBj2qJOxFWgXuv3jcnzWs4+XV9VssiD
s/B5+YC9XvItCpZKjAUBaXDUX/hzPqFoseRygRPChxgrzyvP7ChWSz1JY9G73EYg
ITe7KHQ9wqAMPJYmUp0ZmcACn9tCWH/xSt99KLrnYURPxNHcYpG8+Pwr5r9swJ50
fjkEyEZWCNUu6u8uUvSx5sPrc29aIpuk+QXeBJIsAB24roy8ONo=
=5hUD
-END PGP SIGNATURE-

Re: partman, growlight, discoverable partitions, and fun

[nick black]

Marc Haber left as an exercise for the reader:
> But maybe an alternative? I find the partitioning step one of the most
> error-prone and hard-to-use parts of non-trivial Debian installations.

so overall, i've got to say the feedback i heard here was a lot
more positive than i was expecting, though there was a bit less
than i had hoped for. but perhaps something that can be touched
would see more interest?

given that no one seemed to reject the idea out of hand, i'm
going to go ahead and rebase my work from 2012 (or more likely
look at it once and redo it) in a Salsa fork of d-i, and make
some installation media available. forgive me for likely only
having x86 available at first. i'll try to have this done within
a week or so, and put it up on my server. people can then give
it a whirl.

it's hard to see how exactly i proceed from that point, save in
a reactive fashion (not complaining, just saying). but we'll see
what happens when an ISO is available!

note that there would still be some questions where i'd need
input from Project members (as noted in my Debconf [0]
presentation), particularly regarding translation (even if i can
lift significant portions from partman, i'd need it looked
over) and facilitating accessibility technology.

--nick

[0] https://nick-black.com/dankwiki/images/b/b9/Parting_ways_with_partman.pdf

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: Bug#995189: RFH: isc-dhcp

[Noah Meyerhans]

On Mon, Sep 27, 2021 at 08:25:14PM +0300, Martin-Éric Racine wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> The ISC DHCP suite has a lenghty list of bug reports that have been left 
> unattended. Some bugs date back to DHCP 3 or even earlier.
> 
> Additionally, recent upstream releases are still unpackaged. One release came 
> out well ahead of the Bullseye freeze, a bug report requesting its packaging 
> was filed, but it remains unanswered.
> 
> Leaving a package with a priority Important in such utter state of neglect is 
> unacceptable.
> 
> At this point, it has become clear that, at the very least, its maintainers 
> need help, hence why I filed this WNPP bug.

It's worth noting also that ISC's DHCP client, packaged as
isc-dhcp-client from the isc-dhcp source package, is considered EOL
upstream.  As it's still the first recommended DHCP client by ifupdown,
and ifupdown is still Priority: important, most systems are likely to be
installing isc-dhcp-client.

We may want to start a broader conversation about the default DHCP
client package in Debian.  The maintainers of these packages should
obviously be involved.

For what it's worth, my preference would be transition to
systemd-networkd with bookworm.  If we keep the ifup/ifdown commands
from ifupdown at all, I think they should be fairly this wrappers around
their networkd equivalents.  I don't think we should install something
like netplan by default.

And, of course, environments that currently pull in NetworkManager
should continue to do so if it makes sense.  Although by default, I
believe that NetworkManager uses the ISC dhclient as its DHCP client, so
we may want to make changes there.  It has a built-in DHCP client, but
seems to prefer an external client if one is available.

(Of course, this conversation may already be taking place, but if so
I've missed it.  Please feel free to point me in the right direction.)

noah



signature.asc
Description: PGP signature

Re: Bug#995189: RFH: isc-dhcp

[Marco d'Itri]

On Sep 28, Noah Meyerhans  wrote:

Should it be mentioned what the new recommended DHCP server for general 
use will be?

> For what it's worth, my preference would be transition to
> systemd-networkd with bookworm.
I think that a good default would be systemd-networkd for servers and 
NetworkManager for systems with Wi-Fi or a GUI.

> If we keep the ifup/ifdown commands
> from ifupdown at all, I think they should be fairly this wrappers around
> their networkd equivalents.
This should be quite easy.

> I don't think we should install something
> like netplan by default.
I agree: it only adds complexity.

> (Of course, this conversation may already be taking place, but if so
> I've missed it.  Please feel free to point me in the right direction.)
No, I think that we did not have this flamewar yet.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#995219: ITP: gumble -- gumble is a Mumble client implementation in Go (golang)

[Bradford D. Boyle]

Package: wnpp
Severity: wishlist
Owner: Bradford D. Boyle 

* Package name: gumble
  Version : 0.0~git20200818.146f920-1
  Upstream Author : Tim Cooper https://github.com/layeh/gumble
* License : MPL-2.0
  Programming Lang: Go
  Description : Mumble client implementation in Go (golang)


This package is needed for barnard.

Re: Bug#995189: RFH: isc-dhcp

[Richard Laager]

On 9/27/21 9:15 PM, Marco d'Itri wrote:

On Sep 28, Noah Meyerhans  wrote:

Should it be mentioned what the new recommended DHCP server for general
use will be?


ISC Kea?

I haven't converted to it, but that's their replacement for dhcpd.


I think that a good default would be systemd-networkd for servers and
NetworkManager for systems with Wi-Fi or a GUI.


That seems reasonable.


I don't think we should install something
like netplan by default.



I agree: it only adds complexity.


I personally use netplan everywhere.

As to what should be the distro default, I'm not sure I am convinced 
either way, but to argue the other side... There is some value in using 
netplan by default. Some random thoughts:


This default would match Ubuntu. (I value reducing that delta. Not 
everyone does, and that's fine.)


netplan can configure both systemd-networkd and NetworkManager (though 
I've only used it with systemd-networkd).


In my non-trivial configurations, the netplan YAML input is half as many 
lines as its networkd output. This is with the input including a bit of 
comments and the boilerplate, disabling dhcp, and using YAML's more 
verbose list syntax (separate lines vs one line). I don't see anything 
wrong with its output that I could simplify.


Again, in this non-trivial configuration, I think it's more useful to 
have one netplan YAML file than 24 separate networkd files. This is 
especially true when I'm building this file from an Ansible template and 
most of it (by volume) is built by loops.


In the trivial case, it's 19 lines of netplan (16 if you exclude the 
stock comment) vs 25 lines of systemd-networkd, both in single files. 
That's not a huge difference.


--
Richard