Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'

[Harald Welte]

Please note that the osmocom fork does have a CI job to exactly
prevent a situation like this:  We're continuously building our fork against
Linus Torvalds' git, see 
https://jenkins.osmocom.org/jenkins/job/master-dahdi-linux-torvalds-master/

It seems the strlcpy was fixed in
https://gitea.osmocom.org/retronetworking/dahdi-linux/commit/b4a35fb6984a7693ec82b99af03d368c2f5a8c0b

Maybe the debian pacakge was using an outdated version and not following
https://gitea.osmocom.org/retronetworking/dahdi-linux/commits/branch/master ?

The Osmocom fork introduces some modern hardware support which is not present in
sangoma (Osmocom icE1usb, the only open source hardware E1 interface I am aware 
of),
and it re-introduces support for some older Digium hardware [with active users]
that Digium/Sangoma have removed from their official version.

Regards,
Harald
-- 
- Harald Welte   https://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1071608: apparmor prevents storage of preferences

[Harald Welte]

Package: evince
Version: 46.1-1
Severity: normal

At some point evince on my system stopped to use the document-specific 
preference that I have stored over the
past few years (such as inverted display for many PDFs).  Instead, every PDF is 
opened without that
preference.

I have the suspicion that it's apparmor related, as I get lots of errors every 
time I start evince:

(evince:185861): Gtk-WARNING **: 11:42:12.750: Failed to parse 
/space/home/laforge/.config/gtk-3.0/settings.ini: Permission denied

(evince:185861): Gtk-WARNING **: 11:42:12.795: Attempting to read the recently 
used resources file at '/space/home/laforge/.local/share/recently-used.xbel', 
but the parser failed: Failed to open file 
“/space/home/laforge/.local/share/recently-used.xbel”: Permission denied.

(evince:185861): GVFS-WARNING **: 11:42:12.847: can't init metadata tree 
/space/home/laforge/.local/share/gvfs-metadata/home: open: Permission denied
[many repeated messages]
** (evince:185861): WARNING **: 11:42:12.884: Error setting file metadata: 
can’t open metadata tree
[many repeated messages]
(evince:185861): Gtk-WARNING **: 11:42:13.162: Attempting to store changes into 
'/space/home/laforge/.local/share/recently-used.xbel', but failed: Failed to 
create file “/space/home/laforge/.local/share/recently-used.xbel.KJX8N2”: 
Permission denied
(evince:185861): Gtk-WARNING **: 11:42:13.162: Attempting to set the 
permissions of '/space/home/laforge/.local/share/recently-used.xbel', but 
failed: Permission denied


I guess I can work around this with custom apparmor rules, but shouldn't the 
default be continue working as normal, and not loose important features by the 
default apparmor rules?



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  evince-common46.1-1
ii  gsettings-desktop-schemas46.0-1
ii  libatk1.0-0t64   2.52.0-1
ii  libc62.38-11
ii  libcairo-gobject21.18.0-3+b1
ii  libcairo21.18.0-3+b1
ii  libevdocument3-4t64  46.1-1
ii  libevview3-3t64  46.1-1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libglib2.0-0t64  2.80.2-1
ii  libgnome-desktop-3-20t64 44.0-5
ii  libgtk-3-0t643.24.41-4
ii  libhandy-1-0 1.8.3-1+b1
ii  libpango-1.0-0   1.52.2+ds-1
ii  libpangocairo-1.0-0  1.52.2+ds-1
ii  libsecret-1-00.21.4-1+b1
ii  shared-mime-info 2.4-4

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  dbus-x11 [dbus-session-bus]   1.14.10-4+b1

Versions of packages evince suggests:
ii  gvfs 1.54.0-4
pn  nautilus-sendto  
ii  poppler-data 0.4.12-1
ii  unrar1:7.0.9-1

-- Configuration Files:
/etc/apparmor.d/usr.bin.evince changed [not included]

-- no debconf information

Bug#1067771: cdk.h file location has changed, breaks application build

[Harald Welte]

Package: libcdk5-dev
Version: 5.0.20230201-3
Severity: normal

It used to be the case (for probably more than a decade) that the main cdk.h 
file
contained in libcdk5-dev is located in /usr/include/cdk/cdk.h

This is still the case in debian stable as of 5.0.20180306-3

However, in currnt unstable (5.0.20230201-3), the location has suddenly shifted 
to
/usr/include/cdk.h

This is breaking applications like osmo-bsc, which is using the following
autoconf macro to test for cdk.h presence:

AC_CHECK_HEADERS(cdk/cdk.h, [], AC_MSG_ERROR(Unable to find libcdk))


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_DE.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 libcdk5-dev depends on:
pn  libcdk5t64  
ii  libncurses-dev  6.4+20240113-1

libcdk5-dev recommends no packages.

libcdk5-dev suggests no packages.

Bug#1030752: is this package still maintained?

[Harald Welte]

Hi Greg,

I'm sorry to be complaining again, but it somehow feels that this package
is no longer maintained.   If no new package maintainer can be found,
I think in fact it would be better for debian not to ship any eclipse-titan
package than to continue shipping a known-broken version for more than a year.

That way, it doesn't create the illusion of a working package and people know
they will have to build from source or look elsewhere for packages not 
maintained
within Debian.

We (at sysmocom) would be happy to contribute even some funding or human
resources to the maintenance effort, but we do not have anyone with
Debian developer status in our team.

Kind regards,
Harald

-- 
- Harald Welte   https://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1030752: request 8.3.0 to be packaged. 8.2.0 is known broken

[Harald Welte]

Dear Greg,

it has been more than a year since this bug has been filed.  Upstream TITAN has 
meanwhile
released 8.3.0, 9.0.0 and 10.0.0, while debian still ships a known-broken 8.2.0

For exaple, the SMPP Protocol Module is encoding a wrong length value in the 
data it is sending.
Also, LLC messages are encoded wrong, see https://osmocom.org/issues/5788

I really thnk that 8.3.0 should have been uploaded to debian more than a year 
ago in order
to fix those issues.

Thanks for your attention.

-- 
- Harald Welte   https://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1055160: Acknowledgement (not installable as gcc-arm-non-eabi has moved to 15:12.3.rel1-1)

[Harald Welte]

I've actually tried to resolve this by doing a local dpkg-buildpackage 
of the completely unmodified package retrieved by "apt source 
libstdc++-arm-none-eabi"
and it worked:

dpkg-deb: building package 'libstdc++-arm-none-eabi-newlib' in 
'../libstdc++-arm-none-eabi-newlib_12.3.rel1-1+23_all.deb'.
dpkg-deb: building package 'libstdc++-arm-none-eabi-dev' in 
'../libstdc++-arm-none-eabi-dev_12.3.rel1-1+23_all.deb'.
dpkg-deb: building package 'libstdc++-arm-none-eabi-picolibc' in 
'../libstdc++-arm-none-eabi-picolibc_12.3.rel1-1+23_all.deb'.

which I could then install via dpkg without any conflicts, as it's 15:12.3 

Selecting previously unselected package libstdc++-arm-none-eabi-dev.
(Reading database ... 840133 files and directories currently installed.)
Preparing to unpack libstdc++-arm-none-eabi-dev_12.3.rel1-1+23_all.deb ...
Unpacking libstdc++-arm-none-eabi-dev (15:12.3.rel1-1+23) ...
Selecting previously unselected package libstdc++-arm-none-eabi-newlib.
Preparing to unpack libstdc++-arm-none-eabi-newlib_12.3.rel1-1+23_all.deb ...
Unpacking libstdc++-arm-none-eabi-newlib (15:12.3.rel1-1+23) ...
Selecting previously unselected package libstdc++-arm-none-eabi-picolibc.
Preparing to unpack libstdc++-arm-none-eabi-picolibc_12.3.rel1-1+23_all.deb ...
Unpacking libstdc++-arm-none-eabi-picolibc (15:12.3.rel1-1+23) ...
Setting up libstdc++-arm-none-eabi-dev (15:12.3.rel1-1+23) ...
Setting up libstdc++-arm-none-eabi-newlib (15:12.3.rel1-1+23) ...
Setting up libstdc++-arm-none-eabi-picolibc (15:12.3.rel1-1+23) ...

-- 
- Harald Welte   https://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1055160: not installable as gcc-arm-non-eabi has moved to 15:12.3.rel1-1

[Harald Welte]

Package: libstdc++-arm-none-eabi-dev
Version: 15:12.2.rel1-1+23
Severity: important
Tags: a11y

For at several months, it has been impossible to install 
libstdc++-arm-none-eabi-dev
from the debian archive for unstable, as it depends on gcc-arm-none-eabi (= 
15:12.2.rel1-1)
but sid gcc-arm-none-eabi package has moved to 15:12.3.rel1-1 on August 10, 
2023.

I was always assuming this kind of issue would be fixed automatically somehow 
over time, as surely
some CI job would detect uninstallable packages over an extended period of 
time.  However, it
has still not been fixed and there's no related bug report, so I'm filing one 
here.

I'm not a Debian developer, but IMHO the libstdc++-arm-none-eabi source package 
would have to be
rebuilt against the updated gcc-arm-none-eabi, so that the resulting binary 
packages will
depend on the 15:12.3.rel1-1 gcc version?

Any help is appreciated.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 libstdc++-arm-none-eabi-dev depends on:
ii  gcc-arm-none-eabi  15:12.3.rel1-1

libstdc++-arm-none-eabi-dev recommends no packages.

libstdc++-arm-none-eabi-dev suggests no packages.

Bug#1037337: Acknowledgement (mod_dirindex header/footer displayed only at first request during stat cache period)

[Harald Welte]

I've reported this upstream as I couldn't find the problem fixed even
in git master of today.

upstream bug report is at https://redmine.lighttpd.net/issues/3211

I'm attaching my trivial patch fixing the problem.  Given this is a regression
during distribution upgrade, it would be good to get the package updated with
this fix - before other Debian users fall into the same trap during their 
upgrade.

-- 
- Harald Welte   https://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)
>From 40d2ec1a65fe4d6621ee28d8250380846adced57 Mon Sep 17 00:00:00 2001
From: Harald Welte 
Date: Sun, 11 Jun 2023 18:27:56 +0200
Subject: [PATCH] [mod_dirindex] fix unreliable rendering of readme/header
 (closes: #3211)

If the stat_cache keeps the file open after we render a readme/header
file for the first time, we must re-wind the file cursor back to the
start.

This fixes a bug where only the first rendering of the readme/header
works, and subsequent HTTP responses are lacking it as long as the
stat_cache entry lives.
---
 src/mod_dirlisting.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mod_dirlisting.c b/src/mod_dirlisting.c
index fdfdcdd5..7b152aba 100644
--- a/src/mod_dirlisting.c
+++ b/src/mod_dirlisting.c
@@ -644,6 +644,9 @@ static void http_list_directory_include_file(request_st * const r, const handler
 buffer_clear(out);
 }
 }
+/* rewind the file pointer, as the stat_cache may keep the fd open, resulting
+ * in this function trying to read again */
+lseek(fd, 0, SEEK_SET);
 if (out != tb)
 chunkqueue_append_buffer_commit(cq);
 
-- 
2.40.1

Bug#1037337: mod_dirindex header/footer displayed only at first request during stat cache period

[Harald Welte]

Package: lighttpd
Version: 1.69-1
Severity: normal

I noticed the following regresion after  upgrading to Debian 12 today:

When mod_dirindex is configured to include a header and/or readme into
the directory index (using the dir-listing.show-header or
dir-listing.show-readme options), said header/readme files are not
included reliably into the HTTP response.

Specifically, it looks as if the first request after a pause (or
restart) gets the header/readme included, but any subsequent requests
inside a certain period are rendered without the header/readme.

I tried different stat-cache implementations: "disable", "inotify" and
"simple" - they all could reproduce the same behaviour.

When strace()ing lighttpd, one can clearly see that the README.txt file
(I use dir-listing.show-readme = "README.txt") access pattern changes:

Working case:
newfstatat(AT_FDCWD, "/data/www/user_dir/HEADER.txt"...
openat(AT_FDCWD, "/data/www/user_dir/HEADER.txt"...

non-working case:
newfstatat(AT_FDCWD, "/data/www/user_dir/HEADER.txt"...

so somehow the file is not opened on the second request.

Some debugging and instrumentation later, it seems that the file is
opened on first access, and then kept open by the stat_cache (even when
"disable" is used, which probably is a separate bug).

However, the mod_dirlisting.c code read()s the file *without rewinding
back after reading it*.  This explains why on first read after open it
succeeds, and subsequent reads then return no data as the read cursor
is already at EOF.

I've so far looked only at debians 1.69-1 sources.  Will check upstream
next and see if there's a fix already available.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 lighttpd depends on:
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  libcrypt1  1:4.4.33-2
ii  libnettle8 3.8.1-2
ii  libpcre2-8-0   10.42-1
ii  libxxhash0 0.8.1-1
ii  lsb-base   11.6
ii  media-types10.0.0
ii  mime-support   3.66
ii  systemd-sysv   252.6-1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages lighttpd recommends:
pn  lighttpd-mod-deflate  
pn  lighttpd-mod-openssl  
ii  perl  5.36.0-7
pn  spawn-fcgi

Versions of packages lighttpd suggests:
ii  apache2-utils 2.4.57-2
pn  lighttpd-doc  
pn  lighttpd-mod-webdav   
pn  lighttpd-modules-dbi  
pn  lighttpd-modules-lua  
ii  openssl   3.0.9-1
pn  php-cgi   
pn  php-fpm   

Bug#1033902: ulogd2 debian package missing PCAP output plugin from upstream

[Harald Welte]

On Tue, Apr 04, 2023 at 08:31:42AM +0100, Chris Boot wrote:
> On 03/04/2023 19:37, Harald Welte wrote:
> > However, I was surprised to see that the ulogd2 package both in Debian 
> > stable as well
> > as unstable doesn't contain the PCAP output plugin.  Is that a conscious 
> > decision? I would
> > think it's a rather useful feature to have.
> 
> It's included in the ulogd2-pcap package, which is separate in order to
> avoid the dependency on libpcap. It was this way even with ulogd 1.x.

ugh.  Somehow that was too obvious. Sorry for the noise.

-- 
- Harald Welte   https://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1033902: ulogd2 debian package missing PCAP output plugin from upstream

[Harald Welte]

Package: ulogd2
Version: 2.0.8-1
Severity: normal

Today  - for the first time in probably 15+ years - I wanted to capture the 
actual packets
dropped within netfilter in a pcap file.  The method I developed during my 
netfilter days
20 year ago for this is the PCAP output plugin of ulogd.

To my knowledge it's the only method which allows you to capture the actual 
binary packet
violating your iptables or nftables policy for later analysis in wireshark or 
other pcap
related tools.

However, I was surprised to see that the ulogd2 package both in Debian stable 
as well
as unstable doesn't contain the PCAP output plugin.  Is that a conscious 
decision? I would
think it's a rather useful feature to have.

Also, the example config file contains PCAP related sections, making this even 
more confusing.  So you
uncomment parts of the example config that gets installed 
(stack=log2:NFLOG,base1:BASE,pcap1:PCAP) and then it
fails due to not finding the PCAP plugin with either with

Apr 03 19:02:11 lakshmi1 ulogd[3579]: can't find requested plugin PCAP

(in the plugin auto-load case , or with

Apr 03 19:02:38 lakshmi1 ulogd[3607]: load_plugin: 
'/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_PCAP.so': 
/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_PCAP.so: cannot open shared object 
file: No such file or directory

(in the case one explicitly wants to load the plugin via the commented-out line 
from the sample config file.

Given that building the pcap plugin is enabled by default, I guess it must be 
explicitly disabled with
--disable-pcap in the debian package, so I guess it's a conscious decision and 
not an accident?

Thanks for looking into this.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 ulogd2 depends on:
ii  adduser3.132
ii  init-system-helpers1.65.2
ii  libc6  2.36-8
ii  libmnl01.0.4-3
ii  libnetfilter-acct1 1.0.3-3
ii  libnetfilter-conntrack31.0.9-3
ii  libnetfilter-log1  1.0.2-3
ii  libnfnetlink0  1.0.2-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-3

ulogd2 recommends no packages.

Versions of packages ulogd2 suggests:
pn  ulogd2-dbi  
pn  ulogd2-json 
pn  ulogd2-mysql
pn  ulogd2-pcap 
pn  ulogd2-pgsql
pn  ulogd2-sqlite3  

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

-- no debconf information

Bug#1030752: request 8.3.0 to be packaged. 8.2.0 is known broken

[Harald Welte]

Package: eclipse-titan
Version: 8.2.0-1
Severity: normal

Unfortunately titan 8.2.0 has many known regressions in encoding messages all 
accross
our test suites, so it is completely unusable.  As 8.3.0 with bugfixes has been
released already on January 16, it would be great to upgrade the debian package
to that 8.3.0 - or alternatively fall back to the last working package before 
8.2.0
was released.

https://projects.eclipse.org/projects/tools.titan/releases/8.3.0


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 eclipse-titan depends on:
ii  expect5.45.4-2+b1
ii  gcc   4:12.2.0-3
ii  libc6 2.36-8
ii  libedit-dev   3.1-20221030-2
ii  libedit2  3.1-20221030-2
ii  libgcc-s1 12.2.0-14
ii  libpcap-dev   1.10.3-1
ii  libpcre3-dev  2:8.39-15
ii  libsctp-dev   1.0.19+dfsg-2
ii  libssl-dev3.0.7-2
ii  libssl3   3.0.7-2
ii  libstdc++612.2.0-14
ii  libxml2   2.9.14+dfsg-1.1+b3
ii  libxml2-dev   2.9.14+dfsg-1.1+b3
ii  make  4.3-4.1
ii  perl  5.36.0-7
ii  python3   3.11.1-3

Versions of packages eclipse-titan recommends:
ii  default-jdk  2:1.17-74

eclipse-titan suggests no packages.

-- no debconf information

Bug#1023958: Request to enable CONFIG_AF_KCM

[Harald Welte]

Package: src:linux
Version: 6.0.8-1
Severity: wishlist

It has been 6 years (since Linux kernel v4.10) that upstream introduced
a rather useful feature for protocols implementing binary message based
protocols on top of TCP called KCM.  Unfortunately during all those
years and even until Debian unstable today, it is not possible to use
this feature as the kernels are compiled with CONFIG_AF_KCM disabled.

This creates a rather unfortunate chicken-and-egg situation where there
are userspace programs/libraries that would benefit from its related
performance, but cannot use it with unmodified Debian kernels and hence
are less motivated to enable it.  So lack of distribution support
hinders adoption by more applications.

Background on KCM can be found at https://lwn.net/Articles/657999/ and
in the kernel source at Documentation/networking/kcm.rst

I would hence like to request enabling CONFIG_AF_KCM in the Debian
kernel packages.  Since STREAM_PARSER and BPF_SYSCALL are both already
enabled, there are no additional dependencies.

AF_KCM can be built as module, so it should not affect any systems where
no applications use it.  It would only be auto-loaded once an AF_KCM
socket is being used for the first time.

Thanks for your consideration.

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 linux-image-6.0.0-4-amd64 depends on:
it  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20220905-1
ii  linux-base  4.9

Versions of packages linux-image-6.0.0-4-amd64 recommends:
iu  apparmor 3.0.7-1+b2
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.0.0-4-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-pc 2.06-4
pn  linux-doc-6.0   

Versions of packages linux-image-6.0.0-4-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20221012-1
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20221012-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1021703: slapd crashes when too many clients connect in a short period of time.

[Harald Welte]

some miscellaneous questions that come to my mind after reading the bug report

* if the slapd is hanging, what does a 'strace' on the PID of the slapd process 
tell you?
* what is the rate of new client connections the triggers the problem for you 
(you can for example check the number of TCP SYN per second to the LDAP port 
via pcap file)?
* can you reproduce the problem irrespective of GSSAPI/kerberos?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#775443: libgpm errors in a lxc container

[Harald Welte]

I'm seeing *tons* of these in a pretty standard debian 11 lxc container
on a debian 10 host.

insie the container:

ii  libgpm2:amd64   1.20.7-8   amd64
General Purpose Mouse - shared library
ii  vim 2:8.2.2434-3+deb11u1   amd64Vi 
IMproved - enhanced vi editor
ii  vim-common  2:8.2.2434-3+deb11u1   all  Vi 
IMproved - Common files
ii  vim-runtime 2:8.2.2434-3+deb11u1   all  Vi 
IMproved - Runtime files

there is no non-standard vim config whatsoever.  It's a pretty stock bullseye 
that I just
created today using 'lxc -t download'

---
Aug 02 16:51:51 vpn vi[9459]: *** err
Aug 02 16:51:51 vpn vi[9459]: unable to open gpm console, check your /dev 
filesystem!
Aug 02 16:51:51 vpn vi[9459]: *** err
Aug 02 16:51:51 vpn vi[9459]: Oh, oh, it's an error! possibly I die!
---
I see lots of repeats every few seconds, possibly every time vim was used?

Clearly running an editor like vim inside a container is nothing unexpected in 
2022,
and shouldn't result in tons of error messages spamming syslog / journal?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1013330: linux-image-5.18.0-0.bpo.1-arm64: kernel panic in dpaa2_eth_free_tx_fd

[Harald Welte]

[   46.826808] Memory Limit: none
[   46.829852] ---[ end Kernel panic - not syncing: Oops: Fatal exception in 
interrupt ]---


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-15-arm64 (SMP w/16 CPU threads)
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 linux-image-5.18.0-0.bpo.1-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.18.0-0.bpo.1-arm64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.18.0-0.bpo.1-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.18  

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1010849: DWARF support disabled during build / no symbolic stack traces or argument types

[Harald Welte]

Package: bpftrace
Version: 0.14.1-3
Severity: normal

It seems the Debian bpftrace is built without libdw support.  This means no 
stack
traces can be provided with uprobes, and one cannot dereference structs or other
type information from the DWARF information.

# bpftrace -lv 'uprobe:/usr/local/lib/libosmocore.so.18.0.0:osmo_timer_schedule'
WARNING: Cannot parse DWARF: libdw not available

# bpftrace --info
System
  OS: Linux 5.16.0-5-amd64 #1 SMP PREEMPT Debian 5.16.14-1 (2022-03-15)
  Arch: x86_64

Build
  version: v0.14.1
  LLVM: 13.0.1
  ORC: v2
  foreach_sym: yes
  unsafe uprobe: no
  bfd: no
  bpf_attach_kfunc: yes
  bcc_usdt_addsem: yes
  bcc bpf_attach_uprobe refcount: yes
  bcc library path resolution: yes
  libbpf: yes
  libbpf btf dump: yes
  libbpf btf dump type decl: yes
  libdw (DWARF support): no
  ^

I'm wondering what is the rationale of not including DWARF support?  Is this
intentional? It renders large portions of uprobe use cases useless.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bpftrace depends on:
ii  libbpf0   1:0.7.0-2
ii  libbpfcc  0.24.0+ds-1
ii  libc6 2.33-7
ii  libclang1-13  1:13.0.1-3+b2
ii  libgcc-s1 12.1.0-1
ii  libllvm13 1:13.0.1-3+b2
ii  libstdc++612.1.0-1

bpftrace recommends no packages.

bpftrace suggests no packages.

-- no debconf information

Bug#1010688: apparmor profile prvents -C -W

[Harald Welte]

putting the following in /etc/apparmor.d/local/usr.bin.tcpdump
works around the problem:

  /**.[pP][cC][aA][pP][0-9]* rw,

please adjust the packaged apparmor profile for stable and unstable to allow
people to use the -C -W option.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1010688: apparmor profile prevents -C -W

[Harald Welte]

Package: tcpdump
Version: 4.99.1-3
Severity: normal

I have this problem both with Debian 11 and debian unstable:

When trying to use something like "-w /some/file/name.pcap -C 1 -W 10" tcpdump
gets -EACCESS when trying to open the file:

openat(AT_FDCWD, "/var/pcap/lapd.pcap0", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 
EACCES (Permission denied)

manually changing UID to tcpdump and trying to create the file works.

audit log shows:

[ 1975.392192] audit: type=1400 audit(1651910055.299:16): apparmor="DENIED" 
operation="mknod" profile="tcpdump" name="/var/pcap/lapd.pcap0" pid=2003 
comm="tcpdump" requested_mask="c" denied_mask="c" fsuid=106 ouid=106

The problem seems to be that the apparmor profile assumes that pcap files end 
in pcap.  However, when using
the -W option, there is a numerical suffix after the pcap, breaking that 
assumption.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tcpdump depends on:
ii  adduser 3.121
ii  libc6   2.33-7
ii  libpcap0.8  1.10.1-4
ii  libssl1.1   1.1.1n-1

tcpdump recommends no packages.

Versions of packages tcpdump suggests:
ii  apparmor  3.0.4-2

-- no debconf information

Bug#1008104: sid: No xserver-xorg-input-{evdev,libinput} after upgrade

[Harald Welte]

Package: xserver-xorg-input-evdev
Version: 1:2.10.6-2+b1
Severity: important

I'm running debian unstable for 15+ years and usually perform an apt upgrade
manually about once per week.  Yesterday I upgraded again, and suddenly after
the upgrade, xserver-xorg-input-{evdev,libinput} were no longer present, meaning
that I could not even enter my username in the display manager (wdm) after 
system reboot.

No input was possible from either the built-in laptop/touchpad of my Lenovo 
x260 keyboard/trackpad,
nor from externally-attached mouse + keyboard.

Luckily I'm technically skilled enough to boot into rescue mode, look at 
Xorg.0.log,
see that no drivers were found for any of the input devices and then apt install
the evdev + libinput packages.

However, for most other users this would render their systems unusable, hence 
I'm marking
the bug as 'important'.

So somehow during the continuous unstable upgrades (which I'm doing for 
something like 4 years
on this laptop) decided that neither evdev nor libinput is a package to keep 
through the most
recent dist-upgrade + autoremove I ran yesterday.  Maybe a missing 
depends/recommends somewhere?


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 27  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb 12 11:32 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD 
Graphics 520] [8086:1916] (rev 07)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1155 Oct 18  2009 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerFlags"
Option  "AllowEmptyInput"   "off"
EndSection

#Section "InputDevice"
#   Identifier  "Generic Keyboard"
#   Driver  "kbd"
#   Option  "XkbRules"  "xorg"
#   Option  "XkbModel"  "pc104"
#   Option  "XkbLayout" "us"
#EndSection

#Section "InputDevice"
#   Identifier  "Configured Mouse"
#   Driver  "mouse"
#EndSection

Section "Device"
Identifier  "Configured Video Device"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
EndSection

Section "Screen"
Identifier  "Default Screen"
Monitor "Configured Monitor"
EndSection

Contents of /etc/X11/xorg.conf.d:
-
total 0

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 5.16.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-18) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 
5.16.14-1 (2022-03-15)

Xorg X server log files on system:
--
-rw-r--r-- 1 laforge laforge  843197 Aug 25  2020 
/space/home/laforge/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 laforge laforge 1492643 Mar 22 10:23 
/space/home/laforge/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 rootroot  75700 Mar 22 15:39 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   715.654] 
X.Org X Server 1.21.1.3
X Protocol Version 11, Revision 0
[   715.654] Current Operating System: Linux nataraja 5.16.0-5-amd64 #1 SMP 
PREEMPT Debian 5.16.14-1 (2022-03-15) x86_64
[   715.654] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.16.0-5-amd64 
root=/dev/mapper/nataraja_x260-root ro swapaccount=1
[   715.654] xorg-server 2:21.1.3-2+b1 (https://www.debian.org/support) 
[   715.654] Current version of pixman: 0.40.0
[   715.654]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   715.654] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   715.654] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 22 11:09:20 
2022
[   715.654] (==) Using config file: "/etc/X11/xorg.conf"
[   715.654] (==) Using 

Bug#1003069: openid exception "AttributeError: module 'base64' has no attribute 'decodestring'"

[Harald Welte]

Package: python3-django-allauth
Version: 0.44.0+ds-1
Severity: normal

I'm running a bullseye installation with mailman3-web and wanted to enable 
openid
authentication via the python3-django-allouth package.  However, when using it,
I get the following exception / backtrace:

ERROR:django.request:Internal Server Error: /accounts/openid/login/
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
34, in inner
response = get_response(request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, 
in _get_response
response = self.process_exception_by_middleware(e, request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, 
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, 
in view
return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, 
in dispatch
return handler(request, *args, **kwargs)
  File 
"/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py",
 line 45, in get
return self.perform_openid_auth(form)
  File 
"/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py",
 line 94, in perform_openid_auth
auth_request = client.begin(endpoint)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 359, 
in begin
return self.beginWithoutDiscovery(service, anonymous)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 382, 
in beginWithoutDiscovery
auth_req = self.consumer.begin(service)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 610, 
in begin
assoc = self._getAssociation(service_endpoint)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 1178, 
in _getAssociation
assoc = self.store.getAssociation(endpoint.server_url)
  File 
"/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/utils.py",
 line 105, in getAssociation
base64.decodestring(stored_assoc.secret.encode("utf-8")),
AttributeError: module 'base64' has no attribute 'decodestring'


It seems like base64.decodestring() has been deprecated since python 3.8 but 
somehow this module
has not been updated.

Upstream has a fix in 
https://github.com/pennersr/django-allauth/commit/425dc774fb5d032204b92f0870c3802202259ad3


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-django-allauth depends on:
ii  python33.9.8-1
ii  python3-cryptography   3.4.8-1
ii  python3-django 2:3.2.10-2
ii  python3-jwt2.1.0-1
pn  python3-openid 
ii  python3-requests   2.25.1+dfsg-2
pn  python3-requests-oauthlib  

python3-django-allauth recommends no packages.

Versions of packages python3-django-allauth suggests:
pn  python-django-allauth-doc  

Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

[Harald Welte]

Dear Micha,

On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:

> in the upstream bug tracker the author suggested this bug to be fixed
> already in versions AqBanking 6.4.1 and Gwenhywfar 5.8.0. 

I built from source and can confirm this is correct.

> I've just uploaded fixed packages to the Debian archive.

I will test them as soon as possible.

The next question is whether there is any need for back-porting the fix to
stable?

AFAICT the relevant fix is actually only one commit:

commit 78d01bb9e0028f79a5dab1e290fa14e7526e4757
Author: Martin Preuss 
Date:   Wed Dec 15 21:42:53 2021 +0100

typemaker2: Fixed a bug (not setting pointers to NULL after free).


-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

[Harald Welte]

On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:
> Would you mind to give these versions another try, once they become
> available?

confirmed fixed in current packages on 'unstable', thanks.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

[Harald Welte]

misc correction: It's probably only about 10 years that I'm using
aqbanking in this setup.  In any case, it has been extremely stable for
me during that time.

As for the actual bug: I built aqbanking 6.3.2 (from upstream git) on
Debian unstable and the same problem can be observed there.  I verified
that the libaqbanking.so from the custom build is used in the process,
so it's clearly not using the Debian-packaged library.

Same also is the case with upstream 6.1.0.  Building 5.8.2 unfortuantely
fails as it expects gwenhywfar-config to be present, while the new
version switched to pkg-config.  Even after patching the autoconf, it's
appears to be impossibel to build an old aqbanking5 against modern
gwenhywfar, so I'm a bit lost.

Is there an easy way to install previous aqbanking packages in unstable
before upgrading to 6.4.x?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001708: setgfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

[Harald Welte]

Package: libaqbanking44
Version: 6.4.0-1
Severity: normal

I'm using aqbanking / aqhbci with HBIC chip card for 20 years now, and it has 
always worked
rather fine in Debian, as far as I can remember.

However, recently, it stopped to work on Debian unstable, while the same 
configuration,
account, data files and HBCI chip card continue to work smoothly on Debian 11 
stable.

So this is a clear regression compared to Debian 11.

The error happens before there is any communication with either the bank or the 
HBCI chip card, merely
while reading the CSV input file with SEPA transfers and building up some 
internal data structures prior
to talking to the bank.   /proc/fd  for the proces shows only 
stdin/stdout/stderr.

$ gdb --args aqbanking-cli sepatransfers -a 663951200 -f 
/tmp/aqbanking_transfers_20211210.csv --profile=sepatransfer
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from aqbanking-cli...
Reading symbols from 
/usr/lib/debug/.build-id/65/920ab0c9608f4b8430b25f041ba00d1734afb9.debug...
(gdb) run
Starting program: /usr/bin/aqbanking-cli sepatransfers -a 663951200 -f 
/tmp/aqbanking_transfers_20211210.csv --profile=sepatransfer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__gmpn_copyi () at tmp-copyi.s:81
81  tmp-copyi.s: No such file or directory.
(gdb) bt
#0  __gmpn_copyi () at tmp-copyi.s:81
#1  0x77db93f4 in AB_Value_dup (ov=0x55605380) at 
./src/libs/aqbanking/types/value.c:69
#2  0x77da8b24 in AB_Transaction_dup (p_src=p_src@entry=0x556053f0)
at ./src/libs/aqbanking/types/transaction.c:771
#3  0x77e2fc33 in AH_Job_TransferBase_HandleCommand_SepaUndated 
(j=0x555c72e0, t=0x556053f0)
at ./src/libs/plugins/backends/aqhbci/ajobs/jobtransferbase.c:524
#4  0x77e931c3 in _addCommandToOutbox (outbox=0x555c4810, 
t=0x556053f0, a=0x55b61780, u=0x555abf10,
pro=0x555f1ec0) at 
./src/libs/plugins/backends/aqhbci/banking/provider_sendcmd.c:178
#5  _addCommandsToOutbox (ctx=0x555edba0, outbox=0x555c4810, 
uql=0x55610920, pro=0x555f1ec0)
at ./src/libs/plugins/backends/aqhbci/banking/provider_sendcmd.c:245
#6  AH_Provider_SendCommands (pro=0x555f1ec0, pq=, 
ctx=0x555edba0)
at ./src/libs/plugins/backends/aqhbci/banking/provider_sendcmd.c:63
#7  0x77d7a612 in _sendProviderQueues (pid=3, ctx=0x55604990, 
pql=0x555b2370, ab=0x555abcb0)
at ./src/libs/aqbanking/banking_online.c:729
#8  _sendCommandsInsideProgress (pid=3, ctx=0x55604990, 
commandList=, ab=0x555abcb0)
at ./src/libs/aqbanking/banking_online.c:578
#9  AB_Banking_SendCommands (ab=0x555abcb0, commandList=, 
ctx=0x55604990)
at ./src/libs/aqbanking/banking_online.c:535
#10 0x55567e91 in execBankingJobs (ab=0x555abcb0, 
tList=0x55598940, ctxFile=0x0)
at ./src/tools/aqbanking-cli/util.c:872
#11 0x5556a048 in sepaMultiJobs (ab=ab@entry=0x555abcb0, 
dbArgs=dbArgs@entry=0x555ab590, argc=argc@entry=6,
argv=argv@entry=0x7fffe5f0, multisepa_type=) at 
./src/tools/aqbanking-cli/sepamultijobs.c:140
#12 0x55560ad6 in main (argc=6, argv=0x7fffe5f0) at 
./src/tools/aqbanking-cli/main.c:395
(gdb) frame 1
#1  0x77db93f4 in AB_Value_dup (ov=0x55605380) at 
./src/libs/aqbanking/types/value.c:69
69mpq_set(v->value, ov->value);
(gdb) p *v
$1 = {_list1_element = 0x55610e10, value = {{_mp_num = {_mp_alloc = 21845, 
_mp_size = 21845, _mp_d = 0x55835ed0},
  _mp_den = {_mp_alloc = 21845, _mp_size = 21845, _mp_d = 
0x55612e40}}}, currency = 0x0}
(gdb) p *ov
$2 = {_list1_element = 0x555f0ef0, value = {{_mp_num = {_mp_alloc = 
1432425056, _mp_size = 21845,
_mp_d = 0x555f0ff0}, _mp_den = {_mp_alloc = 1432430912, _mp_size = 
21845, _mp_d = 0x3}}}, currency = 0x0}
(gdb) frame 2
#2  0x77da8b24 in AB_Transaction_dup (p_src=p_src@entry=0x556053f0)
at ./src/libs/aqbanking/types/transaction.c:771
771 p_struct->taxes=AB_Value_dup(p_src->taxes);
(gdb) p p_src->taxes
$3 = (AB_VALUE *) 0x55605380
(gdb) p *p_src->taxes
$4 = {_list1_element = 0x555f0ef0, value = {{_mp_num 

Bug#1001390: xterm / uxterm / lxterm suddenly missing from alternatives

[Harald Welte]

Hi Sven,

On Thu, Dec 09, 2021 at 07:28:22PM +0100, Sven Joachim wrote:
> There is a postinst script in dpkg which moves the misplaced files from
> /var/lib/dpkg to /var/lib/dpkg/alternatives, but if more than one
> package sets up an alternative, that is apparently not enough.

I didn't have any 'suspicious' files there.

> My recommendation would be to reinstall affected packages like xterm,
> and configure the alternatives again.  

reinstalling xterm solved the problem.

> Sometimes Debian unstable lives by its name, although fortunately not
> too often.

I'm running unstable on my daily desktop + laptop for about 20 years now,
surprisingly few problems, I would say not more than 1-2 per year typically.

This bug can be closed.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001390: xterm / uxterm / lxterm suddenly missing from alternatives

[Harald Welte]

On Thu, Dec 09, 2021 at 05:36:03PM +0100, Sven Joachim wrote:

> Probably you have hit bug #1001198 in dpkg 1.21.0, which corrupts the
> alternatives database.

ugh :(  That may very well be.

> Did you upgrade dpkg to version 1.21.1 yet?  If not, please do so and
> report back.

yes, I do have dpkg version 1.21.1 installed [by now].  Should that have
automagically fixed the corrupted database?  I couldn't immediately see
from #1001198 whether any recovery action is required on affected systems.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001391: vim.basic no longer an alternative for 'vi'?

[Harald Welte]

Package: vim
Version: 2:8.2.3565-1+b1
Severity: normal

aftere the most recent debian unstable package upgrades,
/etc/alternatives/vi suddenly no longer pointed to vim, which it has
been for (as far as I can recall) 20 years or so on my systems.

Investigation shows that indeed /var/lib/dpkg/alternatives/vi no longer
offers 'vim' as an option:


auto
/usr/bin/vi
vi.1.gz
/usr/share/man/man1/vi.1.gz

/usr/bin/nvi
20
/usr/share/man/man1/nvi.1.gz



while on a Debian 10 system it shows:


auto
/usr/bin/vi
vi.1.gz
/usr/share/man/man1/vi.1.gz
vi.da.1.gz
/usr/share/man/da/man1/vi.1.gz
vi.de.1.gz
/usr/share/man/de/man1/vi.1.gz
vi.fr.1.gz
/usr/share/man/fr/man1/vi.1.gz
vi.it.1.gz
/usr/share/man/it/man1/vi.1.gz
vi.ja.1.gz
/usr/share/man/ja/man1/vi.1.gz
vi.pl.1.gz
/usr/share/man/pl/man1/vi.1.gz
vi.ru.1.gz
/usr/share/man/ru/man1/vi.1.gz

/usr/bin/vim.basic
30
/usr/share/man/man1/vim.1.gz
/usr/share/man/da/man1/vim.1.gz
/usr/share/man/de/man1/vim.1.gz
/usr/share/man/fr/man1/vim.1.gz
/usr/share/man/it/man1/vim.1.gz
/usr/share/man/ja/man1/vim.1.gz
/usr/share/man/pl/man1/vim.1.gz
/usr/share/man/ru/man1/vim.1.gz



Is this intentional? I couldn't find any notice of it in changelog.Debian.


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/nvi
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/bin/vim.gtk3

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim depends on:
ii  libacl1  2.3.1-1
ii  libc62.32-5
ii  libgpm2  1.20.7-9
ii  libselinux1  3.3-1+b1
ii  libsodium23  1.0.18-1
ii  libtinfo66.3-1
ii  vim-common   2:8.2.3565-1
ii  vim-runtime  2:8.2.3565-1

vim recommends no packages.

Versions of packages vim suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-15
ii  universal-ctags [ctags]  5.9.20210829.0-1
ii  vim-doc  2:8.2.3565-1
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1001390: xterm / uxterm / lxterm suddenly missing from alternatives

[Harald Welte]

Package: xterm
Version: 370-1
Severity: normal

After upgrading xterm to the most recent package in xterm,
suddenly the x-terminal-emulator alternative was pointing
to gnome-terminal instead of uxterm (before the upgrade).

Even worse, xterm and uxterm are apparently no longer even
registered with the alternatives mechanism.

I checked the debian changelog, and it didn't state any
related change.

So I conclude this is a bug and xterm / uxterm / lxterm
should of course still show up in the alternatives, as it
has always been.

/var/lib/dpkg/alternatives/x-terminal-emulator on unstable:

---
/usr/bin/x-terminal-emulator
x-terminal-emulator.1.gz
/usr/share/man/man1/x-terminal-emulator.1.gz

/usr/bin/gnome-terminal.wrapper
40
/usr/share/man/man1/gnome-terminal.1.gz
---



/var/lib/dpkg/alternatives/x-terminal-emulator on Debian 10:

---
/usr/bin/x-terminal-emulator
x-terminal-emulator.1.gz
/usr/share/man/man1/x-terminal-emulator.1.gz

/usr/bin/koi8rxterm
20
/usr/share/man/man1/koi8rxterm.1.gz
/usr/bin/lxterm
30
/usr/share/man/man1/lxterm.1.gz
/usr/bin/uxterm
20
/usr/share/man/man1/uxterm.1.gz
/usr/bin/xterm
20
/usr/share/man/man1/xterm.1.gz
---



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.32-5
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.11.0+dfsg-1
ii  libice6 2:1.0.10-1
ii  libtinfo6   6.3-1
ii  libutempter01.2.1-2
ii  libx11-62:1.7.2-2+b1
ii  libxaw7 2:1.0.13-1.1
ii  libxext62:1.3.4-1
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.2.0-1
ii  xbitmaps1.1.1-2.1

Versions of packages xterm recommends:
ii  x11-utils  7.7+5

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#1001328: closed by Debian FTP Masters (reply to Nicolas Mora ) (Bug#1001328: fixed in ulfius 2.7.7-1)

[Harald Welte]

Thanks a lot for the very fast response in tagging 2.7.7 and hence fixing the 
problem
for unstable.  

However, I am not sure if this bug should be closed yet as 'stable'
(debian 11 / bullseye)  also must be fixed.  As bullseye cannot update
the upstream package version, a patch must be introduced to the Debian
package.

Or Should there be a separate Debian bug filed for bullseye?

Regards,
Harald

On Wed, Dec 08, 2021 at 10:51:07PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libulfius2.7 package:
> 
> #1001328: ulfius_url_{encode,decode} call malloc instad of o_malloc
> 
> It has been closed by Debian FTP Masters  
> (reply to Nicolas Mora ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Nicolas Mora 
> ) by
> replying to this email.
> 
> 
> -- 
> 1001328: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001328
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Wed, 08 Dec 2021 22:49:03 +
> From: Debian FTP Masters 
> To: 1001328-cl...@bugs.debian.org
> Subject: Bug#1001328: fixed in ulfius 2.7.7-1
> 
> Source: ulfius
> Source-Version: 2.7.7-1
> Done: Nicolas Mora 
> 
> We believe that the bug you reported is fixed in the latest version of
> ulfius, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1001...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Nicolas Mora  (supplier of updated ulfius package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Wed, 08 Dec 2021 17:27:55 -0500
> Source: ulfius
> Architecture: source
> Version: 2.7.7-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian IoT Maintainers 
> 
> Changed-By: Nicolas Mora 
> Closes: 1000989 1001328
> Changes:
>  ulfius (2.7.7-1) unstable; urgency=medium
>  .
>[Paride Legovini]
>* d/t/unit-test: run with ::1 in no_proxy (LP: #1945634)
>  .
>[Nicolas Mora]
>* New upstream release (Closes: #1001328)
>* Fix testsuite fail with proxy (Closes: #1000989)
> Checksums-Sha1:
>  bc04f875dd92b8b321e06eafadde43e49f0e 2383 ulfius_2.7.7-1.dsc
>  d90f0b97fa56eb843262917efdac6150f48e36cd 254242 ulfius_2.7.7.orig.tar.gz
>  43d07ea68eb09fd23392037c77dae9593b587f71 8136 ulfius_2.7.7-1.debian.tar.xz
>  45088fb5008d501b4eea6be734c8f4073a074ee3 9007 ulfius_2.7.7-1_amd64.buildinfo
> Checksums-Sha256:
>  d8928e0c34c8fd2aae09c34f3609dcadb710ad6acdbabed850d15215d892fdc3 2383 
> ulfius_2.7.7-1.dsc
>  e39bfac8e6ef3ed1b2633d4d617f82549ed88b0f2bb0bc85928d1189c4d2e0de 254242 
> ulfius_2.7.7.orig.tar.gz
>  c57370a08744e1ef69e442f9ceacb1aa43affa74d921791e3557f70257311704 8136 
> ulfius_2.7.7-1.debian.tar.xz
>  e7370d60798c3d39a495d9b0672fc49ab9f82d8809d4c35501092a8d9bc49a48 9007 
> ulfius_2.7.7-1_amd64.buildinfo
> Files:
>  4c422f579f4d516b21439b3d6e0c7fd8 2383 devel optional ulfius_2.7.7-1.dsc
>  79ddaefa4a340af5ff98c3578f3a6ea7 254242 devel optional 
> ulfius_2.7.7.orig.tar.gz
>  5d1c4412d40793fd98f0854947b42aa6 8136 devel optional 
> ulfius_2.7.7-1.debian.tar.xz
>  827592668a59abfaeb867a287d275a1e 9007 devel optional 
> ulfius_2.7.7-1_amd64.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEhAWwL8wo75dEyPJT/oITlEC9IrkFAmGxMhYACgkQ/oITlEC9
> Irnd6RAApgAv0IL3ghLnZvDXx9vPi87yD/DFrV0siy+3dFYHVvXVpvGLV3Y+Waej
> WkW9hrrax/6NmAQrKRBJQAO4hMbE/jCSwokrmeMhTsq/Yh6dEF8YKUd/TCOd5uM0
> +rdg/mEt2k3izb6S0MH2HznZKRce4cFUVJoND2m9sN7HnXdHl7G96e1103REOtNA
> fhzS2MhPcXyChoADOdyfEK6IkLU7LfK2Av59uLazVZYBXLYzThIn0VKfZH1RL02A
> Bsw4kmEbDlM9DpMILR8tUIgv3RqjryG9pqmd7MQPDaIQaiV4MrO2vYCLxOnyNUbn
> 7I2nV8jYJlyw4IyJkNfjonaclIsOChUZNYl4N/id8JTgjxMjUNiDszjhFFZz9kdr
> yXqoSP++WoySHpVz7qm3oo27s/n+YVKZoI2jT+B9fwcMM/q7tZvVwnhhvLIx2f+4
> JXRPFbHSk/6sGv6dyjgkKRJspdMGZ/T+RtXuuyllkDfTOrVanUWDjZZmks5dmay4
> 2BHDFhmIY1B7G6mzxyUl8Zww6qzceG74B0lYhdlaLAzy/ONTFDQwU6NkaO82bRaP
> R5khmDs177eiL6iqMIMXtVkLDekJHz0LSciGHymfD03zpDVdY9ENNh0oYCiAURxe
> YYaz4mMdTMkNtgWEwvoBvEjaqF1BDWKL+VqAh8eA8fDT6ABP/es=
> =MPC8

Bug#1001328: Acknowledgement (ulfius_url_{encode,decode} call malloc instad of o_malloc)

[Harald Welte]

The pull request has been merged (very quickly) upstream.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001328: ulfius_url_{encode,decode} call malloc instad of o_malloc

[Harald Welte]

Package: libulfius2.7
Version: 2.7.6-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: Nicolas Mora 

Ulfius has the capability of applications registering their own memory
allocation functions using o_set_alloc_funcs(), as described in API.md
at 
https://github.com/babelouest/ulfius/blob/master/API.md#memory-management

Applications such as osmo-remsim make use of this feature to introduce
libtalloc as a tool to help locating memory leaks.

However, from 2.6.0 up to 2.7.6 and current master, ulfius introduced
a bug which renders this feature unusable:  Some new code started to bypass
the application-provided malloc-functio but directly call libc-malloc
while passing that libc-malloc-allocated memory to the application-provided
free-function.  As every memory allocator expects to receive only memory it
has allocated to its free-function, this immediately crashes every application
with custom allocator functions.

The upstream bug report is at https://github.com/babelouest/ulfius/issues/206

The upstream pull request is at https://github.com/babelouest/ulfius/pull/207

Debian will need to patch/update the ulfius packages for bullseye + sid.
Debian buster is not affected, as it still ships ulfius 2.5.x which is prior
to introducing the bug.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libulfius2.7 depends on:
ii  libc62.32-5
ii  libcurl3-gnutls  7.79.1-2
ii  libgnutls30  3.7.2-2
ii  libjansson4  2.13.1-1.1
ii  libmicrohttpd12  0.9.73-4
ii  liborcania2.22.2.1-1+b1
ii  libyder2.0   1.4.14-1
ii  zlib1g   1:1.2.11.dfsg-2

libulfius2.7 recommends no packages.

libulfius2.7 suggests no packages.

-- no debconf information
>From a2951c32475a79fccfaa06b7c3c36297c6f6cf5b Mon Sep 17 00:00:00 2001
From: Harald Welte 
Date: Wed, 8 Dec 2021 16:57:12 +0100
Subject: [PATCH] u_request: Don't use malloc, but always o_malloc

Allocating memory using malloc, but then free'ing it using o_free will
not work for anyone using a custom memory allocator.   The allocations
and free's must either both go to libc, or both via the custom
allocator; one cannot allocate one way and release another.

Closes: #206
---
 src/u_request.c | 2 +-
 src/ulfius.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/u_request.c b/src/u_request.c
index 385572b..8203c5e 100644
--- a/src/u_request.c
+++ b/src/u_request.c
@@ -143,7 +143,7 @@ static char from_hex(char ch) {
  */
 static char * url_decode(const char * str) {
   if (str != NULL) {
-char * pstr = (char*)str, * buf = malloc(strlen(str) + 1), * pbuf = buf;
+char * pstr = (char*)str, * buf = o_malloc(strlen(str) + 1), * pbuf = buf;
 while (* pstr) {
   if (* pstr == '%') {
 if (pstr[1] && pstr[2]) {
diff --git a/src/ulfius.c b/src/ulfius.c
index 0d7da36..8a0caa6 100644
--- a/src/ulfius.c
+++ b/src/ulfius.c
@@ -1842,7 +1842,7 @@ static char to_hex(char code) {
 char * ulfius_url_encode(const char * str) {
   char * pstr = (char*)str, * buf = NULL, * pbuf = NULL;
   if (str != NULL) {
-buf = malloc(strlen(str) * 3 + 1);
+buf = o_malloc(strlen(str) * 3 + 1);
 if (buf != NULL) {
   pbuf = buf;
   while (* pstr) {
@@ -1876,7 +1876,7 @@ char * ulfius_url_encode(const char * str) {
 char * ulfius_url_decode(const char * str) {
   char * pstr = (char*)str, * buf = NULL, * pbuf = NULL;
   if (str != NULL) {
-buf = malloc(strlen(str) + 1);
+buf = o_malloc(strlen(str) + 1);
 if (buf != NULL) {
   pbuf = buf;
   while (* pstr) {
-- 
2.34.1

Bug#1000956: update eclipse-titan to upstream 8.0.0 or 8.1.0

[Harald Welte]

Hi Greg,

thanks a lot for your super-quick response, it is much appreciated.

I'm happy that my report has helped to fix the process from now on.

Thanks again!

Regards,
Harald

On Wed, Dec 01, 2021 at 01:38:08PM +0100, Pilisi Gergely wrote:
> Hi Harald,
> 
> there was some misunderstanding here. Elemer has left the Titan team and
> the new manager
> didn't know enough about the Debian release process, so nobody asked me to
> create a new package.
> We just clarified the situation and everything will be smoother in the
> future. Actually the newest version
> of Titan is on the Mentor's site right now and waiting for approval. Hold
> on just a little more please. ;)
> 
> BR,
> Greg
> 
> Harald Welte  ezt írta (időpont: 2021. dec. 1., Sze,
> 13:21):
> 
> > Package: eclipse-titan
> > Version: 7.2.0-1.1
> > Severity: wishlist
> >
> > I just noticed that even unstable still ships eclipse-titan 7.2, while
> > upstream has released 8.0.0 in August 2021 and now already 8.1.0 yesterday.
> >
> > It is my general assumption (I may be wrong) that unstable is tracking
> > upstream
> > with relatively small delay, so that whenever stabilization of a new
> > debian release
> > happens the then-latest versions of the software are frozen.  If unstable
> > lags
> > behind upstream significantly, then the versions appearing in stable
> > distributions
> > are going to be even older.
> >
> > Maybe the new upstream releases were just not noticed?  Or are there known
> > problems
> > why one should avoid upgrading?
> >
> > Thanks in advance!
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
> > Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
> > not set
> > Shell: /bin/sh linked to /bin/bash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages eclipse-titan depends on:
> > ii  expect5.45.4-2+b1
> > ii  gcc   4:11.2.0-2
> > ii  libc6 2.32-4
> > ii  libedit-dev   3.1-20210910-1
> > ii  libedit2  3.1-20210910-1
> > ii  libgcc-s1 11.2.0-12
> > ii  libpcap-dev   1.10.1-4
> > ii  libpcre3-dev  2:8.39-13
> > ii  libsctp-dev   1.0.19+dfsg-1
> > ii  libssl-dev1.1.1l-1
> > ii  libssl1.1 1.1.1l-1
> > ii  libstdc++6    11.2.0-12
> > ii  libxml2   2.9.12+dfsg-5+b1
> > ii  libxml2-dev   2.9.12+dfsg-5+b1
> > ii  make  4.3-4.1
> > ii  perl  5.32.1-6
> > ii  python3   3.9.8-1
> >
> > Versions of packages eclipse-titan recommends:
> > ii  default-jdk  2:1.11-72
> >
> > eclipse-titan suggests no packages.
> >
> > -- no debconf information
> >

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1000956: update eclipse-titan to upstream 8.0.0 or 8.1.0

[Harald Welte]

Package: eclipse-titan
Version: 7.2.0-1.1
Severity: wishlist

I just noticed that even unstable still ships eclipse-titan 7.2, while
upstream has released 8.0.0 in August 2021 and now already 8.1.0 yesterday.

It is my general assumption (I may be wrong) that unstable is tracking upstream
with relatively small delay, so that whenever stabilization of a new debian 
release
happens the then-latest versions of the software are frozen.  If unstable lags
behind upstream significantly, then the versions appearing in stable 
distributions
are going to be even older.

Maybe the new upstream releases were just not noticed?  Or are there known 
problems
why one should avoid upgrading?

Thanks in advance!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eclipse-titan depends on:
ii  expect5.45.4-2+b1
ii  gcc   4:11.2.0-2
ii  libc6 2.32-4
ii  libedit-dev   3.1-20210910-1
ii  libedit2  3.1-20210910-1
ii  libgcc-s1 11.2.0-12
ii  libpcap-dev   1.10.1-4
ii  libpcre3-dev  2:8.39-13
ii  libsctp-dev   1.0.19+dfsg-1
ii  libssl-dev1.1.1l-1
ii  libssl1.1 1.1.1l-1
ii  libstdc++611.2.0-12
ii  libxml2   2.9.12+dfsg-5+b1
ii  libxml2-dev   2.9.12+dfsg-5+b1
ii  make  4.3-4.1
ii  perl  5.32.1-6
ii  python3   3.9.8-1

Versions of packages eclipse-titan recommends:
ii  default-jdk  2:1.11-72

eclipse-titan suggests no packages.

-- no debconf information

Bug#999864: bladerf 2.0 xA5 not supported even in ustable/experimental

[Harald Welte]

Package: bladerf
Version: 0.2019.07-7
Severity: normal
X-Debbugs-Cc: 

The currently available bladerf 2.0 xA5 is supported by the latest released 
version of the upstream bladeRF package (2021-10), but not by the earlier 
verisons currently in unstable or experimental.

Due to the global chip shortage this new hardware version had to be introduced, 
see https://www.nuand.com/introducing-the-bladerf-2-0-micro-xa5/ as a 
replacement to the xA4.  As far as I know, only the FPGA size is different.

It would be great to see the debian package upgrade to the 2021-10 version 
which has been released on October 5: 
https://github.com/Nuand/bladeRF/releases/tag/2021.10

Thanks in advance

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bladerf depends on:
ii  libbladerf2  0.2019.07-7
ii  libc62.32-4
ii  libtecla11.6.3-3

bladerf recommends no packages.

bladerf suggests no packages.

-- no debconf information

Bug#999372: asciidoc: Slidy backend broken: 2× "WARNING: include file not found: /etc/asciidoc/javascripts/[…].js"

[Harald Welte]

I can confirm this bug also.  I frequently use asciidoc slidy to generate
presentation slides, and it stooped to work in Debian unstable after
asciidoc 10.x was packaged.

Error message is exactly those two missing javascript files as in the original
bug report.

Building the same slides in Debian 10 or Debian 11 works just fine with the
respective older asciidoc versions.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#931339: dirmgr in buster now points to invalid key servers

[Harald Welte]

I've seen this has already been fixed in bullseye, but a current debian
stable/buster now ships with a default keyserver that has non-resolving
DNS records. (pool.sks-keyservers.net).

This in turn makes any application using dirmgr unusable by default.

One such example being 'lxc-create -t download' which now fails on a
non-customized buster installation.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#983764: /usr/share/chipcard/cards/README missing

[Harald Welte]

Hi Micha,

thanks for your super-quick response.

On Mon, Mar 01, 2021 at 02:57:31PM +0100, Micha Lenk wrote:
> When removing that apparently bogus file, I didn't expect it to break the
> chipcard-tool binary. What a weird dependency...

Indeed, it is a very big surprise to me that the code would test for a README
file, rather than the actual xml data files in that directory...

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#983764: /usr/share/chipcard/cards/README missing

[Harald Welte]

Package: libchipcard-data
Version: 5.1.5rc2-6
Severity: important

Since the most recent update to libchipcard-date in unstable
yesterday, aqbanking-cli doesn't work with chipcard based banking
anymore:

chipcard-tool(31256):client.c:  215: Data files not found (-51)

Doing an strace showed that the program checks for the presence of
/usr/share/chipcard/cards/README and then fails if that doesn't exist.

A simple "sudo touch /usr/share/chipcard/cards/README" made aqbanking-cli
work again.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- Configuration Files:
/etc/chipcard/client/chipcardc.conf changed:
char resmgr="pcsc"
server {
  char typ="local"
  char addr="/var/run/chipcard/chipcard.comm"
} # service


-- no debconf information

Bug#983350: titan manuals not packaged

[Harald Welte]

Package: eclipse-titan
Version: 7.2.0-1
Severity: minor

the upstream eclipse-titan package contains an extensive set of user
manuals in asciidoc format.  If enabled, those asciidoc files are compiled
into PDF manuals.

It would be great if building the documentation was enabled by the debian
package, and the resulting manuals could be made available for example
in a eclipse-titan-doc package.

This way, users would always have the matching documentation for the version
they have installed, without having to obtain it from third-party sources.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eclipse-titan depends on:
ii  expect5.45.4-2+b1
ii  gcc   4:10.2.1-1
ii  libc6 2.31-9
ii  libedit-dev   3.1-20191231-2+b1
ii  libedit2  3.1-20191231-2+b1
ii  libgcc-s1 10.2.1-6
ii  libpcap-dev   1.10.0-2
ii  libpcre3-dev  2:8.39-13
ii  libsctp-dev   1.0.18+dfsg-1
ii  libssl-dev1.1.1j-1
ii  libssl1.1 1.1.1j-1
ii  libstdc++610.2.1-6
ii  libxml2   2.9.10+dfsg-6.3+b1
ii  libxml2-dev   2.9.10+dfsg-6.3+b1
ii  make  4.3-4
ii  perl  5.32.1-2
ii  python3   3.9.1-1

Versions of packages eclipse-titan recommends:
ii  default-jdk  2:1.11-72

eclipse-titan suggests no packages.

-- no debconf information

Bug#981732: missing dependency on prawn/templates

[Harald Welte]

Package: ruby-asciidoctor-pdf
Version: 1.5.4-2
Severity: grave

I just did 'apt-get install asciidoctor ruby-asciidoctor-pdf' and then tried
to build an asciidoc document (in this case the titan.core API guide):

asciidoctor-pdf --attribute skip-front-matter apiguide/Apiguide.adoc
Traceback (most recent call last):
5: from /usr/bin/asciidoctor-pdf:7:in `'
4: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
3: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
2: from /usr/lib/ruby/vendor_ruby/asciidoctor/pdf.rb:8:in `'
1: from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require': 
cannot load such file -- prawn/templates (LoadError)
make: *** [Makefile:60: apiguide/Apiguide.pdf] Error 1

I know close to nothing about ruby, but it look like asciidoctor-pdf or one of 
its upstream
dependencies depend on 'prawn/templates', but those are not installed by the 
dpgk/apt
dependencies.

Indeed, there is "require 'prawn/templates'" in 
/usr/lib/ruby/vendor_ruby/asciidoctor/pdf.rb

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-asciidoctor-pdf depends on:
ii  ruby  1:2.7+2
ii  ruby-asciidoctor  2.0.12-2
ii  ruby-concurrent   1.1.6+dfsg-3
ii  ruby-prawn2.3.0+dfsg-1
ii  ruby-prawn-icon   2.5.0-1
ii  ruby-prawn-svg0.31.0-1
ii  ruby-prawn-table  0.2.2-1
ii  ruby-safe-yaml1.0.5-1
ii  ruby-thread-safe  0.3.6-1
ii  ruby-treetop  1.6.8-1

ruby-asciidoctor-pdf recommends no packages.

Versions of packages ruby-asciidoctor-pdf suggests:
pn  ruby-rouge  

-- no debconf information

Bug#939435: cgroupfs-mount: mount a name=systemd cgroup hierarchy for lxc

[Harald Welte]

Hi guys,

I can confirm this problem (now) exists on debian unstable using
* 5.9.0-5-amd64 / linux-image-5.9.0-5-amd64 / 5.9.15-1
* cgroupfs-mount 1.4

It used to work until some weeks ago, but I cannot exactly pinpoint the time.

I got the "Cgroup v1 clone_children flag: missing" output until I entered
the mkdir + mount for /sys/fs/cgroup/systemd

I could not start unprivileged containers (neither debian10 nor centos8)
until I added the mkdir+mount on the "host"

After adding that mkdir+mount on the Debian unstable host,
I also had the same problem inside a debian9 container: I could not start
docker inside a Debian 9 container until adding the mkdir+mount inside
the Debian9 container.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#977949: ipmi-console doesn't need root and should be in /usr/bin

[Harald Welte]

Package: freeipmi-tools
Version: 1.6.4-3
Severity: minor
X-Debbugs-Cc: 

The ipmi-console command can be executed by any normal user and doesn't
require "system administrator" (aka "root") permission., IMHO, it should
hence be installed to /usr/bin, and not to /usr/sbin., The fact that you
are accessing an IPMO SoL console of another machine, (of which you may
be the system administrator) doesn't mean you have to be the system
administrator of the client running ipmi-console.

Debian FHS 3.0 states:

> Utilities used for system administration (and other root-only
> commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin.

This implies that not only the "other" commands but also the utilities
for system-administration are "root-only" - which in the case of
ipmi-console they clearly are not.

I'm not familiar enough with other parts of freeipmi-tools, there
might be more commands that share a similar situation.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freeipmi-tools depends on:
ii  freeipmi-common  1.6.4-3
ii  libc62.31-6
ii  libfreeipmi171.6.4-3
ii  libipmiconsole2  1.6.4-3
ii  libipmidetect0   1.6.4-3

freeipmi-tools recommends no packages.

Versions of packages freeipmi-tools suggests:
pn  freeipmi-bmc-watchdog  
pn  freeipmi-ipmidetect

-- no debconf information

Bug#907240: ITP: nextpnr -- Portable FPGA place and route tool

[Harald Welte]

Hi Ruben,

as usual, your efforts are much appreciated.  Thanks a lot!

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#907240: Status of nextpnr packaging

[Harald Welte]

AFAICT Ruben had indicated in mid-2018 he wants to package, and Nathanial
worked on a duplicate in mid-2020 but never  got any response.

It's great that we have yosys in Debian now - but it's not quite as useful
particularly to many ICE40 users without nextpnr...

So if there is anything that can be done to unblock this, it would be
greatly appreciated. Thanks!

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#977041: libapt-pkg5.0: apt install segfaults

[Harald Welte]

Package: libapt-pkg5.0
Version: 1.4.11
Severity: important

Dear Maintainer,

Using a clean debian:stretch container of today (2020-12-10) from
hub.docker.com suddenly makes "apt install" of a single dpkg package
segfault:

root@5a1043034f18:/tmp# apt-get install
/tmp/libfftranscode0_0.3_amd64.deb 
Reading package lists... Done
Segmentation fault (core dumped)

with backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x7f4e926c4140 in pkgPolicy::InitDefaults() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(gdb) bt full
#0  0x7f4e926c4140 in pkgPolicy::InitDefaults() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
No symbol table info available.
#1  0x7f4e926c5e74 in pkgPolicy::pkgPolicy(pkgCache*) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
No symbol table info available.
#2  0x7f4e92601d6c in pkgCacheFile::BuildPolicy(OpProgress*) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
No symbol table info available.
#3  0x7f4e92602d23 in pkgCacheFile::Open(OpProgress*, bool) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
No symbol table info available.
#4  0x7f4e9294f0cc in DoInstall(CommandLine&) () from 
/usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
No symbol table info available.
#5  0x7f4e92619056 in CommandLine::DispatchArg(CommandLine::Dispatch 
const*, bool) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
No symbol table info available.
#6  0x7f4e929402ae in DispatchCommandLine(CommandLine&, 
std::vector > 
const&) () from /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
No symbol table info available.
#7  0x5581226c6726 in ?? ()
No symbol table info available.
#8  0x7f4e91c5a2e1 in __libc_start_main (main=0x5581226c6660, argc=3, 
argv=0x7ffdd841ce58, 
init=, fini=, rtld_fini=, 
stack_end=0x7ffdd841ce48)
at ../csu/libc-start.c:291
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -7075202461956481313, 
94013116672000, 
140728231644752, 0, 0, -3947932273984315681, 
-4012509856963535137}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7ffdd841ce78, 
0x7f4e92da6170}, data = {
  prev = 0x0, cleanup = 0x0, canceltype = -666775944}}}
not_first_call = 
#9  0x5581226c682a in ?? ()
No symbol table info available.


Unfortunately there's no -dbg package available for libapt-pkg, so I
cannot get symbol intformation for the backtrace.

There is nothing special about this system.  The very same dpkg package
could be installed without any problems for many months, but suddenly
there is a regresion.  Our CI jobs perform this package installation on
debian:stretch many times each day.  It always worked before.

The package is available from
https://ftp.osmocom.org/binaries/libfftranscode/libfftranscode0_0.3_amd64.deb
it's source cdoe is not available but it was built like any normal
debian packge.

Installing it straight away via dpkg works fine:


root@5a1043034f18:/tmp# dpkg -i ./libfftranscode0_0.3_amd64.deb 
Selecting previously unselected package libfftranscode0:amd64.
(Reading database ... 20865 files and directories currently installed.)
Preparing to unpack .../libfftranscode0_0.3_amd64.deb ...
Unpacking libfftranscode0:amd64 (0.3) ...
Setting up libfftranscode0:amd64 (0.3) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...

-- System Information:
Debian Release: 9.13
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libapt-pkg5.0 depends on:
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-11+deb9u4
ii  libgcc1 1:6.3.0-18+deb9u1
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libstdc++6  6.3.0-18+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages libapt-pkg5.0 recommends:
ii  apt  1.4.11

libapt-pkg5.0 suggests no packages.

-- no debconf information

Bug#957465: Upstream fix

[Harald Welte]

FYI: by now we also have tagged a number of 'gcc-10 compile fix' patch releases.

libosmocore 1.3.2
libosmo-sccp 1.2.1
osmo-bts 1.2.1
osmo-bsc 1.6.1
osmo-msc 1.6.2
osmo-iuh 0.6.1

So you have the choice of cherry-picking the gcc-10 compile fixes for those
pcakages, or to simply upgrade to those patch releases, which contain no changes
other than the gcc-10 compile fixes.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#965326: Changelogs of 'linux' package in stretch+buster are 404

[Harald Welte]

Package: ftp.debian.org
Severity: important
X-Debbugs-Cc: 

When accessing https://packages.debian.org/source/buster/linux and
selecting 'Debian Changelog', I get directed to
https://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_4.19.118-2+deb10u1_changelog
which prints '404 Not Found'., , The same happens when trying to get the
ChangeLog for the stretch 'linux' Changelog.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#947863: lxc: apparmor denied mount with unprivileged lxc

[Harald Welte]

I'm seeing this problem all the time when using a pretty default Debian buster
host with Debian buster lxc containers.

If you then use the standard Debian 'certbot' package inside the lxc container,
it will fail to be executed every time:

Host:
[15500835.942037] audit: type=1400 audit(1594975170.691:971): apparmor="DENIED" 
operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=20567 comm="(certbot)" 
flags="rw, rslave"

LXC:
Jul 17 10:39:30 people systemd[5522]: certbot.service: Failed to set up mount 
namespacing: Permission denied
Jul 17 10:39:30 people systemd[5522]: certbot.service: Failed at step NAMESPACE 
spawning /usr/bin/certbot: Permission denied


Isn't 'debian 10 lxc container' inside 'debian 10 host' something that should
work out of the box, both for privileged and unprivileged containers?  And 
isn't the
use of certbot pretty much the most common thing to do for any machine exposing 
https
to the internet today?

I guess what triggers all of this is the PrivateTmp=true in certbot.service?

In any case, this problem seems to be around for more than 1.5 years by now,
with various ugly workarounds in existance.

* https://github.com/lxc/lxc/pull/2758
* https://github.com/lxc/lxc/issues/2778
* Ubuntu patched systemd to ignore setting up namespaces: 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=030919ba5e4931d6ee576d0259fae67fe4ed9770

In the end, I agree with josch's comment: If unprivileged containers are not
expected to run with apparmor at all, then why does the default config not
disable that?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#957651: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/osmo-bts/+/17916
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#957634: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/openbsc/+/17917
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#957649: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/osmo-bsc/+/17914
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#957652: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/osmo-iuh/+/17915
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#957463: Upstream fix

[Harald Welte]

Upstream fix is available at https://gerrit.osmocom.org/c/libosmo-sccp/+/17911

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#957465: Upstream fix

[Harald Welte]

is available in in https://gerrit.osmocom.org/c/libosmocore/+/17910

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#953026: python-stdnum fails to validate new Dutch BTW/VAT number format

[Harald Welte]

Package: python-stdnum
Version: 1.5-1

The problem is that from January 1st, Dutch BTW (VAT) numbers can have two valid
formats, and python stdnum < 1.13 only understands the old format.  This
creates various failures in downstream application software that relies
on stdnum.nl.btw accepting all valid VAT numbers.

See https://github.com/arthurdejong/python-stdnum/issues/182

The btw-identificatienummer has been introduced on January 1st 2020 in
the Netherlands as an alternative to the btw-nummer that contains the
BSN personal identifier. The number has the same structure and function
but does not contain a BSN and uses a different check digit algorithm.

More information:

* 
http://kleineondernemer.nl/index.php/nieuw-btw-identificatienummer-vanaf-1-januari-2020-voor-eenmanszaken
* https://nl.wikipedia.org/wiki/Btw-nummer_(Nederland)
* 
https://www.belastingdienst.nl/wps/wcm/connect/bldcontenten/belastingdienst/business/vat/new-vat-id/
* 
https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/btw/administratie_bijhouden/btw_nummers_controleren/uw_btw_nummer

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#944848: aqbanking: After upgrade plugin ddvcard not found

[Harald Welte]

Package: libchipcard-libgwenhywfar78-plugins
Version: 5.1.4rc1-2
Followup-For: Bug #944848

I'm observing a similar problem with plugin starcoscard not found after upgrade.

I've been using aqbanking with chipcard of Deutsche Bank for about 15 years 
without
any trouble.  Hoewver, when upgrading the packages recently, the following 
error message
started to be printed:

3:2019/11/20 12-09-44:gwen(433298):plugin.c:  401: Plugin "starcoscard" not 
found.

It appears that somehow during the upgrade, the package 
libchipcard-libgwenhywfar78-plugins
was not installed (missing dependency?) and as a result, the related plugin is 
missing.

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

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

Versions of packages libchipcard-libgwenhywfar78-plugins depends on:
ii  libc62.29-3
ii  libchipcard6 5.1.4rc1-2
ii  libgwenhywfar78  4.99.24rc8-1

libchipcard-libgwenhywfar78-plugins recommends no packages.

libchipcard-libgwenhywfar78-plugins suggests no packages.

-- no debconf information

Bug#939974: bug has been resolved

[Harald Welte]

I can conform that the recent introduction of uhd 3.14.1.1-1 has fixed
the FTBFS and the package is building fine again.

-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#940135: close confirmed

[Harald Welte]

I can confirm that building osmo-trx against libuhd-dev 3.14.1.1-1 now
works again as expected. Thanks!
-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#934134: seabios: Unable to install FreeDOS

[Harald Welte]

I can confirm this problem.  It also happens here, when trying to install
FreeDOS 1.2 from CDROM on debian unstable (seabios 1.12.0-1)
-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures

[Harald Welte]

Is there anything that we can do to help resolving this issue?  

osmo-trx builds are FTBFS for more than three weeks now, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974

Thanks a lot!

Regards,
Harald
-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#940135: Statement from Michael Dickens @ Ettus (UHD vendor)

[Harald Welte]

Forwarding this relatd post from the gnuradio mailing list.


From: Michael Dickens 
To: Harald Welte 
Cc: GNURadio Discussion List , "A. Maitland Bottoms" 
, Pau
Espin Pedrol 
Subject: Re: [Discuss-gnuradio] UHD / -lboost_system / pkg-config / Debian patch

Hi Harald - Mait & I talked about this issue during GRCon19 a few weeks
ago. I believe we came to the same conclusions as you note: A project that
does not otherwise require non-UHD library/ies should not have to know to
link against them (nor how). The linkage should be provided transparently
by CMake or pkgconfig or whatever: variables are returned from "find"ing
UHD that provides CFLAGS, CXXFLAGS, LDFLAGS, LIBRARIES, LIBRARY_DIRS,
INCLUDE_DIRS, and so forth. These variables can then be used as-is by the
calling project without having to know anything else about how the API or
ABI is built, installed, or used beyond these variables. The correct way to
do this varies depending on which "find" is used. For pkgconfig, using
"Requires.private" or "Requires" or just leaving the linkage as before the
patch ... any of those might work. But, yes, the bottom line is that the
patch you note isn't doing the right thing and needs to be either fixed or
removed. I'm leaving it to Mait to deal with this as he sees fit; I think
we'd all prefer this get done sooner rather than later. - MLD


-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures

[Harald Welte]

As Pau indicated, we are building a osmo-trx-uhd binary which doesn't use
any of boost internally, but simply wants to use UHD.

I you remove "-lboost_system" from the UHD pkg-config, all UHD using 
applications
that don't use boost_system internally will fail to link.  Normally I would
assume that the correct path of action is to remove "-lboost_system" and at
the same time introduce a "libboost-system" into the Requires section of 
pkg-config.

However, as boost couldn't be bothered to follow the industry-standard and fails
to provide pkg-config files for 12 years (see 
https://svn.boost.org/trac10/ticket/1094),
You cannot use the pkg-config internal dependency mechanism.

So my position remains: The patch is wrong, it should be reverted.  The 
application
knows it needs UHD.  It shouldn't need to track whatever UHD's dependencies to 
other
libraries are today or might become in the future.

-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#939974: osmo-trx FTBFS: undefined reference to symbol '_ZN5boost6system16generic_categoryEv'

[Harald Welte]

This is actually a bug that Debian introduces by patching its uhd pacakge, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940135

Maybe the osmo-trx / debian-mobcom package maintainers can talk to the uhd 
package maintainer.
-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#940135: Libs.private doesn't help

[Harald Welte]

Hi again,

I just tested:

> If -lboost_system is in the Libs.private: field of uhd.pc, does osmo-trx 
> build?

No, it doesn't.

As indicated before, osmo-trx-uhd doesn't use any of boost itself.  I'm sure
there are other programs out there which just use the UHD C API and not use
boost internally.

-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#926317: [Debian-iot-maintainers] Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control

[Harald Welte]

Hi Nicolas,

thanks for your response.

On Thu, Apr 04, 2019 at 09:10:10AM -0400, Nicolas Mora wrote:
> Libyder relies on libsystemd to write logs in journald, but it's one of the 
> log output available, like syslog, a file, a callback or the console. But you 
> can use libyder without systemd if you don't use it as log output.

This is great,

but then why do you have the following patch in the yder debian package?

Description: soname is still 2.0, fix PKGCONF_REQ_PRIVATE
Author: Nicolas Mora 
Index: yder-1.4.4/CMakeLists.txt
===
--- yder-1.4.4.orig/CMakeLists.txt
+++ yder-1.4.4/CMakeLists.txt
@@ -135,7 +135,7 @@ endif ()
 
 if (WITH_JOURNALD)
   set(PKGCONF_REQ "")
-  set(PKGCONF_REQ_PRIVATE "libsystemd, liborcania")
+  set(PKGCONF_REQ_PRIVATE "systemd, liborcania")
 else ()
   set(PKGCONF_REQ "")
   set(PKGCONF_REQ_PRIVATE "liborcania")

This patch does the *exact opposite* of what you described in your
e-mail.  It causes the libyder.pc contain a Requires.private on
'systemd', and not on 'libsytemd'.

This means you can build + install they libyder + libyder-dev package just fine
on a system without systemd. But then, when you actually want to build any
application against libyder, its autoconf/cmake step will fail as 'systemd.pc' 
is
not available but listed in Requires.private.

So if you really only need libsystemd, why change from libsystemd to
systemd in the patch above?

Regards,
Harald
-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control

[Harald Welte]

Package: libyder-dev
Version: 1.4.4-4
Severity: normal

I'm experiencing problems building yder-based applications:,
libyder.pc (after applying debian/cmake.patch) has a Requires.private to
the pacakge 'systemd'.  However, 'systemd' is not listed in the
'Depends' line of debian/control.

This leads to the absurd situation that I can build + install
libyder-dev, but other yder-using applications will not get past their
cmaake/autoconf step as 'systemd' is not neccessarily installed.

So at the very least, 'systemd' should be listed in 'Depends'.

I'm somewhat doubtful about this entire method of using pkg-config
'Requires.private'.  It may make sense in the absence of a package
manager.  But as we're talking about a Debian package here: Dependencies
should be tracked at package installation time using dpkg/apt, and not
some pkg-config private mechanism, IMHO.

Also, I'm not entirely sure why there's a dependency on 'systemd', and
not 'libsystemd' as in the upstream source.  The Debian changelog
unfortunately doesn't explain why that cmake.patch is used.

Thanks in advance.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libyder-dev depends on:
ii  libjansson-dev  2.12-1
ii  liborcania-dev  1.2.9-5
ii  libsystemd-dev  241-2
ii  libyder2.0  1.4.4-4

libyder-dev recommends no packages.

libyder-dev suggests no packages.

-- no debconf information

Bug#879816: eclipse-titan depends on gcc-8.2.0, but unstable has gcc-8.3.0

[Harald Welte]

The "supposed" fix in upstream
at 
https://github.com/eclipse/titan.core/commit/425a11165fa7b88ca36ca363fc714432e46822fb
is not a fix at all for this problem.

The problem is that the entire check in Eclipse TITAN is bogus. From
what I know there was one such ABI incompatibility something like 10
years ago, and TITAN continues to have this supposed workaround. I don't
think many people are running 10 years old distributions. On the
contrary, the "workaround" of enforcing gcc version equality is breaking
lots of current-day setups again and again - with absolutely no reason.

I believe you can safely link objects created by different gcc/g++ versions,
with that one ancient exception that shouldn't matter anymore these
days.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#879816: eclipse-titan depends on gcc-8.2.0, but unstable has gcc-8.3.0

[Harald Welte]

Package: eclipse-titan
Version: 6.5.0-1
Followup-For: Bug #879816

I'm really sorry, but this bug keeps re-appearing again and again.  I
don't think it has been adressed at all so far.

Every time Debian updates the gcc version, it breaks the eclipse-titan
package. I updated my system yesterday, and eclispe-titan was
uninstalled automatically.  Needless, to say, I use it as part of my
everyday work :)

Trying to re-install it:
   The following packages have unmet dependencies:
eclipse-titan : Depends: gcc (< 4:8.2.0.0) but 4:8.3.0-1 is to be installed

The bug has clearly still exists.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#879816: The bug just happened *again*

[Harald Welte]

Hi guys,

For at least the third or fourth time over the course of a year, this
bug has occurred now, without any resolution.  As it was clearly
demonstrated that it doesn't work to rebuild eclipse-titan automatically
every time a new gcc version is built, I would *really* appreciate if
you could follow the advice of other Debian developers here and remove
that dependency to match on the specific gcc version, and rather check
only on the major version or completely remove it.

This is from Debian unstable today, rendering me again unable to work:

---
The following packages have unmet dependencies:
 eclipse-titan : Depends: gcc (< 4:8.1.0.0) but 4:8.2.0-1 is to be installed
E: Unable to correct problems, you have held broken packages.
---

Thanks for your kind attention.  I strongly hope that a related fix will be
merged not only to unstable but also make it in time before the next
stable Debian release. Thanks.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#901463: TITAN documentation is not packaged as part of eclipse-titan or eclipse-titan-doc

[Harald Welte]

Package: eclipse-titan
Version: 6.3.1-1+b2
Severity: wishlist

The eclipse-titan package for Debian unfortunately does not include the official
documentation.  Normally, I would assume documentation is installed under
/usr/share/doc/$package - but there's nothing but the changelog and the 
copyright
statement there.  Not even a README file that points to
https://www.eclipse.org/downloads/download.php?file=/titan/TitanDocuments_6_3_0.zip

I suggest that due to their size, the PDF files should be packaged as 
eclipse-titan-doc.

However, it still makes sense to package them from the same debian source 
package,
to make sure that there's always a matching eclipse-titan-doc package for each 
eclipse-titan
package.

See also https://www.eclipse.org/forums/index.php/m/1790623 where I describe 
that it's
actually quite hard to find the documentation today for a variety of reasons.

The binary tar-ball builds released by upstream TITAN for Ubuntu, SuSE and 
other distributions
(https://projects.eclipse.org/projects/tools.titan/downloads)
include the PDF files, btw.  It appears that just the Debian package isn't 
shipping them.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eclipse-titan depends on:
ii  default-jdk   2:1.10-67
ii  expect5.45.4-2
ii  gcc   4:7.3.0-3
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-5
ii  libncurses6   6.1+20180210-4
ii  libpcap-dev   1.8.1-6
ii  libpcre3-dev  2:8.39-9
ii  libsctp-dev   1.0.17+dfsg-2
ii  libssl-dev1.1.0h-4
ii  libssl1.1 1.1.0h-4
ii  libstdc++68.1.0-5
ii  libtinfo6 6.1+20180210-4
ii  libxml2   2.9.4+dfsg1-7
ii  libxml2-dev   2.9.4+dfsg1-7
ii  make  4.2.1-1
ii  perl  5.26.2-6
ii  python2.7.15-3

eclipse-titan recommends no packages.

eclipse-titan suggests no packages.

-- no debconf information

Bug#893112: Acknowledgement (eclipse-titan depends on gcc < 7.2.0, but unstable has gcc-7.3.0)

[Harald Welte]

FYI, 10 days later, a new package still hasn't become part of the debian 
archive:

sudo apt-get install eclipse-titan
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 eclipse-titan : Depends: gcc (< 4:7.2.0.0) but 4:7.3.0-2 is to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).


As far as I understand, all that's needed is for the existing package to be 
re-built
against the new gcc version?  Is there anything that can be done to trigger this
in a more timely manner, or even automatize it?

I know, I'm just a user and Debian is a volunteer project.  But short of 
becoming
a Debian developer, is there anything I can do to help this?  Thanks!

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#893112: eclipse-titan depends on gcc < 7.2.0, but unstable has gcc-7.3.0

[Harald Welte]

Package: eclipse-titan
Severity: grave

This is history repeating itself, see debian bug 879816

I would hope this can be solved in a generic way, without breaking the 
eclipse-titan
package every few months when debian updates the gcc version.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eclipse-titan depends on:
ii  default-jdk   2:1.9-61
ii  expect5.45.4-1
ii  gcc   4:7.3.0-1
ii  libc6 2.27-2
ii  libgcc1   1:8-20180312-2
ii  libncurses5   6.1-1
ii  libpcap-dev   1.8.1-6
ii  libpcre3-dev  2:8.39-9
ii  libsctp-dev   1.0.17+dfsg-2
ii  libssl-dev1.1.0g-2
ii  libssl1.1 1.1.0g-2
ii  libstdc++68-20180312-2
ii  libtinfo5 6.1-1
ii  libxml2   2.9.4+dfsg1-6.1
ii  libxml2-dev   2.9.4+dfsg1-6.1
ii  make  4.2.1-1
ii  perl  5.26.1-5
ii  python2.7.14-4

eclipse-titan recommends no packages.

eclipse-titan suggests no packages.

Bug#879816: eclipse-titan depends on gcc-6.3.0, but unstable has gcc-7.2.0

[Harald Welte]

Hi!

The problem just re-appeared as gcc was updated to 7.3.0 in unstable:

g++  -c -DLINUX -I/usr/include -I/usr/include/titan -I../include  -Wall   -o 
EUTRA_Types.o EUTRA_Types.cc
In file included from /usr/include/titan/TTCN3.hh:42:0,
 from EUTRA_Types.hh:19,
 from EUTRA_Types.cc:11:
/usr/include/titan/cversion.h:7:2: error: #error The version of GCC does not 
match the expected version (GCC 7.2.0)
 #error The version of GCC does not match the expected version (GCC 7.2.0)
  ^
Makefile:144: recipe for target 'EUTRA_Types.o' failed
make: *** [EUTRA_Types.o] Error 1

$ gcc --version
gcc (Debian 7.3.0-1) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I think it's really important to solve this in a generic way, i.e. to make sure
eclipse-titan is rebuilt every time gcc is rebuilt.
-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#879816: closed by Gergely Pilisi <mail.pili...@gmail.com> (Bug#879816: fixed in eclipse-titan 6.3.0-1)

[Harald Welte]

I think g++ is the version number the package should depend upon, not gcc,
given that TITAN compiles the TTCN3 files to C++ and not to C.

Would be great to get this patch merged, and to make sure a fixed package
ends up both in stretch/stable and in unstable.

Regarding relaxing the check in TITAN: I would suggest to only do this after
detailed consultation with upstream.  Until that happened, please add the
patch similar to what Andreas suggested in eclipse-titan-depends-gcc.patch,
but with g++.

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#884303: ttcn3_makefilegen generates files with wrong paths

[Harald Welte]

Package: eclipse-titan
Version: 6.3.0-1
Severity: important

The TITAN makefile generator will generate makefiles on Debian whcih will not 
build.

I suppose the reason is that Debian installs the TITAN 
files/libraries/executables in
a structure that's different from what upstream TITAN assumes, and that as a 
result,
the generated Makefile will not work.

During the past months, I've been using the following sed-script in many of my 
TITAN
projects and use it to post-process the generated Makefiles.  That's a kludge, 
but it
works:

sed -i -e 's/# TTCN3_DIR = /TTCN3_DIR = \/usr/' Makefile
sed -i -e 's/LDFLAGS = /LDFLAGS = -L \/usr\/lib\/titan /' Makefile
sed -i -e 's/CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)\/include/CPPFLAGS = 
-D$(PLATFORM) -I$(TTCN3_DIR)\/include -I\/usr\/include\/titan/' Makefile
# below lines were not needed for TITAN 6.1.0 but are for TITAN >= 6.3.0
sed -i -e 's/TTCN3_DIR = $/TTCN3_DIR = \/usr/' Makefile
sed -i -e 's/\/bin\/compiler/\/bin\/ttcn3_compiler/' Makefile

The latest version of this work-around/kludge is maintained at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/regen-makefile.sh

A proper solution would probably be for Debian to apply a patch on the TITAN 
source code
to make sur the generated Makefile uses the paths to which the binaries + 
libraries are
installed in Debian.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages eclipse-titan depends on:
ii  default-jdk   2:1.8-59
ii  expect5.45.3-1
ii  libc6 2.25-3
ii  libgcc1   1:7.2.0-17
ii  libncurses5   6.0+20171125-1
ii  libpcap-dev   1.8.1-5
ii  libpcre3-dev  2:8.39-8
ii  libsctp-dev   1.0.17+dfsg-1+b1
ii  libssl-dev1.1.0g-2
ii  libssl1.1 1.1.0g-2
ii  libstdc++67.2.0-17
ii  libtinfo5 6.0+20171125-1
ii  libxml2   2.9.4+dfsg1-5.1
ii  libxml2-dev   2.9.4+dfsg1-5.1
ii  make  4.1-9.1
ii  perl  5.26.1-3
ii  python2.7.14-3

eclipse-titan recommends no packages.

eclipse-titan suggests no packages.

-- no debconf information

Bug#879816: eclipse-titan depends on gcc-6.3.0, but unstable has gcc-7.2.0

[Harald Welte]

Please note this bug also exist in stable/stretch.  I'm not a BTS
expert, but is it possible to somehow flag a bug as being relevant to
multiple debian releases? If so, please mark this bug as such.  If not,
I'm happy to file a separate bug against stretch.

Right now, the eclipse-titan package in the debian archive for stretch
was built using gcc-6.2.0, but stretch actually has gcc-6.2.1 by now.

So starting with a fresh stretch installation, you will run into this
exact same problem.  Without the gross hack of manually patching the
include file, the eclipse-titan compiler is not usable.

I am not a Debian expert, but I guess you will need to find out how you can
automatically trigger a re-build of eclipse-titan, every time a package
with a new gcc version is pushed into the debian archive.

Probably only part of the solution:  The eclipse-titan package should
depend on the specific gcc-version.  So basically 'control' would list
a "Depends: gcc (= 6.2.0)" line to express this specific dependency
which is currently only in /usr/include/titan/cversion.h, but not in the
package metadata, where (I think) it belongs.

Regards,
Harald

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#879815: Acknowledgement (eclipse-titan not installable on current stretch/amd64)

[Harald Welte]

I'm sorry, this is a bogus report.  I figure out it was a misconfiguration
on my machine, sorry for the noise. Please close.
-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#879816: eclipse-titan depends on gcc-6.3.0, but unstable has gcc-7.2.0

[Harald Welte]

Package: eclipse-titan
Version: 6.2.0-1
Severity: important

upstream eclipse-titan enforces that the gcc version used to build it is 
identical
to the gcc version that is used to compile code generated by the eclipse titan 
ttcn3
compiler.

So whenever a new build of eclipse-titan happens in the debian archive, it will 
work
for some time, until somebody updates the gcc version, at which point 
compilation will
fail.

Right now, in "unstable", eclipse-titan-6.2.0 was apparently built using 
gcc-6.3.0,
but "unstable" contains gcc-7.2.0 as default gcc version.

Building any TTCN-3 project thus renders the following error messages during 
copilation:

g++  -c -DLINUX -I/usr/include -I/usr/include/titan -I/usr/include/titan -Wall 
-fPIC   -o GGSN_Tests.o GGSN_Tests.cc
In file included from /usr/include/titan/TTCN3.hh:42:0,
 from GGSN_Tests.hh:19,
 from GGSN_Tests.cc:11:
/usr/include/titan/cversion.h:7:2: error: #error The version of GCC does not 
match the expected version (GCC 6.3.0)
 #error The version of GCC does not match the expected version (GCC 6.3.0)
  ^

$ gcc --version
gcc (Debian 7.2.0-11) 7.2.0

I was building http://git.osmocom.org/osmo-ttcn3-hacks/tree/ggsn_tests for the 
above output, but it will
happen for any TTCN-3 project as the core include file TTCN3.hh refers to the 
include file with that
statement

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages eclipse-titan depends on:
ii  default-jdk   2:1.8-59
ii  expect5.45-8
ii  libc6 2.24-17
ii  libgcc1   1:7.2.0-11
ii  libncurses5   6.0+20170902-1
ii  libpcap-dev   1.8.1-5
ii  libpcre3-dev  2:8.39-5
ii  libsctp-dev   1.0.17+dfsg-1+b1
ii  libssl-dev1.1.0f-5
ii  libssl1.1 1.1.0f-5
ii  libstdc++67.2.0-11
ii  libtinfo5 6.0+20170902-1
ii  libxml2   2.9.4+dfsg1-5
ii  libxml2-dev   2.9.4+dfsg1-5
ii  make  4.1-9.1
ii  perl  5.26.0-8
ii  python2.7.14-1

eclipse-titan recommends no packages.

eclipse-titan suggests no packages.

-- no debconf information

Bug#879815: eclipse-titan not installable on current stretch/amd64

[Harald Welte]

Package: eclipse-titan
Severity: grave

When trying to install eclipse-titan on a current stetch/amd64,
I get:

The following packages have unmet dependencies:
 eclipse-titan : Depends: libssl-dev but it is not going to be installed

This is with the following (only) line in /etc/apt/sources.list:

deb http://ftp.de.debian.org/debian/ unstable main contrib non-free

and just after "apt-get update".

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages eclipse-titan depends on:
ii  default-jdk   2:1.8-59
ii  expect5.45-8
ii  libc6 2.24-17
ii  libgcc1   1:7.2.0-11
ii  libncurses5   6.0+20170902-1
ii  libpcap-dev   1.8.1-5
ii  libpcre3-dev  2:8.39-5
ii  libsctp-dev   1.0.17+dfsg-1+b1
pn  libssl-dev
ii  libssl1.1 1.1.0f-5
ii  libstdc++67.2.0-11
ii  libtinfo5 6.0+20170902-1
ii  libxml2   2.9.4+dfsg1-5
ii  libxml2-dev   2.9.4+dfsg1-5
ii  make  4.1-9.1
ii  perl  5.26.0-8
ii  python2.7.14-1

eclipse-titan recommends no packages.

eclipse-titan suggests no packages.

Bug#852513: system unbootable on Lenovo x260 / efibootmgr ENOSPC

[Harald Welte]

I can confirm a similar (probably identical) issue on a Lenvoo x260 with
grub 2.02~beta3-4 and beta3-5, but not with <= beta3-3.

Please see #852748 for all related information.

Removing files form /sys/fs/pstore/ and even deleting other
entries with efibootmgr manually didn't solve the issue.  At this point,
downgrading to grub2 2.02~beta3-3 or earlier is the only known
workaround.

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#852748: Acknowledgement (system unbootable on Lenovo x260 with EFI)

[Harald Welte]

2.02~beta3-5 exposes the same problem, but during grub-install I now get
the following error message:

nataraja:/sys/fs/pstore# grub-install 
Installing for x86_64-efi platform.
File descriptor 4 (/dev/sda3) leaked on vgs invocation. Parent PID 16830: 
grub-install
File descriptor 4 (/dev/sda3) leaked on vgs invocation. Parent PID 16830: 
grub-install
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output 
error.

This seems related/identical to #756253 / #852513

I also had plenty of dmesg-* files in /sys/fs/pstore.  Removing them
didn't help

strace tells me:

[pid 16934] 
access("/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c",
 F_OK) = -1 ENOENT (No such file or directory)
[pid 16934] 
open("/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c", 
O_WRONLY|O_CREAT, 0644) = 3
[pid 16934] ioctl(3, FS_IOC_GETFLAGS, 0x7ffe0df7b194) = 0
[pid 16934] write(3, 
"\7\0\0\0\1\0\0\0b\0d\0e\0b\0i\0a\0n\0\0\0\4\1*\0\3\0\0\0"..., 122) = -1 ENOSPC 
(No space left on device)
[pid 16934] ioctl(3, FS_IOC_GETFLAGS, 0x7ffe0df7b194) = 0
[pid 16934] 
unlink("/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c")
 = 0
[pid 16934] close(3)= 0
[pid 16934] write(2, "Could not prepare Boot variable", 31Could not prepare 
Boot variable) = 31
[pid 16934] write(2, ": No space left on device\n", 26: No space left on 
device) = 26

Manually deleting a random entry with efibootmgr (the one for the NVMe
which I don't have) also didn't help.

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#852748: Acknowledgement (system unbootable on Lenovo x260 with EFI)

[Harald Welte]

Please note as 2.02-beta3-4 has now propagated from unstable to testing,
'testing' also fails to install a bootable grub on affected machines :(

I've meanwhile updated to the latest Lenovo BIOS "R02ET52W (1.25 )"
without any change to the boot behaviour.  A grub installed from beta3-3
still boots, while beta3-4 fails to boot.

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#852748: system unbootable on Lenovo x260 with EFI

[Harald Welte]

Package: grub-efi-amd64-bin
Version: 2.02~beta3-4
Severity: important

After updating to 2.02~beta3-4 and successive grub-install (happens
during installation), the system was completely unable to boot.  I tried
various BIOS settings (boot order, EFI and Legacy mode, disabled all other boot
sources), played with efibootmgr settings, no avail.

The only way to boot the system was using an external USB drive that had
been created with a previous version of grub2-efi.  From there, I could
then load the lvm module and load the grub2 configuration file from my
built-in hard disk (the nataraja_x26-space volume) and boot the system.

When the system failed to boot, no grub output was seen on the display.
Rather, booting the hard disk immediately returned to the boot menu (or
proceeded to alternative boot sources such as PXE).  So it fails super
fast, without any output.

Booting into a Debian resuce system, chroot()ing into the root
filesystem and then running grub-install did not change the situation at
all.

Downgrading to 2.02~beta3-3 from testing immediately solved the problem,
so the breakage is definitely introduced between beta3-3 and beta3-4.

I am not sure if this is something specific to the x260, but I would be
surprised if I'm the only one hit by this and rendering systems
unbootable is quite a big problem :/

BIOS information from dmidecode:

BIOS Information
Vendor: LENOVO
Version: R02ET46W (1.19 )
Release Date: 03/15/2016
Address: 0xE
Runtime Size: 128 kB
ROM Size: 16384 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.19
Firmware Revision: 1.11

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/nataraja_x260-root / btrfs 
rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/ 0 0
/dev/sda3 /boot/efi msdos 
rw,relatime,fmask=0022,dmask=0022,codepage=437,errors=remount-ro 0 0
/dev/mapper/nataraja_x260-space /space btrfs 
rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/crypt /crypt btrfs 
rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/ 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HTS723232L9A360_090830FC2400NEHEAGAG
(hd1)   /dev/sdg
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod lvm
insmod btrfs
set 
root='lvmid/BBL6ib-CjYL-8A8o-itKZ-EHiK-wAp8-v0kG1p/3ZjUVz-KvQI-jJK0-HsYA-RoP6-mQQj-dwG9mx'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/BBL6ib-CjYL-8A8o-itKZ-EHiK-wAp8-v0kG1p/3ZjUVz-KvQI-jJK0-HsYA-RoP6-mQQj-dwG9mx'
  3cabc80b-e273-47d5-b70a-b3742a50e9c0
else
  search --no-floppy --fs-uuid --set=root 3cabc80b-e273-47d5-b70a-b3742a50e9c0
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set 

Bug#846913: Acknowledgement (CONFIG_GTP is not set / gtp.ko module not built)

[Harald Welte]

Not that this would have any significance to Debian, but just for your
information, the latest Fedora, OpenSUSE and Ubuntu releases (shipping
4.8.0 or later) have all enabled CONFIG_GTP.

It would be great if people (myself included) could run their GTP-using
software also on Debian :)

Regards,
Harald

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#846913: CONFIG_GTP is not set / gtp.ko module not built

[Harald Welte]

Package: src:linux
Version: 4.8.7-1
Severity: wishlist

Dear Debian kernel team, it would be great if you could activate the
(newly-introduced) CONFIG_GTP kernel option to build the related kernel
module.  The Module implements the 3GPP GTP (Generic Tunneling Protocol)
and has no impact on any other parts of the kernel or networking
sub-system, except that one addtiional tunneling protocol is present,
which some users might use and others not.

There are several Free Software userspace programs using the GTP module,
including OpenGGSN, ergw and OpenAirInterface.

Thanks in advance for your consideration!

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-rc2+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.8.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod23-1
ii  linux-base  4.5

Versions of packages linux-image-4.8.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2

Versions of packages linux-image-4.8.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.03+dfsg-14
ii  grub-efi-amd64  2.02~beta3-3
pn  linux-doc-4.8   

Versions of packages linux-image-4.8.0-1-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20160824-1
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20160824-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#798375: Stale SCTP sockets / recovery only by reboot

[Harald Welte]

Package: src:linux
Version: 3.16.5-1
Severity: normal
Tags: patch

I appear to have run into a SCTP bug that has been around since 2009:
http://sourceforge.net/p/lksctp/mailman/message/23492403/
and has been fixed in mainline as part of commit
bdf6fa52f01b941d4a80372d56de465bdbbd1d23.

However, the bug was still visible in the Debian kernel version
3.16.5-1, and I suppose all that's needed is a cherry-pick.

It is possible to reproduce as follows:

* start a SCTP server socket (bind/listen) on linux
* make the client connect to that
* accept() the connection on the server
* make the client disappear suddenly (e.g. power it down, disconnect its
  network cable) in a way that there is no handshake to terminate the
  association
* close the server program
** linux sends SHUTDOWN and associated retansmissions
* start the server program again
* make the client re-connect
** INIT/INIT_ACK/HEARTBEAT/HEARTBEAT_ACK/DT1/SACK messages can be seen
   in wireshark on the server and traverse nicely to and from the client,
   but none of that data ever arrives on th socket.  The re-started
   server never even receives any notification about the new connection,
   thre is subequently no socket being created.

I double-checked, no other process had a clone of that socket open from
the userspace point of view.

The only way I fould to recover was to reboot the server system, which
of course is quite annoying.  Unloading the sctp kernel module was not
an option, as it still had a reference count, despite no SCTP sockets
existing anymore in the system.

The issue was possible to reproduce several times, so itw as not some
strange one-off behavior.

-- Package-specific info:
** Version:
Linux version 3.16-3-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-12) ) #1 SMP Debian 3.16.5-1 (2014-10-10)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16-3-amd64 
root=UUID=2fa8d876-a03f-447f-bda0-d7f6fed53004 ro

** Not tainted

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-3.16-3-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.57
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod21-1
ii  linux-base  4.0
ii  module-init-tools   21-1

Versions of packages linux-image-3.16-3-amd64 recommends:
ii  firmware-linux-free  3.4

Versions of packages linux-image-3.16-3-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.03+dfsg-10
ii  grub-pc 2.02~beta2-26
pn  linux-doc-3.16  

Versions of packages linux-image-3.16-3-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
ii  firmware-iwlwifi0.44
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
ii  firmware-ralink 0.44
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  linux-image-3.16-3-amd64/postinst/depmod-error-initrd-3.16-3-amd64: false
  linux-image-3.16-3-amd64/prerm/removing-running-kernel-3.16-3-amd64: true
  linux-image-3.16-3-amd64/postinst/mips-initrd-3.16-3-amd64:

Bug#672106: qgis crashes immediately upon start (x86_64, unstable)

[Harald Welte]

Package: qgis
Version: 1.7.4+1.7.5~20120320-1
Severity: important

I have never used qgis before, installed it using apt-get install qgis
on my x86_64/unstable system and when trying to start it, I am getting
the following crash/abort:

=
laforge@nataraja%pts/25 (15:31) ~  qgis
Warning: loading of qgis translation failed [/usr/share/qgis/i18n//qgis_en_US]
Warning: loading of qt translation failed [/usr/share/qt4/translations/qt_en_US]
qgis.bin: 
/build/buildd-sip4_4.13.2-1-amd64-oTGNAQ/sip4-4.13.2/siplib/siplib.c:10938: 
sipEnumType_alloc: Assertion `(((currentType)-td_flags  0x0007) == 0x0003)' 
failed.
[1]18271 abort  qgis
=

Starting it in gdb yields:

Program received signal SIGABRT, Aborted.
0x72e08475 in *__GI_raise (sig=optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x72e08475 in *__GI_raise (sig=optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x72e0b6f0 in *__GI_abort () at abort.c:92
#2  0x72e01621 in *__GI___assert_fail (assertion=
0x7fffdf26a8d0 (((currentType)-td_flags  0x0007) == 0x0003), 
file=optimized out, line=10938, function=0x7fffdf269b50 
sipEnumType_alloc)
at assert.c:81
#3  0x7fffdf25cee3 in sipEnumType_alloc (self=optimized out, 
nitems=optimized out)
at 
/build/buildd-sip4_4.13.2-1-amd64-oTGNAQ/sip4-4.13.2/siplib/siplib.c:10938
#4  0x7fffdf724251 in type_new () from /usr/lib/libpython2.7.so.1.0
#5  0x7fffdf7ba7b3 in type_call.25625 () from /usr/lib/libpython2.7.so.1.0
#6  0x7fffdf7b9773 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#7  0x7fffdf2651ee in createContainerType (cod=optimized out, td=
0x7fffde530460, bases=optimized out, metatype=
Python Exception class 'gdb.error' There is no member named ma_mask.: 
type at remote 0x7fffdf46fb80, mod_dict=optimized out, type_dict=, 
client=
0x7fffde518d00)
at /build/buildd-sip4_4.13.2-1-amd64-oTGNAQ/sip4-4.13.2/siplib/siplib.c:5403
#8  0x7fffdf26553e in createClassType (client=0x7fffde518d00, ctd=
Python Exception class 'gdb.error' There is no member named ma_mask.: 
0x7fffde530460, mod_dict=)
at /build/buildd-sip4_4.13.2-1-amd64-oTGNAQ/sip4-4.13.2/siplib/siplib.c:5538
Python Exception class 'gdb.error' There is no member named ma_mask.: 
#9  0x7fffdf265698 in sip_api_init_module (client=0x7fffde518d00, mod_dict=)
at /build/buildd-sip4_4.13.2-1-amd64-oTGNAQ/sip4-4.13.2/siplib/siplib.c:1418
#10 0x7fffde14a06b in initcore ()
   from /usr/lib/python2.7/dist-packages/qgis/core.so
#11 0x7fffdf72cbd5 in _PyImport_LoadDynamicModule ()
   from /usr/lib/libpython2.7.so.1.0
#12 0x7fffdf7d1fac in import_submodule.39466 ()
   from /usr/lib/libpython2.7.so.1.0
#13 0x7fffdf7a63d2 in load_next.39471 () from /usr/lib/libpython2.7.so.1.0
#14 0x7fffdf7d2604 in import_module_level.isra.9 ()
   from /usr/lib/libpython2.7.so.1.0
#15 0x7fffdf7cc07a in PyImport_ImportModuleLevel ()
   from /usr/lib/libpython2.7.so.1.0
#16 0x7fffdf6c3ebf in builtin___import__ () from 
/usr/lib/libpython2.7.so.1.0
#17 0x7fffdf7b9773 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#18 0x7fffdf7ba0c7 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.7.so.1.0
#19 0x7fffdf70fc62 in PyEval_EvalFrameEx () from 
/usr/lib/libpython2.7.so.1.0
#20 0x7fffdf6c88b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#21 0x7fffdf6c8be2 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#22 0x7fffdf6c8c7c in PyRun_StringFlags () from /usr/lib/libpython2.7.so.1.0
#23 0x7fffdfb79043 in QgsPythonUtilsImpl::runStringUnsafe(QString const, 
bool)
() from /usr/lib/libqgispython.so.1.7.5
#24 0x7fffdfb790de in QgsPythonUtilsImpl::runString(QString const, 
QString) ()
   from /usr/lib/libqgispython.so.1.7.5
#25 0x7fffdfb785b6 in QgsPythonUtilsImpl::initPython(QgisInterface*) ()
   from /usr/lib/libqgispython.so.1.7.5
#26 0x0056d16a in QgisApp::loadPythonSupport() ()
#27 0x00551a5c in QgisApp::QgisApp(QSplashScreen*, bool, QWidget*, 
QFlagsQt::WindowType) ()
#28 0x0054e4e3 in main ()

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages qgis depends on:
ii  libc6   2.13-32
ii  libgcc1 1:4.7.0-7
ii  libgdal1-1.7.0  1.7.3-6+b4
ii  libgeos-c1  3.3.1-1
ii  libgsl0ldbl 1.15+dfsg-1
ii  libpq5  9.1.3-2
ii  libproj04.7.0-1
ii  libqgis1.7.51.7.4+1.7.5~20120320-1
ii  libqt4-network  4:4.8.1-1
ii  libqt4-sql  4:4.8.1-1
ii  libqt4-svg  4:4.8.1-1
ii  libqt4-xml  4:4.8.1-1
ii  libqtcore4  4:4.8.1-1
ii  libqtgui4   

Bug#653882: update from 4.42 to 4.50 breaks uucp-over-ssl client

[Harald Welte]

Package: stunnel4
Version: 3:4.50-1
Severity: normal

Upgrading from 4.42-1 to 4.50-1 breaks my uucp-over-ssl setup in strange
ways.

My config is:
==
foreground = yes

[uucico]
client = yes
connect = 111.22.33.444:996
exec = /usr/sbin/uucico
execargs = uucico -S ganesha.gnumonks.org -D
pty = yes
TIMEOUTconnect = 15
=

With 4.42-1, I get the following output and mails are transferred as
they should:

$ stunnel4 ~/scripts/stunnel-uucico.conf
2011.12.31 23:00:27 LOG5[3456:140461314680576]: stunnel 4.42 on 
x86_64-pc-linux-gnu platform
2011.12.31 23:00:27 LOG5[3456:140461314680576]: Compiled with OpenSSL 1.0.0d 8 
Feb 2011
2011.12.31 23:00:27 LOG5[3456:140461314680576]: Running  with OpenSSL 1.0.0e 6 
Sep 2011
2011.12.31 23:00:27 LOG5[3456:140461314680576]: Update OpenSSL shared libraries 
or rebuild stunnel
2011.12.31 23:00:27 LOG5[3456:140461314680576]: Threading:PTHREAD SSL:ENGINE 
Auth:LIBWRAP Sockets:POLL,IPv6 
2011.12.31 23:00:27 LOG5[3456:140461314680576]: Reading configuration from file 
/home/laforge/scripts/stunnel-uucico.conf
2011.12.31 23:00:27 LOG5[3456:140461314680576]: Configuration successful
2011.12.31 23:00:27 LOG5[3456:140461314905856]: connect_blocking: connected 
111.22.33.444:996
2011.12.31 23:00:27 LOG5[3456:140461314905856]: Service uucico connected remote 
server from 192.168.100.239:45283
2011.12.31 23:01:29 LOG3[3456:140461314905856]: readsocket: Input/output error 
(5)
2011.12.31 23:01:29 LOG5[3456:140461314905856]: Connection reset: 7890332 bytes 
sent to SSL, 6152 bytes sent to socket

With 4.50-1, using the same config, I get:

$ stunnel4 ~/scripts/stunnel-uucico.conf
2011.12.31 22:38:58 LOG5[3153:139703414937344]: stunnel 4.50 on 
x86_64-pc-linux-gnu platform
2011.12.31 22:38:58 LOG5[3153:139703414937344]: Compiled/running with OpenSSL 
1.0.0e 6 Sep 2011
2011.12.31 22:38:58 LOG5[3153:139703414937344]: Threading:PTHREAD SSL:ENGINE 
Auth:LIBWRAP Sockets:POLL,IPv6 
2011.12.31 22:38:58 LOG5[3153:139703414937344]: Reading configuration from file 
/home/laforge/scripts/stunnel-uucico.conf
2011.12.31 22:38:58 LOG5[3153:139703415162624]: Service uucico accepted 
connection
2011.12.31 22:38:58 LOG5[3153:139703414937344]: Configuration successful
2011.12.31 22:38:58 LOG3[3153:139703415162624]: TCP_NODELAY: Socket operation 
on non-socket (88) 
2011.12.31 22:38:58 LOG5[3153:139703415162624]: Connection reset: 0 bytes sent 
to SSL, 0 bytes sent to socket
2011.12.31 22:39:00 LOG3[3153:139703414937344]: Received signal 2; terminating

There is not a single packet sent on the wire (checked with tcpdump),
and reverting to 4.42-1 solves the problem.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages stunnel4 depends on:
ii  adduser   3.113
ii  libc6 2.13-24
ii  libssl1.0.0   1.0.0e-3
ii  libwrap0  7.6.q-22
ii  netbase   4.47
ii  openssl   1.0.0e-3
ii  perl-modules  5.12.4-6
ii  zlib1g1:1.2.3.4.dfsg-3

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  none

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#629267: (no subject)

[Harald Welte]

Package: gthumb
Version: 3:2.13.1-1
Severity: important


During the last weeks, gthumb has been becoming more and more unstable for me.

Now, I can hardly start it without it receviging a SIGABRT due to glibc invalid
free detection a  couple of seconds after start.

A backtrace looks like this:
(gdb) run .
Starting program: /usr/bin/gthumb .
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffdffb6700 (LWP 14425)]
[New Thread 0x7fffdf7b5700 (LWP 14426)]
[New Thread 0x7fffdf202700 (LWP 14428)]
*** glibc detected *** /usr/bin/gthumb: free(): invalid pointer: 
0x00865c40 ***
=== Backtrace: =
/lib/libc.so.6(+0x725d6)[0x748a95d6]
/lib/libc.so.6(cfree+0x6c)[0x748ae30c]
/lib/libglib-2.0.so.0(g_string_free+0x4a)[0x750bea4a]
/usr/lib/gthumb/extensions/libbookmarks.so(+0x2fb1)[0x7fffe3a24fb1]
/usr/lib/gthumb/extensions/libbookmarks.so(+0x32c5)[0x7fffe3a252c5]
/usr/lib/libgio-2.0.so.0(+0x57b59)[0x759f8b59]
/usr/lib/libgio-2.0.so.0(+0x67a68)[0x75a08a68]
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f3)[0x7509c4a3]
/lib/libglib-2.0.so.0(+0x45c80)[0x7509cc80]
/lib/libglib-2.0.so.0(g_main_loop_run+0x182)[0x7509d2f2]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x76e3f2b7]
/usr/bin/gthumb(main+0x1b3)[0x4c1087]
/lib/libc.so.6(__libc_start_main+0xfd)[0x74855ead]
/usr/bin/gthumb[0x436319]
=== Memory map: 
0040-004f8000 r-xp  09:00 39522045   
/usr/bin/gthumb
006f7000-006ff000 rw-p 000f7000 09:00 39522045   
/usr/bin/gthumb
006ff000-00a4b000 rw-p  00:00 0  [heap]
7fffd800-7fffd80a4000 rw-p  00:00 0 
7fffd80a4000-7fffdc00 ---p  00:00 0 
7fffdea02000-7fffdea03000 ---p  00:00 0 
7fffdea03000-7fffdf203000 rw-p  00:00 0 
7fffdf203000-7fffdf2e5000 r-xp  09:00 39522632   
/usr/lib/libasound.so.2.0.0
7fffdf2e5000-7fffdf4e5000 ---p 000e2000 09:00 39522632   
/usr/lib/libasound.so.2.0.0
7fffdf4e5000-7fffdf4ec000 rw-p 000e2000 09:00 39522632   
/usr/lib/libasound.so.2.0.0
7fffdf4ec000-7fffdf4ed000 rw-p  00:00 0 
7fffdf511000-7fffdf515000 r-xp  09:00 42762564   
/usr/lib/libcanberra-0.24/libcanberra-alsa.so
7fffdf515000-7fffdf714000 ---p 4000 09:00 42762564   
/usr/lib/libcanberra-0.24/libcanberra-alsa.so
7fffdf714000-7fffdf715000 rw-p 3000 09:00 42762564   
/usr/lib/libcanberra-0.24/libcanberra-alsa.so
7fffdf715000-7fffdf775000 rw-s  00:04 10846211   
/SYSV (deleted)
7fffdf775000-7fffdf776000 ---p  00:00 0 
7fffdf776000-7fffdf7b6000 rw-p  00:00 0 
7fffdf7b6000-7fffdf7b7000 ---p  00:00 0 
7fffdf7b7000-7fffdffb7000 rw-p  00:00 0 
7fffdffb7000-7fffe005c000 r--p  09:00 38928405   
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf
7fffe005c000-7fffe0061000 r-xp  09:00 42566217   
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7fffe0061000-7fffe026 ---p 5000 09:00 42566217   
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7fffe026-7fffe0261000 rw-p 4000 09:00 42566217   
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7fffe0261000-7fffe0275000 r-xp  09:00 41173364   
/usr/lib/gio/modules/libgioremote-volume-monitor.so
7fffe0275000-7fffe0474000 ---p 00014000 09:00 41173364   
/usr/lib/gio/modules/libgioremote-volume-monitor.so
7fffe0474000-7fffe0475000 rw-p 00013000 09:00 41173364   
/usr/lib/gio/modules/libgioremote-volume-monitor.so
7fffe0475000-7fffe0477000 r-xp  09:00 25346223   
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
7fffe0477000-7fffe0676000 ---p 2000 09:00 25346223   
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
7fffe0676000-7fffe0677000 rw-p 1000 09:00 25346223   
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
7fffe0677000-7fffe0727000 r--p  09:00 38928406   
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
7fffe0727000-7fffe35e9000 r--p  09:00 41205820   
/usr/share/icons/gnome/icon-theme.cache
7fffe35e9000-7fffe3a22000 r--p  09:00 20512779   
/usr/share/icons/hicolor/icon-theme.cache
7fffe3a22000-7fffe3a27000 r-xp  09:00 42779463   
/usr/lib/gthumb/extensions/libbookmarks.so
7fffe3a27000-7fffe3c27000 ---p 5000 09:00 42779463   
/usr/lib/gthumb/extensions/libbookmarks.so
7fffe3c27000-7fffe3c28000 rw-p 5000 09:00 42779463   
/usr/lib/gthumb/extensions/libbookmarks.so
7fffe3c28000-7fffe3c38000 r-xp  09:00 39519430   
/usr/lib/libtasn1.so.3.1.11
7fffe3c38000-7fffe3e37000 ---p 0001 09:00 

Bug#629267: gthumb SIGABRT bookmarks

[Harald Welte]

Hi David,

thanks for your quick response.  I don't know why the bug report ended
up with no subject, I explicitly specified one in debbug.  Maybe some
editing mishap on my part in the vi later..

On Sun, Jun 05, 2011 at 09:16:02AM +0200, David Paleino wrote:

  During the last weeks, gthumb has been becoming more and more unstable for 
  me.
 
 This is hardly a gThumb bug: its last upload was at mid-March. And this is far
 older than last weeks.

Some more investigation shows: There was a length list of bookmarks in
~/.gtk-bookmarks, all of them relatively long path names of mp3
directories on my machine.

I do not recall adding hundreds and hundreds of directories to any
bookmark list in any application.  However, I only started to use gxmms2
very recently, not sure if it might be responsible for atting those
bookmarks.  Time-wise it would probably match the occurrence of my
gthumb issues.

After deleting the ~/.gtk-bookmarks file, gthumb works like a charm
again.  (I know, I should have simply renamed it or kept a backup copy,
but that thought occurred about 2 seconds too late).

So the bug seems definitely related to a long bookmarks list with long
path names in them.

And indeed, if I use something like 
'find /sunbeam/mp3_dark/a-z -type d  ~/.gtk-bookmarks'
gthumb immediately crashes on start with SIGABRT again.

The file at this point contains 1075 lines, the longest of them 156
characters long.  A number of them contain special characters like ';'
'(' ')' '!' due to the nature of those file-names being auto-generated
from CDDB at the time of their CD-ripping.

I could provide the file privately, but don't want to attach it to a
public bug report.  I just don't want the entire world to see a
directory of my music collection.

Regards,
Harald
-- 
- Harald Welte lafo...@gnumonks.org   http://laforge.gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619241: pcscd crashes at time CCID reader is hot-plugged

[Harald Welte]

 pcscdaemon.c:550:main() pcsc-lite 1.7.0 daemon ready.
1445 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0167 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0166 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0002, path: (null)
0159 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0140 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0139 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0139 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0146 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0002, path: (null)
[New Thread 0x77245700 (LWP 19356)]
03387101 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x076B, PID: 0x3021, path: (null)
0039 hotplug_libudev.c:309:HPAddDevice() Adding USB device: OmniKey CardMan 
3121
0110 readerfactory.c:934:RFInitializeReader() Attempting startup of OmniKey 
CardMan 3121 00 00 using 
/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so
00035622 readerfactory.c:824:RFBindFunctions() Loading IFD Handler 3.0
0090 ifdhandler.c:1732:init_driver() Driver version: 1.4.2
1122 ifdhandler.c:1750:init_driver() LogLevel: 0x0003
0025 ifdhandler.c:1771:init_driver() DriverOptions: 0x
0273 ifdhandler.c:79:IFDHCreateChannelByName() lun: 0, device: 
usb:076b/3021:libudev:0:(null)
0991 ccid_usb.c:267:OpenUSBByName() ifdManufacturerString: Ludovic Rousseau 
(ludovic.rouss...@free.fr)
0021 ccid_usb.c:268:OpenUSBByName() ifdProductString: Generic CCID driver
0016 ccid_usb.c:269:OpenUSBByName() Copyright: This driver is protected by 
terms of the GNU Lesser General Public License version 2.1, or (at your option) 
any later version.
2151 ccid_usb.c:502:OpenUSBByName() Found Vendor/Product: 076B/3021 
(OmniKey CardMan 3121)
0022 ccid_usb.c:504:OpenUSBByName() Using USB bus/device: 5/31
00022128 ccid_usb.c:952:get_data_rates() Got 256 data rates but was expecting 
106
[...]

So the patch seems to fix the segfault, but still the question remains: Why is
pcscd not using its internal CCID driver if OpenCT is installed (but not even
running) ?

Thanks again!

Regards,
Harald

-- 
- Harald Welte lafo...@gnumonks.org   http://laforge.gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619241: pcscd crashes at time CCID reader is hot-plugged

[Harald Welte]

, cleanup = 0x0, 
  canceltype = 0}}}
not_first_call = value optimized out
freesize = value optimized out
__PRETTY_FUNCTION__ = start_thread
#5  0x7f59e758a3cd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#6  0x in ?? ()
No symbol table info available.

 So the patch seems to fix the segfault, but still the question remains: Why 
 is
 pcscd not using its internal CCID driver if OpenCT is installed (but not even
 running) ?
 
 pcscd has no _internal_ CCID driver. pcscd has no internal driver at all.

well I was meaning to say: the CCID driver / ifd_handler that is shipping as
part of pcsc-lite

So as a summary, I think there are still two separate, problems:

1) the fact that pcscd does not handle the case that devpath == NULL,
   which can be worked around using your patch

2) the question why pcscd is trying to use _only_ the OpenCT ifd_handler,
   even when openct is not started (which it detects!)

and maybe even a third one:

3) why does libudev sometimes not provide a devpath in the first place.

Regards,
Harald
-- 
- Harald Welte lafo...@gnumonks.org   http://laforge.gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619241: pcscd crashes at time CCID reader is hot-plugged

[Harald Welte]

Hi Ludovic,

thanks for your response.

On Wed, Mar 23, 2011 at 02:18:46PM +0100, Ludovic Rousseau wrote:

 Can you rebuild pcscd in debug mode and run it inside gdb to get a
 backtrace?

I already did that and I already sent another message to this bug indicating
where exactly it crashes and why...

There is nothing 'unusual' in the backtrace, it really just is that:

In function HPRescanUsbBus():
parent = udev_device_get_devnode(parent);

udev_device_get_devnode() returns NULL (which is possible, according to
http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-device.html#udev-device-get-devnode),
but pcscd uses this result unverified later in a strdup().

 Since only pcscd is involved you can run it directly from the source
 directory within installing it.

yes, that's what I did.

-- 
- Harald Welte lafo...@gnumonks.org   http://laforge.gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619241: pcscd crashes at time CCID reader is hot-plugged

[Harald Welte]

Package: pcscd
Version: 1.7.0-2
Severity: normal
Tags: sid

As soon as any of my CCID readers is hot-plugged, pcscd crashes.

I've tried this with
* Omnikey 3121
* Omnikey 5121
* Omnikey 5321
* Cherry ST-1000 U
* Reiner SCT CyberJack USB

Log file:
nataraja:~# pcscd -f -a -d 
 debuglog.c:277:DebugLogSetLevel() debug level=debug
0575 configfile.l:245:DBGetReaderListDir() Parsing conf directory: 
/etc/reader.conf.d
0053 configfile.l:287:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/libccidtwin
0116 configfile.l:287:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/0comments
0088 pcscdaemon.c:550:main() pcsc-lite 1.7.0 daemon ready.
2987 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0292 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0290 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0002, path: (null)
0280 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0290 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0306 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0287 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0001, path: (null)
0282 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x1D6B, PID: 0x0002, path: (null)
27828592 hotplug_libudev.c:258:get_driver() Looking for a driver for VID: 
0x076B, PID: 0x3021, path: (null)
0041 hotplug_libudev.c:309:HPAddDevice() Adding USB device: Generic CCID 
Reader
Segmentation fault

If I do the same in ltrace, I get

dev.c:309:HPAddDevic..., \033[0m0410 hotplug_libudev.c:309:HPAddDevice() 
Adding USB device: Generic CCID Reader
) = 102
[pid 5894] udev_device_get_sysattr_value(0x152a180, 0x415886, 0x7f1133535e00, 
-1, 0x7f1133f5d700) = 0x152ad80
[pid 5894] strtol(0x152ad80, 0, 10, 0, 0)  = 0
[pid 5894] snprintf(\001\200\255\3730, 4282546, )  = 30
[pid 5894] pthread_mutex_lock(0x61b4e0, 0x4158b2, 0x7fff7acaac9e, 0x4158b2, 0) 
= 0
[pid 5894] udev_device_get_sysattr_value(0x152a180, 0x4158da, 0x7fff7acaac9e, 
0x4158b2, 0x61b4e0) = 0
[pid 5894] udev_device_get_sysattr_value(0x152a8c0, 0x4158b3, 0, 
0x65636166726574, 0x7f1133535ea8) = 0
[pid 5894] __strdup(0x7fff7acaad80, 0xfeadb33f, 80, 0, 0x152b2d0) = 
0x152b300
[pid 5894] __strdup(0, 0x7fff7acaad94, 0, 0x4449434320636972, 0x72656461655220 
unfinished ...
[pid 5894] --- SIGSEGV (Segmentation fault) ---
[pid 5894] +++ killed by SIGSEGV +++

So it is most likely some string handling issue regarding sysfs.

-- System Information:
Debian Release: wheezy/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages pcscd depends on:
ii  adduser   3.112+nmu2 add and remove users and groups
ii  libc6 2.11.2-13  Embedded GNU C Library: Shared lib
ii  libccid [pcsc-ifd-handler]1.4.2-2PC/SC driver for USB CCID smart ca
ii  libudev0  166-1  libudev shared library
ii  lsb-base  3.2-27 Linux Standard Base 3.2 init scrip
ii  openct [pcsc-ifd-handler] 0.6.20-1.1 middleware framework for smart car

pcscd recommends no packages.

pcscd suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619241: pcscd crashes at time CCID reader is hot-plugged

[Harald Welte]

Trying to debug this further resulted in the following preliminary
analysis:

In function HPRescanUsbBus():
parent = udev_device_get_devnode(parent);

udev_device_get_devnode() returns NULL (which is possible, according to
http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-device.html#udev-device-get-devnode),
but pcscd uses this result unverified later in a strdup().

I'm not really sure what kind of device node you are trying to resolve
here.  I've tried to debug it further, but I don't really know what
you attempt to resolve here.  udev_device_get_syspath(parent) works,
but it is not what the CCID driver wants as input.

Regards,
Harald
-- 
- Harald Welte lafo...@gnumonks.org   http://laforge.gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#580327: gitosis unable to install on lenny due to missing python-setuptools

[Harald Welte]

Package: gitosis
Version: 0.2+20080825-2
Severity: grave
Justification: renders package unusable

When trying to install gitosis using 'apt-get install gitosis', I get:

gitosis: Depends: python-setuptools (= 0.6c5) but it is not installable


-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages gitosis depends on:
ii  adduser   3.110  add and remove users and groups
ii  git-core  1:1.5.6.5-3+lenny2~bpo40+1 fast, scalable, distributed revisi
ii  openssh-serve 1:5.1p1-5  secure shell server, an rshd repla
pn  python-setupt none (no description available)

gitosis recommends no packages.

gitosis suggests no packages.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510966: latest mgp package doesn't display any presentation, not even included examples

[Harald Welte]

Package: mgp
Version: 1.13a-1
Severity: critical

After running an 'apt-get upgrade' on my debian unstable, the latest mgp
version was installed.  Unfortunately, this mgp version does nothing but show a
black screen, refuse to terminate on user request and eat all CPU and memory.

This can be easily reproduced by running mgp on one of the examples included
with it, e.g. the  /usr/share/doc/mgp/examples/sample.mgp

I've tried all options that would make sense, including -o / -O / -x vflib / -x
freetype / -l / -V / -F 0,0,0.  The behaviour is always consistent and always
reproducible.

strace()ing the binary shows repeated calls to brk(), and top indicates the
process is eating up all cpu cycles available.  The program cannot be terminated
by the usual 'q' key, since apparently kbd input is never processed and the
process never reasds from its libX11 filedescriptor again.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-rc7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mgp depends on:
ii  imlib111.9.15-7  Imlib is an imaging library for X 
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libfontconfig1 2.6.0-3   generic font configuration library
ii  libgif44.1.6-6   library for GIF images (library)
ii  libice62:1.0.4-1 X11 Inter-Client Exchange library
ii  libjpeg62  6b-14 The Independent JPEG Group's JPEG 
ii  libm17n-0  1.5.2-1   a multilingual text processing lib
ii  libmng11.0.9-1   Multiple-image Network Graphics li
ii  libpng12-0 1.2.27-2  PNG library - runtime
ii  libsm6 2:1.0.3-2 X11 Session Management library
ii  libtiff4   3.8.2-11  Tag Image File Format (TIFF) libra
ii  libx11-6   2:1.1.5-2 X11 client-side library
ii  libxext6   2:1.0.4-1 X11 miscellaneous extension librar
ii  libxft22.1.12-3  FreeType-based font drawing librar
ii  libxmu62:1.0.4-1 X11 miscellaneous utility library
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii  perl [perl5]   5.10.0-19 Larry Wall's Practical Extraction 
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages mgp recommends:
ii  libjpeg-progs 6b-14  Programs for manipulating JPEG fil
ii  netpbm [pnmtopng] 2:10.0-12  Graphics conversion tools
ii  sharutils 1:4.6.3-1  shar, unshar, uuencode, uudecode

Versions of packages mgp suggests:
pn  asiya24-vfont none (no description available)
ii  emacsen-common1.4.17 Common facilities for all emacsen
ii  ghostscript   8.63.dfsg.1-2  The GPL Ghostscript PostScript/PDF
ii  gsfonts-x11   0.21   Make Ghostscript fonts available t
pn  texlive   none (no description available)
pn  ttf-freefont  none (no description available)
ii  ttf-kochi-gothic  1.0.20030809-8 Kochi Subst Gothic Japanese TrueTy
ii  ttf-kochi-mincho  1.0.20030809-8 Kochi Subst Mincho Japanese TrueTy
ii  ttf-opensymbol1:2.4.1-15 The OpenSymbol TrueType font
ii  ttf-sazanami-gothic   20040629-2 Sazanami Gothic Japanese TrueType 
ii  ttf-sazanami-mincho   20040629-2 Sazanami Mincho Japanese TrueType 

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#498568: Debian cannot be installed on bootable SD cards

[Harald Welte]

On Thu, Sep 11, 2008 at 02:15:11PM +0200, Frans Pop wrote:
  The actual distribution installation program needs to
  1. recognize /dev/mmcblk* as block devices that can be used as
 target device
 
 This is the main issue. As Debian Installer uses libparted for 
 partitioning the real question is whether or not libparted supports these 
 devices. If that is true then very minor adjustments in partman should 
 suffice to support partitioning them.

As I wrote in my last mail, the usual 'generic' block device handling
in libparted works fine with SD/MMC devices.  However, the enumerator
to find and enumerate over all block devices on a Linux system did not 
yet find the device.

I have now implemented this as a trivial patch (see below) and also sent the
patch to upstream git for inclusion.

Using the patch, parted shows:

 Model: SD/MMC Storage Card (sd/mmc)
 Disk /dev/mmcblk0: 2013MB
 Sector size (logical/physical): 512B/512B
 Partition Table: msdos
 
 Number  Start  End SizeType File system  Flags
  1  131kB  2013MB  2013MB  primary  fat16 

-

commit f08cf81fad42a6c9c8bca83dc91a0fe1cdf9081a
Author: Harald Welte [EMAIL PROTECTED]
Date:   Wed Sep 17 08:44:54 2008 +0800

Ad SD/MMC Storage Card support on Linux

This patch adds a new SDMMC device type to represent SD/MMC
cards.  There is nothing special about handling those devices,
they are just standard block devices with different names.

They use device major ID 179 and are usually called
/dev/mmcblkN (where N is the card number) and the individual partitions
/dev/mmcblkNpM (where M is the partition number).

This patch was developed as part of an effort to make debian-installer
support installation of Debian GNU/Linux on SD/MMC cards, as boot-from-SD
is becoming a feature seen in mobile x86 devices.

:100644 100644 e955e6f... 568e019... M  AUTHORS
:100644 100644 fdfcb1f... 2a3421f... M  include/parted/device.h
:100644 100644 333f818... 983f232... M  libparted/arch/linux.c
:100644 100644 5e67584... d7c0292... M  parted/parted.c

diff --git a/AUTHORS b/AUTHORS
index e955e6f..568e019 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -231,3 +231,6 @@ Debarshi Ray[EMAIL PROTECTED]
 * Introduce 'print devices' and alias 'print list' to 'print all'.
 * Alias 'mktable' to 'mklabel'.
 * Code and API clean-up, bug fixes, and other miscellaneous stuff.
+
+Harald Welte[EMAIL PROTECTED]
+* SD/MMC Storage card support on Linux
diff --git a/include/parted/device.h b/include/parted/device.h
index fdfcb1f..2a3421f 100644
--- a/include/parted/device.h
+++ b/include/parted/device.h
@@ -44,7 +44,8 @@ typedef enum {
 PED_DEVICE_VIODASD  = 10,
 PED_DEVICE_SX8  = 11,
 PED_DEVICE_DM   = 12,
-PED_DEVICE_XVD  = 13
+PED_DEVICE_XVD  = 13,
+PED_DEVICE_SDMMC= 14
 } PedDeviceType;
 
 typedef struct _PedDevice PedDevice;
diff --git a/libparted/arch/linux.c b/libparted/arch/linux.c
index 333f818..983f232 100644
--- a/libparted/arch/linux.c
+++ b/libparted/arch/linux.c
@@ -255,6 +255,7 @@ struct blkdev_ioctl_param {
 #define SX8_MAJOR1  160
 #define SX8_MAJOR2  161
 #define XVD_MAJOR   202
+#define SDMMC_MAJOR 179
 
 #define SCSI_BLK_MAJOR(M) ( \
 (M) == SCSI_DISK0_MAJOR \
@@ -537,6 +538,8 @@ _device_probe_type (PedDevice* dev)
 #endif
 } else if (dev_major == XVD_MAJOR  (dev_minor % 0x10 == 0)) {
 dev-type = PED_DEVICE_XVD;
+} else if (dev_major == SDMMC_MAJOR  (dev_minor % 0x08 == 0)) {
+dev-type = PED_DEVICE_SDMMC;
 } else {
 dev-type = PED_DEVICE_UNKNOWN;
 }
@@ -1259,6 +1262,11 @@ linux_new (const char* path)
 goto error_free_arch_specific;
 break;
 
+case PED_DEVICE_SDMMC:
+if (!init_generic (dev, _(SD/MMC Storage Card)))
+goto error_free_arch_specific;
+break;
+
 default:
 ped_exception_throw (PED_EXCEPTION_NO_FEATURE,
 PED_EXCEPTION_CANCEL,
diff --git a/parted/parted.c b/parted/parted.c
index 5e67584..d7c0292 100644
--- a/parted/parted.c
+++ b/parted/parted.c
@@ -1268,10 +1268,10 @@ do_print (PedDevice** dev)
 int has_free_arg = 0;
 int has_list_arg = 0;
 int has_num_arg = 0;
-const char *const transport[14] = {unknown, scsi, ide, dac960,
+const char *const transport[15] = {unknown, scsi, ide, dac960,
   cpqarray, file, ataraid, i2o,
   ubd, dasd, viodasd, sx8, 
dm,
-  xvd

Bug#498568: Debian cannot be installed on bootable SD cards

[Harald Welte]

Hi Frans,

On Thu, Sep 11, 2008 at 02:15:11PM +0200, Frans Pop wrote:
 
 On Thursday 11 September 2008, Harald Welte wrote:
  The distribution installation initrd needs to
  1. include and auto-load the sdhc.ko and sdhci_pci.ko kernel modules
 
 Including these modules is a trivial change. However, it does not make 
 sense to do so until the installer supports installing to an SD card.

I agree.

 Auto-loading is a non-issue for Debian-Installer. If the kernel/udev 
 supports the device that will just work. (And I know it does work as the 
 module gets loaded fine on my laptop.)

good.

  2. create the /dev/mmcblk* device nodes as per udev/hotplug events
 
 Not an issue. Should just work.

good.  I was not aware how much of the 'regular linux system' udev/hotplug
magic you have in the installer initrd.

  The actual distribution installation program needs to
  1. recognize /dev/mmcblk* as block devices that can be used as
 target device
 
 This is the main issue. As Debian Installer uses libparted for 
 partitioning the real question is whether or not libparted supports these 
 devices. If that is true then very minor adjustments in partman should 
 suffice to support partitioning them.

I quickly browsed/grepped through the source code of libparted, and I didn't
see anything regarding device names.  It just opens whatever block device
was specified and works with it.

If I use the 'parted' program on my debian unstable system here with a SDHCI
compliant card reader + 2GB SD card, I get:


prithivi:~# parted /dev/mmcblk0
GNU Parted 1.8.8
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Unknown (unknown)
Disk /dev/mmcblk0: 2013MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End SizeType File system  Flags
 1  131kB  2013MB  2013MB  primary  fat16 


So it just works fine.


  2. use a grub-install or similar program that can discover the bios
  drive number to /dev/mmcblk* device name mapping 
 
 This is essentially outside the scope of the installer itself. Once grub 
 (or grub2) supports the devices the installer should need at most minor 
 changes in its grub-installer component. Grub support is thus a 
 pre-requirement for adding support in the installer.

grub itself (the actual bootloader) has no problem.
grub2 supports /dev/mmcblk* out of the box

However, the old grub1 needs a one-line fix to the grub-install shellscript.  I
have sent a trivial patch to the grub developers, but they rejected it since
grub1 is no longer maintained.

So if Debian (or any other distribution) keeps shipping grub1, they would have
to add the small patch from 
http://savannah.gnu.org/bugs/download.php?file_id=16416

 Main thing to get support in Debian Installer is to find someone who has 
 both the hardware and the motivation to work on this. As said before, the 
 actual changes in D-I itself should be trivial.

I can help with actual testing on the hardware.  Right now VIA has too few
development boards internally to send them out to developers, sorry.

However, I have read that the eeePC or at least some of its models support
SD-boot, too.  If that is the case, there should be plenty people out there
with access to the hardware.

Also, to add the support for installing on SD card, you don't actually need
a bios that can boot it.  As long as you can partition, format and install the
dpkg's on the SD card, and you can put grub onto the card, everything should be
fine.

 If someone were to sponsor or loan me an SD card, I'd be happy to check if 
 libparted supports it and, if it does, do the needed partman changes.

the actual SD card is certainly not a problem. 2GB cards are around 5 EUR these
days (at least here in Taiwan), so less than the actual shipping cost.  I'm
happy to do a wire transfer to any account on the EU to enable you to buy a
card :)

-- 
- Harald Welte [EMAIL PROTECTED]  http://linux.via.com.tw/

VIA Open Source Liaison



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]