Bug#1065203: regression: TypeError: find_username() missing 1 required positional argument: 'ssh_conf'

[Ritesh Raj Sarraf]

Package: dput-ng
Version: 1.39
Followup-For: Bug #1065203
X-Debbugs-Cc: r...@debian.org

I've been suffering with same problems, and even more, with dput-ng for
some time now. Only now, that ssh-upload alos fails, do I realize I
should have reported the bug.


```
$ dput  mergerfs_2.33.5-1_source.changes
Uploading mergerfs using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Uploading mergerfs_2.33.5-1.dsc
Could not upload file mergerfs_2.33.5-1.dsc: 229 Extended Passive Mode Entered 
(|||13868|).

$ dput  ssh-upload mergerfs_2.33.5-1_source.changes
Uploading mergerfs using scp to ssh-upload (host: ssh.upload.debian.org; 
directory: /srv/upload.debian.org/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Traceback (most recent call last):
  File "/usr/bin/dput", line 129, in 
upload_package(changes, args)
  File "/usr/lib/python3/dist-packages/dput/uploader.py", line 323, in 
invoke_dput
with uploader(profile['method'], profile,
  File "/usr/lib/python3.11/contextlib.py", line 137, in __enter__
return next(self.gen)
   ^^
  File "/usr/lib/python3/dist-packages/dput/uploader.py", line 170, in uploader
obj.initialize()
  File "/usr/lib/python3/dist-packages/dput/uploaders/scp.py", line 56, in 
initialize
login = find_username(self._config)
^^^
TypeError: find_username() missing 1 required positional argument: 'ssh_conf'
```


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dput-ng depends on:
ii  python3   3.11.6-1
ii  python3-dput  1.39

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  
ii  rsync3.2.7-1+b1

-- no debconf information

Bug#1051924: devscripts: FTBFS fails in test test/test_debchange

[Ritesh Raj Sarraf]

Package: devscripts
Version: 2.23.6
Severity: important
Tags: ftbfs
X-Debbugs-Cc: r...@debian.org


Dear Maintainer,


The devscripts package FTBFS in Debian, in the reproducible builds
project, as well as in the derivative Apertis distribution.

The problem comes from `debchange`, which now doesn't like
buster-backports as a distro.

For the failing test, I bumpded the test distro from Buster to Bookworm.

Does it look correct ?


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBEMAIL="r...@debian.org"
DEBFULLNAME="Ritesh Raj Sarraf"
BTS_SMTP_HOST="localhost"
BTS_INTERACTIVE=yes
DEBSIGN_KEYID="43DE F582 F9E6 7111 CE00  8917 F2F1 1C23 F00A 2BE6"
DEB_SIGN_KEYID="43DE F582 F9E6 7111 CE00  8917 F2F1 1C23 F00A 2BE6"

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-security'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.22.0
ii  fakeroot  1.32.1-1
ii  file  1:5.45-2
ii  gnupg 2.2.40-1.1
ii  gnupg22.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.72-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-9
ii  python3   3.11.4-5+b1
ii  sensible-utils0.0.20
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.7.3
ii  curl8.2.1-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2023.05.26
ii  dput-ng [dput]  1.37
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5
ii  libdpkg-perl1.22.0
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.27-1
ii  libjson-perl4.1-1
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.11-1
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.21-1
ii  licensecheck3.3.9-1
ii  lintian 2.116.3
ii  man-db  2.11.2-3
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.27-2
ii  python3-requests2.31.0+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.4-0.1
ii  unzip   6.0-28
ii  wget1.21.3-1+b2
ii  xz-utils5.4.4-0.1

Versions of packages devscripts suggests:
ii  adequate 0.15.8
ii  at   3.2.5-2
ii  autopkgtest  5.30
pn  bls-standalone   
ii  build-essential  12.10
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.6
pn  diffoscope   
pn  disorderfs   
ii  dose-extra   7.0.0-4
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.16-1+b1
pn  mmdebstrap   
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:9.4p1-1
pn  piuparts 
pn  postgresql-client
ii  pristine-lfs 20210404.1-2
ii  quilt0.67+really0.66-1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information
>From 5509881fbc5e80c101b6bba900cbc3ad8eaa44aa Mon Sep 17 00:00:00 2001
From: Ritesh Raj Sarraf 
Date: Wed, 13 Sep 2023 20

Bug#1051462: kdiff3: segfault when quitting the application

[Ritesh Raj Sarraf]

Package: kdiff3
Version: 1.10.5-1
Followup-For: Bug #1051462
X-Debbugs-Cc: r...@debian.org


Workaround is to disable "Word Wrap Diff Windows" under menu:

DiffView => Word Wrap Diff Windows

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-security'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages kdiff3 depends on:
ii  kio   5.107.0-1
ii  libc6 2.37-7
ii  libgcc-s1 13.2.0-3
ii  libkf5configcore5 5.107.0-1
ii  libkf5configwidgets5  5.107.0-2
ii  libkf5coreaddons5 5.107.0-1
ii  libkf5crash5  5.107.0-1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5kiocore55.107.0-1
ii  libkf5kiowidgets5 5.107.0-1
ii  libkf5parts5  5.107.0-1
ii  libkf5widgetsaddons5  5.107.0-1
ii  libkf5xmlgui5 5.107.0-1+b1
ii  libqt5core5a  5.15.10+dfsg-3
ii  libqt5gui55.15.10+dfsg-3
ii  libqt5printsupport5   5.15.10+dfsg-3
ii  libqt5widgets55.15.10+dfsg-3
ii  libstdc++613.2.0-3

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.10.5-1

kdiff3 suggests no packages.

-- no debconf information

Bug#1051462: kdiff3: segfault when quitting the application

[Ritesh Raj Sarraf]

Package: kdiff3
Version: 1.10.5-1.1
Followup-For: Bug #1051462
X-Debbugs-Cc: r...@debian.org

I did a rebuild of 1.10.5-1 on my local machine as well, and I got this
report from kcrash.


```
Application: kdiff3 (kdiff3), signal: Segmentation fault

   PID: 24865 (kdiff3)
   UID: 1000 (rrs)
   GID: 1000 (rrs)
Signal: 11 (SEGV)
 Timestamp: Fri 2023-09-08 16:20:16 IST (9s ago)
  Command Line: kdiff3
Executable: /usr/bin/kdiff3
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-50ec912755ae4e4695ca5a6bb7e88c85.scope
  Unit: user@1000.service
 User Unit: app-org.kde.konsole-50ec912755ae4e4695ca5a6bb7e88c85.scope
 Slice: user-1000.slice
 Owner UID: 1000 (rrs)
   Boot ID: a756b371b728465a8a28838af2d1a4c7
Machine ID: c879ebc407d84ea997f9e5564dd7aab6
  Hostname: priyasi
   Storage: 
/var/lib/systemd/coredump/core.kdiff3.1000.a756b371b728465a8a28838af2d1a4c7.24865.169417021600.zst
 (present)
  Size on Disk: 4.6M
   Message: Process 24865 (kdiff3) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-254.1-3.amd64
Module libudev.so.1 from deb systemd-254.1-3.amd64
Stack trace of thread 24865:
#0  0x7ff8f8ca80fc __pthread_kill_implementation (libc.so.6 
+ 0x8a0fc)
#1  0x7ff8f8c5a472 __GI_raise (libc.so.6 + 0x3c472)
#2  0x7ff8facb2b46 _ZN6KCrash19defaultCrashHandlerEi 
(libKF5Crash.so.5 + 0x5b46)
#3  0x7ff8f8c5a510 __restore_rt (libc.so.6 + 0x3c510)
#4  0x7ff8f787f7ea n/a (libwayland-client.so.0 + 0xb7ea)
#5  0x7ff8f787ad38 n/a (libwayland-client.so.0 + 0x6d38)
#6  0x7ff8f787b1c2 wl_proxy_marshal_array_flags 
(libwayland-client.so.0 + 0x71c2)
#7  0x7ff8f787b3cd wl_proxy_marshal_flags 
(libwayland-client.so.0 + 0x73cd)
#8  0x7ff8f78f3b5d 
_ZN15QtWaylandClient17QWaylandShmBufferD2Ev (libQt5WaylandClient.so.5 + 0x6db5d)
#9  0x7ff8f78f3bed 
_ZN15QtWaylandClient23QWaylandShmBackingStoreD1Ev (libQt5WaylandClient.so.5 + 
0x6dbed)
#10 0x7ff8f78f3c79 
_ZN15QtWaylandClient23QWaylandShmBackingStoreD0Ev (libQt5WaylandClient.so.5 + 
0x6dc79)
#11 0x7ff8f9b0da1b _ZN13QBackingStoreD1Ev (libQt5Gui.so.5 + 
0x30da1b)
#12 0x7ff8fa18ae3f _ZN14QWidgetPrivate16deleteTLSysExtraEv 
(libQt5Widgets.so.5 + 0x18ae3f)
#13 0x7ff8fa1993a0 _ZN7QWidget7destroyEbb 
(libQt5Widgets.so.5 + 0x1993a0)
#14 0x7ff8fa1a0772 _ZN7QWidgetD2Ev (libQt5Widgets.so.5 + 
0x1a0772)
#15 0x5561a831e199 
_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv (kdiff3 + 
0x99)
#16 0x7ff8f8c5c955 __run_exit_handlers (libc.so.6 + 0x3e955)
#17 0x7ff8f8c5ca8a __GI_exit (libc.so.6 + 0x3ea8a)
#18 0x7ff8f8c456d1 __libc_start_call_main (libc.so.6 + 
0x276d1)
#19 0x7ff8f8c45785 __libc_start_main_impl (libc.so.6 + 
0x27785)
#20 0x5561a8265031 _start (kdiff3 + 0x58031)
ELF object binary architecture: AMD x86-64
[New LWP 24865]
This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) [answered N; input not from 
terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `kdiff3'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=11, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
[KCrash Handler]
#5  0x7ff8f787f7ea in ?? () from 
/lib/x86_64-linux-gnu/libwayland-client.so.0
#6  0x7ff8f787ad38 in ?? () from 
/lib/x86_64-linux-gnu/libwayland-client.so.0
#7  0x7ff8f787b1c2 in wl_proxy_marshal_array_flags () from 
/lib/x86_64-linux-gnu/libwayland-client.so.0
#8  0x7ff8f787b3cd in wl_proxy_marshal_flags () from 
/lib/x86_64-linux-gnu/libwayland-client.so.0
#9  0x7ff8f78f3b5d in 
QtWaylandClient::QWaylandShmBuffer::~QWaylandShmBuffer() () from 
/lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#10 0x7ff8f78f3bed in 
QtWaylandClient::QWaylandShmBackingStore::~QWaylandShmBackingStore() () from 
/lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#11 0x7ff8f78f3c79 in 
QtWaylandClient::QWaylandShmBackingStore::~QWaylandShmBackingStore() () from 
/lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#12 0x7ff8f9b0da1b in QBackingStore::~QBackingStore() () from 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#13 0x7ff8fa18ae3f in QWidgetPrivate::deleteTLSysExtra() () from 

Bug#1051462: kdiff3: segfault when quitting the application

[Ritesh Raj Sarraf]

Package: kdiff3
Version: 1.10.5-1
Severity: important
X-Debbugs-Cc: r...@debian.org

Dear Maintainer,


kdiff3, version 1.10.5-1, keeps persistently crashing upon exit. I'm not
sure if the gathered trace is any useful but adding it here.


```
$ coredumpctl dump 22787
   PID: 22787 (kdiff3)
   UID: 1000 (rrs)
   GID: 1000 (rrs)
Signal: 11 (SEGV)
 Timestamp: Fri 2023-09-08 15:46:17 IST (1min 40s ago)
  Command Line: kdiff3
Executable: /usr/bin/kdiff3
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-d4586fce1af2414a8aa867c1e9d69bd5.scope
  Unit: user@1000.service
 User Unit: app-org.kde.konsole-d4586fce1af2414a8aa867c1e9d69bd5.scope
 Slice: user-1000.slice
 Owner UID: 1000 (rrs)
   Boot ID: be103b493b054b3cbef500a2863a95dc
Machine ID: c879ebc407d84ea997f9e5564dd7aab6
  Hostname: priyasi
   Storage: 
/var/lib/systemd/coredump/core.kdiff3.1000.be103b493b054b3cbef500a2863a95dc.22787.169416817700.zst
 (present)
  Size on Disk: 5.3M
   Message: Process 22787 (kdiff3) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-254.1-3.amd64
Module libudev.so.1 from deb systemd-254.1-3.amd64
Stack trace of thread 22787:
#0  0x7fac88ea80fc __pthread_kill_implementation (libc.so.6 
+ 0x8a0fc)
#1  0x7fac88e5a472 __GI_raise (libc.so.6 + 0x3c472)
#2  0x7fac8adf2b46 _ZN6KCrash19defaultCrashHandlerEi 
(libKF5Crash.so.5 + 0x5b46)
#3  0x7fac88e5a510 __restore_rt (libc.so.6 + 0x3c510)
#4  0x7fac879bf8ee n/a (libwayland-client.so.0 + 0xb8ee)
#5  0x7fac879bad58 n/a (libwayland-client.so.0 + 0x6d58)
#6  0x7fac879bb212 wl_proxy_marshal_array_flags 
(libwayland-client.so.0 + 0x7212)
#7  0x7fac879bb421 wl_proxy_marshal_flags 
(libwayland-client.so.0 + 0x7421)
#8  0x7fac87a33b5d 
_ZN15QtWaylandClient17QWaylandShmBufferD2Ev (libQt5WaylandClient.so.5 + 0x6db5d)
#9  0x7fac87a33bed 
_ZN15QtWaylandClient23QWaylandShmBackingStoreD1Ev (libQt5WaylandClient.so.5 + 
0x6dbed)
#10 0x7fac87a33c79 
_ZN15QtWaylandClient23QWaylandShmBackingStoreD0Ev (libQt5WaylandClient.so.5 + 
0x6dc79)
#11 0x7fac89d0da1b _ZN13QBackingStoreD1Ev (libQt5Gui.so.5 + 
0x30da1b)
#12 0x7fac8a38ae3f _ZN14QWidgetPrivate16deleteTLSysExtraEv 
(libQt5Widgets.so.5 + 0x18ae3f)
#13 0x7fac8a3993a0 _ZN7QWidget7destroyEbb 
(libQt5Widgets.so.5 + 0x1993a0)
#14 0x7fac8a3a0772 _ZN7QWidgetD2Ev (libQt5Widgets.so.5 + 
0x1a0772)
#15 0x5570679f6cf1 n/a (kdiff3 + 0x106cf1)
#16 0x7fac88e5c955 __run_exit_handlers (libc.so.6 + 0x3e955)
#17 0x7fac88e5ca8a __GI_exit (libc.so.6 + 0x3ea8a)
#18 0x7fac88e456d1 __libc_start_call_main (libc.so.6 + 
0x276d1)
#19 0x7fac88e45785 __libc_start_main_impl (libc.so.6 + 
0x27785)
#20 0x5570679435b1 n/a (kdiff3 + 0x535b1)
ELF object binary architecture: AMD x86-64
```


Reverting back to version 1.10.4-1 from snapshots.d.o is working
perfect. Thus I concluded that the issue is in particular with the
latest 1.10.5 version.



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages kdiff3 depends on:
ii  kio   5.107.0-1
ii  libc6 2.37-7
ii  libgcc-s1 13.2.0-3
ii  libkf5configcore5 5.107.0-1
ii  libkf5configwidgets5  5.107.0-2
ii  libkf5coreaddons5 5.107.0-1
ii  libkf5crash5  5.107.0-1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5kiocore55.107.0-1
ii  libkf5kiowidgets5 5.107.0-1
ii  libkf5parts5  5.107.0-1
ii  libkf5widgetsaddons5  5.107.0-1
ii  libkf5xmlgui5 5.107.0-1+b1
ii  libqt5core5a  5.15.10+dfsg-3
ii  libqt5gui55.15.10+dfsg-3
ii  libqt5printsupport5   5.15.10+dfsg-3
ii  libqt5widgets55.15.10+dfsg-3
ii  libstdc++613.2.0-3

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.10.5-1

kdiff3 suggests no packages.

-- no debconf information

Bug#1036051: working riscv64 patch

[Ritesh Raj Sarraf]

On Wed, 2023-08-02 at 06:45 +0200, Matthias Klose wrote:
> here is a working patch:
> https://patches.ubuntu.com/b/bpfcc/bpfcc_0.26.0+ds-1ubuntu2.patch
> 
> need to exclude the tools dir as done for other architectures, both
> in 
> debian/rules and debian/control

Thank you. I'll prepare something for Debian Experimental to start
with.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1041192: Recommends: exuberant-ctags, not ctags?

[Ritesh Raj Sarraf]

Control: tag -1 +pending

Hello Joseph,

On Sat, 2023-07-15 at 07:26 -0700, T. Joseph Carter wrote:

> > Package: seascope
> > Version: 0.9+8a669e0e-3
> > Severity: normal
> > 
> > I've noted that seascope Recommends: exuberant-ctags which for the
> > longest time was the only form of ctags in Debian. universal-ctags
> > now
> > exists as an alternative. 

I guess that must be the reason, that exuberant-ctags was the only
available package in Debian for a very long time.

> > Might any ctags be used for seascope or is
> > there a particular reason to prefer exuberant-ctags?

I've never used universal-ctags. But the choice should be provided. If
anything breaks, we'll sooner/later have some bug reports.

I have changed the Recommends to `ctags` instead, which is Provided by
both the packages. It will be part of the next upload.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System




signature.asc
Description: This is a digitally signed message part

Bug#1041154: dput: Extended passive mode entered

[Ritesh Raj Sarraf]

Package: dput
Version: 1.1.3
Severity: important
X-Debbugs-Cc: r...@debian.org

Dear Maintainer,

When trying to upload a package to Debian, I run into the below issue:


```
rrs@priyasi:~/.../uml$ dput user-mode-linux_6.3um1_source.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Checking signature on .changes
gpg: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.changes:
 Valid signature from A63A58A3F2E17569
Checking signature on .dsc
gpg: /home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.dsc: 
Valid signature from A63A58A3F2E17569
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading user-mode-linux_6.3um1.dsc: 229 Extended Passive Mode Entered 
(|||32688|).
14:40 ♒ ॐ ♅ ♄ ⛢  ☹ => 1
```


And when running with the debug mode, I have:


```
rrs@priyasi:~/.../uml$ dput -d user-mode-linux_6.3um1_source.changes
D: Login: rrs
[Errno 2] No such file or directory: '/home/rrs/.config/dput/dput.cf': skipping 
‘/home/rrs/.config/dput/dput.cf’
D: Parsing configuration file ‘/etc/dput.cf’
D: Parsing configuration file ‘/home/rrs/.dput.cf’
D: modules_found: ['ftp', 'http', 'https', 'local', 'rsync', 'scp']
D: Module: ftp ()
D: Method name: ftp
D: Module: http ()
D: Method name: http
D: Module: https ()
D: Method name: https
D: Module: local ()
D: Method name: local
D: Module: rsync ()
D: Method name: rsync
D: Module: scp ()
D: Method name: scp
Trying to upload package to ftp-master (ftp.upload.debian.org)
D: Validating contents of changes file 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.changes
D: Architecture: source
D: dsc-File: user-mode-linux_6.3um1.dsc
D: upload control file: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.changes
D: source control file: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.dsc
Checking signature on .changes
gpg: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.changes:
 Valid signature from A63A58A3F2E17569
Checking signature on .dsc
gpg: /home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.dsc: 
Valid signature from A63A58A3F2E17569
D: Package Version: 6.3um1
D: File to upload: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.dsc
D: Checksum for 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.dsc is fine
D: File to upload: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.tar.xz
D: Checksum for 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.tar.xz is fine
D: File to upload: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.buildinfo
D: Checksum for 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.buildinfo
 is fine
D: Checking: distribution unstable matches (?!UNRELEASED|.*-security)
D: File to upload: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1_source.changes
D: Default Method: ftp
D: Host Method: ftp
D: Login anonymous from section ftp-master used
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
D: FQDN: ftp.upload.debian.org
D: Login: anonymous
D: Incoming: /pub/UploadQueue/
D: FTP port: 21
D: Using passive ftp
D: FTP-Connection to host: ftp.upload.debian.org
D: Directory to upload to: /pub/UploadQueue/
D: Uploading File: 
/home/rrs/NoBackup/Community/Packaging/uml/user-mode-linux_6.3um1.dsc
  Uploading user-mode-linux_6.3um1.dsc: 229 Extended Passive Mode Entered 
(|||41578|).
D: Should exit silently now, but will throw exception for debug.
Traceback (most recent call last):
  File "/usr/bin/dput", line 33, in 
sys.exit(load_entry_point('dput==1.1.3', 'console_scripts', 
'execute-dput')())
 

  File "/usr/share/dput/dput/dput.py", line 1186, in main
upload_methods[method](
  File "/usr/share/dput/dput/methods/ftp.py", line 82, in upload
ftp_connection.storbinary(
  File "/usr/lib/python3.11/ftplib.py", line 498, in storbinary
with self.transfercmd(cmd, rest) as conn:
 ^^^
  File "/usr/lib/python3.11/ftplib.py", line 393, in transfercmd
return self.ntransfercmd(cmd, rest)[0]
   
  File "/usr/lib/python3.11/ftplib.py", line 353, in ntransfercmd
host, port = self.makepasv()
 ^^^
  File "/usr/lib/python3.11/ftplib.py", line 327, in makepasv
untrusted_host, port = parse227(self.sendcmd('PASV'))
   ^^
  File "/usr/lib/python3.11/ftplib.py", line 839, in parse227
raise error_reply(resp)
ftplib.error_reply: 229 Extended Passive Mode Entered (|||41578|).
14:46 ♒ ॐ ♅ ♄ ⛢  ☹ => 1
```



-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = 

Bug#1040402: lcov: mark package as Multi-Arch: foreign

[Ritesh Raj Sarraf]

Package: lcov
Version: 1.16-1
Severity: normal
X-Debbugs-Cc: r...@debian.org

Dear Maintainer,


We have a peculiar problem in a cross-build environment, which reflects
on this package. Thus this bug report, or rather a question.


I am not very very sure if this change has any other side effects
otherwise. Hence, requesting input from you as well.



First, reproduce the problem


Step 1: With a dummy package metadata that depends on lcov

```
rrs@priyasi:.../dummy$ cat debian/control
Source: dummy
Section: misc
Priority: optional
Build-Depends: cmake, lcov, debhelper-compat(= 13), googletest
Standards-Version: 3.9.2

Package: dummy
 Version: 
```

Step 2: Add non-native architecture and try to install
```
rrs@priyasi:.../dummy$ sudo dpkg --add-architecture arm64

rrs@priyasi:.../dummy$ sudo apt update
... snipped ...

rrs@priyasi:.../dummy$ sudo apt build-dep -y -aarm64 .
[sudo] password for rrs:
Note, using directory '.' to get the build dependencies
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:.:arm64 : Depends: lcov:arm64 but it is not installable
E: Unable to correct problems, you have held broken packages.
```


Then, built the `lcov` package with this change `Multi-Arch: foreign` and 
installed on my machine.

```
Package: lcov
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 441
Maintainer: Alastair McKinstry 
Architecture: all
Multi-Arch: foreign
Version: 1.16-1
Depends: perl:any, gcc, libjson-perl, libperlio-gzip-perl
Recommends: libgd-gd2-perl
```


Then, repeat the problem steps again.

```
rrs@priyasi:.../dummy$ sudo apt build-dep -y -aarm64 .
Note, using directory '.' to get the build dependencies
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  googletest
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0 B/506 kB of archives.
After this operation, 3,589 kB of additional disk space will be used.
Retrieving bug reports... 0%^CInterrupted
```


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-security'), (500, 'testing-debug'), (500, 'oldstable-updates'), (500, 
'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages lcov depends on:
ii  gcc  4:12.3.0-1
ii  libjson-perl 4.1-1
ii  libperlio-gzip-perl  0.20-1+b1
ii  perl 5.36.0-7

Versions of packages lcov recommends:
ii  libgd-perl [libgd-gd2-perl]  2.76-4+b1

lcov suggests no packages.

-- no debconf information

Bug#1036915: apt crash in parser

[Ritesh Raj Sarraf]

Package: apt
Version: 2.6.1
Severity: important
X-Debbugs-Cc: r...@debian.org

Dear maintainer,

While trying to rebuild another package from Bookworm, it came a
surprise that `apt` crashed. Below are some details, which should help
you reproduce the crash. Note that the issue is, so far, only seen wile
building the `eckit` package.


```
rrs@priyasi:~/.../eckit (debian/bookworm)$ apt build-dep .
Note, using directory '.' to get the build dependencies
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_create
Aborted (core dumped)
16:37 ♒ ॐ ♅ ♄ ⛢  ☹ => 134

rrs@priyasi:~/.../eckit (debian/bookworm)$ apt -v
apt 2.6.1 (amd64)
16:37 ♒ ॐ ♅ ♄ ⛢ ☺ 
```

Here's the stacktrace:


```
Module libsystemd.so.0 from deb systemd-252.6-1.amd64
Module libudev.so.1 from deb systemd-252.6-1.amd64
Stack trace of thread 158831:
#0  0x7f3b9d2a9ccc __pthread_kill_implementation (libc.so.6 
+ 0x8accc)
#1  0x7f3b9d25aef2 __GI_raise (libc.so.6 + 0x3bef2)
#2  0x7f3b9d245472 __GI_abort (libc.so.6 + 0x26472)
#3  0x7f3b9d49d919 n/a (libstdc++.so.6 + 0x9d919)
#4  0x7f3b9d4a8e1a n/a (libstdc++.so.6 + 0xa8e1a)
#5  0x7f3b9d4a8e85 _ZSt9terminatev (libstdc++.so.6 + 
0xa8e85)
#6  0x7f3b9d4a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8)
#7  0x7f3b9d4a01e9 _ZSt20__throw_length_errorPKc 
(libstdc++.so.6 + 0xa01e9)
#8  0x7f3b9d53f8b9 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm 
(libstdc++.so.6 + 0x13f8b9)
#9  0x7f3b9d8490aa n/a (libapt-pkg.so.6.0 + 0x1000aa)
#10 0x7f3b9d84b3f2 
_ZN13debListParser12ParseDependsEPKcS1_RN3APT10StringViewES4_RjbbbNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 (libapt-pkg.so.6.0 + 0x1023f2)
#11 0x7f3b9d84bde3 
_ZN13debListParser12ParseDependsEPKcS1_RNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_RjRKbSB_SB_RKS7_
 (libapt-pkg.so.6.0 + 0x102de3)
#12 0x7f3b9d86404c n/a (libapt-pkg.so.6.0 + 0x11b04c)
#13 0x7f3b9d99dafe n/a (libapt-private.so.0.0 + 0x59afe)
#14 0x7f3b9d9a1da3 _Z10DoBuildDepR11CommandLine 
(libapt-private.so.0.0 + 0x5dda3)
#15 0x7f3b9d816097 
_ZN11CommandLine11DispatchArgEPKNS_8DispatchEb (libapt-pkg.so.6.0 + 0xcd097)
#16 0x7f3b9d96453e 
_Z19DispatchCommandLineR11CommandLineRKSt6vectorINS_8DispatchESaIS2_EE 
(libapt-private.so.0.0 + 0x2053e)
#17 0x56202509f29f n/a (apt + 0x229f)
#18 0x7f3b9d24618a __libc_start_call_main (libc.so.6 + 
0x2718a)
#19 0x7f3b9d246245 __libc_start_main_impl (libc.so.6 + 
0x27245)
#20 0x56202509f371 n/a (apt + 0x2371)
ELF object binary architecture: AMD x86-64
```

Of particular relevance should be:

```
#10 0x7f3b9d84b3f2 
_ZN13debListParser12ParseDependsEPKcS1_RN3APT10StringViewES4_RjbbbNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 (libapt-pkg.so.6.0 + 0x1023f2)
#11 0x7f3b9d84bde3 
_ZN13debListParser12ParseDependsEPKcS1_RNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_RjRKbSB_SB_RKS7_
 (libapt-pkg.so.6.0 + 0x102de3)
```


The problem seems to be reproducible with the following snippet from `eckit`:

```
Build-Depends: debhelper-compat (= 13),
  dh-buildinfo,
  ecbuild (>= 3.6.1-1~),
  chrpath,
  flex,
  bison,
  libopenblas-dev [ amd64 arm64 armhf i386 mips64el ppc64el s390x ppc64 ],
  libblas-dev [ !amd64 !arm64 !armhf !i386 !mips64el !ppc64el !s390x !ppc64 ],
  liblapack-dev [ !amd64 !arm64 !armhf !i386 !mips64el !ppc64el !s390x !ppc64],
  libaec-dev,
  libxxhash-dev,
  libjemalloc-dev,
  librados-dev [!hurd-i386  !kfreebsd-amd64 !kfreebsd-i386 !riscv64 !sh4 !ia64 
!alpha !hppa !powerpc !mipsel] ,
  libradospp-dev [!hurd-i386  !kfreebsd-amd64 !kfreebsd-i386 !riscv64 !sh4 
!ia64 !alpha !hppa !powerpc !mipsel],
  libbz2-dev,
  liblz4-dev,
  libeigen3-dev,
  libsnappy-dev,
  librsync-dev,
  mpi-default-dev,
  doxygen,
  python3-all,
  libssl-dev,
  libcurl4-gnutls-dev (>=  7.20),
  libncurses-dev
```

If I drop the architecture specific bits from the packages, `apt` then
does not crash. In short, revise the above to:

```
Build-Depends: debhelper-compat (= 13),
  dh-buildinfo,
  ecbuild (>= 3.6.1-1~),
  chrpath,
  flex,
  bison,
  libopenblas-dev,
  libblas-dev,
  liblapack-dev,
  libaec-dev,
  libxxhash-dev,
  libjemalloc-dev,
  librados-dev,
  libradospp-dev,
  libbz2-dev,
  liblz4-dev,
  libeigen3-dev,
  libsnappy-dev,
  librsync-dev,
  mpi-default-dev,
  doxygen,
  python3-all,
  libssl-dev,
  libcurl4-gnutls-dev (>=  7.20),
  libncurses-dev
```



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";

Bug#1033303: mergerfs: Upgrade to v2.34.1 for bookworm

[Ritesh Raj Sarraf]

On Tue, 2023-03-21 at 23:23 +, MK wrote:
> Package: mergerfs
> Version: 2.33.5~debian-bullseye
> Severity: wishlist
> 
> 

Hello. Unfortunately, I don't have the resources to do it soon, withing
the Bookworm release time frame. If I can squeeze time, I'll do it but
it is highly unlikely.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1024690: libnss-unknown: should install NSS service via dh_installnss

[Ritesh Raj Sarraf]

This is now done.

I had some problems getting it uploaded via ftp.

$ dput libnss-unknown_0.0.2-4_source.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Checking signature on .changes
gpg: 
/home/rrs/NoBackup/Community/Packaging/libnss-unknown_0.0.2-4_source.changes: 
Valid signature from A63A58A3F2E17569
Checking signature on .dsc
gpg: /home/rrs/NoBackup/Community/Packaging/libnss-unknown_0.0.2-4.dsc: Valid 
signature from A63A58A3F2E17569
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading libnss-unknown_0.0.2-4.dsc: 229 Extended Passive Mode Entered 
(|||10968|).


But luckily ssh upload worked proper.

$ dput ssh-upload libnss-unknown_0.0.2-4_source.changes
Checking signature on .changes
gpg: 
/home/rrs/NoBackup/Community/Packaging/libnss-unknown_0.0.2-4_source.changes: 
Valid signature from A63A58A3F2E17569
Checking signature on .dsc
gpg: /home/rrs/NoBackup/Community/Packaging/libnss-unknown_0.0.2-4.dsc: Valid 
signature from A63A58A3F2E17569
Uploading to ssh-upload (via scp to ssh.upload.debian.org):
ms: Failure (2) searching keyserver pool.sks-keyservers.net for user id 
'ssh://ssh.upload.debian.org'
The authenticity of host 'ssh.upload.debian.org ()' can't be established.
ED25519 key fingerprint is SHA256:/2BewgKzUVkFOkgYWwf4g6PAwWA6F6xBGHk1Nu5+k00.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ssh.upload.debian.org' (ED25519) to the list of 
known hosts.
libnss-unknown_0.0.2-4.dsc  

100% 1956 5.0KB/s   00:00
libnss-unknown_0.0.2-4.debian.tar.xz

100% 2220 4.4KB/s   00:00
libnss-unknown_0.0.2-4_source.buildinfo 

100% 640113.6KB/s   00:00
libnss-unknown_0.0.2-4_source.changes   

100% 2417 6.3KB/s   00:00
Successfully uploaded packages.

On Wed, 2023-04-12 at 13:26 +0530, Ritesh Raj Sarraf wrote:
> Hello Gioele,
> 
> On Tue, 2023-03-07 at 15:49 +0100, Gioele Barabucci wrote:
> > Dear Ritesh,
> > 
> > a friendly reminder about this bug and the associated patch.
> > 
> > libnss-unknown is the last package in Debian that does not use the 
> > dh_installnss and modifies /etc/nsswitch.conf via maintscripts.
> > 
> > The patch at 
> > https://salsa.debian.org/debian/libnss-unknown/-/merge_requests/4 
> > (refreshed for 0.0.2-3) fixes this issue.
> > 
> > Could you please merge this and upload a new package, so that the 
> > transition to dh_installnss will be completed in time for Bookworm?
> > 
> 
> THank you for the patch. I'll merge it now. Not sure if it'll make
> the
> cut to Bookworm but that can be dealt with separately.
> 
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1024690: libnss-unknown: should install NSS service via dh_installnss

[Ritesh Raj Sarraf]

Hello Gioele,

On Tue, 2023-03-07 at 15:49 +0100, Gioele Barabucci wrote:
> Dear Ritesh,
> 
> a friendly reminder about this bug and the associated patch.
> 
> libnss-unknown is the last package in Debian that does not use the 
> dh_installnss and modifies /etc/nsswitch.conf via maintscripts.
> 
> The patch at 
> https://salsa.debian.org/debian/libnss-unknown/-/merge_requests/4 
> (refreshed for 0.0.2-3) fixes this issue.
> 
> Could you please merge this and upload a new package, so that the 
> transition to dh_installnss will be completed in time for Bookworm?
> 

THank you for the patch. I'll merge it now. Not sure if it'll make the
cut to Bookworm but that can be dealt with separately.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

Also, on my test setup, my LIO target is a standard one. No multinode
cluster. It is a single-node target.

The way I trigger path failovers is by bringing down individual network
interfaces. That serves well enough for my initiator focused tests.


On Thu, 2023-02-23 at 19:14 +0530, Ritesh Raj Sarraf wrote:
> > > > 
> > > > Are you running KVM virtualization atop of your SAN target?
> > > >  
> > > 
> > > My LIO target runs in a KVM guest. So does the iSCSI initiator
> > > too.
> > > 
> > 
> > 
> > Pure KVM or libvirtd too?
> > 
> 
> libvirtd it is. The same hypervisor with libvirtd running, hosts the
> initiator and the target, in different VMs.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

Also, what 10 GiB ethernet do you run on your hypervisor ? What
make/model ? Is that known to work reliably ?

My experience from around some years ago, 10 GiB ethernet support was
still budding. But things may have changed lately. I just don't have
access to those things no more.


On Thu, 2023-02-23 at 19:14 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2023-02-23 at 14:19 +0100, Milan Oravec wrote:
> > > > 
> > > 
> > > By KVM, do you mean just pure KVM ? Or the management suite too,
> > > libvirt ?
> > > 
> > 
> > 
> > Yes, libvirt is used to manage KVM, and virt-manager on my desktop
> > to
> > connect to it. It is simple setup without clustering.  
> > 
> 
> Thanks for confirming.
> 
> You should start with the hypervisor where libvirtd is running. Check
> if that hypervisor host is running normal.
> 
> From all the symptoms you've shared, my wild arrow in the dark is
> that
> your hypervisor/guest network may be running into issues.
> 
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

On Thu, 2023-02-23 at 14:19 +0100, Milan Oravec wrote:
> > > 
> > 
> > By KVM, do you mean just pure KVM ? Or the management suite too,
> > libvirt ?
> > 
> 
> 
> Yes, libvirt is used to manage KVM, and virt-manager on my desktop to
> connect to it. It is simple setup without clustering.  
> 

Thanks for confirming.

You should start with the hypervisor where libvirtd is running. Check
if that hypervisor host is running normal.

From all the symptoms you've shared, my wild arrow in the dark is that
your hypervisor/guest network may be running into issues.

> 
> 
> Do you know someone who can help with this? Here is example of KVM
> guest running configuration:
> 
> libvirt+ 244533      1  5 Feb03 ?        1-03:54:37 qemu-system-
> x86_64 -enable-kvm -name guest=me_test,process=qemu:me_test,debug-
> threads=on -S -object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-
> 108-me_test/master-key.aes -machine pc-1.1,accel=kvm,usb=off,dump-
> guest-core=off -cpu host -m 8096 -realtime mlock=off -smp
> 4,sockets=1,cores=4,threads=1 -uuid 1591f345-96b5-4077-9d32-
> b2991003753d -no-user-config -nodefaults -chardev
> socket,id=charmonitor,fd=57,server,nowait -mon
> chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-
> shutdown -boot strict=on -device piix3-usb-
> uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-
> pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-
> ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-
> ide0-1-0,id=ide0-1-0,bootindex=1 -drive
> file=/dev/mapper/me_test,format=raw,if=none,id=drive-virtio-
> disk0,cache=none,discard=unmap,aio=native -device virtio-blk-
> pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-
> disk0,bootindex=2,write-cache=on -netdev
> tap,fd=60,id=hostnet0,vhost=on,vhostfd=61 -device virtio-net-
> pci,netdev=hostnet0,id=net0,mac=aa:bb:cc:00:10:31,bus=pci.0,addr=0x3
> -chardev pty,id=charserial0 -device isa-
> serial,chardev=charserial0,id=serial0 -chardev
> spicevmc,id=charchannel0,name=vdagent -device
> virtserialport,bus=virtio-
> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice
> .0 -spice port=5929,addr=0.0.0.0,disable-ticketing,seamless-
> migration=on -device qxl-
> vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,v
> gamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device virtio-balloon-
> pci,id=balloon0,bus=pci.0,addr=0x5 -sandbox
> on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=de
> ny -msg timestamp=on
> 
> Maybe there is something undesirable for the iscsi target. 
>  

Seems like you are using host networking ? Have you validated that that
part is working reliably ?

> > 
> > > > There will be errors in your system journal for this particular
> > > > setup.
> > > > 
> > > > Errors like:
> > > > 
> > > > * connection drops
> > > > * iscsi session drops/terminations
> > > > * SCSI errors
> > > > * multipath path checker errors
> > > > 
> > > > All these will be errors which will be recovered eventually.
> > > > That
> > > > is
> > > > why we have the need for close integration in between these
> > > > layers,
> > > > when building a storage solution on top.
> > > > 
> > > 
> > > 
> > > This is very complex ecosystem. I know that error reporting is
> > > good
> > > think :) and helping out to troubleshoot problems. But when
> > > everything is all right there should be no errors, right?
> > >  
> > 
> > In an ideal scenario, yes, there will be no errors. But on a SAN
> > setup,
> > cluster failovers are a feature of the SAN target, and as such
> > during
> > that transition some errors are expected on the initiator, which
> > are
> > eventually recovered.
> > 
> > Recovery is the critical part here. When states do not recover to
> > normal, it is an error; either the target or the initiator. Or even
> > the
> > middleman (network) at times.
> > 
> 
> 
> This part seems to work OK, so far no data loss was detected.
>  

From your initial logs, mpath reported 'io pending' on one of the
paths. I'm not sure if I'd call that fully recovered.

What if you down the other (healthy) path ? Does IO progress on the
initial (io pending) path ?

> > > 
> > > Are you running KVM virtualization atop of your SAN target?
> > >  
> > 
> > My LIO target runs in a KVM guest. So does the iSCSI initiator too.
> > 
> 
> 
> Pure KVM or libvirtd too?
> 

libvirtd it is. The same hypervisor with libvirtd running, hosts the
initiator and the target, in different VMs.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

Hello Milan,

On Mon, 2023-02-20 at 09:51 +0100, Milan Oravec wrote:
> > >  
> > 
> > So did you trigger a cluster takeover ? My guess is it is your
> > target
> > initiating the connection drops, while taking over to the other
> > node.
> > 
> > 
> 
> 
> There was no intentional cluster takeover. This happens during normal
> operation. 
>  
> > How a target behaves during the transition is left to the target.
> > The
> > initiator will keep querying for recovery, until either it times
> > out or
> > recovers.
> > 
> 
> 
> recovery seems to work fine. I've tested it by disconnecting one path
> to target and all was OK, second path was used and when first one
> recovered is switched to that one over. 
>  


> > 
> > > > > 
> 
> I can understand this is very complex problem, what do you suggest me
> to debug this issues? We have 5 host connected to Fujitsu target, but
> errors are only on those two which are running KVM guests. Other
> servers running mail hosts and camera surveillance are not affected
> it seems. They are Debian systems but not running multipath, so I've
> made test:
> 
> So far I've disabled all KVM guests on one (of those two KVM hosts
> used fro virtualization) host and mounted  one KVM guest file system
> locally (/mnt) and performed stress test on that mount:
> 

By KVM, do you mean just pure KVM ? Or the management suite too,
libvirt ?


> 
> When I let run one KVM guest (Debian) on this host system following
> errors are in dmesg:
> 
> [Mon Feb 20 09:49:39 2023]  connection1:0: pdu (op 0x5 itt 0x53)
> rejected. Reason code 0x9
> [Mon Feb 20 09:49:41 2023]  connection1:0: pdu (op 0x5 itt 0x7c)
> rejected. Reason code 0x9
> [Mon Feb 20 09:49:41 2023]  connection1:0: pdu (op 0x5 itt 0x51)
> rejected. Reason code 0x9
> [Mon Feb 20 09:50:07 2023]  connection1:0: pdu (op 0x5 itt 0x33)
> rejected. Reason code 0x9
> 
> Guest is using Virtio disk drivers (vda) so I've switched it to
> generic SATA (sda) for this guest, but errors in log remains.
> 
> It seem that KVM is triggering this errors and make our NAS unstable.
> 
> What can KVM do differently? It is using /dev/mapper/dm-XX as disk
> devices so no direct iscsi access. 
> 
> Any ideas what should I try next? 
> 
> 

I'm afraid I do not have much direct hints for you here. given that
this issue does not happen when KVM is not involved, would imply that
the erratic behavior originates from that software's integration.


> > There will be errors in your system journal for this particular
> > setup.
> > 
> > Errors like:
> > 
> > * connection drops
> > * iscsi session drops/terminations
> > * SCSI errors
> > * multipath path checker errors
> > 
> > All these will be errors which will be recovered eventually. That
> > is
> > why we have the need for close integration in between these layers,
> > when building a storage solution on top.
> > 
> 
> 
> This is very complex ecosystem. I know that error reporting is good
> think :) and helping out to troubleshoot problems. But when
> everything is all right there should be no errors, right?
>  

In an ideal scenario, yes, there will be no errors. But on a SAN setup,
cluster failovers are a feature of the SAN target, and as such during
that transition some errors are expected on the initiator, which are
eventually recovered.

Recovery is the critical part here. When states do not recover to
normal, it is an error; either the target or the initiator. Or even the
middleman (network) at times.

> > 
> > 
> > 
> > Note: These days I only have a software LIO target to test/play
> > with,
> > where I have not seen any real issues/errors. How each SAN Target
> > behaves is something highly specific to the target, in your case
> > the
> > Fujitsu target.
> > 
> > 
> 
> 
> Are you running KVM virtualization atop of your SAN target?
>  

My LIO target runs in a KVM guest. So does the iSCSI initiator too.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

 > > alua' wp=rw
> > > `-+- policy='service-time 0' prio=10 status=active
> > >   |- 1:0:0:16 sdah 66:16  active i/o pending running
> > >   `- 2:0:0:16 sdai 66:32  active ready running
> > > ais_app (360e00d2c002c1772001f) dm-99
> > > FUJITSU,ETERNUS_DXL
> > > size=500G features='3 queue_if_no_path queue_mode mq'
> > > hwhandler='1
> > > alua' wp=rw
> > > `-+- policy='service-time 0' prio=10 status=active
> > >   |- 1:0:0:28 sdbh 67:176 active i/o pending running
> > >   `- 2:0:0:28 sdbf 67:144 active ready running
> > > 
> > 
> > Looks all correct to me. You already are using feature
> > queue_if_no_path
> > 
> > > SAN consists of one Fujitsu DX100 S4 storage with two controllers
> > > connected to LAN switch with two 10Gb fibre links (one from
> > > controller), each link has its own VLAN configured. Errors
> > > reported
> > > ocures on virtualization host that are connected mutipath with
> > > two
> > > 10Gb fibre links to respective VLANs. Jumbo frames are enabled
> > > across
> > > the way.
> > > 
> > 
> > Good. As I expected, you do have a 2 node target controller setup.
> > 
> > > I'll add all neded info upun request.
> > > 
> > > I've consulted this issue with Fujitsu representative and it
> > > seems we
> > > have all configured right and he advised me to contact Debian
> > > support. So I'm here and would kindly ask to point me the right
> > > direction. 
> > > 
> > 
> > Okay!! What behavior do you expect ? What anomaly do you see with
> > the
> > iSCSI initiator in Debian ?
> > 
> 
>  
> I expect no errors in logs and drop out free communication with
> target.  I think this is not normal/standard behaviour. 
> 
> 

There will be errors in your system journal for this particular setup.

Errors like:

* connection drops
* iscsi session drops/terminations
* SCSI errors
* multipath path checker errors

All these will be errors which will be recovered eventually. That is
why we have the need for close integration in between these layers,
when building a storage solution on top.



Note: These days I only have a software LIO target to test/play with,
where I have not seen any real issues/errors. How each SAN Target
behaves is something highly specific to the target, in your case the
Fujitsu target.



-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Ritesh Raj Sarraf]

On Tue, 2023-02-14 at 14:35 +0100, Petter Reinholdtsen wrote:
> Will it be hard to test if the result work during build and reject
> the
> architecure based on build failure instead of a fixed list of
> architectures.

Getting it to build is one part, making it behave reliably is comes
immediate next.

Then, there's also the inclusion/exclusion every release, based on
build status.

I chose to stick with the fixed architecture list because:

* Real life is progressing, as in I now have lesser volunteer time
* I don't want to commit when I know I don't have a lot of
time/experience on the subject.


All that said, Debian is about fun. And Experimental is for this very
same purpose. I will make an upload to Experimental soon, as I
expressed the intent earlier. And let it soak there for a couple of
(upstream) release cycles.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Ritesh Raj Sarraf]

On Tue, 2023-02-14 at 13:22 +0100, Petter Reinholdtsen wrote:
> > I don't recollect if the list of supported architecture is
> > mentioned
> > somewhere, but I restricted the build to some of the 64 Bit
> > architectures only, because of the lack of upstream support.
> 
> OK.  What do 'upstream support' mean here, and did they list
> supported
> platforms anywhere?

By 'upstream support', I meant based on random conversations I had with
them years ago.

So, for curiosity, I did a quick check on where packaging in general
stands.

We have:

* https://koji.fedoraproject.org/koji/buildinfo?buildID=1880777
* https://src.fedoraproject.org/rpms/bcc/blob/rawhide/f/bcc.spec
* https://github.com/iovisor/bcc/issues/2678
* https://repo.iovisor.org/yum/
* https://repo.iovisor.org/apt/
 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

 you do have a 2 node target controller setup.

> I'll add all neded info upun request.
> 
> I've consulted this issue with Fujitsu representative and it seems we
> have all configured right and he advised me to contact Debian
> support. So I'm here and would kindly ask to point me the right
> direction. 
> 

Okay!! What behavior do you expect ? What anomaly do you see with the
iSCSI initiator in Debian ?

> 
> 
> -- System Information:
> Debian Release: 11.6
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-21-amd64 (SMP w/256 CPU threads)
> Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages open-iscsi depends on:
> ii  debconf [debconf-2.0]  1.5.77
> ii  libc6  2.31-13+deb11u5
> ii  libisns0   0.100-3
> ii  libkmod2   28-1
> ii  libmount1  2.36.1-8+deb11u1
> ii  libopeniscsiusr    2.1.3-5
> ii  libssl1.1  1.1.1n-0+deb11u4
> ii  libsystemd0    247.3-7+deb11u1
> ii  udev   247.3-7+deb11u1
> 
> open-iscsi recommends no packages.
> 
> open-iscsi suggests no packages.
> 
> -- Configuration Files:
> /etc/iscsi/iscsid.conf [Errno 13] Permission denied:
> '/etc/iscsi/iscsid.conf'
> 
> -- debconf information:
>   open-iscsi/upgrade_even_with_failed_sessions:
>   open-iscsi/downgrade_and_break_system:
>   open-iscsi/upgrade_recovery_error:
>   open-iscsi/remove_even_with_active_sessions:
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Ritesh Raj Sarraf]

Hello Petter

On Mon, 2023-02-06 at 08:20 +0100, Petter Reinholdtsen wrote:
> Because of issues with the opensnitch build and test, I noticed the
> Debian buildds only build bpfcc on a limited set of architectures. 
> Is
> it written down somewhere why so few of the Debian architectures are
> listed as working with bpfcc?  Any chance to increase the list to all
> supported Debian architectures?

I don't recollect if the list of supported architecture is mentioned
somewhere, but I restricted the build to some of the 64 Bit
architectures only, because of the lack of upstream support.

I personally enabled bpfcc on some extra (64 bit) architectures back
then but learnt that the upstream support is only focused on x86.
Things may have changed lately as I am not on top of the bpfcc
development upstream.


I would love to extend the architecture support. If you already have
changes that enable additional architectures, an MR will be
appreciated. Preferably, first we should let it soak/reside, for 1-2
upstream releases, under Debian Experimental.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1030478: cannot uninstall open-iscsi package

[Ritesh Raj Sarraf]

After this operation, 1,457 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 469492 files and directories currently installed.)
Removing open-iscsi (2.1.8-1) ...
Warning: Stopping iscsid.service, but it can still be activated by:
  iscsid.socket
Processing triggers for man-db (2.11.2-1) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.1.0-4-amd64
(Reading database ... 469455 files and directories currently installed.)
Purging configuration files for open-iscsi (2.1.8-1) ...

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1028479: bpfcc-tools: insecure use of /tmp

[Ritesh Raj Sarraf]

cture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-1-amd64 (SMP w/1 CPU thread; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=pl_PL.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 bpfcc-tools depends on:
> ii  python3  3.11.1-1
> ii  python3-bpfcc    0.25.0+ds-1
> ii  python3-netaddr  0.8.0-2
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1027833: user-mode-linux: hostfs directory traversal

[Ritesh Raj Sarraf]

Hello Jakub,

On Wed, 2023-01-11 at 18:39 +0100, Jakub Wilk wrote:
> * Ritesh Raj Sarraf , 2023-01-10 18:43:
> > > The man page says that hostfs kernel param is "used to confine
> > > all 
> > > hostfs mounts to within the specified directory tree on the
> > > host". But 
> > > it's trivial to escape this confinements with ../ sequences:
> > > 
> > >    # mount none -t hostfs -o
> > > ../../../../../../../../home/bob/secrets /mnt
> > 
> > Could you please share the kernel command line option passed to the
> > running uml instance ?
> 
> I used with something like this:
> 
>     $ linux hostfs=/srv/chroots/unstable-i386/ rootfstype=hostfs
> init=/bin/sh quiet
> 


I think the manpage is misleading. Note that the manpage was especially
prepared for Debian and was last touched many years ago. I only looked
for its correctness now, now that you reported of it.

The current upstream documentation does warn about the functionality,
and does not advertise anything about confining the namespace.

I will try to fix it in time for Bookworm. Otherwise patches welcome.

The latest up-to-date documentation is available in the kernel sources
at: Documentation/virt/uml/user_mode_linux_howto_v2.rst

To quote from the documentation:

Host file access
==

If you want to access files on the host machine from inside UML, you
can treat it as a separate machine and either nfs mount directories
from the host or copy files into the virtual machine with scp.
However, since UML is running on the host, it can access those
files just like any other process and make them available inside the
virtual machine without the need to use the network.
This is possible with the hostfs virtual filesystem.  With it, you
can mount a host directory into the UML filesystem and access the
files contained in it just as you would on the host.

*SECURITY WARNING*

Hostfs without any parameters to the UML Image will allow the image
to mount any part of the host filesystem and write to it. Always
confine hostfs to a specific "harmless" directory (for example ``/var/tmp``)
if running UML. This is especially important if UML is being run as root.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1027833: user-mode-linux: hostfs directory traversal

[Ritesh Raj Sarraf]

Hello Jakub,

On Tue, 2023-01-03 at 22:28 +0100, Jakub Wilk wrote:
> The man page says that hostfs kernel param is "used to confine all 
> hostfs mounts to within the specified directory tree on the host".
> But 
> it's trivial to escape this confinements with ../ sequences:
> 
>    # mount none -t hostfs -o ../../../../../../../../home/bob/secrets
> /mnt
> 

Could you please share the kernel command line option passed to the
running uml instance ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1022742: multipath-tools: CVE-2022-41973 CVE-2022-41974

[Ritesh Raj Sarraf]

I won't be able to attend to it in time, for personal reasons. Let's hope
somebody beats me before I'm back

s3nt fr0m a $martph0ne, excuse typ0s

On Tue, Oct 25, 2022, 01:51 Salvatore Bonaccorso  wrote:

> Source: multipath-tools
> Version: 0.9.0-4
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> t...@security.debian.org>
> Control: found -1 0.7.9-3
>
> Hi,
>
> The following vulnerabilities were published for multipath-tools.
>
> CVE-2022-41973[0]:
> | Symlink attack
>
> CVE-2022-41974[1]:
> | Authorization bypass
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2022-41973
> https://www.cve.org/CVERecord?id=CVE-2022-41973
> [1] https://security-tracker.debian.org/tracker/CVE-2022-41974
> https://www.cve.org/CVERecord?id=CVE-2022-41974
> [2] https://www.openwall.com/lists/oss-security/2022/10/24/2
>
> Regards,
> Salvatore
>
>

Bug#1021180: usrmerge may break user-mode-linux rootfs

[Ritesh Raj Sarraf]

Hello Marco,

On Mon, 2022-10-03 at 16:09 +0200, Marco d'Itri wrote:
> On Oct 03, Ritesh Raj Sarraf  wrote:
> 
> > Now, going forward, I can manually fix it by mounting to
> > /usr/lib/modules and arranging the symlink to the old location in
> > the
> > guest, something that usrmerge is trying to do.
> Actually I think that it is much easier:
> - unmount /usr/lib/modules
> - complete the installation of usrmerge
> - reboot
> 
> Can you confirm that after doing this everything will work as
> expected?
> 

There was nothing mounted onto /usr/lib/modules before. Instead, all
this time it was mounted on /lib/modules/ just like on the host. I
think it failed because usrmerge script was invoking mv command while
/lib/modules was independently mounted 'read-only'

After facing this error, I switched the fstab to /usr/lib/modules and
rebooted. I first rebooted because unmounting /lib/modules was not
possible as it was held by the linux process.

After the reboot, re-running the usrmerge script worked proper. 

> What is the canonical way to detect UML?

systemd does it nicely with:

root@uml:~# systemd-detect-virt 
uml
root@uml:~# 

> I am not sure if we want to unmount/remount stuff, but at least (and
> at 
> least as a first step) the conversion program can bail out gracefully
> and explain what to do.

Yes. Some careful instructions targeting novice users. I was able to
quickly work it out but something simple for general users would be
nice.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1021180: usrmerge may break user-mode-linux rootfs

[Ritesh Raj Sarraf]

Package: usrmerge
Version: 31
Severity: normal
X-Debbugs-Cc: r...@debian.org


Hello,

I'm just filing it as a report here as I'm not sure if this qualifies as
a valida bug. Nevertheless it does break the user's system.


```
Setting up perl (5.34.0-5) ...
Setting up libfile-find-rule-perl (0.34-2) ...
Selecting previously unselected package usrmerge.
(Reading database ... 22180 files and directories currently installed.)
Preparing to unpack .../archives/usrmerge_32_all.deb ...
Unpacking usrmerge (32) ...
Setting up usrmerge (32) ...
sched: RT throttling activated
mv: cannot move '/lib/modules' to '/usr/lib/modules': Device or resource busy

FATAL ERROR:
mv --no-clobber /lib/modules /usr/lib/modules: rc=1

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)
```

The below occurred inside a Debian Unstable rootfs running
user-mode-linux.

And the reason this fails is because:

```
root@uml:~# cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
hostfs  /lib/moduleshostfs  /usr/lib/uml/modules0   0
hostfs  /var/tmp/Debian-Build/containershostfs  
/var/tmp/Debian-Build/containers0   0
/swapfile   swapswapdefaults0   0
/dev/ubda   /   ext4discard,errors=remount-ro   0   1
```


The uml kernel is a modular kernel. The bare boot is built as the
monolithic kernel and everything else as modules, which are then mounted
from the host to the UML guest.

Now, going forward, I can manually fix it by mounting to
/usr/lib/modules and arranging the symlink to the old location in the
guest, something that usrmerge is trying to do.

But I report it here only to keep parties aware and if/whether they have
a better detection and handling of this scenario.



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.34.0-5

usrmerge recommends no packages.

usrmerge suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = (unset),
LC_TIME = "en_IO.UTF-8",
LANG = "en_IN.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_IN.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#1010307: user-mode-linux: FTBFS in bookworm as it Build-Depends on removed linux-source-5.16"

[Ritesh Raj Sarraf]

Control: tag -1 done

On Thu, 2022-04-28 at 16:52 +0200, Paul Gevers wrote:
> Recently your package showed up there because it Build-Depends on
> linux-source-5.16 which has been removed from bookworm. Versioned
> linux packages are moving targets. Are you aware of the unversioned
> linux-source instead, such that you don't need to update the BD every
> time the linux kernel updates?

This was uploaded this week on Monday.

Thank you for mentioning about the linux-source package. I wasn't aware
of it. I'll try to see if that fits the build requirements.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1008811: Won't start without python3-dbus (misses dependency)

[Ritesh Raj Sarraf]

Control: tag -1 pending

On Sat, 2022-04-02 at 00:55 +0200, Daniel Leidert wrote:
> Package: snapper-gui
> Version: 0git.960a94834f-3.1
> Severity: serious
> 
> snapper-gui doesn't start without python3-dbus:

Thank you for reporting this bug. It has been committed in the
packaging repository and will be part of the next upload.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1003366: Processed: Re: Bug#1007838: d-i.debian.org: Installer iSCSI does not work in Debian 11

[Ritesh Raj Sarraf]

Hello,

On Fri, 2022-03-18 at 11:10 +0100, Cyril Brulebois wrote:
> Thanks Eugene,
> 
> Eugene Losowski-Gallagher 
> (2022-03-18):
> > This looks like a duplicate of:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003366
> > Same issue (but with more diagnostics).
> 
> Since one isn't supposed to be using iscsid within the installer, I'd
> suggest dropping it from the udeb entirely, so that people don't
> waste
> time trying to start a daemon that's not supposed to be started
> there?
> 

I agree. 

My recommended setup for `root on iscsi` is documented in the
README.Debian.

> Alternatively, if that daemon can still be useful within the
> installer,
> I can look into implementing a double build for open-iscsi, building
> with systemd support for the main binary, and without it for the udeb
> binary.
> 
> 

It could certainly be integrated into the installer in some form. But
the setup has to be carefully stacked. And there will be multiple
configuration scenarios (sw iscsi, hw iscsi, offload, multipath etc)
that need to be tested in multiple combinations.

Lately, I haven't had the volunteer time that I once had, to commit to
these packages. So any help in implementing, testing and maintaining
these features is welcome.

> In any cases, that's a bit of a side quest, and the real issue is why
> the regular installer tools aren't able to set up iSCSI storage. :)
> (And that part I'm not familiar enough at this stage to be able to
> debug.)

I haven't checked this particular case. But, in general, you didn't
much need to run the daemon in the installer. You just discover, and
then establish the connecitons to the target and be done, for the part
of the installer.

On real boot, when init fires up iscsid daemon, it'll take over those
connections and do the necessary housekeeping thenceforth.

This is all around 8 years old setup knowledge across distributions.
Not sure what the current approach is.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1005900: linux.uml: uml_mconsole client becomes blocked on read after issuing commands stop and go

[Ritesh Raj Sarraf]

Hello Mihai,

In this case, it is good to have the User Mode Linux upstream in the
loop.

Thanks,
Ritesh

--- linux-source-5.16/arch/um/drivers/mconsole_kern.c   2022-02-05 
20:22:06.0 +0200
+++ linux-source-5.16.fix/arch/um/drivers/mconsole_kern.c   2022-02-16 
23:35:39.562668086 +0200
@@ -224,6 +224,7 @@
 
 void mconsole_stop(struct mc_request *req)
 {
+   int err;
deactivate_fd(req->originating_fd, MCONSOLE_IRQ);
os_set_fd_block(req->originating_fd, 1);
mconsole_reply(req, "stopped", 0, 0);
@@ -247,6 +248,11 @@
}
os_set_fd_block(req->originating_fd, 0);
mconsole_reply(req, "", 0, 0);
+   err=activate_fd(MCONSOLE_IRQ, req->originating_fd, IRQ_READ,
+   (void*)(req->originating_fd), NULL);
+   if (err)
+ mconsole_reply(req, "Failed to reactivate MCONSOLE_IRQ, \
+   this will block the read for uml_mconsole", 1, 0);
 }
 
 static DEFINE_SPINLOCK(mc_devices_lock);
--- linux-source-5.16/arch/um/kernel/irq.c  2022-02-05 20:22:06.0 
+0200
+++ linux-source-5.16.fix/arch/um/kernel/irq.c  2022-02-16 23:39:15.650279367 
+0200
@@ -249,7 +249,7 @@
free_irq_entry(entry, false);
 }
 
-static int activate_fd(int irq, int fd, enum um_irq_type type, void *dev_id,
+int activate_fd(int irq, int fd, enum um_irq_type type, void *dev_id,
   void (*timetravel_handler)(int, int, void *,
  struct time_travel_event *))
 {
@@ -304,6 +304,7 @@
 out:
return err;
 }
+EXPORT_SYMBOL(activate_fd);
 
 /*
  * Remove the entry or entries for a specific FD, if you
--- linux-source-5.16/arch/um/include/shared/irq_user.h 2022-02-05 
20:22:06.0 +0200
+++ linux-source-5.16.fix/arch/um/include/shared/irq_user.h 2022-02-16 
23:39:09.642292312 +0200
@@ -19,6 +19,7 @@
 void sigio_run_timetravel_handlers(void);
 extern void free_irq_by_fd(int fd);
 extern void deactivate_fd(int fd, int irqnum);
+extern int activate_fd(int irq, int fd, enum um_irq_type type, void *dev_id, 
void (*timetravel_handler)(int, int, void *, struct time_travel_event *));
 extern int deactivate_all_fds(void);
 extern int activate_ipi(int fd, int pid);

On Thu, 2022-02-17 at 01:06 +0200, Mihai Hanor wrote:
> Package: user-mode-linux
> Version: 5.16um1
> Severity: normal
> File: /usr/bin/linux.uml
> X-Debbugs-Cc: quake2i...@gmail.com
> 
> Dear Maintainer,
> 
> * What is the problem:
> Issuing the commands stop followed by go, at the input of the
> uml_mconsole
> client, results in the client becoming blocked on read socket. This
> is because
> of logic in arch/um/drivers/mconsole_kern.c, where mconsole_stop()
> doesn't
> reactivate the MCONSOLE_IRQ before the function has exited.
> 
> I've managed to find a fix which seems to be working, but I don't
> know if it's
> a proper fix. Please see the attached file.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (1, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages user-mode-linux depends on:
> ii  libc6  2.33-5
> 
> Versions of packages user-mode-linux recommends:
> ii  uml-utilities  20070815.4-1
> 
> Versions of packages user-mode-linux suggests:
> ii  mate-terminal [x-terminal-emulator]  1.26.0-1
> ii  pterm [x-terminal-emulator]          0.76-2
> pn  rootstrap                            
> pn  slirp                                
> pn  user-mode-linux-doc                  
> pn  vde2                                 
> 
> -- no debconf information

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

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

[Ritesh Raj Sarraf]

IIRC, this is intentional. d-i doesn't provide libsystemd in the
installer environment.

In the installer environment, one is supposed to use iscsistart binary.


On Sat, 2022-01-08 at 23:29 +, Eugene wrote:
> 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

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[Ritesh Raj Sarraf]

e processing.
> ADDITIONAL INFORMATION: you can consult the additional and detailed
> information about our privacy policy
> DATA PROTECTION OFFICER (DPO): Miguel Angel Muñoz +34 93 470 30
> 00 dpo_econocom...@econocom.com 
> CONFIDENTIALITY: If you received this email in error, please
> immediately contact us and destroy the material in its entirety,
> whether in electronic or hard copy format. If you are not the
> intended recipient, you are hereby notified that any disclosure,
> copying, distribution, or use of the information contained herein
> (including any reliance thereon) is strictly prohibited, on his/her
> own responsibility.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[Ritesh Raj Sarraf]

Control: tag -1 +pending

Thanks for confirming Carlos. The following has been added and will be
part of the next upload.


commit 00b79442b9af0c5275880b73b9bae5c68150e2c5 (HEAD -> master)
Author: Ritesh Raj Sarraf 
Date:   Mon Dec 20 15:29:43 2021 +0530

Add some documentation about LVM + DM-Multipath setup

Thanks: Carlos Barros
Closes: 1001710

diff --git a/debian/multipath-tools.README.Debian 
b/debian/multipath-tools.README.Debian
index 257eebdb..ec1dee40 100644
--- a/debian/multipath-tools.README.Debian
+++ b/debian/multipath-tools.README.Debian
@@ -1,6 +1,24 @@
 Additional information for users of multipath-tools from Debian.
 
 
+LVM over DM-Multipath
+=
+
+Debigu Bug #1001710
+
+On a setup that involves both, LVM and DM-Multipath, it is important to set the
+right filter in lvm.conf file to ensure that LVM does not acquire the bare 
SCSI devices
+before DM-Multipath can.
+
+On such combined setups, the standard recommendation is to pvcreate devices on 
the 
+enumerated multipathed devices. And also ensure that the bare SCSI devices are 
filtered out
+from LVM's list
+
+   # filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", 
"r|/sd[b-z].*|", "a|.*|" ]
+
+In the above example snippet, it is ensured that LVM filters out any SCSI 
devices of name type
+sd[b-z].*
+
 


On Fri, 2021-12-17 at 21:59 +, BARROS FERNANDEZ, Carlos wrote:
> Hello Ritesh.
> 
> Thanks for your answer.
> 
> Tried serveral things to make it work, but only a filter in lvm.conf
> did work. (the pv's were created under multipath, and also did
> several vgcfgbackup, the pv's did not have any /dev/sd?? written in
> their sectors)
> The filter that I put is:
> filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", "r|/sd[b-
> z].*|", "a|.*|" ]
> 
> I had to put sd[b-z].* because the system in installed in lvm too, so
> I had to exclude that device. Maybe there is a better filter, but I
> do not know how to write it.
> 
> The server uses a RAID controller for internal disks and hba for the
> external disks
> 
> Right now, it seems stable between reboots, I hope that the raid
> controller will always setup before the hba, otherwise the filter
> won't work. 
> 
> I think that this info can be of help to other users, could you put a
> README.debian including this filter? (or modify the lvm.conf to add
> the note)
> Like:
> To setup LVM over multipath, and allow other LVM over a non
> multpathed device, if you encounter that the pv-devices are not
> under 
> multipath control, try this filter line in lvm.conf, update-initrd
> and reboot. to check it that it works ok.
> 
>        filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|",
> "r|/sd[b-z].*|", "a|.*|" ]
>   sd[b-z].* makes all /dev/sd* be skipped but /dev/sda.
> Adjust for your hardware configuration.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[Ritesh Raj Sarraf]

Hello Carlos,

On Tue, 2021-12-14 at 19:04 +0100, Carlos Barros wrote:
> A server was setup with some disks configured in multipath.
> The root filesystem is on LVM on internal disk, not configured for
> multipath.
> 
> Then build another lvm configuration on those devices
> (/dev/mapper/...)
> 
> Now, every time it starts, lvm takes the /dev/sd.. before multipath
> sets /dev/mapper/...  up.


This combination of the setup, where you have Multipath + LVM, is a
known working config.

There are some special tweaks needed though. I don't recollect the
exact specifics but basically there might be 2 things.

1. You need to ensure that you run pvcreate on top of the multipathed
devices and NOT on the bare SCSI devices.

2. THere's also a filter in /etc/lvm/ where you define the list of SCSI
devices that should be blacklisted from LVM.

> Also, the booting proccess delays for 2+  minutes, mostly because of
> systemd-udev-settle.service:
> root@panblando:~# systemd-analyze blame
>  2min 22ms systemd-udev-settle.service
> 1min 105ms NetworkManager-wait-online.service
>     9.983s smartmontools.service
>     4.415s dev-mapper-dl380g8\x2d\x2dvg\x2droot.device
> 
> But this service is called from multipath:
> [Unit]
> Description=Device-Mapper Multipath Device Controller
> Wants=systemd-udev-trigger.service systemd-udev-
> settle.service
> Before=iscsi.service iscsid.service lvm2-activation-
> early.service
> Before=local-fs-pre.target blk-availability.service
> After=multipathd.socket systemd-udev-trigger.service systemd-
> udev-settle.service
> DefaultDependencies=no
> Conflicts=shutdown.target
> ConditionKernelCommandLine=!nompath
> ConditionKernelCommandLine=!multipath=off
> 
> According to systemd-udev-settle.service(8) it is not recommended, as
> that service can fail (in fact, 
> in the server it fails as systemd says) 
> 

I don't recollect the specifics but iirc that service is required for a
reason. Remember that, typically, multipath-tools is used in
combination with SAN devices which are remote.

> I think that the problem is related to multipath, because it did not
> setup the devices before lvm, 
> and maybe the problem is inside the initrd.
> 

Please explore the suggestions I mentioned above. I am fairly sure that
it may just be a case of proper blacklisting.

> Then I did install multipath-tools-boot but the problem is the same.
> The only way is to avoid mounting the filesystems in the LVM (or
> umounting them) vgchange -an VG 
> and do the multipath and mount it, all by hand
> 
Yes. THis is expected behavior. mutliapth can only acquire the device
when it is free.



-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1001261: rclone: new upstream release 1.57.0

[Ritesh Raj Sarraf]

Package: rclone
Version: 1.53.3-2
Severity: wishlist
X-Debbugs-Cc: r...@debian.org

Dear Maintainer,

While the cause is not directly related to rclone but the current
version fails to sync data from Google, which is now fixed in version
1.56+

https://github.com/rclone/rclone/issues/5455

May I request if it is possible to update to the latest upstream
release ?


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rclone depends on:
ii  libc6  2.32-4

rclone recommends no packages.

rclone suggests no packages.

-- no debconf information

Bug#1000495: openssh: drop the advertisement clause in BSD license

[Ritesh Raj Sarraf]

Control: forward -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3368

On Wed, 2021-11-24 at 22:16 +, Colin Watson wrote:
> Regardless of what permission Niels has given, I can't unilaterally
> change it in Debian's OpenSSH packaging; it needs to be updated
> upstream
> first.  Please file a bug at bugzilla.mindrot.org about this and mark
> this bug as forwarded (I don't think it makes sense for me to be in
> the
> middle here).

Thank you Colin. I have filed a bug upstream and appropriately set this
one as forwarded.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#1000495: openssh: drop the advertisement clause in BSD license

[Ritesh Raj Sarraf]

Source: openssh
Version: 1:8.4p1-5
Severity: minor
X-Debbugs-Cc: r...@debian.org

Dear Maintainer,

Niels gave his explicit permission to drop clause 3, the "advertising" clause, 
from his code.
This restores the GPL compatibility.

Request if the same can be updated in this package.

References:
* https://github.com/pyca/bcrypt/pull/170
* 
https://github.com/pyca/bcrypt/files/3081054/Blowfish-cypher-license-change.pdf



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1000373: libssh2: drop the advertisement clause in BSD license

[Ritesh Raj Sarraf]

Source: libssh2
Version: 1.10.0-2
Severity: minor
X-Debbugs-Cc: r...@debian.org

Dear Maintainer,

Niels gave his explicit permission to drop clause 3, the "advertising" clause, 
from his code.
This restores the GPL compatibility.

Request if the same can be updated in this package.

References:
* https://github.com/pyca/bcrypt/pull/170
* 
https://github.com/pyca/bcrypt/files/3081054/Blowfish-cypher-license-change.pdf



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#999548: conmon: address already in use

[Ritesh Raj Sarraf]

On Fri, 2021-11-12 at 15:50 +0530, Ritesh Raj Sarraf wrote:
> Hello,
> 
> I think the current version of conmon in Debian is plauged with this
> upstream bug: https://github.com/containers/podman/issues/9447 
> 
> 

But there may be more to this bug.
See:
https://github.com/containers/podman/issues/9447#issuecomment-800829725

As a quick test, I built version 2.0.30 but still run into the same
problem.

> 
> ```
> rrs@lenovo:$ ./testing-pp.sh 
> DOCKER_HOST is: unix:/run/user/1000/podman/podman.sock
> ./testing-pp.sh called with no arg: using default up
> Creating network "testing-photoprism_default" with the default driver
> Creating testing-photoprism-scheduler    ... done
> Creating testing-photoprism_mariadb_1    ... done
> Creating testing-photoprism_photoprism_1 ... error
> 
> ERROR: for testing-photoprism_photoprism_1  port reloading failed:
> rootless port failed to add port: listen tcp 0.0.0.0:2343: bind:
> address
> already in use
> 
> ERROR: for photoprism  port reloading failed: rootless port failed to
> add port: listen tcp 0.0.0.0:2343: bind: address already in use
> ERROR: Encountered errors while bringing up the project.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#999548: conmon: address already in use

[Ritesh Raj Sarraf]

Package: conmon
Version: 2.0.25+ds1-1.1
Severity: important

Hello,

I think the current version of conmon in Debian is plauged with this
upstream bug: https://github.com/containers/podman/issues/9447 



```
rrs@lenovo:$ ./testing-pp.sh 
DOCKER_HOST is: unix:/run/user/1000/podman/podman.sock
./testing-pp.sh called with no arg: using default up
Creating network "testing-photoprism_default" with the default driver
Creating testing-photoprism-scheduler... done
Creating testing-photoprism_mariadb_1... done
Creating testing-photoprism_photoprism_1 ... error

ERROR: for testing-photoprism_photoprism_1  port reloading failed:
rootless port failed to add port: listen tcp 0.0.0.0:2343: bind: address
already in use

ERROR: for photoprism  port reloading failed: rootless port failed to
add port: listen tcp 0.0.0.0:2343: bind: address already in use
ERROR: Encountered errors while bringing up the project.
```


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

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

Versions of packages conmon depends on:
ii  libc6 2.32-4
ii  libglib2.0-0  2.70.1-1
ii  libsystemd0   249.5-2

conmon recommends no packages.

conmon suggests no packages.

-- no debconf information

Bug#998810: debspawn: does not honor InjectedPkgsDir

[Ritesh Raj Sarraf]

Package: debspawn
Version: 0.5.0-1
Severity: normal
X-Debbugs-Cc: r...@debian.org

As per the manual page, settings defined in /etc/debspawn/global.json
should override the defaults.

On my machine, I have the following in `/etc/debspawn/global.json`: 

{
"APTCacheDir": "/var/tmp/Debian-Build/temp/",
"TempDir": "/var/tmp/Debian-Build/Build/",
"ResultsDir": "/var/tmp/Debian-Build/Result/",
"InjectedPkgsDir": "/var/tmp/Debian-Build/pbuilder-deps/"
}

But the same is not honored by debspawn. It does not pick the local debs
from the specified InjectedPkgsDir path. OTOH, if I go with the
defaults, i.e. `/var/lib/debspawn/injected-pkgs/`, it works.


IN fact, while looking at the setup on my host machine, it looks like
the settings aren't honored at all. To workaround it, I have been adding
symlinks instead:

```
rrs@priyasi:.../debspawn$ file *
aptcache:  symbolic link to /var/tmp/Debian-Build/temp/
images:directory
injected-pkgs: directory
results:   symbolic link to /var/tmp/Debian-Build/Result/
```

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debspawn depends on:
ii  debootstrap1.0.125
ii  python33.9.7-1
ii  python3-toml   0.10.2-1
ii  systemd-container  249.5-2
ii  zstd   1.4.8+dfsg-3

Versions of packages debspawn recommends:
ii  build-essential  12.9
ii  devscripts   2.21.4

Versions of packages debspawn suggests:
ii  sudo  1.9.5p2-3

-- no debconf information

Bug#880576: targetcli-fb: Cannot create PSCSI backend for SCSI tape drive

[Ritesh Raj Sarraf]

On Fri, 2021-10-22 at 16:12 +0200, Christian Scheffczyk wrote:
> Hello Maintainers,
> 
> was this problem fixed ever?

I don't think so. I've CCed the other maintainer.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#994492: sg3-utils-udev should not require initramfs-tools[-core]

[Ritesh Raj Sarraf]

Hello Michael,

This change was proposed by the Dracut maintainers.
https://salsa.debian.org/linux-blocks-team/sg3-utils/-/merge_requests/1

While I don't use/test Dracut, I've always wanted to be willing to
accommodate more choice.

But now this is a challenge when integrating changes, where one doesn't
directly have an insight to all possible use cases/complications.

Michael: What do you propose a change for this ? I don't have any
preference here.


Thanks,
Ritesh

On Thu, 2021-09-16 at 20:13 +0300, Michael Tokarev wrote:
> Package: sg3-utils-udev
> Version: 1.45-1
> Severity: minor
> 
> Starting bullseye, sg3-utils-udev requires (depends) on initramfs-
> tools[-core].
> But it does not *use* any of the functionality of this package, except
> of
> _extending_ initramfs-tools.
> 
> This dependency forces us to invent more and more dummy versions of
> initramfs packages in order just to use core system functionality
> (eg multipath-tools now depends on sg3-utils-udev which can not be
> installed without initramfs-tools which breaks (replaces) our boot
> infrastructure).
> 
> For now we installed an empty initramfs-tools-core-dummy package just
> to be able to use multipath-tools and not break our systems.
> 
> Please note there's no mention of this new dependency in the changelog,
> but it makes major issue for ones who does not use initramfs-tools.
> 
> Thank you!

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#996708: open-iscsi: unusable with default installation

[Ritesh Raj Sarraf]

Control: tag -1 +confirmed pending


Thank you for reporting it. It is very rare to get a user bug report
during the development cycle.

On Thu, 2021-10-21 at 23:13 +0800, Yangfl wrote:
> > What do you mean by 'manually' ? Invoking the iscsid binary by hand
> > ?
> 
> Yes, `sudo iscsid`.
> 
> And I guess the issue is probably caused by missing
> /usr/lib/systemd/system/iscsid.service in
> https://packages.debian.org/sid/amd64/open-iscsi/filelist . After I
> manually download the service file from git repo, everything goes
> fine.

That was indeed the case. Something must have changed on the systemd
side of things. The debian specific service file used to get auto
picked during build, previously.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#996708: open-iscsi: unusable with default installation

[Ritesh Raj Sarraf]

Hello,

On Sun, 2021-10-17 at 23:34 +0800, Yangfl wrote:
> Package: open-iscsi
> Version: 2.1.4-2
> 
> Hi,
> 
> After installing open-iscsi without modifying any configuration,
> iscsiadm can't do any discovery using `iscsiadm -m discovery -t
> sendtargets -p `, which seemly caused by failure to start
> iscsid. Some log:
> 
> 

Was the daemon running at the time when you attempted the discovery  of
the targets ?

> After stopping those services `systemctl stop iscsid.service;
> systemctl stop iscsid.socket` and start iscsid manually, `iscsiadm -m
> discovery` successes as expected.
> 

What do you mean by 'manually' ? Invoking the iscsid binary by hand ?

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#995313: ntfs-3g: license clarification for ntfsprogs/boot.c

[Ritesh Raj Sarraf]

Package: ntfs-3g
Version: 1:2021.8.22-2
Severity: important
Tags: upstream
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org, r...@debian.org

Hello,

The debian/copyright file needs some clarification for the
ntfsprogs/boot.c file. That file is licensed under the GPLv3+ license
which effectively makes the whole tool under GPLv3.

The source headers mention that the code is adapted from the vfat code,
which was granted an exception under the Public Domain [1]


Request clarification on the ntfsprogs/boot.c file's license.

[1] https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c#L198


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ntfs-3g depends on:
ii  fuse3 [fuse]  3.10.5-1
ii  libc6 2.32-4
ii  libgcrypt20   1.9.4-3+b1
ii  libgnutls30   3.7.2-2
ii  libntfs-3g89  1:2021.8.22-2

ntfs-3g recommends no packages.

ntfs-3g suggests no packages.

-- no debconf information

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Ritesh Raj Sarraf]

On Wed, 2021-08-18 at 21:58 +0100, Jose M Calhariz wrote:
> Giving that I have seen this bug before with my machines, it is only
> the first time I am reporting and being the first reporter so I am
> with you, this is some setting in my site or my machine.
> 
> With more reasearch with help from the local specialist I found a
> an extra iSCSI setup to a local appliance that I not longer need.  So
> I remove it from /etc/iscsi.  Doing again a:
> 
> dpkg --configure -a
> 
> Setting up open-iscsi (2.1.3-5) ...
> open-iscsi postinst: since the check in preinst some iSCSI sessions
> have
>  failed. -> will wait 30s for automatic recovery
> Processing triggers for initramfs-tools (0.140) ...
> update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
> 
> 
> This time it succeeds.  So this probably is a problem on my machine.
> May I suggest for you to increase the timeout from 30s to 60 or 120s?
> 

Great. Thanks for the testing on another setup.

The thing about timeouts is that there's no sweet spot. 30s must have
been chosen keeping the Linux SCSI Mid-Layer in mind.

> Mine reasoning is that my machine boots fast enough for me not
> investigate more my iSCSI connections, but probably the iSCSI
> appliance is giving authentication timeout and so the increased need
> for a longer timeout on open-iscsi postinst.  Making the package more
> robust.
> 

This is all TCP so the recovery should be instantaneous on the
transport side. On top of that, iSCSI with its default settings, will
do a ping health check every 5 seconds.

> We may talk more about this problem and I offer my time and machine
> to
> do research on to improve the package if you see benefit on that. 
> But
> I will not keep the bug open if you want to close it.

No rush as such. I just proposed so, after brief validation on my
setup.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Ritesh Raj Sarraf]

On Wed, 2021-08-18 at 19:35 +0530, Ritesh Raj Sarraf wrote:
> On Wed, 2021-08-18 at 13:32 +0100, Jose M Calhariz wrote:
> > I was expecting to be easy to collect the info in one or 2 files, but
> > I am wrong.  I have 3 targets with multipath for 2 of them and I am
> > not certain what is active.  I have multipath active, I am certain of
> > that, because of the device I am mouting:
> > /dev/mapper/mpath-X-part1
> > 
> > So I am expecting you need all files inside /etc/iscsi and some
> > run-time info?
> 
> I am asking this information just for the sake of this task, to
> ascertain why it failed in the first 30 seconds.
> 
> Since this worked for you, later, when you increased the timeout to 120
> seconds; there's not much to do I suppose. But yes, from this bug
> report's sake, having that information clarified will be good.

Given this bug report, I validated the upgrade on my local box. It is a
fairly complex configuration pulling in all bits: iSCSI, Multipath,
Root on Multipath (iSCSI) etc.

I can confirm that the upgrade went proper without any glitch. Relevant
snippets below:

Preparing to unpack .../20-libisns0_0.100-3_amd64.deb ...
Unpacking libisns0:amd64 (0.100-3) over (0.100-2) ...
Preparing to unpack .../21-libopeniscsiusr_2.1.3-5_amd64.deb ...
Unpacking libopeniscsiusr (2.1.3-5) over (2.1.2-1) ...
Preparing to unpack .../22-open-iscsi_2.1.3-5_amd64.deb ...
Unpacking open-iscsi (2.1.3-5) over (2.1.2-1) ...
Preparing to unpack .../23-pigz_2.6-1_amd64.deb ...
Unpacking pigz (2.6-1) over (2.4-1+b1) ...
Preparing to unpack .../24-popularity-contest_1.71_all.deb ...



Setting up vim-tiny (2:8.2.2434-3) ...
Setting up man-db (2.9.4-2) ...
Updating database of manual pages ...
man-db.service is a disabled or a static unit not running, not starting
it.
Setting up open-iscsi (2.1.3-5) ...
open-iscsi postinst: since the check in preinst some iSCSI sessions
have
 failed. -> will wait 30s for automatic recovery
Setting up usbutils (1:013-3) ...
Setting up fdisk (2.36.1-8) ...
Setting up grub-common (2.04-20) ...
Installing new version of config file /etc/grub.d/30_uefi-firmware ...


and

root@debian-sanboot:~# multipath -ll
sanroot (3600140561d8bb00b25143b38318ce2c0) dm-0 LIO-ORG,debsanboot
size=8.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:0 sda 8:0  active ready running
|-+- policy='service-time 0' prio=50 status=enabled
| `- 3:0:0:0 sdb 8:16 active ready running
|-+- policy='service-time 0' prio=50 status=enabled
| `- 4:0:0:0 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=50 status=enabled
  `- 5:0:0:0 sdd 8:48 active ready running

root@debian-sanboot:~# iscsiadm -m session
tcp: [1] 172.16.20.40:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [2] 172.16.20.41:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [3] 172.16.20.43:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [4] 172.16.20.42:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)


So from the information I have, my suspicion was correct. The oddity
must be in your setup. The defaults must have been overridden for a
good reason. There's also the possibility that your network may have a
glitch. It is not easy for me to guess.

And with limited volunteer time, there's only a subset of the default
settings/combinations I can test at my end.


I suggest this bug be done as I don't see any issue. But I'll let you
make that call.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Ritesh Raj Sarraf]

On Wed, 2021-08-18 at 13:32 +0100, Jose M Calhariz wrote:
> I was expecting to be easy to collect the info in one or 2 files, but
> I am wrong.  I have 3 targets with multipath for 2 of them and I am
> not certain what is active.  I have multipath active, I am certain of
> that, because of the device I am mouting:
> /dev/mapper/mpath-X-part1
> 
> So I am expecting you need all files inside /etc/iscsi and some
> run-time info?

I am asking this information just for the sake of this task, to
ascertain why it failed in the first 30 seconds.

Since this worked for you, later, when you increased the timeout to 120
seconds; there's not much to do I suppose. But yes, from this bug
report's sake, having that information clarified will be good.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Ritesh Raj Sarraf]

On Tue, 2021-08-17 at 19:02 +0100, Jose M Calhariz wrote:
> > Did you change/tweak any of the default timeout values ?
> > 
> 
> Most probably, it is not me that usually setup the iSCSI connections.
> What values do you want me to look into it and where?

All information should be available under `/etc/iscsi`.
There will be per target database created under that folder. And those
will have all the finer session and replacement timeouts defined. They
are usually generated/updated through the `iscsiadm` utility during
discovery.

PS: That db may also include CHAP secrets, if you set any.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Ritesh Raj Sarraf]

Hello Jose,

Good to hear from you. I recollect having met you, in person, at
Debconf Heidelberg or Debconf Capetown. I hope you are doing good. :-)

On Tue, 2021-08-17 at 16:27 +0100, Jose M Calhariz wrote:
> During upgrades of open-iscsi on my environment it fails to run
> postinst with success.  I got the following messages:
> 
> Setting up open-iscsi (2.1.3-5) ...
> open-iscsi postinst: since the check in preinst some iSCSI sessions
> have
>  failed. -> will wait 30s for automatic recovery
> open-iscsi postinst: some sessions are still in failed state ->
> iscsid
>  will be restarted regardless, since that may
>  actually help with the session recovery.
> dpkg: error processing package open-iscsi (--configure):
>  installed open-iscsi package post-installation script subprocess
> returned error exit status 1
> 
> 
> I have tried to change the postinst to wait for more time, for
> example
> 120s and it worked, after 40 seconds of wait.

Hmmm. Usually, the sessions should recover within a couple of seconds.
IIRC, the check is every 5 seconds.


Did you change/tweak any of the default timeout values ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#989565: mergerfs: Duplicated file and directory names in Midnight Commander

[Ritesh Raj Sarraf]

Hello Dmitry,

Thank you for the bug report.

On Mon, 2021-06-07 at 20:10 +0300, Dmitry Semyonov wrote:
> Dear Maintainer,
> 
> The https://github.com/trapexit/mergerfs/pull/878 patch released as a
> part of mergerfs-2.32.3 upstream could be applied to the 2.31.0-1
> version currently packaged in Debian bullseye to resolve the $subj
> issue.
> 
> See https://github.com/trapexit/mergerfs/issues/877 and
> https://midnight-commander.org/ticket/4226 for additional background
> information.
> 

Thanks. I'll try to aim for this soon.

> Alternatively, please consider packaging the latest upstream release.
> It
> contains several other fixes not related to this bug.

I'm not sure if that's feasible at this point in time, given the freeze
for Debian Bullseye.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#989825: unblock: user-mode-linux/5.10um3

[Ritesh Raj Sarraf]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package user-mode-linux

Dear Release Team,

This is a request to unblock the package. The latest upload fixes bug
989665.

[ Reason ]

Bug 989665 occurred, as expected, because of the resolution put in bug
983379. Since it wasn't clear back then, if and whether the fix would be
a Linux Stable material, we carried a patch in User Mode Linux in the
interim.

Now that the fix made into Linux Stable series, the fix for 989665 is to
drop that patch.

[ Impact ]

Package user-mode-linux in Bullseye will not be in a buildable state
without this fix.

[ Tests ]

The fix allows the package to build again. Right now, for Unstable, it
has built proper for both the supported architectures (i386 and amd64)

[ Risks ]

None to my knowledge

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock user-mode-linux/5.10um3
diff -Nru user-mode-linux-5.10um2/config.amd64 
user-mode-linux-5.10um3/config.amd64
--- user-mode-linux-5.10um2/config.amd642021-03-07 10:01:29.0 
+0530
+++ user-mode-linux-5.10um3/config.amd642021-06-11 11:43:23.0 
+0530
@@ -1,6 +1,6 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/um 5.10.19 Kernel Configuration
+# Linux/um 5.10.40 Kernel Configuration
 #
 CONFIG_CC_VERSION_TEXT="gcc (Debian 10.2.1-6) 10.2.1 20210110"
 CONFIG_CC_IS_GCC=y
@@ -1771,6 +1771,7 @@
 # CONFIG_AUXDISPLAY is not set
 CONFIG_UIO=m
 CONFIG_UIO_PDRV_GENIRQ=m
+# CONFIG_VFIO is not set
 # CONFIG_VIRT_DRIVERS is not set
 CONFIG_VIRTIO=y
 CONFIG_VIRTIO_MENU=y
@@ -1915,7 +1916,6 @@
 # CONFIG_AD7091R5 is not set
 # CONFIG_AD7291 is not set
 # CONFIG_AD799X is not set
-# CONFIG_ADI_AXI_ADC is not set
 # CONFIG_INA2XX_ADC is not set
 # CONFIG_LTC2471 is not set
 # CONFIG_LTC2485 is not set
@@ -3095,7 +3095,6 @@
 # um Debugging
 #
 # CONFIG_GPROF is not set
-# CONFIG_GCOV is not set
 CONFIG_EARLY_PRINTK=y
 # end of um Debugging
 
diff -Nru user-mode-linux-5.10um2/config.i386 
user-mode-linux-5.10um3/config.i386
--- user-mode-linux-5.10um2/config.i386 2021-03-07 10:01:29.0 +0530
+++ user-mode-linux-5.10um3/config.i386 2021-06-11 11:43:23.0 +0530
@@ -1,6 +1,6 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/um 5.10.19 Kernel Configuration
+# Linux/um 5.10.40 Kernel Configuration
 #
 CONFIG_CC_VERSION_TEXT="gcc (Debian 10.2.1-6) 10.2.1 20210110"
 CONFIG_CC_IS_GCC=y
@@ -8,6 +8,8 @@
 CONFIG_LD_VERSION=23502
 CONFIG_CLANG_VERSION=0
 CONFIG_LLD_VERSION=0
+CONFIG_CC_CAN_LINK=y
+CONFIG_CC_CAN_LINK_STATIC=y
 CONFIG_CC_HAS_ASM_GOTO=y
 CONFIG_CC_HAS_ASM_INLINE=y
 CONFIG_IRQ_WORK=y
@@ -162,6 +164,7 @@
 # CONFIG_KALLSYMS_ALL is not set
 CONFIG_KALLSYMS_BASE_RELATIVE=y
 CONFIG_BPF_SYSCALL=y
+CONFIG_USERMODE_DRIVER=y
 # CONFIG_BPF_PRELOAD is not set
 CONFIG_USERFAULTFD=y
 # CONFIG_EMBEDDED is not set
@@ -244,7 +247,7 @@
 CONFIG_UML_X86=y
 # CONFIG_64BIT is not set
 CONFIG_X86_32=y
-# CONFIG_3_LEVEL_PGTABLES is not set
+CONFIG_3_LEVEL_PGTABLES=y
 CONFIG_ARCH_HAS_SC_SIGNALS=y
 CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
 CONFIG_GENERIC_HWEIGHT=y
@@ -255,7 +258,7 @@
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_KERNEL_STACK_ORDER=2
 CONFIG_MMAPPER=y
-CONFIG_PGTABLE_LEVELS=2
+CONFIG_PGTABLE_LEVELS=3
 # end of UML-specific options
 
 #
@@ -310,7 +313,7 @@
 CONFIG_CLONE_BACKWARDS=y
 CONFIG_OLD_SIGSUSPEND3=y
 CONFIG_OLD_SIGACTION=y
-CONFIG_COMPAT_32BIT_TIME=y
+# CONFIG_COMPAT_32BIT_TIME is not set
 CONFIG_ARCH_NO_PREEMPT=y
 
 #
@@ -915,7 +918,8 @@
 CONFIG_BRIDGE_EBT_SNAT=m
 CONFIG_BRIDGE_EBT_LOG=m
 CONFIG_BRIDGE_EBT_NFLOG=m
-# CONFIG_BPFILTER is not set
+CONFIG_BPFILTER=y
+CONFIG_BPFILTER_UMH=m
 CONFIG_IP_DCCP=m
 CONFIG_INET_DCCP_DIAG=m
 
@@ -1795,6 +1799,7 @@
 # CONFIG_AUXDISPLAY is not set
 CONFIG_UIO=m
 CONFIG_UIO_PDRV_GENIRQ=m
+# CONFIG_VFIO is not set
 # CONFIG_VIRT_DRIVERS is not set
 CONFIG_VIRTIO=y
 CONFIG_VIRTIO_MENU=y
@@ -1939,7 +1944,6 @@
 # CONFIG_AD7091R5 is not set
 # CONFIG_AD7291 is not set
 # CONFIG_AD799X is not set
-# CONFIG_ADI_AXI_ADC is not set
 # CONFIG_INA2XX_ADC is not set
 # CONFIG_LTC2471 is not set
 # CONFIG_LTC2485 is not set
@@ -3115,7 +3119,6 @@
 # um Debugging
 #
 # CONFIG_GPROF is not set
-# CONFIG_GCOV is not set
 CONFIG_EARLY_PRINTK=y
 # end of um Debugging
 
diff -Nru user-mode-linux-5.10um2/debian/changelog 
user-mode-linux-5.10um3/debian/changelog
--- user-mode-linux-5.10um2/debian/changelog2021-03-07 10:01:29.0 
+0530
+++ user-mode-linux-5.10um3/debian/changelog2021-06-11 11:43:23.0 
+0530
@@ -1,3 +1,11 @@
+user-mode-linux (5.10um3) unstable; urgency=medium
+
+  * [95d05ef] Drop patch um_mark_all_kernel_symbols_as_local.patch
+(Closes: #989665)
+  * [bf8d469] Update UML Linux configs
+
+ -- Ritesh Raj Sarraf   Fri, 11 Jun 2021 11:43:23 +0530
+
 user-mode-linux (5.10um2) unst

Bug#989665: user-mode-linux FTBFS: link error

[Ritesh Raj Sarraf]

Control: tag -1 pending

On Wed, 2021-06-09 at 20:57 +0300, Adrian Bunk wrote:
> Source: user-mode-linux
> Version: 5.10um2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=user-mode-linux=sid
> 
> ...
>   LD  .tmp_vmlinux.kallsyms1
> /usr/bin/ld: anonymous version tag cannot be combined with other
> version tags
> /usr/bin/ld: init/main.o: warning: relocation in read-only section
> `.text'
> /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:1167: vmlinux] Error 1

Thanks for the bug report Adrian. I hope to prepare an upload to
Unstable soon.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#989200: debspawn: save build log irrespective of the result

[Ritesh Raj Sarraf]

Package: debspawn
Version: 0.4.2-2
Severity: normal
Tags: patch

Right now, when a build fails, debspan does not save the build log.
Having the build log is extremely useful in either case.




-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debspawn depends on:
ii  debootstrap1.0.123
ii  python33.9.2-3
ii  python3-toml   0.10.1-1
ii  systemd-container  247.3-5
ii  zstd   1.4.8+dfsg-2.1

Versions of packages debspawn recommends:
ii  build-essential  12.9
ii  devscripts   2.21.2

Versions of packages debspawn suggests:
ii  sudo  1.9.5p2-3

-- no debconf information
>From 29051a0a2c5c4a10fc58c9a1f7d4017c9897bc93 Mon Sep 17 00:00:00 2001
From: Ritesh Raj Sarraf 
Date: Fri, 28 May 2021 15:04:08 +0530
Subject: [PATCH] Save build log under all conditions

The build log is always useful, whether the package build passes or
fails. Infact, during a failure, it is more important. So, save the
build log in either case.

Signed-off-by: Ritesh Raj Sarraf 
---
 debspawn/build.py | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/debspawn/build.py b/debspawn/build.py
index ae190f5..dc034e9 100644
--- a/debspawn/build.py
+++ b/debspawn/build.py
@@ -432,18 +432,19 @@ def build_from_directory(osbase, pkg_dir, *,
  source_pkg_dir=pkg_dir,
  buildflags=buildflags,
  build_env=build_env)
+
+# save buildlog, if we generated one
+log_fname = os.path.join(osbase.results_dir, 
'{}_{}_{}.buildlog'.format(pkg_sourcename,
+
version_noepoch(pkg_version),
+
osbase.arch))
+save_captured_console_output(log_fname)
+
 if not ret:
 return False
 
 # copy build results
 _retrieve_artifacts(osbase, pkg_tmp_dir)
 
-# save buildlog, if we generated one
-log_fname = os.path.join(osbase.results_dir, 
'{}_{}_{}.buildlog'.format(pkg_sourcename,
-
version_noepoch(pkg_version),
-
osbase.arch))
-save_captured_console_output(log_fname)
-
 # sign the resulting package
 if sign:
 r = _sign_result(osbase.results_dir, pkg_sourcename, pkg_version, 
osbase.arch)
@@ -512,18 +513,19 @@ def build_from_dsc(osbase, dsc_fname, *,
  interact=interact,
  buildflags=buildflags,
  build_env=build_env)
+
+# save buildlog, if we generated one
+log_fname = os.path.join(osbase.results_dir, 
'{}_{}_{}.buildlog'.format(pkg_sourcename,
+
version_noepoch(pkg_version),
+
osbase.arch))
+save_captured_console_output(log_fname)
+
 if not ret:
 return False
 
 # copy build results
 _retrieve_artifacts(osbase, pkg_tmp_dir)
 
-# save buildlog, if we generated one
-log_fname = os.path.join(osbase.results_dir, 
'{}_{}_{}.buildlog'.format(pkg_sourcename,
-
version_noepoch(pkg_version),
-
osbase.arch))
-save_captured_console_output(log_fname)
-
 # sign the resulting package
 if sign:
 r = _sign_result(osbase.results_dir, pkg_sourcename, pkg_version, 
osbase.arch)
-- 
2.32.0.rc0

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Control: retitle -1 unblock: open-iscsi/2.1.3-5


Dear Release Team and Paul,

I am hopeful that this recent upload of open-iscsi at version 2.1.3-5
is proper. I request an unblock of this version so that the d-i issue
is fixed.

The patch was prepared in close co-ordination with Cyril from d-i team.

The current migration status on the tracker page looks okay to me.
The debdiff in between the versions from Testing and Unstable are
attached with this email

Thanks,
Ritesh

On Fri, 2021-05-14 at 21:56 +0200, Paul Gevers wrote:
> Hi Ritesh,
> 
> On 12-05-2021 18:27, Ritesh Raj Sarraf wrote:
> > The package has been uploaded to Unstable. It has built proper on
> > all
> > supported architectures. You may want to consider unblocking this
> > build
> > revision.
> 
> The armhf udeb package has an unmet dependency.
> 
> Paul
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
diff -Nru open-iscsi-2.1.3/debian/changelog open-iscsi-2.1.3/debian/changelog
--- open-iscsi-2.1.3/debian/changelog	2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/changelog	2021-05-20 19:52:30.0 +0530
@@ -1,3 +1,26 @@
+open-iscsi (2.1.3-5) unstable; urgency=medium
+
+  [ Cyril Brulebois ]
+  * [3b8b2d8] Revert "Set architecture for build to linux-any"
+  * [1297e50] Adjust dh_auto_install and dh_makeshlibs overrides for the conditional udeb.
+
+ -- Ritesh Raj Sarraf   Thu, 20 May 2021 19:52:30 +0530
+
+open-iscsi (2.1.3-4) unstable; urgency=medium
+
+  * [8142984] Set architecture for build to linux-any. This ensures that the
+library is built on the right set of architectures and dh_makeshlibs is
+invoked appropriately. (Closes: #987858)
+
+ -- Ritesh Raj Sarraf   Tue, 04 May 2021 21:45:56 +0530
+
+open-iscsi (2.1.3-3) unstable; urgency=medium
+
+  * [47645a5] Make open-iscsi-udeb compatible with d-i.
+    Thanks to Cyril Brulebois (Closes: #987568)
+
+ -- Ritesh Raj Sarraf   Thu, 29 Apr 2021 13:43:35 +0530
+
 open-iscsi (2.1.3-2) unstable; urgency=medium
 
   * [c3b7109] Fix FTCBFS:
diff -Nru open-iscsi-2.1.3/debian/control open-iscsi-2.1.3/debian/control
--- open-iscsi-2.1.3/debian/control	2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/control	2021-05-20 19:52:23.0 +0530
@@ -144,8 +144,6 @@
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
diff -Nru open-iscsi-2.1.3/debian/rules open-iscsi-2.1.3/debian/rules
--- open-iscsi-2.1.3/debian/rules	2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/rules	2021-05-20 19:52:23.0 +0530
@@ -9,6 +9,8 @@
 include /usr/share/dpkg/pkg-info.mk
 export KBUILD_BUILD_TIMESTAMP = @$(SOURCE_DATE_EPOCH)
 
+UDEB := $(filter open-iscsi-udeb,$(shell dh_listpackages))
+
 %:
 	dh $@
 
@@ -59,6 +61,7 @@
 	mkdir -p debian/iscsiuio/usr/share/initramfs-tools/hooks
 	cp -p debian/extra/iscsiuio.initramfs.hook debian/iscsiuio/usr/share/initramfs-tools/hooks/iscsiuio
 
+ifneq ($(UDEB),)
 	@# open-iscsi-udeb
 	dh_install -p open-iscsi-udeb usr/iscsid sbin/
 	dh_install -p open-iscsi-udeb usr/iscsistart sbin/
@@ -69,6 +72,10 @@
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start 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
+	dh_install -p open-iscsi-udeb libopeniscsiusr/libopeniscsiusr*.so.* usr/lib/${DEB_HOST_MULTIARCH}
+endif
+
 override_dh_installinit:
 	dh_installinit -p open-iscsi --name=iscsid
 	dh_installinit -p open-iscsi
@@ -96,3 +103,10 @@
 
 override_dh_missing:
 	dh_missing --fail-missing
+
+override_dh_makeshlibs:
+ifneq ($(UDEB),)
+	dh_makeshlibs --add-udeb=open-iscsi-udeb
+else
+	dh_makeshlibs
+endif


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Sat, 2021-05-15 at 17:37 +0200, Cyril Brulebois wrote:
> Ritesh Raj Sarraf  (2021-05-15):
> > Yes. That scsi-modules support bites back now. I just forgot about
> > it
> > completely. My intent was to not duplicate another architecture
> > list
> in
> > d/rules, and in trying to simplify things, it has just fallen apart
> > with this old oddity of support on armel.
> 
> I'm happy to provide (and test) a patch that would only hardcode the
> list in debian/control, and make sure the extra steps aren't run from
> debian/rules. If you like the idea, you might get a patch in the next
> few hours.

That'd be nice of you. So, yes, please.

And you'd be the next best team (debian-boot) to test that feature as
it is specific to d-i.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Sat, 2021-05-15 at 16:30 +0200, Cyril Brulebois wrote:
> It's just scsi-modules that's not available on armel apparently.
> 
> As far as I know, armel is in “maintenance mode” anyway, trying not
> to
> lose support for old devices. I wouldn't worry if an optional
> component
> like open-iscsi(-udeb) would not be installable on this single
> architecture. I'll let folks from debian-arm@ comment further on
> this.
> 
> But of course, this is a problem that prevents migration now, 

> let's
> check why; the old Architecture list looked like this (before
> switching
> it to linux-any):
> 
>     Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc
> ppc64
> ppc64el s390x
> 
> without armel so you had no installability issue there… Note that
> this
> was actually explained in the comment just before that line:
> 
>     # Note: the (virtual) udeb package scsi-modules (provided by
> different
>     #   linux kernel udebs) must exist for these architectures -
> so
>     #   check that before adding them to this list; the other
>     #   scsi-(core|common|...)-modules are NOT sufficient!
> 
> An obvious fix would be to revert to an hardcoded list of supported
> architectures (and requesting a removal of the obsolete armel binary
> that should start appearing in the cruft report[1] once that has
> happened); that's not too nice but I don't see any obvious better fix
> right now.

Yes. That scsi-modules support bites back now. I just forgot about it
completely. My intent was to not duplicate another architecture list in
d/rules, and in trying to simplify things, it has just fallen apart
with this old oddity of support on armel.

Time is pressing and I'm wondering what best to do here. I certainly do
not care much for the iSCSI support in the installer. I didn't write or
test that feature either. And I'm not even sure if that module even
works well in the installer. There's 'Root on (iSCSI + DM Multipath)'
that I use and care for but that doesn't even get set through the d-i
installer. Instead, the setup is to bootstrap the root LUN.

Maybe best to rope-in Ubuntu folks. I believe they make use of it in
the installer. I personally would like to drop the iSCSI support in the
installer, simply because I don't use it and don't have the commitment
to support/test it, nor the necessary hands-on knowledge if a bug is
reported. But derivatives may have a dependency on it.

The current easy fix, as Cyril mentioned above, it to revert it back to
the previous architecture list and adapt the same in d/rules in target
override_dh_makeshlibs.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,


While this bug is now in fixed status with the recent upload of open-
iscsi version 2.1.3-4, there's still some other issue about the udeb
being reported on the tracker package.

In particular, it metions:
open-iscsi-udeb/armel has unsatisfiable dependency

I see now difference in the generated deb's dependency list. Is it
something you are aware of, in general, about d-i's status on armel ?
Or are there still bugs from the installer's point of view, where I
need to step in ?



rrs@priyasi:.../Chrome-Downloads$ dpkg -I open-iscsi-udeb_2.1.3-
4_armel.udeb 
 new Debian package, version 2.0.
 size 212060 bytes: control archive=572 bytes.
 592 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-4
 Architecture: armel
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 1185
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.
19:33 ♒ ॐ ♅ ♄ ⛢ ☺ 
rrs@priyasi:.../Chrome-Downloads$ dpkg -I open-iscsi-udeb_2.1.3-
4_armhf.udeb 
 new Debian package, version 2.0.
 size 218124 bytes: control archive=572 bytes.
 591 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-4
 Architecture: armhf
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 933
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.
19:33 ♒ ॐ ♅ ♄ ⛢ ☺ 


On Sat, 2021-05-01 at 04:32 +0200, Cyril Brulebois wrote:
> Hi,
> 
> Ritesh Raj Sarraf  (2021-04-30):
> > The upload I prepped failed on some of the architectures.
> > https://buildd.debian.org/status/logs.php?pkg=open-iscsi=2.1.3-3
> 
> It's lacking a push to the Git repository (git fetch didn't get
> anything
> new from a few days ago).
> 
> > In d/control, there is:
> > 
> > ```
> > Package: open-iscsi-udeb
> > # Note: the (virtual) udeb package scsi-modules (provided by
> > different
> > #   linux kernel udebs) must exist for these architectures - so
> > #   check that before adding them to this list; the other
> > #   scsi-(core|common|...)-modules are NOT sufficient!
> > Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
> > ppc64el s390x
> > Section: debian-installer
> > Package-Type: udeb
> > ```
> > 
> > 
> > The udeb package was introduced by Colin Watson from Ubuntu. I
> > extended
> > the architecture list, based on the supported architectures by d-i.
> > But
> > I really don't use or test this functionality of the package.
> > 
> > 
> > How would you like to see this fixed Cyril ?
> > 
> > The easiest option, if d-i supports, would be to extend architecture
> > list to: `linux-any`, keeping it in line with what the actual open-
> > iscsi package supports.
> 
> Yes, I think that would be a good idea, so that you don't have to keep
> the list in sync between debian/control and debian/rules. We don't have
> many examples of packages maintained by the d-i team that use it, but
> at least src:haveged and src:systemd have similar udebs (after all,
> that
> only matters at build-time, d-i only sees the results of the build).
> 
> Regarding your conditional, you could check whether you're building for
> linux (once you switch to linux-any) or you could check whether the
> udeb
> is being built: dh_listpackages (-a) can be use to determine that.
> 
> 
> Cheers,

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#948674: Processed: RFP: otter-browser -- Fast and configurable web browser inspired by Opera 12

[Ritesh Raj Sarraf]

Hello Chris,

On Fri, 2021-05-14 at 19:34 +0200, Chris Hofstaedtler wrote:
> * Ritesh Raj Sarraf  [210514 17:33]:
> > Is there some explanation on this change ? Or is it some broken
> > script
> > that is run ?
> 
> > > > noowner 948674
> > > Bug #948674 [wnpp] RFP: otter-browser -- Fast and configurable
> > > web
> > > browser inspired by Opera 12
> 
> The bug is still titled "RFP:". I *guess* RFPs usually should not
> have owners. Maybe you want to actually retitle to ITP: and again
> set the owner.
> 
Yes. Possibly that may be the reason. I did retitle the bug report, but
to an "ITA: " than an "ITP: "


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#988469: mypy: failure on armhf and i386

[Ritesh Raj Sarraf]

Package: mypy
Severity: important
Tags: ftbfs

Dear Maintainer,

During a rebuild of your package, it was noticed that the package ftbfs
on common 32 bit platforms. So far, I've seen it happen on i386 and
armhf. The same failures are also seen on the reproducible builds
project.

*
creating build/temp.linux-armhf-3.9/build
arm-linux-gnueabihf-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-jS0VHk/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 
-fdebug-prefix-map=/build/mypy-0.812=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-I/build/mypy-0.812/mypyc/lib-rt -Ibuild -I/usr/include/python3.9 -c 
build/__native_8c8c5116bc4884237d33.c -o 
build/temp.linux-armhf-3.9/build/__native_8c8c5116bc4884237d33.o -O1 -Werror 
-Wno-unused-function -Wno-unused-label -Wno-unreachable-code 
-Wno-unused-variable -Wno-unused-command-line-argument 
-Wno-unknown-warning-option -Wno-unused-but-set-variable
build/__native_8c8c5116bc4884237d33.c: In function 
'CPyDef_fastparse___TypeConverter___visit_Subscript':
build/__native_8c8c5116bc4884237d33.c:560362: note: '-Wmisleading-indentation' 
is disabled from this point onwards, since column-tracking was disabled due to 
the size of the code/headers
560362 | CPyL27: ;
   | 

cc1: out of memory allocating 32764 bytes after a total of 93487104 bytes
error: command '/usr/bin/arm-linux-gnueabihf-gcc' failed with exit code 1
E: pybuild pybuild:353: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: error: pybuild --build -i python{version} -p 3.9 returned exit 
code 13
make[1]: *** [debian/rules:51: override_dh_auto_build] Error 25
make[1]: Leaving directory '/build/mypy-0.812'
make: *** [debian/rules:26: binary] Error 2
*

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mypy depends on:
ii  python3   3.9.2-3
pn  python3-mypy  

mypy recommends no packages.

Versions of packages mypy suggests:
pn  mypy-doc  

Bug#988328: [pkg-go] Bug#988328: golang-github-pquerna-cachecontrol: FTBFS in tests constant 9223372036854775807 overflows int

[Ritesh Raj Sarraf]

ControL: severity -1 important

On Thu, 2021-05-13 at 12:43 +0100, peter green wrote:
> The package is arch all.
> 
> While I don't think it's explicitly spelled out anywhere, my
> understanding
> is that it has never been a requirement for arch all packages to
> build
> on all architectures. So IMO this bug should be downgraded (I'm not
> going
> to make the downgrade myself though because I'm not the maintainer)

I think it is a valid reason to lower the severity. Thanks for pointing
it out.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#948674: Processed: RFP: otter-browser -- Fast and configurable web browser inspired by Opera 12

[Ritesh Raj Sarraf]

Is there some explanation on this change ? Or is it some broken script
that is run ?



On Thu, 2021-05-13 at 09:57 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > noowner 948674
> Bug #948674 [wnpp] RFP: otter-browser -- Fast and configurable web
> browser inspired by Opera 12
> Removed annotation that Bug was owned by r...@debian.org.
> > 
> End of message, stopping processing here.
> 
> Please contact me if you need assistance.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#948674: ITA: otter-browser -- Fast and configurable web browser inspired by Opera 12

[Ritesh Raj Sarraf]

Package: wnpp
Followup-For: Bug #948674


I am currently evaluating the Otter Browser. I have revived the
packaging and am looking at its feature set.

There are some bugs with the browser, which I'll try to work with the
upstream.

My intent is to first evaluate the longevity of this package and then
act on whether this should be part of the Distribution

Bug#988424: python-sparse: failure in tests

[Ritesh Raj Sarraf]

Package: python-sparse
Severity: important
Tags: ftbfs
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org

Dear Maintainer,

It turns out that the package seems to be failing in some of the tests
on 32 bit systems.

=== FAILURES ===
__ [doctest] sparse._common.full_like __
1384 
1385 Returns
1386 ---
1387 out : SparseArray
1388 Array of `fill_value` with the same shape and type as `a`.
1389 
1390 Examples
1391 
1392 >>> x = np.ones((2, 3), dtype='i8')
1393 >>> full_like(x, 9.0).todense()  # doctest: +NORMALIZE_WHITESPACE
Expected:
array([[9, 9, 9],
   [9, 9, 9]])
Got:
array([[9, 9, 9],
   [9, 9, 9]], dtype=int64)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_common.py:1393:
 DocTestFailure
__ [doctest] sparse._common.ones_like __
1537 
1538 Returns
1539 ---
1540 out : SparseArray
1541 Array of ones with the same shape and type as `a`.
1542 
1543 Examples
1544 
1545 >>> x = np.ones((2, 3), dtype='i8')
1546 >>> ones_like(x).todense()  # doctest: +NORMALIZE_WHITESPACE
Expected:
array([[1, 1, 1],
   [1, 1, 1]])
Got:
array([[1, 1, 1],
   [1, 1, 1]], dtype=int64)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_common.py:1546:
 DocTestFailure
_ [doctest] sparse._common.zeros_like __
1461 
1462 Returns
1463 ---
1464 out : SparseArray
1465 Array of zeros with the same shape and type as `a`.
1466 
1467 Examples
1468 
1469 >>> x = np.ones((2, 3), dtype='i8')
1470 >>> zeros_like(x).todense()  # doctest: +NORMALIZE_WHITESPACE
Expected:
array([[0, 0, 0],
   [0, 0, 0]])
Got:
array([[0, 0, 0],
   [0, 0, 0]], dtype=int64)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_common.py:1470:
 DocTestFailure
__ [doctest] sparse._dok.DOK ___
056 
057 
058 You can convert :obj:`DOK` arrays to :obj:`COO` arrays, or 
:obj:`numpy.ndarray`
059 objects.
060 
061 >>> from sparse import COO
062 >>> s3 = COO(s2)
063 >>> s3
064 
065 >>> s2.todense()  # doctest: +NORMALIZE_WHITESPACE
Differences (unified diff with -expected +actual):
@@ -3,3 +3,3 @@
[0, 6, 7, 0, 0],
[0, 0, 0, 0, 0],
-   [0, 0, 0, 0, 0]])
+   [0, 0, 0, 0, 0]], dtype=int64)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_dok.py:65:
 DocTestFailure
___ [doctest] sparse._slicing.sanitize_index ___
144 Sanitize the elements for indexing along one axis
145 >>> sanitize_index([2, 3, 5])
146 array([2, 3, 5])
147 >>> sanitize_index([True, False, True, False])
Expected:
array([0, 2])
Got:
array([0, 2], dtype=int32)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_slicing.py:147:
 DocTestFailure
 [doctest] sparse._coo.common.argwhere _
586 
587 See Also
588 
589 :obj:`where`, :obj:`COO.nonzero`
590 
591 Examples
592 
593 >>> import sparse
594 >>> x = sparse.COO(np.arange(6).reshape((2, 3)))
595 >>> sparse.argwhere(x > 1)
Differences (unified diff with -expected +actual):
@@ -2,3 +2,3 @@
[1, 0],
[1, 1],
-   [1, 2]])
+   [1, 2]], dtype=int32)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_coo/common.py:595:
 DocTestFailure
 [doctest] sparse._coo.core.COO 
070 You can create :obj:`COO` objects from Numpy arrays.
071 
072 >>> x = np.eye(4, dtype=np.uint8)
073 >>> x[2, 3] = 5
074 >>> s = COO.from_numpy(x)
075 >>> s
076 
077 >>> s.data  # doctest: +NORMALIZE_WHITESPACE
078 array([1, 1, 1, 5, 1], dtype=uint8)
079 >>> s.coords  # doctest: +NORMALIZE_WHITESPACE
Expected:
array([[0, 1, 2, 2, 3],
   [0, 1, 2, 3, 3]])
Got:
array([[0, 1, 2, 2, 3],
   [0, 1, 2, 3, 3]], dtype=int32)

/srv/build/python-sparse-0.11.2/.pybuild/cpython3_3.9_sparse/build/sparse/_coo/core.py:79:
 DocTestFailure
_ [doctest] sparse._coo.core.COO._sort_indices _
1542 Sorts the :obj:`COO.coords` attribute. Also sorts the data in
1543 :obj:`COO.data` to match.
1544 
1545 Examples
1546 
1547 >>> coords = np.array([[1, 2, 0]], dtype=np.uint8)
1548 >>> data = np.array([4, 1, 3], dtype=np.uint8)
1549 >>> s = COO(coords, data)
1550 >>> s._sort_indices()
1551 >>> s.coords  # doctest: +NORMALIZE_WHITESPACE
Expected:
  

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

On Tue, 2021-05-04 at 22:04 +0530, Ritesh Raj Sarraf wrote:
> > That's not what I meant. I'll try to be more clear next time.
> > 
> > You're debdiff showed only the content of the open-iscsi binary
> > package
> > (which wasn't affected by your changes). My request was intended
> > for
> > *all* binary packages. You can get that by running debdiff on the
> > changes files IIRC.
> 
> Attached are the diffs you requested. This time, I have not yet
> uploaded the proposed package to Unstable. I will have for an
> affirmation from the Release Team.

The package has been uploaded to Unstable. It has built proper on all
supported architectures. You may want to consider unblocking this build
revision.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#976507: golang-google-cloud: FTBFS on armhf

[Ritesh Raj Sarraf]

Source: golang-google-cloud
Followup-For: Bug #976507
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org


I just want to add that along with arm64, I've had the package FTBFS on
armhf and i386 too.

Bug#988328: golang-github-pquerna-cachecontrol: FTBFS in tests constant 9223372036854775807 overflows int

[Ritesh Raj Sarraf]

Source: golang-github-pquerna-cachecontrol
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org

Dear Maintainer,

Not sure if this package had built successfully in the past or not.
Buildd is down while I'm writing this bug report, so I can't really be
sure. I did check reproducible builds and it has been reported to be
failing there.


During a rebuild of the package, it is seen that the package fails in
one of the tests, commonly on 32 bit systems. So far, I can see it fails
on armhf and i386.

*
   dh_auto_test -O--buildsystem=golang
cd obj-i686-linux-gnu && go test -vet=off -v -p 8 
github.com/pquerna/cachecontrol github.com/pquerna/cachecontrol/cacheobject 
github.com/pquerna/cachecontrol/examples 
github.com/pquerna/cachecontrol/examples/lowlevel
# github.com/pquerna/cachecontrol/cacheobject 
[github.com/pquerna/cachecontrol/cacheobject.test]
src/github.com/pquerna/cachecontrol/cacheobject/directive_test.go:262:43: 
constant 9223372036854775807 overflows int
=== RUN   TestCachableResponsePublic
--- PASS: TestCachableResponsePublic (0.00s)
=== RUN   TestCachableResponsePrivate
--- PASS: TestCachableResponsePrivate (0.00s)
=== RUN   TestResponseWriter
--- PASS: TestResponseWriter (0.00s)
PASS
ok  github.com/pquerna/cachecontrol 0.007s
FAILgithub.com/pquerna/cachecontrol/cacheobject [build failed]
?   github.com/pquerna/cachecontrol/examples[no test files]
?   github.com/pquerna/cachecontrol/examples/lowlevel   [no test files]
FAIL
dh_auto_test: error: cd obj-i686-linux-gnu && go test -vet=off -v -p 8 
github.com/pquerna/cachecontrol github.com/pquerna/cachecontrol/cacheobject 
github.com/pquerna/cachecontrol/examples 
github.com/pquerna/cachecontrol/examples/lowlevel returned exit code 2
make: *** [debian/rules:7: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Command `dpkg-buildpackage --changes-option=-DDistribution=bullseye` failed.

*

Bug#988324: falkon: how well to integrate spellcheck

[Ritesh Raj Sarraf]

Package: falkon
Version: 3.1.0+dfsg1-11
Severity: normal

Dear Georges,

I realized that you start noticing a feature when you miss it. Such is
the case with spell-check. Falkon doesn't support spell-check
out-of-the-box. And that is when I realized how important the
spell-check feature really is.


So, following the documentation, I am able to get Falkon understand the
converted .bdic files. I was wondering if this can we done better than
doing manually.

While this is a Falkon problem, I wonder 2 things:

1. Why can't/doesn't Falkon make use of KDE libs, like the rest of KDE,
for spell check

2. If going by the way Falkon recommends, would it make sense to
add some post-installation script in place, which could detect the list
of installed dictionaries on the system and upon user consent extract a
.bdict format out of it


Option 2 is currently manual and it'd be nice to have it done automatic.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages falkon depends on:
ii  kio  5.82.0-1~np1
ii  libc62.31-12
ii  libgcc-s110.2.1-6
ii  libkf5coreaddons55.82.0-1~np1
ii  libkf5crash5 5.82.0-1~np1
ii  libkf5kiocore5   5.82.0-1~np1
ii  libkf5kiowidgets55.82.0-1~np1
ii  libkf5purpose-bin5.82.0-1~np1
ii  libkf5purpose5   5.82.0-1~np1
ii  libkf5wallet-bin 5.82.0-1~np1
ii  libkf5wallet55.82.0-1~np1
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5dbus5  5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5network5   5.15.2+dfsg-5
ii  libqt5printsupport5  5.15.2+dfsg-5
ii  libqt5qml5   5.15.2+dfsg-5
ii  libqt5quickwidgets5  5.15.2+dfsg-5
ii  libqt5sql5   5.15.2+dfsg-5
ii  libqt5sql5-sqlite5.15.2+dfsg-5
ii  libqt5webchannel55.15.2-2
ii  libqt5webenginecore5 5.15.2+dfsg-3
ii  libqt5webenginewidgets5  5.15.2+dfsg-3
ii  libqt5widgets5   5.15.2+dfsg-5
ii  libqt5x11extras5 5.15.2-2
ii  libssl1.11.1.1k-1
ii  libstdc++6   10.2.1-6
ii  libxcb1  1.14-3
ii  qml-module-qtwebengine   5.15.2+dfsg-3

falkon recommends no packages.

Versions of packages falkon suggests:
ii  qtwebengine5-dev-tools  5.15.2+dfsg-3

-- no debconf information

Bug#988131: falkon does not gain focus when called from external applications

[Ritesh Raj Sarraf]

On Fri, 2021-05-07 at 12:57 +0530, Ritesh Raj Sarraf wrote:
> 
> I has something to do with xcb, in general.
> 
> On another machine running KDE + Wayland, the default falkon process
> gives the following, when called externally.
> 
> Please register the custom scheme 'clementine-itms' via
> QWebEngineUrlScheme::registerScheme() before installing the custom
> scheme handler.
> Falkon: 3 extensions loaded
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> libpng warning: iCCP: known incorrect sRGB profile
> [94505:94534:0507/125435.749499:ERROR:nss_util.cc(283)] After loading
> Root Certs, loaded==false: NSS error code: -8018
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> 
> 
> This can be worked around with:
> QT_QPA_PLATFORM=xcb
> 
> I have tested it on the machine where it runs KDE + Wayland

I tried more setups.

With sway WM + Wayland, the issue is the same. And the workaround is
the same too.

OTOH, when I tried with good old icewm, the issue is not seen. Falkon,
there, behaves proper just as I'd want.

So I don't know where to look further. It seems to be an erratic
behavior seen only on some setups.

The unfortunate part is that my primary machine, where I run KDE + X11
+ Falkon, the problem is as is. I had hoped that the wayland workaround
(QT_QPA_PLATFORM=xcb) would help but that is not the case.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#988131: falkon does not gain focus when called from external applications

[Ritesh Raj Sarraf]

On Thu, 2021-05-06 at 19:30 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2021-05-06 at 18:44 +0530, Ritesh Raj Sarraf wrote:
> > On Thu, 2021-05-06 at 13:34 +0200, Georges Khaznadar wrote:
> > > Dear Ritesh,
> > > 
> > > I tried to reproduce the bug you are describing, without success.
> > > 
> > > My attempt to reproduce the bug was:
> > > 
> > > - From a terminal, I type "falkon", then Enter key
> > > - Falkon is launched and it gets the focus.
> > > 
> > > My desktop software is currently LXDE, version 10; the terminal is
> > > gnome-terminal. When I do the same with x-www-browser, Falkon's
> > > window
> > > gets the focus too.
> > 
> > 
> > Let me outline the steps
> > 
> > 1. Open Falkon main browser
> > 2. Now open terminal
> > 3. Run x-www-browser (falkon) www.debian.org
> > 
> > Expected behavior should be that Falkon will get focus and open the
> > browser for you.
> 
> I made a video trying to visualize the problem I'm running into.
> 
> https://youtu.be/k1ijRR_7UmE
> 
> Hope you are okay with accessing it on YouTube. If not, please let
> know. I'll make alternate arrangements.

I has something to do with xcb, in general.

On another machine running KDE + Wayland, the default falkon process
gives the following, when called externally.

Please register the custom scheme 'clementine-itms' via
QWebEngineUrlScheme::registerScheme() before installing the custom
scheme handler.
Falkon: 3 extensions loaded
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
libpng warning: iCCP: known incorrect sRGB profile
[94505:94534:0507/125435.749499:ERROR:nss_util.cc(283)] After loading
Root Certs, loaded==false: NSS error code: -8018
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()


This can be worked around with:
QT_QPA_PLATFORM=xcb

I have tested it on the machine where it runs KDE + Wayland

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#988131: falkon does not gain focus when called from external applications

[Ritesh Raj Sarraf]

On Thu, 2021-05-06 at 18:44 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2021-05-06 at 13:34 +0200, Georges Khaznadar wrote:
> > Dear Ritesh,
> > 
> > I tried to reproduce the bug you are describing, without success.
> > 
> > My attempt to reproduce the bug was:
> > 
> > - From a terminal, I type "falkon", then Enter key
> > - Falkon is launched and it gets the focus.
> > 
> > My desktop software is currently LXDE, version 10; the terminal is
> > gnome-terminal. When I do the same with x-www-browser, Falkon's
> > window
> > gets the focus too.
> 
> 
> Let me outline the steps
> 
> 1. Open Falkon main browser
> 2. Now open terminal
> 3. Run x-www-browser (falkon) www.debian.org
> 
> Expected behavior should be that Falkon will get focus and open the
> browser for you.

I made a video trying to visualize the problem I'm running into.

https://youtu.be/k1ijRR_7UmE

Hope you are okay with accessing it on YouTube. If not, please let
know. I'll make alternate arrangements.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#988131: falkon does not gain focus when called from external applications

[Ritesh Raj Sarraf]

Hello Georges,


Thank you for the prompt response.

On Thu, 2021-05-06 at 13:34 +0200, Georges Khaznadar wrote:
> Dear Ritesh,
> 
> I tried to reproduce the bug you are describing, without success.
> 
> My attempt to reproduce the bug was:
> 
> - From a terminal, I type "falkon", then Enter key
> - Falkon is launched and it gets the focus.
> 
> My desktop software is currently LXDE, version 10; the terminal is
> gnome-terminal. When I do the same with x-www-browser, Falkon's
> window
> gets the focus too.


Let me outline the steps

1. Open Falkon main browser
2. Now open terminal
3. Run x-www-browser (falkon) www.debian.org

Expected behavior should be that Falkon will get focus and open the
browser for you.

> 
> Which desktop manager are you using?

I'm on KDE 5.81.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#988131: falkon does not gain focus when called from external applications

[Ritesh Raj Sarraf]

Package: falkon
Version: 3.1.0+dfsg1-11
Severity: normal

First of all, a big thank you to both, you and the upstream team, for
doing an awesome job with Falkon. I desperately wanted a simple yet
modern web browser and Falkon fits the bill quite well.


While it has been just a couple of hours with me using it, I think I've
come across an integration issue with Falkon.


Falkon, when called through, say x-www-browser, doesn't gain focus.
Looking closer, I noticed the behavior with plain Falkon too. 

If you call Falkon as in `falkon www.debian.org` from your terminal, the
web browser does open the page in a new tab, but the web browser does
not gain focus, which is what the usual expectation would be.

OTOH, if I invoke the same command with `-t`, as in, `falkon -t
www.debian.org`, falkon gains the focus.

It is a minor glitch and would be nice to have it fixed.

There's also a behaviral bug when launching Falkot with -t, in that
along with opening the requested page in a tab, Falkon also opens an
extra empty tab.


PS: I have looked through the preferences in Falkon to be sure that it
is not a functionality enabled/disabled and to my understanding that
doesn't seem to be the case. Apologies in case it is something obvious
and I may have missed.

Thanks,
Ritesh


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages falkon depends on:
ii  kio  5.81.0-1~np1
ii  libc62.31-12
ii  libgcc-s110.2.1-6
ii  libkf5coreaddons55.81.0-1~np1
ii  libkf5crash5 5.81.0-1~np1
ii  libkf5kiocore5   5.81.0-1~np1
ii  libkf5kiowidgets55.81.0-1~np1
ii  libkf5purpose-bin5.81.0-1~np1
ii  libkf5purpose5   5.81.0-1~np1
ii  libkf5wallet-bin 5.81.0-1~np1
ii  libkf5wallet55.81.0-1~np1
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5dbus5  5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5network5   5.15.2+dfsg-5
ii  libqt5printsupport5  5.15.2+dfsg-5
ii  libqt5qml5   5.15.2+dfsg-5
ii  libqt5quickwidgets5  5.15.2+dfsg-5
ii  libqt5sql5   5.15.2+dfsg-5
ii  libqt5sql5-sqlite5.15.2+dfsg-5
ii  libqt5webchannel55.15.2-2
ii  libqt5webenginecore5 5.15.2+dfsg-3
ii  libqt5webenginewidgets5  5.15.2+dfsg-3
ii  libqt5widgets5   5.15.2+dfsg-5
ii  libqt5x11extras5 5.15.2-2
ii  libssl1.11.1.1k-1
ii  libstdc++6   10.2.1-6
ii  libxcb1  1.14-3
ii  qml-module-qtwebengine   5.15.2+dfsg-3

falkon recommends no packages.

Versions of packages falkon suggests:
pn  qtwebengine5-dev-tools  

-- no debconf information

Bug#988102: python-libnacl: failing in tests on 32 bit systems

[Ritesh Raj Sarraf]

Package: python-libnacl
Version: 1.7.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org


Dear Maintainer,

Your package fails to build, so far on 32 bit systems. It is failing in
one of the tests.

The build failure snippet is below

***

dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 
in use)
I: pybuild base:232: cd 
/srv/build/python-libnacl-1.7.2/.pybuild/cpython3_3.9_libnacl/build; python3.9 
-m nose -v tests
test_gcm_aead (unit.test_aead.TestAEAD) ... ok
test_ietf_aead (unit.test_aead.TestAEAD) ... ok
test_auth_rejects_wrong_lengths (unit.test_auth_verify.TestAuthVerify) ... ok
test_auth_verify (unit.test_auth_verify.TestAuthVerify) ... ok
test_auth_verify_rejects_wrong_key_lengths 
(unit.test_auth_verify.TestAuthVerify) ... ok
test_onetimeauth_rejects_wrong_lengths (unit.test_auth_verify.TestAuthVerify) 
... ok
test_onetimeauth_verify (unit.test_auth_verify.TestAuthVerify) ... ok
test_onetimeauth_verify_rejects_wrong_key_lengths 
(unit.test_auth_verify.TestAuthVerify) ... ok
test_key_blake (unit.test_blake.TestBlake) ... ok
test_keyless_blake (unit.test_blake.TestBlake) ... ok
test_publickey (unit.test_dual.TestDual) ... ok
test_secretkey (unit.test_dual.TestDual) ... ok
test_sign (unit.test_dual.TestDual) ... ok
test_publickey (unit.test_public.TestPublic) ... ok
test_secretkey (unit.test_public.TestPublic) ... ok
test_secret_box (unit.test_raw_auth_sym.TestSecretBox) ... ok
test_secret_box_easy (unit.test_raw_auth_sym_easy.TestSecretBox) ... ok
test_key_generichash (unit.test_raw_generichash.TestGenericHash) ... ok
test_keyless_generichash (unit.test_raw_generichash.TestGenericHash) ... ok
test_hash (unit.test_raw_hash.TestHash) ... ok
test_box (unit.test_raw_public.TestPublic) ... ok
test_box_seal (unit.test_raw_public.TestPublic) ... ok
test_boxnm (unit.test_raw_public.TestPublic) ... ok
test_gen (unit.test_raw_public.TestPublic) ... ok
test_scalarmult_rejects_wrong_length (unit.test_raw_public.TestPublic) ... ok
test_crypto_kdf_derive_from_key (unit.test_raw_random.TestRandomBytes) ... 
Aborted (core dumped)
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=134: cd 
/srv/build/python-libnacl-1.7.2/.pybuild/cpython3_3.9_libnacl/build; python3.9 
-m nose -v tests
dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:7: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Command `dpkg-buildpackage --changes-option=-DDistribution=bullseye` failed.
gbp:error: '/home/rrs/bin/gbp-pbuilder' failed: it exited with 2

***

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-libnacl depends on:
ii  libsodium23  1.0.18-1
pn  python   

python-libnacl recommends no packages.

python-libnacl suggests no packages.

Bug#988101: golang-testify: failing tests on armhf

[Ritesh Raj Sarraf]

Source: golang-testify
Version: 1.6.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org

Dear Maintainer,

While preparing the pacakge for a derivative distribution, I have come
to notice that the package's (some of the) tests, fail on the armhf
architecture.

The build failure snippet is below. I also noticed that the same has
been seen on the reproducible builds too.



=== RUN   TestBoolAssertionFunc
=== RUN   TestBoolAssertionFunc/true
=== RUN   TestBoolAssertionFunc/false
--- PASS: TestBoolAssertionFunc (0.00s)
--- PASS: TestBoolAssertionFunc/true (0.00s)
--- PASS: TestBoolAssertionFunc/false (0.00s)
=== RUN   TestErrorAssertionFunc
=== RUN   TestErrorAssertionFunc/noError
=== RUN   TestErrorAssertionFunc/error
--- PASS: TestErrorAssertionFunc (0.00s)
--- PASS: TestErrorAssertionFunc/noError (0.00s)
--- PASS: TestErrorAssertionFunc/error (0.00s)
PASS
ok  github.com/stretchr/testify/require 0.823s
=== RUN   TestPassedReturnsTrueWhenAllTestsPass
--- PASS: TestPassedReturnsTrueWhenAllTestsPass (0.00s)
=== RUN   TestPassedReturnsFalseWhenSomeTestFails
--- PASS: TestPassedReturnsFalseWhenSomeTestFails (0.00s)
=== RUN   TestSuiteRequireTwice
=== RUN   TestSuiteRequireTwice
=== RUN   TestSuiteRequireTwice/TestRequireOne
suite_test.go:42: 
Error Trace:suite_test.go:42
Error:  Not equal: 
expected: 1
actual  : 2
Test:   TestSuiteRequireTwice/TestRequireOne
=== RUN   TestSuiteRequireTwice/TestRequireTwo
suite_test.go:47: 
Error Trace:suite_test.go:47
Error:  Not equal: 
expected: 1
actual  : 2
Test:   TestSuiteRequireTwice/TestRequireTwo
--- FAIL: TestSuiteRequireTwice (0.03s)
--- FAIL: TestSuiteRequireTwice/TestRequireOne (0.01s)
--- FAIL: TestSuiteRequireTwice/TestRequireTwo (0.00s)
--- PASS: TestSuiteRequireTwice (0.03s)
=== RUN   TestSuiteRecoverPanic
=== RUN   TestPanicInSetupSuite
suite.go:63: test panicked: oops in setup suite
goroutine 21 [running]:
runtime/debug.Stack(0x842dbc, 0x2f5ab0, 0x390fc0)
/usr/lib/go-1.15/src/runtime/debug/stack.go:24 +0x78
github.com/stretchr/testify/suite.failOnPanic(0x904e00)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:63
 +0x3c
panic(0x2f5ab0, 0x390fc0)
/usr/lib/go-1.15/src/runtime/panic.go:969 +0x158
github.com/stretchr/testify/suite.(*panickingSuite).SetupSuite(0x915260)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite_test.go:63
 +0x38
github.com/stretchr/testify/suite.Run(0x904e00, 0x3966d8, 0x915260)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:118
 +0x45c
github.com/stretchr/testify/suite.TestSuiteRecoverPanic.func1(0x904e00)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite_test.go:108
 +0x40
testing.tRunner(0x904e00, 0x35343c)
/usr/lib/go-1.15/src/testing/testing.go:1123 +0xc8
created by testing.(*T).Run
/usr/lib/go-1.15/src/testing/testing.go:1168 +0x220
--- FAIL: TestPanicInSetupSuite (0.01s)
=== RUN   TestPanicInSetupTest
=== RUN   TestPanicInSetupTest/Test
suite.go:63: test panicked: oops in setup test
goroutine 23 [running]:
runtime/debug.Stack(0x89ed64, 0x2f5ab0, 0x390fc8)
/usr/lib/go-1.15/src/runtime/debug/stack.go:24 +0x78
github.com/stretchr/testify/suite.failOnPanic(0x904fc0)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:63
 +0x3c
panic(0x2f5ab0, 0x390fc8)
/usr/lib/go-1.15/src/runtime/panic.go:969 +0x158
github.com/stretchr/testify/suite.(*panickingSuite).SetupTest(0xa19940)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite_test.go:69
 +0x38
github.com/stretchr/testify/suite.Run.func1(0x904fc0)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:148
 +0x460
testing.tRunner(0x904fc0, 0xa33b30)
/usr/lib/go-1.15/src/testing/testing.go:1123 +0xc8
created by testing.(*T).Run
/usr/lib/go-1.15/src/testing/testing.go:1168 +0x220
--- FAIL: TestPanicInSetupTest (0.01s)
--- FAIL: TestPanicInSetupTest/Test (0.00s)
=== RUN   

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Control: retitle -1 unblock: open-iscsi/2.1.3-4

Hello Paul,

On Fri, 2021-04-30 at 22:00 +0200, Paul Gevers wrote:
> Hi,
> 
> On 30-04-2021 17:03, Ritesh Raj Sarraf wrote:
> > I will go ahead with the upload now and will untag this bug report
> > of
> > `moreinfo`.
> 
> That's not what I meant. I'll try to be more clear next time.
> 
> You're debdiff showed only the content of the open-iscsi binary
> package
> (which wasn't affected by your changes). My request was intended for
> *all* binary packages. You can get that by running debdiff on the
> changes files IIRC.

Attached are the diffs you requested. This time, I have not yet
uploaded the proposed package to Unstable. I will have for an
affirmation from the Release Team.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/1c/1d6be98cf8c560bc6460b875d465d58d6c4ced.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/6f/976fbb6002dc58eb3d0a5ea09d3e802e513a7d.debug

Control files of package iscsiuio: lines which differ (wdiff format)

Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package iscsiuio-dbgsym: lines which differ (wdiff format)
---
Build-Ids: [-6f976fbb6002dc58eb3d0a5ea09d3e802e513a7d-] 
{+1c1d6be98cf8c560bc6460b875d465d58d6c4ced+}
Depends: iscsiuio (= [-2.1.3-2)-] {+2.1.3-4)+}
Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package libopeniscsiusr: lines which differ (wdiff format)
---
Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package libopeniscsiusr-dbgsym: lines which differ (wdiff 
format)
--
Depends: libopeniscsiusr (= [-2.1.3-2)-] {+2.1.3-4)+}
Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package libopeniscsiusr-dev: lines which differ (wdiff format)
---
Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package open-iscsi: lines which differ (wdiff format)
--
Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package open-iscsi-dbgsym: lines which differ (wdiff format)
-
Depends: open-iscsi (= [-2.1.3-2)-] {+2.1.3-4)+}
Version: [-2.1.3-2-] {+2.1.3-4+}

Control files of package open-iscsi-udeb: lines which differ (wdiff format)
---
Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-udeb, 
libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), [-libopeniscsiusr,-] 
libsystemd0 (>= 247.3), [-udev,-] scsi-modules
Installed-Size: [-1220-] {+1341+}
Version: [-2.1.3-2-] {+2.1.3-4+}
diff -Nru open-iscsi-2.1.3/debian/changelog open-iscsi-2.1.3/debian/changelog
--- open-iscsi-2.1.3/debian/changelog	2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/changelog	2021-05-04 21:45:56.0 +0530
@@ -1,3 +1,18 @@
+open-iscsi (2.1.3-4) unstable; urgency=medium
+
+  * [8142984] Set architecture for build to linux-any. This ensures that the
+library is built on the right set of architectures and dh_makeshlibs is
+    invoked appropriately. (Closes: #987858)
+
+ -- Ritesh Raj Sarraf   Tue, 04 May 2021 21:45:56 +0530
+
+open-iscsi (2.1.3-3) unstable; urgency=medium
+
+  * [47645a5] Make open-iscsi-udeb compatible with d-i.
+Thanks to Cyril Brulebois (Closes: #987568)
+
+ -- Ritesh Raj Sarraf   Thu, 29 Apr 2021 13:43:35 +0530
+
 open-iscsi (2.1.3-2) unstable; urgency=medium
 
   * [c3b7109] Fix FTCBFS:
diff -Nru open-iscsi-2.1.3/debian/control open-iscsi-2.1.3/debian/control
--- open-iscsi-2.1.3/debian/control	2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/control	2021-05-04 21:00:04.0 +0530
@@ -139,13 +139,11 @@
 #   linux kernel udebs) must exist for these architectures - so
 #   check that before adding them to this list; the other
 #   scsi-(core|common|...)-modules are NOT sufficient!
-Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64 ppc64el s390x
+Architecture: linux-any
 Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport ind

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Fri, 2021-04-30 at 21:20 +0530, Ritesh Raj Sarraf wrote:
> 
> How would you like to see this fixed Cyril ?
> 
> The easiest option, if d-i supports, would be to extend architecture
> list to: `linux-any`, keeping it in line with what the actual open-
> iscsi package supports.

Here's what I've done. And propose.

rrs@priyasi:~/.../open-iscsi (wip/ritesh/fix-armel)$ git diff
master..HEAD
diff --git a/debian/changelog b/debian/changelog
index acfa52e..8365844 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+open-iscsi (2.1.3-4) unstable; urgency=medium
+
+  * [98b0d39] Add check for architectures where open-iscsi-udeb is
built
+  * [bf3d0f5] Add armel to support architecture for d-i
+
+ -- Ritesh Raj Sarraf   Fri, 30 Apr 2021 22:07:27
+0530
+
 open-iscsi (2.1.3-3) unstable; urgency=medium
 
   * [47645a5] Make open-iscsi-udeb compatible with d-i.
diff --git a/debian/control b/debian/control
index a69ce2c..3df235f 100644
--- a/debian/control
+++ b/debian/control
@@ -139,7 +139,7 @@ Package: open-iscsi-udeb
 #   linux kernel udebs) must exist for these architectures - so
 #   check that before adding them to this list; the other
 #   scsi-(core|common|...)-modules are NOT sufficient!
-Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
ppc64el s390x
+Architecture: amd64 arm64 armel armhf i386 ia64 mips mipsel powerpc
ppc64 ppc64el s390x
 Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
diff --git a/debian/rules b/debian/rules
index 60211b8..17ef5d8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -101,4 +101,9 @@ override_dh_missing:
dh_missing --fail-missing
 
 override_dh_makeshlibs:
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 ia64
mips mipsel powerpc ppc64 ppc64el s390x))
dh_makeshlibs --add-udeb=open-iscsi-udeb
+else
+   dh_makeshlibs
+endif
+



I noticed that d-i seems to have gained support for armel too. So my
proposed changes introduce support for armel. And the conditional check
also ensures to call the correct dh_makeshlibs on the respective host
architecture.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

The upload I prepped failed on some of the architectures.
https://buildd.debian.org/status/logs.php?pkg=open-iscsi=2.1.3-3

In d/control, there is:

```
Package: open-iscsi-udeb
# Note: the (virtual) udeb package scsi-modules (provided by different
#   linux kernel udebs) must exist for these architectures - so
#   check that before adding them to this list; the other
#   scsi-(core|common|...)-modules are NOT sufficient!
Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
ppc64el s390x
Section: debian-installer
Package-Type: udeb
```


The udeb package was introduced by Colin Watson from Ubuntu. I extended
the architecture list, based on the supported architectures by d-i. But
I really don't use or test this functionality of the package.


How would you like to see this fixed Cyril ?

The easiest option, if d-i supports, would be to extend architecture
list to: `linux-any`, keeping it in line with what the actual open-
iscsi package supports.





On Thu, 2021-04-29 at 13:36 +0530, Ritesh Raj Sarraf wrote:
> 
> Thank you. I find your reworded comment proper and have applied the
> same.
> 
> I will now work with the release team.
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Control: tag -1 +moreinfo +help

On Fri, 2021-04-30 at 21:02 +0530, Ritesh Raj Sarraf wrote:
> Control: tag -1 -moreinfo
> 
> On Fri, 2021-04-30 at 20:33 +0530, Ritesh Raj Sarraf wrote:
> > On Thu, 2021-04-29 at 22:19 +0200, Paul Gevers wrote:
> > > > The interim workaround is to ship the library into the open-
> > > > iscsi-
> > > udeb
> > > > package itself.
> > > 
> > > This looks acceptable, but could you please add a binary debdiff to
> > > this
> > > report to show the effect of the changes?
> > 
> > I guess I used the tool in the right way.
> > 
> > rrs@priyasi:.../Result$ debdiff /var/tmp/Chrome-Downloads/open-
> > iscsi_2.1.3-2_amd64.deb open-iscsi_2.1.3-3_amd64.deb
> > File lists identical (after any substitutions)
> > 
> > Control files: lines which differ (wdiff format)
> > 
> > Version: [-2.1.3-2-] {+2.1.3-3+}
> > 
> > 
> > 
> > I will go ahead with the upload now and will untag this bug report of
> > `moreinfo`.
> > 
> 
> The package has been uploaded to Debian Unstable now.
> 

And it has failed to build on some of the architectures. And that is
because, we have:

```
Package: open-iscsi-udeb
# Note: the (virtual) udeb package scsi-modules (provided by different
#   linux kernel udebs) must exist for these architectures - so
#   check that before adding them to this list; the other
#   scsi-(core|common|...)-modules are NOT sufficient!
Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
ppc64el s390x
Section: debian-installer
Package-Type: udeb
```

Let me work with the d-i team and come with a follow-up fix/upload.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Control: tag -1 -moreinfo

On Fri, 2021-04-30 at 20:33 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2021-04-29 at 22:19 +0200, Paul Gevers wrote:
> > > The interim workaround is to ship the library into the open-
> > > iscsi-
> > udeb
> > > package itself.
> > 
> > This looks acceptable, but could you please add a binary debdiff to
> > this
> > report to show the effect of the changes?
> 
> I guess I used the tool in the right way.
> 
> rrs@priyasi:.../Result$ debdiff /var/tmp/Chrome-Downloads/open-
> iscsi_2.1.3-2_amd64.deb open-iscsi_2.1.3-3_amd64.deb
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Version: [-2.1.3-2-] {+2.1.3-3+}
> 
> 
> 
> I will go ahead with the upload now and will untag this bug report of
> `moreinfo`.
> 

The package has been uploaded to Debian Unstable now.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

On Thu, 2021-04-29 at 22:19 +0200, Paul Gevers wrote:
> > The interim workaround is to ship the library into the open-iscsi-
> udeb
> > package itself.
> 
> This looks acceptable, but could you please add a binary debdiff to
> this
> report to show the effect of the changes?

I guess I used the tool in the right way.

rrs@priyasi:.../Result$ debdiff /var/tmp/Chrome-Downloads/open-
iscsi_2.1.3-2_amd64.deb open-iscsi_2.1.3-3_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Version: [-2.1.3-2-] {+2.1.3-3+}



I will go ahead with the upload now and will untag this bug report of
`moreinfo`.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package open-iscsi

[ Reason ]
With version 2.1.x of open-iscsi, a new library was introduced;
libopeniscsiusr. Since we ship a udeb variant of the open-iscsi package,
this library got pulled in into the open-iscsi-udeb package, adding a
depending on package libopeniscsiusr.

[ Impact ]
The open-iscsi-udeb package is not installable in the d-i environment
because of the unavailable respective udeb package for libopeniscsiusr.

The interim workaround is to ship the library into the open-iscsi-udeb
package itself. Nobody else is really making use of it. Post Bullseye,
I'll look into either shipping a new udeb for this library or building
the udeb variant of open-iscsi without support for this library, it is
allows.

[ Risks ]
The changes are trivial. We (Me and Cyril from d-i team) have validated
the effects of the change and do not see any breakage.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

I have not uploaded this revision of the package to Unstable yet. I will
do the upload after you review this change and give me a go ahead.
Thanks.

unblock open-iscsi/2.1.3-2
diff -Nru open-iscsi-2.1.3/debian/changelog open-iscsi-2.1.3/debian/changelog
--- open-iscsi-2.1.3/debian/changelog   2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/changelog   2021-04-29 13:43:35.0 +0530
@@ -1,3 +1,10 @@
+open-iscsi (2.1.3-3) unstable; urgency=medium
+
+  * [47645a5] Make open-iscsi-udeb compatible with d-i.
+Thanks to Cyril Brulebois (Closes: #987568)
+
+ -- Ritesh Raj Sarraf   Thu, 29 Apr 2021 13:43:35 +0530
+
 open-iscsi (2.1.3-2) unstable; urgency=medium
 
   * [c3b7109] Fix FTCBFS:
diff -Nru open-iscsi-2.1.3/debian/control open-iscsi-2.1.3/debian/control
--- open-iscsi-2.1.3/debian/control 2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/control 2021-04-29 13:42:24.0 +0530
@@ -144,8 +144,6 @@
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
diff -Nru open-iscsi-2.1.3/debian/rules open-iscsi-2.1.3/debian/rules
--- open-iscsi-2.1.3/debian/rules   2021-02-08 00:53:13.0 +0530
+++ open-iscsi-2.1.3/debian/rules   2021-04-29 13:42:24.0 +0530
@@ -69,6 +69,9 @@
dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start 
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
+   dh_install -p open-iscsi-udeb libopeniscsiusr/libopeniscsiusr*.so.* 
usr/lib/${DEB_HOST_MULTIARCH}
+
 override_dh_installinit:
dh_installinit -p open-iscsi --name=iscsid
dh_installinit -p open-iscsi
@@ -96,3 +99,6 @@
 
 override_dh_missing:
dh_missing --fail-missing
+
+override_dh_makeshlibs:
+   dh_makeshlibs --add-udeb=open-iscsi-udeb

Bug#987730: unblock: multipath-tools/0.8.5-1

[Ritesh Raj Sarraf]

Control: tag -1 -moreinfo

On Wed, 2021-04-28 at 21:49 +0200, Sebastian Ramacher wrote:
> > On Wed, 2021-04-28 at 22:50 +0530, Ritesh Raj Sarraf wrote:
> > >   [x] attach debdiff against the package in testing
> > > 
> > 
> > The revised debdiff patch is attached in this follow-up message.
> > The
> > initial patch was missing an important fix.
> 
> Please go ahead and remove the moreinfo tag once the new version is
> available in unstable.

Thank you Sebastian. I just uploaded the package to Unstable.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Thu, 2021-04-29 at 08:28 +0200, Cyril Brulebois wrote:
> OK, it's slighty different from the haveged package I mentioned that
> you
> could have taken as an example… but I think it should serve our
> purpose
> in a suitable fashion, so feel free to go ahead, thanks!
> 

In the interest of the limited time, I didn't really manage to look at
it.

> Regarding this comment:
> 
>     # We do this to keep the udeb in the installer happy
> 
> it's more about your executables being able to find the shared
> objects
> they need, the installer is neither happy nor unhappy. :D
> 
> I would expect the following to be a little more descriptive, but of
> course you keep whatever you find best. :)
> 
>     # Ship shared libraries along with the executable in a single
> udeb

Thank you. I find your reworded comment proper and have applied the
same.

I will now work with the release team.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,

On Wed, 2021-04-28 at 17:51 +0200, Cyril Brulebois wrote:
> > 
> > Why not just drop the dependency on udev and libopeniscsiusr
> entirely,
> > for the open-iscsi-udeb package ?
> 
> This is not sufficient:

Please review the attached patch. I build tested locally and the
results are below. If this looks good to you, then I'll prepare an
upload and ask the release team for an unblock.

I also opted to drop the explicit udev dependency.

rrs@priyasi:.../Result$ dpkg -I open-iscsi-udeb_2.1.3-2_amd64.udeb 
 new Debian package, version 2.0.
 size 248668 bytes: control archive=572 bytes.
 592 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-2
 Architecture: amd64
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 1341
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.


Thanks,
Ritesh
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
From b98d26b860ef7c989438d2641eaa5d2c514d2b51 Mon Sep 17 00:00:00 2001
From: Ritesh Raj Sarraf 
Date: Wed, 28 Apr 2021 22:13:39 +0530
Subject: [PATCH] Make open-iscsi-udeb compatible with d-i

In this change, we add libopeniscsiusr shared object explicitly to the udeb package to
avoid any reference to the libopeniscsiusr .deb package

We also add an override in shlibs generation

This oddity, that of open-iscsi-udeb shipping a library but open-iscsi
not shipping the library, is purely in the context of debian-installer

So, let's override and instruct mkshlibs to do the requested thing

And finally,
Drop explicit dependency on libopeniscsiusr and udev
---
 debian/control | 2 --
 debian/rules   | 6 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0a4627f..a69ce2c 100644
--- a/debian/control
+++ b/debian/control
@@ -144,8 +144,6 @@ Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
diff --git a/debian/rules b/debian/rules
index 10584dd..1152be3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -69,6 +69,9 @@ override_dh_auto_install:
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start sbin/iscsi-start
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.finish-install usr/lib/finish-install.d/10open-iscsi
 
+	# We do this to keep the udeb in the installer happy
+	dh_install -p open-iscsi-udeb libopeniscsiusr/libopeniscsiusr*.so.* usr/lib/${DEB_HOST_MULTIARCH}
+
 override_dh_installinit:
 	dh_installinit -p open-iscsi --name=iscsid
 	dh_installinit -p open-iscsi
@@ -96,3 +99,6 @@ override_dh_installdocs:
 
 override_dh_missing:
 	dh_missing --fail-missing
+
+override_dh_makeshlibs:
+	dh_makeshlibs --add-udeb=open-iscsi-udeb
-- 
2.31.1



signature.asc
Description: This is a digitally signed message part

Bug#987730: unblock: multipath-tools/0.8.5-1

[Ritesh Raj Sarraf]

Dear Release Team,

On Wed, 2021-04-28 at 22:50 +0530, Ritesh Raj Sarraf wrote:
>   [x] attach debdiff against the package in testing
> 

The revised debdiff patch is attached in this follow-up message. The
initial patch was missing an important fix.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
diff -Nru multipath-tools-0.8.5/debian/changelog multipath-tools-0.8.5/debian/changelog
--- multipath-tools-0.8.5/debian/changelog	2020-12-24 05:23:53.0 +0530
+++ multipath-tools-0.8.5/debian/changelog	2021-04-28 22:40:55.0 +0530
@@ -1,3 +1,10 @@
+multipath-tools (0.8.5-2) unstable; urgency=medium
+
+  * [373f5c5] Fix bashism in script kpartx/kpartx_id.
+Thanks to Julien Cristau (Closes: #987669)
+
+ -- Ritesh Raj Sarraf   Wed, 28 Apr 2021 22:40:55 +0530
+
 multipath-tools (0.8.5-1) unstable; urgency=medium
 
   [ Ritesh Raj Sarraf ]
diff -Nru multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
--- multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch	1970-01-01 05:30:00.0 +0530
+++ multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch	2021-04-28 22:40:55.0 +0530
@@ -0,0 +1,23 @@
+From: Ritesh Raj Sarraf 
+Date: Wed, 28 Apr 2021 22:06:50 +0530
+Subject: Fix bashism in kpartx_id script
+
+Thanks: Julien Cristau
+Closes: #987669
+---
+ kpartx/kpartx_id | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
+index c45db2f..18732e7 100755
+--- a/kpartx/kpartx_id
 b/kpartx/kpartx_id
+@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
+ else
+ echo "DM_TYPE=raid"
+ fi
+-if [[ $dmserial ]]; then
++if [ -n "$dmserial" ]; then
+ echo "DM_SERIAL=$dmserial"
+ fi
+ 
diff -Nru multipath-tools-0.8.5/debian/patches/series multipath-tools-0.8.5/debian/patches/series
--- multipath-tools-0.8.5/debian/patches/series	2020-12-24 05:23:53.0 +0530
+++ multipath-tools-0.8.5/debian/patches/series	2021-04-28 22:40:55.0 +0530
@@ -7,3 +7,4 @@
 0008-Bug-916521-FTCBFS-uses-the-wrong-pkg-config.patch
 0009-kpartx-rules-use-Debian-specific-partx-path.patch
 0010-multipath.rules-do-not-assume-usrmerged-paths.patch
+0010-Fix-bashism-in-kpartx_id-script.patch


signature.asc
Description: This is a digitally signed message part

Bug#987730: unblock: multipath-tools/0.8.5-1

[Ritesh Raj Sarraf]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package multipath-tools

[ Reason ]
It was discovered that one of the scripts, kpartx/kpartx_id, which
declares posix compatibility has a single line bashism

[ Impact ]
The script fails apart, under the condition where the bashism is used

[ Risks ]
Trivial, one-liner

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock multipath-tools/0.8.5-1

Please give me a Yes, and then I'll do the upload to Debian Unstable.
diff -Nru multipath-tools-0.8.5/debian/changelog 
multipath-tools-0.8.5/debian/changelog
--- multipath-tools-0.8.5/debian/changelog  2020-12-24 05:23:53.0 
+0530
+++ multipath-tools-0.8.5/debian/changelog  2021-04-28 22:40:55.0 
+0530
@@ -1,3 +1,10 @@
+multipath-tools (0.8.5-2) unstable; urgency=medium
+
+  * [373f5c5] Fix bashism in script kpartx/kpartx_id.
+Thanks to Julien Cristau (Closes: #987669)
+
+ -- Ritesh Raj Sarraf   Wed, 28 Apr 2021 22:40:55 +0530
+
 multipath-tools (0.8.5-1) unstable; urgency=medium
 
   [ Ritesh Raj Sarraf ]
diff -Nru 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
--- 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch 
1970-01-01 05:30:00.0 +0530
+++ 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch 
2021-04-28 22:40:55.0 +0530
@@ -0,0 +1,23 @@
+From: Ritesh Raj Sarraf 
+Date: Wed, 28 Apr 2021 22:06:50 +0530
+Subject: Fix bashism in kpartx_id script
+
+Thanks: Julien Cristau
+Closes: #987669
+---
+ kpartx/kpartx_id | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
+index c45db2f..2b0b1de 100755
+--- a/kpartx/kpartx_id
 b/kpartx/kpartx_id
+@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
+ else
+ echo "DM_TYPE=raid"
+ fi
+-if [[ $dmserial ]]; then
++if [ -n $dmserial ]; then
+ echo "DM_SERIAL=$dmserial"
+ fi
+ 
diff -Nru multipath-tools-0.8.5/debian/patches/series 
multipath-tools-0.8.5/debian/patches/series
--- multipath-tools-0.8.5/debian/patches/series 2020-12-24 05:23:53.0 
+0530
+++ multipath-tools-0.8.5/debian/patches/series 2021-04-28 22:40:55.0 
+0530
@@ -7,3 +7,4 @@
 0008-Bug-916521-FTCBFS-uses-the-wrong-pkg-config.patch
 0009-kpartx-rules-use-Debian-specific-partx-path.patch
 0010-multipath.rules-do-not-assume-usrmerged-paths.patch
+0010-Fix-bashism-in-kpartx_id-script.patch

Bug#987669: kpartx: bashism in /bin/sh script (kpartx_id)

[Ritesh Raj Sarraf]

On Tue, 2021-04-27 at 15:52 +0200, Julien Cristau wrote:
> 
> Apr 27 13:44:47 ubc-enc2bl10/ubc-enc2bl10 systemd-udevd[50553]:
> 'kpartx_id 254 29 mpath-3600c0ff00027786c559a785d0100'(err)
> '/lib/udev/kpartx_id: 96: /lib/udev/kpartx_id: [[: not found'
> 
> /lib/udev/kpartx_id has a /bin/sh shebang, [[ is a bashism, so should
> probably be replaced with the standard "test -n".


Maybe I'm doing something very silly. But I don't get the desired
output with "test -n"

rrs@priyasi:~$ cat /tmp/string.sh 
#!/bin/dash


x="Ritesh"
y=

if [ -n $x ]; then
echo Yes
fi

if [ -n $y ]; then
echo Yes
fi

test -n $x && echo Yes
test -n $y && echo Yes

rrs@priyasi:~$ /tmp/string.sh 
Yes
Yes
Yes
Yes


I rather propose this commit.

commit 7d3a38a2efd955e17b43edd43e866c8705f7d570 (HEAD -> patch-
queue/wip/ritesh/fix-bashism)
Author: Ritesh Raj Sarraf 
Date:   Wed Apr 28 22:06:50 2021 +0530

Fix bashism in kpartx_id script

Thanks: Julien Cristau
Closes: #987669

diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
index c45db2f8..e8448674 100755
--- a/kpartx/kpartx_id
+++ b/kpartx/kpartx_id
@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
 else
 echo "DM_TYPE=raid"
 fi
-if [[ $dmserial ]]; then
+if ! [ -z $dmserial ]; then
 echo "DM_SERIAL=$dmserial"
 fi
 


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,

On Sun, 2021-04-25 at 22:02 +0200, Cyril Brulebois wrote:
> but it seems the experimental uploads weren't fetched for some reason
> (I only glanced at git, didn't check what happened on the archive
> side).
> 
> Since the problem is about the dependency between the udeb and one of
> the library from the same package, a possibly easy fix could be to
> just
> ship the contents of the said library inside the udeb, along with the
> current contents.
> 
> That'd probably be about adjusting a .install file as opposed to
> adding
> a dedicated library udeb that would need some care for SONAME bumps,
> etc. (plus NEW of course).


That's an explicit dependency that got added in the merge I reviewed
for 2.1.2.

Why not just drop the dependency on udev and libopeniscsiusr entirely,
for the open-iscsi-udeb package ?

If you agree, then I can prepare an upload just dropping these.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987166: Description truncated

[Ritesh Raj Sarraf]

Control: tag -1 +pending

On Mon, 2021-04-19 at 23:13 +0200, Chris Hofstaedtler wrote:
> * Ritesh Raj Sarraf  [210419 21:12]:
> > > The package description appears truncated after "between".
> > 
> > If you have suggestions on how to extend it further, please do so.
> > My
> > english showed limitations in finding words to describe it.
> 
> I guess appending "them." would at least finish the sentence?

Thanks Chris. That does improve the description.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987185: SyntaxError: future feature annotations is not defined

[Ritesh Raj Sarraf]

Package: pristine-lfs
Version: 20210404.0-2
Severity: normal

Dear Andrej,

While installing another python package, I came across this error
reported about pristine-lfs package, which is why this bug report.



rrs@priyasi:~$ sudo apt install pypy3
[sudo] password for rrs: 
Sorry, try again.
[sudo] password for rrs: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  pypy3-lib
Suggested packages:
  pypy3-doc pypy3-tk
The following NEW packages will be installed:
  pypy3 pypy3-lib
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.1 MB of archives.
After this operation, 78.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian testing/main amd64 pypy3-lib amd64 
7.3.3+dfsg-3 [2,508 kB]
Get:2 http://deb.debian.org/debian testing/main amd64 pypy3 amd64 7.3.3+dfsg-3 
[9,596 kB]
Fetched 12.1 MB in 9s (1,380 kB/s)  


   
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
Selecting previously unselected package pypy3-lib:amd64.
(Reading database ... 409013 files and directories currently installed.)
Preparing to unpack .../pypy3-lib_7.3.3+dfsg-3_amd64.deb ...
Unpacking pypy3-lib:amd64 (7.3.3+dfsg-3) ...
Selecting previously unselected package pypy3.
Preparing to unpack .../pypy3_7.3.3+dfsg-3_amd64.deb ...
Unpacking pypy3 (7.3.3+dfsg-3) ...
Setting up pypy3-lib:amd64 (7.3.3+dfsg-3) ...
Setting up pypy3 (7.3.3+dfsg-3) ...
running pypy3 rtupdate hooks for 7.3
Failed to byte-compile /usr/lib/python3/dist-packages/pristine_lfs/errors.py:   
File "/usr/lib/python3/dist-packages/pristine_lfs/errors.py", line 10
from __future__ import annotations
^
SyntaxError: future feature annotations is not defined

Failed to byte-compile /usr/lib/python3/dist-packages/pristine_lfs/util.py:   
File "/usr/lib/python3/dist-packages/pristine_lfs/util.py", line 11
from __future__ import annotations
^
SyntaxError: future feature annotations is not defined



running pypy3 post-rtupdate hooks for 7.3
Processing triggers for man-db (2.9.4-2) ...
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
Scanning processes...   



Scanning candidates...  



Scanning processor microcode... 



Scanning linux images...




Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

Restarting services...
Service restarts being deferred:
 systemctl restart user@1000.service

No containers need to be restarted.

No user sessions are running outdated binaries.
15:57 ♒ ॐ ♅ ♄ ⛢ ☺ 




-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#987166: Description truncated

[Ritesh Raj Sarraf]

Hello Josh,

On Sun, 2021-04-18 at 11:46 -0700, Josh Triplett wrote:
> Package: libnss-unknown
> Version: 0.0.2-2+b1
> Severity: minor
> X-Debbugs-Cc: j...@joshtriplett.org
> 
> The package description appears truncated after "between".

well not really. That's an amend from the previous description, which
was much much shorter.

If you have suggestions on how to extend it further, please do so. My
english showed limitations in finding words to describe it.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

[Ritesh Raj Sarraf]

On Sun, 2021-03-21 at 23:57 +0100, Chris Hofstaedtler wrote:
> > While I don't test with sysvinit any more, I don't recollect
> > dropping
> > support for it. So if there's any specific issue, we could try to
> > resolve it.
> 
> TBF, if there's not going to be regular testing with sysvinit, maybe
> the support code for it should go away...?

Yes. If it becomes release critical.

OTOH, The shell script having issues shouldn't really be of major
concern. Because most majority of users have switched to systemd based
setups. Also our GR resolution encourages to provide best possible
support for both scenarios.

My wishful thought has always been that there will be other users in
Debian (and derivatives), who'd still have an interest in it
(sysvinit), and will report back issues and fixes too.

I see Ryutaroh bug report with that in mind only.


As for this bug report, the issue isn't really directly with open-
iscsi. Or at least, not to my knowledge. Only the invocation of a
systemd helper utility causes problems.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#983379: [PATCH] um: mark all kernel symbols as local

[Ritesh Raj Sarraf]

Hi,

Just a follow-up question on this fix.

Is it something that is a candidate for linux-stable ?


Thanks,
Ritesh

On Sat, 2021-03-06 at 16:21 +0530, Ritesh Raj Sarraf wrote:
> > > Marking all the symbols as local seems correct, and does seem
> > > to address the issue, so do that. Also do it for static link,
> > > nsswitch libraries could still be loaded there.
> > > 
> > > [1] https://bugs.debian.org/983379
> > > 
> > > Reported-by: Ritesh Raj Sarraf 
> > > Signed-off-by: Johannes Berg 
> > > ---
> > >   arch/um/kernel/dyn.lds.S | 6 ++
> > >   arch/um/kernel/uml.lds.S | 6 ++
> > >   2 files changed, 12 insertions(+)
> > > 
> > > diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S
> > > index dacbfabf66d8..2f2a8ce92f1e 100644
> > > --- a/arch/um/kernel/dyn.lds.S
> > > +++ b/arch/um/kernel/dyn.lds.S
> > > @@ -6,6 +6,12 @@ OUTPUT_ARCH(ELF_ARCH)
> > >   ENTRY(_start)
> > >   jiffies = jiffies_64;
> > >   
> > > +VERSION {
> > > +  {
> > > +    local: *;
> > > +  };
> > > +}
> > > +
> > >   SECTIONS
> > >   {
> > >     PROVIDE (__executable_start = START);
> > > diff --git a/arch/um/kernel/uml.lds.S b/arch/um/kernel/uml.lds.S
> > > index 45d957d7004c..7a8e2b123e29 100644
> > > --- a/arch/um/kernel/uml.lds.S
> > > +++ b/arch/um/kernel/uml.lds.S
> > > @@ -7,6 +7,12 @@ OUTPUT_ARCH(ELF_ARCH)
> > >   ENTRY(_start)
> > >   jiffies = jiffies_64;
> > >   
> > > +VERSION {
> > > +  {
> > > +    local: *;
> > > +  };
> > > +}
> > > +
> > >   SECTIONS
> > >   {
> > >     /* This must contain the right address - not quite the
> default
> > > ELF one.*/
> > > 
> 
> Tested on all 3 machines where the issue was seen before.
> 
> 
> > 
> > Acked-By: Anton Ivanov 
> 
> Tested-By: Ritesh Raj Sarraf 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#983379: [PATCH] um: mark all kernel symbols as local

[Ritesh Raj Sarraf]

On Fri, 2021-03-05 at 20:54 +, Anton Ivanov wrote:
> On 05/03/2021 20:43, Johannes Berg wrote:
> > From: Johannes Berg 
> > 
> > Ritesh reported a bug [1] against UML, noting that it crashed on
> > startup. The backtrace shows the following (heavily redacted):
> > 
> > (gdb) bt
> > ...
> >   #26 0x60015b5d in sem_init () at ipc/sem.c:268
> >   #27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-
> > gnu/libcom_err.so.2
> >   #28 0x7f8990ab8fb2 in call_init (...) at dl-init.c:72
> > ...
> >   #40 0x7f89909bf3a6 in nss_load_library (...) at
> > nsswitch.c:359
> > ...
> >   #44 0x7f8990895e35 in _nss_compat_getgrnam_r (...) at
> > nss_compat/compat-grp.c:486
> >   #45 0x7f8990968b85 in __getgrnam_r [...]
> >   #46 0x7f89909d6b77 in grantpt [...]
> >   #47 0x7f8990a9394e in __GI_openpty [...]
> >   #48 0x604a1f65 in openpty_cb (...) at arch/um/os-
> > Linux/sigio.c:407
> >   #49 0x604a58d0 in start_idle_thread (...) at arch/um/os-
> > Linux/skas/process.c:598
> >   #50 0x60004a3d in start_uml () at
> > arch/um/kernel/skas/process.c:45
> >   #51 0x600047b2 in linux_main (...) at
> > arch/um/kernel/um_arch.c:334
> >   #52 0x6000574f in main (...) at arch/um/os-
> > Linux/main.c:144
> > 
> > indicating that the UML function openpty_cb() calls openpty(),
> > which internally calls __getgrnam_r(), which causes the nsswitch
> > machinery to get started.
> > 
> > This loads, through lots of indirection that I snipped, the
> > libcom_err.so.2 library, which (in an unknown function, "??")
> > calls sem_init().
> > 
> > Now, of course it wants to get libpthread's sem_init(), since
> > it's linked against libpthread. However, the dynamic linker
> > looks up that symbol against the binary first, and gets the
> > kernel's sem_init().
> > 
> > Hajime Tazaki noted that "objcopy -L" can localize a symbol,
> > so the dynamic linker wouldn't do the lookup this way. I tried,
> > but for some reason that didn't seem to work.
> > 
> > Doing the same thing in the linker script instead does seem to
> > work, though I cannot entirely explain - it *also* works if I
> > just add "VERSION { { global: *; }; }" instead, indicating that
> > something else is happening that I don't really understand. It
> > may be that explicitly doing that marks them with some kind of
> > empty version, and that's different from the default.
> > 
> > Explicitly marking them with a version breaks kallsyms, so that
> > doesn't seem to be possible.
> > 
> > Marking all the symbols as local seems correct, and does seem
> > to address the issue, so do that. Also do it for static link,
> > nsswitch libraries could still be loaded there.
> > 
> > [1] https://bugs.debian.org/983379
> > 
> > Reported-by: Ritesh Raj Sarraf 
> > Signed-off-by: Johannes Berg 
> > ---
> >   arch/um/kernel/dyn.lds.S | 6 ++
> >   arch/um/kernel/uml.lds.S | 6 ++
> >   2 files changed, 12 insertions(+)
> > 
> > diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S
> > index dacbfabf66d8..2f2a8ce92f1e 100644
> > --- a/arch/um/kernel/dyn.lds.S
> > +++ b/arch/um/kernel/dyn.lds.S
> > @@ -6,6 +6,12 @@ OUTPUT_ARCH(ELF_ARCH)
> >   ENTRY(_start)
> >   jiffies = jiffies_64;
> >   
> > +VERSION {
> > +  {
> > +    local: *;
> > +  };
> > +}
> > +
> >   SECTIONS
> >   {
> >     PROVIDE (__executable_start = START);
> > diff --git a/arch/um/kernel/uml.lds.S b/arch/um/kernel/uml.lds.S
> > index 45d957d7004c..7a8e2b123e29 100644
> > --- a/arch/um/kernel/uml.lds.S
> > +++ b/arch/um/kernel/uml.lds.S
> > @@ -7,6 +7,12 @@ OUTPUT_ARCH(ELF_ARCH)
> >   ENTRY(_start)
> >   jiffies = jiffies_64;
> >   
> > +VERSION {
> > +  {
> > +    local: *;
> > +  };
> > +}
> > +
> >   SECTIONS
> >   {
> >     /* This must contain the right address - not quite the default
> > ELF one.*/
> > 

Tested on all 3 machines where the issue was seen before.


> 
> Acked-By: Anton Ivanov 

Tested-By: Ritesh Raj Sarraf 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

[Ritesh Raj Sarraf]

On Fri, 2021-03-05 at 12:05 +0900, Ryutaroh Matsumoto wrote:
> Hi Ritesh,
> CC: Debian init-system-helpers maintainers,
> 
> Thank you very much for spending your time on investigating this
> issue.
> I wonder if this issue should also be assigned to init-system-helpers
> package
> including deb-systemd-helper, for example, by the following commands
> 
>  clone 983737 -1
>  reassign -1 init-system-helpers  1.60
> 
> Your analysis of this issue seems indicating this is also an issue in
> init-system-helpers,
> though I am unsure. As init-system-helpers is one of very few
> "essential" packages,
> its bug must be identified and fixed before the release of Bullseye,
> if any.

I guess so. Rather than clone you could just reassign this bug to init-
system-helpers and see what the maintainers have to say about my
findings.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part