Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi wrote:
>
> On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> > Hi
> >
> > I have updated my repo to uprev v1.10 and support argcomple3.
> >
> > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> >
> > Hector, Andrea, can you take a look at it?
> >
> > Hector the fun bits are at
> > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
>
> Reviewed and added some comments, thanks!
>
> >
> > Andrea: the build seems to be having issues with 32 bits:
> > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
>
> Ah yes, I hit that yesterday as well:
> https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
Can you check if
https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
does the trick for you?
warning! not a rust hacker myself :P
>
> Part of these errors are fixed by:
> `879b4d4 ("virtme-ng-init: support 32-bit architectures")`
>
> But there are still some 32-bit related errors, I'll push an additional
> fix later today.
>
> -Andrea
Bug#1038692: ITP: ppx-cold -- Provide the @cold annotation for OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, Debian OCaml Maintainers , jpu...@debian.org * Package name: ppx-cold Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_cold * License : expat Programming Lang: OCaml Description : Provide the @cold annotation for OCaml This package provides the @cold annotation to program in OCaml to disable a closure optimisation. It is a depend of a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
fonts-liberation transition
Dear debian-devel, I'd like to annouce and discuss a package transition with you: In this release cycle I am going to let the src:fonts-liberation2 [1] package replace and take over the role of the src:fonts-liberation [2] package. /* However, since the version of the fonts-liberation package is currently at 1:1.07.4-11 and the version of the fonts-liberation2 package is currently at 2.1.5-1, the new version will have to carry the epoch of the former. However, I don't see any issues with this approach, as I don't know of any other package which declares a *versioned* relationship to any of the fonts-liberation* packages. To provide some rationale: Upstream [3] abandoned the v1 Liberation fonts some years ago (last commit 2018) and entirely replaced them with the v2 Liberation fonts which were built on similar, but different base fonts. Additionally, they factored out the Liberation Sans Narrow font from the v1 fonts, because this variant was not available in the v2 fonts. This package is currently waiting in the NEW queue [4]. In Debian, we first packaged the v1 font in the fonts-liberation package. When v2 was released, I upgraded the package to this version, but was asked to revert that change shortly after due to some hinting glitches introduced by the new version (which were resolved meanwhile). So, I re-introduced the v1 fonts (and that's where the epoch comes from) and packaged the v2 fonts separately in the fonts-liberation2 package. */ TL/DR: My plan for the future is to only have the same two packages in Debian that upstream provides. That is, Liberation v2 in the fonts- liberation package and Liberation Sans Narrow in the fonts-liberation- sans-narrow package. The new fonts-liberation package will have version 1:2.1.5-2. Please keep me in CC, I am not subscribed to debian-devel. Cheers, - Fabian [1] https://tracker.debian.org/pkg/fonts-liberation2 [2] https://tracker.debian.org/pkg/fonts-liberation [3] https://github.com/liberationfonts [4] https://ftp-master.debian.org/new/fonts-liberation-sans-narrow_1:1.07.6-1.html signature.asc Description: This is a digitally signed message part
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote:
> On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi
> wrote:
> >
> > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> > > Hi
> > >
> > > I have updated my repo to uprev v1.10 and support argcomple3.
> > >
> > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > >
> > > Hector, Andrea, can you take a look at it?
> > >
> > > Hector the fun bits are at
> > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> >
> > Reviewed and added some comments, thanks!
> >
> > >
> > > Andrea: the build seems to be having issues with 32 bits:
> > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
> >
> > Ah yes, I hit that yesterday as well:
> > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
>
> Can you check if
> https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
> does the trick for you?
usize seems to do the trick for me, I think it's more portable than
c_ulong (that comes from std::os::raw:c_ulong).
I'll push a fix soon, I just want to make sure it builds everywhere
(testing right now). :)
-Andrea
>
> warning! not a rust hacker myself :P
>
> >
> > Part of these errors are fixed by:
> > `879b4d4 ("virtme-ng-init: support 32-bit architectures")`
> >
> > But there are still some 32-bit related errors, I'll push an additional
> > fix later today.
> >
> > -Andrea
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Tue, Jun 20, 2023 at 09:19:58AM +0200, Andrea Righi wrote: > On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote: > > On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi > > wrote: > > > > > > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote: > > > > Hi > > > > > > > > I have updated my repo to uprev v1.10 and support argcomple3. > > > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian > > > > > > > > Hector, Andrea, can you take a look at it? > > > > > > > > Hector the fun bits are at > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c > > > > > > Reviewed and added some comments, thanks! > > > > > > > > > > > Andrea: the build seems to be having issues with 32 bits: > > > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837 > > > > > > Ah yes, I hit that yesterday as well: > > > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz > > > > Can you check if > > https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch > > does the trick for you? > > usize seems to do the trick for me, I think it's more portable than > c_ulong (that comes from std::os::raw:c_ulong). > > I'll push a fix soon, I just want to make sure it builds everywhere > (testing right now). :) I confirm that this one seems to fix the build error: https://github.com/arighi/virtme-ng/commit/438158e15a8af04fadfbb3943a227271db4b6e29 I'd like to cut a new version (v1.11) at this point, if/when you have a new PR ready I can also include your changes (no rush). -Andrea
Re: FTBFS (reprotest) on all recent uploads
On 20/06/2023 05:31, Joachim Zobel wrote: I can see two logs of successful builds and a diff for them. Looks to me like the 2nd build is aborting. .. I: Building the package I: user script /srv/workspace/pbuilder/1086848/tmp/hooks/A99_set_merged_usr starting Re-configuring usrmerge... removed '/etc/unsupported-skip-usrmerge-conversion' dpkg-query: package 'usrmerge' is not installed and no information is available Use dpkg --info (= dpkg-deb --info) to examine archive files. /usr/sbin/dpkg-reconfigure: usrmerge is not installed I: unmounting dev/ptmx filesystem I: unmounting dev/pts filesystem I: unmounting dev/shm filesystem I: unmounting proc filesystem I: unmounting sys filesystem I: cleaning the build env I: removing directory /srv/workspace/pbuilder/1086848 and its subdirectories This is happening for a lot of packages, but reprotest seems fine on Salsa.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 21:05 schrieb Luca Boccassi: On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote: On 2023-06-19 14:37, Luca Boccassi wrote: The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling&sharing of resources to maintain those setups, and the road should already be paved for it. I am not sure if I have seen this play out in practice[1]. Ubuntu^WCanonical has been doing its own development in this space as well with netplan. Ubuntu will continue to do its own fixes to glue things together. Kind regards Philipp Kern [1] With notable exceptions like doko maintaining the toolchain - and I'm sure I'm not crediting everyone. But that's also explicit package maintainership. I've been working for a long time with many Canonical engineers, happily and fruitfully, to the benefit of both Debian and Ubuntu, so my experience is quite different. This includes the developers working on src:systemd. As the maintainer of Netplan and (soon to be [1]) DD, I have a strong interest in this topic. I agree, going with systemd-networkd on servers and NetworkManager on desktops, the pooling & sharing of resources between Debian and Ubuntu will be a win-win situation! Netplan allows seeding and configuration for both of those tools and is already being used in Debian cloud-images for this purpose. All while keeping full flexibility to use the underlying tool's native config files in addition to Netplan's YAML. E.g. /etc/netplan/*.yaml will generate configuration in /run/systemd/network/... and/or /run/NetworkManager/system-connections/... while /etc/systemd/network/... and /etc/NetworkManager/system-connections/... are still there for native or override configurations. I think we shaped up the Netplan package in Debian [2] pretty nicely in the recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not least, at the Netplan project we're happy to help out with any rough edges that Debian might run into, as we might have already seen those in Ubuntu and of course we're also open for contributions! Cheers, Lukas [1] https://nm.debian.org/process/1180/ [2] https://tracker.debian.org/pkg/netplan.io
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Simon McVittie left as an exercise for the reader: > At the moment I believe the status quo for d-i is that networking is > managed by NetworkManager if a desktop task happens to have pulled it in, > or ifupdown otherwise? And that seems reasonable (although I personally > prefer to set up systemd-networkd on servers). i don't wish to start an argument, but just to ask: everyone has recommended NetworkManager for workstations. i've been running systemd-networkd on everything (servers, laptops, and workstations) for several years now, usually in conjunction with dnsmasq and wpa_supplicant, and it's been pretty great. what does NetworkManager offer that makes it superior to systemd-networkd on the desktop (which i'm interpreting to mean "for interactive use")? i'm not doubting its advantages, just ignorant of them. =] it seems to me that unifying the network stack has some value all its own. -- 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
Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
Am 19.06.23 um 20:01 schrieb Simon McVittie:
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
Why does isc-dhcp-client have priority:important to begin with?
I don't think users care so much about a dhcp client but rather a
network configuration system
The priority question isn't the important one. The real question is:
What network configuration system should users end up with (by
default)?
Indeed, this is the correct question to ask!
Yes, whatever DHCP client ifupdown would prefer to use, that seems
like an implementation detail of ifupdown: it should pull it in via
an appropriate level of dependency, and that's orthogonal to whether a
particular class of installation has its networking managed by ifupdown,
NetworkManager, systemd-networkd or something else by default.
ACK.
At the moment I believe the status quo for d-i is that networking is
managed by NetworkManager if a desktop task happens to have pulled it in,
or ifupdown otherwise? And that seems reasonable (although I personally
prefer to set up systemd-networkd on servers).
Of our desktop tasks, all except possibly LXDE and LXQT pull in
NetworkManager via Recommends or stronger, which seems right. LXDE
and LXQT might pull in connman as a higher preference than NM, via an
alternative dependency that includes connman-gtk or cmst: it's not
immediately obvious to me what actually happens, and I don't have a
recent installation of either one to look at right now.
As the maintainer of Netplan, I have a strong interest in this topic. I agree with
bluca, going with systemd-networkd on servers and NetworkManager on desktops, the
pooling & sharing of resources between Debian and Ubuntu will be a win-win
situation! I'd propose to use Netplan.io on top of that, to seed the configuration
for either network configuration tool in a common way, which should make life
easier for the d-i team.
Netplan allows to configure both of those tools and is already being used
across Ubuntu and in Debian cloud-images for this purpose. All while keeping
full flexibility to use the underlying tool's native config files, should
Netplan's simple YAML settings not be enough for a given complex usecase. E.g.
/etc/netplan/*.yaml will generate configuration in /run/systemd/network/...
and/or /run/NetworkManager/system-connections/... while
/etc/systemd/network/... and /etc/NetworkManager/system-connections/... are
still there for native (or override) configurations!
I think we shaped up the Netplan package in Debian [2] pretty nicely in the
recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not
least, at the Netplan project we're happy to help out with any rough edges that
Debian might run into, as we might have already seen those in Ubuntu and of
course we're also open for contributions!
The other possible reason to have a DHCP client is for recovery, but
most bootable Debian systems will have busybox (via Recommends from
initramfs-tools-core), and that has a small DHCP client included anyway.
I also think that installing both ifupdown and NetworkManager on
desktop environments is worse than only NM.
ifupdown should be fairly harmless when not configured to manage any
non-loopback interfaces (which is what d-i does when NM is installed),
but I agree that it seems better not to have it if it's not needed.
ifupdown is mostly in "life support" mode, as stated by andrewsh at Debian
Reunion Hamburg [2].
ifupdown2 is implemented in Python and has some backing by CumulusNetworks.
ifupdown-ng has only ever seen a single upload in Debian, but was deemed to be
the best ifupdown implementation currently.
IMHO ifupdown{2,-ng} is the "old world" and when doing such change we should rather go the systemd-networkd
(server) + NetworkManager (desktop) path, potentially in combination with Netplan, in order to switch to a more modern
and future proof network configuration tool, that also supports advanced features such as WiFi regulatory domain
settings or SR-IOV network virtualization, to cover today's usecases. We'd also get nice CLI tools to control this
stack for free, such as "networkctl", "nmcli" or "netplan status".
Cheers,
Lukas
[1] https://tracker.debian.org/pkg/netplan.io
[2]
https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
nick black writes: > what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop I don't know what systemd-networkd has to offer in this regard, but for laptop usage I'm personally fond of the ModemManager integration along with multihoming policies (eth0 preferred over wlan0 preferred over wwan0 by default). For the same reason I believe conman should not be default on any hardware with a built-in modem, regardless of desktop choice. For servers I agree with others here - I'm slowly migrating to systemd-networkd. Makes stuff like DHCPv6-PD much easier to manage for example. I've been a happy ifupdown user for ages, but now I believe it's time to move on... A standalone dhcp client is still important to me for one specific use case: testing and debugging of DHCP services. Been using the ISC client a lot for this, both for IPv4 and for different DHCPv6 modes. I guess the busybox client is a good enough replacement for v4. Not sure about DHCPv6. The advantages of the ISC client for this use case has been the terminal debug output and the scripting abilities, where you also could use "/usr/bin/env" as "script" to dump all the vars. Bjørn
Re: FTBFS (reprotest) on all recent uploads
On 20/06/23 10:25, Peter B wrote: On 20/06/2023 05:31, Joachim Zobel wrote: I can see two logs of successful builds and a diff for them. Looks to me like the 2nd build is aborting. .. I: Building the package I: user script /srv/workspace/pbuilder/1086848/tmp/hooks/A99_set_merged_usr starting Re-configuring usrmerge... removed '/etc/unsupported-skip-usrmerge-conversion' dpkg-query: package 'usrmerge' is not installed and no information is available Use dpkg --info (= dpkg-deb --info) to examine archive files. /usr/sbin/dpkg-reconfigure: usrmerge is not installed [...] This is happening for a lot of packages, but reprotest seems fine on Salsa. It looks like this issue has been fixed yesterday: https://salsa.debian.org/qa/jenkins.debian.net/-/commit/9951365b854660b4c3ea770c11414f254c50151a -- Gioele Barabucci
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Ansgar writes: > I think this should be NetworkManager for desktop environments and I > personally like systemd-networkd for other environments. In both cases > these replace both ifupdown and isc-dhcp-client. We might be using slightly different terms, but for desktops I still tend to use ifupdown (since the network config is easily configured thus, and essentially never changes); laptops I have ifupdown & network-manager (since the latter makes joining wireless networks on my travels easier). Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 2023-06-20 at 05:03 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > At the moment I believe the status quo for d-i is that networking is > > managed by NetworkManager if a desktop task happens to have pulled it in, > > or ifupdown otherwise? And that seems reasonable (although I personally > > prefer to set up systemd-networkd on servers). > > i don't wish to start an argument, but just to ask: everyone has > recommended NetworkManager for workstations. i've been running > systemd-networkd on everything (servers, laptops, and > workstations) for several years now, usually in conjunction with > dnsmasq and wpa_supplicant, and it's been pretty great. what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop (which i'm interpreting to mean > "for interactive use")? Managing VPN connections or 802.1X authentication for ethernet connections is nicer with NetworkManager for desktop computers too. For computers with static networking (where static might still mean DHCP) systemd-networkd might be sufficient as well. This might also include a subset of desktop computers, but I think the better default is still NM and it is up to the administrator to configure an alternative. Ansgar
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > At the moment I believe the status quo for d-i is that networking is > > managed by NetworkManager if a desktop task happens to have pulled it in, > > or ifupdown otherwise? And that seems reasonable (although I personally > > prefer to set up systemd-networkd on servers). > > i don't wish to start an argument, but just to ask: everyone has > recommended NetworkManager for workstations. i've been running > systemd-networkd on everything (servers, laptops, and > workstations) for several years now, usually in conjunction with > dnsmasq and wpa_supplicant, and it's been pretty great. what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop (which i'm interpreting to mean > "for interactive use")? Ubiquitous user interfaces, mostly. Our default for laptops and other portable computers needs to be something that lets a non-technical user of GNOME/Plasma/etc. join a wireless network, without learning how to write configuration files and operate sudo, and in practice that means the various desktop environments' UIs for NM (or something analogous like connman or wicd, but NM seems to be by far the best-supported choice out of those). I don't know enough about implementation details of NM and systemd-networkd to know whether the API design of NM is more suitable for that purpose, or whether the various UIs for NM and the absence of UIs for systemd-networkd is just inertia; but in practice the network configuration service that has first-class support in most of our desktop environments (in particular GNOME and Plasma) is NM. I was using "desktop" in the sense of task-gnome-desktop and friends, more than as a class of hardware. Laptops and other portable computers are the main thing that really needs easily user-configurable networking. I think it makes sense for desktop/workstation hardware to be treated like an oddly-shaped laptop by default, which means it gets the benefit of the wider testing that goes into NM and its various user interfaces, rather than having laptops and desktops behave differently for reasons that are unlikely to be obvious to a new user. Some users of desktop/workstation hardware strongly prefer to use a more "static" network configuration service like systemd-networkd or ifupdown so that they can rely on having the network setup not change under them, particularly if they're using services like NFS filesystems or LDAP authentication. That's an entirely reasonable thing to want to do, but IMO this is an example of the design principle that the choice that is better for non-technical users can make a better default, because technically adept users who know they have particular requirements can easily switch to what we might characterize as "server" infrastructure, but non-technical users can't easily switch in the opposite direction (or even know that they might want to). A secondary benefit of NM is that it works on non-systemd-booted systems, whereas systemd-networkd isn't designed for that use. I'm personally happy with systemd as pid 1, but some people consider requiring systemd as pid 1 to be a deal-breaker, and if NM is a good candidate for being our default *anyway* then we might as well get that secondary benefit too. smcv
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 20 Jun 2023 at 11:42, Simon McVittie wrote: > > On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote: > > Simon McVittie left as an exercise for the reader: > > > At the moment I believe the status quo for d-i is that networking is > > > managed by NetworkManager if a desktop task happens to have pulled it in, > > > or ifupdown otherwise? And that seems reasonable (although I personally > > > prefer to set up systemd-networkd on servers). > > > > i don't wish to start an argument, but just to ask: everyone has > > recommended NetworkManager for workstations. i've been running > > systemd-networkd on everything (servers, laptops, and > > workstations) for several years now, usually in conjunction with > > dnsmasq and wpa_supplicant, and it's been pretty great. what > > does NetworkManager offer that makes it superior to > > systemd-networkd on the desktop (which i'm interpreting to mean > > "for interactive use")? > > Ubiquitous user interfaces, mostly. Our default for laptops and other > portable computers needs to be something that lets a non-technical user > of GNOME/Plasma/etc. join a wireless network, without learning how to > write configuration files and operate sudo, and in practice that means > the various desktop environments' UIs for NM (or something analogous > like connman or wicd, but NM seems to be by far the best-supported choice > out of those). > > I don't know enough about implementation details of NM and > systemd-networkd to know whether the API design of NM is more suitable > for that purpose, or whether the various UIs for NM and the absence of > UIs for systemd-networkd is just inertia; but in practice the network > configuration service that has first-class support in most of our desktop > environments (in particular GNOME and Plasma) is NM. > > I was using "desktop" in the sense of task-gnome-desktop and friends, more > than as a class of hardware. Laptops and other portable computers are the > main thing that really needs easily user-configurable networking. > I think it makes sense for desktop/workstation hardware to be treated like > an oddly-shaped laptop by default, which means it gets the benefit of the > wider testing that goes into NM and its various user interfaces, rather > than having laptops and desktops behave differently for reasons that are > unlikely to be obvious to a new user. > > Some users of desktop/workstation hardware strongly prefer to use a more > "static" network configuration service like systemd-networkd or ifupdown > so that they can rely on having the network setup not change under > them, particularly if they're using services like NFS filesystems or > LDAP authentication. That's an entirely reasonable thing to want to do, > but IMO this is an example of the design principle that the choice that > is better for non-technical users can make a better default, because > technically adept users who know they have particular requirements can > easily switch to what we might characterize as "server" infrastructure, > but non-technical users can't easily switch in the opposite direction > (or even know that they might want to). > > A secondary benefit of NM is that it works on non-systemd-booted systems, > whereas systemd-networkd isn't designed for that use. I'm personally > happy with systemd as pid 1, but some people consider requiring systemd > as pid 1 to be a deal-breaker, and if NM is a good candidate for being > our default *anyway* then we might as well get that secondary benefit too. Yes a fully working and well-integrated GUI is the most important thing for the default (as in, desktop tasklet default), power users can always switch to something else. NetworkManager is clearly ahead of the alternatives in that regard. Kind regards, Luca Boccassi
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Tue, 20 Jun 2023 at 10:19, Lukas Maerdian wrote:
>
> Am 19.06.23 um 20:01 schrieb Simon McVittie:
> > On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
> >> On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
> >>> Why does isc-dhcp-client have priority:important to begin with?
> >>> I don't think users care so much about a dhcp client but rather a
> >>> network configuration system
> >>
> >> The priority question isn't the important one. The real question is:
> >>
> >> What network configuration system should users end up with (by
> >> default)?
>
> Indeed, this is the correct question to ask!
>
> > Yes, whatever DHCP client ifupdown would prefer to use, that seems
> > like an implementation detail of ifupdown: it should pull it in via
> > an appropriate level of dependency, and that's orthogonal to whether a
> > particular class of installation has its networking managed by ifupdown,
> > NetworkManager, systemd-networkd or something else by default.
>
> ACK.
>
> > At the moment I believe the status quo for d-i is that networking is
> > managed by NetworkManager if a desktop task happens to have pulled it in,
> > or ifupdown otherwise? And that seems reasonable (although I personally
> > prefer to set up systemd-networkd on servers).
> >
> > Of our desktop tasks, all except possibly LXDE and LXQT pull in
> > NetworkManager via Recommends or stronger, which seems right. LXDE
> > and LXQT might pull in connman as a higher preference than NM, via an
> > alternative dependency that includes connman-gtk or cmst: it's not
> > immediately obvious to me what actually happens, and I don't have a
> > recent installation of either one to look at right now.
>
> As the maintainer of Netplan, I have a strong interest in this topic. I agree
> with bluca, going with systemd-networkd on servers and NetworkManager on
> desktops, the pooling & sharing of resources between Debian and Ubuntu will
> be a win-win situation! I'd propose to use Netplan.io on top of that, to seed
> the configuration for either network configuration tool in a common way,
> which should make life easier for the d-i team.
>
> Netplan allows to configure both of those tools and is already being used
> across Ubuntu and in Debian cloud-images for this purpose. All while keeping
> full flexibility to use the underlying tool's native config files, should
> Netplan's simple YAML settings not be enough for a given complex usecase.
> E.g. /etc/netplan/*.yaml will generate configuration in
> /run/systemd/network/... and/or /run/NetworkManager/system-connections/...
> while /etc/systemd/network/... and /etc/NetworkManager/system-connections/...
> are still there for native (or override) configurations!
>
> I think we shaped up the Netplan package in Debian [2] pretty nicely in the
> recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not
> least, at the Netplan project we're happy to help out with any rough edges
> that Debian might run into, as we might have already seen those in Ubuntu and
> of course we're also open for contributions!
>
> > The other possible reason to have a DHCP client is for recovery, but
> > most bootable Debian systems will have busybox (via Recommends from
> > initramfs-tools-core), and that has a small DHCP client included anyway.
> >
> >> I also think that installing both ifupdown and NetworkManager on
> >> desktop environments is worse than only NM.
> >
> > ifupdown should be fairly harmless when not configured to manage any
> > non-loopback interfaces (which is what d-i does when NM is installed),
> > but I agree that it seems better not to have it if it's not needed.
>
> ifupdown is mostly in "life support" mode, as stated by andrewsh at Debian
> Reunion Hamburg [2].
> ifupdown2 is implemented in Python and has some backing by CumulusNetworks.
> ifupdown-ng has only ever seen a single upload in Debian, but was deemed to
> be the best ifupdown implementation currently.
>
> IMHO ifupdown{2,-ng} is the "old world" and when doing such change we should
> rather go the systemd-networkd (server) + NetworkManager (desktop) path,
> potentially in combination with Netplan, in order to switch to a more modern
> and future proof network configuration tool, that also supports advanced
> features such as WiFi regulatory domain settings or SR-IOV network
> virtualization, to cover today's usecases. We'd also get nice CLI tools to
> control this stack for free, such as "networkctl", "nmcli" or "netplan
> status".
>
> Cheers,
> Lukas
>
> [1] https://tracker.debian.org/pkg/netplan.io
> [2]
> https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Yeah I think it would be nice to do some experiments there, at least
starting with networkd and eventually considering netplan as an
additional step on top - thanks for volunteering :-P
Ultimately it seems to me that the defaults should be driven by
tasklets rather than priority - ie, make ifupdown and dhcpd-base
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
Hi Andrea On Tue, Jun 20, 2023 at 10:02 AM Andrea Righi wrote: > > On Tue, Jun 20, 2023 at 09:19:58AM +0200, Andrea Righi wrote: > > On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote: > > > On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi > > > wrote: > > > > > > > > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote: > > > > > Hi > > > > > > > > > > I have updated my repo to uprev v1.10 and support argcomple3. > > > > > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian > > > > > > > > > > Hector, Andrea, can you take a look at it? > > > > > > > > > > Hector the fun bits are at > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c > > > > > > > > Reviewed and added some comments, thanks! > > > > > > > > > > > > > > Andrea: the build seems to be having issues with 32 bits: > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837 > > > > > > > > Ah yes, I hit that yesterday as well: > > > > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz > > > > > > Can you check if > > > https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch > > > does the trick for you? > > > > usize seems to do the trick for me, I think it's more portable than > > c_ulong (that comes from std::os::raw:c_ulong). I thought that std::os::raw:c_ulong was more or less ok, as I said... me no rust :P > > > > I'll push a fix soon, I just want to make sure it builds everywhere > > (testing right now). :) > > I confirm that this one seems to fix the build error: > https://github.com/arighi/virtme-ng/commit/438158e15a8af04fadfbb3943a227271db4b6e29 > > I'd like to cut a new version (v1.11) at this point, if/when you have a > new PR ready I can also include your changes (no rush). Cool, let me know when you want to land it, so I update my package. I have added support for cross-compilation of the package: https://salsa.debian.org/ribalda/virtme-ng/-/commit/0e6ffec3897504ef1b7af7171f3b9cf68decfc76 Also, to ease the development at some point we should converge on the content of the debian folder. Is the package already in ubuntu? Cheeers! > > -Andrea
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Tue, Jun 20, 2023 at 02:17:38PM +0200, Ricardo Ribalda Delgado wrote: > Hi Andrea > > On Tue, Jun 20, 2023 at 10:02 AM Andrea Righi > wrote: > > > > On Tue, Jun 20, 2023 at 09:19:58AM +0200, Andrea Righi wrote: > > > On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote: > > > > On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi > > > > wrote: > > > > > > > > > > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado > > > > > wrote: > > > > > > Hi > > > > > > > > > > > > I have updated my repo to uprev v1.10 and support argcomple3. > > > > > > > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian > > > > > > > > > > > > Hector, Andrea, can you take a look at it? > > > > > > > > > > > > Hector the fun bits are at > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c > > > > > > > > > > Reviewed and added some comments, thanks! > > > > > > > > > > > > > > > > > Andrea: the build seems to be having issues with 32 bits: > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837 > > > > > > > > > > Ah yes, I hit that yesterday as well: > > > > > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz > > > > > > > > Can you check if > > > > https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch > > > > does the trick for you? > > > > > > usize seems to do the trick for me, I think it's more portable than > > > c_ulong (that comes from std::os::raw:c_ulong). > > I thought that std::os::raw:c_ulong was more or less ok, as I said... > me no rust :P I think they are both ok, I prefer usize just because it is more idiomatic Rust (usize is actually a distinct type) and c_ulong is provided to maintain compatibility with libc. > > > > > > > > I'll push a fix soon, I just want to make sure it builds everywhere > > > (testing right now). :) > > > > I confirm that this one seems to fix the build error: > > https://github.com/arighi/virtme-ng/commit/438158e15a8af04fadfbb3943a227271db4b6e29 > > > > I'd like to cut a new version (v1.11) at this point, if/when you have a > > new PR ready I can also include your changes (no rush). > > Cool, let me know when you want to land it, so I update my package. Ok, will do. > > I have added support for cross-compilation of the package: > https://salsa.debian.org/ribalda/virtme-ng/-/commit/0e6ffec3897504ef1b7af7171f3b9cf68decfc76 > > Also, to ease the development at some point we should converge on the > content of the debian folder. Is the package already in ubuntu? Absolutely, I would like to apply all your changes so that the content of debian/ upstream will be the same as yours. The package for Ubuntu is only available in a ppa at the moment. My plan is to land a proper package in Debian and then ask a resync of the same package in Ubuntu. Thanks, -andrea
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Simon McVittie left as an exercise for the reader: > I was using "desktop" in the sense of task-gnome-desktop and friends, more > than as a class of hardware. Laptops and other portable computers are the > main thing that really needs easily user-configurable networking. > I think it makes sense for desktop/workstation hardware to be treated like > an oddly-shaped laptop by default, which means it gets the benefit of the > wider testing that goes into NM and its various user interfaces, rather > than having laptops and desktops behave differently for reasons that are > unlikely to be obvious to a new user. since sending that mail, i've looked into gnome, and it seems to have pretty deep integration with NM. given gnome's positioning in debian, that seems to satisfy my question in and of itself. it's clearly at a level well above wpa_gui etc. (which i don't use, but might have proffered for consideration). thanks as always for your detailed and thoughtful mails. > A secondary benefit of NM is that it works on non-systemd-booted systems, > whereas systemd-networkd isn't designed for that use. I'm personally > happy with systemd as pid 1, but some people consider requiring systemd > as pid 1 to be a deal-breaker, and if NM is a good candidate for being > our default *anyway* then we might as well get that secondary benefit too. i hadn't even considered this, thanks. one nice thing about systemd-networkd is that it's pretty extensive in terms of structured configurability; i've currently got two machines with "CombinedChannels 1" to run XDP programs which bind to queue 0, for instance. of course, these are advanced options and thus can assume non-default effort. -- 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: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jun 20, 2023 at 10:23:58AM +0100, Matthew Vernon wrote: > We might be using slightly different terms, but for desktops I still > tend to use ifupdown (since the network config is easily configured > thus, and essentially never changes); laptops I have ifupdown & > network-manager (since the latter makes joining wireless networks on my > travels easier). ifupdown everywhere here, as on the one side it simplifies bridge configuration and makes for a minimal/transparent config, and on the other I find it pretty convenient to add new networks to wpa_supplicant.conf, where it's also easy to set per-network priorities if I'm going to have a particular preference of wireless network for any measure of time. For my laptop, jumping between the two modes is quite literally effortless: auto eth0 iface eth0 inet dhcp pre-up /sbin/mii-tool eth0 | /bin/grep -qv "no link" auto wlan0 iface wlan0 inet dhcp pre-up /sbin/mii-tool eth0 | /bin/grep -q "no link" wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf -- (defun main () (format t "Mason Loring Bliss - ma...@blisses.org - ") (format t "By the mysgydynge of the sterysman, he was set vpon the pylys") (format t " of the brydge, and the barge whelmyd. - Chronicle of Fabyan~%")) signature.asc Description: PGP signature
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
Hi Ricardo, On Tue, Jun 20, 2023 at 02:17:38PM +0200, Ricardo Ribalda Delgado wrote: ... > > > > > > I have updated my repo to uprev v1.10 and support argcomple3. > > > > > > > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian > > > > > > > > > > > > Hector, Andrea, can you take a look at it? > > > > > > > > > > > > Hector the fun bits are at > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c > > > > > > > > > > Reviewed and added some comments, thanks! FYI, I've applied all your debian/ changes (with some adjustments) to my git repo, I think we should be (more or less) aligned now. At some point, if this package lands in Debian I would like to remove the debian/ folder from my upstream repository and completely rely on the Debian one for the deb packaging, but for now I'm maintaining it also upstream, so that we have a central point that can use as a reference for all the next changes. Thanks, -Andrea
ITP: qatlib -- Intel(R) QuickAssist Technology hardware accelleration for security authentication and compression
Package: wnpp Severity: wishlist Owner: Colin Ian King X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com * Package name: qatlib Version : 23.02.0 Upstream Contact: giovanni.cabi...@intel.com * URL : https://github.com/intel/qatlib * License : BSD-3-Clause Programming Lang: C, x86 assemvler Description : Intel(R) QuickAssist Technology hardware accelleration for security authentication and compression Intel(R) QuickAssist Technology (Intel(R) QAT) provides hardware acceleration for offloading security, authentication and compression services from the CPU, thus significantly increasing the performance and efficiency of standard platform solutions. Its services include symmetric encryption and authentication, asymmetric encryption, digital signatures, RSA, DH and ECC, and lossless data compression. It provides user space libraries that allow access to Intel(R) QuickAssist devices and expose the Intel(R) QuickAssist APIs and sample codes. See also: https://wiki.debian.org/QAT I intend to maintain this much like other Intel related Debian packages Sincerely, Colin Ian King
Re: ITP: qatlib -- Intel(R) QuickAssist Technology hardware accelleration for security authentication and compression
Apologies for the re-send, the last part of the email got truncated. I'm re-sending it as below: Package: wnpp Severity: wishlist Owner: Colin Ian King X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com * Package name: qatlib Version : 23.02.0 Upstream Contact: giovanni.cabi...@intel.com * URL : https://github.com/intel/qatlib * License : BSD-3-Clause Programming Lang: C, x86 assemvler Description : Intel(R) QuickAssist Technology hardware accelleration for security authentication and compression Intel(R) QuickAssist Technology (Intel(R) QAT) provides hardware acceleration for offloading security, authentication and compression services from the CPU, thus significantly increasing the performance and efficiency of standard platform solutions. Its services include symmetric encryption and authentication, asymmetric encryption, digital signatures, RSA, DH and ECC, and lossless data compression. It provides user space libraries that allow access to Intel(R) QuickAssist devices and expose the Intel(R) QuickAssist APIs and sample codes. See also: https://wiki.debian.org/QAT I intend to maintain this much like other Intel related Debian packages that I maintain, such as intel-cmt-cat, intel-ipsec-mb, numatop, psst, thermald and thunderbolt-tools. This includes refreshing packages on new upstream releases, refreshing packages to include hot fixes and to ensure the packaging keeps in-sync with Debian standards. I also intent to contribute to the upstream project by cleaning up code, fixing user facing spelling mistakes and performing static analysis on the code to find and fix outstanding issues. Sincerely. Colin Ian King
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-06-19 Sven Joachim wrote: [...] > If my above statements about debootstrap are correct, this will result > in no dhcp-client being installed at all by debootstrap unless the > override bug also requests bumping dhcpcd-base's priority from optional > to important. Not complety true. debootstrap would still install systemd which includes systemd-networkd. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
Hi Simon, On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > upstream maintenance or releases. Maintained software that uses SDL 1.2 > should be ported to SDL 2. Given the time scales involved, is it worth waiting for SDL 3 (soon...) before porting SDL 1.2 software? I’m assuming that SDL 3 will be available for Trixie, and this would avoid two porting efforts. Regards, Stephen pgpNOBwOwE0Bk.pgp Description: OpenPGP digital signature
