Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Hi, On 04.04.24 20:51, Bill Allombert wrote: I still think we should allow Autobuild: no as an escape hatch. If we want to require non-free package to be autobuildable, we should be more explicit about it (and probably require more feedback from debian-devel). There is no requirement for non-free to be autobuildable today. This change also does not introduce this, except for everything that is to be built on official builders to not require network access. There are even two stages of allowlisting today (file-based and the dsc field). Kind regards Philipp Kern
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote: > On 2024-04-02 09:21, Sean Whitton wrote: > > Hello, > > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > > > The debian policy, section 4.9, forbids network access for packages in > > > the main archive, which implicitly means they are authorized for > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > fixed). > > > > > > This gives constraints on the build daemons infrastructure and also > > > brings some security concerns. Would it be possible to extend this > > > restriction to all archives? > > > > We need to know if this is going to break existing packages and allow > > some input from their maintainers. Are you able to prepare a list of > > the affected packages? > > Fair enough. I can work on that, but help would be welcome as my > resources are limited. I did a test rebuild of contrib, non-free and non-free-firmware packages in sid with both stable sbuild schroot and unshare backends and could not find a difference in build success (i.e. what failed failed in both, what succeeded succeeded in both). Kind regards Philipp Kern
Bug#1066829: ITP: assetfinder -- Find domains and subdomains related to a given domain
Hi, On 2024-03-14 01:47, aquilamac...@riseup.net wrote: * Package name: assetfinder Version : 0.1.1 Upstream Contact: Tom Hudson * URL : https://github.com/tomnomnom/assetfinder * License : MIT Programming Lang: Golang Description : Find domains and subdomains related to a given domain assetfinder is a command-line tool to find domains and subdomains potentially related to a specified domain. Enhances domain discovery for comprehensive analysis. I'm writing to submit an Intention to Package (ITP) for assetfinder under the pkg-security team's umbrella. Is this tool still maintained? The last changes have been 5 years ago and it references quite a few sources that no longer exist. I'd also expect that such a tool needs maintenance to keep up with API changes. And lastly the name is a tad too generic, given that it's solely focussed on DNS "assets", and not any other assets you might want to track. Kind regards Philipp Kern
Bug#1064581: nsncd - upcoming rust-nix update.
On 2024-02-24 14:35, Peter Green wrote: We are preparing an update of rust-nix to version 0.27, the new version has been uploaded to experlmental. In the new version of the nix crate, No features are enabled by default, you must enable the features you require. The attached patch relaxes the cargo dependency on nix to allow the new version and expliciltly enables the "fs" feature. A debdiff is attatched, if I get no response I will likely NMU this when the new rust-nix is uploaded to unstable. Please feel free to NMU at your convenience. Kind regards Philipp Kern
Bug#1062376: libinfinity: NMU diff for 64-bit time_t transition
On 2024-02-01 08:36, Steve Langasek wrote: Please find the patch for this NMU attached. Patches don't carry mode bits. I'm guessing that the .install file did not get a +x bit and thus the package failed to build. Kind regards Philipp Kern
Bug#1059388: git-debrebase: found two-parent merge, how to cope?
Package: dgit Version: 11.5 Severity: wishlist X-Debbugs-Cc: pk...@debian.org Hey, In the absence of a better venue of asking this question (there seems to be no mailing list): I have an upstream repository that contains a two-parent merge for some reason (https://github.com/twosigma/nsncd, of all the things merging a CLA into the repository). dgit bails out with this: | Format `3.0 (quilt)', need to check/update patch stack | examining quilt state (multiple patches, linear mode) | git-debrebase: snag ignored (-funclean-ordering): packaging change (6228b52f9f4e1c847907651dcfa27a4003280538) follows upstream change (eg 2a5ff9d32c70a818044d26b007ec407a875d2374) | git-debrebase: snag ignored (-funclean-ordering): packaging change (b977d9b16db9bd6dcfc7f9f1e1831ea254d2df1d) follows upstream change (eg 44c81340420d2e993e7506f3144720862c56d77a) | git-debrebase: snag ignored (-funclean-mixed): found mixed upstream/packaging commit (ef3e287879586088e795a518977de87e65c6c2fd) | | git-debrebase: error: found unprocessable commit, cannot cope: general two-parent merge (e3de17c274315bab561664ac57e46472670545cf) | git-debrebase: Branch does not seem to be meant to be a git-debrebase branch? | git-debrebase: Wrong branch, or maybe you needed git-debrebase convert-from-*. | git-debrebase: | dgit: failed command: git-debrebase --noop-ok -funclean-mixed -funclean-ordering make-patches --quiet-would-amend | | dgit: error: subprocess failed with error exit status 255 I have so far forced an --anchor manually upon git-debrebase, which worked, but is also very tedious to pass everywhere. Is this something that will auto-fix itself on the next upstream release because dgit will properly discard the history pre the current upstream release? I was at least hoping that it would disappear with the first regular upload - but this did not happen. Is there something I can do for dgit to accept the current state of the repository as canonical up to the point where the Debian packaging was modified/forked off. The snags are upstream's prior packaging as found in the upstream repository, which does not seem to be uncommon to me either. The repo can be found on dgit as well as on [1]. Kind regards and thanks Philipp Kern [1] https://salsa.debian.org/Debian/nsncd
Bug#1058704: ITP: nsncd -- Name service non-caching daemon
Package: wnpp Severity: wishlist Owner: Philipp Kern X-Debbugs-Cc: debian-de...@lists.debian.org, pk...@debian.org * Package name: nsncd Version : 1.4.1 (plus patches[1]) * URL : https://github.com/twosigma/nsncd * License : Apache 2.0 Programming Lang: Rust Description : Name service non-caching daemon nsncd implements the NSCD (name-service caching daemon) protocol to provide out-of-process NSS lookups but does not implement caching. It is designed to provide high-performance NSS lookups for programs that are not using the system libc, while providing semantics as if NSCD were not being used. This is useful in environments in which you are mixing binaries from several sources. One such environment is Nix, where binaries will be linked to a (hermetic) glibc from the Nix store. By dropping the need to cache, nsncd is a lot simpler than nscd - it's only purpose is to decouple your binaries from the NSS modules you have configured, which will continue to run under the system glibc. I'm going to maintain the package for the time being. If the Rust team also wants to maintain Rust leaf software, I'm also happy to collaborate there. Kind regards Philipp Kern [1] The Nix people also added support for host resolution in https://github.com/nix-community/nsncd/.
Bug#1034424: buildd.debian.org: Please use predictible build paths
On 2023-05-11 07:11, Johannes Schauer Marin Rodrigues wrote: I think the main purpose for the log filtering is to make log files easily grep-able despite the build path having random components. I'd say it's also to allow diffing. That might be a lost cause when parallelism is involved, though. Kind regards Philipp Kern
Bug#1030301: buildd.debian.org: please add support for non-free-firmware
On 2023-02-02 11:07, Cyril Brulebois wrote: I hadn't spotted that before because firmware packages moving from non-free to non-free-firmware needed a source+binary upload to go through NEW, with binary being `Architecture: all`… so I didn't spot that no autobuilding was happening until Salvatore started asking about firmware-nonfree builds that weren't happening (source-only for a newer release). Yup, there wasn't any bug to actually make autobuilding work for non-free-firmware yet. In hinsight maybe we were talking about different things: bootstrap the n-f-f allowlist from the current n-f one, but keep them separate, vs. keeping a single common list for both. The former would look good to me. I don't think it's useful to split the allowlist. We should just reuse the same one. Kind regards Philipp Kern
Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
On 07.01.23 21:50, Joachim Wuttke wrote: The issue for me is not that I do "just want to not have 2 python interpreters installed". The issue for me is the Depends of the transitory python3-numpy releases break my dependent software, as described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025169. Isn't this a bug in the CMake script looking up the version of Python to compile against? Naively I'd expect it to use whatever python3 points to. For a distro build we'd want to compile multiple times against a distro-provided set of versions to enable transitions. Kind regards Philipp Kern
Bug#1024278: libgssglue: autopkgtest failure with pkgconf
Hey Simon, On 12.12.22 10:02, Simon Josefsson wrote: Philipp Kern writes: Hey Simon, On Thu, Nov 17, 2022 at 12:46:19PM +0100, Sebastian Ramacher wrote: I see. If so, it would be good if pkgconf was made consistent with pkg-config here, if the intention is to replace it. This discussion needs to happen with the pkgconf maintainer / upstream. But since this is the only package where the extra whitespace seems to be an issue, I'd just be pragmatic on the libgssglue side. Could we be pragmatic here and fix it in Debian in the meantime? It'd be a shame if we had a couple of packages autoremoved from testing due to this, if it's basically a one character change somewhere. Feel free to work on the pkgconf bug upstream, or within Debian, or work around the pkgconf bug within libgssglue, or something else, as you (or someone else) prefers. I'm tagging the bug report with 'help'; the package is already marked LowNMU and I've sent [VAC] to debian-private. Right, thanks for pointing that out - I had missed that. NMU debdiff attached. Thanks! Kind regards Philipp Kerndiff -Nru libgssglue-0.7/debian/changelog libgssglue-0.7/debian/changelog --- libgssglue-0.7/debian/changelog 2022-08-16 01:29:01.0 +0200 +++ libgssglue-0.7/debian/changelog 2022-12-12 13:03:24.0 +0100 @@ -1,3 +1,12 @@ +libgssglue (0.7-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Be more lenient when checking for pkg-config's cflags output +in the autopkgtest. libs output was already leniently checked. +(Closes: #1024278) + + -- Philipp Kern Mon, 12 Dec 2022 13:03:24 +0100 + libgssglue (0.7-1) unstable; urgency=medium * New upstream version 0.7 diff -Nru libgssglue-0.7/debian/tests/libgssglue libgssglue-0.7/debian/tests/libgssglue --- libgssglue-0.7/debian/tests/libgssglue 2022-08-16 01:26:24.0 +0200 +++ libgssglue-0.7/debian/tests/libgssglue 2022-12-12 13:03:16.0 +0100 @@ -6,7 +6,7 @@ trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM pkg-config --cflags libgssglue -pkg-config --cflags libgssglue | grep '^-I/usr/include/gssglue$' +pkg-config --cflags libgssglue | grep '^-I/usr/include/gssglue' echo PASS: pkg-config --cflags libgssglue pkg-config --libs libgssglue
Bug#1024278: libgssglue: autopkgtest failure with pkgconf
Hey Simon, On Thu, Nov 17, 2022 at 12:46:19PM +0100, Sebastian Ramacher wrote: > > I see. If so, it would be good if pkgconf was made consistent with > > pkg-config here, if the intention is to replace it. > > This discussion needs to happen with the pkgconf maintainer / upstream. > But since this is the only package where the extra whitespace seems to > be an issue, I'd just be pragmatic on the libgssglue side. Could we be pragmatic here and fix it in Debian in the meantime? It'd be a shame if we had a couple of packages autoremoved from testing due to this, if it's basically a one character change somewhere. Kind regards and thanks Philipp Kern
Bug#1004638: Bug#1013009: Bug#1004638: openjfx: FTBFS with ffmpeg 5.0
Hi Emmanuel, On 17.10.22 01:28, Emmanuel Bourg wrote: Le 16/10/2022 à 17:10, Philipp Kern a écrit : While arm64/armhf remains unfixed (and could have its own t-p-u upload based on the +0 version plus Ubuntu's patch), there's also a question if a newer version would actually fix the issue. I talked to Sebastian on IRC and we agreed that I'd upload the Ubuntu patch for now. It doesn't make anything worse and will allow building on amd64 again. Hi Philipp, Thank you for taking the time to look into the openjfx package. Do you know how difficult porting to ffmpeg 5.0 would be? The video support is a major feature of OpenJFX, removing it isn't ideal. https://github.com/FFmpeg/FFmpeg/blob/master/doc/APIchanges has the changes. It might not be too involving itself if it were up-to-date with the most recent ffmpeg pre-5.0. It's possible that it did not follow earlier deprecations. In the best case it's mostly moving around includes and deleting obsolete functions. I did check upstream and couldn't find a ported version either. But then was also kind of left confused given the myriad of tags and a new repository location as well as the separate repository for the older version. Kind regards and thanks Philipp Kern
Bug#1004638: openjfx: FTBFS with ffmpeg 5.0
tag 1013009 + pending
tag 1004638 + pending
thanks
On Sun, Oct 16, 2022 at 03:53:13PM +0200, Philipp Kern wrote:
> I think it's still worthwhile to upload this build.
While arm64/armhf remains unfixed (and could have its own t-p-u upload
based on the +0 version plus Ubuntu's patch), there's also a question if
a newer version would actually fix the issue.
I talked to Sebastian on IRC and we agreed that I'd upload the Ubuntu
patch for now. It doesn't make anything worse and will allow building
on amd64 again.
nmudiff attached.
Kind regards
Philipp Kern
diff -Nru openjfx-11.0.11+1/debian/changelog openjfx-11.0.11+1/debian/changelog
--- openjfx-11.0.11+1/debian/changelog 2022-05-03 16:48:31.0 +0200
+++ openjfx-11.0.11+1/debian/changelog 2022-10-16 12:19:38.0 +0200
@@ -1,3 +1,14 @@
+openjfx (11.0.11+1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop build-dependency on ffmpeg, openjfx isn't source-compatible with
+ffmpeg 5.0. Closes: #1004638.
+ * Build-depend on g++-11, source not compatible with g++ 12.
+Closes: #1013009.
+(Both patches taken from Ubuntu, thanks to Steve Langasek)
+
+ -- Philipp Kern Sun, 16 Oct 2022 12:19:38 +0200
+
openjfx (11.0.11+1-1) unstable; urgency=medium
* New upstream release
diff -Nru openjfx-11.0.11+1/debian/control openjfx-11.0.11+1/debian/control
--- openjfx-11.0.11+1/debian/control2022-05-03 15:33:58.0 +0200
+++ openjfx-11.0.11+1/debian/control2022-10-16 12:19:38.0 +0200
@@ -10,13 +10,12 @@
default-jdk,
default-jdk-doc,
flex,
+ g++-11,
gperf,
gradle (>= 4.4),
gradle-debian-helper (>= 2.0),
junit4,
libasound2-dev,
- libavcodec-dev,
- libavformat-dev,
libgl1-mesa-dev,
libgstreamer-plugins-base1.0-dev,
libgstreamer1.0-dev,
diff -Nru openjfx-11.0.11+1/debian/patches/disable-ffmpeg.patch
openjfx-11.0.11+1/debian/patches/disable-ffmpeg.patch
--- openjfx-11.0.11+1/debian/patches/disable-ffmpeg.patch 1970-01-01
01:00:00.0 +0100
+++ openjfx-11.0.11+1/debian/patches/disable-ffmpeg.patch 2022-10-16
12:19:38.0 +0200
@@ -0,0 +1,24 @@
+Description: Don't build ffmpeg plugin when ffmpeg is disabled
+Author: Steve Langasek
+Last-Update: 2022-09-21
+Bug-Debian: https://bugs.debian.org/1004638
+
+Index: openjfx-11.0.11+1/build.gradle
+===
+--- openjfx-11.0.11+1.orig/build.gradle
openjfx-11.0.11+1/build.gradle
+@@ -3715,14 +3715,6 @@ project(":media") {
+ }
+ }
+ }
+-} else {
+-// Building fxavcodec plugin (libav plugin)
+-exec {
+-commandLine ("make", "${makeJobsFlag}", "-C",
"${nativeSrcDir}/gstreamer/projects/linux/avplugin")
+-args("CC=${mediaProperties.compiler}",
"LINKER=${mediaProperties.linker}",
+- "OUTPUT_DIR=${nativeOutputDir}",
"BUILD_TYPE=${buildType}",
+- "BASE_NAME=avplugin", IS_64 ? "ARCH=x64"
: "ARCH=x32")
+-}
+ }
+ }
+ }
diff -Nru openjfx-11.0.11+1/debian/patches/series
openjfx-11.0.11+1/debian/patches/series
--- openjfx-11.0.11+1/debian/patches/series 2022-05-03 15:27:46.0
+0200
+++ openjfx-11.0.11+1/debian/patches/series 2022-10-16 12:19:38.0
+0200
@@ -18,3 +18,4 @@
no-error_deprecated-declarations.patch
32-gradle-compatibility.patch
36-disable-swt-on-32bit-arch.patch
+disable-ffmpeg.patch
diff -Nru openjfx-11.0.11+1/debian/rules openjfx-11.0.11+1/debian/rules
--- openjfx-11.0.11+1/debian/rules 2022-05-03 15:27:46.0 +0200
+++ openjfx-11.0.11+1/debian/rules 2022-10-16 12:19:38.0 +0200
@@ -3,6 +3,8 @@
DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+export CXX=g++-11
+
# FIXME: looks like s390x is recognized as a 32bit arch ...
# more heap on s390x needed
ifneq (,$(filter $(DEB_HOST_ARCH), s390x))
Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure
Hi, On Wed, Dec 08, 2021 at 12:11:28PM +, Thorsten Glaser wrote: > Michael Meskes dixit: > > >I did some more testing and it seems this simple patch fixes the issue: > > I think you should still include a setgroups(0, NULL) call there. > > Personally I’d prefer setres[ug]id() because that makes the intent > more explicit even when the effect is the same, but… I’ll let you > and the security team decide. Gentle bump for this issue. Also shouldn't patching out setusercontext and having no substitute get a CVE? >:) calendar.c forks, so there is no need to regain privileges post setuid(). I'm kinda with tg in that setres[ug]id() makes the intent clearer instead of relying on uid==0 behavior. Kind regards Philipp Kern
Bug#1004638: openjfx: FTBFS with ffmpeg 5.0
Hey, On 16.10.22 14:02, Sebastian Ramacher wrote: I was looking into applying Ubuntu's patch to Debian. It still has the issue that the builds on arm64 and armhf fail. Reverting to 11.0.11+0 seems to fix that. So we definitely need the g++-11 dependency as well. I guess I was misled by the most recent logs now failing due to ffmpeg, but the earlier log failed differently - that's true. I think it's still worthwhile to upload this build. It looks like the getJumpIsland* code is guarded by an JUMP_ISLANDS ifdef (and newly introduced in +1). But it's also hard-enabled for ARM64 specifically: | #if CPU(ARM64) && CPU(ADDRESS64) | #define USE_JUMP_ISLANDS 1 | #endif Did I expect to run into an embedded copy of WebKit? Not really. We are also already turning off the JIT for armel through a patch. Kind regards Philipp Kern
Bug#1004963: Bug#1014977: libde265: CVE-2022-1253 CVE-2021-36411 CVE-2021-36410 CVE-2021-36408 CVE-2021-35452
tags -1 + pending
thanks
Hey Moritz,
On Fri, Jul 15, 2022 at 05:48:41PM +0200, Moritz Mühlenhoff wrote:
> The following vulnerabilities were published for libde265.
[...]
Thanks for clearly linking to the upstream commits, that was very
helpful! Compared to the older bug these were quite straightforward to
apply. The CVEs referenced by #1004963 are still open in upstream's
bugtracker.
Attached is the diff of the NMU I just uploaded to DELAYED/2-days.
Kind regards and thanks
Philipp Kern
diff -Nru libde265-1.0.8/debian/changelog libde265-1.0.8/debian/changelog
--- libde265-1.0.8/debian/changelog 2020-12-16 16:32:29.0 +0100
+++ libde265-1.0.8/debian/changelog 2022-10-16 15:26:20.0 +0200
@@ -1,3 +1,17 @@
+libde265 (1.0.8-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Import upstream fixes for CVE-tracked vulnerabilities
+(Closes: #1014977)
+- CVE-2022-1253
+- CVE-2021-36411
+- CVE-2021-36410
+- CVE-2021-36409
+- CVE-2021-36408
+- CVE-2021-35452
+
+ -- Philipp Kern Sun, 16 Oct 2022 15:26:20 +0200
+
libde265 (1.0.8-1) unstable; urgency=medium
* Update to debhelper compat level 13 and add debian/not-installed
diff -Nru libde265-1.0.8/debian/patches/0001-CVE-2022-1253.patch
libde265-1.0.8/debian/patches/0001-CVE-2022-1253.patch
--- libde265-1.0.8/debian/patches/0001-CVE-2022-1253.patch 1970-01-01
01:00:00.0 +0100
+++ libde265-1.0.8/debian/patches/0001-CVE-2022-1253.patch 2022-10-16
15:19:58.0 +0200
@@ -0,0 +1,50 @@
+From 8e89fe0e175d2870c39486fdd09250b230ec10b8 Mon Sep 17 00:00:00 2001
+From: Dirk Farin
+Date: Tue, 5 Apr 2022 09:52:57 +0200
+Subject: [PATCH] error on out-of-range cpb_cnt_minus1 (oss-fuzz issue 27590)
+
+---
+ libde265/sps.cc | 5 -
+ libde265/vui.cc | 6 ++
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+Index: libde265-1.0.8/libde265/sps.cc
+===
+--- libde265-1.0.8.orig/libde265/sps.cc
libde265-1.0.8/libde265/sps.cc
+@@ -425,7 +425,10 @@ de265_error seq_parameter_set::read(erro
+
+ vui_parameters_present_flag = get_bits(br,1);
+ if (vui_parameters_present_flag) {
+-vui.read(errqueue, br, this);
++de265_error err = vui.read(errqueue, br, this);
++if (err) {
++ return err;
++}
+ }
+
+
+Index: libde265-1.0.8/libde265/vui.cc
+===
+--- libde265-1.0.8.orig/libde265/vui.cc
libde265-1.0.8/libde265/vui.cc
+@@ -201,6 +201,9 @@ de265_error video_usability_information:
+ if (!low_delay_hrd_flag[i])
+ {
+ READ_VLC_OFFSET(cpb_cnt_minus1[i], uvlc, 0);
++ if (cpb_cnt_minus1[i] > 31) {
++ return DE265_ERROR_CODED_PARAMETER_OUT_OF_RANGE;
++ }
+ }
+
+ for (nalOrVcl = 0; nalOrVcl < 2; nalOrVcl++)
+@@ -361,6 +364,9 @@ de265_error video_usability_information:
+ if (vui_hrd_parameters_present_flag) {
+ de265_error err;
+ err = hrd_parameters(errqueue, br, sps);
++ if (err) {
++ return err;
++ }
+ }
+ }
+
diff -Nru libde265-1.0.8/debian/patches/0001-fill-32x32-scaling-matrices.patch
libde265-1.0.8/debian/patches/0001-fill-32x32-scaling-matrices.patch
--- libde265-1.0.8/debian/patches/0001-fill-32x32-scaling-matrices.patch
1970-01-01 01:00:00.0 +0100
+++ libde265-1.0.8/debian/patches/0001-fill-32x32-scaling-matrices.patch
2022-10-16 15:25:49.0 +0200
@@ -0,0 +1,85 @@
+From 7d5aeb5f11531de33f5b7ae0e768ffc50da4facb Mon Sep 17 00:00:00 2001
+From: Dirk Farin
+Date: Tue, 23 Feb 2021 16:29:01 +0100
+Subject: [PATCH] fill 32x32 scaling matrices
+
+---
+ libde265/sps.cc | 25 +++--
+ libde265/sps.h| 2 +-
+ libde265/transform.cc | 4 +---
+ 3 files changed, 25 insertions(+), 6 deletions(-)
+
+Index: libde265-1.0.8/libde265/sps.cc
+===
+--- libde265-1.0.8.orig/libde265/sps.cc
libde265-1.0.8/libde265/sps.cc
+@@ -873,10 +873,10 @@ de265_error read_scaling_list(bitreader*
+ int dc_coeff[4][6];
+
+ for (int sizeId=0;sizeId<4;sizeId++) {
+-int n = ((sizeId==3) ? 2 : 6);
++//int n = ((sizeId==3) ? 2 : 6);
+ uint8_t scaling_list[6][32*32];
+
+-for (int matrixId=0;matrixIdScalingFactor_Size1[matrixId][y][x];
++
++ for (int dy=0;dy<4;dy++)
++for (int dx=0;dx<4;dx++) {
++ sclist->ScalingFactor_Size3[matrixId][4*y+dy][4*x+dx] = v;
++}
++ }
++
++ sclist->ScalingFactor_Size3[matrixId][0][0] =
sclist->ScalingFactor_Size1[matrixId][0][0];
++}
++
+ return DE265_OK;
+ }
+
+Index: libde265-1.0.8/libde265/sps.h
+===
+--- libde265-1.0.8.orig/libde265/sps.h
libde265-1.0.8/libde265/sps.h
+@@ -54,7 +54,7 @@ typedef struct scaling_list_data {
+ uint8_t ScalingFactor_Size0[6][4][4];
+ ui
Bug#1004638: openjfx: FTBFS with ffmpeg 5.0
On Sun, Jan 30, 2022 at 11:23:39PM +0100, Sebastian Ramacher wrote: > openjfx FTBFS with ffmpeg 5.0 (available in experimental): [...] It looks like even upstream openjfx (moved to [1]) is still not source-compatible with ffmpeg 5.0. I could not find a bug in Oracle's Java bug tracker about this either. Ubuntu has disabled ffmpeg support[2], but hasn't released with that yet (it's only in Kinetic due to be released soonish). This drops libavplugin.so completely from libopenjfx-jni. Source packages with a reverse (build-)dependency: | afterburner.fx | controlsfx | davmail | easybind | fontawesomefx | igv | javafxsvg | josm | libhibernate-validator-java | libjloda-java | libmiglayout-java | mediathekview | megan-ce | openchemlib | pdfsam | starjava-topcat | triplea | zeroc-ice controlsfx uses javafx.scene.media.Media. pdfsam uses javafx.scene.media.AudioClip. The others don't use javafx.scene.media at all. mediathekview does not use controlsfx's MediaImageCell - which is the one importing javafx.scene.media.Media. So I'd assume that within Debian this breaks at most completion sound functionality in pdfsam-gui if we were to drop the ffmpeg build-dependency. I'm going to go ahead and do that. Kind regards Philipp Kern [1] https://github.com/openjdk/jfx [2] https://patches.ubuntu.com/o/openjfx/openjfx_11.0.11+1-1ubuntu1.patch
Bug#885563: vte: Do not release with Buster
On Sun, Sep 30, 2018 at 09:03:47AM -0400, Jeremy Bicha wrote: > On Sun, Sep 30, 2018 at 2:57 AM Niels Thykier wrote: > > AFAICT, the cdebconf-gtk-terminal bug (#887649) has not been updated in > > the past 8 months. Is it still realistic to remove vte before the > > transition freeze (2019-01-12)? > I agree that I don't see anyone working on that bug now. I think > porting to gtk3 and getting rid of the unmaintained vte version is an > important goal for Debian. I'd like to leave this bug as RC for Buster > until the Transition Freeze. Unfortunately it doesn't look like there was progress on #887649 this cycle either. So I fear that we'll end up needing to tag both #887649 and #885563 bookworm-ignore. :( Kind regards Philipp Kern
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
On Wed, Sep 15, 2021 at 12:34:53AM +0200, Lukas Schwaighofer wrote: > With the new version of gnu-efi that was recently uploaded [1] to > unstable, syslinux fails to build from source. > > So far I tried applying a simple fix from the upstream mailing list [2] > which result in a successful build, but the efi binaries from that > build are unbootable. It looks like Ubuntu added a patch to fix this slightly differently (adding to efi/main.c instead of adding [1]). With that it compiles as well. I don't quite understand the reference to glibc in the changelog[2], though. This is reusing syslinux's internal setjmp logic copied from klibc while gnu-efi rolled its own. It's also possible that by including the "wrong" header you get the wrong linkage against the wrong implementation. Could you try this out? Apparently I cannot test this within qemu OVMF (per [3] and it also didn't boot for me). Kind regards Philipp Kern [1] http://launchpadlibrarian.net/553034379/syslinux_3%3A6.04~git20190206.bf6db5b4+dfsg1-3_3%3A6.04~git20190206.bf6db5b4+dfsg1-3ubuntu1.diff.gz [2] https://launchpad.net/ubuntu/+source/syslinux/3:6.04~git20190206.bf6db5b4+dfsg1-3ubuntu1 [3] https://wiki.archlinux.org/title/syslinux#Limitations_of_UEFI_Syslinux
Bug#1003479: swig: Missing support for php8.1
On Mon, Jan 10, 2022 at 10:21:11PM +0100, Vincent Danjean wrote: > Looking at upstream, support for php8 will be present in swig 4.1.0 that is > not yet released. It looks like it's due to be released in a week (2022-10-24). Kind regards Philipp Kern
Bug#1021390: nvda2speechd: downloads source from the network during build
On 10.10.22 22:02, Samuel Thibault wrote: I think in its current state the package is anyway non-free since it does not fulfill the DFSG for the contents it ships in its binary packages. Ok, let's move it to non-free then. I admit that I'm surprised that policy 4.9 actually provides a carve-out for this - only targeting network access restrictions to "main": For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. Pulling external code during the build from a package in the archive is still super surprising to me. Do we have other precedents? I can see how it's a pragmatic solution but [1] together with [2] kinda scares me. ;-) At that point, couldn't we ship the cross-build target compiler prebuilt in non-free? That being said, that would unfortunately still not help with buildds, given that we still don't support build-dependencies on non-free packages unfortunately. :( Kind regards Philipp Kern [1] https://sources.debian.org/src/nvda2speechd/0.1-5/debian/rules/#L29 [2] https://github.com/rust-lang/rustup/issues/2028
Bug#1015897: gobby: Gobby is crashing right after calling it
Hi, On 26.07.22 11:28, Andreas Tille wrote: Am Tue, Jul 26, 2022 at 09:58:49AM +0200 schrieb Philipp Kern: On 23.07.22 15:09, Andreas Tille wrote: ** (gobby:197027): WARNING **: 15:06:06.692: Failed to create root directory: Permission denied Subsequent storage operations will most likely fail How do your permissions on ~/.config drwxr-xr-x 90 andreas andreas 4096 26. Jul 11:24 .config and ~/.config/gobby look like? drwxr-xr-x 2 andreas andreas 4096 20. Jul 10:11 gobby $ ls -lR .config/gobby .config/gobby: insgesamt 8 -rw-r--r-- 1 andreas andreas 52 23. Aug 2020 documents.xml -rw-r--r-- 1 andreas andreas 298 23. Aug 2020 hosts.xml -rw-r--r-- 1 andreas andreas 0 12. Aug 2013 known_hosts -rw-r--r-- 1 andreas andreas 0 23. Aug 2020 recent_hosts Does the latter exist now? It existed - but if I remove it no such dir is create newly. And how about ~/.infinote-records and your homedir? FWIW, it does not crash for me on a new installation on bookworm. Kind regards Philipp Kern
Bug#1015897: gobby: Gobby is crashing right after calling it
Hi, On 23.07.22 15:09, Andreas Tille wrote: ** (gobby:197027): WARNING **: 15:06:06.692: Failed to create root directory: Permission denied Subsequent storage operations will most likely fail How do your permissions on ~/.config and ~/.config/gobby look like? Does the latter exist now? Kind regards Philipp Kern
Bug#1012166: ITP: haskell-tzdata -- Haskell package that distributes the standard time zone database
Hi, On 31.05.22 10:14, Robert Greener wrote: The goal of this package is to distribute the standard Time Zone Database in a cabal package, so that it can be used in Haskell programs uniformly on all platforms. This package currently ships the 2022a version of the time zone database. The version of the time zone database shipped is always reflected in the version of this package: x.y.MMDD.z, then MMDD is the official release date of time zone database. I'm not sure further proliferation of this data that needs updating frequently is helpful. Is there any way this data could instead be read from disk - i.e. the from the existing tzdata package? This would add up to the load of all the various packages of various languages that already need updating with every tzdata release. Kind regards Philipp Kern
Bug#1004994: src:ibm-3270: fails to migrate to testing for too long: uploader built arch:all binaries
Hi Paul, On 05.02.22 08:50, Paul Gevers wrote: Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Feel free to accelerate this upload. Thanks! Kind regards Philipp Kern
Bug#969354: lists.debian.org: Use DKIM with lists.debian.org
[This is a repeat of the archived #500966] On Mon, Aug 31, 2020 at 07:30:13PM -0400, Alexander Tait Brotman wrote: > lists.debian.org should use DKIM as part of taking ownership of its > messages. This allows mailbox providers to be reasonably sure that > messages signed by the systems can be attributed to lists.debian.org, > and perhaps assist with domain reputation. This may also help with > forwarding as ARC gains traction as well. This should not have any > major impact on performance, nor on deliverability. I don't think DKIM will help much. But it would really, really help if lists.debian.org could do ARC so that providers can a) do reputation or b) just trust that domain to get it right. Yes, there have been some changes to invalidate DKIM signatures less, but you cannot control what the incoming DKIM signature encompassed. So I found a mail recently where there were various headers included that lists.debian.org modifies by design. ARC solves this problem by just letting you sign the outgoing emails, regardless of prior DKIM status. Kind regards Philipp Kern
Bug#993750: rgtk2: FTBFS on s390x: smoke-test failure: caught segfault
On 06.09.21 10:39, Simon McVittie wrote: This happened on s390x buildds consistently across two builds of the +b2 binNMU, but I can't reproduce it on the s390x porterbox zelenka in either a sid or bullseye chroot, which is odd. I've given back the official buildd build to see whether it was something transient. s390 porters: are there any important differences between the s390x porterbox and the s390x buildds, like a different CPU or something? zelenka is a z15 8561. Same for zani and zandonai. Kernel-wise we have a mix: Linux zandonai 4.19.0-17-s390x #1 SMP Debian 4.19.194-3 (2021-07-18) s390x GNU/Linux Linux zani 5.10.0-8-s390x #1 SMP Debian 5.10.46-4 (2021-08-03) s390x GNU/Linux Linux zelenka 4.19.0-17-s390x #1 SMP Debian 4.19.194-3 (2021-07-18) s390x GNU/Linux (zani is the only machine of the three on Debian 11) Kind regards Philipp Kern
Bug#993488: maybe reason for wontfix?
On 2021-09-03 14:23, Tomas Pospisek wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a "wontfix + close" but no rationale. Which leaves the original reporter with a large "?" I guess. I am guessing that the reason for the "wontfix" is "that's just how Unix works unfortunately" aka "that's a Unix design bug"? Is my guess correct? One other question - any idea on a way forward here? I would guess that behaviour (changing group membership won't change group membership of running processes) is rooted somewhere quite low in the stack, maybe in the kernel itself (or in posix :-#)? So if the original reporter would want to go ahead and look to that problem beeing fixed would he need to go talk to the kernel mailing list or do you have idea where he could go to? Processes in *nix inherit permissions. That's inherent to the design. If you want more guarantees, you need to move from discretionary access control (based on the identity at the time of process (tree) creation) to mandatory access control (e.g. SELinux). Kind regards Philipp Kern
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 03.09.21 13:11, Simon Richter wrote: [Revocation mechanism] If we don't have one, shouldn't we worry more about that given the widespread use of TLS? We have a big hammer, shipping a new ca-certificates package. If we want something that only affects apt, but not other packages, that mechanism doesn't exist yet. I think that's an interesting point, not just for revocation. There are forces pushing for more agility, switching out roots of trust more frequently. So for very old releases, you usually had the signing key of the next release on disk, so you could move to the next release. In this case you sort of risk not having the TLS authority on disk to make that happen. And of course we need to track what the authorities are doing that our frontends are using (e.g. [1] around how to deal with old Android devices). But then I'm not sure how much we need to care about ancient releases that are out of security support. We would need to commit to regularly update the certificate bundle, though. To your other point: I don't think managing trust into individual CAs will scale. We cannot really anticipate which CAs we are going to use in the future. Kind regards Philipp Kern [1] https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 18.04.21 17:27, Salvatore Bonaccorso wrote: > Is this bug still valid to be open? > > The mentioned commit landed in 5.3-rc1, 4.19.54 and as well 4.9.183. Unfortunately the daily debian-installer build (on Linux 5.10.0-6-s390x) is still broken on qemu-system-s390x. So the s390x part is still true. Kind regards Philipp Kern
Bug#985556: flatpak/1.2.5-0+deb10u4 FTBFS on i386
On 20.03.21 13:32, Simon McVittie wrote: > On Sat, 20 Mar 2021 at 09:16:45 +0100, Salvatore Bonaccorso wrote: >> On Sat, Mar 20, 2021 at 12:12:39AM +, Simon McVittie wrote: >>> Could x86-conova-01.debian.org be an IPv6-only buildd? > ... >>> Or, if not that, could it be the case that this buildd is firewalled or >>> otherwise restricted such that connections from the build to a test >>> server listening on an arbitrary high port number on the loopback >>> interface will fail? >> >> JFTR, this might indeed be the case. I gave it back a couple of times >> and building on x86-conova-01.debian.org failed. The last one got >> picked on buildd-x86-grnet-01 which now seems to have built. > > If we now have buildds that are more restrictive or limited than > the buildds that were used at the time stable was frozen, then > it would probably be good if it was possible to arrange for only > testing/unstable/experimental packages to be built on those buildds, > with stable updates built on buildds that more closely resemble the ones > they were originally tested on - otherwise we'll get random build > regressions. The buildd is IPv6-only. I'm somewhat torn given that we have enough buildd coverage that a give-back would likely solve the problem. At the same time you can't avoid a particular buildd either. So I concur, as much as it hurts me in this day and age, that we should at least temporarily disable stable/oldstable builds on the IPv6-only buildds. I have commented out stretch and buster (and their corresponding security and backports suites) on x86-conova-01 for now. I'll definitely leave bullseye on, though. Not sure if there's another IPv6-only buildd lingering around. Kind regards and thanks Philipp Kern
Bug#981297: ITP: smbus2 -- another pure Python implementation of the python-smbus package
On 28.01.21 21:44, Anton Gladky wrote: > * Package name : smbus2 > Version : 0.4.1 > Upstream Author : Karl-Petter Lindegaard > * URL : https://github.com/kplindegaard/smbus2 > * License : MIT > Programming Lang: Python > Description : another pure Python implementation of the > python-smbus package Do you mean "another implementation of python-smbus, written in pure Python"? Like this it sounds like yet another one was needed, with no real justification in the description. Kind regards Philipp Kern
Bug#805305: tasksel_3.62_source.changes REJECTED
On 2020-12-21 11:24, John Paul Adrian Glaubitz wrote: On 12/21/20 11:08 AM, Holger Wansing wrote: If I understand this correctly, dm's are not allowed to upload packages including NEW parts / introducing new packages? Correct. The DM permissions that you have received are static and if you tried to upload anything outside these static permissions, you will get a REJECT. (I could not find this documented in Debian Policy or Developers Reference BTW, so maybe I am wrong with the above assumption?) No, it's just not documented. The authoritative documentation is (sadly) in a GR: https://www.debian.org/vote/2007/vote_003 And it was unclear how much of it can actually be changed without a GR - despite ~all bullet points saying "initial policy". A power to set policy has not been conferred to a team with this GR. At least that's what I recall. ;-) Kind regards Philipp Kern
Bug#975496: O: hercules -- System/370, ESA/390 and z/Architecture Emulator
Package: wnpp Severity: normal I intend to orphan the hercules package. It's an s390(x) emulator and the package itself is in fairly good shape overall. It's mostly that I have no use for it for several years now. (And mostly I do not want to feel responsible for it anymore.) Upstream has been trying for years to get a 4.0 release together[0], but the last commit for that was back in 2019. The website also moved around a bunch of times. So it's unclear at this point how maintained it is, if at all. qemu also offers a usable s390x emulator. I'd say that hercules is a lot more true to the original hardware, especially if you need to emulate the platform for something else than Linux. Or if you want to emulate an ancient System/360 or System/370. The package's description is: > Hercules is an open source software implementation of the mainframe > System/370 > and ESA/390 architectures, in addition to the new 64-bit z/Architecture. > . > This means that your PC can emulate an IBM mainframe processor. The > mainframe can range from a 360 to a z900 - running in "System/370" > mode, "ESA/390" mode, or "z/Architecture" mode. Hercules executes > S/370, ESA/390, and z/Architecture instructions and channel > programs. It emulates mainframe I/O devices by using PC devices. For > example, 3390 DASD devices are emulated by large files on your hard > disk, and local 3270 screens are emulated by tn3270 sessions. > . > Hercules implements only the raw S/370, ESA/390, and z/Architecture > instruction set; it does not provide any operating system facilities. This > means that you need to provide an operating system or standalone program > which > Hercules can load from an emulated disk or tape device. You will have to use > a > free software operating system such as Linux, write the operating system or > standalone program yourself, obtain a license from IBM to run one of their > operating systems on your PC, or use IBM programs and operating systems which > have been placed in the public domain. > . > Virtual networking can be accomplished using the TUN/TAP driver in > host Linux kernel. [0] https://github.com/hercules-390/hyperion signature.asc Description: OpenPGP digital signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On 18.11.20 18:33, Matthew Vernon wrote: > Package: tech-ctte > Control: block 921012 by -1 > Control: block 964139 by -1 > X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk > > Dear Technical Committee, > > This bug report relates specifically to bugs in the network-manager > package (#921012, #964139) but has broader implications, particularly > around what it means to "support the efforts of developers"[0] working > on support for alternative init systems (I will talk about sysvinit here > without loss of generality to other non-systemd init systems). > > In brief: > > #921012 is about changing network-manager to Depend upon "default-logind > | logind" rather than libpam-systemd > > #964139 is about restoring the removed network-manager init script which > was removed from the package. There is no suggestion that the init > script was buggy > > Both changes are necessary for it to be possible to install > network-manager on a sysvinit system; it is going to be hard to use > Debian without network-manager. > > Both bugs have sat open for extended periods with no input from the > maintainer; so I prepared an NMU and uploaded it to DELAYED/14 as well > as making an MR on salsa[1]. > > The NMU was declined, on the basis that removing the init script was not > a mistake; I'm not aware of any rationale being provided beyond that for > refusing either patch. > > I'm afraid the effect of this is that the maintainers of this package > are making it impossible for other developers to enable support of > sysvinit. There are people[2] who will (and have) test compatibility > changes, help with issues with sysvinit scripts, and so on, but those > efforts are in effect being stonewalled. > > The effect of this, and equivalent behaviour in some other packages, is > that it is going to be impossible to make a useful Bullseye for users > who want to use sysvinit. > > I (and a couple of other interested parties) have approached the DPL > about this matter on a number of occasions this year, and have tried to > follow their advice where possible. I regret that it has proved > necessary to involve the technical committee. > > I invite the technical committee to rule that: > * The network-manager init script should be restored > * Network-manager should Depend: on default-logind | logind rather than > libpam-systemd > * Similar init-compatibility changes should not be blocked by package > maintainers unless they are defective on their own merits > * These changes be made in time to be effective in Bullseye I know it was mentioned back in the day, but trying to re-ask it now: Wouldn't it be possible to ship init scripts for compatibility purposes from a sysvinit (or maybe a sysvinit-support) package? This would be the inverse of what happened back when systemd was introduced, which was about shipping service files that superseded existing init scripts. I understand that you might not want that maintenance burden, however it seems like the network-manager maintainers might not want that maintenance burden either. That obviously would not solve the dependency issue, where the (not copied) claim of the maintainers is that there is no interface equality between what you suggest and what they think is appropriate. The last message in the bug suggested dropping a file in network-manager's config directory to disable a certain feature. With hooks it's clearly acceptable to drop files into configs of other packages and one could argue that a configuration directory is a similarly acceptable interface to reuse from another package. Maybe there'd be an amenable way if the interaction is properly defined? Like a support package doing that providing some pseudo-package that can serve as an alternative dependency. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#241060: hercules: doesn't handle ^Z
On Tue, Mar 30, 2004 at 04:55:10PM +0200, Matthias Urlichs wrote: > While hercules is interruptible by pressing ^Z, some things are a > bit ugly: > > - - it doesn't reset terminal colors, i.e. the shell prompt is > yellow-on-red when I do that; > > - - after resuming, line editing doesn't work any more, and doesn't > switch screens. I can confirm that this is still the case with a contemporary 3.13 Hercules build. Kind regards Philipp Kern
Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.
On 05.11.20 17:41, David Heidelberg wrote: > Package: wnpp > Severity: wishlist > Owner: David Heidelberg > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: dosbox-staging > Version : 0.76 > Upstream Author : The DOSBox Staging Team > * URL : https://dosbox-staging.github.io/ > * License : GPL-2.0-or-later > Programming Lang: C, C++ > Description : DOSBox Staging is a full x86 CPU emulator (independent of > host architecture), capable of running DOS programs that require real or > protected mode. > > > DOSBox Staging is a full x86 CPU emulator (independent of host > architecture), capable of running DOS programs that require real or > protected mode. > It features: > * A built-in DOS-like console > * Emulation of several PC variants: IBM PC, IBM PCjr, Tandy 1000), > and CPUs (286, 386, 486, and Pentium I) > * Graphics chipsets: Hercules, CGA, EGA, VGA, and SVGA > * Audio solutions: PC Speaker, Tandy Sound System, Disney Sound Source, > Sound Blaster series, and Gravis UltraSound > * CDROM and CD Digital Audio with audio optionally encoded as FLAC, > Opus, OGG/Vorbis, MP3 or WAV > * Joystick emulation working with modern game controllers > * Serial port emulation including IPX over UDP and Telnet over TCP/IP > * Hardware-accelerated video output including integer (pixel-perfect) > scaling, sharp-bilinear scaling, OpenGL shaders, and more > > DOSBox Staging is highly configurable and sufficiently-optimized to run > any DOS game on a modern computer. > > Q: why is this package useful/relevant? > A: Sucessor of DOSBox, which is already inside Debian Why do we need both rather than upgrading dosbox? Is this package supposed to take over the existing binary package eventually? Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#964221: googletest: meson support
Hey Steven, On 20.10.20 03:26, Steven Robbins wrote: > On Fri, 3 Jul 2020 22:14:18 +0200 Philipp Kern wrote: > >> Would it be possible for googletest in Debian to ship these meson.build files >> alongside the source in the library packages? That way packages could >> build-depend on libgtest-dev without requiring them to use CMake. > > It's a reasonable request. Where in the filesystem would you like to see > these > three files? The wrap is pretty specific in that googletest and googlemock have to be subdirectories. So effectively the wrap is unzipped today at the /usr/src/googletest level - which seems very reasonable to me as it mimics the existing CMakeLists.txt layout as well. Kind regards and thanks Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#972337: RFA: openclonk -- multiplayer game of strategy, action and skill
On 16.10.20 12:38, Philipp Kern wrote: > Package: wnpp > Severity: normal > > I request an adopter for the openclonk package. > > The package description is: > OpenClonk is a free multiplayer action game where you control clonks, > small but witty and nimble humanoid beings. The game is mainly about > mining, settling and fast-paced melees. OpenClonk is also not just a > game but also a versatile 2D game engine that offers countless > possibilities to make own mods. > . > This package contains the OpenClonk engine. > > Releasing has slowed down massively in recent years, the last release per > https://openclonk.org was back in March 2018. There is still activity on > https://github.com/openclonk/openclonk, though. Something to clarify: As this is team-maintained by the Games team, it mostly needs a new uploader who feels responsible for it. Kind regards Philipp Kern
Bug#972337: RFA: openclonk -- multiplayer game of strategy, action and skill
Package: wnpp Severity: normal I request an adopter for the openclonk package. The package description is: OpenClonk is a free multiplayer action game where you control clonks, small but witty and nimble humanoid beings. The game is mainly about mining, settling and fast-paced melees. OpenClonk is also not just a game but also a versatile 2D game engine that offers countless possibilities to make own mods. . This package contains the OpenClonk engine. Releasing has slowed down massively in recent years, the last release per https://openclonk.org was back in March 2018. There is still activity on https://github.com/openclonk/openclonk, though.
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 14.06.20 17:20, Philipp Kern wrote:
> On 11.05.20 11:53, Winfried Münch wrote:
>> package: s390-tools
>>
>> Version: current Installer from 04.05.2020 21:14
>> http://ftp.halifax.rwth-aachen.de/debian/dists/buster/main/installer-s390x/current/images/generic/
>>
>>
>> When I install debian I run in this Problem (from console 4):
>>
>> May 11 09:43:43 debootstrap: Errors were encountered while processing:
>> May 11 09:43:43 debootstrap: s390-tools
>> May 11 09:43:44 debootstrap: dpkg: dependency problems prevent
>> configuration of s390-tools:
>> May 11 09:43:44 debootstrap: s390-tools depends on perl:any.
>> May 11 09:43:44 debootstrap:
>> May 11 09:43:44 debootstrap: dpkg: error processing package s390-tools
>> (--configure):
>> May 11 09:43:44 debootstrap: dependency problems - leaving unconfigured
>>
>> Installation failed in step install base system.
>
> perl:any is not part of the transitive closure that debootstrap
> calculates. To me it looks like a bug in debootstrap in that it does not
> find a deb to download because it does not drop the :any - either in
> pkgdetails or before.
>
> This was presumably broken by 2.3.0-1 which packaged ziomon and included
> a ${perl:Depends} on the main package as well - possibly because Lintian
> alerted about the missing dependency. That was technically correct, as
> it includes binaries that require modules from perl rather than
> perl-base. And it would presumably have worked if "perl:any" had instead
> been substituted as "perl".
>
> It's pretty telling how late this was discovered, sort of pointing out
> that Debian s390x has no users at all if that kind of bug slips into a
> stable release. Ubuntu forked the base tooling and thus was not
> affected. To be honest, that tells me that the port should be demoted
> and not be part of the next release. Especially given the lack of
> (motivated) porters.
The good news is that with Debian stable 10.6 that was released today
the installation actually works again and I was able to conduct a
successful one from within z/VM.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
Bug#970155: gobby: please remove the menu file
On 12.09.20 13:04, Pino Toscano wrote: > Package: gobby > Version: 0.6.0~20170204~e5c2d1-3 > Severity: wishlist > Tags: patch > > Hi, > > Debian deprecated the Debian menu 5 years ago [1]. > > gobby provides already a desktop file with icon, so the Debian menu > file is redundant (and theoretically by Policy it should not even be > allowed, as there is a desktop file). Patch attached for this. > > [1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html Feel free to just upload your NMU. Kind regards and thanks Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#969501: binNMUs of M-A:same packages use varying SOURCE_DATE_EPOCH
On 03.09.20 21:38, Helmut Grohne wrote: > Package: buildd.debian.org > > When binNMUing a package, the time of the build is used for creating the > changelog entry. This is an sbuild default due to #843773. That results > in SOURCE_DATE_EPOCH not being equal for those builds and some tools > embed that timestamp into packages for shared files. Doing so can result > in unpack errors, when the relevant binary packages are marked > Multi-Arch: same. An example package is libtie-hash-indexed-perl and it > happens to break due to binNMUs being performed on different dates. > > On the sbuild side, the idea is that you pass --binNMU-timestamp=... > Unfortunately, it's not so easy on the wanna-build side as you can > schedule a binNMU at any time. What makes matters worse is that each > binNMU is scheduled individually and locks tables individually in that > process (according to Aurelien Jarno). So while wanna-build could pass > that flag to sbuild, it's not easy to produce an equal value for all > binNMUs of a source package. Picking closer dates would have avoided the > issue with libtie-hash-indexed-perl. > > Does anyone else see more options for solving this? My personal opinion always has been to mimic what Ubuntu does with sourceful +build uploads. It would avoid us chasing down every single difference that binNMUs cause. The current system is mostly a result of the wish of doing per-arch binNMUs which is really not the primary purpose of the system anymore. But alas, changing this has not been politically viable in the past - because source uploads are treated so differently by the archive, builders are not allowed by the archive to upload them and because they'd culturally be treated as NMUs instead of updates for internal, technical reasons. I also hate the per-architecture DB structure of wanna-build and consider it a mistake. But then to do things sanely you'd need a middle service doing permission checking. Technically the Release team mostly uses "wb" as a wrapper and we could plumb through a timestamp - as long as all binNMUs are scheduled in one invocation, which should be mostly (but not always) true. In any case it feels like if we want this invariant to hold we also need archive-wide monitoring to ensure it. That said, I know Guillem held in the past that the invariant people rely on here is more by accident than being intentional - and that co-installable MA:same packages should not be supported ([1]). Kind regards Philipp Kern [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#132 signature.asc Description: OpenPGP digital signature
Bug#968998: debian-installer: grub and shim are missing from built-using
On 25.08.20 18:18, Julien Cristau wrote: > Package: debian-installer > Version: 20150324 > Severity: important > X-Debbugs-Cc: jcris...@debian.org > > d-i EFI images include a copy of grub (and shim, on architectures with > secure boot). Those should be listed in Built-Using so we don't end up > without the corresponding source in the archive. grub2 for sure as it's GPL-3, but is it actually required for shim, which is BSD? Kind regards Philipp Kern
Bug#960265: Up the priority of installation breakage
clone 960265 -1 reassign -1 debootstrap retitle -1 debootstrap: should handle multi-arch dependencies properly severity -1 important severity 960265 serious thanks This is also a bug in debootstrap in that it should strip ":any" from package dependencies when calculating the set of packages to install. It tries to fetch "perl:any" instead of "perl". See [1]. At the same time bug #960265 is actually of priority serious (breaks bootstrapping), rather than normal. Kind regards Philipp Kern [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960265#20 signature.asc Description: OpenPGP digital signature
Bug#968548: buster-pu: package s390-tools/2.3.0-2~deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: important
X-Debbugs-Cc: debian-s...@lists.debian.org
debootstrap fails to install Debian buster on s390x because of a
multi-arch "perl:any" dependency it fails to parse (bug #960265). This
update to s390-tools hardcodes the dependency on "perl" without that,
which should make the installation possible again. I already validated
that this fixed the issue on unstable and I could successfully install
it using debian-installer.
The fix is this one-liner. Debdiff attached. This should be fixed in the
package rather than debootstrap for now as debootstrap fixes are harder
to distribute.
> diff -Nru s390-tools-2.3.0/debian/control s390-tools-2.3.0/debian/control
> --- s390-tools-2.3.0/debian/control 2018-02-04 19:29:22.0 +0100
> +++ s390-tools-2.3.0/debian/control 2020-08-16 16:35:52.0 +0200
> @@ -9,7 +9,7 @@
>
> Package: s390-tools
> Architecture: s390x
> -Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, gawk
> +Depends: ${shlibs:Depends}, ${misc:Depends}, perl, gawk
> Recommends: sg3-utils
> Description: Set of fundamental utilities for Linux on S/390
> The package contains:
My assumption is that this is not fixable through -updates but requires
a point release to be properly fixed.
Kind regards and thanks
Philipp Kern
diff -Nru s390-tools-2.3.0/debian/changelog s390-tools-2.3.0/debian/changelog
--- s390-tools-2.3.0/debian/changelog 2018-02-04 19:29:22.0 +0100
+++ s390-tools-2.3.0/debian/changelog 2020-08-17 10:04:45.0 +0200
@@ -1,3 +1,17 @@
+s390-tools (2.3.0-2~deb10u1) buster; urgency=medium
+
+ * Upload debootstrap fix to Debian stable.
+
+ -- Philipp Kern Mon, 17 Aug 2020 10:04:45 +0200
+
+s390-tools (2.3.0-2) unstable; urgency=medium
+
+ * Hardcode perl dependency instead of using ${perl:Depends}.
+The latter introduces a multi-arch dependency (perl:any) that the
+ base installation environment cannot cope with.
+
+ -- Philipp Kern Sun, 16 Aug 2020 10:36:02 -0400
+
s390-tools (2.3.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru s390-tools-2.3.0/debian/control s390-tools-2.3.0/debian/control
--- s390-tools-2.3.0/debian/control 2018-02-04 19:29:22.0 +0100
+++ s390-tools-2.3.0/debian/control 2020-08-16 16:35:52.0 +0200
@@ -9,7 +9,7 @@
Package: s390-tools
Architecture: s390x
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, gawk
+Depends: ${shlibs:Depends}, ${misc:Depends}, perl, gawk
Recommends: sg3-utils
Description: Set of fundamental utilities for Linux on S/390
The package contains:
signature.asc
Description: OpenPGP digital signature
Bug#968507: O: icon-naming-utils -- script for maintaining backwards compatibility of Tango Project
Package: wnpp Severity: normal I intend to orphan the icon-naming-utils package. Last upstream release was 11 years ago. There is effectively no churn in this package. It is also a required build dependency for a bunch of icon themes: # Broken Build-Depends: extra-xdg-menus: icon-naming-utils gnome-icon-theme: icon-naming-utils (>= 0.8.7) human-icon-theme/non-free: icon-naming-utils (>= 0.8.1) mate-icon-theme: icon-naming-utils (>= 0.8.7) mate-themes: icon-naming-utils metatheme-gilouche: icon-naming-utils moblin-icon-theme: icon-naming-utils sugar-artwork: icon-naming-utils suru-icon-theme: icon-naming-utils tangerine-icon-theme/non-free: icon-naming-utils (>= 0.7.1) tango-icon-theme: icon-naming-utils (>= 0.8.90) The package description is: Tango is a project to create a new cross-desktop and cross-platform icon theme, using a standard style guide, and the new Icon Naming Specification. This package contains the perl script for maintaining backwards compatibility.
Bug#966324: O: tango-icon-theme -- Tango icon library
Package: wnpp Severity: normal I intend to orphan the tango-icon-theme package. There is effectively no churn in this package - but the last upstream release was also 11 years ago. The install base is still quite large (~28k), but votes are awfully low. It is also a reverse dependency of a bunch of packages: # Broken Depends: frescobaldi: frescobaldi metatheme-gilouche: gnome-theme-gilouche piuparts: piuparts-master piuparts-master-from-git-deps scolasync: scolasync superkb: superkb # Broken Build-Depends: code-saturne: tango-icon-theme The package description is: This package contains the icons made by the Tango project. . The project's aim is to create a cross-desktop and cross-platform icon theme following the Icon Naming Specification by the Freedesktop project. The icons follow a standard and consistent style guide to look coherent.
Bug#966318: O: pdf2svg -- converts PDF documents to SVG files (one per page)
Package: wnpp Severity: normal I intend to orphan the pdf2svg package. This is a very minimal wrapper around Poppler and Cairo, feeding one's output into the other's input to convert PDF into SVG files. I mostly did not have this need anymore for a long time now. It historically did not need a lot of up-keep, but of course input that Poppler only barely understands (yay PDF) will not transfer well into SVG. Popcon is ~950 installs, 90 votes. The package description is: pdf2svg is a tiny command-line utility using Cairo and Poppler to convert PDF documents into SVG files. Multi-page PDF can be split up to one SVG per page by passing a file naming specification.
Bug#966317: O: gcc-3.3 -- providing The GNU Standard C++ Library v3 (libstdc++5)
Package: wnpp Severity: normal I am hereby orphaning gcc-3.3, which today just builds libstdc++5. I no longer have binaries that rely on this ancient library. IBM TSM used to require this - but as far as I can see, there are newer binaries these days that use the "contemporary" C++ library. For old games it seems feasible to just copy the binary around if needed. I'd be more worried about other 32-bit libraries breaking at this point. I'd weakly suggest not to include this package in the next Debian release, but there might still be someone who cares. Popcon install count is still around 4517, but vote is only 2, with 4514 reports not containing sufficient information around usage. Description: The GNU Standard C++ Library v3 This package contains an additional runtime library for C++ programs built with the GNU compiler. . This package contains an old version of libstdc++ intended solely for compatibility with proprietary binaries that cannot be recompiled. Kind regards Philipp Kern
Bug#965540: gcc-3.3: Removal of obsolete debhelper compat 5 and 6 in bookworm
Hi, On 20.07.20 21:35, Niels Thykier wrote: > Source: gcc-3.3 > Version: 1:3.3.6ds1-31 > Severity: normal > Usertags: compat-5-6-removal > > The package gcc-3.3 uses debhelper with a compat level of 5 or 6, > which is deprecated and scheduled for removal[1]. Are you sure that 1:3.3.6ds1-31 is broken? That's the version I uploaded with the fix. Kind regards Philipp Kern
Bug#964221: googletest: meson support
Source: googletest Version: 1.10.0-3 googletest is weirdly special in that it is supposed to be compiled together with the project that is being tested, using the same flags. As such it ships with source files and not just a shared library that can be imported using pkg-config. Right now it supports cmake as-is. Meson is a (new?) build system that is gaining in popularity. Right now what a meson-using upstream project can do to manage its dependencies tightly is to use so-called "wraps" that patch meson.build build system definitions from the internet on top of an arbitrary upstream source that does not support meson yet. So for gtest there is [1], which ships a zip for 1.10.0 at [2] that contains three meson.build files and one LICENSE.build. Would it be possible for googletest in Debian to ship these meson.build files alongside the source in the library packages? That way packages could build-depend on libgtest-dev without requiring them to use CMake. Kind regards and thanks Philipp Kern [1] https://wrapdb.mesonbuild.com/gtest [2] https://wrapdb.mesonbuild.com/v1/projects/gtest/1.10.0/1/get_wrap
Bug#958108: Please build and install bindings for gi introspection
tag -1 + pending tag -1 - patch thanks On 18.04.20 16:25, Pietro Battiston wrote: > The libinfinity software includes the gi introspection code, but it is > currently disabled in the debian package. > > According to my tests, enabling it would only require replacing > > --enable-gtk-doc > > > with > > --enable-gtk-doc \ > --enable-introspection > > within debian/rules, and adding > > usr/lib/@DEB_HOST_MULTIARCH@/girepository-1.0/* > > after > > usr/lib/@DEB_HOST_MULTIARCH@/libinfinoted-plugin-manager-*.so.* > > within debian/libinfinity-0.7.0.install. The changes were more involved than that but I uploaded a fix to NEW. (It required the addition of a package.) Kind regards and thanks Philipp Kern
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 11.05.20 11:53, Winfried Münch wrote:
> package: s390-tools
>
> Version: current Installer from 04.05.2020 21:14
> http://ftp.halifax.rwth-aachen.de/debian/dists/buster/main/installer-s390x/current/images/generic/
>
>
> When I install debian I run in this Problem (from console 4):
>
> May 11 09:43:43 debootstrap: Errors were encountered while processing:
> May 11 09:43:43 debootstrap: s390-tools
> May 11 09:43:44 debootstrap: dpkg: dependency problems prevent
> configuration of s390-tools:
> May 11 09:43:44 debootstrap: s390-tools depends on perl:any.
> May 11 09:43:44 debootstrap:
> May 11 09:43:44 debootstrap: dpkg: error processing package s390-tools
> (--configure):
> May 11 09:43:44 debootstrap: dependency problems - leaving unconfigured
>
> Installation failed in step install base system.
perl:any is not part of the transitive closure that debootstrap
calculates. To me it looks like a bug in debootstrap in that it does not
find a deb to download because it does not drop the :any - either in
pkgdetails or before.
This was presumably broken by 2.3.0-1 which packaged ziomon and included
a ${perl:Depends} on the main package as well - possibly because Lintian
alerted about the missing dependency. That was technically correct, as
it includes binaries that require modules from perl rather than
perl-base. And it would presumably have worked if "perl:any" had instead
been substituted as "perl".
It's pretty telling how late this was discovered, sort of pointing out
that Debian s390x has no users at all if that kind of bug slips into a
stable release. Ubuntu forked the base tooling and thus was not
affected. To be honest, that tells me that the port should be demoted
and not be part of the next release. Especially given the lack of
(motivated) porters.
Furthermore it seems like the current debian-installer daily build does
not boot and ends up in disabled PSW before printing even a single line
of output.
I never managed to get any kind of continuous integration going myself
given how hard it is to integrate with existing Debian infrastructure to
test it properly - unless you are an admin there already. Even a qemu
setup would have spotted this particular bug. But without any users who
care I also don't think it is worth spending much time on this.
Kind regards and sorry
Philipp Kern
Bug#810865: parking infinoted.service
On 2020-06-03 19:39, Geert Stappers wrote: Parking this infinoted.service in this issue. [Unit] Description=infinoted server for Gobby collaborative text editor After=multi-user.target [Service] Type=simple ExecStart=/usr/bin/infinoted-0.7 ;At boot the service does not sart ;Adding --daemonize does not work either ;ExecStart=/usr/bin/infinoted-0.7 --daemonize [Install] WantedBy=multi-user.target To be continued Geert Stappers If you could figure out DynamicUser and storage for it, I think there could be an argument that we can push it. I'd still likely break some existing installs but that's how it is. Sadly libinfinity does not build right now, the author mostly abandoned it and I sunk many hours already into trying to figure out how to fix the test and couldn't. Kind regards Philipp Kern
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 20.05.20 12:42, Valentin Vidić wrote: > On Wed, May 20, 2020 at 11:19:53AM +0200, John Paul Adrian Glaubitz wrote: >> Ah, sorry. I was seeing the cached version of the thread, refreshing helped. >> >> In any case, the SPARC kernel maintainer (Dave Miller) had the same argument >> that it would potentially break existing setups but eventually I could >> convince him that the change was right. >> >> Not sure which distributions he has in mind. > > It is hard to tell, but it seems the current state is hardcoded > in different places: > > https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html > https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html > > I think it would be better to make debian-installer smarter about > this since we will probably run into the same problem again with > a different architecture/driver. qemu-system-s390x is probably the least representative here. I recall that the consoles for z/VM and LPAR were actually different. As alluded to by the thread LPAR uses SCLP while you get 3215 on z/VM. I'm all for making d-i smarter. But I think we should start by trying to back merge all the improvements Canonical made on Ubuntu instead of Debian as part of their s390x contract. Maybe trying ubuntu-installer and seeing if that works correctly would be a good start. But then I keep wondering how representative qemu is. Is VT220 SCLP even something you get on a real z machine? Not that we shouldn't fix qemu, of course. But Hercules might be closer to the real thing in this regard. Kind regards Philipp Kern
Bug#958130: hercules FTCBFS: make dependencies contain linker flags
Hey Helmut, On 27.04.20 06:12, Helmut Grohne wrote: > On Sun, Apr 26, 2020 at 10:41:20PM +0200, Philipp Kern wrote: >> Is there a way for me to test this patch? (I also take pointers.) There >> are more references to -lltdl in there and curiously rebuilding the >> package actually drops the shlibs reference from libltdl, so I'd have >> liked to make sure the problem is actually fixed. > > If you are using sbuild, you can simply add --host=$somearch to your > invocation. If you are using pbuilder, you can simply add --host-arch > $somearch to your invocation. There is no need for extra chroots or like > that. Just those extra options. After your upload, you can check > http://crossqa.debian.net/src/hercules to see the results of the > autobuilder. Beware that the service presently has a noticeable backlog, > so it may take a few days to build your package (unless you schedule it > yourself). Also be aware that since gcc-10 presently FTBFS on x86, cross > building on x86 in unstable tends to not work. At the time of this > writing, you can still cross build from amd64 to mips64el, because > mips64el didn't finish building gcc-10 yet. After that, a testing chroot > may be needed. The crossqa page tells you which hosts work with amd64 at > any given time. > > In case you have further questions, don't hesitate to ask. That's awesome. Thanks for your work on cross-building! Please make sure to air this a little more on Planet Debian or Developer News. :) Kind regards Philipp Kern
Bug#958130: hercules FTCBFS: make dependencies contain linker flags
Hi Helmut, On 18.04.20 18:24, Helmut Grohne wrote: > Source: hercules > Version: 3.13-1 > Tags: patch upstream > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > hercules fails to cross build from source, because an upstream > Makefile.am includes -lltdl in a Makefile dependency. This triggers > architecture-specific behaviour in make. It looks up the flag using the > built-in library search path (for the build architecture). However > libltdl is only installed for the host architecture, so the library > isn't found and make gives up. One shouldn't list such flags in > dependencies. Please consider applying the attached patch to make > hercules cross buildable. Is there a way for me to test this patch? (I also take pointers.) There are more references to -lltdl in there and curiously rebuilding the package actually drops the shlibs reference from libltdl, so I'd have liked to make sure the problem is actually fixed. Kind regards and thanks Philipp Kern
Bug#958108: Please build and install bindings for gi introspection
On 18.04.20 16:25, Pietro Battiston wrote: > Package: libinfinity-0.7-0 > Version: 0.7.1-1 > Severity: wishlist > Tags: patch > > The libinfinity software includes the gi introspection code, but it is > currently disabled in the debian package. > > According to my tests, enabling it would only require replacing > > --enable-gtk-doc > > > with > > --enable-gtk-doc \ > --enable-introspection > > within debian/rules, and adding > > usr/lib/@DEB_HOST_MULTIARCH@/girepository-1.0/* > > after > > usr/lib/@DEB_HOST_MULTIARCH@/libinfinoted-plugin-manager-*.so.* > > within debian/libinfinity-0.7.0.install. Did you actually manage to build it successfully? There's currently a FTBFS bug due to glib (#935614) that I was able to bisect on the upstream Github report but where I am at a loss on how to fix. Kind regards Philipp Kern
Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google
On 2020-04-08 19:43, Olek Wojnar wrote: Bazel has suddenly become more important because it is preventing us from getting packages working that would help with the COVID-19 pandemic. Due to the significance, I am copying the Debian Med team as well as key people from this bug's history in the hopes of getting something moving quickly. On Tue, 22 May 2018 14:55:19 -0600 Kyle Moffett wrote: I spent a while working on it off and on, but there is a decent amount of tweaking and other packaging work needed to get policy-compliant bazel packages. (E.G: There are quite a few binary JAR files shipped in the upstream tarball that don't necessarily match the versions in Debian). I just didn't have the spare time, especially now that I have a kid, to sink into one package. I can relate to the kid/time issues! ;) Have you had any time to work on it recently? Did you ever upload any of your work? In the meantime, I see that Bazel has an unofficial Ubuntu build [1]. Do you know anything about that? It seems like a good place for us to start if you aren't close to a product yourself. That's the build Google provides that is built with Bazel itself, using a ton of vendored libraries. (Because that's how Google operates internally.) Generally the pkg_deb output[1] is not really policy-compliant and more built from the ground up without any Debian tooling. So the /mere existence/ of that package (which was there from the beginning) does not help the quest of getting Bazel packaged for Debian, unfortunately. Kind regards Philipp Kern, obviously not speaking for Google [1] https://github.com/bazelbuild/bazel/blob/f828b4c77805ad0ea6afecef798aa69d68bec8d4/scripts/packages/debian/BUILD#L69
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/28/2020 1:33 PM, Thomas Goirand wrote: >> It'd need to be a script that the systemd maintainers feel reasonably >> confident will always run systemd's implementation when systemd is >> running, to avoid the mixed implementations issue. > > Not at all. Systemd maintainers have no say if someone wishes to > implement things in another way, the same way there's gawk and mawk, > implementing the same thing. If we don't allow such things, then really, > Debian is doomed. The interface in question here is "awk". So if the interface would be a hypothetical "update-sysusers", then this could be shared with alternatives. I completely understand the view of the systemd maintainers that "systemd-sysusers" as a binary should be provided by their package rather than an alternative. >> Strikes me as there is a possible solution, though: have opensysusers >> dpkg-divert it and put a shell script in its place that checks which >> init system is running, and exec's the right sysusers based on that. > > This is exactly what should be avoided. It's perfectly fine to try to > use opensysusers with systemd if one wants. In fact, that's exactly the > best way we could do to be able to test it. Also, dpkg-divert is really > ugly, and something you use as the last resort, when all other options > have been exhausted. If the problem here is that everything embeds a call to systemd-sysusers directly and you want to provide a different intermediate interface eventually then diverting it as a workaround in the meantime seems sound to me, no? So far I see you present a single option rather than trying to negotiate within the option space. Good escalations are not "Moreover, I don't see why /usr/bin/systemd-sysusers would be any different from let's say /usr/bin/awk." but trying to present the two opposing viewpoints and potential solutions to them. Kind regards Philipp Kern
Bug#949626: busybox-static: Please include less and ftpput in busybox-udeb
On 1/22/2020 10:56 PM, Witold Baryluk wrote: > it is really hard to debug issues and read long log files (like syslog), > especially in debian-installer failures. > > There is more, but it is really equivalent to cat. It doesn't actually do > paging. > > Please include functional less, just like in busybox-static with the same > build options. There is nano though. (I'd still second less. I think we can spare the space.) > ftpput to transfer files out would good option too. The age of FTP has long passed. Kind regards Philipp Kern
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On 1/21/2020 4:50 PM, Sam Hartman wrote: >>>>>> "Philipp" == Philipp Kern writes: > > Philipp> I'm told it was broken by the upgrade of Apache - apparently it > can no > Philipp> longer do per path client certificate authentication. There is a > Philipp> pending RT ticket from DSA to fix that but I don't think there is > Philipp> anything I can do at the moment - except turn on SSO for the > whole > Philipp> vhost. Maybe that could even be a workaround for now and we could > Philipp> check if someone is annoyed by that. :) > > TLS dropped the facilities necessary to do that. > Ultimately you'll need a vhost for stuff that requires client certs and > other vhosts that do not. > The user experience of having a site request client certs when you don't > have one to give is really bad in some browsers. > > Client certs really kind of are the unloved step child of web > authentication. Yeah, so Julien helpfully just created auth.buildd.debian.org (thanks for that!). I'm going to spend some time on that tomorrow. That being said, tracker, nm and contributors already moved to request client certificates on the main host. I find the UI problematic when you actually have a cert, as it will show a problem. In enterprise environments you can push a policy to not ask about which certificate to use but for privacy reasons it is still explicit in the normal case. And yes, the correct approach would be something like OAuth2. Or use client certificates with some sort of CLI. :/ Kind regards Philipp Kern
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On January 20, 2020 10:59:48 Drew Parsons wrote: Has the self-service wannabuild giveback script been disabled? It's now rejecting connections, e.g. https://buildd.debian.org/auth/giveback.cgi?pkg=ga=sid=armel generates Forbidden You don't have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication. Apache Server at buildd.debian.org Port 443 My SSO is otherwise working fine, e.g. triggering debci tests at https://ci.debian.net/user I'm told it was broken by the upgrade of Apache - apparently it can no longer do per path client certificate authentication. There is a pending RT ticket from DSA to fix that but I don't think there is anything I can do at the moment - except turn on SSO for the whole vhost. Maybe that could even be a workaround for now and we could check if someone is annoyed by that. :) Kind regards Philipp Kern
Bug#936509: fdsend: Python2 removal in sid/bullseye
reassign 936509 ftp.debian.org retitle 936509 RM: fdsend -- RoM; obsoleted by built-in functionality affects 936509 + src:fdsend severity 936509 important thanks On Fri, Aug 30, 2019 at 07:17:00AM +, Matthias Klose wrote: > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. While there is a somewhat high popcon count, all of this is due to ganeti. Python 3 provides all facilities required for sendfd support natively and documents them as such in [1] and [2]. The latter even contains a one-liner that's all that is required at this point. Ganeti has also been fixed upstream to make use of the native functionality: commit 493c901bd23c9a891a3426b0468a4db462058af3 Author: Apollon Oikonomopoulos Date: Thu Jun 20 10:26:58 2019 +0200 Implement SendFds fdsend does not support Python 3; luckily, Python 3's socket library exposes everything we need to re-implement it in pure Python, so add utils.SendFds which sends a bunch of fds, along with data, over a socket. Signed-off-by: Apollon Oikonomopoulos Thus this package should be removed in favor of the built-in methods rather than be ported to Python 3 (which has happened but will now not be uploaded here). Users should follow the documentation to migrate. Kind regards and thanks Philipp Kern [1] https://docs.python.org/3/library/socket.html#socket.socket.recvmsg [2] https://docs.python.org/3/library/socket.html#socket.socket.sendmsg
Bug#948038: ITP: gfsecret -- Tools to make secret sharing easier.
On 1/4/2020 10:32 PM, Thomas Perret wrote: > Le 03/01/2020 à 18:18, Philipp Kern a écrit : >> >> What's the advantage of this tool vs. the tools in libgfshare-bin and ? >> >> Kind regards and thanks >> Philipp Kern >> > > From what I understand (correct me if I'm wrong) the tools included in > libgfshare-bin are more a raw proof of concept of the underlying library > than a user friendly interface. > I wasn't aware of but from what I tested, it seems you can only > share a secret passphrase. > > Gfsecret allows you to split and combine files using what is called > share URIs defined in a configuration file at split time. You can then > use this configuration file to combine the minimum number of shares > detected by the software to rebuild the file. > > My main use (and the main purpose of this software) is to split your > master GPG key. Since a few release versions, there is even a facilating > tool to do exactly that. > > The share URIs can be put on different local or external volumes. > Gfsecret supports local filesystem, external volumes identified by > uuid/label/mtp. > > More information is available on Gfsecret website: > https://incenp.org/dvlpt/gfsecret.html > > My opinion is that Gfsecret can be a good addition to Debian. Do you > think I should keep on packaging it or is it too redundant with other > tools already available? It looks like it actually uses libgfshare in the background and provides some value over a naive binary (URIs[1]). So I guess that's ok. Make sure to elaborate on the unique features in the long description. :) Kind regards Philipp Kern [1] Somehow it'd have been nice if it wouldn't be the responsibility of every single binary to implement a scheme. Plan 9 and Hurd come to mind here, but alas.
Bug#948038: ITP: gfsecret -- Tools to make secret sharing easier.
On 1/3/2020 5:33 PM, Thomas Perret wrote: > Package: wnpp > Severity: wishlist > Owner: Thomas Perret > > * Package name: gfsecret > Version : 0.4.4 > Upstream Author : Damien Goutte-Gattat > * URL : https://git.incenp.org/damien/gfsecret > * License : GPL-3.0+ > Programming Lang: C > Description : Tools to make secret sharing easier. > > Gfsecret is a set of tools to facilitate secret sharing according to the > Adi Shamir’s secret sharing scheme. > > Two tools are provided: gfsec-split will split a file into several > shares, and gfsec-use will reconstruct the original file from some of > the shares. What's the advantage of this tool vs. the tools in libgfshare-bin and ? Kind regards and thanks Philipp Kern
Bug#937420: Remove pydhcplib from the distribution
retitle 937420 RM: pydhcplib -- removal triggered by the Python2 removal thanks Rationale: package is unmaintained, has very low popcon and no rdeps
Bug#935669: assaultcube-data (1.2.0.2.1-3) in enabled autobuilding
On 10/17/2019 1:53 AM, Carlos Donizete Froes wrote: > The assaultcube-data (1.2.0.2.1-3) package includes "XS-Autobuild: yes" in the > header portion of "debian/control"[1] and the disclaimer compliance with the > licenses contained in "debian/copyright"[2] where It's okay to create the > software automatically across multiple architectures and distribute it. > > [1] https://sources.debian.org/src/assaultcube-data/1.2.0.2.1-3/debian/control > > [2] > https://sources.debian.org/src/assaultcube-data/1.2.0.2.1-3/debian/copyright > > If so, could you approve this package or do I need to target something else? Within the TEXTURES part of the "Other" license there are a few that do not actually allow the textures to be shipped. Do we have a reasonable assumption that it is actually the "Other" license's cover text that applies to them? For instance I'm concerned about these (with no expectation of covering them exhaustively): > All files and images may be used without restrictions in your projects. > It is prohibited to offer those files as part of other texture packs or sell > or > distribute them in any other way without prior permission from arcitool. > These textures are copyright (c) Ted Southard http://www.digitalflux.com > They are free to use for non commercial use. Re-packaging and selling as part > of a texture collection is strictly prohibited. > Where can I not use these textures? > Any webpage, program, or texture cd that has them available without > my permission is not permitted. You can however use them in a design scheme > for your site. > You are not allowed to spread them without giving the creators name, to > include > them in texture collections without a written permission and you strictly may > not offer them as textures for sale in any way. etc Kind regards Philipp Kern
Bug#941026: netcfg_gateway_reachable wrongly rejects IPv6 link-local addresses
On 2019-09-23 18:00, Andrew Kanaber wrote: When doing static IP configuration, netcfg will reject a gateway address outside the host's network as defined by the netmask. This is wrong for IPv6 because the gateway can legitimately be a link-local address in fe80::/64 instead of the host's network range. Ubuntu have fixed this bug in their version, see LP#1382295 https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/1382295 The relevant function is netcfg_gateway_reachable in netcfg-common.c which simply checks gateway_address & netmask == host_address. It should also allow IPv6 addresses in the link local prefix fe80::/64. Less importantly, the error message it triggers could be a bit clearer, "The gateway address you entered is unreachable" sounds like it might be a network error when it's purely a user-input parsing rejection - if the code had actually tried the link-local address it would've worked. So how does it identify the interface to use in this case? Does the kernel have special support to pick the correct one if there is only one non-loopback interface? Generally link-local addresses do need to be qualified with the interface to be used. Kind regards Philipp Kern
Bug#682342: Latest patch successfully tested
On 8/16/2019 8:34 PM, Nishanth Aravamudan wrote:
> On 15.08.2019 [17:08:39 +0200], Cyril Brulebois wrote:
>> Nishanth Aravamudan (2019-08-14):
>>> We are able to reproduce this issue at will in Ubuntu Bionic's
>>> installer (not identical to Debian's, but code-wise in this path the
>>> same). While quite a while after the last update from Philipp, we
>>> tested the patch (netcfg_dhcp_domain.patch) after updating it to avoid
>>> a compilation issue, we found it did fix the problem for us.
>>>
>>> I am not sure if I can get Debian into our infrastructure to test
>>> explicitly, but I will work on it; at the same time, the code change
>>> seems straightforward.
>>
>> Thanks for your feedback. Care to share the fixed version? :)
>
> D'oh! I'm sorry, I thought I did. The patch we tested was:
>
> diff -Naur a/dhcp.c b/dhcp.c
> --- a/dhcp.c 2017-10-10 14:01:42.0 +
> +++ b/dhcp.c 2019-08-14 01:04:58.339325357 +
> @@ -590,7 +590,7 @@
> preseed_hostname_from_fqdn(client, buf);
> }
>
> -if (netcfg_get_hostname (client, "netcfg/get_hostname",
> hostname, 1)) {
> +if (netcfg_get_hostname (client, "netcfg/get_hostname",
> hostname, !have_domain)) {
> /*
> * Going back to POLL wouldn't make much sense.
> * However, it does make sense to go to the retry
> diff -Naur a/netcfg-common.c b/netcfg-common.c
> --- a/netcfg-common.c 2017-10-10 14:04:08.0 +
> +++ b/netcfg-common.c 2019-08-13 20:01:13.606510273 +
> @@ -1060,14 +1060,24 @@
> continue;
> }
>
> -if (accept_domain && (s = strchr(hostname, '.'))) {
> -di_info("Detected we have an FQDN; splitting and setting
> domain");
> -if (s[1] == '\0') { /* "somehostname." <- . should be ignored */
> +if ((s = strchr(hostname, '.'))) {
> +di_info("Detected an FQDN in hostname");
> +if (s[1] == '\0') {
> +/* "somehostname." <- . should be ignored */
> *s = '\0';
> -} else { /* assume we have a valid domain name given */
> -strncpy(domain, s + 1, MAXHOSTNAMELEN);
> -debconf_set(client, "netcfg/get_domain", domain);
> -have_domain = 1;
> +di_info("Stripped trailing dot from hostname");
> +} else {
> +/* assume that the domain is valid and copy it if
> + * accept_domain is set; just use the hostname if
> + * it is unset
> + */
> +if (accept_domain) {
> +strncpy(domain, s + 1, MAXHOSTNAMELEN);
> + di_info("Setting domain to %s", domain);
This needs indenting fix-up.
> +debconf_set(client, "netcfg/get_domain", domain);
> +have_domain = 1;
> +}
> +/* strip the domain from the hostname */
> *s = '\0';
> }
> }
>
>> I'm a little reluctant to blindly merging this patch (originally
>> labeled “untested”) without a go from its author. Philipp, should
>> I go ahead?
>
> Totally understood! I just wanted to make sure to revive this issue, as
> I'd also like to get it fixed in Ubuntu! Like I said, I will do my best
> to test and reproduce the fix with stock Debian.
I think this should be fine and we're early in the release cycle to find
potential problems if there are any.
Obviously it'd be great to have a test hardness with a DHCP server
sending various bits and us verifying that netcfg did the right thing.
But I'd surprised to find the time for that myself.
Kind regards and thanks
Philipp Kern
Bug#935365: buildd.debian.org: allowing self-service givebacks for Failed packages?
Hey Samuel, thanks for your feedback! On 8/22/2019 12:17 AM, Samuel Thibault wrote: > The self-service giveback is currently not available for packages in the > Failed state. I wonder if such a restriction is really useful. > > The thing is: apparently only I do this, but I always set hurd-i386 > package build failures in the Failed state with the appropriate failure > log lines, which are very helpful for sorting out the porting work > (see https://people.debian.org/~sthibault/graph-top.txt), and packages > maintainers have already told me they appreciate this, because I know > well the hurd-i386 failures and can thus easily point out the actual > problems to maintainers. > > But if people can not giveback due to this even in cases where it's a > transient failure or lagging dependency version, I'am afraid they will > now not send a mail for giving back on hurd-i386, thinking that I have > set the Failed state for a stronger reason than I actually meant. > > Put another way, this restriction on the Failed state leads me to think > I should rather stop setting packages in the Failed state, but then it's > detrimental to the porting work triaging. I think I came from the point where Failed is a manually set state that conveyed a meaning that we should not just erase, especially if we face opportunistic give-backs. At the same time that sort of depends on the frequency of the use of this feature. Traditionally `Failed' was supposed to be for failure states that were known to require another package upload. I guess what you are saying here is that you'd also set Failed if another package is at fault. I can relate to that, as expressive documented failure reasons are always better than just log tails - if you have the time to add those annotations. I also don't know if we have a good way of gauging consensus among porters here. I added buildd-maintainers@ to bcc. Please chime in if you have an opinion here. In the end it's easy to do. I'm sympathetic to just allow it and see if it actually causes trouble. AFAIK we also preserve the last failure reason in the database and do not immediately wipe it out (TBC). > Actually, even when the Fail state has been set manually on archs (e.g. > a know bug affecting all archs), it would still make sense to allow > maintainers to trigger the giveback when the bug is known to be fixed by > another package upload. I really do not want to check if someone is a package's maintainer if I can avoid it. But then again this is also something that could legitimately be done by the uploader of the other package anyway. Kind regards and thanks Philipp Kern
Bug#935217: buildd.debian.org: Giveback service complains about version mismatch
On 8/21/2019 4:26 AM, Guillem Jover wrote: > Just tried the new giveback service (which looks great, thanks!) for > attr on sh4, and I got this error message: > > URL:https://buildd.debian.org/auth/giveback.cgi?pkg=attr=sid=sh4 > ,--- > You are authenticated as guillem. ✓ > Working on package attr, suite sid and architecture sh4. ✓ > Package version 1 in state Build-Attempted, can be given back. ✓ > Error when executing wanna-build command:attr: version mismatch (1:2.4.48-4 > by buildd_sh4-sh4-gandi-02) > > ✗ > `--- The joy of parsing command output. I think I fixed it, by limiting the amount of splits on the period. Please retry. :) Kind regards and thanks for reporting Philipp Kern
Bug#931317: debian-installer: A feature to "secure erase" SSDs would be nice
On 2019-07-02 00:33, Ben Hutchings wrote: On Mon, 2019-07-01 at 22:09 +0200, Philip Hands wrote: I think it's probably rather hard to do safely, as IIRC one often needs to try hdparm, then in order to cause the drive not to be locked do something like suspend and resume the system, then set an admin password, and only then do the secure erase ... which then takes quite a while. I believe that modern drives (both HD and SSD) often have their own encryption layer, and secure erase is implemented by erasing the encryption key and (on an SSD) marking all blocks free in the flash translation layer. Unfortunately the locking bit is still true for many machines, so even if it is quick, it can be hard to get the drive into the state where the BIOS did not have an opportunity to block the user from triggering the erase operation. Kind regards Philipp Kern
Bug#930428: debootstrap should ensure matching _apt uid
On 2019-06-21 07:51, Trek wrote: On Thu, 20 Jun 2019 22:31:15 +0200 Ansgar Burchardt wrote: If _apt deserves a special solution, I would suggest assigning the _apt user a static uid instead of patching debootstrap. it seems to me the simplest approach, from a technical point of view, and it's the one I'm using since _apt user was introduced (making sure uids match) Adding deity@l.d.o. APT maintainers, please see the context in the bug. Do you think there should be logic in debootstrap to handle the case of trying to have the same UID within a chroot and outside, or could you apply for a static UID assignment? I would also prefer the latter, but I honestly don't know how messy the migration would be... (If so, I guess this bug should be reassigned to apt.) Kind regards and thanks Philipp Kern
Bug#930428: debootstrap should ensure matching _apt uid
On 2019-06-21 20:36, Ben Hutchings wrote: On Thu, 2019-06-20 at 20:33 +0200, Philipp Kern wrote: On 20/06/2019 09:50, Ansgar Burchardt wrote: > Ansgar Burchardt writes: > > (I don't maintain debootstrap.) > > > > I don't think it is a good idea to require debootstrap to know about > > such details. > > > > For limiting network access, I would recommend instead using network > > namespaces (to only provide limited network access for all processes) > > and/or user namespaces (if filtering for single UIDs is really needed). > > These do not require any uids to match between in- and outside. > > And sadly the submitter's address bounced my mail as the mail provider > the submitter uses cannot parse RFC-5321 mail addresses correctly. Well, you can use -submitter@ if you already know that your domain is problematic. Even re-reading the RFC I'm not sure why that's a bug. RFC 5321 references RFC 1035's definition of the label, which specifies that a needs to be first in the label. [...] No, RFC 1035 says that starting each label with a letter "will result in fewer problems with many applications". But RFC 1123 says a label *can* begin with a digit, and that there is no ambiguity with IP literals because TLDs start with a letter. Thanks for the clarification (although the "will result in fewer problems" is kind of what I meant then, I guess). It turns out what he did was not apparent in the mail I replied to and the problem was instead in the local part (using quotes and whitespace in it), which - while potentially valid - is also such an odd corner case that I think we'd be hard pressed to find anyone else who does that. And then again, if your whole goal is to test the boundaries of deliveries (and potentially to avoid spam while doing so), you are somewhat on your own in the modern Internet. :) Kind regards Philipp Kern
Bug#930428: debootstrap should ensure matching _apt uid
On 20/06/2019 09:50, Ansgar Burchardt wrote: Ansgar Burchardt writes: (I don't maintain debootstrap.) I don't think it is a good idea to require debootstrap to know about such details. For limiting network access, I would recommend instead using network namespaces (to only provide limited network access for all processes) and/or user namespaces (if filtering for single UIDs is really needed). These do not require any uids to match between in- and outside. And sadly the submitter's address bounced my mail as the mail provider the submitter uses cannot parse RFC-5321 mail addresses correctly. Well, you can use -submitter@ if you already know that your domain is problematic. Even re-reading the RFC I'm not sure why that's a bug. RFC 5321 references RFC 1035's definition of the label, which specifies that a needs to be first in the label. I didn't immediately find anything updating that part of RFC 1035. RFC 2181 also specifies that applications can impose additional restrictions on top of labels. I'm happy to file an internal bug report if there is actually supporting documentation rather than just trying out the boundaries of deliverability. (Where I mostly wish you good luck. It's not a fight I want to have, which is also why I mostly stopped using my @debian.org address.) Kind regards Philipp Kern
Bug#930428: debootstrap should ensure matching _apt uid
On 20/06/2019 20:22, Ansgar Burchardt wrote: Trek writes: Ansgar Burchardt wrote: For limiting network access, I would recommend instead using network namespaces (to only provide limited network access for all processes) and/or user namespaces (if filtering for single UIDs is really needed). These do not require any uids to match between in- and outside. filtering out the root user is a pretty common security practice and setting an iptables rule on uids is simple for system administrators So you don't run sshd (requires root with network access)? That seems rather uncommon to me. There is a difference between running an sshd that only listens and allowing outbound connections as root, though. But that's a tangent. using namespaces, how can you block any user but not the _apt user if it is not already created? You look up which uid the _apt user inside the chroot has and use that. Yeah, but that scales poorly if you have a centralized firewall policy. It means that you need to maintain dynamic rules. I know it's possible and you can dedicate a chain to it. At the same time I think this problem is actually common enough that it deserves a solution. P.S.: the patch seems ok to me, I don't like hard-conding the _apt user line in /etc/passwd, as apt postinst uses adduser, but it's not clear to me when adduser is installed during debootstrap You cannot use `adduser` as debootstrap might install binaries you cannot execute (in the first stage). But the effects of the patch are different from calling adduser, for example the _apt user it creates has no entry in /etc/shadow. Such inconsistencies are not good. Yeah, that's certainly not desirable. But there's also a limited amount of places (like /etc/shadow) that need to be touched in addition. Kind regards Philipp Kern
Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]
On 2019-06-15 11:04, Paul Gevers wrote: On 14-06-2019 12:50, Aron Xu wrote: I have tested the package in a virtual machine on amd64 for linux/4.19.37-3 (buster) and a locally built updated linux kernel that breaks zfs-linux/0.7.12-2. The dkms package builds fine with both of the versions and zpool create/export/import works fine. Therefore, please unblock the t-p-u update for buster, thanks. I am probably asking a very stupid question, but ... The changes in the patch are in the source code. Do these dkms package work is such a way that the binaries are compiled every time that a kernel gets updated? I.e. a change in the source that checks for the kernel version actually results in a binary that works for that source? The whole point of dkms is to make sure that kernel modules available as source are made available to all installed kernels. So as long as the ABI version of the kernel changes (in Ubuntu with every upload, for us much more rarely) the module is recompiled. The corollary here is that it is not recompiled if the ABI version did not change because the module is assumed to still be compatible. (Our kernel maintainers also regularly ignore certain ABI changes they do not consider to actually be part of the ABI they support.) Kind regards Philipp Kern
Bug#930557: ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps
Hi Socrates. On 2019-06-15 15:11, Socrates Tzagiousis wrote: [...] i3-gaps is a fork of i3wm, a tiling window manager for X11. It is kept up to date with upstream, adding a few additional features such as gaps between windows *** Why should it be submitted and differences to the original (vanilla i3): *** i3-gaps is a popular fork of the most widely used tiling wm (vanilla i3), and is used exclusively by many people. It essentially contains a superset of functionalities to vanilla i3, and its gaps and smart border features as well as added i3bar RGBA transparency make it not only more pleasing to use, but easier to distinguish individual window frames without having to resort to colourful window frames and title bars as in the original. It is included on the main repositories of most major distributions right now, and for good reason. Why weren't the changes accepted upstream? Is this really a sustainable fork that has sufficient interest? Kind regards and thanks Philipp Kern
Bug#900918: debian-installer: Please make the generated images reproducible
On 1/22/2019 7:08 AM, Cyril Brulebois wrote: >> Alternatively, we could make pigz a strict build requirement but >> that sounds a little antisocial. > Right. In what way do you consider this antisocial and what's speaking against doing that? If it's about CPU time, then maybe it should obey the parallelization setting of the build process. But then it's already a build process and if you want that to not be detrimental to your desktop performance, you nice it. Apart from that thing I really struggle to find something "antisocial" in that build-dependency. Kind regards and thanks Philipp Kern
Bug#918607: ITP: kthresher -- Purge Unused Kernels
Hi, Am 07.01.2019 um 19:30 schrieb Darshaka Pathirana: > * Package name: kthresher > Version : 1.3.1 > Upstream Author : Rackspace US, Inc. > * URL : https://github.com/rackerlabs/kthresher > * License : Apache > Programming Lang: Python > Description : Purge Unused Kernels > > Tool to remove unused kernels that were installed automatically > This tool removes those kernel packages marked as candidate for autoremoval. > Those packages are generally installed via Unattended upgrade or > meta-packages. By default the latest kernel and manual installations are > marked to Never Auto Remove. it looks like this doesn't support Python 3 yet and I suspect that new packages should. I'd suggest that instead of distutils' LooseVersion, which was never meant for that, you use apt_pkg.version_compare. To be fair it's not quite a Debian revision to parse but it's close enough that the tokenization from our algorithm should work fine to sort kernel versions. Kind regards Philipp Kern
Bug#916036: Install fwupd on a default installation
Hi Mario, first of all thanks for your pointers! On 27/12/2018 20:28, mario.limoncie...@dell.com wrote: Just the fact that the update claims that the hardware only accepts signed updates or something else? :) At a minimum a claim. I will note - although slightly off-topic to the discussion at hand - that it would be useful to people to be able to run their own repository of updates and control the rollouts (and staging percentages) themselves. I'm not actually suggesting that Debian would need to run their own, but it'd be a useful service to the users who don't want to send telemetry to the Linux Foundation - and furthermore have a significant deployment where it's worth canarying the updates. Entirely doable. LVFS can be set up locally with the firmware that is interesting uploaded to that "instance". This will mean setting up a GPG key pair and signing the firmware with that instance as well. On fwupd clients a "remote" needs to be registered for that instance with the public key and instance location. So I suppose mirroring would entail fetching the firmware.xml.gz from LVFS' CDN and then downloading and rewriting the release locations - plus dealing with signing the metadata. That seems fairly straightforward. If there would be a way to check the provenance of an updater package (i.e. not just rely on arbitrary vendor authentication on the backend), that'd still be nice. (Plus percentage-based rollouts, but that's just yet another feature request. :) FYI: Telemetry related to the update is entirely optional and "opt-in" after you've performed an update. Thanks, I found a note on [1] and if it's indeed per remote, it should be fairly easy to manage. Fair enough. Do you have a pointer for examples of such updates? Unfortunately I updated my own Dell dock recently from Windows, so I can't easily check. Mostly I'm interested if it's a proprietary binary run on the host. That's its own can of worms. (Which technically is true for the EFI update too, but it's staged from outside of Linux on boot-up.) Executing proprietary binaries distributed in the CAB file is against fwupd philosophy and prohibited. All code for the plugin that executes in Linux and is distributed with fwupd must be open source. fwupd only pulls "payloads" from the CAB files. Regarding the examples I called out: You can review the fwupd tree in the plugins/ directory to see the * thunderbolt/ plugin which uses the kernel Thunderbolt interface * dell-dock/ plugin which uses kernel USB interfaces * dell/ plugin which uses a EFI binary for TPM and dock updates * ebitdo/ plugin which uses kernel USB interfaces * rts54hid/ rts54hub/ plugins which use kernel USB interfaces There are many more, you can look more closely at your leisure. The matching binaries that are on LVFS. Here's some examples: Thunderbolt: https://fwupd.org/lvfs/device/4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a MST: https://fwupd.org/lvfs/device/be025b25-ca5c-546c-97c6-ee2160ba489d 8bitdo: https://fwupd.org/lvfs/device/8baed357-638e-5b54-b582-0476bf7d6348 TPM: https://fwupd.org/lvfs/device/e58a5f6d-ba78-5f0f-a35f-612f97ca8c9a I cannot tell you how happy this makes me. This is awesome. Thank you (and everyone else who contributed to this effort) for doing the right thing! And obviously kudos to Dell for staffing this. The plugin library seems to be on [2] and there's a sizable set of them. Even an AMT updater. :o Kind regards and thanks Philipp Kern [1] https://blogs.gnome.org/hughsie/2018/01/10/phoning-home-after-updating-firmware/ [2] https://github.com/hughsie/fwupd/tree/master/plugins
Bug#916036: Install fwupd on a default installation
Hey Mario, On 2018-12-27 03:52, mario.limoncie...@dell.com wrote: Something I think worth mentioning is that LVFS is being transitioned to being run and managed by the Linux Foundation. yeah, that's great news. Interestingly enough the vendor signs a blob (CAB file) and LVFS throws it away and re-signs the blob with its own key. But then again I think the base assumption is that the contained firmware images are themselves signed as well and the BIOS does a check before ingesting them. Speaking on behalf of one of the biggest distributors of firmware on LVFS (Dell) I can say that all of the firmware images are signed by Dell PKI infrastructure and will not flash on the system if modified. LVFS is currently in the process of plumbing this information through to the U/I as well. Just the fact that the update claims that the hardware only accepts signed updates or something else? :) Obviously you end up with the usual concerns like the repository being able to hold back updates from certain clients. The website's code is supposedly available on https://github.com/hughsie/lvfs-website/ though and I suppose a transparency effort could solve that particular problem, too. LVFS is able to prevent distributing updates in two situations: 1) when there are known bad SW combinations (say vendor knew bug existed in fwupd 1.0.x but was fixed in 1.1.x - set minimum version for the update to be 1.1.x). or need to update device XYZ before device ABC. 2) rate limiting of updates To stage rollouts and monitor optional feedback in the event of a problem. I will note - although slightly off-topic to the discussion at hand - that it would be useful to people to be able to run their own repository of updates and control the rollouts (and staging percentages) themselves. I'm not actually suggesting that Debian would need to run their own, but it'd be a useful service to the users who don't want to send telemetry to the Linux Foundation - and furthermore have a significant deployment where it's worth canarying the updates. Oh yes. Not just that, also finding the right image to apply and then figuring out how the hell to apply it is a solved problem with EFI-based fwupdate. Please keep in mind it's much much more than EFI updates now too. There are updates that can apply "in Debian" without a reboot for things like Thunderbolt controllers, docks, MST hubs, and various USB devices. Fair enough. Do you have a pointer for examples of such updates? Unfortunately I updated my own Dell dock recently from Windows, so I can't easily check. Mostly I'm interested if it's a proprietary binary run on the host. That's its own can of worms. (Which technically is true for the EFI update too, but it's staged from outside of Linux on boot-up.) Kind regards and thanks Philipp Kern
Bug#916036: Install fwupd on a default installation
On 26/12/2018 22:32, Steve McIntyre wrote: On Wed, Dec 26, 2018 at 10:27:35PM +0100, Cyril Brulebois wrote: Steve McIntyre (2018-12-26): Philipp Kern (2018-12-26): I'm not sure, though, if there is some philosophical objection here in that fwupd downloads non-free blobs and/or that Debian does not actually ship the blobs themselves. FWIW both parts seem unacceptable to me, esp. in a default installation. They're not all necessarily non-free, but it's a useful service for people to make safe firmware updates easy. How do we know those blobs are safe, and that they won't change all of a sudden if they aren't hosted on Debian infrastructure? We *don't* directly, but they blobs are signed and placed online by the vendors. LVFS (the online backend) is a good Free Software-friendly service. Interestingly enough the vendor signs a blob (CAB file) and LVFS throws it away and re-signs the blob with its own key. But then again I think the base assumption is that the contained firmware images are themselves signed as well and the BIOS does a check before ingesting them. Obviously you end up with the usual concerns like the repository being able to hold back updates from certain clients. The website's code is supposedly available on https://github.com/hughsie/lvfs-website/ though and I suppose a transparency effort could solve that particular problem, too. This is a major step forwards from the old Windows-only ot "boot a DOS floppy" style of firmware updates. Oh yes. Not just that, also finding the right image to apply and then figuring out how the hell to apply it is a solved problem with EFI-based fwupdate. Kind regards Philipp Kern
Bug#916036: Install fwupd on a default installation
severity 916036 normal thanks Hi, I'd have another - and I hope stronger - argument to upgrade the dependency from suggests to recommends: gnome-software is actually displaying an error when fwupd is not present on the bus (see attached screenshot). But yes, I also second that we really should install this by default. I'm not sure if this could (or should) live in discover and how important the UI bits present in gnome-software are for this. But BIOS update management is becoming more important and now that large vendors actually publish their updates in LVFS, we should make these available to our users by default as well. I'm not sure, though, if there is some philosophical objection here in that fwupd downloads non-free blobs and/or that Debian does not actually ship the blobs themselves. Kind regards and thanks Philipp Kern
Bug#916468: Conflict over /usr/bin/dune
Am 18.12.2018 um 18:48 schrieb Ian Jackson: > But overall I think this, plus the history of the ocaml program's > name, does demonstrate that the ocaml program's claim to the overall > software name `dune', and the command name `dune' is incredibly weak. > > I just checked and `odune' seems to be available. For a build tool a > reasonably short name is justified. The `o' prefix is often used with > ocaml and though there is of course a risk of clashes with both > individual programs and with some suites like the old OpenStep stuff, > it seems that `/usr/bin/odune', odune(1) et al, are not taken. But then again it's a build tool that actually needs to be called its name on the console (just like the node mess). whitedune is a GUI program that could have any name as long as it's obvious from the desktop metadata and in fact its webpage disappeared and it hasn't seen a new upstream version since 2011. And the C++ library doesn't seem to have a CLI name claim at all. I suppose it's mostly the point that we package all free software on the planet that we become an arbiter of names. But we should try not to be that if we can avoid it. Kind regards Philipp Kern
Bug#913740: fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects
Am 21.11.2018 um 15:47 schrieb Mauricio Oliveira: >> [...] I will note that it's also possible to copy additional >> root certificates into the initrd pre-install. (At least it used to work >> before HTTPS was generally available.) > It looks like this requires rebuilding the initrd, which is some extra work > (and unfortunately it does not allow using the already > distributed/official files out there), [...] Linux support specifying multiple files to be loaded as an initrd[1]. In that case the content is merged and you can keep reusing the distributed files, just adding your root certificates on top. Yes, it requires extra work. So does preseeding. Now maybe the argument is that there could be mirrors outside of your control that redirect you to HTTPS and the root of trust is the GPG key material embedded into the initrd. That's a fair point but I will note that you did not actually list a use case, you just reported what didn't work. I guess I don't really object to your patch and am mostly questioning the existence of the option in this day and age, which then means people are encouraged to enable that rather than setup their infrastructure correctly. But there might still be value in having that option available with some signage on how to do it right. Kind regards Philipp Kern [1] In EFI mode Linux is the one requesting the files. Otherwise the boot loader can provide them, which works fine at least with grub and iPXE.
Bug#913740: fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects
On 2018-11-14 15:48, Mauricio Oliveira wrote: In fetch-url the --no-check-certificate option is conditioned to HTTPS. In case of HTTP to HTTPS redirect, that option is not enabled, and may cause fetch-url to fail if the certificate cannot be verified. Since that option/functionality must be explicitly requested with the debian-installer/allow_unauthenticated_ssl preseed option (i.e., user is aware of SSL/HTTPS context and agrees w/ non-verified certificates) we can just check for this in the HTTP protocol too, and assume HTTPS may potentially be used, as the user specified this option. An alternative/obvious solution in the _user_ side is to specify HTTPS URLs upfront, but there are cases when an user does not know for sure whether the server uses/supports that, or the server might change its behavior and start HTTP to HTTPS redirect after URLs have spread over (e.g., scripts and infrastructure) - thus a fix in the installer side is a simpler and more complete approach. Why do we need to build out this insecure option more rather than the target having supported SSL certificates (now that Let's Encrypt and friends exist)? I will note that it's also possible to copy additional root certificates into the initrd pre-install. (At least it used to work before HTTPS was generally available.) Kind regards and thanks Philipp Kern
Bug#913656: buildd.debian.org: dpkg ends up with error 2 due to miss path for /etc/profile
On 2018-11-13 17:24, edneyhelene wrote: Package: buildd.debian.org Severity: normal Tags: patch Dear Maintainer, Debian buster have a strange problem at the momment! DPKG cant find ldconfig path and it gives error 2! The solution is to edit /etc/profile Bugged version : if [ "`id -u`" -eq 0 ]; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" else PATH="/usr/local/bin:/usr/bin:/bin:/usr/games" fi ___ Solution: /Sbin is missing after games and needs an patch for solution. Temporary fix is to edit like this: if [ "`id -u`" -eq 0 ]; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" else PATH="/usr/local/bin:/usr/bin:/bin:/usr/games/sbin" fi and then source /etc/profile If someone could please make this permanent fix for the system on an next update would be great! Maybe you should make sure that your environment is correct when escalating your privileges to root, e.g. using "sudo -i". Anyway you reported this against a wrong component and this is in fact a user error. I suggest reaching out to debian-u...@lists.debian.org for help. Kind regards Philipp Kern
Bug#910858: tpm2-tss: FTBFS on big endian architectures: test failures
tag 910858 + patch thanks On 2018-10-21 20:40, Philipp Kern wrote: forwarded 910858 https://github.com/tpm2-software/tpm2-tss/issues/1171 thanks On 12.10.2018 14:48, Emilio Pozuelo Monfort wrote: Source: tpm2-tss Version: 2.1.0-1 Severity: serious Tags: ftbfs Hi, Your package failed to build on big endian architectures: [ RUN ] tpm2b_unmarshal_success [ ERROR ] --- 0xefbeadde != 0xdeadbeef [ LINE ] --- test/unit/TPM2B-marshal.c:213: error: Failure! [ FAILED ] tpm2b_unmarshal_success [ RUN ] tpm2b_unmarshal_success_offset [ ERROR ] --- 0xefbeadde != 0xdeadbeef [ LINE ] --- test/unit/TPM2B-marshal.c:254: error: Failure! [ FAILED ] tpm2b_unmarshal_success_offset Full logs at https://buildd.debian.org/status/package.php?p=tpm2-tss Forwarded upstream to https://github.com/tpm2-software/tpm2-tss/issues/1171 https://github.com/tstruk/tpm2-tss/commit/d8d9b90f4f29313f6807c63e208b1a140f371c9c fixes this issue and I confirmed that the test suite now passes on s390x with that patch applied. Kind regards and thanks Philipp Kern
Bug#910858: tpm2-tss: FTBFS on big endian architectures: test failures
forwarded 910858 https://github.com/tpm2-software/tpm2-tss/issues/1171 thanks On 12.10.2018 14:48, Emilio Pozuelo Monfort wrote: > Source: tpm2-tss > Version: 2.1.0-1 > Severity: serious > Tags: ftbfs > > Hi, > > Your package failed to build on big endian architectures: > > [ RUN ] tpm2b_unmarshal_success > [ ERROR ] --- 0xefbeadde != 0xdeadbeef > [ LINE ] --- test/unit/TPM2B-marshal.c:213: error: Failure! > [ FAILED ] tpm2b_unmarshal_success > [ RUN ] tpm2b_unmarshal_success_offset > [ ERROR ] --- 0xefbeadde != 0xdeadbeef > [ LINE ] --- test/unit/TPM2B-marshal.c:254: error: Failure! > [ FAILED ] tpm2b_unmarshal_success_offset > > Full logs at > > https://buildd.debian.org/status/package.php?p=tpm2-tss Forwarded upstream to https://github.com/tpm2-software/tpm2-tss/issues/1171 Kind regards Philipp Kern
Bug#910865: prometheus-node-exporter: Files in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ should not be compressed
On 12.10.2018 20:01, Martín Ferrari wrote: > On 12/10/18 16:47, Philipp Kern wrote: > >> I'd be great if we had a better story for the scripts in >> /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ >> but right now one of them (and only one) is even gziped and hence not >> directly executable (despite no configuration being needed) and that's >> smartmon.sh.gz. Could you exclude those files from being compressed? > > I agree it would be good if these are not compressed.. But as I > understand the policy, they must be compressed if they are documentation > or examples. > > An alternative would be to ship them in > /usr/share/promenteus-node-exporter, but I am not sure that is > appropriate.. Maybe you can advise? > >> Bonus points if there were systemd services one could turn on to run >> them periodically. :) > > True. But right now I don't have the bandwidth do write those.. I would > be glad to add them if you write them :) https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1 Please test and let me know if that works / doesn't work for you. And yes, maybe that should have been contributed upstream instead, but a distro can be more opinionated. Kind regards and thanks Philipp Kern
Bug#910865: prometheus-node-exporter: Files in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ should not be compressed
Package: prometheus-node-exporter Version: 0.15.2+ds-1 I'd be great if we had a better story for the scripts in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ but right now one of them (and only one) is even gziped and hence not directly executable (despite no configuration being needed) and that's smartmon.sh.gz. Could you exclude those files from being compressed? Bonus points if there were systemd services one could turn on to run them periodically. :) Kind regards and thanks Philipp Kern
Bug#904384: tpm2-tools: new upstream version
Hi, I echo that it'd be strongly desirable to have a new tpm2-tools in Debian. The current version does not even talk to the TPM2 device by default, but instead requires explicit options to do so. Instead it assumes that you are using the tools against a software emulator. To update tpm2-tools a new tpm2-tss is needed according to the matrix on https://github.com/tpm2-software/tpm2-tools/blob/master/INSTALL.md. I'm not sure yet if tpm2-abrmd would be required to be packaged as well, given that we should have the in-kernel resource manager available now. If someone happens to need a sponsor for any of this, please let me know. Kind regards and thanks Philipp Kern
Bug#910560: [choose-mirror] fails to build when parallel build is activated
On 2018-10-08 12:42, John Paul Adrian Glaubitz wrote: On 10/8/18 12:38 PM, Holger Wansing wrote: Ok, so we have no package problem at all? Well, it builds fine on the buildds and it also does not show build issues on reproducible-builds.org: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/choose-mirror.html Should that bug be reassigned to jenkins.debian.org then, to make jenkins happy on that topic, too? jenkins seems to not having parallel builds activated? Should probably use similar settings as the buildds, to give comparable results? Controversial opinion: It should use sbuild instead of pbuilder. sbuild is more actively maintained and more reliable in my experience. sbuild is also what the buildds are using. sbuild doesn't solve this particular problem either. You need to pass in DEB_BUILD_OPTIONS=parallel=n rather than setting --jobs. The latter is mapped to -j, which breaks (because it's put into MAKEFLAGS) and the former maps to -J. Julien is right in that there is a bug here that's worth fixing but the default build environment which is incredibly hard to discover does not expose them. Kind regards Philipp Kern
Bug#910560: [choose-mirror] fails to build when parallel build is activated
On 2018-10-08 09:08, John Paul Adrian Glaubitz wrote: On 10/8/18 7:51 AM, Holger Wansing wrote: Since version 2.92, choose-mirror fails to build with "dpkg-buildpackage -j", the debian/iso_3166.tab file seems to be removed by error: (can also be seen at jenkins: https://jenkins.debian.net/view/d-i_packages/job/d-i_build_choose-mirror/ where I found it initially) It builds fine here on my machine using sbuild and also fine on the buildds which are building with sbuild and "parallel=N" with N >= 2 [1]. You are building in an unclean build environment unless you are building with something like sbuild and pbuilder, so your build results can have unexpected results. Please create a local sbuild setup and try again. Adrian [1] https://buildd.debian.org/status/package.php?p=choose-mirror=unstable dpkg-buildpackage -j is like the worst option to ever have been introduced and not removed. Try -J instead. :( Kind regards Philipp Kern
Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash
On 24.09.2018 22:18, Simon McVittie wrote: > We can't upgrade gjs to a version that uses mozjs60 until either this is > fixed somehow, or gjs and its dependencies (notably GNOME Shell) are > removed from s390x. The architecture-specific removal seems a more likely > short term solution; if this is done I'll downgrade this bug to important. Running the revdep check for gjs (there are currently none on mozjs60): > % dak rm -n -a s390x -R gjs > W: -a/--architecture implies -p/--partial. > Will remove the following packages from unstable: > >gjs | 1.50.2-1 | source >gjs | 1.52.3-2 | source, s390x > gjs-tests | 1.52.3-2 | s390x > libgjs-dev | 1.52.3-2 | s390x > libgjs0g | 1.52.3-2 | s390x > > Maintainer: Debian GNOME Maintainers > > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Depends: > gnome-characters: gnome-characters > gnome-documents: gnome-documents > gnome-maps: gnome-maps > gnome-shell: gnome-shell > gnome-sound-recorder: gnome-sound-recorder > gnome-sushi: gnome-sushi > gnome-weather: gnome-weather > ostree: ostree-tests > polari: polari > > # Broken Build-Depends: > gnome-characters: gjs (>= 1.49) > libgjs-dev (>= 1.49) > gnome-documents: gjs (>= 1.48.0) > libgjs-dev (>= 1.48) > gnome-maps: gjs (>= 1.50.0) > libgjs-dev (>= 1.44.0) > gnome-shell: libgjs-dev (>= 1.50.2-3~) > gnome-sound-recorder: gjs > gnome-sushi: libgjs-dev (>= 1.40) > gnome-weather: gjs (>= 1.49.4) >libgjs-dev (>= 1.39.91) > gpaste: libgjs-dev (>= 1.48.0) > libguestfs: gjs > libsecret: gjs > polari: libgjs-dev (>= 1.49.2) > seed-webkit2: libgjs-dev > > Dependency problem found. The main packages that are regrettable in this context are libguestfs and maybe also ostree. Would the gjs dependency be avoidable there? Kind regards Philipp Kern
Bug#810865: infinoted NMU to add init script and systemd service file
On 2018-09-21 14:58, Jonas Meurer wrote:
thanks for maintaining infinoted.
Would you mind if I uploaded an NMU of infinoted just with the patch
from this bugreport applied? I verified that the patch works. It's
somewhat annoying to not have init system integration of infinoted.
I'll go on with an NMU (to delayed-7) if I don't hear back from you.
I'm pretty reluctant to maintain an init script at all and that's the
primary reason why I haven't merged one - as soon as it's legit to just
have a systemd service, I'm very happy to add one to the packaging. I
also think service files should've been submitted upstream and work
consistently across platforms, which this one won't (due to the
Debian-specific /etc/default setup, also infinoted.service references an
${OPTIONS} that isn't actually set?). It also uses /etc/infinoted for
variable data (directory owned by the service user to store the key
material there) but doesn't even put the config file into that directory
- instead it lives in the non-discoverable /etc/xdg directory. I suppose
given that it's managed by ucf it's not even a conffile (which is good,
but again not discoverable).
I feel you could feel free to take over the package and if there's
ongoing maintenance/migration work commit to that? Rather than doing an
NMU for a wishlist bug? That'd be fine with me.
Kind regards and thanks
Philipp Kern
