Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

[Eugene Berdnikov]

  Hello.
  
On Tue, May 14, 2024 at 10:44:37PM +0200, Aurelien Jarno wrote:
> On 2024-05-14 21:51, Chris Hofstaedtler wrote:
> > Hi Eugene,
> > 
> > could you please try again with:
> > util-linux 2.40.1-1
> > glibc 2.38-7 or newer
> > 
> > and report back, if the problem is fixed for you?
> > 
[...]
> 
> It appears that util-linux 2.40.1-1 has been rebuilt against a fixed
> glibc, so the problem is probably fixed. At the end it should be
> limited to util-linux versions 2.40-1 to 2.40-8. I don't think it is
> necessary to upgrade glibc to get the issue fixed.

 Installation of util-linux 2.40.1-1 (and accompanied libmount1,
 libuuid1, libblkid1, libsmartcols1 of the same version) solves
 the problem, output of "last" is correct.
 
 Thank you, guys!
-- 
 Eugene Berdnikov

Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

[Eugene Berdnikov]

Package: util-linux
Version: 2.40-8
Severity: normal

 Hello.

 Upgrade of util-linux from 2.39.3-6 to 2.40-8 on i386 systems breaks
 last(1), while the same upgrade on amd64 systems does not break it.
 Examples on my hosts running in 32-bit mode:

--
root@citrine # /usr/bin/last -3
last: unrecognized ut_type: 22985
last: preallocation size exceeded

--
root@typhoon # /usr/bin/last -3
last: unrecognized ut_type: 3640
last: unrecognized ut_type: 52
6.5.0-1- 3 Thu Jan  1 03:00gone - no logout
last: unrecognized ut_type: -14908
amd64evel  Sat Jul  6 11:21 - down  
(586103921+18:44)
last: preallocation size exceeded

--
root@passat # /usr/bin/last -3
last: unrecognized ut_type: -13985
last: unrecognized ut_type: 53
6.5.0-1- 2 Thu Jan  1 03:00gone - no logout
last: unrecognized ut_type: 15714
last: unrecognized ut_type: -4407
amd64evel  Sat Jul  6 11:21gone - no logout
last: unrecognized ut_type: -31324
last: unrecognized ut_type: 29555
6.5.0-1- b9Thu Jan  1 03:00gone - no logout
last: unrecognized ut_type: 2583
last: unrecognized ut_type: 29556
last: unrecognized ut_type: -18676
last: unrecognized ut_type: 19843
last: unrecognized ut_type: 14690
192.168. ts/9root  Thu Jan  1 03:00gone - no logout
last: preallocation size exceeded

--

 Running binary extracted from util-linux 2.39.3-6 package (as /tmp/last)
 always produce right results:
--
root@citrine # /tmp/last -3
root pts/9192.168.27.27Mon May  6 22:40   still logged in
root pts/9192.168.27.7 Mon May  6 10:19 - 13:20  (03:01)
root pts/10   192.168.27.17Fri May  3 16:12 - 19:10  (02:57)

wtmp begins Sun Apr 14 11:18:49 2024
--

 Package info:
 
||/ Name   Version  Architecture Description
+++-==---=
ii  util-linux 2.40-8   i386 miscellaneous system utilities
ii  libc-bin   2.37-18  i386 GNU C Library: Binaries
ii  libc-l10n  2.37-18  all  GNU C Library: localization files
ii  libc6:i386 2.37-18  i386 GNU C Library: Shared libraries

-- 
 Eugene Berdnikov

Bug#1053788: Mismatching references to /etc/default/exim(4)

[Eugene Berdnikov]

Package: exim4-config
Version: 4.97~RC1-2
Severity: normal

 Hello.
 
 Systemd unit "exi4.service" have "EnvironmentFile=-/etc/default/exim4",
 while post-install script generates /etc/default/exim (without "4").
 In particular:

% fgrep -r /etc/default/exim /var/lib/dpkg/info
/var/lib/dpkg/info/exim4-config.postinst:   # generate /etc/default/exim4
/var/lib/dpkg/info/exim4-config.postinst:   cat > /etc/default/exim << EOF
/var/lib/dpkg/info/exim4-config.postinst:# /etc/default/exim4
/var/lib/dpkg/info/exim4-config.postinst:   chmod 0644 /etc/default/exim
/var/lib/dpkg/info/exim4-config.postinst:   # generate /etc/default/exim4 
on fresh installations.
/var/lib/dpkg/info/exim4-config.postinst:   if test -z "$2" && test ! -e 
/etc/default/exim4 ; then
/var/lib/dpkg/info/exim4-config.postrm: rm -f /etc/default/exim4
%

 As a result, definitions from generated /etc/default/exim are ignored.
-- 
 Eugene Berdnikov

Bug#1051351: graphviz: Please package a new upstream version

[Eugene Toder]

Hi László,

Thank you for the quick response. I agree, uploading it to experimental
will make it easier for us (end users) to test it.

On Thu, Sep 7, 2023, 02:50 László Böszörményi (GCS)  wrote:

> Hi Eugene,
>
> On Wed, Sep 6, 2023 at 8:36 PM Eugene Toder  wrote:
> > It appears that the upstream version of graphviz was last updated in
> > September 2019, i.e. almost 4 years ago. Several new versions were
> > released since then with many bug fixes. Please package a new version.
>  I've already received several reports of this. As noted in these,
> I've the newest package version v8.1.0 ready [1]. As it's a big
> upstream release and I've split the original; packages to several
> others it needs testing. Some of it is already done, but I look
> forward your findings if any.
> In short, I think I should upload it to experimental to make it more
> visible for you, end users.
>
> Regards,
> Laszlo/GCS
> [1] dget -x https://people.debian.org/~gcs/graphviz_8.1.0-1.dsc
>

Bug#1051351: graphviz: Please package a new upstream version

[Eugene Toder]

Package: graphviz

Version: 2.42.2-7+b3

Severity: normal

X-Debbugs-Cc: elto...@gmail.com


Dear maintainer,

It appears that the upstream version of graphviz was last updated in

September 2019, i.e. almost 4 years ago. Several new versions were

released since then with many bug fixes. Please package a new version.

Some other distributions (Fedora, Arch, Alpine, Gentoo) have the latest

version.

Regards,

Eugene


-- System Information:

Debian Release: bookworm/sid

Architecture: amd64 (x86_64)



Kernel: Linux 5.15.112-ts1-amd64 (SMP w/6 CPU threads)

Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash

Init: unable to detect



Versions of packages graphviz depends on:

ii  libann01.1.2+doc-9+b1

ii  libc6  2.36-7

ii  libcdt52.42.2-7+b3

ii  libcgraph6 2.42.2-7+b3

ii  libexpat1  2.5.0-1

ii  libgcc-s1  12.2.0-13

ii  libgd3 2.3.3-9

ii  libglib2.0-0   2.74.6-2

ii  libgts-0.7-5   0.7.6+darcs121130-5+b1

ii  libgvc62.42.2-7+b3

ii  libgvpr2   2.42.2-7+b3

ii  liblab-gamut1  2.42.2-7+b3

ii  libstdc++6 12.2.0-13

ii  libx11-6   2:1.8.4-2+deb12u1

ii  libxaw72:1.0.14-1

ii  libxmu62:1.1.3-3

ii  libxt6 1:1.2.1-1.1



Versions of packages graphviz recommends:

ii  fonts-liberation2  2.1.5-1



Versions of packages graphviz suggests:

pn  graphviz-doc  

pn  gsfonts   



-- no debconf information

Bug#1041304: gnome-shell: Keyboard layout cannot be switched in popup windows (e.g. Nautilus rename box) under X11 session

[Eugene Romanenko]

Package: gnome-shell
Version: 43.6-1~deb12u1
Severity: normal

Dear Maintainer,

Keyboard layout cannot be switched in popup windows (e.g. Nautilus rename box) 
under X11 session

Steps to reproduce:
 - Select GNOME on X session on login
 - You must use multiple input sources (keyboard layouts)
 - Open Nautilus window, select some file/folder, press F2 to display rename box
 - Try to switch keyboard layout using keyboard shortcut - it doesn't work


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.37-2
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-2
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.6-1~deb12u1
ii  gir1.2-nm-1.01.42.4-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-2
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.40.3-2~deb12u1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.6-1~deb12u1
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u1
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-2
ii  libedataserver-1.2-273.46.4-2
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-2
ii  libglib2.0-bin   2.74.6-2
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.37-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.6-1~deb12u1
ii  libnm0   1.42.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  122-3
ii  libpolkit-gobject-1-0122-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-00.20.5-3
ii  libsystemd0  252.12-1~deb12u1
ii  libwayland-server0   1.21.0-1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libxfixes3   1:6.0.0-2
ii  python3   

Bug#1039582: gnome-shell: Can't switch keyboard layout using mouse under X11

[Eugene Romanenko]

Package: gnome-shell
Version: 43.6-1~deb12u1
Severity: normal

Dear Maintainer,

Keyboard layout cannot be switched in gnome-shell using mouse, when shell runs 
under X11 and input sources used individually for each window.

Steps to reproduce:
 - Select GNOME on X session on login
 - You must use multiple input sources (keyboard layouts)
 - You must check radiobutton "Switch input sources individually for each 
window" in Keyboard section of Settings.
 - Open some window (e.g. terminal)
 - Input source indicator on top bar show default layout (e.g. "en")
 - Click on input source indicator on top bar, select another layout (e.g. 
"bg") - window will temporarily lost focus and layot not switched.

 Under wayland session or when used same source for all windows layout switches 
correctly.


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU:ru
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.37-2
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-2
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.6-1~deb12u1
ii  gir1.2-nm-1.01.42.4-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-2
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.40.2-1~deb12u1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.6-1~deb12u1
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-2
ii  libedataserver-1.2-273.46.4-2
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-2
ii  libglib2.0-bin   2.74.6-2
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.37-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.6-1~deb12u1
ii  libnm0   1.42.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  122-3
ii  libpolkit-gobject-1-0122-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-0  

Bug#1034778: batch mode

[Eugene Berdnikov]

Package: easy-rsa
Version: 3.1.0-0.2
Severity: minor

 Script always runs in batch mode, regardless of "--batch" command line
 option and inlined help. It's impossible to switch to non-batch mode.
 Following path fixes it.

--- easyrsa 2023-03-21 21:46:48.0 +0300
+++ easyrsa.p1  2023-04-21 23:40:19.0 +0300
@@ -1422,10 +1422,10 @@
 
# create request
EASYRSA_REQ_CN="$name"
-   gen_req "$name" batch ${nopass+ nopass}
+   gen_req "$name" ${ssl_batch+ batch} ${nopass+ nopass}
 
# Sign it
-   ( sign_req "$crt_type" "$name" batch ) || {
+   ( sign_req "$crt_type" "$name" ${ssl_batch+ batch} ) || {
rm -f "$req_out" "$key_out"
    die "Failed to sign '$name' - See error messages above for 
details."
}

-- 
 Eugene Berdnikov

Bug#1033505: caja: Hyphenation marks in long file names are NOT needed AT ALL! Why did they make this stupid function?!

[Eugene]

Package: caja
Version: 1.24.0-1
Severity: important
X-Debbugs-Cc: sher...@gmail.com

Dear Maintainer,

*** 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.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 caja depends on:
ii  caja-common   1.24.0-1
ii  desktop-file-utils0.26-1
ii  gvfs  1.46.2-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-13+deb11u5
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcaja-extension11.24.0-1
ii  libexempi82.5.2-1
ii  libexif12 0.6.22-3
ii  libgail-3-0   3.24.24-4+deb11u2
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.66.8-1
ii  libglib2.0-bin2.66.8-1
ii  libglib2.0-data   2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u2
ii  libice6   2:1.0.10-1
ii  libmate-desktop-2-17  1.24.1-2
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libselinux1   3.1-3
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.7.2-1
ii  libxml2   2.9.10+dfsg-6.7+deb11u3
ii  mate-desktop  1.24.1-2
ii  shared-mime-info  2.0-1

Versions of packages caja recommends:
ii  gvfs-backends  1.46.2-1

Versions of packages caja suggests:
ii  engrampa1.24.1-1
pn  gstreamer1.0-tools  
pn  meld

Bug#1024592: systemd configuration for inetd mode is broken in 1:9.1p1-1

[Eugene Berdnikov]

Package: openssh-server
Version: 1:9.1p1-1
Severity: minor

 After upgrade from 1:9.0p1-1+b1 to 1:9.1p1-1 sshd starts under systemd
 as standalone daemon only.

 1. File /lib/systemd/system/ssh@.service is missing in 1:9.1p1-1,
while /lib/systemd/system/ssh.socket is present.
So sshd can not be run as inetd-style service, because ".socket"
requires apropriate "@.service" unit.

 2. Unit file /lib/systemd/system/ssh.socket has considerable changes
in comparison with old 1:9.0p1-1+b1. First, it's [Unit] section
has "Before=sockets.target", and [Install] section has
"WantedBy=sockets.target", it seems contradictionry to me.
Then, old version 1:9.0p1-1+b1 has two options in this section:
"Before=ssh.service" and "Conflicts=ssh.service". It prevents
from concurent access to listening socket. New package 1:9.1p1-1
has no such options.

 Result: with ssh.service=disabled and ssh.socket=enabled port 22 is
 listened by two process: by systemd and by sshd daemon. All incoming
 connections are handled by standalone sshd daemon, probably because
 systemd can't handle them due to absence of @.service unit file.

 If unit files ssh.socket and ssh@.service are taken from old package,
 all works right as expected.
-- 
 Eugene Berdnikov

Bug#1011483: closed by Chris Hofstaedtler (Re: #1011483 duplicate/related to #1003366)

[Eugene Losowski-Gallagher]

Hi Chris,

Thank you for the prompt to test against sid.
I just tested and can confirm that it works.

Thank you so much for the help.

Eugene

On Thu, 4 Aug 2022 at 13:00, Chris Hofstaedtler  wrote:

> Hi Eugene,
>
> * Eugene Losowski-Gallagher 
> [220804 08:25]:
> > Ref: Bug#1011483
> (please keep the bug in To:)
>
> > Thank you for the comment on closing, and apologies for the delay in
> > writing.
> > I'll admit the description is poor (I submitted too early while trying to
> > report it- so didn't properly write the description to match the title).
> >
> > Questions on this closing:
> > 1) What is happening to the patch attached?
> > 2) I also wrote a patch for 1003366 - and both should resolve the issues
> on
> > OpenISCSI (just needs to be applied in order 1003366 first, then
> 1011483).
>
> > I have tested these and am using the "dev" build as installation media
> > until these get applied.
> >
> > Please advice how to proceed: New ticket for all components + patch,
> > patches applied (and both closed), etc?
>
> As far as I know, iscsi now works in the installer. I tried a sid
> installer from a few days ago and successfully installed a new VM.
>
> Is there anything left to do / something that does not work for you?
>
> Chris
>
>

-- 

*Eugene Losowski-Gallagher*
*Mob: *07825160923

Bug#1011483: closed by Chris Hofstaedtler (Re: #1011483 duplicate/related to #1003366)

[Eugene Losowski-Gallagher]

Hi Chris,

Ref: Bug#1011483

Thank you for the comment on closing, and apologies for the delay in
writing.
I'll admit the description is poor (I submitted too early while trying to
report it- so didn't properly write the description to match the title).

Questions on this closing:
1) What is happening to the patch attached?
2) I also wrote a patch for 1003366 - and both should resolve the issues on
OpenISCSI (just needs to be applied in order 1003366 first, then 1011483).

I have tested these and am using the "dev" build as installation media
until these get applied.

Please advice how to proceed: New ticket for all components + patch,
patches applied (and both closed), etc?

Many thanks

Eugene


On Fri, 29 Jul 2022 at 21:27, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the open-iscsi package:
>
> #1011483: reportbug: open-iscsi-udeb - iscsiadm InitiatorName not set:
> /etc/iscsi/initiatorname.iscsi does not exist
>
> It has been closed by Chris Hofstaedtler .
>
> 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 Chris Hofstaedtler <
> z...@debian.org> by
> replying to this email.
>
>
> --
> 1011483: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011483
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Chris Hofstaedtler 
> To: 1011483-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 29 Jul 2022 22:22:17 +0200
> Subject: Re: #1011483 duplicate/related to #1003366
> I'll close this bug (doesnt have much info) in favor of #1003366.
>
>
> -- Forwarded message --
> From: Eugene 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 23 May 2022 22:02:09 +0100
> Subject: reportbug: open-iscsi-udeb - iscsiadm InitiatorName not set:
> /etc/iscsi/initiatorname.iscsi does not exist
> Package: open-iscsi
> Version: 2.1.3-5
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: eugene.losowskigallag...@googlemail.com
>
> Dear Maintainer,
>
> *** 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: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages open-iscsi depends on:
> ii  debconf [debconf-2.0]  1.5.77
> ii  libc6  2.31-13+deb11u3
> ii  libisns0   0.100-3
> ii  libkmod2   28-1
> ii  libmount1  2.36.1-8+deb11u1
> ii  libopeniscsiusr2.1.3-5
> ii  libssl1.1  1.1.1n-0+deb11u2
> ii  libsystemd0247.3-7
> ii  udev   247.3-7
>
> open-iscsi recommends no packages.
>
> open-iscsi suggests no packages.
>
> -- debconf information excluded
>


-- 

*Eugene Losowski-Gallagher*
*Mob: *07825160923

Bug#1014894: firmware-amd-graphics: With the firmware installed Teamviewer unable to start with segfault error

[Eugene Klepikoff]

Package: firmware-amd-graphics
Version: 20210818-1
Severity: normal

Dear Maintainer,

On my older laptop ASUS F5RL on boot I was having a warning of a missing
firmware for Raderon graphics, I installed this firmware and the warning
disappeared, system is working ok, but I have problems with at least two
programs: Teamviewer - it fails to start, giving a "segfault" error and a
wine program which is also fails to start, giving another error (I'll
provide it if needed). Once I delete the firmware package and update
initramfs both programs begin to work properly.
Graphic card installed is ATI Radeon Xpress 1100
I tried to install two previous versions of the firmware: 20210315-3
and 20190114-2 - the result was the same.

I know the laptop is quite old but still working. Please consider a fix.
Thanks.


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

Kernel: Linux 5.10.0-16-686 (SMP w/2 CPU threads)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.140

-- no debconf information

-- 
Best regards, Eugene.

Bug#1011483: reportbug: open-iscsi-udeb - iscsiadm InitiatorName not set: /etc/iscsi/initiatorname.iscsi does not exist

[Eugene]

Package: open-iscsi
Version: 2.1.3-5
Severity: normal
Tags: d-i
X-Debbugs-Cc: eugene.losowskigallag...@googlemail.com

Dear Maintainer,

*** 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: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libisns0   0.100-3
ii  libkmod2   28-1
ii  libmount1  2.36.1-8+deb11u1
ii  libopeniscsiusr2.1.3-5
ii  libssl1.1  1.1.1n-0+deb11u2
ii  libsystemd0247.3-7
ii  udev   247.3-7

open-iscsi recommends no packages.

open-iscsi suggests no packages.

-- debconf information excluded
>From e9617133456f23cff32a00ee1e1668be38167b6c Mon Sep 17 00:00:00 2001
From: Eugene Losowski-Gallagher 
Date: Mon, 23 May 2022 21:51:43 +0100
Subject: [PATCH] iSCSI started in installer environment - Disks detected for
 installation

---
 debian/rules | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 22ccf63..3c96ee4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -84,7 +84,9 @@ ifneq ($(UDEB),)
dh_install -p open-iscsi-udeb utils/iscsi_discovery sbin/
dh_install -p open-iscsi-udeb utils/iscsi-iname sbin/
dh_install -p open-iscsi-udeb etc/iscsid.conf etc/iscsi/
-   dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start 
sbin/iscsi-start
+   # Debian package cannot rename file so will create a symbolic link 
instead
+   dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start sbin/
+   ln -sf /sbin/open-iscsi-udeb.start 
debian/open-iscsi-udeb/sbin/iscsi-start
dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.finish-install 
usr/lib/finish-install.d/10open-iscsi
 
# Ship shared libraries along with the executable in a single udeb
-- 
2.20.1

Bug#1003366: reportbug: open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer environment

[Eugene Losowski-Gallagher]

Hi All,

I have a patch:
0001-iscsid-in-udeb-not-dependent-on-libsystemd-Closes-10.patch
(attached)

Unfortunately I cannot create merge requests direct, or via email on the
project.

On Tue, 11 Jan 2022 at 20:03, Eugene Losowski-Gallagher <
eugene.losowskigallag...@googlemail.com> wrote:

> Hi Ritesh,
>
> Thank you for the clarification on using "iscsistart".
>
> I have followed this up through the installer.
>
> To explain the use-case in its entirety:
> 1) Use starts a machine on a TGT enabled (iscsi-target) network
> 2) User tests the network by entering the host name of the tgt
># This is the step that fails! - uses "iscsiadm" which is dependent on
> "iscsid"
> 3) User selects the drives they want to use, and then proceed with setup
> (formatting etc)
> -- Installer continues as normal ---
>
>
> Explanation of 2)
> To perform the discovery and testing of the tgt the installer uses:
> "iscsiadm"
>   This works via communicating with "iscsid"
>   And that takes us back to the libsystemd.so.0 dependency.
> So we need to get "iscsid" running without the "libsystemd" dependency.
>
>
> Explanation of 3)
> "iscsistart"
> 1) This is an application to start the initiator
> - As far as I am aware this works fine, just requires a lot of parameters
> to begin
>
>
> So thinking about this (and looking at the repositories for the original
> and debian versions):
> 1) The upstream repository (https://github.com/open-iscsi/open-iscsi) has
> a "NO_SYSTEMD" build
> 2) The project gets built with autoconf (and this might the the cause of
> my woes) - as systemd is detected at build time.
> This is confirmed in the "debian/control" file - where it is a build
> dependency.
>
>
> To move forward on this:
> Q1) Is it at all possible to make a "NO_SYSTEMD" build for the
> "open-iscsi-udeb" package
> - this is a define present in:
>   https://github.com/open-iscsi/open-iscsi
> This will require some change(s) in the build setup for the udeb
> (crucially not change the normal package!)
>
> Please can you let me know if that (i.e 2x builds) is acceptable?
>
>
> That should in theory resolve the issue properly:
> 1) *-udeb is not installed on the system
> 2) systemd is (still) not used in the installer environment
> 3) iscsid will start as it is not linked to systemd
> 4) This allows iscsiadm to discover the iSCSI drives
> 5) Installer for partman-iscsi works properly
>
>
> I hope this allows (at least in theory) a way forward.
> - At least explaining why it doesn't work as expected.
>
> The practicalities might be more difficult - but with your approval of the
> overall strategy I can work on it.
>
> Many thanks
>
> Eugene
>


-- 

*Eugene Losowski-Gallagher*
*Mob: *07825160923
From 5c31bbac1c04855eedd27c5b113ef83bc8ac4caa Mon Sep 17 00:00:00 2001
From: Eugene Losowski-Gallagher 
Date: Mon, 16 May 2022 21:32:55 +0100
Subject: [PATCH] iscsid in udeb not dependent on libsystemd (Closes: #1003366)

---
 debian/rules | 29 ++---
 usr/Makefile |  3 +++
 2 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2451953..22ccf63 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,9 +20,24 @@ override_dh_auto_configure:
 
 override_dh_auto_build:
 	@# Let debhelper pass configure flags.
+	# Build standard open-iscsi
 	dh_auto_configure --sourcedirectory=iscsiuio
-
 	CFLAGS="$(CPPFLAGS) $(CFLAGS)" dh_auto_build
+	mkdir -p usr-deb
+	mv usr/iscsid usr-deb/iscsid
+	mv usr/iscsistart usr-deb/iscsistart
+	mv usr/iscsiadm usr-deb/iscsiadm
+ifneq ($(UDEB),)
+	(cd usr; make clean)
+	# Build No libsystemd version first for udeb integration
+	export NO_SYSTEMD=1; CFLAGS="$(CPPFLAGS) $(CFLAGS)" dh_auto_build
+	@# Move binaries to udeb directory
+	mkdir -p usr-udeb
+	mv usr/iscsid usr-udeb/iscsid
+	mv usr/iscsistart usr-udeb/iscsistart
+	mv usr/iscsiadm usr-udeb/iscsiadm
+endif
+
 
 override_dh_auto_install:
 
@@ -33,9 +48,9 @@ override_dh_auto_install:
 	dh_install -p libopeniscsiusr-dev libopeniscsiusr/libopeniscsiusr/ usr/include/
 
 	@# open-iscsi
-	dh_install -p open-iscsi usr/iscsid sbin/
-	dh_install -p open-iscsi usr/iscsistart sbin/
-	dh_install -p open-iscsi usr/iscsiadm sbin/
+	dh_install -p open-iscsi usr-deb/iscsid sbin/
+	dh_install -p open-iscsi usr-deb/iscsistart sbin/
+	dh_install -p open-iscsi usr-deb/iscsiadm sbin/
 	dh_install -p open-iscsi utils/iscsi_discovery sbin/
 	dh_install -p open-iscsi utils/iscsi-iname sbin/
 	dh_install -p open-iscsi etc/iscsid.conf etc/iscsi/
@@ -63,9 +78,9 @@ override_dh_auto_install:
 
 ifneq ($(UDEB),)
 	@# open-iscsi-udeb
-	dh_install -p open-iscsi-udeb usr/i

Bug#1010260: lintian: false positive maintainer-script-empty if it has conditional exit

[Eugene Crosser]

Package: lintian
Version: 2.114.0ubuntu1
Severity: normal

Dear Maintainer,

maintainer-script may have as its only function to forbid package
installation or upgrade. For instance, I have a `preinst` script that
forbids upgrade but does not forbid its installation:

=
#!/bin/sh
set -e

case $1 in
upgrade)
  echo "" >&2
  echo "*** This package cannot be live-upgraded, it is supposed ***" >&2
  echo "*** to be preinstalled in the bootable image ***" >&2
  echo "" >&2
  exit 1
  ;;
esac

#DEBHELPER#

exit 0
=

In my view, this is a perfectly valid use case, however the check for
"empty maintainer script" in lib/Lintian/Check/MaintainerScripts/Empty.pm
line 86 detects such script as "empty" and reports a warning.

I have posted a comment about the same in salsa gitlab:
https://salsa.debian.org/lintian/lintian/-/commit/aa476eb35498f84eb5214a483cd68be9b28188fe#note_306753

-- System Information:
Irrelevant since I am filing it from a workstation, and the problem
exists in the master branch of the lintian repo.

-- no debconf information

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Eugene Berdnikov]

  Hi.
  
On Fri, Oct 22, 2021 at 01:44:38AM +0200, Florian Schlichting wrote:
> On Thu, Oct 21, 2021 at 04:25:28PM +0300, Eugene Berdnikov wrote:
> >   Hi Florian.
> >   
> > On Thu, Oct 21, 2021 at 03:11:41PM +0200, Florian Schlichting wrote:
> > > I've just uploaded xpdf 3.04+git20211021-1 which should fix #996832 -
> > > once it hits the mirrors in a few hours, can you check if that improves
> > > your issue as well?
> > 
> >  Can you give a direct url of package for download?
> 
> there's a mirror sync like 4 times a day, so it can take a while. By
> now, the new package can be seen here:
> https://packages.debian.org/sid/xpdf
> 
> from which you can follow links to (for example)
> - 
> http://ftp.ru.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_amd64.deb
> - 
> http://ftp.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_i386.deb
> or whatever suits you

 The 3.04+git20220201-1 Debian package was tried today, but it has same
 problems: question marks where "Page" and "Size" should be,
 "?" and "+" instead of letters in table of contents and in search form.
 Tested for LANG=C and russian locale "ru_RU.UTF8".
-- 
 Eugene Berdnikov

Bug#1003366: reportbug: open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer environment

[Eugene Losowski-Gallagher]

Hi Ritesh,

Thank you for the clarification on using "iscsistart".

I have followed this up through the installer.

To explain the use-case in its entirety:
1) Use starts a machine on a TGT enabled (iscsi-target) network
2) User tests the network by entering the host name of the tgt
   # This is the step that fails! - uses "iscsiadm" which is dependent on
"iscsid"
3) User selects the drives they want to use, and then proceed with setup
(formatting etc)
-- Installer continues as normal ---


Explanation of 2)
To perform the discovery and testing of the tgt the installer uses:
"iscsiadm"
  This works via communicating with "iscsid"
  And that takes us back to the libsystemd.so.0 dependency.
So we need to get "iscsid" running without the "libsystemd" dependency.


Explanation of 3)
"iscsistart"
1) This is an application to start the initiator
- As far as I am aware this works fine, just requires a lot of parameters
to begin


So thinking about this (and looking at the repositories for the original
and debian versions):
1) The upstream repository (https://github.com/open-iscsi/open-iscsi) has a
"NO_SYSTEMD" build
2) The project gets built with autoconf (and this might the the cause of my
woes) - as systemd is detected at build time.
This is confirmed in the "debian/control" file - where it is a build
dependency.


To move forward on this:
Q1) Is it at all possible to make a "NO_SYSTEMD" build for the
"open-iscsi-udeb" package
- this is a define present in:
  https://github.com/open-iscsi/open-iscsi
This will require some change(s) in the build setup for the udeb
(crucially not change the normal package!)

Please can you let me know if that (i.e 2x builds) is acceptable?


That should in theory resolve the issue properly:
1) *-udeb is not installed on the system
2) systemd is (still) not used in the installer environment
3) iscsid will start as it is not linked to systemd
4) This allows iscsiadm to discover the iSCSI drives
5) Installer for partman-iscsi works properly


I hope this allows (at least in theory) a way forward.
- At least explaining why it doesn't work as expected.

The practicalities might be more difficult - but with your approval of the
overall strategy I can work on it.

Many thanks

Eugene

Bug#1003366: reportbug: open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer environment

[Eugene]

Package: open-iscsi
Version: 2.1.3-5
Severity: important
Tags: d-i




-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  libisns0   0.100-3
ii  libkmod2   28-1
ii  libmount1  2.36.1-8
ii  libopeniscsiusr2.1.3-5
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libsystemd0247.3-6
ii  udev   247.3-6

open-iscsi recommends no packages.

open-iscsi suggests no packages.

-- debconf information excluded

*** /tmp/open-iscsi-bugreport
open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer 
environment

PACKAGE:
open-iscsi-udeb (only a bug in the installer environment)

FIX REQUIRED:
* Add libsystemd0 to following packages in:
https://salsa.debian.org/linux-blocks-team/open-iscsi
debian/control
open-iscsi "Depends"
open-iscsi-udeb "Depends"

LOGIC/REASONING:
1) libsystemd is a "Build-Depends" for this package (but is omitted in the 
run-time dependency list "Depends" 

---

2) When running the debian-installer (partman-iscsi), this calls open-iscsi 
package to setup ISCSI drives at install time

2.1) The iscsi setup fails because "/sbin/iscsid" cannot run due to being 
unable to find "libsystemd0.so"

2.2) Further checks on the installer environment show that "libsystemd.so.0" is 
not present in /lib directory

---

3) "libsystemd.so.0" is present once installed (so this is purely installer 
related)

---

*) It also complains about missing "/etc/iscsi/initiatorname.iscsi" - but I am 
hoping that is setup automatically once the daemon starts




STEPS TO REPRODUCE:
1) Run installer on an environment with a iSCSI Target setup (I used tgt on 
QEMU)
2) On "Detect Disks" and "Partition Disks" go to "Configure iSCSI volumes"
3) Enter the host details for the iscsi target
-- FAILS --
4) Review the logs (Console and /var/logs/syslog)
-4.1 Shows that cannot start "iscsid"

Expected behavior is
1) iscsi daemon starts - and so can find the drives
2) Failing the above should be able to use the console from installer mode, to 
discover the iSCSI drives on the target

Bug#1003008: Error 134633601: Error while parsing number"

[Eugene Berdnikov]

Package: grub-legacy
Version: 0.97-79
Severity: Normal

 After upgrade grub-legacy from 0.97-78 to 0.97-79 installation fails
 with message "Error 134633601: Error while parsing number":

-
grub> root (hd0,0)
root (hd0,0)
 Filesystem type is ext2fs, partition type 0x8065e03
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd-141250989)"... failed (this is not 
fatal)
 Running "embed /grub/e2fs_stage1_5 (hd-141250989,-"... failed (this is not 
fatal)
 Running "install /grub/stage1 (hd-141250989) /grub/stage2 p /grub/menu.lst 
"... failed

Error 134633601: Error while parsing number
-

 Observed on all updated hosts (about ten in my own). Rollback to 0.97-78
 resolves the problem (with the same config files).

 Package versions:

ii  grub-legacy0.97-79  amd64GRand Unified Bootloader (Legacy 
version)
ii  grub-common2.04-20  amd64GRand Unified Bootloader (common 
files)
ii  libc6-i386 2.33-1   amd64GNU C Library: 32-bit shared 
libraries for AMD64

 Debian version: Debian GNU/Linux bookworm/sid (64bit)
-- 
 Eugene Berdnikov

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Eugene Berdnikov]

  Hi Florian.
  
On Thu, Oct 21, 2021 at 03:11:41PM +0200, Florian Schlichting wrote:
> I've just uploaded xpdf 3.04+git20211021-1 which should fix #996832 -
> once it hits the mirrors in a few hours, can you check if that improves
> your issue as well?

 Can you give a direct url of package for download?
-- 
 Eugene Berdnikov

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Eugene Berdnikov]

ritev(3, 
[{iov_base="\22\0h\0\1\0\200\0037\2\0\0007\2\0\0\10\0\20\0\206\1\0\0l\0;\0\206\1\0\0\0\0\1\0\37\0\0\0\5\0\37\0\0\0b\1\0\0\6\2\0\0\7\2\0\0V\2\0\0\1\0`\201\234\1\1\0\0)\237\1\1\,\237\1\1\0\300l\237\1\1\0@o\237\1\1\0\320)\241\1\1\0\260R\241\1\1\0\240\230\372\0\1\0\320?\375\0\1\0\360C\375\0\1\0
 \207\375\0\1\0\260\212\375\0\1\0\340D\377\0\1\0pn\377\0\1\0 
Iw\0\1\0`\360y\0\1\0\320\364y\0\1\0`Hz\0\1\0\220Kz\0\1\0\320\364{\0\1\0\0\36|\0\1\0\300y
 \2\1\0\320!#\2"..., iov_len=420}, {iov_base=NULL, iov_len=0}, {iov_base="", 
iov_len=0}], 3) = 420
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\2\332\3\0\0\0\0\16\0@\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
 iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="%\0\1\0", iov_len=4}, {iov_base=NULL, iov_len=0}, 
{iov_base="", iov_len=0}], 3) = 4
recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, 
[{iov_base="5\30\4\0006\1`\3\236\0\0\0L\0\v\0F\0\5\0006\1`\3\24\0`\3\0\0\0\0\10\0\v\0B\0\v\0006\1`\3\16\0`\3\0\0\0\0\7\0\0\0\0\0\1\0\6\0\1\0\0\0\2\0\0\0\n\0\1\0\2\0\1\0\t\0B\0\v\0006\1`\3\17\0`\3\1\0\n\0\7\0\n\0\2\0\t\0\7\0\t\0\7\0\1\0\7\0\n\0\6\0\2\0\6\0\n\0$\207\1\0\24\0\6\0\1\0\200\0037\2\0\0007\2\0\0\0\0\0\0\240\206\1\0",
 iov_len=152}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 152
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\10\341\3b\0\0\0007\2\0\0\0\0\0\0\206\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0l\0;\0\206\1\0\0\0\0\1\0\37\0\0\0\5\0\37\0\0\0b\1\0\0\6\2\0\0\7\2\0\0V\2\0\0\1\0`\201\234\1\1\0\0)\237\1\1\,\237\1\1\0\300l\237\1\1\0@o\237\1\1\0\320)\241\1\1\0\260R\241\1\1\0\240\230\372\0\1\0\320?\375\0\1\0\360C\375\0\1\0
 \207\375\0\1\0\260\212\375\0\1\0\340D\377\0\1\0pn\377\0\1\0 
Iw\0\1\0`\360y\0\1\0\320\364y\0\1\0`Hz\0\1\0\220Kz\0\1\0\320\364{\0\1\0\0\36|\0\1\0\300y"...,
 iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 424
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="+\30\1\0", iov_len=4}, {iov_base=NULL, iov_len=0}, 
{iov_base="", iov_len=0}], 3) = 4
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\2\342\3\0\0\0\0\16\0@\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
 iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, 
[{iov_base="\22\0i\0\1\0\200\0037\2\0\0007\2\0\0\10\0\5\0\214\1\0\0l\0<\0\214\1\0\0\0\0\1\0\37\0\0\0\5\0\37\0\0\0b\1\0\0\6\2\0\0\7\2\0\0V\2\0\0\1\0`\201\234\1\1\0\0)\237\1\1\,\237\1\1\0\300l\237\1\1\0@o\237\1\1\0\320)\241\1\1\0\260R\241\1\1\0\240\230\372\0\1\0\320?\375\0\1\0\360C\375\0\1\0
 \207\375\0\1\0\260\212\375\0\1\0\340D\377\0\1\0pn\377\0\1\0 
Iw\0\1\0`\360y\0\1\0\320\364y\0\1\0`Hz\0\1\0\220Kz\0\1\0\320\364{\0\1\0\0\36|\0\1\0\300y
 \2\1\0\320!#\2"..., iov_len=424}, {iov_base=NULL, iov_len=0}, {iov_base="", 
iov_len=0}], 3) = 424
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\2\344\3\0\0\0\0\16\0@\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
 iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="%\0\1\0", iov_len=4}, {iov_base=NULL, iov_len=0}, 
{iov_base="", iov_len=0}], 3) = 4
recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN (Resource temporarily 
unavailable)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++


 I'll return to 64-bit workstation in several hours.
-- 
 Eugene Berdnikov

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Eugene Berdnikov]

On Thu, Oct 21, 2021 at 12:28:56AM +0100, Adam Sampson wrote:
> On Thu, Oct 21, 2021 at 12:23:16AM +0100, Adam Sampson wrote:
> > [xpdf crashes in Motif on] asc = _XmRendXftFont(rend)->ascent;
> 
> Hmm -- the crash in #996832 is happening in the same place...
> 
> Do you have an Xpdf*font: resource (or something similar) set on your
> display?

% xrdb -query | fgrep -i xpdf
Xpdf*fileFilterStyle:   filter_hidden_files

 It is definitely loaded from /etc/X11/Xresources/xpdf
 (part of Debian xpdf package).
-- 
 Eugene Berdnikov

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Eugene Berdnikov]

, value = 139938285711260}, {name 
= 0x0, value = 94517303531376}}
n = 1
i = 
s = 0x55f686580e70
buf = "\001\000\243", '\000' 
#10 0x55f685786288 in XPDFViewer::init (this=0x55f68650ed40, 
appA=, doc=0x0, fileName=0x55f68650ea10, pageA=1, destName=0x0, 
fullScreen=false, ownerPassword=0x0, userPassword=0x0) at xpdf/XPDFViewer.cc:282
dest = std::unique_ptr = {get() = 0x0}
pg = 1
z = 
#11 0x55f6857864b2 in XPDFViewer::XPDFViewer 
(this=this@entry=0x55f68650ed40, appA=appA@entry=0x55f6864c24b0, 
fileName=fileName@entry=0x55f68650ea10, pageA=pageA@entry=1, 
destName=destName@entry=0x0, fullScreen=, ownerPassword=0x0, 
userPassword=0x0) at xpdf/XPDFViewer.cc:254
No locals.
#12 0x55f68576d0d6 in XPDFApp::open (this=this@entry=0x55f6864c24b0, 
fileName=fileName@entry=0x55f68650ea10, page=page@entry=1, dest=dest@entry=0x0, 
ownerPassword=ownerPassword@entry=0x0, userPassword=userPassword@entry=0x0) at 
xpdf/XPDFApp.cc:230
viewer = 0x55f68650ea10
#13 0x55f68576329d in main (argc=, argv=) at 
xpdf/xpdf.cc:275
app = std::unique_ptr = {get() = 0x55f6864c24b0}
fileName = std::unique_ptr, std::allocator >> = {get() = 0x55f68650ea10}
pg = 1
destName = std::unique_ptr, std::allocator >> = {get() = 0x0}
userPassword = std::unique_ptr, std::allocator >> = {get() = 0x0}
ownerPassword = std::unique_ptr, std::allocator >> = {get() = 0x0}
ok = 
(gdb) quit

Depends:

ii  libc6:amd64   2.32-4 
amd64GNU C Library: Shared libraries
ii  libc6-dbg:amd64   2.32-4 
amd64GNU C Library: detached debugging symbols
ii  libc6-dev:amd64   2.32-4 
amd64GNU C Library: Development Libraries and Header Files
ii  libc6-i3862.32-4 
amd64GNU C Library: 32-bit shared libraries for AMD64
ii  libgcc-s1:amd64   11.2.0-9   
amd64GCC support library
ii  libpaper1:amd64   1.1.28+b1  
amd64library for handling paper characteristics
ii  libpoppler102:amd64   20.09.0-3.1
amd64PDF rendering library
ii  libx11-6:amd642:1.7.2-2+b1   
amd64X11 client-side library
ii  libxt6-dbgsym:amd64   1:1.2.0-1  
amd64debug symbols for libxt6
ii  libxm4:amd64  2.3.8-3
amd64Motif - X/Motif shared library
ii  libxm4-dbgsym:amd64   2.3.8-3
amd64debug symbols for libxm4
ii  libxt6:amd64  1:1.2.0-1  
amd64X11 toolkit intrinsics library

% uname -rv
5.8.0-2-amd64 #1 SMP Debian 5.8.10-1 (2020-09-19)

-- 
 Eugene Berdnikov

Bug#995844: 5.1-2 crash in auth

[Eugene Berdnikov]

 75, static STRLEN_IP6S = 48, static MAX_IP6_STRLEN = 
75, static v4_localhost = {__in6_u = {__u6_addr8 = 
"\000\000\000\000\000\000\000\000\000\000\377\377\177\000\000\001", __u6_addr16 
= {0, 0, 0, 0, 0, 65535, 127, 256}, __u6_addr32 = {0, 0, 4294901760, 
16777343}}}, static v4_anyaddr = {__in6_u = {__u6_addr8 = 
"\000\000\000\000\000\000\000\000\000\000\377\377\000\000\000", __u6_addr16 = 
{0, 0, 0, 0, 0, 65535, 0, 0}, __u6_addr32 = {0, 0, 4294901760, 0}}}, static 
v4_noaddr = {__in6_u = {__u6_addr8 = 
"\000\000\000\000\000\000\000\000\000\000\377\377\377\377\377\377", __u6_addr16 
= {0, 0, 0, 0, 0, 65535, 65535, 65535}, __u6_addr32 = {0, 0, 4294901760, 
4294967295}}}, static v6_noaddr = {__in6_u = {__u6_addr8 = '\377' , __u6_addr16 = {65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535}, 
__u6_addr32 = {4294967295, 4294967295, 4294967295, 4294967295
#31 0x556418e193aa in Comm::DoSelect (msec=, msec@entry=392) 
at ModEpoll.cc:275
num = 
i = 0
fd = 11
F = 0x7f96bd2622a0
hdl = 
cevents = 0x7f96bc81e010
__FUNCTION__ = "DoSelect"
#32 0x556418dc54ad in CommSelectEngine::checkEvents (this=, 
timeout=392) at comm.cc:1888
last_timeout = 1632681851
#33 0x556418b7aeb0 in EventLoop::checkEngine (this=0x7ffc34e64f40, 
engine=0x7ffc34e64ec0, primary=) at EventLoop.cc:36
requested_delay = 
__FUNCTION__ = "checkEngine"
#34 0x556418b7b09a in EventLoop::runOnce (this=this@entry=0x7ffc34e64f40) 
at EventLoop.cc:115
sawActivity = 
waitingEngine = 0x7ffc34e64ec0
__FUNCTION__ = {, , , 
, , , , }
#35 0x556418b7b1b8 in EventLoop::run (this=this@entry=0x7ffc34e64f40) at 
EventLoop.cc:83
No locals.
#36 0x556418c7bd4b in SquidMain (argc=, argv=) at main.cc:1716
cmdLine = {argv_ = std::vector of length 7, capacity 7 = 
{0x55641a3f92e0 "(squid-1)", 0x55641a3f93a0 "--kid", 0x55641a3f9460 "squid-1", 
0x55641a3f9520 "-YC", 0x55641a3f9b40 "-f", 0x55641a3fa200 
"/etc/squid/squid.conf", 0x0}, shortOptions_ = 0x55641a423c60 
"CDFNRSYXa:d:f:hk:m::n:sl:u:vz?", longOptions_ = std::vector of length 5, 
capacity 8 = {{ = {name = 0x55641a3f9820 "foreground", has_arg = 0, 
flag = 0x0, val = 2}, }, { = {name = 0x55641a3f9a80 
"kid", has_arg = 1, flag = 0x0, val = 3}, }, { = {name 
= 0x55641a3fa140 "help", has_arg = 0, flag = 0x0, val = 104}, }, { = {name = 0x55641a3fa800 "version", has_arg = 0, flag = 
0x0, val = 118}, }, { = {name = 0x0, has_arg = 0, flag 
= 0x0, val = 0}, }}}
WIN32_init_err = 0
__FUNCTION__ = "SquidMain"
mainLoop = {errcount = 0, static Running = 0x7ffc34e64f40, last_loop = 
false, engines = std::vector of length 4, capacity 4 = {0x7ffc34e64e80, 
0x55641915e760 , 0x7ffc34e64ea0, 0x7ffc34e64ec0}, 
timeService = 0x7ffc34e64df8, primaryEngine = 0x7ffc34e64ec0, loop_delay = 392, 
error = false, runOnceResult = false}
signalEngine = { = {_vptr.AsyncEngine = 0x5564190be358 
}, }
store_engine = { = {_vptr.AsyncEngine = 0x5564190be330 
}, }
comm_engine = { = {_vptr.AsyncEngine = 0x5564190cec58 
}, }
time_engine = {_vptr.TimeEngine = 0x5564190be5d8 }
#37 0x556418b1c9c2 in SquidMainSafe (argv=0x7ffc34e65348, argc=6) at 
main.cc:1403
__FUNCTION__ = { }
_dbg_level = 
_dbo = 
#38 main (argc=6, argv=0x7ffc34e65348) at main.cc:1391
No locals.

Kernel: 5.8.0-1-amd64

||/ Name  Version Architec
+++-=-===-
ii  libc6:amd64   2.32-4  amd64   
ii  libcap2:amd64 1:2.44-1amd64   
ii  libcom-err2:amd64 1.46.4-1amd64   
ii  libcrypt1:amd64   1:4.4.25-2  amd64   
ii  libdbi-perl:amd64 1.643-3+b1  amd64   
ii  libecap3:amd641.0.1-3.2+b1amd64   
ii  libexpat1:amd64   2.4.1-2+b1  amd64   
ii  libgcc-s1:amd64   11.2.0-7amd64   
ii  libgnutls30:amd64 3.7.2-2 amd64   
ii  libgssapi-krb5-2:amd641.18.3-7amd64   
ii  libldap-2.4-2:amd64   2.4.59+dfsg-1   amd64   
ii  libltdl7:amd642.4.6-15amd64   
ii  libnetfilter-conntrack3:amd64 1.0.8-3 amd64   
ii  libnettle8:amd64  3.7.3-1 amd64   
ii  libpam0g:amd641.4.0-10amd64   
ii  libsasl2-2:amd64  2.1.27+dfsg-2.1 amd64   
ii  libstdc++6:amd64  11.2.0-7amd64   
ii  libsystemd0:amd64 247.9-1 amd64   
ii  libtdb1:amd64 1.3.18-2amd64   
ii  libxml2:amd64 2.9.12+dfsg-5   amd64   
ii  logrotate 3.18.1-2amd64   
ii  lsb-base  11.1.0  all 
ii  netbase   6.3 all 
ii  squid-common  5.1-2   all 
ii  squid-dbgsym  5.1-2   amd64

-- 
 Eugene Berdnikov

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Eugene Berdnikov]

  Hi Samuel.
  
On Tue, Sep 28, 2021 at 08:51:59PM +0100, Samuel Henrique wrote:
> >  To build version dependency automatically script should have access
> >  to the whole history of all versions of libc6, with list of symbols
> >  and markers when each symbol become usable.
> 
> We have that, you can read about it here[0][1][2], if you're interested.

 Thank you for those references, I've got much helpful info from them.

> >  Yes, this issue may occure when libc6 vesion is outdated in normal
> >  upgrade process.
> 
> I would disagree on the definition of a normal upgrade process, one
> would never end up with a combination of incompatible rsync + libc,
> that can only happen if somebody installs a package that is not
> supported by Debian (not from the official repos) and that package
> holds libc back (thus running an unsupported version)[4].

 I had several (at least 2 distinct) live systems with this post-upgrade
 problem. They have backups, but now it too late: now those backups are
 replaced by new ones.

 However, it requires some clarification what is "normal upgrade" process.
 I do not run full-upgrade ("aptitude safe-upgrade" in my taste) if some
 new package it to be installed. I simply check dependences to be sure
 that new package does not bring risk to break functionality of important
 services on production system. The full-upgrade is performed on a schedule,
 once a week or two, and requires additional monitoring of the system's
 behaviour. For example, I have an LXC containter with libc-2.31-17,
 which was not updated at least a month (file libc.so.6 dated 23-Aug).
 Running "apt-get update ; aptitude -R install rsync" I got rsync-3.2.3-8
 without libc6 update. I consider this as a normal situation, because
 I have no obligation to do full-upgrade when I install some package.
 However, this combination (rsync-3.2.3-8 + libc6-2.31-17) is not
 functional: rsync replies "failed to set permissions [...] Function
 not implemented (38)".

> I did try to reproduce the issue on Jessie, with libc 2.28, but I was
> able to run "rsync -va /etc/ld.so.cache /tmp" with no issues.

 Did you try the last rsync binary with libc6-2.28?
 I tried and got an error (see below).

> It might be possible that the issue you're seeing only affects libc
> between 2.28 and 2.31, if that's the case, it will be very tricky for
> me to reproduce since Debian only supports 2.28, 2.31 and 2.32.

 Many versions are saved here: http://snapshot.debian.org/binary/libc6/.

 Using the previously mentioned LXC container and binary packages from
 snapshot.debian.org, I tried rsync-3.2.3-8 with libc 2.31-17, 2.30-4,
 2.29-10, 2.28-10, 2.28-1, 2.27-1, in all cases rsync fails with the same
 "not implemented" error. I did not go below 2.27-1 because it requires
 downgrading of base system packages...

> If you have an affected system at hand, I would kindly ask you to try
> to implement upstream's workaround[5] and see if it makes your issue
> go away.

 I could take me too much time to set up building environment and compile
 from sources... However, I can test binary on my setup, if you provide it
 (for arch:amd64, please). I can provide access to my LXC environment:
 just send me your ssh public key, and I'll create an entry for you.

> Just a small correction, I see you mentioned lchown, but the issue is
> related to lchmod.

 Yes, it should be read "lchown" (lchmod was mentioned by mistake).
-- 
 Eugene Berdnikov

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Eugene Berdnikov]

  Hi Samuel.

On Sat, Sep 25, 2021 at 09:29:42PM +0100, Samuel Henrique wrote:
> >  for lchown() is definitely a new feature, so the right way, IMHO,
> >  is to correct dependences for rsync package: "libc6 (>= 2.31)".
> 
> I don't think it's as simple as that, I understand your issue now, but
> I wouldn't just bump the dependency requirement without understanding
> it better.
> As it stands now, the version requirement is automatically set by
> debhelper, based on the symbols rsync uses.

 Are you sure about version? I doubt. The list of libraries is built
 by debhelper, I agree. But the *version* dependency, IMHO, can't be built
 on the list of referenced symbols.

 To build version dependency automatically script should have access
 to the whole history of all versions of libc6, with list of symbols
 and markers when each symbol become usable. Note that presense of
 symbol is not mean usability: for libc6-2.30 entry "lchown()" is
 definitely present (ltrace confirms it), but attemptp to call it
 return an error "not implemented", i.e. this version contains only
 stub code (symbol is reserved for future use).

 I belive the version dependency have to be filled manually. Moreover,
 with manual assignment buggy versions of library can be excluded,
 which is very unlikely to be done automatically.

> The bug we are facing comes from libc6, as we can see in the upstream
> bug report, and rsync is trying to workaround that issue (the patch I
> introduced on 3.2.3-7).

 I did not look through the code, but probably it detects presence of
 lchown() but don't cover the situation when this entry is not functional.

> Having outdated packages is not a problem, but having only a subset of
> them is an indicator of something wrong. Rsync 3.2.3-7 migrated to
> testing after libc6 2.32, so this issue will not happen unless the
> person purposely holds libc back. I thought your system was running
> like that by accident.
> I'm not judging here, I just meant to explain that the trigger to the
> issue will not affect every Debian user.

 Yes, this issue may occure when libc6 vesion is outdated in normal
 upgrade process.

> Being able to keep the current version requirement will be important
> in the long term as I want to be able to upload new releases to
> backports. I also think that there's a chance rsync's upstream solves
> the new regression soon (if confirmed), which would deem the version
> bump unneeded.
> 
> What do you think?

 OK, I expressed my thoughts, technical problem is clear, so
 it's left for you and upstream to find the best and right solution.
 Thank you for support, Samuel.
-- 
 Eugene Berdnikov

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Eugene Berdnikov]

  Hi Samuel.
  
On Sat, Sep 25, 2021 at 03:08:47PM +0100, Samuel Henrique wrote:
> 1) Do you know how is it possible that you were running Debian testing
> with libc6 2.30-4? Even Debian stable has a newer version, I believe
> you could have missed running apt full-upgrade at some point.

 I have several hosts with old kernels (like 4.17) and their headers,
 and gcc-7, which are tied to libc6-2.30 by their dependences.
 On "aptitude install libc6" first resolver's proposal was to remove
 these packages. I agreed with this choice to install libc6-2.32.

 I have a copy of one such system on backup, it may be studied for
 more details if need... However, it looks pointless, because support
 for lchown() is definitely a new feature, so the right way, IMHO,
 is to correct dependences for rsync package: "libc6 (>= 2.31)".

> 2) Is your system under a chroot and/or without /proc mounted?

 No, fault happens with physical hosts (not VMs or containers),
 where /proc is mounted. However, they are all running SysV init.

> > Upgrade libc6 to 2.32-4 solves the problem.
> That's the current version available in testing and unstable, so
> anybody running those will be fine.

 Right. I also have some similar hosts with libc-2.32, probably they were
 upgraded to last version due to absence of old kernels, old gcc, etc.
 Rsync runs fine on them.

> If anything, 3.2.3-7 is fixing the very same issue you reported, which
> should have been happening in rsync 3.2.3 + libc6 2.32 (but you
> mention you had an older libc6).
> 
> Overall I believe there might be something wrong in your system,
> related to libc6.

 Every system with periodic updates might have outdated packages,
 generally it's not a problem (and should not be a problem) if binary API
 is compatible and all package dependences are correct.
-- 
 Eugene Berdnikov

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Eugene Berdnikov]

Package: rsync
Version: 3.2.3-7
Severity: important

 Hello. After last update of Debian/testing (bookworm/sid) with rsync 3.2.3-4
 to rsync-3.2.3-7, new version can't change file attributes. Example:

# rsync -va /etc/ld.so.cache /tmp
sending incremental file list
ld.so.cache
rsync: [receiver] failed to set permissions on "/tmp/.ld.so.cache.hvkXg2": 
Function not implemented (38)

 Proper permissions for file are not set.
 Rsync 3.2.3-4 on the same system works good.

 Ltrace for rsync-3.2.3-7 shows call to non-implemented function "lchmod":

[pid 5535] __lxstat(1, ".ld.so.cache.Hhy5UI", 0x7ffe8558e790 
[pid 5535] SYS_lstat(".ld.so.cache.Hhy5UI", 0x7ffe8558e790)  = 0
[pid 5535] <... __lxstat resumed> )  = 0
[pid 5535] utimensat(0xff9c, 0x7ffe85590a00, 0x7ffe8558e700, 256 

[pid 5535] SYS_utimensat(0xff9c, 0x7ffe85590a00, 0x7ffe8558e700, 256) = 0
[pid 5535] <... utimensat resumed> ) = 0
[pid 5535] lchmod(0x7ffe85590a00, 420, 0x7ffe8558e700, 0)= 
0x
___^^___
[pid 5535] __errno_location()= 
0x7fc937826480
[pid 5535] __asprintf_chk(0x55c1a1db93d8, 1, 0x55c1a1d8e0cf, 0x55c1a1db8360) = 
29
[pid 5535] __errno_location()= 
0x7fc937826480
[pid 5535] __snprintf_chk(0x7ffe8558d270, 5120, 1, 5120) = 18
[pid 5535] __vsnprintf_chk(0x7ffe8558d282, 5102, 1, -1)  = 58
[pid 5535] strerror(38)  = 
"Function not implemented"
[pid 5535] __snprintf_chk(0x7ffe8558d2bc, 5044, 1, -1)   = 32
[pid 5535] memcpy(0x55c1a3b57924, "rsync: [receiver] failed to set permissions 
on "/rz/etc/.ld.so.cache.Hhy5UI": Function not implemented (38)\n", 108) = 
0x55c1a3b57924

 List of packages for rsync-3.2.3-7 on broken system are:

||/ Name Version Architecture Description
+++--===--===
ii  libacl1:amd642.3.1-1 amd64access control list - shared 
library
ii  libc6:amd64  2.30-4  amd64GNU C Library: Shared 
libraries
ii  liblz4-1:amd64   1.9.3-2 amd64Fast LZ compression algorithm 
library - runtime
ii  libpopt0:amd64   1.18-3  amd64lib for parsing cmdline 
parameters
ii  libssl1.1:amd64  1.1.1l-1amd64Secure Sockets Layer toolkit 
- shared libraries
ii  libxxhash0:amd64 0.8.0-2 amd64shared library for xxhash
ii  libzstd1:amd64   1.4.8+dfsg-2.1  amd64fast lossless compression 
algorithm
ii  lsb-base 11.1.0  all  Linux Standard Base init 
script functionality
ii  zlib1g:amd64 1:1.2.11.dfsg-2 amd64compression library - runtime

 Upgrade libc6 to 2.32-4 solves the problem.

 I suspect that lchmod() function appears in libc6-2.31 (or in some other
 library), but dependency list for rsync mentions "libc6 (>= 2.15)". 
 Probably it should be corrected.
-- 
 Eugene Berdnikov

Bug#991948: RFP: virtualbox-completion -- Bash completion support for VirtualBox management utility

[Eugene Kilachkoff]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: ekilachk...@gmail.com

* Package name: virtualbox-completion
  Version : 6.1.22
  Upstream Author : Roman Dobosz 
* URL : https://github.com/gryf/vboxmanage-bash-completion
* License : BSD-3-Clause
  Programming Lang: bash
  Description : Bash completion support for VirtualBox management utility

Bash completion support for VirtualBox's VBoxManage CLI.

Would be nice if this could be suggested by virtualbox packages.
VBoxManage is a ton of switches and commands (some of them are
not even in GUI) that are difficult to remember, so this is
indispensable for advanced usage.

Technically this tool supports only VBoxManage. I'm proposing
a virtualbox-completion name so it is easier to find.

Bug#980305: RFA: libcddb2

[Eugene V. Lyubimkin]

Hello Nick,

This comes extremely late, my apologies. However:

Nick Gasson kirjoitti 27.2.2021 klo 8.22:
> I'm not maintaining a dependent package but I'd like to help Debian
> more. I took a look at the two open bugs and I think they can be fixed
> quite easily with the patches I attached. Let me know if you're happy
> for me to adopt it.

You don't need my permission to adopt it. When you find an uploading
Debian Member who could guide and upload the package for you, you're
welcome to update the package with your patches and other potential
changes.

-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#985226: Outdated information in Debian's copyright file for the strace package

[Eugene Syromiatnikov]

Package: strace
Version: 4.26-0.2
Severity: normal

Debian's copyright file for the strace package is significantly outdated:
 * The upstream sources are no longer available at [1], but rather
   at [2] or [3], as pointed from the project page [4] and in the README
   files[5][6].  See also [7][8].
 * The copyrightship (as outlined in COPYING[9]) after the year 2001
   has been replaced with a wildcard "Copyright (c) 2001-20xx The strace
   developers." line, with the list of developers provided in the distributed
   CREDITS[10] file and the last copyright year corresponding to the year
   of the packaged strace release.
 * The license has been changed from BSD to LGPL-2.1-or-later for the main code
   and GPL-2.0-or-later for the test suite [11].

These issues are not present in the upstream debian/copyright[12].

The aforementioned also holds for the latest strace package version, 5.10-1.

[1] http://sourceforge.net/projects/strace/
[2] https://gitlab.com/strace/strace
[3] https://github.com/strace/strace
[4] https://strace.io/
[5] https://gitlab.com/strace/strace/-/blob/master/README.md
[6] https://fossies.org/linux/strace/README
[7] https://gitlab.com/strace/strace/-/commit/51d40516df
[8] https://gitlab.com/strace/strace/-/commit/003c02745f
[9] https://gitlab.com/strace/strace/-/blob/master/COPYING
[10] https://fossies.org/linux/strace/CREDITS
[11] https://gitlab.com/strace/strace/-/commit/b93d52fe3d
[12] https://gitlab.com/strace/strace/-/blob/master/debian/copyright

Bug#979267: Stop using deprecated systemd-resolve tool

[Eugene Zhukov]

On Wed, Jan 20, 2021 at 9:00 PM Michael Biebl  wrote:
>
> Hi Eugene
>
> Am 20.01.21 um 18:08 schrieb Eugene Zhukov:
>  > Please NMU.
>
> Done. Should I push my changes directly to git?
>
Please do. Thank you for working on this!

Eugene

Bug#979267: Stop using deprecated systemd-resolve tool

[Eugene Zhukov]

On Wed, Jan 20, 2021, 18:48 Michael Biebl  wrote:

> Hi
>
> On Mon, 04 Jan 2021 19:27:59 +0100 Michael Biebl  wrote:
> > systemd-resolve is nowadays merely a symlink pointing at resolvectl and
> > we'd like to get rid of this compat symlink at some point.
>
> ..
>
> > Attached is a patch which uses resolvectl instead.
> > Please review and consider applying it in your next upload.
> > It would be great if you can make this upload before the bullseye
> > release, so we can safely drop the symlink in bullseye+1.
>
>
> Just wanted to ask, if you already had time to look at the patch?
> I can offer to NMU if you are busy otherwise. Let me know what you
> prefer.
>

Please NMU.

Thank you,
Eugene

>

Bug#980305: RFA: libcddb2

[Eugene V. Lyubimkin]

Package: wnpp
Severity: normal

Hello,

The libcddb package needs a new maintainer. I no longer have time nor 
interest to maintain it properly.

I had adopted it many years as a dependency of a package I no longer
maintain. It was very low-maintenance until recently; there are now two
outstanding bug reports which require attention [1].

If you maintain one of Debian packages that depend on libcddb (Cc:d),
you might be interested in adopting it.


[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libcddb

Bug#979710: xfonts-bolkhov-75dpi: Missing Cyrillic letter 'u'

[Eugene Berdnikov]

 Hello.
 
 I confirm the existance of this bug in 1.1.20001007-8.1,
 in particular for xfonts-bolkhov-misc package.
 Rollback to 1.1.20001007-8 fixes the issue.
-- 
 Eugene Berdnikov

Bug#973397: Ensure /etc/rsyncd.conf is copied into the package. Allow "systemctl start rsync" to run

[Eugene Losowski-Gallagher]

Package: rsync
Version: 3.1.3-6
Severity: wishlist
Tags: newcomer

{code:diff}
diff --git a/debian/rules-pre-dh b/debian/rules-pre-dh
index 01db177..b8ef76f 100755
--- a/debian/rules-pre-dh
+++ b/debian/rules-pre-dh
@@ -108,6 +108,7 @@ endif
$(INSTALL_SCRIPT) debian/postrm   debian/tmp/DEBIAN/
$(INSTALL_FILE) debian/buildtree/packaging/systemd/rsync.service
debian/tmp/lib/systemd/system/
$(INSTALL_FILE) debian/default  debian/tmp/etc/default/rsync
+   $(INSTALL_FILE) debian/rsyncd.conf  debian/tmp/etc/rsyncd.conf
$(INSTALL_SCRIPT) debian/init.d debian/tmp/etc/init.d/rsync
$(INSTALL_FILE) debian/lintian.overrides
debian/tmp/usr/share/lintian/overrides/rsync
(cd debian/tmp; find ./etc -type f | LC_ALL=C sort | sed s,.,,) >
debian/tmp/DEBIAN/conffiles
{code}



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

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

Versions of packages rsync depends on:
ii  base-files   10.3+deb10u6
ii  init-system-helpers  1.56+nmu1
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libpopt0 1.16-12
ii  lsb-base 10.2019051400

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.9p1-10+deb10u2
ii  openssh-server  1:7.9p1-10+deb10u2

-- no debconf information

Bug#972869: RFA: fmtlib

[Eugene V. Lyubimkin]

Package: wnpp
Severity: normal

Hello,

This package needs a more responsive maintainer. I unfortunately haven't
had enough time for months and this is unlikely to change in the near
future.

fmtlib is a modern C++ library, it provides fast and type-safe
replacement of (s)printf and related machinery.

What needs to be done:
 - package a new upstream release;
 - solve a (documentation-related) FTBFS;
 - potentially make a shared library instead of a static library.


Regards,
-- 
Eugene V. Lyubimkin
C++ GNU/Linux userspace developer, Debian Developer

Bug#966509: geeqie: can not start due to clutter-gtk init failure

[Eugene Berdnikov]

Package: geeqie
Version: 1:1.5.1+git20200723-2
Severity: important

Dear Maintainers,


% geeqie

(geeqie:28868): Clutter-CRITICAL **: 19:45:09.437: Unable to initialize 
Clutter: Unable to initialize the Clutter backend: no available drivers found.
Can't initialize clutter-gtk.


Problem was found after upgrade from 1.5.1-11:

2020-07-29 17:13:18 upgrade geeqie:amd64 1:1.5.1-11 1:1.5.1+git20200723-2
2020-07-29 17:13:19 upgrade geeqie-common:all 1:1.5.1-11 1:1.5.1+git20200723-2

In ~/.config/geeqie/geeqierc.xml clutter is turned OFF:
image.use_clutter_renderer = "false" 


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages geeqie depends on:
ii  geeqie-common1:1.5.1+git20200723-2
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-1
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-1
ii  libdjvulibre21   3.5.27.1-15
ii  libexiv2-27  0.27.2-8
ii  libffmpegthumbnailer4v5  1:2.2.2-dmo1
ii  libgcc-s110.1.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.20-1
ii  libheif1 1.6.1-1+b1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4+b1
ii  liblirc-client0  0.10.1-6.2
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpoppler-glib8 0.71.0-6
ii  libstdc++6   10.1.0-1
ii  libtiff5 4.1.0+git191117-2
ii  libwebp6 0.6.1-2+b1
ii  libx11-6 2:1.6.9-2+b1
ii  sensible-utils   0.0.12+nmu1

Versions of packages geeqie recommends:
pn  cups-bsd | lpr   
pn  exiftran 
pn  exiv2
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  librsvg2-common  2.48.7-1
pn  ufraw-batch  
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg 
pn  gimp   
pn  libjpeg-progs  
pn  ufraw  
ii  xpaint 2.9.1.4-3.2+b1

-- no debconf information

-- 
 Eugene Berdnikov

Bug#948706: Polite ping

[Eugene Berdnikov]

 Hi.
 
On Wed, Jun 03, 2020 at 02:01:33PM +0200, Benedikt Spranger wrote:
> Hi,
> 
> are there any updates or is more help needed?

 Unfortunately, this package seems to be not maintained.
-- 
 Eugene Berdnikov

Bug#240945: strace: Patch to add minimum / maximum time spent in syscall

[Eugene Syromiatnikov]

Control: tags -1 +fixed-upstream

The issue has been fixed in commit 609df3bad702 "count: add information about
minimum and maximum call duration", to be included in the next strace release
(version 5.6).

Bug#603187: "PANIC: attached pid $SOMEPID exited with 0" from strace -f of Haskell program compiled with ghc -threaded

[Eugene Syromiatnikov]

Control: tags -1 +fixed-upstream

This is probably fixed by commit 19cdada5b499 (present since strace 4.7)
that removed the offending code.  It is not reproduced both with strace
4.21 and the current upstream version.

Bug#528488: Should open output file with O_APPEND

[Eugene Syromiatnikov]

Control: tags -1 +upstream

This has been fixed in strace 4.22 by addition of the -A option
(commit be55c1c61aec).

Bug#436284: strace: -e write=fd doesn't dump data after error return

[Eugene Syromiatnikov]

Control: tags -1 +upstream

This has been fixed in strace 4.22 (commit bed7622d4980).

Bug#466195: strace: Please support -r and -t simultaneously

[Eugene Syromiatnikov]

Control: tags -1 +upstream

Bug#466195: strace: Please support -r and -t simultaneously

[Eugene Syromiatnikov]

Control: -1 +upstream

This is fixed in strace 4.22 (commit 698e9c30d4f3).

Bug#952625: libixion: FTBFS: configure: error: Package requirements (spdlog >= 0.16.0) were not met

[Eugene V. Lyubimkin]

Hi,

Rene Engelhard kirjoitti 26.2.2020 klo 18.49:
[...]
>> libfmt-dev does not have a .pc file. Thus this isn't resolvable.
>>
>> root@frodo:/# pkg-config --cflags fmt
>> Package fmt was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `fmt.pc'
>> to the PKG_CONFIG_PATH environment variable
>> No package 'fmt' found
>>
>> -> bug in spdlog
> 
> Commenting out the above line of course works.
> 
> It seems to me that libfmt-dev is header-only or static? (-dev doesn't
> depend on a fmt shared library). So that means that it could safely be
> removed for the header-only usecase.

It is correct that as of moment libfmt-dev provides a static library only, due 
to
a small library size plus still somewhat frequent API changes.

[...]
> Or fmt gets a .pc file (Cced.)

Thanks for the message. Upstream started to provide .pc-file in relatively 
recent versions.
With libfmt-dev from experimental (and soon in unstable), "pkg-config --cflags 
fmt" works.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#950856: fmtlib: Please upload source package to salsa.debian.org and set Vcs-*

[Eugene V. Lyubimkin]

Hello,

Michael R. Crusoe kirjoitti 7.2.2020 klo 14.33:
> Hello, please upload source package to salsa.debian.org and set Vcs-*; thanks

I currently don't have plans to upload packaging to some particular location.

Any particular reason the packaging location is important for you?


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#950857: fmtlib: Please upload a package for version 6.1.2

[Eugene V. Lyubimkin]

Hello,

Michael R. Crusoe kirjoitti 7.2.2020 klo 14.35:
> spdlog is currently using an embedded copy of version 6+, so if fmtlib
> is updated we can use the packaged version instead

Thank you for the heads-up. This is now work-in-progress.


-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#951208: fuse3's backwards compatibilty (Re: Bug#951208: Impossible to mount over nonempty directories)

[Eugene V. Lyubimkin]

Hello,

Martin Pärtel kirjoitti 17.2.2020 klo 10.49:
> I'm unfortunately unlikely to have time to port bindfs to FUSE 3 in the near 
> future :(
> 
> The easiest distro-level workaround in terms of "least code required" would 
> probably be to patch fuse3's fusermount to
> allow and ignore `nonempty` (and maybe print a deprecation warning). Or some 
> hacks could probably be invented to direct
> FUSE 2 filesystems to use FUSE 2 helpers. It's up to the Debian maintainers 
> whether they want the maintenance burder of
> either of these workarounds.

CC'ing FUSE's maintainer for extra input if any.


>From the discussion above I gather that bindfs is still (with limitations) 
>usable with fuse3. If true, then I wouldn't
like to block users of fuse3 from using bindfs via strict Depends. I could add 
Suggests or Recommends on fuse2,
though.

How common of a use case is to use bindfs with a non-empty mount point? I never 
mounted filesystems like that myself, so
I don't know if it's a minor nuisance with an easy workaround, or a significant 
limitation making some use case
unachievable.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#951474: libfmt-dev: spdlog try to load fmt v5 function()

[Eugene V. Lyubimkin]

Control: tags -1 + moreinfo

Hello,

Christian Marillat kirjoitti 17.2.2020 klo 8.45:
> Note : This bug is for armel, armhf, arm64 and powerpc arches.
> 
> As said in bug #950857 spdlog is build using an embedded copy of version 6+
> and thus fail to load include from version 5.
>
> [...]

I'd need more details to reproduce and understand the problem, particularly 
whether
packaged libfmt v5 is a root case or not.

I can see the from lines that there is a linking problem in the package 
'gerbera`,
but I do not see where these logs are coming from. The unstable version of the 
package builds
cleanly for me - are you trying to build an unreleased version? If yes, which 
exact sources?
Do you have links to build logs?


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#947850: Backport fmtlib 5.3 to buster-backports

[Eugene V. Lyubimkin]

Hello,

Jonas Meurer kirjoitti 31.12.2019 klo 18.04:
> thanks for maintaining fmtlib in Debian. In order to bring waybar to
> buster-backports, I'd like to upload a backport of fmtlib to buster-backports
> as well. Would you like to take care of this yourself or are you fine with me
> doing the backport?

Thank you for the interest. I'd be okay with you doing the backport, as long
as no dramatic changes are planned to what package provides. I guess you'd be
mainly interested in a re-build so 'libstdc++6'-dependency are satisfiable in 
stable?


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#941886: crashes with segfault while scanning library

[Eugene V. Lyubimkin]

Hello Antoine,

Antoine Beaupre kirjoitti 7.10.2019 klo 6.02:
> After starting fbreader (which takes 30 seconds), I go to the library
> and hit settings. There I configure my ebook library (~/books), click
> the "Look for books in subdirectories" button, and hit "OK".
> 
> After a little scanning, it totally crashes with the following backtrace:

Thank you for the detailed report. Unfortunately, the upstream development
has stopped many years ago, and it's unlikely for problems to become fixed
unless somebody steps up.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#942068: openvpn-systemd-resolved: missing script for update-systemd-resolved

[Eugene Zhukov]

On Thu, Oct 10, 2019 at 9:16 PM Johan Smits  wrote:
>
> Yes this solved my warnings. Should this be done by the package? Just
> from a upgrade perspective for other users.
Great!
Well, it's not really an option to remove a conffile (previously
installed into /etc) on package upgrade. Some user might have actually
taken it into use.

Bug#942068: openvpn-systemd-resolved: missing script for update-systemd-resolved

[Eugene Zhukov]

On Thu, Oct 10, 2019 at 8:40 PM Johan Smits  wrote:
>
> Hi Eugene,
>
> Thanks for the quick reply.
>
> I imported a ovpn file but not to my knowledge I configured the path.
> Also when I look in the network manager of the VPN tools I can't find
> anything related to this.
>
> But when I look at the file: /etc/openvpn/update-systemd-resolved.conf
> That was installed by package openvpn-systemd-resolved it contains the
> script path.
>
> Here is the output of the file that was installed:
>
> #/etc/openvpn/update-systemd-resolved.conf:
> script-security 2
> setenv PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> up /etc/openvpn/scripts/update-systemd-resolved
> up-restart
> down /etc/openvpn/scripts/update-systemd-resolved
> down-pre
>
> Is this a package error or a configuration error of the file?
>

I see. I think the problem comes from the package.
The previous version of the package (1.3.0-2) indeed installed
/etc/openvpn/update-systemd-resolved.conf, but now this conffile is
installed into /usr/share/doc/openvpn-systemd-resolved/ just for
reference. It should be safe to remove
/etc/openvpn/update-systemd-resolved.conf for you to get rid of
journal log errors.

Eugene

Bug#942068: openvpn-systemd-resolved: missing script for update-systemd-resolved

[Eugene Zhukov]

Thank you for the bug report, Johan.

Could there be something with the configuration on your side?
update-systemd-resolved is installed under /etc/openvpn not /etc/openvpn/scripts

Thanks,
Eugene

Bug#931444: fixed in ncdu 1.14.1-1

[Eugene V. Lyubimkin]

Hi,

Paul Wise kirjoitti 8.9.2019 klo 11.34:
> On Sun, 2019-09-08 at 08:41 +0000, Eugene V. Lyubimkin wrote:
> 
>>* debian/patches:
>>  - 0001-Increase-space-for-item-count-in-loading-screen: added
>>(cherry-picked from upstream). (Closes: #931444)
> 
> This just increases the size of the hardcoded space available so I
> don't think it is the correct fix, since a larger item count will just
> overflow the space again. It would be best to dynamically allocate it
> based on the size of the item count/etc.

Yes, the upstream went for a quick fix here. There are other places, too [1],
where it would be beneficial to use runtime-determined sizes instead of
the fixed-width approach, but the upstream hasn't gone into that direction
so far.

I've marked the bug resolved, as the immediate problem reported is fixed. Plus,
there is a natural limit of how many files one can have before ncdu stops to be
usable, so in this particular case the maximum width approach sounds okay [2].

Feel free to re-open this bug, if you're willing to convince upstream otherwise.

[1] https://code.blicky.net/yorhel/ncdu/issues/37
[2] even though I'd myself allow 2-3 more digits than today.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#939290: missing dependency on newer libstdc++ (Re: Bug#939290: libfmt-dev)

[Eugene V. Lyubimkin]

Hi,

Martin Michlmayr kirjoitti 2.9.2019 klo 22.53:
> Package: libfmt-dev
> Version: 5.3.0+ds-1
[...]
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libfmt.a(format.cc.o): in function 
> `fmt::v5::system_error::init(int, fmt::v5::basic_string_view, 
> fmt::v5::format_args)':
> (.text+0xd52): undefined reference to 
> `std::runtime_error::operator=(std::runtime_error&&)'
> collect2: error: ld returned 1 exit status
> 
> Any idea what this is about?

Yes, thank you for the report. It seems the latest build in unstable picked up 
some symbols
from libstdc++ which are not satisfied in stable. Quick work-around: install 
libstdc++6 from
Debian testing.

This bug will be fixed by listing the missing package dependency.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#934155: lxc: unprivileged lxc container with veth does not start since update to 1:3.1.0+really3.0.4-1 amd64

[Eugene Berdnikov]

 I can't start even a priveleged container (under root).
 
 Kernel: 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux

 Problem was solved by downgrade to lxc/liblxc1 1:3.1.0+really3.0.3-8.
 Example of debug log in attachement.
-- 
 Eugene Berdnikov
lxc-start ipsec6 20190818184124.772 INFO lxccontainer - 
lxccontainer.c:do_lxcapi_start:971 - Set process title to [lxc monitor] 
/var/lib/lxc ipsec6
lxc-start ipsec6 20190818184124.773 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM 
security driver AppArmor
lxc-start ipsec6 20190818184124.773 DEBUGterminal - 
terminal.c:lxc_terminal_peer_default:676 - No such device - The process does 
not have a controlling terminal
lxc-start ipsec6 20190818184124.774 INFO start - start.c:lxc_init:926 - 
Container "ipsec6" is initialized
lxc-start ipsec6 20190818184124.774 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_filter_and_set_cpus:495 - No isolated or offline 
cpus present in cpuset
lxc-start ipsec6 20190818184124.774 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_handle_cpuset_hierarchy:612 - 
"cgroup.clone_children" was already set to "1"
lxc-start ipsec6 20190818184124.774 ERRORcgfsng - 
cgroups/cgfsng.c:mkdir_eexist_on_last:1277 - File exists - Failed to create 
directory "/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6"
lxc-start ipsec6 20190818184124.774 ERRORcgfsng - 
cgroups/cgfsng.c:monitor_create_path_for_hierarchy:1298 - Failed to create 
cgroup "/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6"
lxc-start ipsec6 20190818184124.774 ERRORcgfsng - 
cgroups/cgfsng.c:cgfsng_monitor_create:1388 - Failed to create cgroup 
"/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6"
lxc-start ipsec6 20190818184124.774 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_filter_and_set_cpus:495 - No isolated or offline 
cpus present in cpuset
lxc-start ipsec6 20190818184124.774 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_handle_cpuset_hierarchy:612 - 
"cgroup.clone_children" was already set to "1"
lxc-start ipsec6 20190818184124.774 ERRORcgfsng - 
cgroups/cgfsng.c:mkdir_eexist_on_last:1277 - File exists - Failed to create 
directory "/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6-1"
lxc-start ipsec6 20190818184124.774 ERRORcgfsng - 
cgroups/cgfsng.c:monitor_create_path_for_hierarchy:1298 - Failed to create 
cgroup "/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6-1"
lxc-start ipsec6 20190818184124.775 ERRORcgfsng - 
cgroups/cgfsng.c:cgfsng_monitor_create:1388 - Failed to create cgroup 
"/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6-1"
lxc-start ipsec6 20190818184124.775 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_filter_and_set_cpus:495 - No isolated or offline 
cpus present in cpuset
lxc-start ipsec6 20190818184124.775 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_handle_cpuset_hierarchy:612 - 
"cgroup.clone_children" was already set to "1"
lxc-start ipsec6 20190818184124.775 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_monitor_create:1403 - The monitor process uses 
"lxc.monitor/ipsec6-2" as cgroup
lxc-start ipsec6 20190818184124.775 ERRORcgfsng - 
cgroups/cgfsng.c:__do_cgroup_enter:1498 - No space left on device - Failed to 
enter cgroup "/sys/fs/cgroup/cpuset//lxc.monitor/ipsec6-2/cgroup.procs"
lxc-start ipsec6 20190818184124.775 ERRORstart - start.c:__lxc_start:2004 - 
Failed to enter monitor cgroup
lxc-start ipsec6 20190818184124.775 DEBUGlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:839 - First child 918 exited
lxc-start ipsec6 20190818184124.775 ERRORlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:851 - Received container state 
"STOPPING" instead of "RUNNING"
lxc-start ipsec6 20190818184124.776 ERRORlxc_start - 
tools/lxc_start.c:main:329 - The container failed to start
lxc-start ipsec6 20190818184124.776 ERRORlxc_start - 
tools/lxc_start.c:main:332 - To get more details, run the container in 
foreground mode
lxc-start ipsec6 20190818184124.776 ERRORlxc_start - 
tools/lxc_start.c:main:335 - Additional information can be obtained by setting 
the --logfile and --logpriority options
lxc-start ipsec6 20190818184124.776 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_filter_and_set_cpus:495 - No isolated or offline 
cpus present in cpuset
lxc-start ipsec6 20190818184124.776 DEBUGcgfsng - 
cgroups/cgfsng.c:cg_legacy_handle_cpuset_hierarchy:612 - 
"cgroup.clone_children" was already set to "1"
lxc-start ipsec6 20190818184124.776 WARN cgfsng - 
cgroups/cgfsng.c:cgfsng_monitor_destroy:1178 - No space left on device - Failed 
to move monitor 919 to "/sys/fs/cgroup/cpuset//lxc.pivot/cgroup.procs"

Bug#931444: ncdu: progress dialog: for dirs with many files, total items can almost overlap size

[Eugene V. Lyubimkin]

Control: forwarded -1 https://code.blicky.net/yorhel/ncdu/issues/135


Hello Paul,

Paul Wise kirjoitti 5.7.2019 klo 8.32:
> For directories that have many subdirectories and many files, in the
> ncdu progress dialog the total items count can encroach on and almost
> overlap the total size count:
> 
>Total items: 20161797size: 123.4 GiB
> 
> [...]

Thank you for the report, it's now forwarded upstream.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#930312: python-docker: Please package a more recent version e.g. 3.6.0

[Eugene Zhukov]

Package: python-docker
Version: 3.4.1-4
Severity: wishlist

Dear Maintainer,

Thank you for working on python-docker!
Could you please package a more recent version of it?

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

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

Versions of packages python-docker depends on:
ii  python   2.7.16-1
ii  python-backports.ssl-match-hostname  3.5.0.1-1
ii  python-dockerpycreds 0.3.0-1
ii  python-ipaddress 1.0.17-1
ii  python-requests  2.21.0-1
ii  python-six   1.12.0-1
ii  python-websocket 0.53.0-1

python-docker recommends no packages.

python-docker suggests no packages.

-- no debconf information

Bug#929162: randtype FTCBFS: does not pass cross tools to make

[Eugene V. Lyubimkin]

Hello Helmut,

Helmut Grohne kirjoitti 18.5.2019 klo 14.11:
> randtype fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes randtype cross buildable. Please consider applying the attached
> patch.

Thank you for the patch, it looks good. I'll apply it in the next upload,
likely post-freeze.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#921312: libsaxonhe-java: description says XSLT 3.0 is unsupported but upstream websites disagree

[Eugene Zhukov]

Hi Paul,

Thanks for the bug report. Have you actually tried if XSLT 3.0 is supported by
libsaxonhe-java and it's just package description that needs updating?

Eugene


signature.asc
Description: PGP signature

Bug#920554: unixodbc-bin: Binaries listed in description don't match binaries provided

[F. Eugene Aumson]

Package: unixodbc-bin
Version: 2.3.0-4+b1
Severity: important

Dear Maintainer,

First of all, THANK YOU, for maintaining this package!

Now, the problem:

The package description lists three binaries that are to be included with the
package, ODBCConfig, DataManager, and odbctest.  However, none of these
binaries are actually included.

Also, the package does provide binaries ODBCCreateDataSourceQ4, and
ODBCManageDataSourcesQ4.  However, these are not mentioned in the package
description.

Please provide the ODBCConfig, DataManager and odbctest binaries in this
package; and, please update the description to indicate that the package also
provides ODBCCreateDataSourceQ4 and ODBCManageDataSourcesQ4.

Thanks again!
Gene



-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages unixodbc-bin depends on:
ii  libc6  2.24-11+deb9u3
ii  libgcc11:6.3.0-18+deb9u1
ii  libodbc1   2.3.4-1
ii  libodbcinstq4-12.3.0-4+b1
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqtassistantclient4  4.6.3-7+b1
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libstdc++6 6.3.0-18+deb9u1
ii  odbcinst1debian2   2.3.4-1

unixodbc-bin recommends no packages.

unixodbc-bin suggests no packages.

-- no debconf information

Bug#913754: syslog-ng hangs in getrandom(2) on boot

[Eugene Berdnikov]

  Hi, Péter.
  
On Thu, Nov 15, 2018 at 08:33:13AM +0100, Kókai Péter wrote:
>Hello,
>Which was the previous syslog-ng version ?

 The version 3.13.2-5 was installed 25 Oct, and according to boot logs
 previous version was free from this bug. As far as I understand
 contents of /var/log/dpkg.log, those lines

 2018-10-25 13:06:19 status half-installed syslog-ng:all 3.13.2-4.1
 2018-10-25 13:06:20 status unpacked syslog-ng:all 3.13.2-5

 mean that version 3.13.2-4.1 was upgraded to 3.13.2-5.
 
>--
>Kokan
>On Wed, 14 Nov 2018 at 21:21 Eugene Berdnikov <[1]b...@protva.ru> wrote:
> 
>  Package: syslog-ng
>  Version: 3.13.2-5
>  Severity: minor
> 
>   On boot start of syslog-ng as daemon from /etc/init.d (SysV-init)
>   leads to hangup of boot process for several minutes. Strace shows
>   that delay caused by getrandom(2) syscall:
> 
>  1501 22:44:00
>  
> getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
>  32, 0) = 32 <322.583360>
> 
>   Got with "strace -Tt", means reading of 32 random bytes tooks 322
>  seconds.
>   This is expectable: on boot system has no enоuph entropy, so this
>  syscall
>   blocks until entropy is collected by kernel from device drivers.
> 
>   Previous versions of syslog-ng do not hang.
>  --
>   Eugene Berdnikov
> 
> References
> 
>Visible links
>1. mailto:b...@protva.ru

-- 
 Eugene Berdnikov

Bug#913754: syslog-ng hangs in getrandom(2) on boot

[Eugene Berdnikov]

Package: syslog-ng
Version: 3.13.2-5
Severity: minor

 On boot start of syslog-ng as daemon from /etc/init.d (SysV-init)
 leads to hangup of boot process for several minutes. Strace shows
 that delay caused by getrandom(2) syscall:
 
1501 22:44:00 
getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
 32, 0) = 32 <322.583360>

 Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
 This is expectable: on boot system has no enоuph entropy, so this syscall
 blocks until entropy is collected by kernel from device drivers.
 
 Previous versions of syslog-ng do not hang.
-- 
 Eugene Berdnikov

Bug#911412: bash: Occasional SIGSEGV when using completion

[Eugene Kilachkoff]

Package: bash
Version: 4.4-5
Severity: normal

Dear maintainers,

I'm experiencing segmentation faults in bash. This only happens when I try to 
use completion, but not every time. That is, completion works most of the time 
but in one of the 1000 attempts (maybe more) it crashes. I do not have a 
reliable way of reproducing, however there are certain conditions that increase 
the chances of crashing:

1) A session must be running long enough, typically days. Tens if not hundreds 
of commands are entered.
2) A crash more often happens in deeply nested directories with long names.
3) I have a fairly elaborate .bashrc with lots of helper functions, git-prompt, 
etc, etc.

I'm attaching a backtrace. To me it looks like some kind of corrupted heap.

Thoughts?

-- System Information:
Debian Release: 9.5
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-updates'), (500, 'stable-debug'), (500, 'stable'), (50, 'testing'), 
(49, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bash depends on:
ii  base-files   9.9+deb9u5
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u3
ii  libtinfo56.0+20161126-1+deb9u2

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
ii  bash-doc  4.4-5

-- no debconf information
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 /bin/bash...Reading symbols from 
/usr/lib/debug/.build-id/4b/e0cc32aba02ec4e0f010047be5ae9dee756960.debug...done.
done.
[New LWP 32629]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `bash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  internal_free (mem=0x1d3d018, file=0x4cc198 ".././dispose_cmd.c", line=249, 
flags=) at ../../.././lib/malloc/malloc.c:863
863 ../../.././lib/malloc/malloc.c: No such file or directory.
#0  internal_free (mem=0x1d3d018, file=0x4cc198 ".././dispose_cmd.c", line=249, 
flags=) at ../../.././lib/malloc/malloc.c:863
#1  0x00435bcd in dispose_word (w=0x1cdce68) at .././dispose_cmd.c:249
#2  0x00435d8f in dispose_words (list=0x1c936a8) at 
.././dispose_cmd.c:273
#3  0x0043608d in dispose_command (command=0x1cd32c8) at 
.././dispose_cmd.c:152
#4  0x004360bd in dispose_command (command=0x1cccbc8) at 
.././dispose_cmd.c:163
#5  0x004360bd in dispose_command (command=0x1c36ec8) at 
.././dispose_cmd.c:163
#6  0x004360bd in dispose_command (command=0x1c3ba08) at 
.././dispose_cmd.c:163
#7  0x004360bd in dispose_command (command=0x1c7c808) at 
.././dispose_cmd.c:163
#8  0x004360fd in dispose_command (command=0x1cdbc88) at 
.././dispose_cmd.c:83
#9  0x00465b58 in unwind_frame_run_internal (tag=0x4cc3ac 
"function_calling", 
ignore=0x0) at .././unwind_prot.c:333
#10 0x00465f80 in without_interrupts (arg2=0x0, arg1=0x4cc3ac 
"function_calling", 
function=) at .././unwind_prot.c:123
#11 run_unwind_frame (tag=tag@entry=0x4cc3ac "function_calling") at 
.././unwind_prot.c:151
#12 0x0043d770 in execute_function (var=var@entry=0x1ae1648, 
flags=flags@entry=0, 
fds_to_close=fds_to_close@entry=0x1c95ce8, async=async@entry=0, 
subshell=subshell@entry=0, words=) at .././execute_cmd.c:4812
#13 0x0043ddda in execute_shell_function (var=var@entry=0x1ae1648, 
words=words@entry=0x1cca6a8) at .././execute_cmd.c:4848
#14 0x0047da77 in gen_shell_function_matches (cs=0x1ce1e88, 
nw=, 
foundp=, cw=, lwords=0x1cdcea8, ind=21, 
line=0x1c8f188 "grep -n AV1 src/core/", text=0x1cd8da8 "src/core/", 
cmd=0x1c931a8 "grep")
at .././pcomplete.c:1149
#15 gen_compspec_completions (cs=cs@entry=0x1ce1e88, cmd=cmd@entry=0x1c931a8 
"grep", 
word=word@entry=0x1cd8da8 "src/core/", start=start@entry=0, 
end=end@entry=21, 
foundp=foundp@entry=0x7fff332e76e8) at .././pcomplete.c:1416
#16 0x0047e407 in 

Bug#901594: DE-agnostic agent

[Eugene Zhukov]

Valentin Blot  writes:
> I don't use a DE. Maybe the "demo" agent should be renamed and enhanced
> into a "default" agent for all the people who don't use a DE?

Same here. geoclue-2.0 should at least recommend an agent, be it some demo
agent or some DE agent. Without an agent there is a major effect on the
usability of a package.
According to upstream author himself, an agent is required by default now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900936#20

Bug#901594: (no subject)

[Eugene Zhukov]

severity serious

Bug#901594: (no subject)

[Eugene Zhukov]

severity important

Bug#905267: testng: Help upgrade package to latest upstream release

[Eugene Zhukov]

Package: testng
Severity: wishlist

Upstream switched to Gradle packaging, which I'm not very familiar with.
Please help upgrading TestNG to latest upstream release.

Versions of packages testng depends on:
pn  libbsh-java 
pn  libjcommander-java  

Versions of packages testng recommends:
ii  ant 1.10.5-1
ii  junit4  4.12-7
pn  libyaml-snake-java  

testng suggests no packages.

Bug#900936: new upstream release available

[eugene]

Hi,
FYI there is new upstream release now available with the fix:
http://www.freedesktop.org/software/geoclue/releases/2.4/geoclue-2.4.11.tar.xz

Bug#902457: [Cupt-devel] Bug#902457: cupt: FTBFS in buster/sid (failing tests)

[Eugene V. Lyubimkin]

Hello,

Thank you for the report.

On 27.06.2018 00:52, Santiago Vila wrote:
> [...]
> 
> tt/query/repo-signatures/validation-errors.t  
>(Wstat: 768 Tests: 9 Failed: 3)
>   Failed tests:  1-2, 9
>   Non-zero exit status: 3
[...]
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cupt.html
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the page for this package.

Apologies for the late response. I will take a look at this failure during the
coming week-end, even though it'd be too late to avoid a temporary auto-removal 
from testing.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#898553: grub-legacy 0.97-73 segfaults

[Eugene Berdnikov]

  Hi, Bernard.

> On Mon, Jul 09, 2018 at 05:41:45PM +0300, Eugene Berdnikov wrote:
>  I built probematic grub-legacy 0.97-73 debian package with you patch,

 Qualification: built with gcc-7.3.0 and gcc-8.1.0 compilers.
 Tested run of /usr/sbin/grub for both, MBR installation + boot for gcc-7.
 
>  on x86_64 and i686 architectures. Both variants work fine:
>  - command line /usr/sbin/grub and grub-install script run without faults,
>  - kernels boot as they should.
>  File systems are ext3 on both my computers.
-- 
 Eugene Berdnikov

Bug#898553: grub-legacy 0.97-73 segfaults

[Eugene Berdnikov]

  Hi, Bernard.

On Fri, Jul 06, 2018 at 07:32:46PM +0200, Bernhard Übelacker wrote:
> Attached patch is not relying on having the static variables accessible
> after the stack got switched by putting pointer to them on the new stack.
> 
> Tested so far:
> - i386/amd64: /usr/sbin/grub works.
> - amd64: grub-install works with a ext2 boot partition [1]. Booting the
>   system after that worked too.
>   For some reason it did not want to install to a ext4 system partition,
>   but this might be a different problem (probably #748793).

 I built probematic grub-legacy 0.97-73 debian package with you patch,
 on x86_64 and i686 architectures. Both variants work fine:
 - command line /usr/sbin/grub and grub-install script run without faults,
 - kernels boot as they should.
 File systems are ext3 on both my computers.

 So I think the problem is solved. Thank you very much!
 Waiting for updated version in Debian repository.
-- 
 Eugene Berdnikov

Bug#900199: Can't build mellanox cards drivers on backported kernel linux-image-4.16.0-0.bpo.1-amd64

[Eugene Budanov]

Hi!

I wrote an  email to maintainer of package mlnx-ofed-kernel Vladimir Sokolovsky.

Here an answer:

Hi Eugene,
Kernel 4.16 is not supported by MLNX_OFED_LINUX yet.
So, you can whether use the in-box drivers coming with Debian 9.2 or change the 
OS/kernel.
The newest supported kernel version is 4.15.

Best Regards,
Vladimir Sokolovsky,
Sr. Staff Software Engineer
Mellanox Technologies

You can close this bug as unresolvable.

---
С уважением,
Буданов Евгений.
Системный администратор
Компания «Рестрим»
5 июня 2018 г., 1:19 +0300, Andreas Beckmann , писал:
> On Sun, 27 May 2018 17:17:08 +0300 Eugene Budanov
>  wrote:
> > Package: mlnx-ofed-kernel-dkms
> > Version: 4.2-OFED.4.2.1.0.0.1.gf36c870
>
> > But mlx4-dev, mlx5-dev, mlnx-ofed-kernel tools installed too. All headers 
> > is installed.
> > F.ex:
> > knem-dkms is already the newest version 
> > (1.1.2.90mlnx3-OFED.4.2.0.1.8.1.gc943366)
>
> All these packages don't come from Debian. Whoever provides them should
> supply updates for newer kernel versions.
> There is nothing we can do in Debian to fix bugs in third-party packages.
>
>
> Andreas

Bug#899369: general: system freezes when sending SysRq-c signal instead of dumping the crashdump when on iSCSI root

[Eugene M. Zheganin]

Package: general
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
When on iSCSI root, Debian freezes after sending the SysRq-c signal. SysRq-c 
signal works in a frozen state just fine. I am aware about the fact that Linux 
cannot save the crashdump on iSCSI, so I configured the NFS resource for a 
crashdump. However, I don't see on an NFS server any network activity 
indicating that Debian tries to access the NFS share.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I have configured the kdump as follows:

# kdump-config show
DUMP_MODE:kdump
USE_KDUMP:1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR:/var/crash
crashkernel addr: 0x1500
   /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.16.0-1-amd64
kdump initrd: 
   /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.16.0-1-amd64
NFS:  10.0.2.4:/data/esx/kdump
NFS_TIMEO:600
NFS_RETRANS   3
HOSTTAG:  hv22
current state:ready to kdump

kexec command:
  /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 
root=UUID=4e04292f-93d9-4020-acc3-fa7c3bb1ab88 intel_iommu=on iommu=pt 
modprobe.blacklist=nouveau quiet nr_cpus=1 systemd.unit=kdump-tools.service 
irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img 
/var/lib/kdump/vmlinuz

NFS share is accessible from the freezing host when just mounting it.

   * What was the outcome of this action?
Actual outcome is that Debian freezes as soon as I send the SysRq-c.

   * What outcome did you expect instead?
Expected output would be: system dumps kernel core on an NFS share.

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


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

Kernel: Linux 4.16.0-1-amd64 (SMP w/56 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#897893: (no subject)

[Eugene Budanov]

Hi!

I tried to make the kernel dump, but I found a strange situation. I can't 
create it when sending echo c > /proc/sysrq-trigger .

My settings:

# cat /etc/default/kdump-tools
USE_KDUMP=1
KDUMP_RUNLEVEL="1"
KDUMP_SAVEDIR="file:///var/crash"
KDUMP_NET="none"
KDUMP_SYSCTL="kernel.panic_on_oops=1"
KDUMP_COREDIR="/var/crash"
KDUMP_FAIL_CMD="reboot -f"
DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-4.9.0-6-amd64
MAKEDUMP_ARGS="-c -d 17

# cat /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additonal system variables
# See sysctl.conf (5) for information.
#

fs.file-max = 2097152
net.core.somaxconn = 1
net.core.rmem_max = 1048576
net.core.wmem_max = 16777216
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_syncookies = 1
net.ipv4.ip_local_port_range = 31000 65535
vm.swappiness = 0
kernel.core_pattern = /tmp/core.%e.%p.%h.%t
kernel.core_uses_pid = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
vm.dirty_bytes = 536870912
vm.dirty_background_bytes = 268435456
net.netfilter.nf_conntrack_max = 12621440
net.nf_conntrack_max = 12621440
net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 120
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_window_scaling = 1
kernel.shmmax = 40802189312
kernel.shmall = 9961473
vm.zone_reclaim_mode = 0
vm.min_free_kbytes = 524288
net.core.wmem_default = 65536
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 5
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_congestion_control = htcp
net.ipv6.conf.eth0.disable_ipv6 = 1
# KERNEL PANIC OPTIONS
kernel.panic = 1
kernel.hung_task_panic = 1
kernel.panic_on_io_nmi = 1
kernel.panic_on_oops = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.softlockup_panic = 1

Of course, kdump-tools is running.

Additional information:
# dmesg |  grep "Reserving"
[    0.00] Reserving 512MB of memory at 336MB for crashkernel (System RAM: 
130958MB)

# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 root=/dev/mapper/system-root ro nomodeset 
net.ifnames=0 biosdevname=0 consoleblank=0 rootdelay=120 
transparent_hugepage=never quiet crashkernel=512M (yes, server have 128 GB RAM)

# cat /sys/kernel/kexec_crash_loaded
1

The packages kdump-tools linux-image-dbg crash kexec-tools makedumpfile is 
installed too.

What is I'm missing?

---
With best regards,
Eugene Budanov.

Bug#898553: grub-legacy 0.97-73 segfaults

[Eugene Berdnikov]

On Sun, May 13, 2018 at 04:31:10PM +0300, Eugene B. Berdnikov wrote:
> Package: grub-legacy
> Version: 0.97-73
> Severity: important
> Justification: critical
> 
>  In grub-legacy 0.97-73 binary /usr/sbin/grub segfaults on start.
>  Binary from 0.97-72 works as expected.

 Segfaults are on amd64 and i386 platforms, and also in 0.97-72+b1.
 Downgrade to grub-legacy 0.97-72 resolves the problem.
-- 
 Eugene Berdnikov

Bug#898553: grub-legacy 0.97-73 segfaults

[Eugene B. Berdnikov]

Package: grub-legacy
Version: 0.97-73
Severity: important
Justification: critical

 In grub-legacy 0.97-73 binary /usr/sbin/grub segfaults on start.
 Binary from 0.97-72 works as expected.

# ldd /usr/sbin/grub
linux-gate.so.1 (0xb7fc4000)
libncurses.so.6 => /lib/i386-linux-gnu/libncurses.so.6 (0xb7f8c000)
libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xb7f65000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7d8c000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7d87000)
/lib/ld-linux.so.2 (0xb7fc6000)
#

 Part of strace follows:

execve("/usr/sbin/grub", ["/usr/sbin/grub"], 0xbfdb6388 /* 25 vars */) = 0
brk(NULL)   = 0x8a11000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7f7e000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)

...

stat64("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/etc/terminfo/x/xterm", R_OK)   = -1 ENOENT (No such file or directory)
access("/lib/terminfo/x/xterm", R_OK)   = 0
openat(AT_FDCWD, "/lib/terminfo/x/xterm", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=3455, ...}) = 0
read(3, "\32\1)\0&\0\17\0\235\1\270\5xterm|xterm-debian|X"..., 32768) = 3455
read(3, "", 28672)  = 0
close(3)= 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=38, ws_col=125, ws_xpixel=1269, ws_ypixel=764}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=38, ws_col=125, ws_xpixel=1269, ws_ypixel=764}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
rt_sigaction(SIGTSTP, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTSTP, {sa_handler=0xb7f61f10, sa_mask=[], sa_flags=SA_RESTART}, 
NULL, 8) = 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0xb7f61e10, sa_mask=[], sa_flags=SA_RESTART}, 
NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0xb7f61e10, sa_mask=[], sa_flags=SA_RESTART}, 
NULL, 8) = 0
rt_sigaction(SIGWINCH, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGWINCH, {sa_handler=0xb7f61df0, sa_mask=[], sa_flags=0}, NULL, 
8) = 0
ioctl(1, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
write(1, "\33[?1049h\33[22;0;0t\33[1;38r\33(B\33[m\33["..., 46) = 46
rt_sigaction(SIGWINCH, {sa_handler=SIG_IGN, sa_mask=[WINCH], 
sa_flags=SA_RESTART}, {sa_handler=0xb7f61df0, sa_mask=[], sa_flags=0}, 8) = 0
sync()  = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xee8} ---
+++ killed by SIGSEGV +++



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.15.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages grub-legacy depends on:
ii  grub-common  2.02+dfsg1-4
ii  libc62.27-3
ii  libncurses5  6.1+20180210-2
ii  libtinfo56.1+20180210-2

grub-legacy recommends no packages.

Versions of packages grub-legacy suggests:
ii  grub-legacy-doc  0.97-72
pn  mdadm
ii  multiboot0.6.96+20101113-2

-- no debconf information

Bug#897893: Strange kernel panics on linux-image-4.9.0-6-amd64 with mlx4_en driver

[Eugene Budanov]

Hi!

This is only one driver, mpt2sas downloaded from LSI site version 22.00 instead 
13.0 from Debian package. Because from beggining we think that is was a 
problems in RAID controller. But this hypothesis turned out as erroneous. On 
other machines we use mpt2sas in-kernel driver only. No 3rd party drivers.

---
С уважением,
Буданов Евгений.
Системный администратор
Компания «Рестрим»

On 4 мая 2018 г., 17:08 +0300, Ben Hutchings <b...@decadent.org.uk>, wrote:
> Control: tag -1 moreinfo
>
> On Fri, 2018-05-04 at 15:35 +0300, Eugene Budanov wrote:
> > Package: linux-image-4.9.0-6-amd64
> > Version: 4.9.82-1+deb9u3
> >
> > Hi!
> >
> > Here's a short problem description.
> >
> > We have some Supermicro servers with the same configuration for all
> > machines (hardware, kernels, packages, etc). A month ago, or maybe a
> > bit later, all of these machines began crashing into kernel panic. I
> > can't find any pattern of failure at all. But it happens very often.
> > Some machines may drop into kernel panic a couple times a day! But
> > usually machines crash about every 3 to 6 days. All of these machines
> > have intensive network and i/o operations.
> >
> > I saved dmesg log from one of these machines after the crash (see the
> > attachment).
> >
> > As far as I see, every machine probably has problems with mlx4_en or
> > GRO. Also I see list_add double add => list_del corruption. Can I do
> > anything to get more detailed logs? What additional information do
> > you need for better problem diagnostics?
>
> The WARNING messages show that there are out-of-tree modules (i.e. not
> part of the kernel package) loaded. What are those?
>
> Ben.
>
> --
> Ben Hutchings
> Every program is either trivial or else contains at least one bug
>

Bug#897893: Strange kernel panics on linux-image-4.9.0-6-amd64 with mlx4_en driver

[Eugene Budanov]

Package: linux-image-4.9.0-6-amd64
Version: 4.9.82-1+deb9u3

Hi!

Here's a short problem description.

We have some Supermicro servers with the same configuration for all machines 
(hardware, kernels, packages, etc). A month ago, or maybe a bit later, all of 
these machines began crashing into kernel panic. I can't find any pattern of 
failure at all. But it happens very often. Some machines may drop into kernel 
panic a couple times a day! But usually machines crash about every 3 to 6 days. 
All of these machines have intensive network and i/o operations.

I saved dmesg log from one of these machines after the crash (see the 
attachment).

As far as I see, every machine probably has problems with mlx4_en or GRO. Also 
I see list_add double add => list_del corruption. Can I do anything to get more 
detailed logs? What additional information do you need for better problem 
diagnostics?



---
С уважением,
Буданов Евгений.
Системный администратор
Компания «Рестрим»


dmesg.log
Description: Binary data


lspci
Description: Binary data

Bug#896654: git-buildpackage: gbp import-orig: fails with revision X not found

[Eugene Zhukov]

Hi Guido,

Thanks for a quick fix!
However, how to get around the actual error?
It fails the same way even with:

$ gbp import-orig --verbose --uscan --upstream-vcs-tag=6.14.3

$ gbp import-orig --verbose --uscan --upstream-vcs-tag=6.14.3
--upstream-tag=6.14.3

$ gbp import-orig --verbose ../testng_6.14.3.orig.tar.gz

Note that 6.14.3 tag exists upstream [1].

[1] https://github.com/cbeust/testng/tree/6.14.3

Thanks,
Eugene

Bug#896654: git-buildpackage: gbp import-orig: fails with revision X not found

[Eugene Zhukov]

Package: git-buildpackage
Version: 0.9.8
Severity: normal

Dear Maintainer,

I was trying to update TestNG package to the latest upstream release, but gbp
import-orig fails without much useful (for me) output.

Here is how to reproduce the problem:

eugene@debian:~/dev$ git clone ssh://git.debian.org/git/pkg-java/testng.git
Cloning into 'testng'...
remote: Counting objects: 32552, done.
remote: Compressing objects: 100% (10926/10926), done.
remote: Total 32552 (delta 19512), reused 32540 (delta 19509)
Receiving objects: 100% (32552/32552), 22.93 MiB | 2.35 MiB/s, done.
Resolving deltas: 100% (19512/19512), done.
eugene@debian:~/dev$ cd testng/
eugene@debian:~/dev/testng$ git checkout upstream
Branch 'upstream' set up to track remote branch 'upstream' from 'origin'.
Switched to a new branch 'upstream'
eugene@debian:~/dev/testng$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
eugene@debian:~/dev/testng$ gbp import-orig --uscan --verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'status', '--porcelain']
gbp:info: Launching uscan...
uscan: Newest version of testng on remote site is 6.14.3, local version is 
6.9.12
uscan:=> Newer package available from
  https://github.com/cbeust/testng/archive/6.14.3.tar.gz
gbp:info: Using uscan downloaded tarball ../testng_6.14.3.orig.tar.gz
What is the upstream version? [6.14.3] 
gbp:debug: ['git', 'tag', '-l', 'upstream/6.14.3']
gbp:debug: tar ['-C', '../tmp7udar6lx', '-a', '-xf', 
'../testng_6.14.3.orig.tar.gz'] []
gbp:debug: Unpacked '../testng_6.14.3.orig.tar.gz' to 
'../tmp7udar6lx/testng-6.14.3'
gbp:info: Importing '../testng_6.14.3.orig.tar.gz' to branch 'upstream'...
gbp:info: Source package is testng
gbp:info: Upstream version is 6.14.3
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'testng-6.14.3^{}']
gbp:error: Import of ../testng_6.14.3.orig.tar.gz failed: revision 
'testng-6.14.3^{}' not found
gbp:debug: rm ['-rf', '../tmp7udar6lx'] []
eugene@debian:~/dev/testng$

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.1
ii  git1:2.17.0-1
ii  man-db 2.8.3-2
ii  python33.6.5-3
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  39.0.1-2

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.87
ii  pbuilder  0.229.2
ii  pristine-tar  1.42
ii  python3-requests  2.18.4-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.21p2-3
ii  unzip6.0-21

-- no debconf information

Bug#894544: cantata: please switch build-depends to libcddb2-dev

[Eugene V. Lyubimkin]

Package: cantata
Version: 2.2.0.ds1-1
Severity: normal

Dear Maintainer,

Your package build-depends on 'libcddb-dev', which is an ancient
transitional virtual package provided by 'libcddb2-dev'. I'm looking
forward to remove this virtual package, and your package is the last in
the Debian archive which uses it.

Please replace 'libcddb-dev' with 'libcddb2-dev' in your build-depends.


Regards,

-- System Information:
Debian Release: 8.0
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#882238: [Cupt-devel] Bug#882238: Bug#882238: cupt: FTBFS on hppa and hurd-i386: feeding-input.t fails

[Eugene V. Lyubimkin]

Control: tags -1 + pending

Hi Dave,

On 30.03.2018 19:41, John David Anglin wrote:
> [...]
> The attached change fixed the build failure on my rp3440.  Don't know if 60s 
> is enough for the slower buildds.

Thank you for investigation. It's good to know that the current timeout buffer
just isn't large enough. It's interesting that, judging from the last buildd 
log,
for a particularly CPU-intense case the slowdown versus my desktop was only 5x,
but the more I/O-bound failing case didn't cut it despite a 20x buffer.

I'll increase the timeout to 90s in the next upload, and see if that works 
better
for buildds.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#882238: [Cupt-devel] Bug#882238: cupt: FTBFS on hppa and hurd-i386: feeding-input.t fails

[Eugene V. Lyubimkin]

Hi,

Thank you for taking a look.

On 30.03.2018 01:01, John David Anglin wrote:
[...]
>>> On hurd-i386, I tracked it down to a misbehaviour of timeout(1), reported 
>>> as #894379.
>>> For HPPA, I didn't see any available porterboxes for HPPA on db.debian.org, 
>>> so I could not
>>> reproduced it. Did I miss any?
>> I'll take a look at the timeout problem.  Access to a box can be arranged.
> I find timeout works correctly on hppa.

I see, so it's a different issue then. Please let me know if/when there is a 
box I could
reproduce the test case failure on.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#894380: ncdu: please enable color by default

[Eugene V. Lyubimkin]

Control: tags -1 wontfix

Hi Graham,

Thank you for the interest.

On 29.03.2018 17:32, Graham Inggs wrote:
> Please consider enabling color by default as per the attached patch.
> I believe doing so in Debian Testing can assist upstream in perfecting this 
> new feature.

The color feature is explicitly marked as experimental by upstream. 
Additionally, there are
quite a few old and new features not enabled by default, but we don't enable 
them all just
for earlier testing. Coloring works fine for me, but I don't see it as a 
game-changer worth
to diverge from upstream.

Those who like the feature and want to assist with testing could easily use 
shell aliases to
save the typing and personalise the options they prefer.

If you persuade upstream to change the defaults earlier before the next 
release, I'm open to
cherry-picking that.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#882238: [Cupt-devel] Bug#882238: cupt: FTBFS on hppa and hurd-i386: feeding-input.t fails

[Eugene V. Lyubimkin]

Hi Aaron, Hurd and HPPA porters,

Thank you for the report. Sorry that it took so long to get it to it.

On hurd-i386, I tracked it down to a misbehaviour of timeout(1), reported as 
#894379.
For HPPA, I didn't see any available porterboxes for HPPA on db.debian.org, so 
I could not
reproduced it. Did I miss any?

Otherwise, if you know simple-to-use substitutes for timeout(1) or know what's 
going on in
#894379, your input is welcome.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#894379: coreutils: timeout (hurd, possibly hppa): fails to detect that a program has exited

[Eugene V. Lyubimkin]

Package: coreutils
Version: 8.28-1
Severity: normal

Control: affects -1 cupt


Hello,

Thank you for maintaining coreutils. I use timeout(1) to conveniently
detect hanging problems in the testsuite of cupt. Unfortunately, on hurd
and hppa it makes the test suite fail. 

This issue is best illustrated through a test case:

On hurd-i386 the commands which take less time to execute still make
'timeout' wait full time and exit with the error code:
--8<-
$ mkdir abc
$ cd abc
$ timeout 5s ls
$ echo $?
124
$ timeout 5s cat
$ echo $?
124
-->8-

On, say, amd64 the same scenario works as expected:
--8<-
$ mkdir abc
$ cd abc
$ timeout 5s ls
$ echo $?
0
$ timeout 5s cat
$ echo $?
124
-->8-

I couldn't check this scenario on hppa (as there are no porterboxes for
it), but the bug report #882238 suggests a similar issue has been
encountered on a hppa buildd box.

On hurd-i386 portexbox, I did verify that the program run under
timeout(1) does exit, but timeout(1) itself continues to run even
though it has no child processes anymore.

Bug#808211: saxonhe: Versions 9.6 and 9.7 should be installable at the same time

[Eugene Zhukov]

On Wed, Feb 14, 2018 at 6:50 AM, tony mancill <tmanc...@debian.org> wrote:
> Hello Eugene,
>
> I'm working on packaging checkstyle 8.8 which requires SaxonHE 9.8.  I
> put together a package for the newer saxonhe (in experimental) and I can
> successful build the r-deps within Debian using ratt.  However,
> comparing the 9.7 and 9.8 libraries with japi-compliance-checker, I'm
> reluctant to upload the package to unstable because there are so many
> breaking changes between the versions.
>
> Do you have any advice or thoughts about what we should do for buster?
>
Hi tony,

Thanks for working on this!
I think we need to ping upstream about missing hej/data folder in the
last tag. Without it xml-maven-plugin or epubcheck won't work [0].
My other concern is Schematron upgrade [1]. We might actually want to
package SaxonHE 9.8.0.7 or newer to support both XSLT 1.0 and 2.0.

[0] https://github.com/IDPF/epubcheck/issues/674#issuecomment-348102028
[1] https://github.com/Schematron/schematron/issues/55

Eugene

Bug#890033: fmtlib: CVE-2018-1000052: Segmentation fault in fmt::print()

[Eugene V. Lyubimkin]

Control: severity -1 normal
Control: tags -1 - security

Hello Salvatore,

Thank you for bring this CVE entry for my attention. Unfortunately I find
that the entry contains a factual error and a judgement I disagree with (see 
below).


On 10.02.2018 11:21, Salvatore Bonaccorso wrote:
> [...]
> CVE-2018-152[0]:
> | fmtlib version prior to version 4.1.0 (before commit
> | 0555cea5fc0bf890afe0071a558e44625a34ba85) contains a Memory corruption
> | (SIGSEGV), CWE-134 vulnerability in fmt::print() library function that
> | can result in Denial of Service. This attack appear to be exploitable
> | via Specifying an invalid format specifier in the fmt::print()
> | function results in a SIGSEGV (memory corruption, invalid write). This
> | vulnerability appears to have been fixed in after commit
> | 8cf30aa2be256eba07bb1cefb998c52326e846e7.

Firstly, the crash in question happens when using a specially-crated format 
string.
Just like for C-style printf(), application developers should not pass untrusted
input as a first argument to formatting functions. For well-written applications
using fmtlib, there is no exposure and therefore I disagree with labelling this
bug as security vulnerability or DoS.

One can argue that the library advertises itself as a safe prompts to think the 
library
shall handle gracefully any junk in the format string. It ideally should, but 
failing to so
still wouldn't IMO constitute a vulnerability, but simply a normal-severity bug.

Secondly, the upstream commit 8cf30aa2be is not included in the upstream 
version 4.1.0
(unlike the entry indicates). 4.1.0 was released in January 2018, and the fix 
was
committed in February 2018. Therefore, only next minor or patch release will 
contain
the fix. I am not planning to cherry-pick the fix before that.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#874867: [fbreader] Future Qt4 removal from Buster

[Eugene V. Lyubimkin]

Hello,

On 08.12.2017 17:37, Francesco Poli wrote:
> I suppose you no longer user FBReader, nowadays.
> I wonder: what alternative e-book reader are you currently using?

I read less e-books nowadays, and those I read usually available (or 
convertible)
to HTML or PDF.

> Would you be willing to package Bookworm for inclusion in Debian?

It's a good sign there are some other actively developed software for e-books.
Bookworm specifically has an implementation language/ecosystem (Vala) I'm not 
familiar with,
so I'd not package it myself.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer



signature.asc
Description: OpenPGP digital signature

Bug#874867: [fbreader] Future Qt4 removal from Buster

[Eugene V. Lyubimkin]

Hello Francesco,

First and foremost: if anybody reading these lines has time to take good
care of fbreader, it has been up for adoption for quite some time (#808074).

On 26.11.2017 12:12, Francesco Poli wrote:
[...]
> Hello Eugene,
> I noticed that fbreader needs to be ported to Qt5, but the upstream
> project seems to be basically dead, as stated in [issue #285]
> (which is referenced on the Qt4 removal Debian wiki page).
> 
> [issue #285]: <https://github.com/geometer/FBReader/issues/285>
> 
> It would be really sad news, if fbreader had to be removed from Debian:
> it is a nice lightweight e-book reader.
> 
> Some messages (currently) at the end of the above-cited [issue #285]
> claim that a Qt5 port is possible with a couple of patches ("pallegro
> commented Mar 30, 2016" and "idomeneo commented Nov 18, 2017").
> See also the [Gentoo pr #5970].
> 
> [Gentoo pr #5970]: <https://github.com/gentoo/gentoo/pull/5970>
> 
> Those patches seem to be based on version 0.99.4, which you [said] you
> were hesitant about packaging. Is it time to reconsider, perhaps?

The only long-term solution I see to revive and maintain long-stagnated fbreader
is that somebody becomes an involved and active upstream. I don't see that
packaging a dead-end beta version with some patches on top is supportable and
sustainable (but a prospective new maintainer can disagree with that).

Unlike 0.99.x serie, 0.12.x serie does have two back-ends: Qt4 and GTK2.

This is what I plan to do if nobody steps and as new Debian and/or
upstream maintainer:

1. When Qt4 is removed from Debian, libzlui-qt4 (Qt4 back-end for fbreader) will
go away. Fbreader will remain usable with libzlui-gtk (GTK2 back-end).

2. When GTK2 is removed from Debian, fbreader will be removed from Debian.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#882146: dpkg: does not allow removing a dependency of an unpacked package without --force-depends

[Eugene V. Lyubimkin]

Package: dpkg
Version: 1.19.0.4
Severity: normal

Hi Guillem and all,

Please consider the following situation:
 - package 'aa' is unpacked;
 - package 'aa' has a dependency on package 'bb' (version 2);
 - package 'bb' version 1 is currently installed;
 - we're trying to remove package 'bb'.

I'd expect we can remove 'bb' (version 1), since dependencies do not have to be
satisfied for merely-unpacked packages. Moreover, the dependency 'aa -> bb' was
unsatisfied anyway due to a version mismatch, so removing 'bb' does not break
any dependency which was satisfied before.

Adding '--force-depends' works around the problem, but I'd prefer not having to
mass-enable it.

Here is a transcript with real packages (aa -> python3-uno, bb ->
libreoffice-core):
-8<---
$ dpkg -s python3-uno | egrep "Depends|Status"
Status: install ok unpacked
Depends: libreoffice-core (= 1:5.4.2-3), [...]

$ dpkg -s libreoffice-core | grep Version
Version: 1:5.2.2~rc2-2

$ dpkg --dry-run --force-bad-path --remove libreoffice-core
[...]
dpkg: dependency problems prevent removal of libreoffice-core:
 python3-uno depends on libreoffice-core (= 1:5.4.2-3).
 libreoffice-base-core depends on libreoffice-core (= 1:5.4.2-3).
 libreoffice-math depends on libreoffice-core (= 1:5.4.2-3).

dpkg: error processing package libreoffice-core (--remove):
 dependency problems - not removing
Errors were encountered while processing:
 libreoffice-core

$ dpkg --dry-run --force-bad-path --force-depends --remove libreoffice-core
[...]
dpkg: libreoffice-core: dependency problems, but removing anyway as you 
requested:
 python3-uno depends on libreoffice-core (= 1:5.4.2-3).
 libreoffice-base-core depends on libreoffice-core (= 1:5.4.2-3).
 libreoffice-math depends on libreoffice-core (= 1:5.4.2-3).

(Reading database ... 147478 files and directories currently installed.)
Would remove or purge libreoffice-core (1:5.2.2~rc2-2) ...
->8---

Seen same behavior also in dpkg 1.18.24 and 1.17.24.


-- System Information:
Debian Release: 8.0
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7+b2
ii  libc62.23-1
ii  liblzma5 5.2.2-1.2+b1
ii  libselinux1  2.3-2
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.6~alpha5
pn  debsig-verify  

-- no debconf information

Bug#881720: curl: key authentication doesn't work with scp/sftp

[Eugene M. Zheganin]

Package: curl
Version: 7.52.1-5+deb9u2

curl doesn't support key authentication when using scp/sftp, it complains about
"SSH public key authentication failed: Unable to extract public key from 
private key file:
Method unimplemented in libgcrypt backend". In the same time version 7.54.0 
works just fine on CentOS (although it's
from my personal repository, it contains no tricky hacks, just an upstream 
tarball), 7.56.1 also is proven to work on Solaris
being built from sources.

Here's the output from the Debian curl version:

===Cut===
spitsynas@groot:~$ curl - -k --key ~/.ssh/id_rsa 
'sftp://freshst...@ksssftp.kaspersky-labs.com/ertelecom/SLU/Subscription 
License Usage_ertelecom_August2017.zip' -o zzz.zip -v
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 212.5.110.121...
* TCP_NODELAY set
* Connected to ksssftp.kaspersky-labs.com (212.5.110.121) port 22 (#0)
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
SSH MD5 fingerprint: 03d19d7ec7e07f0f419180d59db1de1b
* SSH authentication methods available: publickey,password
* Using SSH private key file '/home/spitsynas/.ssh/id_rsa'
* SSH public key authentication failed: Unable to extract public key from 
private key file: Method unimplemented in libgcrypt backend
* Failure connecting to agent
* Authentication failure
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (67) Authentication failure
spitsynas@groot:~$
===Cut===

Here's the reference output from stock 7.56.1 version on Solaris:

===Cut===
[aspitsyn@hyperion ~]$ curl -k - --key ~/.ssh/id_rsa 
'sftp://freshst...@ksssftp.kaspersky-labs.com/ertelecom/SLU/Subscription 
License Usage_ertelecom_August2017.zip' -o zzz.zip
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 212.5.110.121...
* TCP_NODELAY set
* Failed to set TCP_KEEPALIVE on fd 3
* Connected to ksssftp.kaspersky-labs.com (212.5.110.121) port 22 (#0)
* SSH MD5 fingerprint: 03d19d7ec7e07f0f419180d59db1de1b
* SSH authentication methods available: publickey,password
* Using SSH private key file '/home/aspitsyn/.ssh/id_rsa'
* Initialized SSH public key authentication
* Authentication complete
{ [2000 bytes data]
100 13.6M  100 13.6M0 0  1996k  0  0:00:07  0:00:07 --:--:-- 1970k
100 13.6M  100 13.6M0 0  1996k  0  0:00:07  0:00:07 --:--:-- 1996k
* Connection #0 to host ksssftp.kaspersky-labs.com left intact
===Cut===

Not that the keys are the same on both hosts (checked and doublechecked, 
furthermore
- this doesn't look like a different key problem, this looks like a key 
extraction problem).

Debian version info:

===Cut===
spitsynas@groot:~$ curl -V
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 
libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 
librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL 
libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
===Cut===


Solaris version info:
===Cut===
[aspitsyn@hyperion ~]$ curl -V
curl 7.56.1 (i386-pc-solaris2.11) libcurl/7.56.1 OpenSSL/1.0.2g 
zlib/1.2.3-T4mods libssh2/1.4.3
Release-Date: 2017-10-23
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets 
HTTPS-proxy
===Cut===


Environment: Debian 4.9.30-2+deb9u2

Bug#879914: fmtlib: please make the build reproducible

[Eugene V. Lyubimkin]

Hi,

On 27.10.2017 10:41, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that fmtlib could not be built reproducibly as — in a Doxygen error
> message — it exposes the use of Doxygen's "FULL_PATH_NAMES = YES".
> 
> Patch attached.

Looks good, thanks. Will be applied in the next upload.


-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#878070: fmtlib: Removing header-only target is causing problem

[Eugene V. Lyubimkin]

Control: retitle -1 fmtlib: static library should be compiled with -fPIC
Control: tags -1 + confirmed pending


Hello,

On 09.10.2017 15:15, Boyuan Yang wrote:
> I saw that your recommendation is to use the static library provided. I think 
> that may not be best practice.

I agree it's not. However, fmtlib changed its major version 4 times in
the last 2½ years, so considering its small size and relative unstability (so 
far)
the package doesn't provide a shared library right now. In version 4 there are
less breaking changes than before, so I'll re-evaluate whether to add a shared
library later in the release cycle.

> As you might already know,  Debian don't really recommend using static 
> libraries. Especially after the beginning of hardening efforts in Debian [2], 
> using static libraries while building hardened binaries will encounter 
> problem 
> that the static library is not built with -fPIC. This is the current case for 
> fcitx5 using fmtlib.

Good point. The code should be definitely built with -fPIC. Thank you for
the report, will be fixed in the next upload.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#877642: RM: cppformat -- ROM; superseded by fmtlib

[Eugene V. Lyubimkin]

Package: ftp.debian.org
Severity: normal

Hello,

The newer version of 'cppformat' was uploaded as 'fmtlib' (following an
upstream project rename). Thus, the older version can be now removed.

Bug#876543: cppformat: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Eugene V. Lyubimkin]

Hello,

On 23.09.2017 16:06, Dmitry Shachnev wrote:
> cppformat uses a custom Sphinx template which is not fully compatible
> with Sphinx 1.5 and newer versions: search does not work because
> SOURCELINK_SUFFIX attribute is not defined in DOCUMENTATION_OPTIONS in
> search.html.
> 
> dh_sphinxdoc currently emits a warning about this, I plan to make it
> an error in the next upload.
> 
> Please backport the relevant upstream patch (see the linked pull request)
> or upgrade to upstream 4.0.0 release.

Thank you for the report. fmtlib 4.0.0 entered unstable yesterday, so
cppformat (old upstream name) will by superseded by it.


-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer