Re: Multi-host networking software, autopkgtests
Ian Jackson writes ("Re: Multi-host networking software, autopkgtests"):
> For now I'm working on an adhoc thing that uses
> - Restrictions: needs-root
> - overlayfs to make an editable clone of the fs provided by autopkgtest
> - chroot
> - ip netns
> - apt-mark and apt-autoremove to get rid of unwanted deps
>
> It's not particularly pretty but it's not much code and I feel I'm
> making progress. I'll report back here when I've succeeded - or
> failed :-).
This worked very well on my laptop but it has been going quite badly
in the CI. The CI environment is really quite different from the
real one (sometimes in what seem like strange ways).
Right now I am having the following impossible thing occurring. [1]
This code:
tunfd= open("/dev/net/tun", O_RDWR);
if (tunfd < 0) sysfatal("open /dev/net/tun");
r= fcntl(tunfd, F_GETFD);
if (r==-1) sysfatal("fcntl(tunfd,F_GETFD)");
is resulting in this output:
2023-01-10T22:58:46.142075+00:00 ci-010-c4ebefae hippotatd[153]:
error: ipif stderr: userv-ipif service: fatal system error:
fcntl(tunfd,F_GETFD): Bad file descriptor
The executable which prints this message is not multithreaded and has
no signal handlers. I suspect ? ? CI ? container ? hates tun ? ?,
or ? ? overlay fs on /dev ? strange effect on /dev/net/tun ? ?.
(Also in the test I have that *doesn't* do the pid namespace and
chroot thing, service(8) seems to have been disabled. Maybe I need to
add a Restriction for that?)
I looked again at the links you helpfully provided. That does look
like it would be doable, but it's decidedly nontrivial.
Each of those scripts has its own ad-hoc answer (or not) to questions
like "cope with the file:// apt urls not working" "map the Debian
architecture to a qemu binary" "configure the within-qemu environment
so we can do anything to it" "manage the lifetime of the qemu" etc.
I'm considering a third option: "disable the tests in debci" :-/.
Ian.
[1]
Test script source code
https://browse.dgit.debian.org/hippotat.git/tree/adt/acommon?h=archive/debian/1.1.5%2bexp7
Recent test log (full of distracting crap):
https://ci.debian.net/data/autopkgtest/unstable/amd64/h/hippotat/30238962/log.gz
Source code for "ipif" program experiencing the EBADF error
https://browse.dgit.debian.org/userv-utils.git/tree/ipif/service.c?h=archive/debian/0.6.1-2#n711
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1028462: ITP: obs-vkcapture -- OBS plugin for Vulkan/OpenGL game capture
Package: wnpp Severity: wishlist Owner: Gregor Riepl X-Debbugs-Cc: debian-devel@lists.debian.org, onit...@gmail.com * Package name: obs-vkcapture Version : 1.2.2 Upstream Contact: David Rosca * URL : https://github.com/nowrep/obs-vkcapture * License : GPL-2+ Programming Lang: C Description : OBS plugin for Vulkan/OpenGL game capture This OBS plugin provides an efficient method to capture output from GPU-accelerated applications, such as games and other 3D applications. The built-in capture methods provided by OBS on Linux are very slow and not suitable for higher resolutions or faster frame rates. With the plugin, high resolution and high frame rate capture directly from a GPU framebuffer becomes possible. As the OBS packages are already maintained by the DebianMultimedia team, I think it makes sense to put the plugin under the unmbrella of DebianMultimedia. I'd be willing to co-maintain it together with the team. I will need a sponsor for the package because I'm not a DD. My packaging effort so far can be found here: https://salsa.debian.org/onitake-guest/obs-vkcapture
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
Package: wnpp Severity: wishlist Owner: Helmut Grohne X-Debbugs-Cc: debian-devel@lists.debian.org, team+b...@tracker.debian.org, Gianfranco Costamagna , Danny Edel The root of this ITP is #1019950. The crux of the matter is that borg 2.x is not very compatible with borg 1.x. I talked to upstream and as far as I understand things, the compatibility is quite limited: borg 2.x expects to deal with borg 2.x serve or a borg 2.x data store. Additionally, borg 2.x can read from a borg 1.x serve and borg 1.x data stores. As part of the upgrade process, users have to convert their borg 1.x data into the borg 2.x format. This involves copying the entire repository. If we were to just update the borgbackup package to ship version 2.x, a number of bad things could happen: * Users trying to back up after a dist-upgrade will no longer be able to write to their repositories until they have upgraded them, i.e. backups will just stop working. * When upgrading a borg server machine, all clients running borg 1.x will no longer be able to back up until they upgrade their borg installation and upgrade their repositories. As such, I want to make borg 1.x and borg 2.x coinstallable. This eliminates much of the trouble: * During a dist-upgrade, people will continue using borg 1.x and backups will continue to work. * borg server machines can coinstall borg 1.x and borg 2.x and thus serve borg 1.x clients and borg 2.x clients at the same time. * Users can install borgbackup2 and migrate their backups. Once finished, they can remove version 1.x and hope that the next upgrade becomes simpler. * The idea is that borgbackup gains a "borg1" command and borgbackup2 is shipped as "borg2". The original name "borg" shall be managed using update-alternatives with "borg1" taking a preference in bookworm and changing that in trixie. * Release notes shall warn users about this change I hope this makes sense Helmut
Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
On 1/10/23 19:54, Rene Engelhard wrote: Hi, Am 10.01.23 um 19:44 schrieb John Paul Adrian Glaubitz: On 1/10/23 19:25, Rene Engelhard wrote: (which are for many BD-Uninstallable since ages because it does not have Java (anymore), didn't do a long-ago transition, ...) They all have Java support except for hppa, see: I was indeed aiming at hppa here. Misses libnumbertext and that one has a Java component and thus we get libnumbertext build-depends on: - default-jdk:hppa default-jdk depends on: - default-jre:hppa (= 2:1.5-72) default-jre depends on: - default-jre-headless:hppa (= 2:1.5-72) default-jre-headless depends on missing: - openjdk-5-jre-headless:hppa Yes, sadly we don't have a working java right now on hppa, and it will probably take some more time to get one. At least I won't have time for it during the next few months. But it would be sad to loose those bindings... The reason for being BD-Uninstallable is the lack of cruft in Debian Ports: https://lists.debian.org/debian-sparc/2017/12/msg00060.html as a result of some packages FTBFS. That is for sparc and m68k? (Where both the needed KDE packages are uninstallable) Adrian, as there seems to be various arches (and reasons) will you speak upstream? Helge
Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
Hi Helge! On 1/11/23 15:03, Helge Deller wrote: Yes, sadly we don't have a working java right now on hppa, and it will probably take some more time to get one. At least I won't have time for it during the next few months. But it would be sad to loose those bindings... There are some efforts to bring back gcj if that helps: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609530.html The reason for being BD-Uninstallable is the lack of cruft in Debian Ports: https://lists.debian.org/debian-sparc/2017/12/msg00060.html as a result of some packages FTBFS. That is for sparc and m68k? (Where both the needed KDE packages are uninstallable) Adrian, as there seems to be various arches (and reasons) will you speak upstream? Yes, I have already replied upstream. I will follow up there tonight. One of the biggest problems for Debian Ports remains the lack of cruft as explained in my post to the debian-sparc mailing list above. This causes these long BD-Uninstallable queues. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Discrepancies between packages.d.o and tracker.d.o
Dear all, I accidentally noticed that the thunderbird package information differs between packages.d.o [0] and tracker.d.o [1]. [0] does not list the package from stable-sec. If I click on the package versions for stable-sec [2] and old-sec [3] on [1], I obtain error pages. Probably something went out-of-sync. Best regards, Peter [0] https://packages.debian.org/search?keywords=thunderbird&searchon=names&suite=all [1] https://tracker.debian.org/pkg/thunderbird [2] https://packages.debian.org/source/stable-security/thunderbird [3] https://packages.debian.org/source/oldstable/updates/thunderbird
Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
Hi, Am 11.01.23 um 15:20 schrieb John Paul Adrian Glaubitz: Hi Helge! On 1/11/23 15:03, Helge Deller wrote: Yes, sadly we don't have a working java right now on hppa, and it will probably take some more time to get one. At least I won't have time for it during the next few months. But it would be sad to loose those bindings... There are some efforts to bring back gcj if that helps: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609530.html https://cgit.freedesktop.org/libreoffice/core/commit/?id=7fe8c0b852fa421fe52de99a7f59e45027139eed That would need to be reinstated if that ever becomes a thing. Regards, Rene
Re: Discrepancies between packages.d.o and tracker.d.o
Hi all, hi Peter, On Mi 11 Jan 2023 17:56:16 CET, Peter Wienemann wrote: Dear all, I accidentally noticed that the thunderbird package information differs between packages.d.o [0] and tracker.d.o [1]. [0] does not list the package from stable-sec. If I click on the package versions for stable-sec [2] and old-sec [3] on [1], I obtain error pages. I can confirm this problem and it exists for many years afair. Who knows how and where to fix it? Where should a bug report be sent to? Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpKYPK8KdolU.pgp Description: Digitale PGP-Signatur
