what about Netplan?

[Philip Hands]

Simon McVittie  writes:

> On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote:
>> On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
>> > I believe NM does not have a fixed configuration format, but only a dbus 
>> > API.
>> 
>> It's perfectly fine to edit configuration files for NM manually, see
>> man:nm-settings-keyfile(5).
>
> ... and debian-installer already knows how to write out these files,
> and has done so for more than a decade if I'm reading correctly. This is
> not a recent innovation, and anyone who has installed our default desktop
> environment in the last few years - especially if they used wifi during
> installation - has been relying on this code path.
>
>  is responsible
> for converting the network configuration that was used temporarily in
> the d-i environment into a NM configuration file if NM is installed,
> or an ifupdown configuration otherwise. Writing the equivalents into
> /etc/systemd/network for systemd-networkd would presumably not be rocket
> science, it's a simple .ini-like syntax similar to the one NM uses.

We're just in the process of adding support for netplan as well:

  https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9

I've only seen netplan mentioned in passing in this thread so far.

It seems like it is exactly what we need as a replacemtent for ifupdown
(given that is what it's designed for AFAICT -- I've not yet tried it
out myself though) and it already supports configuring systemd-networkd,
so seems like a more sensible route than duplicating that effort in D-I.

See: https://netplan.readthedocs.io/

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Martin-Éric Racine]

ti 9. heinäk. 2024 klo 15.13 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> Users may choose to opt-in to the more declarative "use" stanzas if they
> wish and I'd expect any new upstream executors like vrf will need them
> (haven't tried) but not traditional stanzas or if-*.d based extensions.
>
> I wish ifupdown-ng upstream hadn't chosen to introduce an additional set of
> global config options in /etc/network/ifupdown-ng.conf and I am still
> mulling getting rid of that somehow but so far I don't see a real problem
> there.

That sort of needless additions precisely is what makes me doubt
whether ifupdown-ng is the way to go.

> > > Please note that the examples in the manpages are in what upstream
> > > considers the "proper new way" of doing things, they don't show the legacy
> > > way (also a good thing), you may have to read the code to get the full
> > > picture. Do let me know if any legacy-format behavioural
> > > reference-documentation is missing though.
> >
> > Claiming to offer a drop-in substitute all while nudging people
> > towards a new paradigm is not welcome.
>
> If ifupdown's paradigm were working for people we wouldn't be having this
> conversation.

The paradigm is working. What doesn't work is how a package with such
a high priority has repeatedly fallen into neglect. If people file bug
reports or request enhancements, but nothing happens, a fork is
unavoidable. In fairness, a few people have randomly stepped in, but
clearly don't have enough time to maintain it.

> How else would you move /etc/network/interfaces forward without breaking
> anything?

I would really like to hear what is wrong with the current format.

For my perspective, the main issues with ifupdown are:

1) ifupdown doesn't handle bridges and vlans without external
packages, yet it already depends upon iproute2, which provides 'ip'
i.e. a command that can handle these quite nicely.

2) ifupdown doesn't include a way to handle DHCPv6-PD for all
supported DHCP clients.

3) Since the introduction of systemd units, one can no longer rely on
interfaces being brought up sequentially following the order in which
they appear in /etc/network/interfaces.

4) That systemd unit generation blissfully ignores anything else that
physical interfaces in /etc/network/interfaces which introduces yet
more reproducibility problems.

Martin-Éric

Re: what about Netplan?

[Lukas Märdian]

On 11.07.24 09:16, Philip Hands wrote:

Simon McVittie  writes:


On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote:

On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:

I believe NM does not have a fixed configuration format, but only a dbus
API.


It's perfectly fine to edit configuration files for NM manually, see
man:nm-settings-keyfile(5).


... and debian-installer already knows how to write out these files,
and has done so for more than a decade if I'm reading correctly. This is
not a recent innovation, and anyone who has installed our default desktop
environment in the last few years - especially if they used wifi during
installation - has been relying on this code path.

 is responsible
for converting the network configuration that was used temporarily in
the d-i environment into a NM configuration file if NM is installed,
or an ifupdown configuration otherwise. Writing the equivalents into
/etc/systemd/network for systemd-networkd would presumably not be rocket
science, it's a simple .ini-like syntax similar to the one NM uses.


We're just in the process of adding support for netplan as well:

   https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9

I've only seen netplan mentioned in passing in this thread so far.

It seems like it is exactly what we need as a replacemtent for ifupdown
(given that is what it's designed for AFAICT -- I've not yet tried it
out myself though) and it already supports configuring systemd-networkd,
so seems like a more sensible route than duplicating that effort in D-I.

See: https://netplan.readthedocs.io/


Yes, please!
As Phil mentions, we're pretty close in getting D-I support for Netplan merged 
[d-i/netcfg !9].
The implementation enables Netplan+systemd-networkd for new installations, 
except for cases where NetworkManager is available (e.g. Desktop 
installations). In the latter case it would enable Netplan+NetworkManager, as 
it is today.

That way, we will be able to rely on the two most popular, well tested and well 
maintained networking daemons (systemd-networkd & NetworkManager), while also 
being able to use the common Netplan configuration language, controlling both 
(optionally!). Everybody is still free to write their own custom sd-networkd 
.network or N-M .nmconnection in /etc/ or configure the daemon through 
corresponding D-Bus APIs or GUI/TUI applications, by just not putting any 
configuration for a given interface into /etc/netplan/.

Netplan should be considered a unification layer on top of those networking 
daemons, which allows Debian as a project to use common language around networking, 
e.g. in Debian-Installer [d-i/netcfg !9], [cloud] deployments or [documentation], 
independent of the chosen backend daemon (sd-networkd on Cloud & Server, 
NetworkManager on Desktop).

Additional benefits of Netplan:
* Already used on Debian Bookworm [cloud] images by default
* Well tested (big autopkgtest suite) and supported by a company
* Lots of knowledge, Q/A & tutorials on the internet, as its being used by 
millions of people since many years
* Proven track record, being the default for several Ubuntu LTS releases
* Python dependency considered optional, base installations only need the 
"netplan-generator" package
* Solid documentation and a stable API for libnetplan, as of [Netplan 1.0]

This would allow us to combine the best of two worlds, while leaving everybody 
with full flexibility for custom configurations.
In addition to that, I'd propose to keep ifupdown in maintenance mode for a 
transitional period (Trixie at least), to keep backwards compatibility for 
existing systems and give people some time in transitioning to new networking 
tools.

Cheers,
  Lukas

PS: If you happen to be at Debconf in Korea in a few weeks, please join my 
[networking BoF].


[d-i/netcfg !9] 
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9
[cloud] 
https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/
[documentation] 
https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_cloud
[Netplan 1.0] 
https://blog.slyon.de/2024/04/04/netplan-v1-0-paves-the-way-to-stable-declarative-network-management/
[networking BoF] 
https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/

Re: what about Netplan?

[Marco d'Itri]

On Jul 11, Philip Hands  wrote:

> I've only seen netplan mentioned in passing in this thread so far.
Because I believe that Netplan is the answer to a question that nobody 
asked here.

It has all the disadvantages of switching to a new configuration format, 
but then it limits you to the features that it actually implements from 
each backend and you have an indirection layer that must be used when 
interacting with the backend daemon.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Marco d'Itri]

On Jul 11, Vincent Bernat  wrote:

> This is quite unfair. Cumulus tried very hard to make ifupdown2 a community
> projects, with notably a presentation at Debconf 14 and Debconf 16. One of
> its killer feature is the ability to go from the running state to the target
> state with one command (ifreload). It never took as we prefer old broken
> software over something not 100% compatible and also because it is written
> in Python and we didn't want Python in the base installation.
I agree, but I think that the dependency on Python has legitimately been 
a deal breaker.

> Since Cumulus has been bought by Nvidia, things have changed and development
> of ifupdown2 is now done behind closed doors. See
> https://github.com/CumulusNetworks/ifupdown2/pull/271#issuecomment-1706260260
And this pretty much closes the question.
(And makes me even more annoyed for having bought switches from Nvidia.)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: default network management tools

[Lukas Märdian]

On 11.07.24 02:18, Thomas Goirand wrote:

On 7/10/24 20:03, Michael Biebl wrote:

Since there is a lot of support for this idea, the next logical step as smcv 
said, would be to make d-i/netcfg networkd aware. At the beginning, this could 
be opt-in (for testing purposes) and we could make it the default later on.

Any takers?


If someone were to add that support in d-i for Trixie, that'd be great. Even 
better IMO, if it had support for Netplan. Then we could switch the default for 
Forky?


We're actually pretty close in getting D-I support for Netplan merged 
[d-i/netcfg !9], which would enable Netplan+systemd-networkd for new 
installations by default. In addition to that it supports 
Netplan+NetworkManager backend for Desktop installations, as it is today.

That way, we will be able to rely on the two most popular, well tested and well 
maintained networking daemons (systemd-networkd & NetworkManager), while also 
being able to use the common Netplan configuration language, controlling both 
(optionally!). Everybody is still free to write their own custom sd-networkd 
.network or N-M .nmconnection in /etc/ or configure the daemon through 
corresponding D-Bus APIs or GUI/TUI applications, by just not putting any 
configuration for a given interface into /etc/netplan/.

Netplan should be considered a unification layer on top of those networking 
daemons, which allows Debian as a project to use common language around networking, 
e.g. in Debian-Installer [d-i/netcfg !9], [cloud] deployments or [documentation], 
independent of the chosen backend daemon (sd-networkd on Cloud & Server, 
NetworkManager on Desktop).

Additional benefits of Netplan:
* Already used on Debian Bookworm [cloud] images by default
* Well tested (big autopkgtest suite) and supported by a company
* Lots of knowledge, Q/A & tutorials on the internet, as its being used by 
millions of people since many years
* Proven track record, being the default for several Ubuntu LTS releases
* Python dependency considered optional, base installations only need the 
"netplan-generator" package
* Solid documentation and a stable API for libnetplan, as of [Netplan 1.0]

This would allow us to combine the best of two worlds, while leaving everybody 
with full flexibility for custom configurations.
In addition to that, I'd propose to keep ifupdown in maintenance mode for a 
transitional period (Trixie at least), to keep backwards compatibility for 
existing systems and give people some time in transitioning to new networking 
tools.

Cheers,
  Lukas

PS: If you happen to be at Debconf in Korea in a few weeks, please join my 
[networking BoF].


[d-i/netcfg !9] 
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9
[cloud] 
https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/
[documentation] 
https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_cloud
[Netplan 1.0] 
https://blog.slyon.de/2024/04/04/netplan-v1-0-paves-the-way-to-stable-declarative-network-management/
[networking BoF] 
https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/

Re: ifupdown maintenance

[Marco d'Itri]

On Jul 10, Simon Richter  wrote:

> It is supported *now*, but the roadmap is unclear -- that support could be
> discontinued at any moment, and it would not be the first time a feature
> Debian relied on was removed.
You have manufactured a non-existing issue and then decided to get 
anxious about it. I do not believe that I can help you further.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Daniel Gröber]

Hi Vincent, Martin,

On Thu, Jul 11, 2024 at 07:54:50AM +0200, Vincent Bernat wrote:
> >  From where I'm sitting ifupdown2 is completely out of the question as *the*
> > Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like
> > DHCPv6. Upstream community seems nonexistant since this is software by a
> > corp for a corp where community building was probably never the
> > goal. Admittedly I didn't look very hard, this is just my impression
> > currently.
> 
> This is quite unfair. Cumulus tried very hard to make ifupdown2 a
> community projects, with notably a presentation at Debconf 14 and Debconf
> 16.  [...] It never took as we prefer old broken software over something
> not 100% compatible and also because it is written in Python and we
> didn't want Python in the base installation.
> 
> Since Cumulus has been bought by Nvidia, things have changed and development
> of ifupdown2 is now done behind closed doors. See
> https://github.com/CumulusNetworks/ifupdown2/pull/271#issuecomment-1706260260

Right, I wasnt around for those, my impressions are based on post-nvidia
ifupdown2. That being said it doesn't change it's unfortunate current
state. I don't see any community activity on *2 whereas *-ng has a fair bit
and an impressive array of executors already with more coming
https://github.com/ifupdown-ng/ifupdown-ng/tree/main/executor-scripts/linux

> One of its killer feature is the ability to go from the running state to
> the target state with one command (ifreload). 

Yeah I agree that's useful it would be nice if it can fit into
ifupdown-ng's design but I think upstream made a good decision in not
imposing the additional complexity to support it on the executors from the
start.

Maybe we can still add it. Someone more interested in that feature ought to
have a look *hint* *hint* :)



On Thu, Jul 11, 2024 at 11:23:38AM +0300, Martin-Éric Racine wrote:
> > > Claiming to offer a drop-in substitute all while nudging people
> > > towards a new paradigm is not welcome.
> >
> > If ifupdown's paradigm were working for people we wouldn't be having this
> > conversation.
> 
> The paradigm is working.

I mean looking at the other half of this thread, clearly the ifupdown*
paradigm isn't working at all for some people which I think is
unfortunate. I just want to point out that -ng comes as a library too
(which I haven't packaged separately yet) so integrating with
/etc/network/interfaces and even the interface state should very much be
possible for any other network managment tool that would want to.

I still think you're making too much of this `use` feature. I had a
conversation with upstream about it and took another look at the code and
it's basically just an optimization to *only* run the delcared executors as
opposed to all of them (in case any of their config stanzas are used).

I think it may let you sidestep issues with if*.d stanza namespacing issues
too, but that's about it. If you don't like it don't use it. I certainly
have not had a need for it so far.

> > How else would you move /etc/network/interfaces forward without breaking
> > anything?
> 
> I would really like to hear what is wrong with the current format.

I'd like to hear what is wrong with making the current format more
extensible with full legacy compatibility?

The format is fine, but ofc. ifupdown-ng is going to extend it where it
makes sense.

> For my perspective, the main issues with ifupdown are:
> 
> 1) ifupdown doesn't handle bridges and vlans without external
> packages, yet it already depends upon iproute2, which provides 'ip'
> i.e. a command that can handle these quite nicely.

Not quite true, vlan support is now internal AFAIK, or at least I haven't
installed `vlan` in ages and things seem to work :)

The ifupdown-ng executors for vlan/ bridge support are here if you want to
have a look:
https://github.com/ifupdown-ng/ifupdown-ng/blob/main/executor-scripts/linux/link
https://github.com/ifupdown-ng/ifupdown-ng/blob/main/executor-scripts/linux/bridge

> 2) ifupdown doesn't include a way to handle DHCPv6-PD for all
> supported DHCP clients.
> 
> 3) Since the introduction of systemd units, one can no longer rely on
> interfaces being brought up sequentially following the order in which
> they appear in /etc/network/interfaces.

ifupdown-ng's dependency resolution based "paradigm shift ;)" should make
that unecessary, but perhaps that calls for another ifupdown-ng.conf
option? Not sure. Why is the order important outside of the obvious master
device dependencies?

> 4) That systemd unit generation blissfully ignores anything else that
> physical interfaces in /etc/network/interfaces which introduces yet
> more reproducibility problems.

Not sure what you're talking about here?

--Daniel


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Stephan Seitz]

Am Di, Jul 09, 2024 at 20:03:52 +0200 schrieb Matthias Urlichs:
Well, I've been apt-purging ifupdown for almost a decade by now and 
didn't yet miss any of it.


I would never purge ifupdown. I like the nice configuration in one file 
that you can find no matter if it is an old or new Debian installation.


We had to migrate a lot of VMs from one infrastructure to another. VMs 
with the good old eth0/1/2 interfaces were the easiest. No changes here.


The „new” ensXYZ interfaces (what a bullshit) had to be changed. Debian 
systems with /etc/network/interfaces were simple. One file for all 
changes.


Centos has its files in /etc/sysconfig/network-scripts. Okay, was alright 
as well.


And then was the Ubuntu bullshit with NM. Where are the configuration 
files now? And Ubuntu 24 migrated everything to Netplan. Where is the 
stupid configuration now?


So, no, never. Ifupdown is the correct way for a Debian installation.

Stephan

--
|If your life was a horse, you'd have to shoot it.|

Re: default network management tools

[Matthias Urlichs]

On 11.07.24 08:13, Marc Haber wrote:

Therefore, you could change
configuration while the Interfacce was up and then just say "ifdown ;
ifup" and be fine. No network configuration software up to today has
THAT feature.


Shouldn't "systemctl reload systemd-networkd" do exactly that?

--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: ifupdown maintenance

[Martin-Éric Racine]

to 11. heinäk. 2024 klo 12.34 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> On Thu, Jul 11, 2024 at 11:23:38AM +0300, Martin-Éric Racine wrote:
> > > > Claiming to offer a drop-in substitute all while nudging people
> > > > towards a new paradigm is not welcome.
> > >
> > > If ifupdown's paradigm were working for people we wouldn't be having this
> > > conversation.
> >
> > The paradigm is working.
>
> I mean looking at the other half of this thread, clearly the ifupdown*
> paradigm isn't working at all for some people which I think is
> unfortunate. I just want to point out that -ng comes as a library too
> (which I haven't packaged separately yet) so integrating with
> /etc/network/interfaces and even the interface state should very much be
> possible for any other network managment tool that would want to.

I haven't see anyone answer the question of what doesn't work with ifupdown.

> I still think you're making too much of this `use` feature. I had a
> conversation with upstream about it and took another look at the code and
> it's basically just an optimization to *only* run the delcared executors as
> opposed to all of them (in case any of their config stanzas are used).

Whcih still could be accomplished using the 3rd item of the
traditional ifdown line.

> > > How else would you move /etc/network/interfaces forward without breaking
> > > anything?
> >
> > I would really like to hear what is wrong with the current format.
>
> I'd like to hear what is wrong with making the current format more
> extensible with full legacy compatibility?
>
> The format is fine, but ofc. ifupdown-ng is going to extend it where it
> makes sense.
>
> > For my perspective, the main issues with ifupdown are:
> >
> > 1) ifupdown doesn't handle bridges and vlans without external
> > packages, yet it already depends upon iproute2, which provides 'ip'
> > i.e. a command that can handle these quite nicely.
>
> Not quite true, vlan support is now internal AFAIK, or at least I haven't
> installed `vlan` in ages and things seem to work :)

I said ifupdown, not ifupdown-ng.

> > 4) That systemd unit generation blissfully ignores anything else that
> > physical interfaces in /etc/network/interfaces which introduces yet
> > more reproducibility problems.
>
> Not sure what you're talking about here?

ifupdown has helpers that dynamically generate systemd service units
upon bootup. It only generates them for en* and wl* interfaces, which
are then started at random according to systemd preferences. Later in
the boot process, a generic networking.service unit is run to bring up
everything else found in /etc/network/interfaces e.g. vlan, bridges.

Martin-Éric

Bug#1076138: ITP: korean-lunar-calendar -- Korean lunar to Gregorian calendar conversion library

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: korean-lunar-calendar
  Version : 0.3.1
  Upstream Author : Jinil Lee 
* URL : https://github.com/usingsky/korean_lunar_calendar_py
* License : MIT
  Programming Lang: Python
  Description : Korean lunar to Gregorian calendar conversion library

  Convert between the Korean lunar calendar and the Gregorian calendar. The
  Korean calendar, while similar to the Chinese lunar calendar, features
  different dates. The library adheres to the standards set by the Korea
  Astronomy and Space Science Institute (KARI).
  .
  Supports lunar date conversions from 1000-01-01 to 2050-11-18 and solar date
  conversions from 1000-02-13 to 2050-12-31.
  .
  No network connection is required for these operations.

I plan to maintain this package as part of the Python team.

Re: what about Netplan?

[Lukas Märdian]

On 11.07.24 11:13, Marco d'Itri wrote:

On Jul 11, Philip Hands  wrote:


I've only seen netplan mentioned in passing in this thread so far.

Because I believe that Netplan is the answer to a question that nobody
asked here.

It has all the disadvantages of switching to a new configuration format,
but then it limits you to the features that it actually implements from
each backend and you have an indirection layer that must be used when
interacting with the backend daemon.


Yes, it brings a new configuration format. So do systemd-networkd and 
NetworkManager.

Netplan's feature set is pretty comprehensive and certainly enough for a 
default installation,
see its reference: https://netplan.readthedocs.io/en/stable/netplan-yaml/

But it's not an indirection layer that MUST be used. Should the features of 
Netplan not be enough
for an advanced usecase, everybody is free to write configuration for the 
underlying backend directly.

Netplan will not interfere with that and go out of the way. Just don't write 
Netplan configuration
for a specific interface (or all of them) that you want to handle differently.

-- Lukas

Re: default network management tools

[Marco d'Itri]

On Jul 11, Matthias Urlichs  wrote:

> On 11.07.24 08:13, Marc Haber wrote:
> > Therefore, you could change
> > configuration while the Interfacce was up and then just say "ifdown ;
> > ifup" and be fine. No network configuration software up to today has
> > THAT feature.
> Shouldn't "systemctl reload systemd-networkd" do exactly that?
Indeed, it does.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Santiago Ruano Rincón]

El 09/07/24 a las 11:25, Daniel Gröber escribió:
> Hi Santiago,
> 
> On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón wrote:
> > > > Santiago, how do you feel about ifupdown's future maintainability and
> > > > feature development? I honestly never looked into why people started
> > > > writing ifupdown replacements. I had my own gripes with it so I never
> > > > questioned it but I'm happy to hear why we should all rally around it.
> > > 
> > > I've long wondered how we ended up with so many implementations. Team
> > > maintenance of just one implementation would make more sense.
> > > 
> > > > For me the reason to work on ifupdown-ng is that it has a better core
> > > > design, clean&modern code, an active upstream community, a ***test
> > > > suite***
> > 
> > I fully acknowledge this. After trying to fix some of the ifupdown bugs
> > but hitting some design issues, 
> 
> Can you elaborate on that point? What are the sort of issues you run into
> with the traditional ifupdown design and/or it's maintenance.

For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396.
Fixing it is not trivial.

> > I think it makes more sense to focus all
> > the efforts in just one of the implementations, and since ifupdown-ng
> > has all the above mentioned advantages, I'd would be in favor of
> > replacing ifupdown by ifupdown-ng...
> 
> Good to hear.
> 
> From the looks of the BTS page I feel like part of the burdon of
> maintaining ifupdown is that people just default to reporting any
> networking issues there, is that something you see a lot?

No, not really.

> Perhaps we should have a debian-networking mailing list as Maintainer to be
> able to load-share the user-support better?

I'd happy with that!

> > > > and the potential to fully replace ifupdown without breaking anyone's
> > > > system doing it. Full compatibility is not there yet. I'm working on it,
> > > > see [1] but I'm optimistic so far.
> > > >
> > > > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
> > > 
> > > Noted.
> > 
> > ... but it would be *great* to make ifupdown-ng a drop-in replacement
> > first.
> 
> Naturally.
> 
> It is pretty close though. The remaining issues I know about are documented
> in the GH issue: the locking protocol is sligtly suboptimal (and more
> importantly for interop: different), ifstate file is separate and interface
> renaming ("rename" statanza) isn't supported. I didn't even know that last
> one existed, does anyone use those?

Yes, I am aware there are users of the rename stanza.

> If you're on-board with transitioning to -ng that should make the ifstate
> compat pretty easy since we can freeze the old format and behaviour.
> 
> I haven't thrown -ng at a large legacy setup in anger yet (since I don't
> have any), but for regular desktop usage with some mildly custom stuff in
> /etc/network/interfaces I hardly notice which ifupdown* I have installed.
> 
> Note: For testing you have to keep in mind to (tranditional) ifdown the
> ifaces you want to test first since the ifstate is still disjoint
> currently.

ACK.

[snip]

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Re: default network management tools

[Marc Haber]

On Thu, 11 Jul 2024 13:48:06 +0200, Marco d'Itri  wrote:
>On Jul 11, Matthias Urlichs  wrote:
>
>> On 11.07.24 08:13, Marc Haber wrote:
>> > Therefore, you could change
>> > configuration while the Interfacce was up and then just say "ifdown ;
>> > ifup" and be fine. No network configuration software up to today has
>> > THAT feature.
>> Shouldn't "systemctl reload systemd-networkd" do exactly that?
>Indeed, it does.

When I tried it last time, it didnt remove changed addresses, just
added the new ones. Maybe it grew that functionality in the mean time
and I didnt notice.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Bug#1076144: ITP: python-jq -- lightweight and flexible JSON processor

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-jq
  Version : 1.7.0
  Upstream Contact: Michael Williamson 
* URL : https://github.com/mwilliamson/jq.py
* License : BSD-2-clause
  Programming Lang: Python
  Description : lightweight and flexible JSON processor

 A lightweight and flexible JSON processor that provides Python bindings for jq.

I intend to maintain it as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmaPzHkbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFq9FoH/RILM4s9aZRYxlMPK3Wu
MxhOK8kfJ7/ZO/DhK3uZaXjWjBe+7yKMVnjYBg+RL9QGCevlBRiscO4pfJm1DLwh
FO7Hf1aez9CJ1OKAwY7UhhbrRz/PlPTsp89DgC+Y39U6g8ceoxHc5nJrUud0/sJM
fU2f2shyOHBdxYqbGr1oQ3IjO1ZkuNKLtbRa8+PLiBNQGumGqqjxg1FPHZt/e9M2
6JiizqHAHgZ1AjNfOC9wRNohcxjKm/aMykbAkXiCnSYhvhOUrnMLFsuiU2yo1MqS
/t2ESlmKpnH2ORwJn5gzLC9pGAyGhGhEPfvOQFl3x+S8brkjktQbnJxF02XwdVDv
qyk=
=SB98
-END PGP SIGNATURE-

Re: default network management tools (was: ifupdown maintenance)

[Santiago Ruano Rincón]

El 09/07/24 a las 11:45, Simon McVittie escribió:
> On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote:
> > Agreed: either it's drop-in compatible or we may as well switch the
> > default to NM and/or systemd-networkd.
> > 
> > Well, here's a heretical thought: why don't we do that anyway, at least for 
> > new
> > installations?
> 

[snip]

> ... See my recent mail about how we should probably not be inventing
> Debian-specific container frameworks that will end up with one overworked
> maintainer being a single point of failure for the distribution, but
> replace "container framework" with "network management tool" and the
> same ideas are equally valid. Like Podman in the containers space, NM
> and systemd-networkd both have the advantage of being used outside the
> Debian bubble, sharing the responsibility for their continued existence
> among *considerably* more people.

ACK. This is a sound argument. Thanks.

 -- Santiago


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Matthias Urlichs]

On 10.07.24 22:14, Simon Richter wrote:
It is supported *now*, but the roadmap is unclear -- that support 
could be discontinued at any moment, and it would not be the first 
time a feature Debian relied on was removed. 


I don't think that the systemd people have *any* intention to 
substantially change their configuration file structure or whatnot. If 
they ever do, we should (and will!) raise our concerns then.


Right now we have other problems that are way more important IMHO, given 
210 open bugs on ifupdown. (#81219  is 
from January 2001.)


Debian-specific not-quite-Secret Sauce is fine when it adds value 
compared to other distributions (and doesn't require a disproportionate 
amount of Debian-specific knowledge). In this case however I'd argue 
that in the vast majority of cases, ifupdown does not add value.


Not any more. The ecosystem has changed significantly in the last 
quarter century.


Instead we have a maintenance burden — one which isn't exactly lightened 
by the fact that there are four implementations of ifupdown that do more 
or less the same thing. (In case you're wondering: #4 is busybox.)


--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: ifupdown maintenance

[Jose Luis Tallon]

On 11/7/24 8:16, Marc Haber wrote:

On Wed, 10 Jul 2024 23:15:24 +0200, Ansgar ?  wrote:
While there are numerous alternative implementations of DHCP client,
the Linux world seems to be without a working DHCP relay
implementation in those days. That's REALLY bad for an installation
with Linux routers.
Are there any specific requirements --- such as "must be written in 
extra-portable C" --- that any alternative implementation should fulfil ?


At $work we have a dhcp-manythings implementation (in Go) that *might* 
fill the gap. Probably easy to get publicly published+supported.


Just asking.


Thanks,

--

Parkinson's Law: Work expands to fill the time alloted to it.

Re: ifupdown maintenance

[Jose Luis Tallon]

Jumping in in the middle of the conversation, but couldn't resist 

On 11/7/24 10:23, Martin-Éric Racine wrote:

Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.

If ifupdown's paradigm were working for people we wouldn't be having this
conversation.

[snip]
For my perspective, the main issues with ifupdown are:

1) ifupdown doesn't handle bridges and vlans without external
packages, yet it already depends upon iproute2, which provides 'ip'
i.e. a command that can handle these quite nicely.

2) ifupdown doesn't include a way to handle DHCPv6-PD for all
supported DHCP clients.

3) Since the introduction of systemd units, one can no longer rely on
interfaces being brought up sequentially following the order in which
they appear in /etc/network/interfaces.

4) That systemd unit generation blissfully ignores anything else that
physical interfaces in /etc/network/interfaces which introduces yet
more reproducibility problems.


Been working on-and-off on an alternative **guaranteed drop-in** 
alternative for a while, for precisely the same reasons people are 
mentioning in this thread.


Marco D'Itri, Marc Haber, Bernd Zeimetz, Simon Richter, Martin-Éric 
Racine, Stephan Seitz, Daniel Gröber and others provided invaluable 
feedback on this matter.



Should I be able to release something (maybe a far-fetched proposition) 
more or less covering the need, what would be the *hard* requirements to 
have it adopted ??


We are in the same need on my side; might as well not waste too much 
effort needlessly  :)




Thanks,

--
Parkinson's Law: Work expands to fill the time alloted to it.

Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: dh-rust
  Version : 0.0.1
  Upstream Contact: build-common team 
* URL : https://salsa.debian.org/build-common-team/dh-rust
* License : GPL-3+
  Programming Lang: Perl
  Description : debhelper buildsystem for Rust code

 dh-rust provides a debhelper buildsystem to build Rust code.
 .
 This builds and tests binaries and libraries from rust crates,
 the latter installed as source code below /usr/share/cargo/registry.
 .
 Feature highlights, compared to dh-cargo:
  * supports workspace (i.e. multi-crate project)
  * allows overriding CARGO_HOME
  * installs crate contents using "cargo package"
  * can use debian/Cargo.lock or Cargo.lock during build
  * uses crates below debian/vendorlibs when available
  * builds in make target dh_auto_build (not dh_auto_test)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaQAvoACgkQLHwxRsGg
ASEvTQ//W+YQjP71QIGyP3bgs2Sow8pSRga9BkbY7vjGNGGih9FPGFxDmG18dSV0
JcLHuksh+kjHxoDoFpufOLcNTBPf3AQG6O6VuySxt7cG9L27w1a7jxKBXvKtDAtW
7ZBEi/fySLj5PyHYyZWY2fLmhEzBMmuNcY/l1wBklktF5Jkc7mwYSaqI/3mMxeeE
pa6btQuW3Mdf3SyZEc05eriNIi9A6wBTy0Yc+m7oU2QGo+2ckXy3hOcN2SjQR5OM
/h3NydY+bXP8V9Sz/wJ0qhep89Mh/CvEcKeNyw1BbKCHr1e+4UQ8WzEsWSq9c1+c
f8woy3KNbtt1JXpCaJcM2I+PBOIaZ0HupV4IzQYevbpSawgnLY5AsGruJgAHiERj
GVdBrykEj2YHfhw6clqJVTxx2sVYifLgOu5RiM4dGsBwMf0DpuqWXh3HeXnS6Z81
2xj0PTA5t38bQsqLW0JU1IOvzR4m/40SDMpTWo3FjWpc263QmjFMRXSVaUha8qQs
fV9WhL0jTjvNbrUxRM7jKaPyioGXk+RjXQtCJwAG5moJxDVVQD65oQy6Z0q+yZqF
xq9HLaqrC6At2rTyUxCVK5IDavMYXAL+IB7rkJ6ahG7ThDh8cPuSC5+0Ss2f65tB
QtAqmxKPvjr0uLUeMQAvMLWagKKVP39gmtLL7o5LH8OFhZ2DDIM=
=oOzs
-END PGP SIGNATURE-

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Fabian Grünbichler]

On Thu, Jul 11, 2024 at 06:06:21PM GMT, Jonas Smedegaard wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team 
> 

Hi!

(all of what follows is my personal opinion and not coordinated with
other members of the Rust packaging team).

I know the team and you have had differences in the past about how to
approach packing crates and/or software written in Rust, and I can and
do respect the technical aspects of that (at least in parts).

Some sort of attempt to reconcile your pre-existing vendored forks of
the rust-team tooling with the original source, or at least a heads-up
about this plan of yours would have been appreciated. I don't see any
technical obstacles for having a single set of low-level Rust-helper
tools for packaging. I see a lot of downsides to having two such sets
that are 90% compatible, but subtly different and drifting apart over
time.

Please (seriously!) reconsider this, and try to work together with the
existing Rust team to develop a/the common set of (low-level) tooling
and helpers. A lot of the team members are also packaging
Rust-related/using software outside of debcargo-conf (e.g., as part of
the Gnome team), and desire similar features that you do for your
workspace-based, packaged from git crates.

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: dh-rust

The name is pretty misleading IMHO, this is dh-cargo and a helper from
the cargo package, forked and renamed (and extended), even though it is
not Rust or rustc, but cargo that is the target here..

You also conveniently fail to mention that this is a (personal) fork of
existing packages/scripts from existing packages.

>   Version : 0.0.1
>   Upstream Contact: build-common team 
> * URL : https://salsa.debian.org/build-common-team/dh-rust
> * License : GPL-3+

This part in particular almost seems like a hostile takeover - the
original tools are all MIT or Apache-2.0 licensed (the latter is not
mentioned in your git history, but the cargo wrapper is copied from
src:cargo or src:rust, which lists it as dual-licensed), and while you
kept the copyright notices, you didn't keep the license text (which
makes this a violation of the original license that require keeping it,
at least covering those parts originally written under that license -
unless you've actually gotten permission from all of the original
authors and just didn't mention that anywhere..).

With your "relicensing" you effectively made your forks live on the end
of a one-way street - you can take changes made in the original tools
authored by the Rust team, but prevent us from incorporating changes you
(or other contributors) do on your end, unless they are explicitly
dual-licensed, or our tools need to relicensed as well.

While this is obviously okay for you to do from a license stand point
(provided you keep the original license texts as well? but IANAL,
etc.pp.), it's a bit like a slap in the face to your fellow Debian
members in the Rust team, especially given the lack of communication.

>   Programming Lang: Perl
>   Description : debhelper buildsystem for Rust code
> 
>  dh-rust provides a debhelper buildsystem to build Rust code.
>  .
>  This builds and tests binaries and libraries from rust crates,
>  the latter installed as source code below /usr/share/cargo/registry.
>  .
>  Feature highlights, compared to dh-cargo:
>   * supports workspace (i.e. multi-crate project)
>   * allows overriding CARGO_HOME
>   * installs crate contents using "cargo package"
>   * can use debian/Cargo.lock or Cargo.lock during build
>   * uses crates below debian/vendorlibs when available
>   * builds in make target dh_auto_build (not dh_auto_test)

This is also factually wrong - dh-cargo doesn't build in dh_auto_test,
it tests there. It builds in dh_auto_install, and I am currently working
on changing that as part of integrating cdylib support..

But note that there is a reason it's done that way currently - cargo
handles configs (including the override for using packaged crates)
differently in `install` vs `build` - the latter can pick up a wrong
config shipped by the crate/project itself, with higher precedence than
the one managed by the wrapper, with all sorts of "fun" side-effects.

> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaQAvoACgkQLHwxRsGg
> ASEvTQ//W+YQjP71QIGyP3bgs2Sow8pSRga9BkbY7vjGNGGih9FPGFxDmG18dSV0
> JcLHuksh+kjHxoDoFpufOLcNTBPf3AQG6O6VuySxt7cG9L27w1a7jxKBXvKtDAtW
> 7ZBEi/fySLj5PyHYyZWY2fLmhEzBMmuNcY/l1wBklktF5Jkc7mwYSaqI/3mMxeeE
> pa6btQuW3Mdf3SyZEc05eriNIi9A6wBTy0Yc+m7oU2QGo+2ckXy3hOcN2SjQR5OM
> /h3NydY+bXP8V9Sz/wJ0qhep89Mh/CvEcKeNyw1BbKCHr1e+4UQ8WzEsWSq9c1+c
> f8woy3KNbtt1JXpCaJcM2I+PBOIaZ0HupV4IzQYevbpSawgnLY5AsGruJgAHiERj
> GVdBrykEj2YHfhw6clqJVTxx2sVYifLgOu5RiM4dGsBwMf0DpuqWXh3HeXnS6Z81
> 2xj0PTA5t38bQsqLW0JU1IOvzR4m/40SDMpTWo3FjWpc263QmjFMRXSVaUha8qQs
> fV9WhL0jTjvNbrUxRM7jKaPyi

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Nilesh Patra]

On Thu, Jul 11, 2024 at 06:06:21PM +0200, Jonas Smedegaard wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: dh-rust

I would be happy if this makes it to the archive, though. Would be easier to
have a dh for rust which would be specifically useful to build packages that are
not just crates, but instead use multiple language including but not limited to
rust.

As an addendum, also gives freedom to maintain packages outside of the giant git
repo of crates, without having to embed this code in every such outside-of-team
maintained package.

Best,
Nilesh


signature.asc
Description: PGP signature

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Fabian Grünbichler]

On July 11, 2024 7:57:56 PM GMT+02:00, Nilesh Patra  wrote:
>On Thu, Jul 11, 2024 at 06:06:21PM +0200, Jonas Smedegaard wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Jonas Smedegaard 
>> X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team 
>> 
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> * Package name: dh-rust
>
>I would be happy if this makes it to the archive, though. Would be easier to
>have a dh for rust which would be specifically useful to build packages that 
>are
>not just crates, but instead use multiple language including but not limited to
>rust.
>
>As an addendum, also gives freedom to maintain packages outside of the giant 
>git
>repo of crates, without having to embed this code in every such outside-of-team
>maintained package.

Both is already possible using the existing cargo wrapper, which is separate 
from both dh-cargo and debcargo and its monorepo for that reason. gaps in what 
that wrapper covers can (and should, see my full reply about an example) be 
closed. That is not easier if there are two such wrappers. All of that also 
applies to dh-cargo (-built-using). It is called by Debcargd, not the other way 
round.

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Jonas Smedegaard]

Hi Nilesh,

Quoting Nilesh Patra (2024-07-11 19:57:56)
> On Thu, Jul 11, 2024 at 06:06:21PM +0200, Jonas Smedegaard wrote:
> > * Package name: dh-rust
> 
> I would be happy if this makes it to the archive, though. Would be
> easier to have a dh for rust which would be specifically useful to
> build packages that are not just crates, but instead use multiple
> language including but not limited to rust.

Indeed.

We are not familiar with many non-cargo-centric Rust projects, but know
that they exist.  Personally I am aware of only Mozilla projects and one
project using Cargo-in-meson.

Please (when/if accepted into Debian) file wishlist bugreports this
package for concrete examples of interesting Rust projects that might
benefit from non-cargo-centric packaging debhelper tooling, then we can
discuss if reasonable to extend this package to cover them.

Kind regards,

 - 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

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Philipp Kern]

Hi,

On 11.07.24 18:06, Jonas Smedegaard wrote:

* Package name: dh-rust
   Version : 0.0.1
   Upstream Contact: build-common team 
* URL : https://salsa.debian.org/build-common-team/dh-rust


This ("build-common") reminded me of cdbs. Can we not have another 
schism and actually work together?


cdbs also got orphaned but its legacy not cleaned up. I still count 1.6k 
reverse build-depends in unstable.


I'd - at the very least - would like to see a statement why a fork is 
necessary. Innovation can happen in forks. But they don't necessarily 
need to be in the archive to make a point.


Kind regards
Philipp Kern

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Jonas Smedegaard]

Quoting Philipp Kern (2024-07-11 21:13:42)
> On 11.07.24 18:06, Jonas Smedegaard wrote:
> > * Package name: dh-rust
> >Version : 0.0.1
> >Upstream Contact: build-common team 
> > 
> > * URL : https://salsa.debian.org/build-common-team/dh-rust
> 
> This ("build-common") reminded me of cdbs. Can we not have another 
> schism and actually work together?

Sorry, what?

How is "build-common" or CDBS incompatible with "work together"?

Licensecheck use build-common for upstream development, does that make
licensecheck incompatible with "work together" as well, or where is that
fine line that I seemingly have crossed by my choice of contact address?


> cdbs also got orphaned but its legacy not cleaned up. I still count
> 1.6k reverse build-depends in unstable.

Yes, CDBS introduced the idea of common packaging "sequences", but the
idea was implemented inelegantly using purely the same language as
debian/rules (yes, make is a programming language). Then debhelper
(which at the time was a collection of independent helper tools) adopted
the idea and expanded to include the dh sequencer, implemented elegantly
in another language. Elegantly not so much because of the choice of
language, but more because the user interface did not require messing
with the language at all, and for a community where lots of developers
care more about other languages than make and perl (despite having to
touch both of them occationally), there was much rejoice, and history
was rewritten to CDBS being incompatible with "work together" even
though it really was the inspiration for the marvellous dh sequencer.

As for the 1.6k package still using CDBS, I believe I am to blame for
only a dozen of those. For most of them please go yell at the Haskell
team rather than me.


> I'd - at the very least - would like to see a statement why a fork is 
> necessary. Innovation can happen in forks. But they don't necessarily 
> need to be in the archive to make a point.

dh-cargo is designed to repackage prepackaged code projects already
distributed through crates.io.  If you do an NMU where you include the
preferred form for distribution, you are kindly asked to stop doing
NMUs because that messes with how the Rust team deliberately avoids
tracking the actual source for the code projects distributed.

I listed in the ITP a list of features lacking in dh-cargo, which I need
for packaging Rust-based code projects in Debian from preferred form for
distribution source.  I do not need all of the features for all of them,
but some of them sometimes.

Kind regards,

 - 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

Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Phil Wyett]

Morning all,

As we embark on a new process where packages submitted to mentors are reviewed
and brought to a "Ready" stage for then busy DDs who are gracious enough to give
their time to review and possibly sponsor into Debian. We have a unique problem
(one which is now a nice one to have to be honest :-)) where more than one DD
may input on the same package review.

Could submitters to mentors and DDs please ensure that only one DD is working on
a package. This is to avoid conflicting info and also not waste valuable DD
time. If a package is taken, please find another to work on, as there are many
at the "Ready" stage.

Many thanks for your cooperation.

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

--



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

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Andrey Rakhmatullin]

On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote:
> Morning all,
> 
> As we embark on a new process where packages submitted to mentors are reviewed
> and brought to a "Ready" stage for then busy DDs who are gracious enough to 
> give
> their time to review and possibly sponsor into Debian. We have a unique 
> problem
> (one which is now a nice one to have to be honest :-)) where more than one DD
> may input on the same package review.
> 
> Could submitters to mentors and DDs please ensure that only one DD is working 
> on
> a package. This is to avoid conflicting info and also not waste valuable DD
> time. If a package is taken, please find another to work on, as there are many
> at the "Ready" stage.

Do you also suggest to not review packages one isn't going to sponsor? Or
how should this work?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Phil Wyett]

On Fri, 2024-07-12 at 10:44 +0500, Andrey Rakhmatullin wrote:
> On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote:
> > Morning all,
> > 
> > As we embark on a new process where packages submitted to mentors are 
> > reviewed
> > and brought to a "Ready" stage for then busy DDs who are gracious enough to 
> > give
> > their time to review and possibly sponsor into Debian. We have a unique 
> > problem
> > (one which is now a nice one to have to be honest :-)) where more than one 
> > DD
> > may input on the same package review.
> > 
> > Could submitters to mentors and DDs please ensure that only one DD is 
> > working on
> > a package. This is to avoid conflicting info and also not waste valuable DD
> > time. If a package is taken, please find another to work on, as there are 
> > many
> > at the "Ready" stage.
> 
> Do you also suggest to not review packages one isn't going to sponsor? Or
> how should this work?
> 

Morning Andrey,

Anyone can review packages, that has been part of mentors forever really. But
whoever does review a package, I would hope they see it through its journey.

* For non DDs. Hopefully take it to that ready stage where a DD can then take
over and finish a packages journey.

* For DDs. Hopefully take a package on prior to or at the ready stage and take
it through its full journey.

Is this reasonable?

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

--



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

Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Birger Schacht]

Hi,

On 7/11/24 9:55 PM, Jonas Smedegaard wrote:

Quoting Philipp Kern (2024-07-11 21:13:42)



I'd - at the very least - would like to see a statement why a fork is
necessary. Innovation can happen in forks. But they don't necessarily
need to be in the archive to make a point.


dh-cargo is designed to repackage prepackaged code projects already
distributed through crates.io.  If you do an NMU where you include the
preferred form for distribution, you are kindly asked to stop doing
NMUs because that messes with how the Rust team deliberately avoids
tracking the actual source for the code projects distributed.

I listed in the ITP a list of features lacking in dh-cargo, which I need
for packaging Rust-based code projects in Debian from preferred form for
distribution source.  I do not need all of the features for all of them,
but some of them sometimes.


This still does not answer the question why a fork is the better option 
instead of working with the people behind dh-cargo to integrate those 
features into the codebase?


cheers,
Birger