Bug#1069289: arguments to dbus_server_get_address() were incorrect, assertion "server != NULL" failed in file ../../../dbus/dbus-server.c line 840

[Arturo Borrero Gonzalez]

Source: sssd
Version: 2.8.2-4
Severity: normal
Tags: upstream

Hi there,

thanks for your work with the sssd packages, really appreciated.

Today I found this assert that is preventing the sssd.service from starting:

Apr 19 14:02:17 debian sssd[586]: Starting up
Apr 19 14:02:17 debian sssd[586]: dbus[586]: arguments to 
dbus_server_get_address() were incorrect, assertion "server != NULL" failed in 
file ../../../dbus/dbus-server.c line 840.
Apr 19 14:02:17 debian sssd[586]: This is normally a bug in some application 
using the D-Bus library.
Apr 19 14:02:17 debian sssd[586]:   D-Bus not built with -rdynamic so unable to 
print a backtrace
Apr 19 14:02:17 debian systemd[1]: sssd.service: Main process exited, 
code=killed, status=6/ABRT
Apr 19 14:02:17 debian systemd[1]: sssd.service: Failed with result 'signal'.
Apr 19 14:02:17 debian systemd[1]: Failed to start sssd.service - System 
Security Services Daemon.

My configuration:

$ sudo cat /etc/sssd/sssd.conf
[sssd]
domains = files
config_file_version = 2

[domain/files]
id_provider = files
access_provider = permit


Packages in my system:

$ dpkg -l *sss*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---
ii  libnss-sss:amd64  2.8.2-4  amd64Nss library for the System 
Security Services Daemon
ii  libpam-sss:amd64  2.8.2-4  amd64Pam module for the System 
Security Services Daemon
ii  libsss-certmap0   2.8.2-4  amd64Certificate mapping library for 
SSSD
ii  libsss-idmap0 2.8.2-4  amd64ID mapping library for SSSD
ii  libsss-nss-idmap0 2.8.2-4  amd64SID based lookups library for 
SSSD
un  libsss-sudo (no description available)
ii  python3-sss   2.8.2-4  amd64Python3 module for the System 
Security Services Daemon
ii  sssd  2.8.2-4  amd64System Security Services Daemon 
-- metapackage
ii  sssd-ad   2.8.2-4  amd64System Security Services Daemon 
-- Active Directory back end
ii  sssd-ad-common2.8.2-4  amd64System Security Services Daemon 
-- PAC responder
ii  sssd-common   2.8.2-4  amd64System Security Services Daemon 
-- common files
un  sssd-dbus   (no description available)
ii  sssd-ipa  2.8.2-4  amd64System Security Services Daemon 
-- IPA back end
ii  sssd-krb5 2.8.2-4  amd64System Security Services Daemon 
-- Kerberos back end
ii  sssd-krb5-common  2.8.2-4  amd64System Security Services Daemon 
-- Kerberos helpers
ii  sssd-ldap 2.8.2-4  amd64System Security Services Daemon 
-- LDAP back end
ii  sssd-proxy2.8.2-4  amd64System Security Services Daemon 
-- proxy back end
ii  sssd-tools2.8.2-4  amd64System Security Services Daemon 
-- tools


I'm not sure who is to blame, if Dbus or sssd.
In any case, in my opinion, some actionable error message should be produced, 
rather than a weird assert.

Bug#1064342: pulseaudio: a2dp-sink profile connect failed [...]: Protocol not available

[Arturo Borrero Gonzalez]

Package: pulseaudio
Version: 16.1+dfsg1-3
Severity: normal

Dear maintainer,

thanks for your hard work with this package, it is really appreciated.

Today, I hit a problem trying to pair a bluetooth headset.

I got errors like `a2dp-sink profile connect failed [...]: Protocol not 
available`.
Searching the wiki, I found there is a known solution to this, which is 
documented
here:

 
https://wiki.debian.org/BluetoothUser/a2dp#a2dp-sink_profile_connect_failed_.5B5D:_Protocol_not_available

In a nutshell, we need the following two lines in the pulseaudio config file:

load-module module-bluez5-device
load-module module-bluez5-discover

For example, in the file `/etc/pulse/default.pa.d/bluez5.pa`.

Please, consider having the config be shipped as part of the debian package.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser 3.137
ii  init-system-helpers 1.66
ii  libasound2  1.2.10-3
ii  libasound2-plugins  1.2.7.1-1+b1
ii  libc6   2.37-15
ii  libcap2 1:2.66-5
ii  libdbus-1-3 1.14.10-4
ii  libfftw3-single33.3.10-1+b1
ii  libgcc-s1   14-20240201-3
ii  libglib2.0-02.78.4-1
ii  libgstreamer-plugins-base1.0-0  1.22.10-1
ii  libgstreamer1.0-0   1.22.10-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-7
ii  liborc-0.4-01:0.4.34-3
ii  libpulse0   16.1+dfsg1-3
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.2.2-1
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.1-1+b1
ii  libstdc++6  14-20240201-3
ii  libsystemd0 255.3-2
ii  libtdb1 1.4.10-1
ii  libudev1255.3-2
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-32+b1
ii  libx11-62:1.8.7-1
ii  libx11-xcb1 2:1.8.7-1
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  pulseaudio-utils16.1+dfsg1-3
ii  sysvinit-utils [lsb-base]   3.08-6

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.10-4
ii  libpam-systemd [logind]  255.3-2
ii  rtkit0.13-5

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 255.3-2

-- Configuration Files:
/etc/dbus-1/system.d/pulseaudio-system.conf [Errno 2] No such file or 
directory: '/etc/dbus-1/system.d/pulseaudio-system.conf'

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

Bug#1064050: ITP: zellij -- a terminal workspace with batteries included

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: zellij
  Version : 0.39.2
  Upstream Contact: Aram Drevekenin 
* URL : https://zellij.dev/
* License : MIT
  Programming Lang: Rust
  Description : a terminal workspace with batteries included

Zellij is a terminal workspace. It has the base functionality of a terminal 
multiplexer (similar to tmux or screen)
but includes many built-in features that would allow users to extend it and 
create their own personalized environment.

I plan to maintain this as part of the Rust Packaging workflow described in:
 https://wiki.debian.org/Teams/RustPackaging

Bug#1057189: nftables FTCBFS: missing build dependency on python development package

[Arturo Borrero Gonzalez]

On 12/1/23 09:29, Helmut Grohne wrote:

Source: nftables
Version: 1.0.8-1
Severity: important
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

nftables fails to cross build from source, because Python development
files cannot be found while building a Python extension. You are missing
a dependency on libpython3-dev or libpython3-all-dev here. I'm attaching
a patch for your convenience. In theory, this can also break native
builds. Hence bumping severity to important.



Applied, thanks!

Bug#1036165: ITP: atuin -- Rich shell history using a SQLite database with optional encrypted sync

[Arturo Borrero Gonzalez]

On Tue, 16 May 2023 18:01:52 +0800 Blair Noctis  wrote:

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng

* Package name: atuin
  Version : 14.0.1
  Upstream Contact: Ellie Huxtable 
* URL : https://atuin.sh/
* License : MIT
  Programming Lang: Rust
  Description : Rich shell history replacement using SQLite with optional
encrypted sync server



Hi there,

thanks for working on this.

Do you have a repository where you are developing this?

regards.

Bug#1053564: Acknowledgement (nftables: nft freeze after some times, probably as a result of excessive use of named set)

[Arturo Borrero Gonzalez]

On 10/24/23 10:20, Daniel Haryo Sugondo wrote:

Dear maintainer

the problem with named set makes the system unusable.

I would be so thankful, if you can give me some hints, what's
wrong with the behavior since Debian12.




Hi Daniel,

this sounds to me like a bug in the nf_tables linux kernel subsystem.

I don't have the info at hand at the moment whether if this has been fixed 
already. I would try using a newer kernel, either stable or backports.


regards.

Bug#944748: [pkg-netfilter-team] Bug#944748: nftables: no init script

[Arturo Borrero Gonzalez]

On Fri, 20 Oct 2023 11:35:38 +0200 Magnus Holmgren  wrote:


Reminder that this bug isn't about building support for saving the currently 
loaded ruleset to a file and reloading it after reboot, only about adding a 
minimal init script that does the same job as the existing systemd unit.




There wont be any sysvinit integration in this package. Sorry.

rules and then saving the changes, but to facilitate integration of other 
packages with nftables, I think coming up with some scheme where those 
packages can drop configuration snippets in /etc/nftables.d, or perhaps /etc/


This should be done by other components such as firewalld.

No such functions will be added to the nftables package. The nftables package 
will just deploy the `nft` binary plus a few skeleton ruleset and other example. 
I'm already regretting the systemd integration at all.

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Arturo Borrero Gonzalez]

On 9/24/23 13:48, Salvatore Bonaccorso wrote:


The work for bookworm has been done, but for bullseye: would you be
able to help here and prepare the fixes? Unfortunatlly the fixes will
not apply cleanly. If we fear to much breakage, maybe upstream can be
convinced to help?



Hi Salvatore,

I don't think I will have a lot of time to work on this in the next few weeks.

I'm sorry :-(

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Arturo Borrero Gonzalez]

On Sat, Sep 16, 2023, 08:37 Salvatore Bonaccorso  wrote:

> Hi
>
> Dropping some recipients for the Debian specific handling of this
> issue. So AFAIU upstream will not consider this on src:linux side to
> be further handled and needs to be addressed in nftables.
>
> Arturo: With the patches provided I prepared (as Timo) an update
> targetting bookworm for the next point release (bug for release.d.o to
> be submitted soon).
>
> Attached is the proposed debdiff, ans as well as MR on salsa.
>
>
> https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/merge_requests/11
> (note not touching thte salsa-ci part was deliberate, but to make the
> piuparts test one would need adjustment of the target release. But as
> itwas not done for the +deb12u1 itself, I have not touched this)
>
> The same would be needed OTOH for bullseye as well.


Hi Salvatore,

thanks for working on this. I just approved the salsa MR

Please go ahead an upload to the archive via NMU as required ASAP. I won't
be near the keyboard today.

really appreciated,

thanks, regards.

Bug#1039573: cannot authenticate after lock: pam_unix(lightdm:auth): auth could not identify password

[Arturo Borrero Gonzalez]

On Wed, 28 Jun 2023 10:58:39 +0200 Arturo Borrero Gonzalez  
wrote:

Thanks for the follow up, I'll keep you updated in the next few days.


I have not experienced this problem again since the update.

Bug#1039573: cannot authenticate after lock: pam_unix(lightdm:auth): auth could not identify password

[Arturo Borrero Gonzalez]

On 6/27/23 18:14, Yves-Alexis Perez wrote:

On Tue, 2023-06-27 at 12:22 +0200, Arturo Borrero Gonzalez wrote:

I just upgraded lightdm from 1.26.0-8 to 1.32.0-2 and now the greeter wont let 
me
login after a session lock (like a laptop suspend or CTRL+ALT+L on xfce4).



This can be found in the logs:



Jun 27 12:08:28 endurance lightdm[91911]: pam_unix(lightdm-greeter:session): 
session opened for user lightdm(uid=108) by (uid=0)
Jun 27 12:08:29 endurance lightdm[92079]: pam_unix(lightdm:auth): auth could 
not identify password for [arturo]
Jun 27 12:08:38 endurance lightdm[935]: Session pid=92114: Invalid string 
length 1869348864 from child
Jun 27 12:08:38 endurance lightdm[92114]: pam_nologin(lightdm:auth): unexpected 
response from failed conversation function
Jun 27 12:08:38 endurance lightdm[92114]: No user selected during authentication
Jun 27 12:08:38 endurance lightdm[92114]: pam_nologin(lightdm:auth): cannot 
determine user name



So I suspect there is a bug somewhere in the stack.


Hi Arturo, it does look like there's something fishy from the "Invalid string
length 1869348864" (which looks way too high). Is that reproducible everytime
? Is there something specific/peculiar about your installation? I assume
you're using light-locker as your screen locker?



Hi there,

I have experienced the same problem in 2 different systems.
However, I have the strong suspicion that this happened in the same context: 
upgrading the system.


I need a few more days to pass by, but I have the hunch that after a reboot this 
problem goes away. I didn't see it happening again after being hit by it those 2 
times in a row (which triggered me to open this bug).


To your question: yes, I'm using light-locker.

Thanks for the follow up, I'll keep you updated in the next few days.

Bug#1039573: cannot authenticate after lock: pam_unix(lightdm:auth): auth could not identify password

[Arturo Borrero Gonzalez]

Package: lightdm
Version: 1.32.0-2
Severity: important

Hi there!

Thanks for your hard work with this package, it is really appreciated.

I just upgraded lightdm from 1.26.0-8 to 1.32.0-2 and now the greeter wont let 
me
login after a session lock (like a laptop suspend or CTRL+ALT+L on xfce4).

This can be found in the logs:

Jun 27 12:08:28 endurance lightdm[91911]: pam_unix(lightdm-greeter:session): 
session opened for user lightdm(uid=108) by (uid=0)
Jun 27 12:08:29 endurance lightdm[92079]: pam_unix(lightdm:auth): auth could 
not identify password for [arturo]
Jun 27 12:08:38 endurance lightdm[935]: Session pid=92114: Invalid string 
length 1869348864 from child
Jun 27 12:08:38 endurance lightdm[92114]: pam_nologin(lightdm:auth): unexpected 
response from failed conversation function
Jun 27 12:08:38 endurance lightdm[92114]: No user selected during authentication
Jun 27 12:08:38 endurance lightdm[92114]: pam_nologin(lightdm:auth): cannot 
determine user name

So I suspect there is a bug somewhere in the stack.

regards.


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.134
ii  dbus   1.14.8-1
ii  debconf [debconf-2.0]  1.5.82
ii  libaudit1  1:3.0.9-1
ii  libc6  2.36-9
ii  libgcrypt201.10.2-2
ii  libglib2.0-0   2.74.6-2
ii  libpam-systemd [logind]252.11-1
ii  libpam0g   1.5.2-6
ii  libxcb11.15-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.8-3

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+23

Versions of packages lightdm suggests:
ii  accountsservice  22.08.8-6
ii  upower   0.99.20-2
pn  xserver-xephyr   

-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
[Seat:*]
greeter-hide-users=false
display-setup-script=sh -c "xrandr -s 1920x1080"
[XDMCPServer]
[VNCServer]


-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

Bug#1038727: bookworm-pu: package nftables/1.0.6-2+deb12u1

[Arturo Borrero Gonzalez]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nftab...@packages.debian.org
Control: affects -1 + src:nftables

There has been a behavior regression reported in nftables when
upgrading from Debian 11 Bullseye to Debian 12 Bookworm.

The change is in how nftables prints the set definitions, with
or without set elements by default.

Some user tools relying on 'nft -j list sets' fail after upgrading
to Debian Bookworm from Debian Bullseye because the behavior change.

The small upstream fix makes the behavior coherent and predictable for the
set listing action.

There is not much risk in this update:
* The fix patch has been provided directly by upstream
* The fix has been applied to upstream main branch already
* The fix is already in Debian Sid

Find debdiff attached against the current Debian stable package.

See also:
 * https://marc.info/?l=netfilter=168704941828372=2 (original report)
 * https://bugs.debian.org/1038724 (debian bug)
 * 
https://git.netfilter.org/nftables/commit/?id=29bed4fa594c3f6e343a8b5669d61e20c7129cca
 (upstream fix)
diff -Nru nftables-1.0.6/debian/changelog nftables-1.0.6/debian/changelog
--- nftables-1.0.6/debian/changelog 2023-01-29 12:33:00.0 +0100
+++ nftables-1.0.6/debian/changelog 2023-06-20 16:55:52.0 +0200
@@ -1,3 +1,9 @@
+nftables (1.0.6-2+deb12u1) bookworm; urgency=medium
+
+  * [7edf72e] d/patches: add 0001-debian-bug-1038724.patch (Closes: #1038724)
+
+ -- Arturo Borrero Gonzalez   Tue, 20 Jun 2023 16:55:52 
+0200
+
 nftables (1.0.6-2) unstable; urgency=medium
 
   [ Jeremy Sowden ]
diff -Nru nftables-1.0.6/debian/patches/0001-debian-bug-1038724.patch 
nftables-1.0.6/debian/patches/0001-debian-bug-1038724.patch
--- nftables-1.0.6/debian/patches/0001-debian-bug-1038724.patch 1970-01-01 
01:00:00.0 +0100
+++ nftables-1.0.6/debian/patches/0001-debian-bug-1038724.patch 2023-06-20 
16:55:52.0 +0200
@@ -0,0 +1,66 @@
+From 29bed4fa594c3f6e343a8b5669d61e20c7129cca Mon Sep 17 00:00:00 2001
+From: Florian Westphal 
+Date: Sun, 18 Jun 2023 18:39:45 +0200
+Subject: cache: include set elements in "nft set list"
+
+Make "nft list sets" include set elements in listing by default.
+In nftables 1.0.0, "nft list sets" did not include the set elements,
+but with "--json" they were included.
+
+1.0.1 and newer never include them.
+This causes a problem for people updating from 1.0.0 and relying
+on the presence of the set elements.
+
+Change nftables to always include the set elements.
+The "--terse" option is honored to get the "no elements" behaviour.
+
+Fixes: a1a6b0a5c3c4 ("cache: finer grain cache population for list commands")
+Link: https://marc.info/?l=netfilter=168704941828372=2
+Signed-off-by: Florian Westphal 
+---
+ src/cache.c | 2 ++
+ src/rule.c  | 8 +---
+ 2 files changed, 3 insertions(+), 7 deletions(-)
+
+diff --git a/src/cache.c b/src/cache.c
+index 95adee7f..becfa57f 100644
+--- a/src/cache.c
 b/src/cache.c
+@@ -235,6 +235,8 @@ static unsigned int evaluate_cache_list(struct nft_ctx 
*nft, struct cmd *cmd,
+   case CMD_OBJ_SETS:
+   case CMD_OBJ_MAPS:
+   flags |= NFT_CACHE_TABLE | NFT_CACHE_SET;
++  if (!nft_output_terse(>output))
++  flags |= NFT_CACHE_SETELEM;
+   break;
+   case CMD_OBJ_FLOWTABLE:
+   if (filter &&
+diff --git a/src/rule.c b/src/rule.c
+index 633a5a12..1faa1a27 100644
+--- a/src/rule.c
 b/src/rule.c
+@@ -1574,11 +1574,6 @@ static int do_list_table(struct netlink_ctx *ctx, 
struct table *table)
+ 
+ static int do_list_sets(struct netlink_ctx *ctx, struct cmd *cmd)
+ {
+-  struct print_fmt_options opts = {
+-  .tab= "\t",
+-  .nl = "\n",
+-  .stmt_separator = "\n",
+-  };
+   struct table *table;
+   struct set *set;
+ 
+@@ -1601,8 +1596,7 @@ static int do_list_sets(struct netlink_ctx *ctx, struct 
cmd *cmd)
+   if (cmd->obj == CMD_OBJ_MAPS &&
+   !map_is_literal(set->flags))
+   continue;
+-  set_print_declaration(set, , >nft->output);
+-  nft_print(>nft->output, "%s}%s", opts.tab, 
opts.nl);
++  set_print(set, >nft->output);
+   }
+ 
+   nft_print(>nft->output, "}\n");
+-- 
+cgit v1.2.3
+
diff -Nru nftables-1.0.6/debian/patches/series 
nftables-1.0.6/debian/patches/series
--- nftables-1.0.6/debian/patches/series2023-01-29 12:33:00.0 
+0100
+++ nftables-1.0.6/debian/patches/series2023-06-20 16:55:52.0 
+0200
@@ -1 +1,2 @@
+0001-debian-bug-1038724.patch
 invalid-octal-fix.patch

Bug#1038724: regression: nft list sets changed behavior

[Arturo Borrero Gonzalez]

Package: nftables
Version: 1.0.6-2
Severity: important
Tags: upstream

It has been reported that the nftables package version >1.0.0 introduces
a behavior regression related to listing sets.

=== 8< ===
After updating to Debian 12 my tools relying on 'nft -j list sets' fail. 
It now does not include the elements in those lists like it did on 11.

Is this hidden behind an 'anti-terse' flag now?
=== 8< ===

Original report:
 https://marc.info/?l=netfilter=168704941828372=2

This has been addressed by upstream patch:
https://git.netfilter.org/nftables/commit/?id=29bed4fa594c3f6e343a8b5669d61e20c7129cca

Bug#1032248: Bug seems fixed

[Arturo Borrero Gonzalez]

Control: fixed -1 525.105.17-1

Hi there,

after the recent upgrade to 525.105.17-1 I'm no longer observing the problem in 
my system.


Marking bug as resolved, will reopen if is a false positive.

thanks!

Bug#1034819: nft default disabled

[Arturo Borrero Gonzalez]

reassign 1034819 debian-installer

On Tue, 25 Apr 2023 11:27:56 +0200 Bonno Bloksma  wrote:

Package: d-i
Severity: minor

Dear Maintainer,

Testing with a new Debian bookworm install, downloaded apr 24 2023, I noticed my nftables.conf firewall configuration never gets loaded. 


After some testing a searching on the net I found it is disabled by default. As 
the /etc/nftables.conf file is marked executable by default this lead me to 
think it would get loaded by the service.
As the default firewall in that file quite innocent I wonder why the service is 
not enabled by default?

In my case not getting any errors and having a proper config led me to believe 
my firewall was working.
All services worked as well. Of course they did, there was no firewall. :-(

As Buster still had a working iptables I never noticed the problem there, not 
even when I converted some of my itables config to a nft config file.
All my services still worked after the conversion so I assumed the conversion 
was successfull.
Never realizing the filewall config never got loaded and there was no filewall 
at all, so my services did indeed work as there was nothing to block it. :-(

Bookworm does not have iptables anymore by default, it should have at least one 
acvtive firewall.
Please by default enable the nft service during install and have it load the (innocent) default config in /etc/nftables.conf 





The recommended firewall for Debian is the firewalld utility. The default should 
be to have firewalld up and running. This is since Debian 11 Bullseye [0].


I don't think there is nothing wrong in the nftables package.

Please Debian installer folks, what would we need for tasksel to enable 
firewalld by default? (if tasksel is the right place).


regards.

[0] https://lists.debian.org/debian-devel/2019/07/msg00332.html

Bug#1031943: [pkg-netfilter-team] Bug#1031943: Should we do something?

[Arturo Borrero Gonzalez]

control: severity -1 important

On 3/23/23 16:18, Jeremy Sowden wrote:

On 2023-03-23, at 15:58:45 +0100, Alberto Molina Coballes wrote:

I agree with Arturo, the proposed change should be harmless, but we
were not able to reproduce the issue in any of the test performed so I
was thinking to lower the severity and apply the patch but don't ask
to be included in bookworm.


Sounds good to me.



Ok, lowering the severity now, thanks.

Bug#1031943: Should we do something?

[Arturo Borrero Gonzalez]

On Thu, 23 Mar 2023 09:46:05 +0100 Thomas Goirand  wrote:

Hi,

It's been a month since the last entry in this bug, with nobody able to 
reproduce the bug, and no answer from original submitter. Shall we:

- close the bug?
- lower severity?
- apply the patch?



Introducing the proposed change should be harmless. I'd do that, specially if it 
relax some problems somewhere.

Bug#1032248: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out

[Arturo Borrero Gonzalez]

Source: nvidia-graphics-drivers
Version: 525.85.12-1
Severity: important
Tags: upstream

Dear maintainers,

thanks for your hard work with this complex package, really appreciated.

After a recent update to the 525 series, my external monitors freeze randomly, 
and this message can be
see in the dmesg log:

[Thu Mar  2 10:17:01 2023] nvidia-modeset: ERROR: GPU:0: Idling display engine 
timed out: 0xc67e:0:0:1128
[Thu Mar  2 10:17:04 2023] nvidia-modeset: ERROR: GPU:0: Idling display engine 
timed out: 0xc67e:2:0:1128
[Thu Mar  2 10:17:08 2023] nvidia-modeset: ERROR: GPU:0: Idling display engine 
timed out: 0xc67e:0:0:1128
[Thu Mar  2 10:17:10 2023] nvidia-modeset: ERROR: GPU:0: Idling display engine 
timed out: 0xc67e:2:0:1128

Other similar reports online suggests this problem was introduced upstream in 
the 524 series:

https://bbs.archlinux.org/viewtopic.php?id=282669
https://forums.developer.nvidia.com/t/error-gpu-idling-display-engine-timed-out-since-524-x-and-linux-6-1-5/242543

regards.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1030684: libvirtd: apparmor DENIED for /etc/ssl/openssl.cnf results in VM paused with IO error

[Arturo Borrero Gonzalez]

control: retitle -1 libvirtd: apparmor DENIED for /etc/ssl/openssl.cnf

On Mon, 06 Feb 2023 14:29:42 +0100 Arturo Borrero Gonzalez  
wrote:>

When checking the `dmesg` utility, I found and apparmor DENIED entry:

audit: type=1400 audit(1675687963.952:121): apparmor="DENIED" operation="open" 
profile="libvirt-ff5c79a6-f53b-473b-b181-f1148e861bde" name="/etc/ssl/openssl.cnf" pid=40557 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

I've tested several VMs and they all go into this IO error state with similar 
apparmor messages after a while.



Update: the VM going into pause seems unrelated to the apparmor DENIED 
situation. I had a full storage pool.


The apparmor DENIED error is still happening, but I'm unclear of the effects it 
has.

Bug#1030684: libvirtd: apparmor DENIED for /etc/ssl/openssl.cnf results in VM paused with IO error

[Arturo Borrero Gonzalez]

Package: libvirt-daemon-system
Version: 9.0.0-1
Severity: normal

Dear maintainers,

thanks for your work with this package, really appreciated.

Today, working with libvirt/virt-manager in a freshly installed Debian Testing 
system (bookwoorm)
I installed a virtual machine that would pause on its own after some use time, 
with I/O error.

When checking the `dmesg` utility, I found and apparmor DENIED entry:

audit: type=1400 audit(1675687963.952:121): apparmor="DENIED" operation="open" 
profile="libvirt-ff5c79a6-f53b-473b-b181-f1148e861bde" 
name="/etc/ssl/openssl.cnf" pid=40557 comm="qemu-system-x86" requested_mask="r" 
denied_mask="r" fsuid=64055 ouid=0

I've tested several VMs and they all go into this IO error state with similar 
apparmor messages after a while.

Other bugs I've read for similar problems are the following:
* #971837 -- libvirt-daemon: apparmor error when creating VM
* #934459 -- AppArmor configuration doesn't cover openssl.cnf in /etc/ssl/

regards.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.130
ii  debconf [debconf-2.0]   1.5.82
ii  gettext-base0.21-11
ii  iptables1.8.9-2
ii  libvirt-clients 9.0.0-1
ii  libvirt-daemon  9.0.0-1
ii  libvirt-daemon-config-network   9.0.0-1
ii  libvirt-daemon-config-nwfilter  9.0.0-1
ii  libvirt-daemon-system-systemd   9.0.0-1
ii  logrotate   3.21.0-1
ii  polkitd 122-3

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.4-1
ii  dnsmasq-base [dnsmasq-base]  2.88-1
ii  iproute2 6.1.0-1
ii  mdevctl  1.2.0-3
ii  parted   3.5-3

Versions of packages libvirt-daemon-system suggests:
ii  apparmor3.0.8-2+b1
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
pn  pm-utils
ii  systemd 252.5-2
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'

-- debconf information:
  libvirt-daemon-system/id_warning: true

Bug#1030671: g_hash_table_unref: assertion 'hash_table != NULL' failed

[Arturo Borrero Gonzalez]

Package: libvirt-daemon
Version: 9.0.0-1
Severity: normal
Tags: upstream

Dear maintainers,

thanks for your work with this key package, really appreciated.

I installed the latest version of libvirt today and saw an assertion on the 
logs:

[..]
Feb 06 12:26:55 nostromo systemd[1]: Starting libvirtd.service - Virtualization 
daemon...
Feb 06 12:26:55 nostromo systemd[1]: Started libvirtd.service - Virtualization 
daemon.
Feb 06 12:26:55 nostromo dnsmasq[31813]: started, version 2.88 cachesize 150
Feb 06 12:26:55 nostromo dnsmasq[31813]: compile time options: IPv6 GNU-getopt 
DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cr>
Feb 06 12:26:55 nostromo dnsmasq-dhcp[31813]: DHCP, IP range 192.168.122.2 -- 
192.168.122.254, lease time 1h
Feb 06 12:26:55 nostromo dnsmasq-dhcp[31813]: DHCP, sockets bound exclusively 
to interface virbr0
Feb 06 12:26:55 nostromo dnsmasq[31813]: reading /etc/resolv.conf
Feb 06 12:26:55 nostromo dnsmasq[31813]: using nameserver 100.100.1.1#53
Feb 06 12:26:55 nostromo dnsmasq[31813]: using nameserver 100.90.1.1#53
Feb 06 12:26:55 nostromo dnsmasq[31813]: using nameserver 2a0c:5a80:0:2::1#53
Feb 06 12:26:55 nostromo dnsmasq[31813]: using nameserver 2a0c:5a84:0:2::1#53
Feb 06 12:26:55 nostromo dnsmasq[31813]: read /etc/hosts - 8 names
Feb 06 12:26:55 nostromo dnsmasq[31813]: read 
/var/lib/libvirt/dnsmasq/default.addnhosts - 0 names
Feb 06 12:26:55 nostromo dnsmasq-dhcp[31813]: read 
/var/lib/libvirt/dnsmasq/default.hostsfile
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPDISCOVER(virbr0) 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPOFFER(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPDISCOVER(virbr0) 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPOFFER(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPDISCOVER(virbr0) 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPOFFER(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPDISCOVER(virbr0) 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPOFFER(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPREQUEST(virbr0) 
192.168.122.164 52:54:00:1b:c8:0a
Feb 06 12:27:11 nostromo dnsmasq-dhcp[31813]: DHCPACK(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a
Feb 06 12:27:22 nostromo libvirtd[31721]: g_hash_table_unref: assertion 
'hash_table != NULL' failed
Feb 06 12:27:36 nostromo dnsmasq-dhcp[31813]: DHCPDISCOVER(virbr0) 
52:54:00:1b:c8:0a
Feb 06 12:27:36 nostromo dnsmasq-dhcp[31813]: DHCPOFFER(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a
Feb 06 12:27:36 nostromo dnsmasq-dhcp[31813]: DHCPREQUEST(virbr0) 
192.168.122.164 52:54:00:1b:c8:0a
Feb 06 12:27:36 nostromo dnsmasq-dhcp[31813]: DHCPACK(virbr0) 192.168.122.164 
52:54:00:1b:c8:0a

regards.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.3.1-3
ii  libblkid1   2.38.1-4
ii  libc6   2.36-8
ii  libdevmapper1.02.1  2:1.02.185-2
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.5-1
ii  libparted2  3.5-3
ii  libpcap0.8  1.10.3-1
ii  libpciaccess0   0.17-2
ii  libselinux1 3.4-1+b5
ii  libtirpc3   1.3.3+ds-1
ii  libudev1252.5-2
ii  libvirt-daemon-driver-qemu  9.0.0-1
ii  libvirt09.0.0-1
ii  libxml2 2.9.14+dfsg-1.1+b3

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   9.0.0-1
ii  libvirt-daemon-driver-vbox  9.0.0-1
ii  libvirt-daemon-driver-xen   9.0.0-1
ii  libxml2-utils   2.9.14+dfsg-1.1+b3
ii  lvm22.03.16-2
ii  mount   2.38.1-4
ii  netcat-openbsd  1.219-1
ii  qemu-system 1:7.2+dfsg-1+b2
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-1+b2

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   9.0.0-1
pn  numad   

-- no debconf information

Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

[Arturo Borrero Gonzalez]

On Thu, 29 Sep 2022 14:33:29 +0200 Arturo Borrero Gonzalez 
 wrote:


Imagine this setup:

eno1  -- physical base device
eno1. -- vlan sub-interface
eno1. -- vlan sub-interface
br01  -- bridge device

I add eno1. and eno1. to br01 as ports.


I discovered that if use a more modern approach to naming the vlan 
devices this problem won't show up.


If instead of 'eno1.' you create 'vlan' then the algorithm to 
disable IPv6 wont detect the base interface and therefore will leave it 
alone.


This definitely feels fragile and inconsistent, and additional 
indication that the patch proposed by Anton may be the right course of 
action.


regards.

Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

[Arturo Borrero Gonzalez]

On Sun, 06 Feb 2022 08:58:38 +0100 Anton Khirnov  wrote:

Quoting Santiago Garcia Mantinan (2022-02-05 22:56:09)
> Well, having IPv6 addresses attached to those ports can also be undesirable,

Could you please explain why do you think so? It would be good to have
the reason documented somewhere, as this behavior was quite surprising
to me.

> I really think that those addresses should be allowed with an explicit
> config not by default.

I suppose adding an option won't be too hard. I'll send a new patch.



There is something I'm not quite understanding.

Imagine this setup:

eno1  -- physical base device
eno1. -- vlan sub-interface
eno1. -- vlan sub-interface
br01  -- bridge device

I add eno1. and eno1. to br01 as ports.

Why would the bridge care about the IPv6 setup that I have on eno1? 
Perhaps is too invasive (and counterintuitive anyways).


The base/parent device shouldn't be affected by the setup used on the 
sub-devices. The configuration for the base interface should be left 
untouched.


I think the patch by Anton Khirnov may be the right approach.

This problem is affecting 2 different virtual machine setups in my 
organization (openstack and ganeti).


regards.
--
Arturo Borrero Gonzalez
Senior Site Reliability Engineer
Wikimedia Cloud Services
Wikimedia Foundation

Bug#1012613: nftables: upgrade stops but does not start service

[Arturo Borrero Gonzalez]

On Fri, 10 Jun 2022 12:21:37 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= 
 wrote:

Package: nftables
Version: 1.0.4-1
Severity: serious

Dear Maintainer,

upgrades of nftables stop the service but do not start it (even if the
service is actually enabled).
This can lead to lockouts, e.g. when using special rules for ssh access.


nft.preinst:

#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.7.1
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d
/run/systemd/system ] ; then
   deb-systemd-invoke stop 'nftables.service' >/dev/null || true
fi
# End automatically added section


nft.postinst:

#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.7.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
   if deb-systemd-helper debian-installed 'nftables.service'; then
   # This will only remove masks created by d-s-h on
package removal.
   deb-systemd-helper unmask 'nftables.service' >/dev/null || true

   if deb-systemd-helper --quiet was-enabled
'nftables.service'; then
   # Create new symlinks, if any.
   deb-systemd-helper enable 'nftables.service'
>/dev/null || true
   fi
   fi

   # Update the statefile to add new symlinks (if any), which need
to be cleaned
   # up on purge. Also remove old symlinks.
   deb-systemd-helper update-state 'nftables.service' >/dev/null || true
fi
# End automatically added section




I confirmed this can be a problem:

=== 8< ===
⌂0.65 arturo@nostromo:~ $ apt-cache policy nftables
nftables:
  Installed: 1.0.2-1
  Candidate: 1.0.4-1
  Version table:
 1.0.4-1 500
500 http://deb.debian.org/debian sid/main amd64 Packages
 *** 1.0.2-1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
⌂0.68 arturo@nostromo:~ $ sudo systemctl status nftables
● nftables.service - nftables
 Loaded: loaded (/lib/systemd/system/nftables.service; disabled; 
vendor preset: enabled)

 Active: active (exited) since Sun 2022-06-19 13:38:11 CEST; 51s ago
   Docs: man:nft(8)
 http://wiki.nftables.org
Process: 5537 ExecStart=/usr/sbin/nft -f /etc/nftables.conf 
(code=exited, status=0/SUCCESS)

   Main PID: 5537 (code=exited, status=0/SUCCESS)
CPU: 13ms

Jun 19 13:38:11 nostromo systemd[1]: Starting nftables...
Jun 19 13:38:11 nostromo systemd[1]: Finished nftables.
⌂0.70 arturo@nostromo:~ $ sudo nft list ruleset
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
iif "lo" accept
ct state established,related accept
tcp dport 22 ct state new accept
		ip6 nexthdr ipv6-icmp icmpv6 type { nd-router-advert, 
nd-neighbor-solicit, nd-neighbor-advert } accept

counter packets 6 bytes 898 drop
}
}
⌂0.65 arturo@nostromo:~ $ sudo aptitude install nftables
The following packages will be upgraded:
  libnftables1 nftables
2 packages upgraded, 0 newly installed, 0 to remove and 754 not upgraded.
Need to get 365 kB of archives. After unpacking 27.6 kB will be used.
Do you want to continue? [Y/n/?] Y
Get: 1 http://deb.debian.org/debian sid/main amd64 nftables amd64 
1.0.4-1 [71.9 kB]
Get: 2 http://deb.debian.org/debian sid/main amd64 libnftables1 amd64 
1.0.4-1 [294 kB]

Fetched 365 kB in 0s (4,064 kB/s)
Reading changelogs... Done
(Reading database ... 273043 files and directories currently installed.)
Preparing to unpack .../nftables_1.0.4-1_amd64.deb ...
Unpacking nftables (1.0.4-1) over (1.0.2-1) ...
Preparing to unpack .../libnftables1_1.0.4-1_amd64.deb ...
Unpacking libnftables1:amd64 (1.0.4-1) over (1.0.2-1) ...
Setting up libnftables1:amd64 (1.0.4-1) ...
Setting up nftables (1.0.4-1) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.33-7) ...

Current status: 754 (-2) upgradable.
⌂0.78 arturo@nostromo:~ $ sudo nft list ruleset
⌂0.78 arturo@nostromo:~ $ sudo systemctl status nftables
○ nftables.service - nftables
 Loaded: loaded (/lib/systemd/system/nftables.service; disabled; 
vendor preset: enabled)

 Active: inactive (dead)
   Docs: man:nft(8)
 http://wiki.nftables.org

Jun 19 13:38:11 nostromo systemd[1]: Starting nftables...
Jun 19 13:38:11 nostromo systemd[1]: Finished nftables.
Jun 19 13:39:13 nostromo systemd[1]: Stopping nftables...
Jun 19 13:39:13 nostromo systemd[1]: nftables.service: Deactivated 
successfully.

Jun 19 13:39:13 nostromo systemd[1]: Stopped nftables.
=== 8< ===

@Alberto, @Jeremy,

It seems to me like we need to play with the dh_installsystemd 
--no-restart-after-upgrade option, but don't have time to figure out the 
right logic.


I'm currently unable to handle this. Could you please take a look?

regards.

Bug#1012025: nftables.conf: trying to import nftables.conf and get unexpected meta or ip6 when trying to start

[Arturo Borrero Gonzalez]

On Sun, May 29, 2022, 01:03 Tim McConnell  wrote:

> Package: nftables
> Version: 1.0.2-1
> Severity: important
> File: nftables.conf
> Tags: ipv6
> X-Debbugs-Cc: tmcconnell...@gmail.com
>
> Dear Maintainer,
>
> What led up to the situation?
> Trying to configure and enable nftables to stop ip6 neighbor discovery
> packets
> from being rejected by VPN
>
> What exactly did you do (or not do) that was effective (or
>  ineffective)? Attempted to use workstation.nft in examples folder and
> looked for documentation on the web.I couldn't find anything newer than
> 2014
> and asked on Debian Forums and Linuxquestions.org
>
> What was the outcome of this action?
> Attempt to run 'sudo systemctl start nftables.service' and receive this
> error:
> Job for nftables.service failed because the control process exited with
> error
> code.
> See "systemctl status nftables.service" and "journalctl -xeu
> nftables.service"
> for details.
> tmick@DebianTim:~/recap$ sudo systemctl status nftables.service
> × nftables.service - nftables
>  Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor
> preset: enabled)
>  Active: failed (Result: exit-code) since Sat 2022-05-28 16:39:05 CDT;
> 7s
> ago
>Docs: man:nft(8)
>  http://wiki.nftables.org
> Process: 1704177 ExecStart=/usr/sbin/nft -f /etc/nftables.conf
> (code=exited, status=1/FAILURE)
>Main PID: 1704177 (code=exited, status=1/FAILURE)
> CPU: 24ms
>
> May 28 16:39:05 DebianTim nft[1704177]:
> ^^
> May 28 16:39:05 DebianTim nft[1704177]: /etc/nftables.conf:18:3-6: Error:
> syntax error, unexpected meta
> May 28 16:39:05 DebianTim nft[1704177]: meta nexthdr ipv6
> icmpv6 type { destination-unreachable, packet-too>
> May 28 16:39:05 DebianTim nft[1704177]: 
> May 28 16:39:05 DebianTim nft[1704177]: /etc/nftables.conf:19:8-12: Error:
> syntax error, unexpected saddr, expecting string
> May 28 16:39:05 DebianTim nft[1704177]: ipv6 saddr
> fe80::/10
> icmpv6 type { 130, 131, 132, 134, 143, 151, 15>
> May 28 16:39:05 DebianTim nft[1704177]:  ^
> May 28 16:39:05 DebianTim systemd[1]: nftables.service: Main process
> exited,
> code=exited, status=1/FAILURE
> May 28 16:39:05 DebianTim systemd[1]: nftables.service: Failed with result
> 'exit-code'.
> May 28 16:39:05 DebianTim systemd[1]: Failed to start nftables.
> I've tried other methods as inet etc and still get this type of error.
>
> What outcome did you expect instead? For documentation to be clear enough
> for
> this not to be a problem and the nftables to be able to add this filter.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages nftables depends on:
> ii  libc6 2.33-7
> ii  libedit2  3.1-20210910-1
> ii  libnftables1  1.0.2-1
>
> Versions of packages nftables recommends:
> ii  netbase  6.3
>
> Versions of packages nftables suggests:
> pn  firewalld  
>
> -- Configuration Files:
> /etc/nftables.conf changed:
> flush ruleset
> table enp1s0 filter {
>

This table declaration is missing family specificiation, which defaults to
IPv4. I think you canot use IPv6 stuff in v4 tables.

I think you may want to use a table in the 'inet' family, which is
dual-stack, and should accept both IPv4 and IPv6 stuff.




chain base_checks {
> # Drop invalid connections and allow established/related
> connections
> ct state invalid drop
> ct state {established, related} accept
> }
>
> chain input {
> type filter hook input priority 0; policy drop;
> meta nexthdr ipv6 icmpv6 type { destination-unreachable,
> packet-too-big, time-exceeded, parameter-problem, echo-reply, echo-request,
> nd-router-solicit, nd-router-advert, nd-neighbor-solicit,
> nd-neighbor-advert, 148, 149 } accept
> ipv6 saddr fe80::/10 icmpv6 type { 130, 131, 132, 134,
> 143, 151, 152, 153 } accept
> jump base_checks
> # Allow from loopback
> iifname lo accept
> iifname != lo ip daddr 127.0.0.0/32 drop
> # New UDP traffic will jump to the UDP chain
> ip protocol udp ct state new jump UDP
> # New TCP traffic will jump to the TCP chain
> tcp flags & (fin | syn | rst | ack) == syn ct state new
> jump TCP
> # Everything else
> ip protocol udp reject
> ip protocol tcp reject with tcp reset
> reject with icmpx type port-unreachable
> }
> chain forward {
> type 

Bug#1011613: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed

[Arturo Borrero Gonzalez]

Package: pdfsam
Version: 4.2.12-1
Severity: important
Tags: upstream
X-Debbugs-Cc: art...@debian.org

Dear maintainer, thanks for your work with this package, really appreciated.

I got this backtrace today:

arturo@nostromo:~$ pdfsam 
May 25, 2022 12:15:07 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
INFO  12:15:07.502 o.p.PdfsamApp[JavaFX-Launcher] Starting PDFsam
INFO  12:15:08.049 o.s.c.c.GlobalConfiguration[JavaFX Application Thread] 
Configuring Sejda 4.2.13
INFO  12:15:08.288 o.p.PdfsamApp[JavaFX Application Thread] Started in 0 seconds
INFO  12:15:22.386 o.p.p.SAMBoxPdfLoadService[pool-3-thread-1] 
denuncia_deportes_tomas.pdf loaded
INFO  12:15:22.390 o.p.p.SAMBoxPdfLoadService[pool-3-thread-1] 
carta_reclamacion_deportes_tomas_pdf.pdf loaded
INFO  12:15:34.209 o.s.c.s.DefaultTaskExecutionService[pool-2-thread-1] 
Starting task (org.sejda.impl.sambox.MergeTask@15a4a7ff) execution.
WARN  12:15:34.332 
org.sejda.sambox.pdmodel.font.FileSystemFontProvider[pool-2-thread-1] New fonts 
found, font cache will be re-built
WARN  12:15:34.332 
org.sejda.sambox.pdmodel.font.FileSystemFontProvider[pool-2-thread-1] Building 
on-disk font cache, this may take a while
WARN  12:15:34.506 
org.sejda.sambox.pdmodel.font.FileSystemFontProvider[pool-2-thread-1] Finished 
building on-disk font cache, found 212 fonts
INFO  12:15:34.572 o.s.m.t.TaskExecutionContext[pool-2-thread-1] Task 
(org.sejda.impl.sambox.MergeTask@15a4a7ff) executed in 0 seconds
[xcb] Unknown sequence number while processing reply
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been 
called
[xcb] Aborting, sorry about that.
java: ../../src/xcb_io.c:730: _XReply: Assertion 
`!xcb_xlib_threads_sequence_lost' failed.
Aborted

What I did was:
 * open pdfsam
 * click on "merge" documents option
 * load 2 documets
 * click "Run" at the bottom
 * click "Open" at the bottom after the run was completed.
 * the program crashed.

Please note, the merged PDF document was generated despite the crash.

regards.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pdfsam depends on:
ii  default-jre [java9-runtime] 2:1.11-72
ii  libatinject-jsr330-api-java 1.0+ds1-5
ii  libbcmail-java  1.71-1
ii  libbcprov-java  1.71-1
ii  libcommons-io-java  2.11.0-2
ii  libcommons-lang3-java   3.12.0-2
ii  libfontawesomefx-java   9.1.2-2
ii  libgettext-commons-java 0.9.6-6
ii  libhibernate-validator4-java4.3.4-4
ii  libjackson2-jr-java 2.13.0-2
ii  liblogback-java 1:1.2.11-1
ii  libopenjfx-java 11.0.11+0-1
ii  libsambox-java  2.3.4-1
ii  libsejda-commons-java   1.1.7-1
ii  libsejda-eventstudio-java   3.0.4-1
ii  libsejda-injector-java  2.0.0-1
ii  libsejda-java   4.2.13-1
ii  libslf4j-java   1.7.32-1
ii  openjdk-11-jre [java9-runtime]  11.0.14.1+1-1
ii  openjfx 11.0.11+0-1

pdfsam recommends no packages.

pdfsam suggests no packages.

-- no debconf information

Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links: debdiff for NMU in DELAYED/2

[Arturo Borrero Gonzalez]

On 4/6/22 13:29, Thomas Goirand wrote:

Hi,

As per discussion on IRC and check of the existing prerm, arptables 
already has the logic in prerm to clean-up old symlinks, so I didn't 
touch it.


Discussing on #debian-devel, it was agreed we need to clean-up eventual 
remainings of the symlink, if they point to /usr/sbin/*, so that's what 
I've done in the attached patch.


I have attached the debdiff for the NMU that I've uploaded to delayed-2. 
Let me know if that's fine, or if you would like me to "dcut rm" the 
upload.




Works for me, thanks!

Bug#1007829: [pkg-netfilter-team] Bug#1007829: Bug#1007829: arptables - Fails to install: Too many levels of symbolic links

[Arturo Borrero Gonzalez]

On 4/6/22 10:36, Thomas Goirand wrote:

Hi,

Please find attached debdiff to fix this bug.

I'll be uploading this to DELAYED/2 queue, as this is affecting a lot of 
people/packages and we need a fix fast. Please let me know if you prefer 
to fix it yourself and you wish me to "dcut rm" my upload.




I was wondering if a similar fix was required in iptables & ebtables.

In the case of iptables:

https://salsa.debian.org/pkg-netfilter-team/pkg-iptables/-/commit/5b0b40839fbc18eb71130947ed76527b7caccdd1

That code was dropped a few years ago.

However, in the case of ebtables:

https://salsa.debian.org/pkg-netfilter-team/pkg-ebtables/-/blob/master/debian/ebtables.postinst#L20

The same code is present.

In all cases, we need a similar fix for prerm as well, see:

https://salsa.debian.org/pkg-netfilter-team/pkg-ebtables/-/commit/5dbd22d1a2c8848d40596524a73d3c3f5e272734

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Arturo Borrero Gonzalez]

On 3/25/22 23:57, Vincent Bernat wrote:

  ❦ 25 March 2022 11:48 +01, Arturo Borrero Gonzalez:


I honestly don't know how this relates to the execution error itself.
Do you think the address assignment fails because some misconfigured
netmask?


Usually, on Linux, VIP are using /32 to avoid issues with source address
selection. Notably, when contacting a peer, the VIP could be selected
when using a /29, while this is not possible when using a /32.


I just tested your theory, used this in the config:

  virtual_ipaddress {
185.15.57.9/32 dev eno2.2107
208.80.153.190/32 dev eno2.2120
  }

Downgraded to the Bullseye version, but keepalived fails with the same 
error:


aborrero@cloudgw2001-dev:~ $ sudo /usr/sbin/keepalived -lD --dont-fork
Tue Apr  5 08:14:32 2022: Starting Keepalived v2.1.5 (07/13,2020)
Tue Apr  5 08:14:32 2022: WARNING - keepalived was build for newer Linux 
5.10.70, running on Linux 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 
(2022-03-07)
Tue Apr  5 08:14:32 2022: Command line: '/usr/sbin/keepalived' '-lD' 
'--dont-fork'

Tue Apr  5 08:14:32 2022: Opening file '/etc/keepalived/keepalived.conf'.
Tue Apr  5 08:14:32 2022: NOTICE: setting config option 
max_auto_priority should result in better keepalived performance

Tue Apr  5 08:14:32 2022: Starting VRRP child process, pid=1571242
Tue Apr  5 08:14:32 2022: Registering Kernel netlink reflector
Tue Apr  5 08:14:32 2022: Registering Kernel netlink command channel
Tue Apr  5 08:14:32 2022: Opening file '/etc/keepalived/keepalived.conf'.
Tue Apr  5 08:14:32 2022: (/etc/keepalived/keepalived.conf: Line 25) 
Warning - cannot track route 185.15.57.0/29 with no interface specified, 
not tracking
Tue Apr  5 08:14:32 2022: (/etc/keepalived/keepalived.conf: Line 26) 
Warning - cannot track route 172.16.128.0/24 with no interface 
specified, not tracking
Tue Apr  5 08:14:32 2022: Assigned address 208.80.153.188 for interface 
eno2.2120
Tue Apr  5 08:14:32 2022: Assigned address fe80::32e1:71ff:fe60:e97d for 
interface eno2.2120

Tue Apr  5 08:14:32 2022: Registering gratuitous ARP shared channel
Tue Apr  5 08:14:32 2022: (VRRP1) removing Virtual Routes
Tue Apr  5 08:14:32 2022: (VRRP1) removing VIPs.
Tue Apr  5 08:14:32 2022: bind unicast_src 208.80.153.188 failed 99 - 
Cannot assign requested address
Tue Apr  5 08:14:32 2022: (VRRP1): entering FAULT state (src address not 
configured)

Tue Apr  5 08:14:32 2022: (VRRP1) Entering FAULT STATE
Tue Apr  5 08:14:32 2022: (VRRP1) removing Virtual Routes
Tue Apr  5 08:14:32 2022: VRRP sockpool: [ifindex(  8), family(IPv4), 
proto(112), fd(-1,-1), unicast, address(208.80.153.188)]

^CTue Apr  5 08:14:36 2022: Stopping
Tue Apr  5 08:14:37 2022: Stopped - used 0.001718 user time, 0.00 
system time
Tue Apr  5 08:14:37 2022: CPU usage (self/children) user: 
0.006457/0.003166 system: 0.006457/0.00

Tue Apr  5 08:14:37 2022: Stopped Keepalived v2.1.5 (07/13,2020)

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Arturo Borrero Gonzalez]

On Thu, 24 Mar 2022 18:03:29 +0100 Vincent Bernat  wrote:
> Unfortunately, I don't think it's worth reporting the issue upstream
> as they don't like us lagging > so many versions late.

Agreed.


After looking twice, I notice the VIP is in the same subnet as the peer.
If you don't have any other address on the subnet, I don't see how this
could work. If you have, maybe it would be better to use a /32 for the
VIP.


Would you mind to elaborate?

The setup is as follows:

* peer 1, local IP 208.80.153.188/29
* peer 2, local IP 208.80.153.189/29
* VIP 208.80.153.190/29

I honestly don't know how this relates to the execution error itself. Do 
you think the address assignment fails because some misconfigured netmask?

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Arturo Borrero Gonzalez]

Package: keepalived
Version: 1:2.1.5-0.2+deb11u1
Severity: grave
Tags: upstream
X-Debbugs-Cc: art...@debian.org

Dear maintainer,

thanks for your work with this package, really appreciated.

Today I tried upgrading a Debian 10 Buster system to Debian 11 Bullseye.

Keepalived refused to work with a previously working setup, error message:

=== 8< ===
aborrero@cloudgw2001-dev:~ $ sudo /usr/sbin/keepalived -lD --dont-fork
Thu Mar 24 15:59:24 2022: Starting Keepalived v2.1.5 (07/13,2020)
Thu Mar 24 15:59:24 2022: WARNING - keepalived was build for newer Linux 
5.10.70, running on Linux 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07)
Thu Mar 24 15:59:24 2022: Command line: '/usr/sbin/keepalived' '-lD' 
'--dont-fork'
Thu Mar 24 15:59:24 2022: Opening file '/etc/keepalived/keepalived.conf'.
Thu Mar 24 15:59:24 2022: NOTICE: setting config option max_auto_priority 
should result in better keepalived performance
Thu Mar 24 15:59:24 2022: Starting VRRP child process, pid=17238
Thu Mar 24 15:59:24 2022: Registering Kernel netlink reflector
Thu Mar 24 15:59:24 2022: Registering Kernel netlink command channel
Thu Mar 24 15:59:24 2022: Opening file '/etc/keepalived/keepalived.conf'.
Thu Mar 24 15:59:24 2022: (/etc/keepalived/keepalived.conf: Line 25) Warning - 
cannot track route 185.15.57.0/29 with no interface specified, not tracking
Thu Mar 24 15:59:24 2022: (/etc/keepalived/keepalived.conf: Line 26) Warning - 
cannot track route 172.16.128.0/24 with no interface specified, not tracking
Thu Mar 24 15:59:24 2022: Assigned address 208.80.153.188 for interface 
eno2.2120
Thu Mar 24 15:59:24 2022: Assigned address fe80::32e1:71ff:fe60:e97d for 
interface eno2.2120
Thu Mar 24 15:59:24 2022: Registering gratuitous ARP shared channel
Thu Mar 24 15:59:24 2022: (VRRP1) removing Virtual Routes
Thu Mar 24 15:59:24 2022: (VRRP1) removing VIPs.
Thu Mar 24 15:59:24 2022: bind unicast_src 208.80.153.188 failed 99 - Cannot 
assign requested address
Thu Mar 24 15:59:24 2022: (VRRP1): entering FAULT state (src address not 
configured)
Thu Mar 24 15:59:24 2022: (VRRP1) Entering FAULT STATE
Thu Mar 24 15:59:24 2022: (VRRP1) removing Virtual Routes
Thu Mar 24 15:59:24 2022: VRRP sockpool: [ifindex(  8), family(IPv4), 
proto(112), fd(-1,-1), unicast, address(208.80.153.188)]
^CThu Mar 24 16:00:05 2022: Stopping
Thu Mar 24 16:00:06 2022: Stopped - used 0.002007 user time, 0.00 system 
time
Thu Mar 24 16:00:06 2022: CPU usage (self/children) user: 0.008240/0.003615 
system: 0.004120/0.00
Thu Mar 24 16:00:06 2022: Stopped Keepalived v2.1.5 (07/13,2020)
=== 8< ===

The config file is pretty straigt forward:

=== 8< ===
aborrero@cloudgw2001-dev:~ $ cat /etc/keepalived/keepalived.conf
global_defs {
}

vrrp_instance VRRP1 {
  state BACKUP
  interface eno2.2120
  virtual_router_id 52
  nopreempt
  priority 6
  advert_int 1
  authentication {
auth_type PASS
auth_pass 
  }
  track_interface {
eno2.2107
  }
  virtual_routes {
185.15.57.0/29 table 10 nexthop via 185.15.57.10 dev eno2.2107 onlink
172.16.128.0/24 table 10 nexthop via 185.15.57.10 dev eno2.2107 onlink
  }
  virtual_ipaddress {
185.15.57.9/30 dev eno2.2107
208.80.153.190/29 dev eno2.2120
  }
  unicast_peer {
208.80.153.189
  }
}
=== 8< ===

This exact same setup was previously working, and actually, the next version 
works just fine.
Not sure if this has anything to do with the kernel version warning at the 
beginning.

In summary:

| keepalived version  | Debian   | Works? |
| |--||
| 1:2.0.10-1  | buster   | yes|
| 1:2.1.5-0.2+deb11u1 | bullseye | no |
| 1:2.2.7-1~bpo11+1   | bullseye-bpo | yes|

I'm opeining this bug report mostly so others can find it.
Raelly appreciated the bpo package is ready to use.

regards.

Bug#994034: (no subject)

[Arturo Borrero Gonzalez]

On Sat, 11 Sep 2021 11:29:16 +0200 Johannes Schauer Marin Rodrigues 
 wrote:

If you want to use sbuild with the schroot backend, I think your easiest option
is to run sbuild like everybody else does: with the same user inside and
outside the chroot, running sbuild as that user.

If you somehow cannot do that, feel free to supply a patch to sbuild that
allows for your setup to work.

I do want to run sbuild with the same user inside/outside the chroot, but sbuild 
ignores it.


The system is configured to use LDAP users. There is no reason for sbuild to 
ignore that and create arbitrary local users inside the schroot (if that's what 
is happening anyway).


Perhaps you only read the email about using sudo and not the rest of the report? 
 I mean, specifically, the nsswitch.conf diff inside/outside the chroot.


regards.

Bug#994034: (no subject)

[Arturo Borrero Gonzalez]

Another additional hint.

If I run sbuild as root (i.e, sudo sbuild [..]) then the bug isn't triggered.

This may be obvious, but wanted to share the info anyway.

Bug#994034: nsswitch.conf difference

[Arturo Borrero Gonzalez]

Per lechner suggestion at #debian-devel @ IRC, let me share here a potential 
root cause for this issue.


The nsswitch.conf file is different inside/outside the schroot:

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
cat /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files
group:  files
shadow: files
gshadow:files

hosts:  files dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis


aborrero@tools-package-builder-04:~$ cat /etc/nsswitch.conf
passwd: files sss
group:  files sss
shadow: files sss

hosts:  files dns
networks:   files

protocols:  db files
services:   db files sss
ethers: db files
rpc:db files

netgroup:   sss
sudoers:files sss
automount:  files sss

Bug#994034: bug 994034 potential workaround

[Arturo Borrero Gonzalez]

I found a potential workaround.

* inside the schroot I deleted the local user defined as 'aborrero'
* then chown the build dir to uid/gid from outside the schroot

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
ls -la

total 320
drwxr-x--- 4119 sbuild   4096 Sep 10 10:09 .
drwxrws--- 3 sbuild sbuild   4096 Sep 10 10:08 ..
drwxr-x--- 6119 sbuild   4096 Sep 10 10:08 resolver-CXim0X
drwxr-xr-x 9  18194500   4096 Sep 10 10:09 toollabs-webservice-0.76
-rw-r--r-- 1119 sbuild642 Sep 10 10:08 toollabs-webservice_0.76.dsc
-rw-r--r-- 1119 sbuild 307011 Sep 10 10:08 toollabs-webservice_0.76.tar.gz

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
chown -R 18194:500 .


(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
ls -la

total 320
drwxr-x--- 4  18194500   4096 Sep 10 10:09 .
drwxrws--- 3 sbuild sbuild   4096 Sep 10 10:08 ..
drwxr-x--- 6  18194500   4096 Sep 10 10:08 resolver-CXim0X
drwxr-xr-x 9  18194500   4096 Sep 10 10:09 toollabs-webservice-0.76
-rw-r--r-- 1  18194500642 Sep 10 10:08 toollabs-webservice_0.76.dsc
-rw-r--r-- 1  18194500 307011 Sep 10 10:08 toollabs-webservice_0.76.tar.gz

Then the build works as expected:

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
cd toollabs-webservice-0.76/


(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY/toollabs-webservice-0.76# 
 dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot

[..]
dpkg-deb: building package 'toollabs-webservice' in 
'../toollabs-webservice_0.76_all.deb'.

 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../toollabs-webservice_0.76_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY/toollabs-webservice-0.76# 
ls -l ..

total 356
drwxr-x--- 6 18194  500   4096 Sep 10 10:08 resolver-CXim0X
drwxr-xr-x 9 18194  500   4096 Sep 10 11:11 toollabs-webservice-0.76
-rw-r--r-- 1 18194  500642 Sep 10 10:08 toollabs-webservice_0.76.dsc
-rw-r--r-- 1 18194  500 307011 Sep 10 10:08 toollabs-webservice_0.76.tar.gz
-rw-r--r-- 1 root  RoOT  28968 Sep 10 11:11 toollabs-webservice_0.76_all.deb
-rw-r--r-- 1 root  RoOT   5480 Sep 10 11:11 
toollabs-webservice_0.76_amd64.buildinfo
-rw-r--r-- 1 root  RoOT   1085 Sep 10 11:11 
toollabs-webservice_0.76_amd64.changes

Or, is this working because I run dpkg-buildpackage as root inside the chroot? 
Anyway I'm not sure I understand that detail about sbuild/schroot:


(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
id aborrero

id: ‘aborrero’: no such user

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY# 
su aborrero
su: user aborrero does not exist or the user entry does not contain all the 
required fields

Bug#994034: dpkg-deb call fails with permission error if user comes from LDAP

[Arturo Borrero Gonzalez]

Package: sbuild
Version: 0.81.2
Severity: important
Tags: upstream

Dear maintainers, thanks for your hard work with this amazing tool.

We're experimenting a problem with our sbuild deployment. I'm not even sure the 
problem is with
sbuild itself, or shcroot, or what. Anyway, let me try explaining the setup.

* we have a separated virtual machine where we collectively build debian 
packages using sbuild.
* the virtual machine uses LDAP for users with sssd as client stack, our users 
are defined in LDAP.
* we maintain a bunch of schroots for the package builds (basically, one for 
each debian release)

A normal operation would be:

* log into the VM via SSH
* go to a directory in the VM filesystem where a debian source package lives
* run sbuild, usual cmdline is something like: sbuild -v -A -d bullseye 
--no-clean-source
* the package builds normally, but in the final stage the dpkg-deb call fails

I think the relevant part of the log is this:

=== 8< ===
[..]
   dh_gencontrol -O--buildsystem=pybuild
   dh_md5sums -O--buildsystem=pybuild
   dh_builddeb -O--buildsystem=pybuild
dpkg-deb: building package 'toollabs-webservice' in 
'../toollabs-webservice_0.76_all.deb'.
dpkg-deb: error: unable to create '../toollabs-webservice_0.76_all.deb': 
Permission denied
dh_builddeb: error: dpkg-deb --build debian/toollabs-webservice .. returned 
exit code 2
dh_builddeb: error: Aborting due to earlier error
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2

Build finished at 2021-09-10T10:04:15Z

=== 8< ===

I logged it to the schroot after this error with --build-failed-commands 
'%SBUILD_SHELL' to
investigate a bit more, and I see this:

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY#
 ls -la 
total 320
drwxr-x--- 4 aborrero sbuild   4096 Sep 10 10:09 .
drwxrws--- 3 sbuild   sbuild   4096 Sep 10 10:08 ..
drwxr-x--- 6 aborrero sbuild   4096 Sep 10 10:08 resolver-CXim0X
drwxr-xr-x 918194500   4096 Sep 10 10:09 toollabs-webservice-0.76
-rw-r--r-- 1 aborrero sbuild642 Sep 10 10:08 toollabs-webservice_0.76.dsc
-rw-r--r-- 1 aborrero sbuild 307011 Sep 10 10:08 toollabs-webservice_0.76.tar.gz

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY#
 ls -lna
total 320
drwxr-x--- 4   119 123   4096 Sep 10 10:09 .
drwxrws--- 3   117 123   4096 Sep 10 10:08 ..
drwxr-x--- 6   119 123   4096 Sep 10 10:08 resolver-CXim0X
drwxr-xr-x 9 18194 500   4096 Sep 10 10:09 toollabs-webservice-0.76
-rw-r--r-- 1   119 123642 Sep 10 10:08 toollabs-webservice_0.76.dsc
-rw-r--r-- 1   119 123 307011 Sep 10 10:08 toollabs-webservice_0.76.tar.gz

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY#
 id 119
uid=119(aborrero) gid=123(sbuild) groups=123(sbuild)

(bullseye-amd64-sbuild)root@tools-package-builder-04:/build/toollabs-webservice-Oe7KMY#
 grep sbuild /etc/group 
sbuild:x:123:aborrero

Additionally, some information from outside the schroot:

aborrero@tools-package-builder-04:~$ id sbuild
uid=117(sbuild) gid=123(sbuild) groups=123(sbuild)

aborrero@tools-package-builder-04:~$ id
uid=18194(aborrero) gid=500(wikidev) groups=123(sbuild),[.. many more ..]

aborrero@tools-package-builder-04:~$ grep aborrero /etc/group
sbuild:x:123:aborrero

aborrero@tools-package-builder-04:~$ id 119
id: ‘119’: no such user

You can see there is something wrong somewhere. My user is uid 18194 outside 
the schroot (defined
in LDAP) but inside the schroot is 119 (likely statically defined inside the 
schroot).
It seems the mapping between the real user (from the VM, defined in LDAP) and 
the transient user
inside the schroot is not working well.

Please don't hesitate to request more information if required.

regards.

Bug#991309: suggested fix

[Arturo Borrero Gonzalez]

On Tue, 20 Jul 2021 14:28:31 +0200 Christian Ehrhardt 
 wrote:

Since there is no branch from debian/0.9.8-3 yet to propose against
here a suggested fix as a debdiff.



Thanks for the detailed bug report and the debdiff!

Unfortunately I wont be able to handle this until September because summer 
vacations.


In particular, I wont have the time to follow all the procedures to get this 
accepted into testing/stable at this point. If I do the upload without double 
checking all the docs first there are high chances that the update is rejected.


However, I understand the timing thing. If you still want me to do this on 5 
minutes that I can find in front of the laptop I would need a deadsimple 
copy-paste list of steps I need to do in order to upload the package and ask for 
the required permissions. Even with this, I can't promise anything.

Bug#989431: nftables runs to early at system boot

[Arturo Borrero Gonzalez]

On 6/3/21 5:26 PM, F.Stoyan wrote:


nftables runs to early at system boot. At this time not all interfaces are 
available:

# journalctl -b -3 --unit=systemd-networkd.service --unit=nftables.service 
--no-hostname
-- Journal begins at Fri 2021-05-28 15:13:07 CEST, ends at Thu 2021-06-03 
17:08:05 CEST. --
Jun 03 15:18:23 nft[414]: /etc/nftables.conf:12:21-31: Error: Interface does 
not exist
Jun 03 15:18:23 nft[414]: define SSID-MEDIA = enp1s0f0.66
Jun 03 15:18:23 nft[414]: ^^^
Jun 03 15:18:23 nft[414]: /etc/nftables.conf:11:21-31: Error: Interface does 
not exist
Jun 03 15:18:23 nft[414]: define SSID-LABOR = enp1s0f0.65
Jun 03 15:18:23 nft[414]: ^^^


I guess you are using interface index in your ruleset, rather than interface 
names. If you use interface name (i.e, iffname oifname etc) then the interface 
don't need to exist when loading the ruleset.


Loading the ruleset *before* the interfaces are up ensures that no network 
traffic bypass the firewall policy.


Is up to you to configure the systemd unit to load before/after the network.

Bug#987773: enable netfilter modules

[Arturo Borrero Gonzalez]

Sorry for the noise!

Bug#987773: enable netfilter modules

[Arturo Borrero Gonzalez]

Source: linux
Severity: normal

Dear maintainers,

thanks for your hard work with this package, it is really appreciated.

I noticed today the following missing netfilter modules in the kernel
from testing/sid (by the time of this writing same version in both):

=== 8< ===
arturo@endurance:~ $ grep NETFILTER_EGRESS /boot/config-5.10.0-6-amd64 
arturo@endurance:~ $ grep NETFILTER_XT_TARGET_NOTRACK 
/boot/config-5.10.0-6-amd64 
# CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set
=== 8< ===

I think CONFIG_NETFILTER_EGRESS is newer, but should be available since 5.7, in
upstream commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8537f78647c072bdb1a5dbe32e1c7e5b13ff1258

regards.

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#987152: ITP: python3-absl -- Google's library for building Python applications

[Arturo Borrero Gonzalez]

On 4/18/21 3:32 PM, Arturo Borrero Gonzalez wrote:

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 
X-Debbugs-Cc: debian-de...@lists.debian.org



Initial packaging:

https://salsa.debian.org/debian/pkg-python-absl

Bug#987004: (no subject)

[Arturo Borrero Gonzalez]

Initial packaging:

https://salsa.debian.org/debian/pkg-capirca/

Bug#987152: ITP: python3-absl -- Google's library for building Python applications

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python3-absl
  Version : 0.12.0
  Upstream Author : Google Inc
* URL : https://github.com/abseil/abseil-py
* License : Apache 2.0
  Programming Lang: Python
  Description : Google's library for building Python applications

 A collection of Python library code for building Python applications. The
 code is collected from Google's own Python code base, and has been
 extensively tested and used in production. Some features include:

 * Simple application startup

 * Distributed commandline flags system

 * Custom logging module with additional features

 * Testing utilities

This is a dependency for capirca.

Bug#987004: RFP: capirca -- Multi-platform ACL generation system

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist

* Package name: capirca
  Version : 2.0.3
  Upstream Author : Google
* URL : https://github.com/google/capirca
* License : Apache 2.0
  Programming Lang: Python
  Description : Multi-platform ACL generation system

Capirca is a designed to utilize common definitions of networks, services and 
high-level policy
files to facilitate the development and manipulation of network access control 
lists (ACLs) for
various platforms. It was developed by Google for internal use, and is now open 
source.

Capirca consists of capirca Python package and the accompanying aclgen tool.

Bug#985498: missing dependency on cpp

[Arturo Borrero Gonzalez]

On Fri, 19 Mar 2021 11:09:08 +0100 Arturo Borrero Gonzalez  
wrote:

The fix is rather simple: add cpp as Depends for gridengine-common.

I'll send a patch/pull request to the salsa repository soon.




Pull request:

https://salsa.debian.org/hpc-team/gridengine/-/merge_requests/2

Patch also included here for reference:

=== 8< ===
commit 97af886c1e106fe2161d0a704b3e6749323dfb0a (HEAD -> master, origin/master, 
origin/HEAD)

Author: Arturo Borrero Gonzalez 
Date:   Fri Mar 19 11:03:20 2021 +0100

gridengine-common: depends on cpp

The script /usr/share/gridengine/util/arch calls /usr/bin/cpp on line 203.

Introduce corresponding dependency.

Closes: #985498
Signed-off-by: Arturo Borrero Gonzalez 

diff --git a/debian/control b/debian/control
index 8252bc8b3..d9d9a7fa6 100644
--- a/debian/control
+++ b/debian/control
@@ -39,6 +39,7 @@ Depends:
${misc:Depends},
adduser,
bsd-mailx | mailx,
+   cpp,
ucf,
tcsh | c-shell,
 Suggests:
=== 8< ===

regards.
--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation

Bug#985498: missing dependency on cpp

[Arturo Borrero Gonzalez]

Package: gridengine-common
Version: 8.1.9+dfsg-4+deb9u2
Severity: serious
Tags: patch

Dear gridengine maintaners,

thanks for your work on this package, it is really appreciated.

I detected the script /usr/share/gridengine/util/arch calls /usr/bin/cpp on 
line 203:

=== 8< ===
   x86_64)
  if /usr/bin/cpp -dM 

Bug#982576: update

[Arturo Borrero Gonzalez]

Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1500
Control tags -1 upstream

Bug#981857: update

[Arturo Borrero Gonzalez]

Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1499
Control: tags -1 upstream

Bug#970672: update

[Arturo Borrero Gonzalez]

Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1501
Control: tags -1 upstream

Bug#982576: (no subject)

[Arturo Borrero Gonzalez]

Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1500
Control tags -1 upstream

Bug#981857: (no subject)

[Arturo Borrero Gonzalez]

Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1499
Control: tags -1 upstream

Bug#979869: Fixed with xfce4 v1.16

[Arturo Borrero Gonzalez]

The problem dissappeared when switched to xfce4 v1.16 (from 1.14).

Closing bug.

Bug#981641: FTBFS with an xsltproc error

[Arturo Borrero Gonzalez]

On 2/2/21 5:21 PM, Helmut Grohne wrote:

On Tue, Feb 02, 2021 at 04:25:36PM +0100, Arturo Borrero Gonzalez wrote:

I suspect this might be related to this recent change:

https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4eb323698ee7d8e50132fb271c0f3aa92c727285

Could you please check if introducing back docbook-xsl as build-dep fixes the 
issue?


Mea culpa. 


np! :-)

I'm just uploading a new version of nftables, hopefully fixing the issue.



Of course, that would get us a bigger dependency tree than before.
Quite the opposite of what I wanted to achieve. It would be one with
fewer surprises though. What do you think?

Adding the asciidoc maintainer to Cc.



I don't have a strong opinion. But yes, apparently it feels like it would make 
sense.

Bug#981641: FTBFS with an xsltproc error

[Arturo Borrero Gonzalez]

On 2/2/21 2:36 PM, Michael Biebl wrote:

Source: nftables
Version: 0.9.8-2
Severity: serious

Hi,

trying to rebuild nftables on sid, I ran into a failure:

make[3]: Entering directory '/build/nftables-0.9.8/doc'
a2x -L --doctype manpage --format manpage -D . nft.txt
a2x -L --doctype manpage --format manpage -D . libnftables-json.adoc
a2x -L --doctype manpage --format manpage -D . libnftables.adoc
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam navig.graphics 0 
--stringparam admon.textlabel 1 --stringparam admon.graphics 0  
"/etc/asciidoc/docbook-xsl/manpage.xsl" "/build/nftables-0.9.8/doc/libnftables.xml" 
returned non-zero exit status 5

make[3]: *** [Makefile:642: libnftables.3] Error 1
make[3]: *** Waiting for unfinished jobs
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam navig.graphics 0 
--stringparam admon.textlabel 1 --stringparam admon.graphics 0  
"/etc/asciidoc/docbook-xsl/manpage.xsl" "/build/nftables-0.9.8/doc/libnftables-json.xml" 
returned non-zero exit status 5

make[3]: *** [Makefile:645: libnftables-json.5] Error 1
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam navig.graphics 0 
--stringparam admon.textlabel 1 --stringparam admon.graphics 0  
"/etc/asciidoc/docbook-xsl/manpage.xsl" "/build/nftables-0.9.8/doc/nft.xml" returned 
non-zero exit status 5

make[3]: *** [Makefile:639: nft.8] Error 1
make[3]: Leaving directory '/build/nftables-0.9.8/doc'
make[2]: *** [Makefile:481: all-recursive] Error 1
make[2]: Leaving directory '/build/nftables-0.9.8'
make[1]: *** [Makefile:390: all] Error 2
make[1]: Leaving directory '/build/nftables-0.9.8'
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:15: build] Error 25


Looking at https://buildd.debian.org/status/package.php?p=nftables, this
also happened on a few buildds.
In my case it happened for amd64. I suspect there was a recent change in
the xsltproc toolchain.




Hi there,

thanks for the report.

I suspect this might be related to this recent change:

https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4eb323698ee7d8e50132fb271c0f3aa92c727285

Could you please check if introducing back docbook-xsl as build-dep fixes the 
issue?

I might have my local sbuild chroot polluted somehow, I cannot reproduce the 
issue.

CC'ing change author Helmut Grohne 

Bug#931820: (no subject)

[Arturo Borrero Gonzalez]

Control: fixed -1 0.9.2-1

Bug#979869: doesn't start on system startup when using XFCE4

[Arturo Borrero Gonzalez]

Package: xscreensaver
Version: 5.45+dfsg1-1
Severity: important

Hi there,

thanks for your work maintaining the xscreensaver package, it is really 
appreciated.

A recent update of xscreensaver somehow broke the integration with XFCE4 in the 
sense that the
daemon no longer starts on system startup. I can reproduce this every time I 
boot my laptop and
starts the user session in XFCE4.

How to reproduce:
 1) start the machine (XFCE4, lightdm, xscreensaver)
 2) start XFCE4 user session
 3) try to lock the screen by launching xscreensaver (CTRL+ALT+DEL)
 4) nothing happens
 5) open the 'Screensaver' XFCE4 configuration menu
 6) it warns that the xscreensaver daemon is not running, offers to start it 
now, click YES.
 7) the xscreensaver daemon is now running, back to 3), it works now!

I tried to force xscreensaver daemon run by adding it to the 'application 
autostart' in the
XFCE4 'session and startup' menu, but the reproducer is exactly the same.

>From my experience this is a regression, since previous version (in 
>bullseye/testing) didn't have
this behavior.

regards.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.60
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcrypt11:4.4.17-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk2.0-0  2.24.33-1
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.46.2-3
ii  libsystemd0  247.2-4
ii  libx11-6 2:1.6.12-1
ii  libxext6 2:1.3.3-1.1
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.45+dfsg1-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:2.0.5-2
ii  perl  5.32.0-6
ii  wamerican [wordlist]  2019.10.06-1
ii  xfonts-100dpi 1:1.0.4+nmu1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser] 83.0.4103.116-3.1+b1
ii  firefox-esr [www-browser]  78.6.0esr-1
pn  fortune
pn  gdm3 | kdm-gdmcompat   
ii  hv3 [www-browser]  3.0~fossil20110109-8
pn  qcam | streamer
pn  xdaliclock 
pn  xfishtank  
pn  xscreensaver-data-extra
pn  xscreensaver-gl
pn  xscreensaver-gl-extra  

-- no debconf information

Bug#979103: Legally problematic GPL-3+ readline dependency

[Arturo Borrero Gonzalez]

On 1/2/21 6:49 PM, Bastian Germann wrote:

Package: nftables
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According to 
debian/copyright parts of your package are GPL-2-only licensed. If that is also 
(transitively) the case for the binaries that link with libreadline.so.8 it 
might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ licensed older 
version. However, that is orphaned in Debian, so libeditreadline-dev should be 
preferred, which does not compile with your package without any patch. It links 
with the BSD-licensed libedit library which is a readline replacement.




Thanks for the heads up.

I started a conversation upstream, let's see what happens there first.

Bug#975961: override: iptables:net/optional, nftables:net/important

[Arturo Borrero Gonzalez]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-b...@lists.debian.org

It was discussed and decided last year [0][1] to change the priority of both 
packages.

In the case of iptables:
 * from priority important
 * to priority optional

In the case of nftables:
 * from priority optional
 * to priority important

The changes are already present in the packages d/control files, and has been 
for a while.

thanks, regards.

[0] https://lists.debian.org/debian-devel/2019/07/msg00332.html
[1] https://ral-arturo.org/2019/10/14/debian-netfilter.html

Bug#910000: [pkg-netfilter-team] Adopting xtables-addons

[Arturo Borrero Gonzalez]

On 2020-10-19 09:53, Jeremy Sowden wrote:
> On 2020-09-06, at 09:51:22 +0100, Jeremy Sowden wrote:
>> On 2020-08-26, at 11:21:23 +0200, Arturo Borrero Gonzalez wrote:
>>> On Sat, 8 Aug 2020 11:20:40 +0100 Jeremy Sowden wrote:
>>>> There is a RFA bug for xtables-addons (cc'ed):
>>>>
>>>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=91
>>>>
>>>> I was thinking about offering to adopt the package, but I'm still
>>>> a bit of a novice at maintaining packages in Debian, so although
>>>> it's fairly stable and doesn't see a lot of activity upstream, it
>>>> occurred to me that it might make more sense for it to be adopted
>>>> by the Netfilter team and to offer to help out in that context.
>>>>
>>>> Does this seem like a good idea?  Shall I add it to
>>>> https://wiki.debian.org/Teams/pkg-netfilter/tasks?
>>>
>>> Please go ahead.
>>>
>>> I just created this in the wiki:
>>>
>>> https://wiki.debian.org/Teams/pkg-netfilter/tasks#Task:_xtables-addons_refresh
>>
>> Thanks!  You got my surname wrong, btw: right letters, wrong order. :)
>>

Fixed!

>> I've pushed a lot of changes, including work to package the latest
>> upstream release, to my fork of the old Salsa repo:
>>
>>   https://salsa.debian.org/azazel/xtables-addons
>>
>> What is the next step towards getting it into the new repo?
> 
> Please forgive the gentle nudge, but some feedback would be appreciated.
> 

Sorry for the delay.

I just invited you to be a maintainer in the
https://salsa.debian.org/pkg-netfilter-team/pkg-xtables-addons repository.

Ping me if you find you don't have permissions for something.

Once you are happy with the package code, feel free to push the code to the
pkg-netfilter-team repo and start using in from that moment onwards.

All links in files in the debian/ dir should point to this pkg-netfilter-team
repo (i.e, VCS-* etc). Please also use the common maintainer address like in any
other package in the team.

Unrelated to your package, we would eventually need to move to a more modern
approach for the Maintainer: address, probably using the tracker.d.o address. I
didn't pay enough attention to this and I'm not sure what is the right path.

regards.



signature.asc
Description: OpenPGP digital signature

Bug#970672: nftables dnat port range

[Arturo Borrero Gonzalez]

On 2020-09-21 11:12, Igor M wrote:
> apt search -t testing nftables
> ...
> nftables/testing,unstable 0.9.6-1 amd64 [upgradable from: 0.9.0-2]
> 
> did you mean this version?
> 

Yes, or even better:

 buster-backports: 0.9.6-1~bpo10+1

Bug#970672: nftables dnat port range

[Arturo Borrero Gonzalez]

On 2020-09-21 10:40, Igor M wrote:
> 
> Package: nftables
> Version: 0.9.0-2
> 

Please try a newer release of the nftables package.

regards.

Bug#969058: iptables in buster-backports requires netbase >= 6.0 which is not present in archive

[Arturo Borrero Gonzalez]

On Fri, 28 Aug 2020 07:54:38 +0100 r...@synca.io wrote:
> Hi
> 
> > I just uploaded netbase 6.1~bpo10+1 to buster-backports.
> 
> it still doesnt appear to be there.

As of this writing, the package is waiting in the NEW queue before entering the
archive:

https://ftp-master.debian.org/new/netbase_6.1~bpo10+1.html

> 
> this bug utterly hosed the systems i am working on (fortunately a dev 
> network)

If in a rush, one could simply install netbase from testing. It should be a
simple operation.

> 
> imho this bug needs to be triaged as grave/critical and some kind of 
> post-mortem should happen
> 
> im actually speechless that you can release a package in an official 
> debian repository with a failing dependency like this, without any kind 
> of ci stopping you.
> 

This costs thousand of €€€ (EURs) in engineering time. Would you volunteer to do
all the work you are suggesting should be done? Or fund with money for other
folks to do so?

Please, be mindful, Debian is a community project. People do work here mostly on
a volunteer capacity. While I may understand your frustration, this kind of
yelling you are doing might destroy people's motivation in communities.

Ping me offline if you are willing to contribute with your time or money to the
project, I will gladly give you a few pointers :-)

Bug#969058: iptables in buster-backports requires netbase >= 6.0 which is not present in archive

[Arturo Borrero Gonzalez]

Control: forcemerge -1 969020

On Wed, 26 Aug 2020 20:12:15 + Johan Fleury  wrote:
> Package: iptables
> Version: 1.8.5-3~bpo10+1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Commit d7ad2173[^1] was backported into the debian/buster-backports
> branch and the iptables package version 1.8.5-3~bpo10+1 was pushed to
> the buster-backports archive yesterday[^2], but netbase is not present
> in version >=6.0 in the archive.

I just uploaded netbase 6.1~bpo10+1 to buster-backports.
This should fix the problem.

Thanks for reporting!

> 
> This makes `iptables` un-upgradable on my system, and even worse, it
> lead to it being removed an I cannot install it anymore:

this is because the apt pin config you have for the package... The config tells
apt to only install the package from buster-bpo, but that package is
uninstallable, therefore the deadlock.

Bug#969020: [pkg-netfilter-team] Bug#969020: iptables: Broken dependency on netbase (>=6.0) in buster-backports, only 5.6 is available

[Arturo Borrero Gonzalez]

Control: forcermge -1 969058

Bug#910000: Adopting xtables-addons

[Arturo Borrero Gonzalez]

On Sat, 8 Aug 2020 11:20:40 +0100 Jeremy Sowden  wrote:
> There is a RFA bug for xtables-addons (cc'ed):
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=91
> 
> I was thinking about offering to adopt the package, but I'm still a bit
> of a novice at maintaining packages in Debian, so although it's fairly
> stable and doesn't see a lot of activity upstream, it occurred to me
> that it might make more sense for it to be adopted by the Netfilter team
> and to offer to help out in that context.
> 
> Does this seem like a good idea?  Shall I add it to
> https://wiki.debian.org/Teams/pkg-netfilter/tasks?
> 

Please go ahead.

I just created this in the wiki:

https://wiki.debian.org/Teams/pkg-netfilter/tasks#Task:_xtables-addons_refresh

regards.

Bug#965021: adjust severity

[Arturo Borrero Gonzalez]

control: severity -1 important

This is a bug in a particular option of the software. I'm therefore reducing the
bug severity.

Bug#885265: [py3] some fixes to get chirpw running with python3, Fixes #7431

[Arturo Borrero Gonzalez]

Hi there!

I tested chirp from the upstream mercurial repository (py3 branch) today in
Debian testing bullseye, and I got it working with python3 with the attached 
patch.

I was able to download the image from a baofeng UV-5RA, modify it and the upload
it again.

Please, consider merging the attached patch. If the patch requires any mangling
please do so yourself, I'm on vacations and I don't plan to follow-up on this.

regards.
# HG changeset patch
# User Arturo Borrero Gonzalez 
# Date 1596733882 -7200
#  Thu Aug 06 19:11:22 2020 +0200
# Branch py3
# Node ID 16906193cd4089786be642ce0af684a72e29cae9
# Parent  68534f20c1418ae8e4cc09f3ff468d0375ba843a
[py3] some fixes to get chirpw running with python3, Fixes #7431

This patch contains a couple of small changes to get chirpw running with
python3.

Signed-off-by: Arturo Borrero Gonzalez 

diff -r 68534f20c141 -r 16906193cd40 chirp/drivers/uv5r.py
--- a/chirp/drivers/uv5r.py	Thu Feb 13 16:35:52 2020 -0800
+++ b/chirp/drivers/uv5r.py	Thu Aug 06 19:11:22 2020 +0200
@@ -587,7 +587,7 @@
 data += _read_block(radio, i, 0x40, False)
 
 if append_model:
-data += radio.MODEL.ljust(8)
+data += bytes(radio.MODEL.ljust(8), 'utf-8')
 
 LOG.debug("done.")
 return memmap.MemoryMapBytes(data)
diff -r 68534f20c141 -r 16906193cd40 chirp/drivers/vx6.py
--- a/chirp/drivers/vx6.py	Thu Feb 13 16:35:52 2020 -0800
+++ b/chirp/drivers/vx6.py	Thu Aug 06 19:11:22 2020 +0200
@@ -871,5 +871,5 @@
 elif setting == "password":
 newval = self._encode_chars(newval, 4)
 setattr(_settings, setting, newval)
-except Exception, e:
+except:
 raise
diff -r 68534f20c141 -r 16906193cd40 chirp/ui/mainapp.py
--- a/chirp/ui/mainapp.py	Thu Feb 13 16:35:52 2020 -0800
+++ b/chirp/ui/mainapp.py	Thu Aug 06 19:11:22 2020 +0200
@@ -1137,7 +1137,7 @@
 
 query = "http://chirp.danplanet.com/query/rb/1.0/app_direct; \
 "?loc=%s=%s=%s" % (loc, band, dist)
-print query
+print(query)
 
 # Do this in case the import process is going to take a while
 # to make sure we process events leading up to this

Bug#965021: conntrackd: segfaults when not disabling internal cache

[Arturo Borrero Gonzalez]

Control: tags -1 confirmed upstream
Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1445

On Tue, 14 Jul 2020 17:04:17 +0200 Thomas Schneider
 wrote:
> Package: conntrackd
> Version: 1:1.4.5-2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I’m experiencing a problem with conntrackd.
> 

Thanks for the report. I was able to reproduce the problem.

Hopefully a fix will be available soon.

Bug#914706: [pkg-netfilter-team] Bug#914706: Add 1 more element to a set and you can delete the 1st element

[Arturo Borrero Gonzalez]

Control: fixed -1 0.9.6-1

This should be fixed with nftables 0.9-6 and kernel 5.8.0 (which is about to be
released).

Bug#964014: Update iptables in buster backports to 1.8.5+ ?

[Arturo Borrero Gonzalez]

On Tue, 30 Jun 2020 08:10:49 -0400 Etienne Champetier
 wrote:
> Package: iptables
> Version: 1.8.3-2~bpo10+1
> 
> Hello Debian Netfilter Packaging Team,
> 
> Is it planned to have iptables updated in buster backports to 1.8.5+ ?
> I need it to fix https://bugzilla.netfilter.org/show_bug.cgi?id=1422
> At least the following commit:
> https://git.netfilter.org/iptables/commit/?id=18f01acbdefb211ebfefb728d2b6843c59ae06db
> 

I'm afraid this wont happen soon on my side.

Among other things, we would need to also backport libnftnl first.

Would you be able to contribute or help with this in any way?

Bug#961724: iwlwifi module crash after microcode SW error detected

[Arturo Borrero Gonzalez]

Source: linux
Version: 5.6.7-1
Severity: normal
Tags: upstream

Dear maintainers,

thanks for your hard work with the kerne package, it is really appreciated.

I'll like to report a crash I had today with th iwlwifi module.
Find attached the logs.

This is what lspci has to say about this hardware:

04:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
Subsystem: Intel Corporation Dual Band Wireless-AC 8265
Flags: bus master, fast devsel, latency 0, IRQ 135
Memory at ed10 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 74-e5-f9-ff-ff-3d-52-39
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
May 28 13:38:48 endurance kernel: [ 6464.072219] wlp4s0: cannot understand ECSA 
IE operating class, 6, ignoring
May 28 13:38:48 endurance kernel: [ 6464.174227] wlp4s0: cannot understand ECSA 
IE operating class, 6, ignoring
May 28 13:38:48 endurance kernel: [ 6464.277157] wlp4s0: cannot understand ECSA 
IE operating class, 6, ignoring
May 28 13:38:49 endurance kernel: [ 6464.379115] wlp4s0: cannot understand ECSA 
IE operating class, 6, ignoring
May 28 13:38:49 endurance kernel: [ 6464.475066] iwlwifi :04:00.0: 
Microcode SW error detected.  Restarting 0x200.
May 28 13:38:49 endurance kernel: [ 6464.475287] iwlwifi :04:00.0: Start 
IWL Error Log Dump:
May 28 13:38:49 endurance kernel: [ 6464.475293] iwlwifi :04:00.0: Status: 
0x0040, count: 6
May 28 13:38:49 endurance kernel: [ 6464.475297] iwlwifi :04:00.0: Loaded 
firmware version: 36.8fd77bb3.0 8265-36.ucode
May 28 13:38:49 endurance kernel: [ 6464.475303] iwlwifi :04:00.0: 
0x0039 | BAD_COMMAND 
May 28 13:38:49 endurance kernel: [ 6464.475307] iwlwifi :04:00.0: 
0x0230 | trm_hw_status0
May 28 13:38:49 endurance kernel: [ 6464.475311] iwlwifi :04:00.0: 
0x | trm_hw_status1
May 28 13:38:49 endurance kernel: [ 6464.475315] iwlwifi :04:00.0: 
0x0002486C | branchlink2
May 28 13:38:49 endurance kernel: [ 6464.475318] iwlwifi :04:00.0: 
0x0003A7CE | interruptlink1
May 28 13:38:49 endurance kernel: [ 6464.475322] iwlwifi :04:00.0: 
0x | interruptlink2
May 28 13:38:49 endurance kernel: [ 6464.475325] iwlwifi :04:00.0: 
0x0002 | data1
May 28 13:38:49 endurance kernel: [ 6464.475329] iwlwifi :04:00.0: 
0xDEADBEEF | data2
May 28 13:38:49 endurance kernel: [ 6464.475333] iwlwifi :04:00.0: 
0xDEADBEEF | data3
May 28 13:38:49 endurance kernel: [ 6464.475337] iwlwifi :04:00.0: 
0x19801553 | beacon time
May 28 13:38:49 endurance kernel: [ 6464.475340] iwlwifi :04:00.0: 
0x37E09AB1 | tsf low
May 28 13:38:49 endurance kernel: [ 6464.475344] iwlwifi :04:00.0: 
0x | tsf hi
May 28 13:38:49 endurance kernel: [ 6464.475348] iwlwifi :04:00.0: 
0x | time gp1
May 28 13:38:49 endurance kernel: [ 6464.475352] iwlwifi :04:00.0: 
0x80AF5DFB | time gp2
May 28 13:38:49 endurance kernel: [ 6464.475355] iwlwifi :04:00.0: 
0x0001 | uCode revision type
May 28 13:38:49 endurance kernel: [ 6464.475359] iwlwifi :04:00.0: 
0x0024 | uCode version major
May 28 13:38:49 endurance kernel: [ 6464.475363] iwlwifi :04:00.0: 
0x8FD77BB3 | uCode version minor
May 28 13:38:49 endurance kernel: [ 6464.475366] iwlwifi :04:00.0: 
0x0230 | hw version
May 28 13:38:49 endurance kernel: [ 6464.475370] iwlwifi :04:00.0: 
0x00C89000 | board version
May 28 13:38:49 endurance kernel: [ 6464.475374] iwlwifi :04:00.0: 
0x00D50304 | hcmd
May 28 13:38:49 endurance kernel: [ 6464.475377] iwlwifi :04:00.0: 
0x24022080 | isr0
May 28 13:38:49 endurance kernel: [ 6464.475381] iwlwifi :04:00.0: 
0x0100 | isr1
May 28 13:38:49 endurance kernel: [ 6464.475385] iwlwifi :04:00.0: 
0x08201802 | isr2
May 28 13:38:49 endurance kernel: [ 6464.475388] iwlwifi :04:00.0: 
0x004154C0 | isr3
May 28 13:38:49 endurance kernel: [ 6464.475392] iwlwifi :04:00.0: 
0x | isr4
May 28 13:38:49 endurance kernel: [ 6464.475395] iwlwifi :04:00.0: 
0xAFDF009D | last cmd Id
May 28 13:38:49 endurance kernel: [ 6464.475399] iwlwifi :04:00.0: 
0x | wait_event
May 

Bug#959989: nftables: nft does not recognize imap service

[Arturo Borrero Gonzalez]

Control: tags -1 moreinfo

On 5/8/20 1:03 AM, Artur Pydo wrote:
> nft insert rule inet filter input tcp dport \{ 
> smtp,465,submission,imap,imaps,pop3,pop3s \}

I cannot reproduce this. The same rule worked here:

=== 8< ===
arturo@endurance:~$ sudo nft insert rule inet filter input tcp dport \{
smtp,465,submission,imap,imaps,pop3,pop3s \}

arturo@endurance:~$ sudo nft -S list ruleset
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
tcp dport { "smtp", "pop3", "imap2", "submissions", 
"submission", "imaps",
"pop3s" }
[...]
=== 8< ===

This is my services file:

=== 8< ===
arturo@endurance:~$ grep imap /etc/services
imap2   143/tcp imap# Interim Mail Access P 2 and 4
imaps   993/tcp # IMAP over SSL
=== 8< ===


I wonder if fail2ban is wrapping the call to the nft binary in a way that
prevents it from doing the getaddrinfo() call. This seems unlikely anyway.

Bug#959427: nftables: On boot "nftables.service" fails to start

[Arturo Borrero Gonzalez]

On 5/2/20 12:12 PM, Damir Koscic wrote:
> Package: nftables
> Version: 0.9.0-2
> Severity: important
> 
> Dear Maintainer,
> 
> On boot "nftables.service" fails to start. The excerpt from systemd journal
> (shown on bottom of mail), shows that offending part of of config file is:
> 
>   table netdev macs{
>   chain mac_filter{
>   type filter hook ingress device ens192 priority 0; 
> policy drop;
>   ether saddr "00:0c:29:0b:04:09" accept
>   }
>   }
> 
> The config file itself is OK, since there is no problem starting "nftables"
> after boot procedure is done (boot procedure itself is not compromised as
> described in another bug report).
> 
> The fact, that nft error messages were nested between "systemd-udevd" 
> messages,
> suggested that maybe "udevd" has not done its job entirely, and that somehow
> "nftables" depends on it. What I have tried to do is to add following into
> "nftables.service" unit file (using "systemctl edit", thus not modifying 
> packa-
> ge original unit file):
> 
>   After=systemd-udevd.service
> 
> That solved the problem, and all successive reboots were successful.
> 
> I hope this helps you identify the problem and find proper solution for it :)
> 
> Kind regards,
>   Damir Koscic
> 
> 
> Excerpt from systemd journal:
> --
>   audit[317]: AVC apparmor="STATUS" operation="profile_load" 
> profile="unconfined"
>   systemd-udevd[278]: link_config: autonegotiation is unset or enabled, the 
> speed and duplex are not writable.
>   systemd-udevd[288]: Using default interface naming scheme 'v240'.
>   systemd-udevd[289]: Using default interface naming scheme 'v240'.
>   nft[244]: /etc/nftables.conf:61:11-27: Error: Could not process rule: No 
> such file or directory
>   nft[244]: chain mac_filter{
>   nft[244]:   ^^
>   nft[244]: /etc/nftables.conf:63:9-39: Error: Could not process rule: No 
> such file or directory
>   nft[244]: ether saddr "00:0c:29:0b:04:09" accept
>   nft[244]: ^^
>   systemd-udevd[278]: Using default interface naming scheme 'v240'.
>   systemd-udevd[290]: Using default interface naming scheme 'v240'.
>   systemd-udevd[288]: link_config: autonegotiation is unset or enabled, the 
> speed and duplex are not writable.
>   systemd-udevd[289]: link_config: autonegotiation is unset or enabled, the 
> speed and duplex are not writable.
>   systemd-udevd[278]: link_config: autonegotiation is unset or enabled, the 
> speed and duplex are not writable.
>   systemd-udevd[290]: link_config: autonegotiation is unset or enabled, the 
> speed and duplex are not writable.
>   systemd-udevd[283]: Using default interface naming scheme 'v240'.
>   systemd[1]: Starting Flush Journal to Persistent Storage...
> 
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
c
ould it be that the interface the chain is referring to is not available at the
time of loading the ruleset?

nftables has no way to bring up interfaces on its own, so yeah, you might have
an udev dependency on your particular configuration that you should configure in
your service file (like you did).

Anyway, I don't this there is an actionable here? The service file can be
configured to keep trying to start the ruleset until the operation is 
successful.

BTW, Did you try with a newer kernel? There is linux kernel from the v5 family
in buster-bpo.

I'm closing the bug report now, as I think this is more related to the
particular configuration of your system. Thanks for the report, and feel free to
reopen if required!

Bug#959158: [pkg-netfilter-team] Bug#959158: iptables: ip6tables-restore dumps core

[Arturo Borrero Gonzalez]

On Thu, Apr 30, 2020, 09:21 Matej Marusak  wrote:

> Package: iptables
> Version: 1.8.4-3
> Severity: normal
>
> Dear Maintainer,
>
> In cockpit tests [1] we are seeing ip6tables-restore dumping core often.
> It only happens on debian-testing and only in one specific test. Also
> it does not happen always, around 1/3 of runs actually hit this.
> I tried to get some commandline reproduced, but even slightly tweaking
> our tests and it stopped being reproducible. So my gut feeling is that
> this is timing related and our tests hit it just right.
>
> Please see [1] to see backtrace, journal and core.
>
> The core backtrace:
> #0  0x7f16d2993679 in nftnl_table_list_free (list=0x0) at table.c:393
> #1  0x5613a6503fa9 in flush_cache (h=0x7fff89baf4e0, c=0x7fff89baf550,
> tablename=0x0) at nft-cache.c:622
> #2  0x5613a65044f9 in flush_cache (tablename=0x0, c=,
> h=) at nft-cache.c:651
> #3  nft_release_cache (h=) at nft-cache.c:651
>
>
> As I mentioned, I am unfortunatelly not able to find commandline
> reproducer, but I am more than happy to provide any outup or try any
> command.
>
> Hope it is actionable.
> Regards,
> MM
>
>
> [1] https://github.com/cockpit-project/bots/issues/809
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.5.0-1-cloud-amd64 (SMP w/1 CPU core)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages iptables depends on:
> ii  libc62.30-4
> ii  libip4tc21.8.4-3
> ii  libip6tc21.8.4-3
> ii  libmnl0  1.0.4-3
> ii  libnetfilter-conntrack3  1.0.8-1
> ii  libnfnetlink01.0.1-3+b1
> ii  libnftnl11   1.1.6-1
> ii  libxtables12 1.8.4-3
> ii  netbase  6.1
>
> Versions of packages iptables recommends:
> pn  nftables  
>
> Versions of packages iptables suggests:
> ii  firewalld  0.8.2-1
> ii  kmod   27-2
>
> -- no debconf information
>
> ___
> pkg-netfilter-team mailing list
> pkg-netfilter-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-netfilter-team



Thanks for the report.

Could you please provide the ip6tables ruleset that is causing this? i.e,
the ruleset you are trying to restore.

>
>

Bug#956891: Same error in different machine

[Arturo Borrero Gonzalez]

Hi there,

I got the exact same error in a different laptop.
Using kernel 5.4.19-1 (5.4.0-4)

See attached file for the kernel log.
Apr 29 17:48:47 ranger kernel: [ 3252.715611] BUG: kernel NULL pointer 
dereference, address: 0040
Apr 29 17:48:47 ranger kernel: [ 3252.715616] #PF: supervisor read access in 
kernel mode
Apr 29 17:48:47 ranger kernel: [ 3252.715618] #PF: error_code(0x) - 
not-present page
Apr 29 17:48:47 ranger kernel: [ 3252.715619] PGD 0 P4D 0 
Apr 29 17:48:47 ranger kernel: [ 3252.715623] Oops:  [#1] SMP PTI
Apr 29 17:48:47 ranger kernel: [ 3252.715627] CPU: 1 PID: 1129 Comm: xfwm4 
Tainted: P   OE 5.4.0-4-amd64 #1 Debian 5.4.19-1
Apr 29 17:48:47 ranger kernel: [ 3252.715629] Hardware name: LENOVO 
81BF/LNVNB161216, BIOS 6JCN23WW 01/23/2018
Apr 29 17:48:47 ranger kernel: [ 3252.715680] RIP: 
0010:i915_active_acquire+0x9/0x70 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715682] Code: 00 00 00 48 c7 46 58 00 00 
00 00 c7 46 38 00 00 00 00 48 c7 c6 0a 70 62 c0 e9 33 c0 b9 e6 0f 1f 00 0f 1f 
44 00 00 41 54 55 53 <8b> 47 38 48 89 fb 85 c0 74 15 8d 50 01 f0 0f b1 53 38 75 
f2 45 31
Apr 29 17:48:47 ranger kernel: [ 3252.715684] RSP: 0018:a33681ea7a40 
EFLAGS: 00010286
Apr 29 17:48:47 ranger kernel: [ 3252.715686] RAX:  RBX: 
8f0a246cdf00 RCX: 
Apr 29 17:48:47 ranger kernel: [ 3252.715687] RDX: 8f0a1ab9df80 RSI: 
8f0a246cdf00 RDI: 0008
Apr 29 17:48:47 ranger kernel: [ 3252.715688] RBP: 8f0a1ab9df80 R08: 
8f09bcb9e708 R09: 8f09bcb9e708
Apr 29 17:48:47 ranger kernel: [ 3252.715689] R10: a000 R11: 
 R12: 0008
Apr 29 17:48:47 ranger kernel: [ 3252.715690] R13: 0004 R14: 
8f0a1ab9df80 R15: 401c
Apr 29 17:48:47 ranger kernel: [ 3252.715692] FS:  7f2dbf00() 
GS:8f0a33c4() knlGS:
Apr 29 17:48:47 ranger kernel: [ 3252.715693] CS:  0010 DS:  ES:  CR0: 
80050033
Apr 29 17:48:47 ranger kernel: [ 3252.715695] CR2: 0040 CR3: 
0004681e2002 CR4: 003606e0
Apr 29 17:48:47 ranger kernel: [ 3252.715696] Call Trace:
Apr 29 17:48:47 ranger kernel: [ 3252.715730]  i915_active_ref+0x21/0x210 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715734]  ? _cond_resched+0x15/0x30
Apr 29 17:48:47 ranger kernel: [ 3252.715766]  
i915_vma_move_to_active+0x6e/0xf0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715795]  
i915_gem_do_execbuffer+0xc62/0x1520 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715800]  ? _cond_resched+0x15/0x30
Apr 29 17:48:47 ranger kernel: [ 3252.715802]  ? mutex_lock+0xe/0x30
Apr 29 17:48:47 ranger kernel: [ 3252.715805]  ? 
unix_stream_read_generic+0x1f7/0x8f0
Apr 29 17:48:47 ranger kernel: [ 3252.715809]  ? __kmalloc_node+0x1f5/0x300
Apr 29 17:48:47 ranger kernel: [ 3252.715835]  
i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715865]  ? 
i915_gem_madvise_ioctl+0x13a/0x290 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715891]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715906]  drm_ioctl_kernel+0xaa/0xf0 [drm]
Apr 29 17:48:47 ranger kernel: [ 3252.715918]  drm_ioctl+0x208/0x390 [drm]
Apr 29 17:48:47 ranger kernel: [ 3252.715945]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 29 17:48:47 ranger kernel: [ 3252.715948]  do_vfs_ioctl+0x40e/0x670
Apr 29 17:48:47 ranger kernel: [ 3252.715950]  ksys_ioctl+0x5e/0x90
Apr 29 17:48:47 ranger kernel: [ 3252.715952]  __x64_sys_ioctl+0x16/0x20
Apr 29 17:48:47 ranger kernel: [ 3252.715956]  do_syscall_64+0x52/0x160
Apr 29 17:48:47 ranger kernel: [ 3252.715959]  
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Apr 29 17:48:47 ranger kernel: [ 3252.715961] RIP: 0033:0x7f2ef03bd427
Apr 29 17:48:47 ranger kernel: [ 3252.715964] Code: 00 00 90 48 8b 05 69 7a 0c 
00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 
b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 7a 0c 00 f7 d8 64 
89 01 48
Apr 29 17:48:47 ranger kernel: [ 3252.715965] RSP: 002b:7fffd63b65c8 
EFLAGS: 0246 ORIG_RAX: 0010
Apr 29 17:48:47 ranger kernel: [ 3252.715967] RAX: ffda RBX: 
7fffd63b6610 RCX: 7f2ef03bd427
Apr 29 17:48:47 ranger kernel: [ 3252.715968] RDX: 7fffd63b6610 RSI: 
40406469 RDI: 000a
Apr 29 17:48:47 ranger kernel: [ 3252.715969] RBP: 40406469 R08: 
55d72e5a8000 R09: 
Apr 29 17:48:47 ranger kernel: [ 3252.715970] R10:  R11: 
0246 R12: 55d72e8d1ba0
Apr 29 17:48:47 ranger kernel: [ 3252.715971] R13: 000a R14: 
 R15: 7f2eed182e08
Apr 29 17:48:47 ranger kernel: [ 3252.715973] Modules linked in: ctr ccm 
nvidia_modeset(POE) bnep bbswitch(OE) intel_rapl_msr intel_rapl_common 
snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp 
snd_soc_acpi_intel_match 

Bug#956891: i915 intel VGA controller: null pointer dereference in i915_active_acquire()

[Arturo Borrero Gonzalez]

Package: src:linux
Version: 5.4.19-1
Severity: important
Tags: upstream

Dear maintainers,

thanks for your hard work with this package, really appreciated.

I would like to report a kernel crash related to the i915 intel VGA controller.
The issue happens with both 5.4.0-3-amd64 and 5.4.0-4-amd64, specially
when I'm using videconferencing (google meet in both Chromium and Firefox).

Here is the trace I was able to see:

Apr 16 12:13:29  kernel: [  718.329470] BUG: kernel NULL pointer dereference, 
address: 0040
Apr 16 12:13:29  kernel: [  718.329473] #PF: supervisor read access in kernel 
mode
Apr 16 12:13:29  kernel: [  718.329474] #PF: error_code(0x) - not-present 
page
Apr 16 12:13:29  kernel: [  718.329475] PGD 0 P4D 0 
Apr 16 12:13:29  kernel: [  718.329477] Oops:  [#1] SMP PTI
Apr 16 12:13:29  kernel: [  718.329479] CPU: 3 PID: 1233 Comm: xfwm4 Not 
tainted 5.4.0-3-amd64 #1 Debian 5.4.13-1
Apr 16 12:13:29  kernel: [  718.329480] Hardware name: LENOVO 
20H9CTO1WW/20H9CTO1WW, BIOS N1VET40W (1.30 ) 02/07/2018
Apr 16 12:13:29  kernel: [  718.329512] RIP: 0010:i915_active_acquire+0x9/0x70 
[i915]
Apr 16 12:13:29  kernel: [  718.329513] Code: 00 00 00 48 c7 46 58 00 00 00 00 
c7 46 38 00 00 00 00 48 c7 c6 0a 00 a9 c0 e9 f3 2f f3 cc 0f 1f 00 0f 1f 44 00 
00 41 54 55 53 <8b> 47 38 48 89 fb 85 c0 74 15 8d 50 01 f0 0f b1 53 38 75 f2 45 
31
Apr 16 12:13:29  kernel: [  718.329515] RSP: 0018:b79c80cd7a40 EFLAGS: 
00010286
Apr 16 12:13:29  kernel: [  718.329516] RAX:  RBX: 
9c78bab76840 RCX: 
Apr 16 12:13:29  kernel: [  718.329517] RDX: 9c789b9246c0 RSI: 
9c78bab76840 RDI: 0008
Apr 16 12:13:29  kernel: [  718.329518] RBP: 9c789b9246c0 R08: 
9c7803ad4a08 R09: 9c7803ad4a08
Apr 16 12:13:29  kernel: [  718.329518] R10: a000 R11: 
 R12: 0008
Apr 16 12:13:29  kernel: [  718.329519] R13: 0004 R14: 
9c789b9246c0 R15: 401c
Apr 16 12:13:29  kernel: [  718.329520] FS:  7f8d26f45f00() 
GS:9c78be38() knlGS:
Apr 16 12:13:29  kernel: [  718.329521] CS:  0010 DS:  ES:  CR0: 
80050033
Apr 16 12:13:29  kernel: [  718.329522] CR2: 0040 CR3: 
0004685c2006 CR4: 003606e0
Apr 16 12:13:29  kernel: [  718.329523] DR0:  DR1: 
 DR2: 
Apr 16 12:13:29  kernel: [  718.329524] DR3:  DR6: 
fffe0ff0 DR7: 0400
Apr 16 12:13:29  kernel: [  718.329525] Call Trace:
Apr 16 12:13:29  kernel: [  718.329547]  i915_active_ref+0x21/0x210 [i915]
Apr 16 12:13:29  kernel: [  718.329550]  ? _cond_resched+0x15/0x30
Apr 16 12:13:29  kernel: [  718.329570]  i915_vma_move_to_active+0x6e/0xf0 
[i915]
Apr 16 12:13:29  kernel: [  718.329588]  i915_gem_do_execbuffer+0xc62/0x1520 
[i915]
Apr 16 12:13:29  kernel: [  718.329590]  ? _cond_resched+0x15/0x30
Apr 16 12:13:29  kernel: [  718.329592]  ? mutex_lock+0xe/0x30
Apr 16 12:13:29  kernel: [  718.329594]  ? unix_stream_read_generic+0x1f7/0x8f0
Apr 16 12:13:29  kernel: [  718.329597]  ? __kmalloc_node+0x1f5/0x300
Apr 16 12:13:29  kernel: [  718.329614]  i915_gem_execbuffer2_ioctl+0x1df/0x3d0 
[i915]
Apr 16 12:13:29  kernel: [  718.329632]  ? i915_gem_madvise_ioctl+0x13a/0x290 
[i915]
Apr 16 12:13:29  kernel: [  718.329648]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 16 12:13:29  kernel: [  718.329661]  drm_ioctl_kernel+0xaa/0xf0 [drm]
Apr 16 12:13:29  kernel: [  718.329669]  drm_ioctl+0x208/0x390 [drm]
Apr 16 12:13:29  kernel: [  718.329686]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Apr 16 12:13:29  kernel: [  718.329688]  do_vfs_ioctl+0x40e/0x670
Apr 16 12:13:29  kernel: [  718.329691]  ksys_ioctl+0x5e/0x90
Apr 16 12:13:29  kernel: [  718.329693]  __x64_sys_ioctl+0x16/0x20
Apr 16 12:13:29  kernel: [  718.329695]  do_syscall_64+0x52/0x160
Apr 16 12:13:29  kernel: [  718.329697]  
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Apr 16 12:13:29  kernel: [  718.329699] RIP: 0033:0x7f8d2842c427
Apr 16 12:13:29  kernel: [  718.329701] Code: 00 00 90 48 8b 05 69 7a 0c 00 64 
c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 
00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 7a 0c 00 f7 d8 64 89 01 
48
Apr 16 12:13:29  kernel: [  718.329702] RSP: 002b:7ffceb36ad98 EFLAGS: 
0246 ORIG_RAX: 0010
Apr 16 12:13:29  kernel: [  718.329703] RAX: ffda RBX: 
7ffceb36ade0 RCX: 7f8d2842c427
Apr 16 12:13:29  kernel: [  718.329704] RDX: 7ffceb36ade0 RSI: 
40406469 RDI: 000a
Apr 16 12:13:29  kernel: [  718.329704] RBP: 40406469 R08: 
5606326decd0 R09: 
Apr 16 12:13:29  kernel: [  718.329705] R10:  R11: 
0246 R12: 560632a0dc70
Apr 16 12:13:29  kernel: [  718.329706] R13: 000a R14: 
 R15: 7f8d24ec3e08
Apr 16 12:13:29  kernel: [  

Bug#956655: nftables preinst / postrm depend on bash

[Arturo Borrero Gonzalez]

Control: fixed -1 0.9.1-3

On 4/14/20 12:45 AM, Etienne Champetier wrote:
> Package: nftables
> Version: 0.9.0-2
> 
> Hello,
> 
> Trying to install iptables in a container, nftables installation fails
> because preinst / postrm scripts use /bin/bash, which is not present
> in the container and not a dependency
> 

This is fixed by this patch:

https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4f0bb1d072e62bc67b89900d43592876e2560d63

You can find the fix in nftables version 0.9.1-3 which was uploaded to Debian on
Thu, 15 Aug 2019.

Any chance you can use a newer version? For example, you have 0.9.3-2~bpo10+1 in
buster-backports.

regards

Bug#945710: neopi: Python2 removal in sid/bullseye

[Arturo Borrero Gonzalez]

On 4/1/20 5:31 PM, Sandro Tosi wrote:
>> I'm no longer interested in this package. I guess Miguel Angel Martin 
>> Serrano is
>> also not interested.
>>
>> Feel free to adopt it, otherwise I will probably drop it from Debian at some 
>> point.
> 
> I'm not interested in the package either, if you dont mind, i'd like
> to file a removal bugs in the next few days - this will help with the
> py2removal effort.
> 

That would be appreciated.

Thanks!

Bug#945710: neopi: Python2 removal in sid/bullseye

[Arturo Borrero Gonzalez]

On 3/31/20 3:35 AM, Sandro Tosi wrote:
> Hello all,
> 
> On Wed, 27 Nov 2019 23:58:50 + Sandro Tosi  
> wrote:
>> Source: neopi
>> Version: 0.0+git20120821.98-6
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
> 
> it looks like there's a fork of neopi with the port to python3:
> 
> https://github.com/ByteInternet/NeoPI/commit/ac882528aeab9d67a1091dafd74007f10c12
> https://github.com/ByteInternet/NeoPI/commit/6cf5967b1d5c7724f1992bdba6bbb861c2dccb51
> 
> Can you have a look at them and eventually port the package in debian
> to Python3? If you prefer, i can take care of it, and most likely will
> if i nobody gets back to me in ~1 week.
> 

I'm no longer interested in this package. I guess Miguel Angel Martin Serrano is
also not interested.

Feel free to adopt it, otherwise I will probably drop it from Debian at some 
point.

regards.

Bug#949518: iptables-restore empty line not accepted any more (regression)

[Arturo Borrero Gonzalez]

This seems to be fixed by this upstream patch:

https://git.netfilter.org/iptables/commit/?id=8e76391096f12212985c401ee83a67990aa27a29

Will try to include this fix in the iptables package soon.

Bug#950637: update build-dep on iptables-dev

[Arturo Borrero Gonzalez]

Source: xtables-addons
Version: 3.7-1
Severity: serious

It seems xtables-addons build-deps on iptables-dev, which no longer exists.

Please update the build-deps of xtables-addons. You probably need the
libxtables-dev package instead.

This is apparently preventing the migration of iptables from sid to testing.

regards.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#949576: libiptc-dev: Breaks/Replaces missing between libiptc-dev and libip4tc-dev

[Arturo Borrero Gonzalez]

On 1/22/20 7:04 PM, Sven-Haegar Koch wrote:
> On Wed, 22 Jan 2020, Alberto Molina Coballes wrote:
> 
>> A new commit which hopefully solves this bug has been uploaded [1], 
>> but this bug is affecting only 1.8.4-1 and a new release will not be 
>> uploaded inmediatly, but ASAP.
> 
> Thanks for fixing it!
> 
> This bug report was more for completeness - a second run of apt-get 
> makes the packages install, as on retry the conflicting package got 
> already upgraded, so the failed one is able to succeed. Also because it 
> only affects unstable and does not break upgrading completely I did not 
> give it a higher severity.
> 

That's true.

I'm not sure a breaks+replaces is worth carrying over for a package version that
was not even present in testing...

@Alberto, I saw the commit. It is right, but perhaps it will pollute d/control
for no strong reason. We could revert if you want. Up to you!

regards.

Bug#949369: i915: kernel crash in i915_active_acquire()

[Arturo Borrero Gonzalez]

On Mon, Jan 20, 2020, 20:02 Ben Hutchings  wrote:

> Control: tag -1 moreinfo
>
> On Mon, 2020-01-20 at 11:03 +0100, Arturo Borrero Gonzalez wrote:
> > Source: linux
> > Version: 5.4.8-1
> > Severity: normal
> > Tags: upstream
> >
> > Dear maintainers, thanks for your hard work with the linux package, it is
> > really appreciated.
> >
> > I had this kernel crash today that let the system unusable.
> [...]
>
> Is this reproducible without the Nvidia proprietary driver?
>

I was unable to reproduce the issue even without doing any modification to
the system.

Feel free to close the bug. I can reopen it in case I have followups.

>

Bug#946519: (no subject)

[Arturo Borrero Gonzalez]

Control: tag -1 moreninfo

Bug#946519: iptables fails to update rules from fwbuilder

[Arturo Borrero Gonzalez]

On Tue, 10 Dec 2019 14:32:59 +0100
=?utf-8?q?Jos=C3=A9_L=2E_Fern=C3=A1ndez_Jambrina?=
 wrote:
> Package: iptables
> Version: 1.8.3-2
> Severity: important
> 
> Dear Maintainer,
> 
>After upgrading to buster from strech, the iptables defined in fwbuilder 
> don't works when changed:
>  iall I get is a message "iptables: Chain already exists" for each rule and 
> they don't work.
> 
>Moreover as I removed network-manager package my system start withour 
> rules (maybe with default rules) an this moment the script generated by 
> fwbuilder runs without warnning and rules are applied. Afterwards, if I tried 
> to aplly diferent rules, I get the warnning messages and the rules don't work.
> 
>At first my system was running the stable version of iptables, 1.8.2-4, so 
> I move to the testing version, 1.8.3-2, without changes.
> 

We would need additional information about what ruleset are you (or fwbuilder)
trying to load.

regards.

Bug#946289: ufw: fails to start with iptables 1.8.4

[Arturo Borrero Gonzalez]

On Mon, 6 Jan 2020 12:38:52 -0600 Jamie Strandboge  wrote:
> On Fri, 13 Dec 2019, Jamie Strandboge wrote:
> 
> > I can confirm this. It looks like iptables-restore and iptables6-restore
> > in 1.8.4 has broken -n behavior with the nft varieties.
> 
> This is https://bugzilla.netfilter.org/show_bug.cgi?id=1394
> 

This is probably fixed by:

https://git.netfilter.org/iptables/commit/?id=a103fbfadf4c17b8b12caa57eef72deaaa71a18c

Bug#949369: i915: kernel crash in i915_active_acquire()

[Arturo Borrero Gonzalez]

Source: linux
Version: 5.4.8-1
Severity: normal
Tags: upstream

Dear maintainers, thanks for your hard work with the linux package, it is
really appreciated.

I had this kernel crash today that let the system unusable.

 kernel: [  973.595610] #PF: supervisor read access in kernel mode
 kernel: [  973.595610] #PF: supervisor read access in kernel mode
 kernel: [  973.595611] #PF: error_code(0x) - not-present page
 kernel: [  973.595612] PGD 0 P4D 0 
 kernel: [  973.595614] Oops:  [#1] SMP PTI
 kernel: [  973.595616] CPU: 3 PID: 1240 Comm: xfwm4 Tainted: P   OE
 5.4.0-2-amd64 #1 Debian 5.4.8-1
 kernel: [  973.595617] Hardware name: LENOVO 20H9CTO1WW/20H9CTO1WW, BIOS 
N1VET40W (1.30 ) 02/07/2018
 kernel: [  973.595644] RIP: 0010:i915_active_acquire+0x9/0x70 [i915]
 kernel: [  973.595646] Code: 00 00 00 48 c7 46 58 00 00 00 00 c7 46 38 00 00 
00 00 48 c7 c6 0a 20 29 c2 e9 c3 f7 12 cf 0f 1f 00 0f 1f 44 00 00 41 54 55 53 
<8b> 47 38 48 89 fb 85 c0 74 15 8d 50 01 f0 0f b1 53 38 75 f2 45 31
 kernel: [  973.595647] RSP: 0018:b9924256ba40 EFLAGS: 00010286
 kernel: [  973.595648] RAX:  RBX: 8b29346850c0 RCX: 

 kernel: [  973.595649] RDX: 8b288f04e880 RSI: 8b29346850c0 RDI: 
0008
 kernel: [  973.595650] RBP: 8b288f04e880 R08: 8b2936174c08 R09: 
8b2936174c08
 kernel: [  973.595651] R10: a000 R11:  R12: 
0008
 kernel: [  973.595652] R13: 0004 R14: 8b288f04e880 R15: 
401c
 kernel: [  973.595654] FS:  7f342b744f00() GS:8b293e38() 
knlGS:
 kernel: [  973.595655] CS:  0010 DS:  ES:  CR0: 80050033
 kernel: [  973.595655] CR2: 0040 CR3: 000460b2e005 CR4: 
003606e0
 kernel: [  973.595656] DR0:  DR1:  DR2: 

 kernel: [  973.595657] DR3:  DR6: fffe0ff0 DR7: 
0400
 kernel: [  973.595658] Call Trace:
 kernel: [  973.595679]  i915_active_ref+0x21/0x210 [i915]
 kernel: [  973.595683]  ? _cond_resched+0x15/0x30
 kernel: [  973.595703]  i915_vma_move_to_active+0x6e/0xf0 [i915]
 kernel: [  973.595723]  i915_gem_do_execbuffer+0xc62/0x1520 [i915]
 kernel: [  973.595726]  ? _cond_resched+0x15/0x30
 kernel: [  973.595727]  ? mutex_lock+0xe/0x30
 kernel: [  973.595729]  ? unix_stream_read_generic+0x1f7/0x8f0
 kernel: [  973.595733]  ? __kmalloc_node+0x1f5/0x300
 kernel: [  973.595749]  i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
 kernel: [  973.595767]  ? i915_gem_madvise_ioctl+0x13a/0x290 [i915]
 kernel: [  973.595782]  ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
 kernel: [  973.595794]  drm_ioctl_kernel+0xaa/0xf0 [drm]
 kernel: [  973.595801]  drm_ioctl+0x208/0x390 [drm]
 kernel: [  973.595817]  ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
 kernel: [  973.595828]  do_vfs_ioctl+0x40e/0x670
 kernel: [  973.595830]  ? __schedule+0x2eb/0x740
 kernel: [  973.595832]  ksys_ioctl+0x5e/0x90
 kernel: [  973.595835]  ? exit_to_usermode_loop+0x6a/0xf0
 kernel: [  973.595837]  __x64_sys_ioctl+0x16/0x20
 kernel: [  973.595838]  do_syscall_64+0x52/0x160
 kernel: [  973.595841]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 kernel: [  973.595842] RIP: 0033:0x7f342cc195c7
 kernel: [  973.595844] Code: 00 00 90 48 8b 05 c9 78 0c 00 64 c7 00 26 00 00 
00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1
f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 
99 78 0c 00 f7 d8 64 89 01 48
 kernel: [  973.595845] RSP: 002b:7ffe61cf9bb8 EFLAGS: 0246 ORIG_RAX: 
0010
 kernel: [  973.595846] RAX: ffda RBX: 7ffe61cf9c00 RCX: 
7f342cc195c7
 kernel: [  973.595847] RDX: 7ffe61cf9c00 RSI: 40406469 RDI: 
000a
 kernel: [  973.595848] RBP: 40406469 R08: 560b58426630 R09: 

 kernel: [  973.595849] R10:  R11: 0246 R12: 
560b587b50c0
 kernel: [  973.595849] R13: 000a R14:  R15: 
7f342975d6a8
 kernel: [  973.595851] Modules linked in: rfcomm ctr ccm nvidia_modeset(POE) 
cmac overlay bnep intel_rapl_msr inte
l_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp mei_wdt kvm_intel 
snd_hda_codec_hdmi iwlmvm btusb nls_ascii snd_hda_codec_realt
ek btrtl nls_cp437 btbcm btintel kvm mac80211 snd_hda_codec_generic irqbypass 
vfat snd_soc_skl libarc4 fat bluetooth intel_cstate snd_soc_hd
ac_hda intel_uncore snd_hda_ext_core efi_pstore snd_soc_sst_ipc intel_rapl_perf 
snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_so
c_core i915 wmi_bmof pcspkr serio_raw efivars snd_compress snd_hda_intel 
snd_intel_nhlt iTCO_wdt intel_wmi_thunderbolt iwlwifi uvcvideo snd_
hda_codec iTCO_vendor_support snd_hda_core nvidia(POE) watchdog 
videobuf2_vmalloc snd_hwdep videobuf2_memops videobuf2_v4l2 snd_pcm videobuf
2_common snd_timer drm_kms_helper cfg80211 videodev ipmi_devintf sg drbg 
ipmi_msghandler 

Bug#949101: [pkg-netfilter-team] Bug#949101: iptables-restore: segmentation fault

[Arturo Borrero Gonzalez]

On 1/17/20 10:26 AM, Alexander E. Patrakov wrote:
> 
> Great! Could you please make sure that the fix somehow propagates to
> Debian stable?
> 

It is somehow propagated to stable, in the form a backport available:

iptables 1.8.3-2~bpo10+1

I don't plan, nor have time, to work on identifying the patch and doing a patch
update for a stable point release.

Bug#949101: [pkg-netfilter-team] Bug#949101: iptables-restore: segmentation fault

[Arturo Borrero Gonzalez]

Control: fixed -1 1.8.3-2

On 1/16/20 11:10 PM, Alexander E. Patrakov wrote:
> Package: iptables
> Version: 1.8.2-4

Thanks for the bug report!

I couldn't reproduce this in a more recent version:

=== 8< ===
arturo@endurance:~ $ sudo iptables-nft-restore < original_rules.iptables
arturo@endurance:~ $ sudo iptables-nft-restore -n -t < new.iptables
arturo@endurance:~ $ sudo iptables-nft-save
# Generated by xtables-save v1.8.3 on Fri Jan 17 10:22:32 2020
*nat
:PREROUTING ACCEPT [10:3800]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [4:566]
:OUTPUT ACCEPT [4:566]
COMMIT
# Completed on Fri Jan 17 10:22:32 2020
# Generated by xtables-save v1.8.3 on Fri Jan 17 10:22:32 2020
*filter
:INPUT ACCEPT [62:8657]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [65:5404]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A FORWARD -i wg-customers -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg-customers -j DROP
-A FORWARD -o wg-customers -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m
conntrack --ctstate NEW -j ACCEPT
-A f2b-sshd -s 222.186.30.145/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Fri Jan 17 10:22:32 2020
=== 8< ===

Marking this as fixed in version 1.8.3-2 and closing bug.

regards.

Bug#948732: Please provide backport of python3-nftables >= 0.9.3-2 for buster-backports

[Arturo Borrero Gonzalez]

On 1/12/20 5:54 PM, Michael Biebl wrote:
> Source: nftables
> Severity: wishlist
> Control: block 940646 by -1
> 
> Hi,
> 
> some users requested a backport of a recent firewalld version via
> buster-backports.
> Unfortunately this requires python3-nftables >= 0.9.3-2 in
> buster-backports. Would you be willing to provide such a backport?
> 

Yes I can do this. Ping me in a couple of weeks if you don't see the package
uploaded.

Bug#947176: [pkg-netfilter-team] Bug#947176: libiptc.pc non-functional

[Arturo Borrero Gonzalez]

On 1/11/20 12:04 PM, Michael Biebl wrote:
> Hi Arturo
> 
> On Sun, 22 Dec 2019 15:06:02 +0100 Michael Biebl  wrote:
>>
>> 1/ Have a single libiptc-dev package which contains all development files
>> 2/ Have a libip6tc-dev package which contains all development files
>> related to libip6tc, have a libip4tc-dev package which contains all
>> development files related to libip4tc and have libiptc-dev (convenience)
>> package which contains libiptc.pc and depends on both libip6tc-dev and 
>> libip4tc-dev
>>
> 
> Have you decided how you want to proceed from here?
> Would welcome your feedback.
> 

Option 2) is probably the way to go.

I didn't have time to get to this yet. Perhaps @alberto have some spare cycles?

regards.

Bug#948031: please enable some additional Netfilter modules

[Arturo Borrero Gonzalez]

Source: linux
Severity: wishlist

Dear kernel maintainers,

thanks for your hard work with this package, it is really appreciated.

I discovered this in my machine:

arturo@endurance:~$ grep NF_ /boot/config-5.3.0-3-amd64 | grep ^#
# CONFIG_IP6_NF_MATCH_SRH is not set
# CONFIG_NF_CONNTRACK_BRIDGE is not set
arturo@endurance:~$ grep NFT /boot/config-5.3.0-3-amd64 | grep ^#
# CONFIG_NFT_XFRM is not set
# CONFIG_NFT_SYNPROXY is not set
# CONFIG_NFT_BRIDGE_META is not set

Would you please enable them?

thanks!

-- 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_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#946932: /usr/sbin/ebtables-nft-restore requires /etc/ethertypes

[Arturo Borrero Gonzalez]

On 12/18/19 4:25 AM, Michael Biebl wrote:
> Package: iptables
> Version: 1.8.4-1
> Severity: normal
> File: /usr/sbin/ebtables-nft-restore
> 
> Hi,
> 
> when trying to run the firewalld test-suite with only iptables installed
> but not ebtables and ebtables-restore pointing at
> /usr/sbin/ebtables-nft-restore I get the following failure:
> 
> +Error: COMMAND_FAILED: '/usr/sbin/ebtables-restore --noflush' failed: 
> ebtables-restore v1.8.4 (nf_tables): Problem with the specified Ethernet 
> protocol 'IPv6', perhaps /etc/ethertypes is missing
> +Error occurred at line: 2
> +Try `ebtables-restore -h' or 'ebtables-restore --help' for more information.
> +
> stdout:
> ./firewall-cmd.at:911: exit code was 13, expected 0
> 
> And indeed, /etc/ethertypes is provided by the ebtables package.
> Installing ebtables and rerunning the test makes
> /usr/sbin/ebtables-restore succeed.
> 
> Should /etc/ethertypes be moved into a common package which both
> ebtables and iptables can depend upon?
> 

@Alberto,

What do you think about this issue? Could you please handle it?

regards.

Bug#946153: please update build-deps on iptables

[Arturo Borrero Gonzalez]

On 12/6/19 12:27 PM, Luca Boccassi wrote:
> I am a little confused though - as far as I can see, there is no
> dependency on libiptc at all in iproute2. There is no linkage to the
> libraries, and no build-dependency in d/control.
> Only xtables is used.
> 
> The headers seem to be vendorized in the repository, so maybe it came
> up from a global search?
> 

That's true. I searched for the include and iproute2 was in the results.

Sorry for the noise. Closing bug now.

Bug#946149: please update build-deps on iptables

[Arturo Borrero Gonzalez]

On 12/4/19 1:53 PM, Michael Biebl wrote:
> Hi Arturo
> 
> Am 04.12.19 um 12:41 schrieb Arturo Borrero Gonzalez:
>> Package: systemd
>> Version: 243-8
>> Severity: normal
>>
>> Hi there!
>>
>> The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and 
>> libiptc0
>> binary packages. The content is included now in either libip4tc or libip6tc.
>> Such change comes from upstream. 
>>
>> This package seems to `#include `, which is fine; But
>> I encourage to please update the build-deps to use libip4tc-dev instead of
>> libiptc-dev.
> 
> So, I had a quick look at iptables 1.8.4.
> 
> upstream still installs a libiptc.pc and
> 
> ./usr/include/libiptc
> ./usr/include/libiptc/xtcshared.h
> ./usr/include/libiptc/libxtc.h
> ./usr/include/libiptc/libip6tc.h
> ./usr/include/libiptc/libiptc.h
> ./usr/include/libiptc/ipt_kernel_headers.h
> 
> They did drop the libiptc.so though.
> My recommendation is to simply drop libiptc0 but keep libiptc-dev.
> 
> No changes to packages are necessary this way.
> If you drop the libiptc.pc, then this will cause quite a few packages to
> FTBFS.
> 

Thanks for the quick review, really appreciated.

For the record libiptc.pc is currently included in the other package:

debian/libip4tc-dev.install: usr/lib/*/pkgconfig/libiptc.pc

Thinking about your recommendation, it feels a bit weird to have libiptc-dev but
not the corresponding .so lib package. I wonder if that would make things more
confusing in the long term.
My approach was to have libiptc-dev be a transitional package, and Depend on the
other 2 variants so nobody should be FTBFS'ing. I won't drop the transitional
package until every package updates the Build-Dep to use libip4tc-dev.

What do you think about that?

Bug#946153: please update build-deps on iptables

[Arturo Borrero Gonzalez]

Package: iproute2
Version: 5.4.0-1
Severity: normal

Hi there!

The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and libiptc0
binary packages. The content is included now in either libip4tc or libip6tc.
Such change comes from upstream. 

This package seems to `#include `, which is fine; But
I encourage to please update the build-deps to use libip4tc-dev instead of
libiptc-dev.

The header file is the same. Also pkg-config information should be right.

The build should be something like:

gcc $(pkg-config xtables --cflags) yourpackage.c -lip4tc or -lip6tc

instead of:

gcc yourpackage.c -liptc 

This may need reporting upstream. Let me know if you find any issue with this
change.

Bug#946152: please update build-deps on iptables

[Arturo Borrero Gonzalez]

Source: collectd
Severity: normal

Hi there!

The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and libiptc0
binary packages. The content is included now in either libip4tc or libip6tc.
Such change comes from upstream. 

This package seems to `#include `, which is fine; But
I encourage to please update the build-deps to use libip4tc-dev instead of
libiptc-dev.

The header file is the same. Also pkg-config information should be right.

The build should be something like:

gcc $(pkg-config xtables --cflags) yourpackage.c -lip4tc or -lip6tc

instead of:

gcc yourpackage.c -liptc 

This may need reporting upstream. Let me know if you find any issue with this
change.

Bug#946150: please update build-deps on iptables

[Arturo Borrero Gonzalez]

Package: miniupnpd
Severity: normal

Hi there!

The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and libiptc0
binary packages. The content is included now in either libip4tc or libip6tc.
Such change comes from upstream. 

This package seems to `#include `, which is fine; But
I encourage to please update the build-deps to use libip4tc-dev instead of
libiptc-dev.

The header file is the same. Also pkg-config information should be right.

The build should be something like:

gcc $(pkg-config xtables --cflags) yourpackage.c -lip4tc or -lip6tc

instead of:

gcc yourpackage.c -liptc 

This may need reporting upstream. Let me know if you find any issue with this
change.

Bug#946149: please update build-deps on iptables

[Arturo Borrero Gonzalez]

Package: systemd
Version: 243-8
Severity: normal

Hi there!

The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and libiptc0
binary packages. The content is included now in either libip4tc or libip6tc.
Such change comes from upstream. 

This package seems to `#include `, which is fine; But
I encourage to please update the build-deps to use libip4tc-dev instead of
libiptc-dev.

The header file is the same. Also pkg-config information should be right.

The build should be something like:

gcc $(pkg-config xtables --cflags) yourpackage.c -lip4tc or -lip6tc

instead of:

gcc yourpackage.c -liptc 

This may need reporting upstream. Let me know if you find any issue with this
change.