Re: ifupdown maintenance
Hi, On Sun, 2024-09-15 at 23:07 -0400, Michael Stone wrote: > On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote: > > If ifupdown's paradigm were working for people we wouldn't be having this > > conversation. > > How else would you move /etc/network/interfaces forward without breaking > > anything? > > Just don't. If someone needs to do something new that's supported by a > new tool and not ifupdown, they should just use the new tool. Hmm, ifupdown has problems assigning addresses for the internet protocol to interfaces. Is that something "new"? :) (And AFAIR that includes assigning static addresses to a static interface due to race conditions.) > Freeze > ifupdown functionality, mark feature requests as wontfix, and update the > documentation. Should non-trivial bugs also be marked as wontfix? Ansgar
Re: ifupdown maintenance
* Michael Stone [240916 05:04]: > On Tue, Jul 09, 2024 at 10:57:39AM +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? > > Frankly the default is a completely uninteresting issue. The default is the only interesting thing for this thread. > The major concern > IMO is that the zeal to have Yet Another New Thing doesn't break all of the > existing systems that are running perfectly well with ifupdown and which > clearly don't need a new thing. Existing install can stay on ifupdown as long as it exists or maybe even longer. Changing priorities (at least to "standard") of a package does not magically install it on existing systems. Chris
Re: Community survey on network stack for Trixie
Lukas Märdian writes: > On 04.09.24 17:26, Marco d'Itri wrote: >> Do we even have general documentation about configuring networking? > > Yes, there is a "NetworkConfiguration" page on the wiki and the Debian ref: > > * https://wiki.debian.org/NetworkConfiguration I dont thinj this page is usefulnfor most users. It starts with "Reader Prerequisites: To get the most from this article, understand the following concepts before reading: basic unix command line tools, text editors, DNS, TCP/IP, DHCP, netmask, gateway"" It does not mention wifi at all?? > * https://www.debian.org/doc/manuals/debian-reference/ch05.en.html This seems to be a half-finished draft? it starts with no context, then a seemingly random list of packages, "the basic network infrastructure on the modern Debian system" most of which are not installed by default. > Together, they show something like 5+ ways of how to do things: > > * /etc/network/interfaces > * iproute2 > * Netplan > * NetworkManager > * systemd-networkd > > Which one to choose? Well it all depends on the underlying stack, which > the average user might not necessarily know. So it's very confusing. i dont see how netplan helps here --- the pages are confusing because they are poorly written, not aimed at end users of modern networking, and have non-idiomatic english -- this is not a criticism of anyone, im sure this was useful in the 1990s when you had to "configure the network", but things have moved on - and just work for all but advanced users. I think these documents should be archived (or completely rewritten). New users dont need these documents, they just need to know how to enter their wifi details More advanced users probably need several documents, depending on what they want to do. Eg, how to run private networks for containers, how to change dns servers, how to configure a firewall, how to turn your laptop into a router, how to use ipv6 etc. Does netplan make that easier?
Bug#1081966: ITP: uwsgi-plugin-lua -- Lua WSAPI plugin for uWSGI (Lua 5.1)
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-lua Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Lua WSAPI plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Lua plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-lua Alex
Bug#1081971: ITP: python-construct-classes -- Python module for parsing and packing data classes
Package: wnpp Severity: wishlist Owner: Soren Stoutner X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-construct-classes Version : 0.1.2 Upstream Contact: matejcik * URL : https://github.com/matejcik/construct-classes/tree/main * License : Expat Programming Lang: Python Description : Python module for parsing and packing data classes This module relies on python3-construct for parsing and packing. The programmer needs to manually write the Construct expressions. There is no type verification, so it is the programmer's responsibility that the dataclass and the Construct expression match. This is a dependency for the current version of python-trezor, for which I am taking over maintainership under the Debian Python Team.
Re: ifupdown maintenance
On Mon, Sep 16, 2024 at 09:49:24AM +0200, Ansgar 🙀 wrote: Hi, On Sun, 2024-09-15 at 23:07 -0400, Michael Stone wrote: On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote: > If ifupdown's paradigm were working for people we wouldn't be having this > conversation. > How else would you move /etc/network/interfaces forward without breaking > anything? Just don't. If someone needs to do something new that's supported by a new tool and not ifupdown, they should just use the new tool. Hmm, ifupdown has problems assigning addresses for the internet protocol to interfaces. Is that something "new"? :) (And AFAIR that includes assigning static addresses to a static interface due to race conditions.) It's weird that something that apparently doesn't work, does work for so many.
