Bug#1011716: libbluray: continue to FTBFS and VLC crash in stable
On Wed, Sep 21, 2022 at 10:21 AM Sebastian Ramacher wrote: > Yes, that's all correct. But as you can see from the version graph at > the top of the bug report at https://bugs.debian.org/1011716, the > version in stable is not marked as fixed. There is no need to reopen > this bug report because it is still open in stable. Each day is an opportunity to learn something new. :-) Looking forward to seeing the fix in the stable. Cheers.
Bug#1011716: libbluray: continue to FTBFS and VLC crash in stable
Hi. I am not an expert on Debian policy, so the following may be incorrect, but this was my reasoning for re-opening the bug: On Wed, Sep 21, 2022 at 2:21 AM Sebastian Ramacher wrote: > Please don't reopen it. We have version tracking to track this kind of > thinks. For the bullseye version, the bug was still open. Reclosing. As far as I can see, this issue is fixed in bookworm because 1:1.3.2-1 has an upstream fix, there is no fix at all to this issue in stable 1:1.2.1-4+deb11u1. Aren't FTBFS, and other critical software bugs that prevent runtime use of the library entirely, considered a serious Debian policy violation that should be fixed with an upload to stable-proposed-updates? Specifically, I am suggesting a new package 1:1.2.1-4+deb11u2 for inclusion in the next bullseye point release. This keeps the existing upstream version and packaging used for bullseye, with just one additional patch that fixes the FTBFS and runtime issue. >From experimentation the FTBFS and the runtime crash occur with Java 11 (i.e. stable's default-jdk) and Java 17. But not under Java 8. So it may be difficult to observe the FTFBS if one builds the package in a non-isolated environment using Java 8. Thanks, Christian
Bug#1011716: libbluray: continue to FTBFS and VLC crash in stable
reopen 1011716 tags 1011716 bullseye patch thanks Re-opening because I still see FTBFS on Bullseye 11.5 (stable), and this library causes a crash in VLC when certain Blu-rays are opened. I think an upload to stable-updates is necessary. Backporting the following patch from the packaging repository's master branch onto the current source package in bullseye seemed to fix both issues. https://salsa.debian.org/multimedia-team/libbluray/-/blob/8c62a5c355ab7b68eacaced9ae245a88059924db/debian/patches/0002-Fix-build-failure-after-Oracle-Java-CPU-for-April-20.patch Thanks.
Bug#999888: RFP: websocat -- A command line client for WebSockets
Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net * Package name: websocat Version : 1.9.0 Upstream Author : Vitaly "_Vi" Shukela * URL : https://github.com/vi/websocat * License : MIT Programming Lang: Rust Description : A command line client for WebSockets A command line client for WebSockets, like netcat or curl, for ws:// URLs. Has advanced socat-like functionality.
Bug#960650: InspIRCd Security Advisories 2019-02 and 2020-01
I have prepared a draft 2.0.27-1+deb10u1 release for buster-security and uploaded it to mentors: https://mentors.debian.net/debian/pool/main/i/inspircd/inspircd_2.0.27-1+deb10u1.dsc Just need a maintainer to review and sponsor it, and to work with the Security team to get this uploaded to buster-security. (Note the changelog needs to be changed from UNRELEASED to buster-security.) Update for the unstable (3.x) package to follow soon. Christian
Bug#960650: InspIRCd Security Advisories 2019-02 and 2020-01
Control: retitle -1 InspIRCd Security Advisories 2019-02 and 2020-01 In addition to the 2020-01 advisory I also noticed that this package hasn't yet patched the 2019-02 advisory which is a similar crash/DoS bug. (https://docs.inspircd.org/security/2019-02/) 2019-02 and 2020-01 both affect versions 2.0.27-1 (buster) and 3.4.0-2 (bullseye and sid). For buster, we should prepare a 2.0.27-1+deb10u1 upload to address both advisories. For unstable, we can probably just update to the latest upstream version v3.7.0. As inspircd seems to be transitioning maintainers (see #939424), I would be happy to help here. I have already prepared the packaging changes. I just need to verify that I cannot reproduce the bug, and will require a DD to sponsor my uploads and someone from the Debian Security team to help me with the upload to buster-security. Christian
Bug#896165: ITP: bpftool -- utility for querying and updating BPF objects
Control: reassign -1 wnpp Control: notfound -1 linux/4.16.5-1 Control: affects -1 src:linux Control: retitle ITP: bpftool -- utility for querying and updating BPF objects Control: owner -1 ! Hi all, I'm restructuring this as an ITP. I'm very keen to get bpftool in Debian as well, now that the copyright concerns are resolved. I'll work with the kernel team to get it packaged. Thanks Noah for all the work so far. Christian -- * Package name: bpftool Version : 5.5.8 Upstream Author : Various Linux kernel developers * URL : https://www.kernel.org/ * License : GPL-2.0-only OR BSD-2-Clause Programming Lang: C Description : utility for querying and updating BPF objects bpftool is a utility for querying and updating BPF objects on the system. Packaging bpftool will improve the experience of developing and deploying BPF-backed software on Debian systems. bpftool is actively developed and is maintained as part of the upstream kernel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool Therefore, the Debian kernel source package (src:linux) is a natural place for the bpftool binary package.
Bug#936911: librdkafka: Python2 removal in sid/bullseye
Control: tags -1 patch Python is only used in a few small build scripts which are easy to patch for Python 3. I have submitted a merge request on Salsa containing (among other things) a fix for this issue: https://salsa.debian.org/kafka-team/librdkafka/-/merge_requests/1 Christian
Bug#945604: linux-source-5.4: Failed to build linux-source-5.4 in efi_set_secure_boot
Control: tags -1 patch
The root cause is that lock_kernel_down() is unconditionally called
in efi_set_secure_boot, even if the kernel is compiled without
lockdown support (i.e. SECURITY_LOCKDOWN_LSM=n).
This build failure shouldn't affect the Debian official kernel
packages because the Kconfig default value is overridden
to enable lockdown support. However, if you use the Kconfig
defaults (e.g. when building via the linux-source package)
then you may encounter this error.
There is a flag LOCK_DOWN_IN_EFI_SECURE_BOOT (depending
on SECURITY_LOCKDOWN_LSM) that is currently ignored. It seems
like it was originally supposed to gate the lock_kernel_down call().
I've attached a patch to honor this flag again, which should fix this issue.
From de06de54508caf6bb1d3f25d4ef652d1360a43e0 Mon Sep 17 00:00:00 2001
From: Christian Barcenas
Date: Mon, 17 Feb 2020 02:50:58 -0800
Subject: [PATCH] lockdown: honor LOCK_DOWN_IN_EFI_SECURE_BOOT
Previously LOCK_DOWN_IN_EFI_SECURE_BOOT was ignored;
lock_kernel_down() was always called during EFI Secure Boot.
Additionally this resolves a link-time error that occurs when
the kernel is built with EFI=y and SECURITY_LOCKDOWN_LSM=n.
Closes: #945604
---
...efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch b/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
index e20fd562963c..7d7eada166d0 100644
--- a/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
+++ b/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
@@ -50,12 +50,14 @@ Signed-off-by: Ben Hutchings
/*
* Decide what to do when UEFI secure boot mode is enabled.
-@@ -28,6 +29,8 @@ void __init efi_set_secure_boot(enum efi
+@@ -28,6 +29,10 @@ void __init efi_set_secure_boot(enum efi
break;
case efi_secureboot_mode_enabled:
set_bit(EFI_SECURE_BOOT, );
++#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
+ lock_kernel_down("EFI Secure Boot",
+ LOCKDOWN_CONFIDENTIALITY_MAX);
++#endif
pr_info("Secure boot enabled\n");
break;
default:
--
2.25.0
Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
I just noticed that your packaging repo is currently empty. Would you be able to push your current progress to Github so that it's easier to review the source package? On Thu, Feb 6, 2020 at 2:34 PM Sudip Mukherjee wrote: > So, do we also use epoch or shall I try the way which Paul suggested > to add epoch only to the binary package? My vote is to use libbpf's new versioning scheme and epoch 1 for both source and binary packages. The primary benefit is simplicity: IMO it's easier to reason about things that way. It looks like upstream is trying to separate their own release schedule from the kernel's. There is now a possibility that some future libbpf release may contain changes not present in the upstream kernel tree at all. In this scenario, it would *only* make sense to use libbpf versioning for the source package, so we might as well get both epoch adjustments out of the way right now instead of raising this question again in the future. Christian
Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
Because this changes the versioning scheme from kernel releases (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf version numbers (0.0.6-1), the epoch needs to be incremented to 1 I believe. CC'ing debian-devel for discussion/consensus, per Debian Policy Manual 5.6.12. Christian On Wed, Feb 5, 2020 at 12:57 PM Sudip Mukherjee wrote: > > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "libbpf" > > * Package name: libbpf >Version : 0.0.6-1 >Upstream Author : NA > * URL : https://github.com/libbpf/libbpf > * License : LGPL-2.1 > * Vcs : https://github.com/sudipm-mukherjee/libbpf >Section : libs > > It builds those binary packages: > > libbpf-dev - eBPF helper library (development files) > libbpf0 - eBPF helper library (shared library) > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/libbpf > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/libb/libbpf/libbpf_0.0.6-1.dsc > > Changes since the last upload: > >* Package from github. (Closes: #948041) > > Note: > I think this should be done after > https://salsa.debian.org/kernel-team/linux/merge_requests/207 > has been merged. > > > -- > Regards > Sudip >
Bug#948260: RFS: golang-github-russellhaering-gosaml2/0.3.1-1 [ITP] -- Pure Go implementation of SAML 2.0 (library)
Thanks for the review! On Wed, Jan 8, 2020 at 12:24 AM Dmitry Smirnov wrote: > I gave you "developer" access to the team repository. Could you please try to > push there? Great, I pushed successfully. I omitted the release tag/commit b007372 (UNRELEASED->unstable) in case further packaging changes are needed. I think the default branch for some reason is set to 'upstream' rather than 'debian/sid', would it be possible to change that? Gitlab says I don't have the right permissions: https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gosaml2/-/settings/repository > Everything looks good but it would be great if you could add comment (to > "copyright" file) regarding source of information about upstream copyright as > I could not find copyright statement anywhere. Did you see there is a LICENSE file in the root of the upstream Github repository? For projects whose only website is a Github repo with a LICENSE file, is it necessary to add this a comment like this to d/copyright? Christian
Bug#948260: RFS: golang-github-russellhaering-gosaml2/0.3.1-1 [ITP] -- Pure Go implementation of SAML 2.0 (library)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-russellhaering-gosaml2". Additionally, I need the sponsor to push the packaging from my personal repo https://salsa.debian.org/cb-guest/golang-github-russellhaering-gosaml2 to the official go-team repository https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gosaml2 * Package name: golang-github-russellhaering-gosaml2 Version : 0.3.1-1 Upstream Author : Russell Haering * URL : https://github.com/russellhaering/gosaml2 * License : Apache-2.0 * Vcs : https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gosaml2 Section : devel It builds these binary packages: golang-github-russellhaering-gosaml2-dev - Pure Go implementation of SAML 2.0 (library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-russellhaering-gosaml2 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-russellhaering-gosaml2/golang-github-russellhaering-gosaml2_0.3.1-1.dsc Changes since the last upload: * Initial release (Closes: #948190) * Backport patch for AuthnRequest ordering (upstream bug #45). Regards, -- Christian Barcenas
Bug#948190: ITP: golang-github-russellhaering-gosaml2 -- Pure Go implementation of SAML 2.0
Package: wnpp Severity: wishlist Owner: Christian Barcenas * Package name: golang-github-russellhaering-gosaml2 Version : 0.3.1-1 Upstream Author : Russell Haering * URL : https://github.com/russellhaering/gosaml2 * License : Apache-2.0 Programming Lang: Go Description : Pure Go implementation of SAML 2.0 A generic SAML 2.0 implemementation for Service Providers based on etree and goxmldsig. This is a build dependency of several popular open-source projects such as Kolide Fleet and Gravitational Teleport.
Bug#948173: golang-thrift-dev: Go sources are installed into the wrong path
Package: golang-thrift-dev Version: 0.13.0-2 Severity: important Right now Go source files are installed into /usr/share/gocode/src/thrift. This means that Debian packages trying to build via dh-golang must refer to the golang-thrift-dev sources using the import path "thrift". However, the Go import path that is used by Thrift itself and by dependent projects is really "github.com/apache/thrift/lib/go/thrift". Go sources should be installed into /usr/share/gocode/github.com/apache/thrift/lib/go/thrift. The thrift source package's control file should also contain an XS-Go-Import-Path header reflecting the correct Go import path. Aside: is it worth renaming golang-thrift-dev to golang-github-apache-thrift-dev or golang-github-apache-thrift-lib-go-thrift-dev, in order to comform with the package naming convention used by the Debian Go Packaging Team?
Bug#947281: inspircd: fails to start due to apparmor policy
Source: inspircd Version: 3.4.0-1 Severity: important Tags: patch Dear Maintainer, The AppArmor policy that is included with the unstable inspircd package specifies an incorrect path to the pidfile for the inspircd daemon. As a result AppArmor blocks inspircd from writing its own pidfile during launch, causing startup to fail. This can be reproduced with 'apt-get install inspircd' and then 'journalctl -u inspircd.service' on a fresh unstable machine (with AppArmor enabled). systemd[1]: Starting InspIRCd - Internet Relay Chat Daemon... inspircd[10533]: InspIRCd - Internet Relay Chat Daemon inspircd[10533]: For contributors & authors: See /INFO Output systemd[1]: inspircd.service: Can't open PID file /run/inspircd/inspircd.pid (yet?) after start: Operation not permitted systemd[1]: inspircd.service: Failed with result 'protocol'. systemd[1]: Failed to start InspIRCd - Internet Relay Chat Daemon. This issue appears to have been introduced in unstable when the pidfile path was changed from /run/inspircd.pid to /run/inspircd/inspircd.pid in all locations except the AppArmor policy. The fix is straightforward: Index: inspircd-3.4.0/debian/apparmor/usr.sbin.inspircd === --- inspircd-3.4.0.orig/debian/apparmor/usr.sbin.inspircd +++ inspircd-3.4.0/debian/apparmor/usr.sbin.inspircd @@ -22,7 +22,7 @@ /etc/ldap/ldap.conf r, # pidfile used by inspircd. - /run/inspircd.pid w, + /run/inspircd/inspircd.pid w, # we need to be able to write to the log file # and also the old log when logrotate happends Christian -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#945756: ITP: golang-github-flynn-noise -- Go implementation of the Noise Protocol Framework
Package: wnpp Severity: wishlist Owner: Christian Barcenas * Package name: golang-github-flynn-noise Version : 0.0~git20180327.2492fe1-1 Upstream Author : Flynn * URL : https://github.com/flynn/noise * License : BSD-3-Clause Programming Lang: Go Description : Go implementation of the Noise Protocol Framework This is a Go package that implements the Noise Protocol Framework (https://noiseprotocol.org). . Noise is a framework for building crypto protocols. Noise protocols support mutual and optional authentication, identity hiding, forward secrecy, zero round-trip encryption, and other advanced features. I would like to submit this package for inclusion in the Debian Archive as a dependency of WIP packaging for Nebula (github.com/slackhq/nebula).
