Re: RFC: Rearranging qemu-system packages
0x > provides on s390x. And the other to contain all the emulators > for all other platforms, and depend on -native for various > common modules and whatnot. > > Note that -native does not necessary have kvm mode, since it is > not available on all platforms, - so for some (eg sparc) it > will still be emulated. So maybe it shouldn't actually exist > on those platforms. > > Another variation is to have qemu-system-kvm package which > provides native kvm-accelerated mode, plus qemu-system-emu > package with anything else. qemu-system-kvm will not be available > at all on platforms not supporting kvm (or we'll have a dummy > package there). In terms of naming/usage I like this suggestion of having a qemu-system-native which would give you the best possible (even if - as you outlined - that sometimes still is emulation) native experience and OTOH qemu-system-emu for all the emulators. Among other things that allows us to just always use -native in tests where staying smaller (instead of pulling all of -emu) is helpful for speedup and bandwidth. But while I see the appeal of reunifying I also have often liked (and seen people appreciate and use) this being split and explicit. Do you consider your proposed qemu-system-native be a meta package that depends on the right qemu-system-$arch, or an actual package with content. So would it be: a) x86: qemu-system-native -dep-> qemu-system-x86_64 ppc: qemu-system-native -dep-> qemu-system-ppc or b) x86: qemu-system-native ppc: qemu-system-native I personally like (a) more to simplify dependencies while not breaking habits. But that might be just me, so I wanted to ask for clarification so everyone is on the same page here. > And the 3rd variant is to just merge everything back into single > qemu-system package the way it has been a few years back (now > with greatly reduced set of dependencies but with grown size). > > This is - hopefully - the long-term goal, because upstream is > slowly thinking about building qemu-system as a single binary > which provides emulation of everything available, - obviously > we won't try to split such binary into multiple packages :) > But this goal seems to be too far in the future to be plannable. > > Without such merge into single binary, the package will be large > (see full list of emulator binaries above), but hdd space is > much cheaper nowadays.. > > What do you think? > > /mjt -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd
Re: New systemd service file path?
On Tue, Oct 5, 2021 at 3:30 PM Otto Kekäläinen wrote: > > Hello! > > I noticed that Lintian has recently started erroring on > https://lintian.debian.org/tags/systemd-service-in-odd-location > > I can't find this requirement anywhere in the Debian Policy, e.g. > https://www.debian.org/doc/debian-policy/ch-opersys.html#starting-system-services > does not mention anything about systemd paths. > > Seems dh_systemd_enable still installs files into /lib/systemd/system/ > and I find it confusing that apparently Lintian errors on what > debhelper does by default. Please enlighten me on what I have missed. Thanks Otto, I think it is right to bring this to more attention as I've seen various people and builds stumble over it already. Not sure what the general discussion/status on this is, but for myself I have tracked it down starting from one of my builds failing to this commit [1] that has to land into debhelper to resolve it. [1]: https://salsa.debian.org/debian/debhelper/-/commit/d70caa69c64b > So, which one of these paths should be used and why? > - /lib/systemd/system/ > - /usr/lib/systemd/system/ > > Thanks! > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Re: debuginfod.debian.net is temporarily offline
On Wed, Jun 15, 2022 at 2:30 AM Marco Trevisan wrote: > > Hey Sergio, > > I was reading this and I was wondering if a debuginfoid server is going to be > added to ubuntu as well. Yes Marco, we are working on providing one for Ubuntu as well. > I remember your talk in Frankfurt, but I don't remeber if you mentioned > that... > > Cheers! > > Il lun 13 giu 2022, 19:27 Sergio Durigan Junior ha > scritto: >> >> Hello, >> >> The debuginfod.debian.net service is temporarily offline due to a >> hardware issue (the HDD used to store the debuginfo packages died). >> >> Thanks to Jonathan (highvoltage) a new HDD has been installed, but now I >> have to work on rebuilding the index/mirror, which should take at least >> one week. >> >> I will send an email when the service is back online. >> >> Thanks, >> >> -- >> Sergio >> GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 >> Please send encrypted e-mail if possible >> https://sergiodj.net/ -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#815760: (no subject)
Subject: ITP: dpdk -- Data Plane Development Kit Package: wnpp Owner: Christian Ehrhardt Severity: wishlist * Package name: dpdk Version : 2.2 Upstream Author : Thomas Monjalon * URL : http://dpdk.org/ * License : BSD (core libs), GPLv2 (kernel components) Programming Lang: C Description : Data Plane Development Kit 1. What is DPDK useful for DPDK is a set of libraries and drivers for fast packet processing. It was designed to run on any processors. The first supported CPU was Intel x86 and it is now extended to IBM Power 8, EZchip TILE-Gx and ARM. It runs mostly in Linux userland. A FreeBSD port is available for a subset of DPDK features. Main libraries - multicore framework - huge page memory - ring buffers - poll-mode drivers Usage These libraries can be used to: - receive and send packets within the minimum number of CPU cycles (usually less than 80 cycles) - develop fast packet capture algorithms (tcpdump-like) - run third-party fast path stacks Some packet processing functions have been benchmarked up to hundreds million frames per second, using 64-byte packets with a PCIe NIC. 2. Maintenance Plan I'm currently maintaining dpdk for ubuntu (launchpad.net/ubuntu/+source/dpdk) and the existing packaging should be suitable for Debian also. It'd be great to have this packaged in Debian too, so that we can share the work. I am looking for co-maintainers to help me with this. But I'm not a Debian developer, so I'd like to have a more Debian centric co-maintainer for a proper Debian expertise and opinion in all the work. I'm also no DD, so sponsors will be needed.
