Bug#826576: Additional information

[Ron Murray]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry, I forgot to add some information. I'm running Debian Testing on
amd64, and the package details are:

Package: evolution
Version: 3.50.3-1
Priority: optional
Section: gnome
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmYjUTcACgkQEvfoZbXi
52FW3BAAm7G51p3eesI8Oic80o3Om1cXumi3Ry3CAt70u4dzZ7eSv/l/pSjgBp40
Q2Vkzi8ixb7tvAy2TobRP5M36e/BNypIUguxDT3TjwJdU0QRpTox9MrGaIcjWYbF
3u4+AQu6xL5SoYUY+CROkXI+qgcYXA36F23cYHQNmUbNV35O/1rN2C9YcO+qiXXR
+WKCP5erGePn6jwpRKDOri1FnCELzYgiy3U2qMglmxeABitEhvEFLMP7cV3h1xV3
sJlexs3SibHMGIjj1euOdP72JwSvENVHOwTrN4vPRJgUqsmgYpIinCfV+ZDpYPOw
IsUipFQPgj96c6KjM9QBweBwNfTnejNK1gtHfTzzSN+U+naznf1iBMqGRCgyT+2N
t7EF/Y5nOJH7RI/0zwc70VzsbEnJdKBmCYWcptE4e/PL350ax/kXSDbdAvanIc51
uVvZyuv9QCZhbgdhbkHZYocH43CTOew449kuhKiSy9AFKWD5GPNYviX1W5ZjV1V4
R+PzE9OncPIgEzmN1ph9u4dfB90kzl64OjPviL5xcazDTBj5wVUmzks3R6RlhV42
plFZhxs8Mhz2aCXfmlMZYKlDbvVtBEdd55CL/c9u1M5XOwSbpRyHzeqsOUcONgWD
Lz9s4f2pvNmyPT+VDhsZ3SrPJTFd5MB4CCx4fQWEf34DL3NoEsE=
=JnJj
-END PGP SIGNATURE-



-- 
Ron Murray  
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761 

Bug#1058563: Lots of "peer is not from a LAN" messages in syslog

[Ron Murray]

Package: minissdpd
Version: 1.6.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Looks like bugs #890584 and #901605 are back again. I'm getting lots
of "minissdpd[810]: peer xxx.xxx.xxx.xxx:y is not from a LAN"
messages in my syslog. The "peer" involved is my WiFi router, if that
helps, although this machine is on an Ethernet LAN.


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

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

Versions of packages minissdpd depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u3
ii  libnfnetlink0  1.0.2-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

minissdpd recommends no packages.

minissdpd suggests no packages.

- -- debconf information:
* minissdpd/start_daemon: true
  minissdpd/why_I_am_here:
  minissdpd/ip6: false
* minissdpd/listen: enp4s0 lxcbr0

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmV47FAOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52ErPw/8C+olh1a8fQ+2NGyXA9hd74SJJVhB+dINj2Fx
OZmwU5KFQ050ugU2UxKpLIgcZ24kn1SYHbejR+BcE+1hk+ToArByolvKAmg0T2xs
3cwcdB7r6q499WUuCUUaGtxsl80o9S9ii0IjAPjyj7a3a7EanHpj1gYykKdcxhVo
lpkRBVNx9If2t7d7wjwLnEoGJRHjRxntu+Xya35o4iCbWSmgGZP9Efiqxp99QNJI
w2zi3bd0m/H/oaBybI+qpC3YEvfbaUlRzHiFUy2y7c1DWo+C+fS46oFflCUTYMbN
pZRh8fPdo0TMo1ERNhMwGFhyhAekGc3X9bfvB0aMM5r/0RkrBmQyHJZjqNoLQIRI
YVZ6olV6pp6Dk/f2mIYk8IyLm5H6svvyYQbfOIE5iuhfarXnDmRwU09D/Fn9a3wO
Mdm48F5rSv1PaQPsdEDUzvhdADkEvMwBEOqk/9+fSkD5xHAU+/ED8/z2seD/6LrV
gmsnBSseOrGIrxJPwfCiypRiP/UTGkq5esxlCdjlLGJ+ab1C9fw7G/WJ7FMtxM4r
BFcjeElRxEaXCPSSx5D/FoVbhxmuuxGdGtF/iiqUUcmUYyZpttJxek/JlORZudKH
OISsK5jp3elgQSfs3OLAIrv+as+pgI4rXbirzYhfuwv6UJ2Kr5cr0IMlGXCZ/YND
v4pT3tc=
=XqIl
-END PGP SIGNATURE-

Bug#1053436: dhcpcd-base: dhcpcd stops listening on port 68 after several days

[Ron Murray]

I’ll try that later tonight.-- Ron Murray <r...@rjmx.net>PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761On 24 Oct 2023, at 15:28, Martin-Éric Racine  wrote:Next, try what's in Testing.On Tue, Oct 24, 2023 at 10:15 PM Ron Murray  wrote:It’s still happening. Currently running version 1:9.4.1-24~deb12u2. …..Ron--Ron Murray PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761On 9 Oct 2023, at 10:02, Martin-Éric Racine  wrote:Noted. If that still doesn't fix it, the next step is to try what's in Testing.Martin-Éricsu 8. lokak. 2023 klo 20.57 Ron Murray  kirjoitti:I've only just updated to that version. I'll let you know how it goes in a few days.--Ron Murray PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761Martin-Éric Racine wrote:On Tue, 03 Oct 2023 20:28:25 -0400 Ron Murray  wrote:Package: dhcpcd-baseVersion: 9.4.1-22Severity: normalDear Maintainer,  dhcpcd stops listening on udp port 68 after several days. Stilllistening on raw port 17. I've tried re-installing the package and Istill get the same result.Does this still apply to the package that just entered Stable via updates?Martin-Éric

Bug#1053436: dhcpcd-base: dhcpcd stops listening on port 68 after several days

[Ron Murray]

It’s still happening. Currently running version 1:9.4.1-24~deb12u2. …..Ron-- Ron Murray <r...@rjmx.net>PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761On 9 Oct 2023, at 10:02, Martin-Éric Racine  wrote:Noted. If that still doesn't fix it, the next step is to try what's in Testing.Martin-Éricsu 8. lokak. 2023 klo 20.57 Ron Murray <r...@rjmx.net> kirjoitti:
   


  

  
  
I've only just updated to that version. I'll let you know how it goes in a few days.-- Ron Murray <r...@rjmx.net>PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761Martin-Éric Racine wrote:On Tue, 03 Oct 2023 20:28:25 -0400 Ron Murray <r...@rjmx.net> wrote: Package: dhcpcd-base Version: 9.4.1-22 Severity: normal Dear Maintainer,   dhcpcd stops listening on udp port 68 after several days. Still listening on raw port 17. I've tried re-installing the package and I still get the same result.Does this still apply to the package that just entered Stable via updates?Martin-Éric
  

  

Bug#1053439: rsync: Please add support for specifying the SSH port used in SSH transfers

[Ron Murray]

Package: rsync
Version: 3.2.7-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   Please add support for specifying an SSH port other than 22 for SSH
transfers. The "--port=xxx" option only seems to affect rsync transfers.

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

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

Versions of packages rsync depends on:
ii  init-system-helpers1.65.2
ii  libacl12.3.1-3
ii  libc6  2.37-10
ii  liblz4-1   1.9.4-1
ii  libpopt0   1.19+dfsg-1
ii  libssl33.0.11-1
ii  libxxhash0 0.8.2-2
ii  libzstd1   1.5.5+dfsg2-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.08-1
ii  zlib1g 1:1.2.13.dfsg-3

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client   1:9.4p1-1
ii  openssh-server   1:9.4p1-1
ii  python3  3.11.4-5+b1
pn  python3-braceexpand  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmUcuqoOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52GQbw//UDSMfdB4waRUow/uTblDKgDMUPDwVFIbas0j
RmjFhe8Oj5SNzZrd340AsgkBZLeP0bGYVS/MtvfkCxutEDNnDtNmOfVHGkvuBQrZ
jvCKQ1T7kHRQJokTuRERm6zrS0hRWfZrYovd6KcRM70WAdMwCTGwFIiqHeYRGofa
jQz5TAUgKdbYRsoZM/VIRCb8P1d1mWW40O/1sGDyrHhxworU2J02VQQozo/CvaHt
OLakfl1/vAd/g2XwzFOwrc1ybIqjx6NWUMU5kV6HxTkPSBReBDXHsEWEJlzvQxes
3vGRmaT7d5oaJxERMtNMqJwk0JLkCzJL2SmOVVhgoX7t7Y9nvSAEbBn67BouOeON
LGcAvjOimjbdfiZcNcbHPX3+9H8is2qA3yjamtuTlQAbwIlD4qhgCUAuDBlrYcPy
pkmtV/L45pgzOtKuuCjL8OatLWCVBvDqRXmphydXaJ3K4WpW2HLO4stczdKlEZki
X/m6CB8HZ0qQfKBrII2jqCLc30afUVrwen9FCv5I6D7LRHELCuPyTBkd5cUVu4hb
LOsonBCGl1CZFe/F+/mvgm6Unv5YWM0lacrASXtBJK/iHbxMrtCCQ2tER5GIbl+b
qBIa80xpE3R7o0/SfVuHh0MhV6VIZYfyJiT1uQFQUzk/95l71qpA2j3ha9lf9TXn
+PM7fV8=
=ScwT
-END PGP SIGNATURE-

Bug#1053436: dhcpcd-base: dhcpcd stops listening on port 68 after several days

[Ron Murray]

Package: dhcpcd-base
Version: 9.4.1-22
Severity: normal

Dear Maintainer,

   dhcpcd stops listening on udp port 68 after several days. Still
listening on raw port 17. I've tried re-installing the package and I
still get the same result.

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

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

Versions of packages dhcpcd-base depends on:
ii  adduser   3.134
ii  libc6 2.36-9+deb12u3
ii  libudev1  252.12-1~deb12u1

Versions of packages dhcpcd-base recommends:
pn  wpasupplicant  

Versions of packages dhcpcd-base suggests:
pn  resolvconf | openresolv | systemd-resolved  

-- Configuration Files:
/etc/dhcpcd.conf changed:
allowinterfaces enp1s0
denyinterfaces enp3s0 enp4s4
ipv4only
debug
hostname
duid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
option interface_mtu
require dhcp_server_identifier
slaac private
nohook lookup-hostname, resolv.conf
noipv6rs# disable routing solicitation (says so in the 
man page)
interface enp1s0
ipv4only
interface enp3s0
ipv4only
static ip_address=192.168.14.1/23


-- no debconf information

Bug#1053286: tripwire segfaults during run

[Ron Murray]

Package: tripwire
Version: 2.4.3.7-4+b9
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

The latest version of tripwire segfaults during a run. I've taken an
strace, but it's over a Gb lond, and still over 100 Mb when tarred and
feathered. I'll try and attach the last couple of hundred lines.

I do note that the last couple of files that it was checking before it
failed were symlinks to other files
(/lib/x86_64-linux-gnu/libbsd.so.0 and
/lib/x86_64-linux-gnu/libmd.so.0), but I don't know whether that's
relevant or not.

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

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

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]1.5.82
ii  sendmail-bin [mail-transport-agent]  8.17.2-1

tripwire recommends no packages.

tripwire suggests no packages.

- -- Configuration Files:
/etc/tripwire/twpol.txt changed:
@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;
@@section FS
SEC_CRIT  = $(IgnoreNone)-SHa ; # Critical files that cannot change
SEC_BIN   = $(ReadOnly) ;# Binaries that should not change
SEC_CONFIG= $(Dynamic) ; # Config files that are changed
# infrequently but accessed
# often
SEC_LOG   = $(Growing) ; # Files that grow, but that
 # should never change ownership
SEC_INVARIANT = +tpug ;  # Directories that should never
# change permission or ownership
SIG_LOW   = 33 ; # Non-critical files that are of
 # minimal security impact
SIG_MED   = 66 ; # Non-critical files that are of
 # significant security impact
SIG_HI= 100 ;# Critical files that are
 # significant points of
 # vulnerability
(
  rulename = "Tripwire Binaries",
  severity = $(SIG_HI)
)
{
$(TWBIN)/siggen -> $(SEC_BIN) ;
$(TWBIN)/tripwire   -> $(SEC_BIN) ;
$(TWBIN)/twadmin-> $(SEC_BIN) ;
$(TWBIN)/twprint-> $(SEC_BIN) ;
}
(
  rulename = "Tripwire Data Files",
  severity = $(SIG_HI)
)
{
$(TWVAR)/$(HOSTNAME).twd-> $(SEC_CONFIG) -i ;
$(TWETC)/tw.pol -> $(SEC_BIN) -i ;
$(TWETC)/tw.cfg -> $(SEC_BIN) -i ;
$(TWETC)/$(HOSTNAME)-local.key  -> $(SEC_BIN) ;
$(TWETC)/site.key   -> $(SEC_BIN) ;
#don't scan the individual reports
$(TWVAR)/report -> $(SEC_CONFIG) (recurse=0) ;
}
(
  rulename = "Critical system boot files",
  severity = $(SIG_HI)
)
{
/boot   -> $(SEC_CRIT) ;
/lib/modules-> $(SEC_CRIT) ;
}
(
  rulename = "Boot Scripts",
  severity = $(SIG_HI)
)
{
/etc/init.d -> $(SEC_BIN) ;
/etc/rcS.d  -> $(SEC_BIN) ;
/etc/rc0.d  -> $(SEC_BIN) ;
/etc/rc1.d  -> $(SEC_BIN) ;
/etc/rc2.d  -> $(SEC_BIN) ;
/etc/rc3.d  -> $(SEC_BIN) ;
/etc/rc4.d  -> $(SEC_BIN) ;
/etc/rc5.d  -> $(SEC_BIN) ;
/etc/rc6.d  -> $(SEC_BIN) ;
/etc/systemd-> $(SEC_BIN) ;
}
(
  rulename = "Root file-system executables",
  severity = $(SIG_HI)
)
{
/bin-> $(SEC_BIN) ;
/sbin   -> $(SEC_BIN) ;
}
(
  rulename = "Root file-system libraries",
  severity = $(SIG_HI)
)
{
/lib-> $(SEC_BIN) ;
}
(
  rulename = "Security Control",
  severity = $(SIG_MED)
)
{
/etc/passwd -> $(SEC_CONFIG) ;
/etc/shadow -> $(SEC_CONFIG) ;
}
(
  rulename = "Root config files",
  severity = 100
)
{
/root   -> $(SEC_CRIT) ; # Catch all 
additions to /root
/root/.bashrc   -> $(SEC_CONFIG) ;
/root/.bash_profile -> $(SEC_CONFIG) ;
/root/.Xdefaults-> $(SEC_CONFIG) ;
/root/.Xauthority   -> $(SEC_CONFIG) -i ; # Changes Inode 
number on login
/root/.ICEauthority -> $(SEC_CONFIG) ;
}
(
  rulename = "Devices & Kernel information",
  severity = $(SIG_HI),
)
{
/dev-> $(Device) ;
}
(
  rulename = "Things that change all the time",
  severity = 0
)
{
/etc/cups/printers.conf   

Bug#1052008: gm2-13 Cannot Find Its Libraries At Link Time

[Ron Lovell]

Package: gm2-13
Version: 13.2.0-4
Severity: important
X-Debbugs-Cc: ron163...@startmail.com

Dear Maintainer,

Since the upgrade from gm2-12 to gm2-13, the link step fails:

/usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod
FAILED: topsort_m2
/usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2ios -o topsort_m2 ../topsort.mod
/usr/bin/ld: cannot find -lm2pim: No such file or directory
/usr/bin/ld: cannot find -lm2cor: No such file or directory
/usr/bin/ld: cannot find -lm2iso: No such file or directory
collect2: error: ld returned 1 exit status

As a temporary workaround, I modified my build flags to include the
subdirectories containing links to the shared libraries:

/usr/bin/gm2 -L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2pim/
-L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2cor/ -L/usr/lib/gcc/x86_64-linux-
gnu/13/m2/m2iso/ -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod

The GNU Modula-2 packages installed are:

gm2_4:13.2.0-1_amd64
gm2-13_13.2.004_amd64
libgm2-13-dev_13.2.0-4_amd64
libgm2-18_13.2.0-4_amd64


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

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

Versions of packages gm2-13 depends on:
ii  g++-13 13.2.0-4
ii  gcc-13-base13.2.0-4
ii  libc6  2.37-9
ii  libgcc-s1  13.2.0-4
ii  libgm2-13-dev  13.2.0-4
ii  libgmp10   2:6.3.0+dfsg-2
ii  libisl23   0.26-3
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.1-1
ii  libstdc++6 13.2.0-4
ii  libzstd1   1.5.5+dfsg2-1
ii  zlib1g 1:1.2.13.dfsg-3

gm2-13 recommends no packages.

gm2-13 suggests no packages.

-- no debconf information

Bug#1051513: emacs-common: Error "Deep recursion on subroutine ..." when updating emacs

[Ron Murray]

Package: emacs-common
Version: 1:29.1+1-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

It looks like Bug #477136 is back again.

I was updating emacs when I got these errors:

Performing actions...
(Reading database ... 2432913 files and directories currently 
installed.)
Removing elpa-muse (3.20+dfsg-7) ...
Remove elpa-muse for emacs
remove/muse-3.20: Handling removal of emacsen flavor emacs
dh-elpa: purging flavor specific files for emacs
Setting up emacs-gtk (1:29.1+1-5) ...
Deep recursion on subroutine
"main::generate_relevant_tsort_dependencies_internals" \
at /usr/lib/emacsen-common/lib.pl line 127.
tsort: -: input contains a loop:
tsort: apel
tsort: emacsen-common
Install a2ps for emacs
Install crypt++el for emacs

   Seems to be similar to bug #477136.



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

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

Versions of packages emacs-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  emacs-el 1:29.1+1-5
ii  emacsen-common   3.0.5
ii  init-system-helpers  1.65.2
ii  install-info 7.0.3-2

emacs-common recommends no packages.

Versions of packages emacs-common suggests:
ii  emacs-common-non-dfsg  1:29.1+1-1
ii  ncurses-term   6.4+20230625-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmT7jEAOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52EJag//R6zEcdIUbVABVWfLZfv8EYh7cvoyKE9QX616
qf88AEB4FjZ/LGKxlnEVHSrP8Bexnzfx2ACH5O6CzP0mjkMRgasSe76zteIEmyxV
/oRYThk+z+kq0+LK4AxQe/d6VGAJ7TcnWWZtB+6F1ZOna2AN9zowRXj0ljnsyUgX
ne58Ie/6M9YUEuKDORhNbZhZbL2mMh60fEO2fxs0moVRBjKaY3pBnaZh7pWJGOOG
GjrriyASzM+kncaJ5boXvL3tUP2H6iB+ZWaRPLd42WeAFHxqWbbG+RHK096q+D5d
WbNC9kpRsNoX3TgNn0Bjss+1GMYtJSQCGEXb4lz431kjzlpGxMklXaXyYNiZKctM
fB4ztMoYnHBR/i2MU+LeokIj6m8/Q1VLbg7FauF5kLP406ttum91VSdmbYh24oqx
onPF3zztyqhfBQvfdqQzCP6ipSD1N7xCPAb/2gzqfWZZzSJe+ns1t+Jlsikrzs5k
DAPJbsB4sGcyA5rkF+eWN/nKlNTGsnw7q8s/sBiWh/vuCrEkAsAwf3NTxW5mhpnz
8Niie6E9rdCNlMkkVim5KhPN3Zhepf4lrw0VncIpl8rqyVGzVRSd3og/zf0RCyWb
XWymKns38VfYxrxfAqDZW8A1cyMN2xP03zCuPVEFfOIMETMSeaA5j4fTzu3sVqeB
vKUuvLY=
=W0nt
-END PGP SIGNATURE-

Bug#1042872: command-not-found doesn't understand deb822 format in sources.list.d

[Ron Murray]

Package: command-not-found
Version: 23.04.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I have my own repository of packages I've created myself, and I
sign them with GPG. This means that Debian needs to have my public
key, which I've installed in /etc/apt/keyrings/rjmx.pub. Current
practice, according to sources.list(5), is to refer to this in
/etc/apt/sources.d/.sources. In my case, .sources is
"rjmx.sources". Here's its contents:

Types: deb deb-src
URIs: https://www.rjmx.net/Debian
Suites: local
Components: main
Signed-By: /etc/apt/keyrings/rjmx.pub

   This works fine for installing packages, and apt/aptitude etc have no
problem with it.

   However, if I mistype a program to run, I get this:

- -
$ noprog

WARNING:root:could not open file '/etc/apt/sources.list.d/rjmx.sources': Unable 
to parse section data

noprog: command not found
- -

   Thus it looks like command-not-found doesn't understand the deb822
format for files in sources.list.

 .Ron

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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.3
ii  lsb-release  12.0-2
ii  python3  3.11.4-5
ii  python3-apt  2.6.0

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmTJ5K4OHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52GACBAAp+GODecOE2VzoB/Lz0N1FIPNfTJWatbhFaEs
FR8DwdlJhSOQLxGQT8ThaxvgrY/0TGx4clad1FQU1lb3BomlRukdapu/31/t7V9H
3KwVgaxP4qtOf1fnNljGVe9rSIe+nRTKP3kNJPkujGV7fKZ562D/yTIiZIPfnSHc
uGHuEtJH5kaltL0Pj7tzdBROhXZq5PIfTLM6PqJpPuIJotOA9OxDteq+N//kNrmd
06l//cmzsf8wWq+HfHtt5aBagEo3vHeFSu8NfJwlTG5IeMMVtvV5Ep4xqC+eMcys
SsWWGTfPC0aK8Q7jxTOpJEcWZTv3wyEMRmZElMbFsTauH9xf3SNWzE9r5SP3xUvX
6TGjEOBTiP+3nZ7qQD/Mc6oOqx+LCFlhHmkXpmcrwn96iA5qlP+DHPF3zlGLB+26
ZxZ3OOlbByF0RA/I8A+jH6tAxYFKTbIbOqA73SnlWfzFD0m+1jK7vx8WaaTDRPCz
RouUHQYX/bla9cbJs4/yr/gE/x0++Y/4l9RahOolJ1+6idAdonrpzkjYfkjp8GYV
a8hjHuxKlfbKKUvX+voAWZ2xHyHKiqbFtzzdqFB/xx1VBckbQqYiuKLz+dem70Op
CC1473JNxSR+VlOjnZBfcDvp0kvN13aFbb1Z1ow6Os57WPivBV9z6te3MGAmKit3
0Q1GIY4=
=xBqX
-END PGP SIGNATURE-

Bug#1034036: galternatives doesn't set the default browser

[Ron Murray]

Package: galternatives
Version: 1.0.9
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I'm not sure what package to file this bug under, but I picked
galternatives because it's probably the most common way Debian users
(and others?) want to change default applications. Note that, as far
as I know, there's nothing wrong with galternatives itself: please
assign this bug to whichever package you consider to be most
appropriate.

   It all started when I installed the Vivaldi browser on my Debian
testing system. It worked fine in itself, but when I clicked on a link
in an email (using evolution and bluemail gave the same result), it
brought up vivaldi instead of my regular browser (Firefox). I checked
/etc/alternatives/x-www-browser, and it pointed to Firefox, just as
I'd set it. Still, clicking on email links brought up vivaldi instead
of Firefox.

   It's taken me quite some time to find out why this is happening. I
first discovered, using 'ps auxf', that the instance of vivaldi
brought up by clicking on an email link was called by
'/lib/systemd/systemd --user'. So systemd was involved. The plot
thickened.

   Today, I figured it out. Gnome. Now, I don't have Gnome installed
on my Debian testing box, but I installed it on a VM, and found that
gnome-control-center sets these things, *even when you don't have
Gnome installed*. I installed just gnome-control-center on my Debian
testing box, set it up as I wanted, and now clicking on an email link
brings up Firefox, as it's supposed to.

   This means that, for some default applications anyway,
galternatives is useless for setting them up, and, unless you have
gnome-control-center installed, there's no way to set them up at all.

   I'm not sure what the solution is here. Perhaps galternatives could
be modified to fix it, or perhaps a new application is in
order. Another alternative would be to install gnome-control-center at
all times, and provide instructions to use it if needed. (I don't
recommend this: the thing's ugly).

 .Ron Murray

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

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

Versions of packages galternatives depends on:
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  gir1.2-gtk-3.03.24.37-2
ii  python3   3.11.2-1
ii  python3-gi3.42.2-3+b1

Versions of packages galternatives recommends:
ii  pkexec   122-3
ii  python3-xdg  0.28-2

galternatives suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmQvSEkOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52Hm5w//VU59thhwWZgh1SoYF9+WleEsQUdacsSj+6m9
xMiHC83wiXDyXLA4TeYYD3qddIGTCr5dekgRrK4SX+ZF1a1YSdm3iw/NPXpFf8Yy
ASLhSU3b7FpzJjH+vmzCbQ6asYngmSRtLYGMgcbASh+0GgFQbZh9GsvBGJp3yu5x
Byrm5lUnu9gNZfGmAqSnsUhL9xJmpppvYKe3Ojknw1EXwMTKx/iCoNZDyzJ8bGO5
QsDrDPWKGK6O3tyTPEqYwaHN0PPw+1wJjGAEPhC8tAmO5dNtbLN0JDWtREiYG1Fv
9SUsmg3Jp//2bPfpqCOVrlm2obowmO8eV3R/4GL8mQDXmMMPTGRyI7nHDYn+hzLZ
89sCH32+vJ0i8if2yJP1lk938e9Yvko9gjKSnbB8Bz5aWiYtxMHbhWE5lTHJ1MrK
0IaaAbEcs4C/3bEPVyFtAVims/33+g6QgiOkQN48DJIQceLDymKFhxkR+9gcJ4OB
pOWsZN8E3A/6LnCxv0WdBqHvfl+rniwRwIP2Uk8A8SUxbiP1rVhmIS/eyJ1ARF3z
miAhOieNFpxwioba9EKRWknlA56qW5Aj19+yQOy7lhz3dRmHNWQH/WjH6ICBfznd
bGrAQxpnN/6PenJL21b5wqyEShzKv+g/CRSP/Ws9g7VHBjCdMNu+F14R0bAsXQXj
7B0CYp8=
=gwca
-END PGP SIGNATURE-

Bug#1021603: libpmix2

[Ron Lovell]

Should have said Arch Linux Issue 75727.

On Sun, Oct 16, 2022 at 5:20 PM Ron Lovell  wrote:

> Same issue as Arch issue 279267?
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#1021603: libpmix2

[Ron Lovell]

Same issue as Arch issue 279267?

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#1009890: Fixed

[Ron Murray]

It turns out that the problem is, in fact, in package qca2. 

When decrypting or signing a file, qca would invoke gpg with the
pinentry mode set to "loopback". This would normally cause gpg to ask
for a password on the console, but, of course, there isn't one in a GUI
application.

This patch sets the pinentry mode to "default" when we're decrypting or
signing, which should cause the normal pinentry dialog to be
displayed.

Tags: Patch provided

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

When decrypting or signing a file, qca would invoke gpg with the
pinentry mode set to "loopback". This would normally cause gpg to ask
for a password on the console, but, of course, there isn't one.

This patch sets the pinentry mode to "default" when we're decrypting
or signing, which should cause the normal pinentry dialog to be
displayed.

--- qca2-2.3.4.orig/plugins/qca-gnupg/gpgaction.cpp
+++ qca2-2.3.4/plugins/qca-gnupg/gpgaction.cpp
@@ -329,6 +329,7 @@ void GpgAction::start()
 extra = true;
 collectOutput = false;
 allowInput= true;
+		proc.needPass = true;
 if (input.opt_ascii)
 writeText = true;
 break;
@@ -341,6 +342,7 @@ void GpgAction::start()
 extra = true;
 collectOutput = false;
 allowInput= true;
+		proc.needPass = true;
 if (input.opt_ascii)
 readText = true;
 signing = true;
@@ -361,6 +363,7 @@ void GpgAction::start()
 extra = true;
 collectOutput = false;
 allowInput= true;
+		proc.needPass = true;
 if (input.opt_ascii)
 readText = true;
 signing = true;
--- qca2-2.3.4.orig/plugins/qca-gnupg/gpgproc/gpgproc.cpp
+++ qca2-2.3.4/plugins/qca-gnupg/gpgproc/gpgproc.cpp
@@ -27,6 +27,8 @@ using namespace QCA;
 
 namespace gpgQCAPlugin {
 
+bool GPGProc::needPass;
+
 void releaseAndDeleteLater(QObject *owner, QObject *obj)
 {
 obj->disconnect(owner);
@@ -166,7 +168,12 @@ void GPGProc::Private::setupArguments()
 QStringList fullargs;
 fullargs += QStringLiteral("--no-tty");
 fullargs += QStringLiteral("--pinentry-mode");
-fullargs += QStringLiteral("loopback");
+
+	// Change pinentry-mode if we need to get a passphrase from the user
+	if (needPass)
+		fullargs += QStringLiteral("default");
+	else
+		fullargs += QStringLiteral("loopback");
 
 if (mode == ExtendedMode) {
 fullargs += QStringLiteral("--enable-special-filenames");
@@ -459,6 +466,7 @@ GPGProc::GPGProc(QObject *parent)
 : QObject(parent)
 {
 d = new Private(this);
+	needPass = false;
 }
 
 GPGProc::~GPGProc()
--- qca2-2.3.4.orig/plugins/qca-gnupg/gpgproc/gpgproc.h
+++ qca2-2.3.4/plugins/qca-gnupg/gpgproc/gpgproc.h
@@ -64,6 +64,7 @@ public:
 void closeStdin();
 void closeAux();
 void closeCommand();
+	static bool needPass;
 
 Q_SIGNALS:
 void error(gpgQCAPlugin::GPGProc::Error error);


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

Bug#1016407: Solved

[Ron Murray]

   I found that I had all device_file options for sda, sdb and sdc in
~/.config/udiskie/config.yml set to "ignore: true". sdd was ok, and
that was where removeable drives ended up until I removed hard drives
sdb and sdc. Removeable drives then went to sdb, which was ignored.

   udiskie's "--verbose" mode helped solve this.

   You can close this bug now.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

Bug#1019464: qca2: Fails to build from source on amd64

[Ron Murray]

Source: qca2
Version: 2.3.4-1
Severity: normal
Tags: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

While trying to build qca2 from source, I get

- ---
   dh_install -O--builddirectory=build
   dh_installdocs -O--builddirectory=build
   dh_installchangelogs -O--builddirectory=build
   dh_installman -O--builddirectory=build
   dh_installsystemduser -O--builddirectory=build
   dh_lintian -O--builddirectory=build
   dh_perl -O--builddirectory=build
   dh_link -O--builddirectory=build
   dh_strip_nondeterminism -O--builddirectory=build
   dh_compress -O--builddirectory=build
   dh_fixperms -O--builddirectory=build
   dh_missing -O--builddirectory=build
dh_missing: warning: usr/lib/x86_64-linux-gnu/qca-qt5/crypto/libqca-gcrypt.so 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/lib/x86_64-linux-gnu/qca-qt5/crypto/libqca-nss.so 
exists in debian/tmp but is not installed to anywhere 
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libqca-qt5-2 (2), libqca-qt5-2-dev (5), 
libqca-qt5-2-plugins (5), libqca2-doc (1), qca-qt5-2-utils (3)
 * dh_installdocs: libqca-qt5-2 (0), libqca-qt5-2-dev (0), 
libqca-qt5-2-plugins (0), libqca2-doc (0), qca-qt5-2-utils (0)
 * dh_installman: libqca-qt5-2 (0), libqca-qt5-2-dev (0), 
libqca-qt5-2-plugins (0), libqca2-doc (0), qca-qt5-2-utils (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.

Remember to be careful with paths containing "x86_64-linux-gnu", where 
you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in 
debian/not-installed
to ensure it works on all architectures (see #961104).
dh_missing: error: missing files, aborting
make: *** [debian/rules:13: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
- -------

 .Ron


- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmMbxVEOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52E9HQ/8CoPP6GYMW/TkMNMncLKADmK5xhhFw/C8Z38B
unirfy+183UqqW8z1u25EReYpMXo1RJBVtwfhgXxZZYqFA3PJsBtUVvk456eGw3N
QkcRgruzxV7muXo/P9yYCjTj2JzxXf/4tjnS4Wu2kR0tvM6SH+rOET+6D1FIamzB
hOydOmCGbYsZRZdXut+Yymj7Ny0sful5JAA0O17rqF26JNjx3MMoiictQD7M1DlC
K4tpQ9LW7t5+GRpD0fTemPFZrNtQjfYAQTigCbCxVW/FIxcNiH44ulxBfte6oT/h
HteVXCrBERnDYHxMPt6rpxZ6iqTsbpWCGA5mHL2Ux4M0PI4JrHNYRYGbQSw9uGcf
gGAQ38vbIII/W+Zwy4emmzU9JAlfCrcmWBhRbIgQ9Vsb7/TGLYnxHdQ+CuM167QB
tgJSUq1b1n9wuz2zjCq/8e/z7Vs+HImeOn7Hqg9zGCtAiHHbaXGke5B9UwrrjbeR
2Om8PmEgqrHsmshErUaPwoouV1fO1375fu+YtQkibx9OGOsNN7k3HvMtATHgsb2l
T66oMlX71kJPDbBZqRPqulzFSIA0n6/Pj34qkb+Cz/F4JPMfZF99yg3yNkq6u/Vd
Yn/aFrkC9sTuWvFriD8dYLZclMVsCPsHxqLQiHVdP9Gviu35zOAHtpR6Ep3kTRNq
RONBuBg=
=SK6f
-END PGP SIGNATURE-

Bug#1017423: tripwire: Tripwire segfaults at start

[Ron Murray]

Package: tripwire
Version: 2.4.3.7-4+b2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   Starting tripwire with either --check or --test (at least) causes
it to segfault almost immediately. I would guess that the most likely
cause of this is the new version of libc6 that arrived in testing this
morning (a similar problem has been noted before: see bug #994910, for
example).

   Here's what I get when I run it in check mode:

> root:~# tripwire --check --interactive
> Software interrupt forced exit: Arithmetic Exception
> Software interrupt forced exit: Segmentation Fault
> root:~# 

   Here's an strace of the last few steps:

> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", 
> O_RDONLY|O_CLOEXEC) = 3
> read(3, 
> "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\\247\1\0\0\0\0\0"..., 832) 
> = 832
> newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=206640, ...}, AT_EMPTY_PATH) 
> = 0
> mmap(NULL, 209464, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
> 0x7f62929c7000
> mmap(0x7f62929c8000, 151552, PROT_READ|PROT_EXEC, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f62929c8000
> mmap(0x7f62929ed000, 40960, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 
> 3, 0x26000) = 0x7f62929ed000
> mmap(0x7f62929f7000, 16384, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2f000) = 0x7f62929f7000
> close(3)= 0
> mprotect(0x7f62929f7000, 8192, PROT_READ) = 0
> mprotect(0x7f62927ee000, 16384, PROT_READ) = 0
> mprotect(0x7f6292ca8000, 4096, PROT_READ) = 0
> prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, 
> rlim_max=RLIM64_INFINITY}) = 0
> --- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x7f6292750d85} ---
> write(2, "Software interrupt forced exit: "..., 53Software interrupt forced 
> exit: Arithmetic Exception
> ) = 53
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x421} ---
> write(2, "Software interrupt forced exit: "..., 51Software interrupt forced 
> exit: Segmentation Fault
> ) = 51
> exit_group(8)   = ?
> +++ exited with 8 +++

 .Ron Murray

- -- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


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

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

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]1.5.79
ii  sendmail-bin [mail-transport-agent]  8.17.1.9-1

tripwire recommends no packages.

tripwire suggests no packages.

- -- Configuration Files:
/etc/tripwire/twpol.txt changed:
@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;
@@section FS
SEC_CRIT  = $(IgnoreNone)-SHa ; # Critical files that cannot change
SEC_BIN   = $(ReadOnly) ;# Binaries that should not change
SEC_CONFIG= $(Dynamic) ; # Config files that are changed
# infrequently but accessed
# often
SEC_LOG   = $(Growing) ; # Files that grow, but that
 # should never change ownership
SEC_INVARIANT = +tpug ;  # Directories that should never
# change permission or ownership
SIG_LOW   = 33 ; # Non-critical files that are of
 # minimal security impact
SIG_MED   = 66 ; # Non-critical files that are of
 # significant security impact
SIG_HI= 100 ;# Critical files that are
 # significant points of
 # vulnerability
(
  rulename = "Tripwire Binaries",
  severity = $(SIG_HI)
)
{
$(TWBIN)/siggen -> $(SEC_BIN) ;
$(TWBIN)/tripwire   -> $(SEC_BIN) ;
$(TWBIN)/twadmin-> $(SEC_BIN) ;
$(TWBIN)/twprint-> $(SEC_BIN) ;
}
(
  rulename = "Tripwire Data Files",
  severity = $(SIG_HI)
)
{
$(TWVAR)/$(HOSTNAME).twd-> $(SEC_CONFIG) -i ;
$(TWETC)/tw.pol -> $(SEC_BIN) -i ;
$(TWETC)/tw.cfg -> $(SEC_BIN) -i ;
$(TWETC)/$(HOSTNAME)-local.key  -> $(SEC_BIN) ;
$(TWETC)/site.key   -> $(SEC_BIN) ;
#don't scan the individual reports
$(TWVAR)/report   

Bug#1016728: autoconf: _AC_PROG_CXX_STDCXX_EDITION_TRY test is broken due to typo

[Ron]

Package: autoconf
Version: 2.71-2
Severity: important
Tags: patch

Hi,

One of the changes to AC_PROG_CXX since 2.69 is that it now tries to
enable C++11 by default.  In most cases now that is a no-op since the
gcc default is already C++14, but I have some code that explicitly
forces -std=gnu++98 and which make it obvious this test is simply
failing "unnoticed" in the case where the compiler default isn't already
greater than C++11 ...

The problem is a simple typo in _AC_PROG_CXX_STDCXX_EDITION_TRY which
is fixed by the patch below.  Its correctness can be cross checked
against the behaviour and code of _AC_PROG_CC_STDC_EDITION_TRY where the
analogous variable is ac_cv_prog_cc_c$1 and which does work correctly
out of the box when the default (or explicitly set by CFLAGS) compiler
standard is something earlier than C11 ...

  Cheers,
  Ron



--- c.m4.orig   2022-08-06 18:54:47.444388264 +0930
+++ c.m42022-08-06 18:56:24.341810320 +0930
@@ -2749,8 +2749,8 @@
 [AC_REQUIRE([_AC_CXX_CXX$1_TEST_PROGRAM])]dnl
 [AS_IF([test x$ac_prog_cxx_stdcxx = xno],
 [AC_MSG_CHECKING([for $CXX option to enable C++$1 features])
-AC_CACHE_VAL(ac_cv_prog_cxx_$1,
-[ac_cv_prog_cxx_$1=no
+AC_CACHE_VAL([ac_cv_prog_cxx_cxx$1],
+[ac_cv_prog_cxx_cxx$1=no
 ac_save_CXX=$CXX
 AC_LANG_CONFTEST([AC_LANG_DEFINES_PROVIDED][$][ac_cxx_conftest_cxx$1_program])
 for ac_arg in '' m4_normalize(m4_defn([_AC_CXX_CXX$1_OPTIONS]))

Bug#1004589: Part of a solution for #1004589

[Ron Murray]

Much of this is still a problem in the current version in testing
(0.17.2-1). The paths to the binaries in the gnunet.conf file seems to
have been fixed, but the other two problems remain.

Levin's solution to the user problem (by putting the real username in
the .service file still works, but gnunet still barfs on the logfile
problem. The solution to that is to put the logfile in /var/log/gnunet.
The current version of gnunet creates this directory, with correct
permissions (0755 gnunet:gnunet), but doesn't update /etc/gnunet.conf
to fit. With that file set up like this:

[path]
GNUNET_HOME = /var/lib/gnunet/
GNUNET_DATA_HOME = /var/lib/gnunet/data/
GNUNET_RUNTIME_DIR = /var/run/gnunet/

[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = NO
OPTIONS = -l /var/log/gnunet/gnunet.log

   gnunet starts up fine.

 .Ron Murray



-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761



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

Bug#1016407: udiskie: udiske doesn't automount USB drives

[Ron Murray]

Package: udiskie
Version: 2.4.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

   Until recently, when I plugged a USB drive into my system, udiskie
would automount it under /media/, just as it's supposed
to. For the last week or so, it's not doing that any longer.

   I tried explicitly putting "--automount --notify" into its command
line, but that made no difference. One consequence of this problem is
that, if you run udiskie with "--smart-tray", as I do, the tray icon
never shows up. Worse, you can't use it to power down the external
device when you're finished with it.

   I was able to use udisksctl to mount and unmount drives, so udisks2
is probably not the problem.

   I note that neither udisks2 nor udiskie has been updated for some
time, and I haven't changed any of their config files. However, I do
note that a new version of dbus arrived a week or two back, so perhaps
the problem lies in that.

Thanks,

 .Ron Murray

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

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

Versions of packages udiskie depends on:
ii  python33.10.5-3
ii  python3-distutils  3.10.5-2
ii  python3-docopt 0.6.2-4
ii  python3-gi 3.42.1-1+b1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-yaml   5.4.1-1+b2
ii  udisks22.9.4-1

Versions of packages udiskie recommends:
ii  gir1.2-gtk-3.0  3.24.34-1
ii  gir1.2-notify-0.7   0.8.1-1
ii  gobject-introspection   1.72.0-1+b1
ii  notification-daemon 3.20.0-4+b1
ii  plasma-workspace [notification-daemon]  4:5.25.3.1-1
ii  python3-keyutils0.6-2+b6
ii  xfce4-notifyd [notification-daemon] 0.6.3-1

udiskie suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmLmJU4OHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52H6Mw/+JtpF0yUZulZ7u9j9XieJXr31rQOoByItwJpJ
BHV/vYxOrMuFwi8yLBhanOfGSCnn8sNRj2pTk2WnkjD14YfofggRk1siDlfFbjNM
tPNM1NZhFC/u3d1yRgNd6JkBNomi1vWsGTzbnTKkbENknjRznOFDralytMkt2YTm
zGUACavkTWQBqFgz7gR+7mFQevhdNb2iZgbrp4JahsopjF/RPEAJY021eobUjyR7
So5XkbwTc46esjC5i0cO0yI0yH8hgmcQx2EzE31DqeF/oMvRmreUfUk1PCHzvVur
VyRY1NYG19RBVpeLyji1tZAGqlSy+dczfhrp2p2P0Gp6qEQDFS31eDvywXobNktg
XjtQ/9ZF67RUPZFVzrFii7UZudso9AQYNPkgR3e/W2sJ8uXNtQJWoz3YSUR7i1iU
sm8yKCDSbOMW4W9IlF3HD7pSC72eVUmfaGqJ6rV8xlAkivlNmRc0NaNEDc5WNid7
hLYAimbEto/aLBEafKm1gOBXwRvyCT3bUkud6VaIb51dbzt9LCrFC1Tqzqq3kdUw
gZKQNA5iNCXKg5wDB0TkeUN+1iJ9YyfEdLCynt5UTetn2E+0F6EoX3afXk79E853
2IoJyBHSIQB3IvNnnimO4VrJPHeK/3SZNursq75xrEGD1xb7E/oBdIKQ5o6s9ruq
szbElqg=
=9xv8
-END PGP SIGNATURE-

Bug#1009890: libqca-qt5: QCA::startDecrypt() doesn't ask for a pass phrase

[Ron Murray]

Package: libqca-qt5-2
Version: 2.3.4-1
Severity: normal
File: libqca-qt5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I'm writing an app that can use PGP/GPG to encrypt entries, and,
since the rest of the app is written in Qt5, I chose to use QCA for
that part.

   My code (the relevant part, anyway) looks like this:

QByteArray message = content.toLocal8Bit();

QCA::OpenPGP gpg;
QCA::SecureMessage msg();

msg.startDecrypt();
msg.update(message);
msg.end();
msg.waitForFinished(-1);

   When I try to decrypt a GPG entry with this code, it returns
"ErrorUnknown", which I take to indicate that it doesn't have a
passphrase for the secret key. It certainly didn't ask for one.

   It is interesting, however, that if I use the command-line gpg to
decrypt a file using the same secret key (and get asked for a
pass phrase), I can go back to my app, try to decrypt the same PGP
entry again, and it works, because gpg-agent still contains the pass
phrase until it times out.

   So it seems that QCA can access pass phrases in gpg-agent, but it's
unable to request a pinentry from gpg-agent to collect a pass phrase
otherwise. I did manage to catch an invocation of gpg while my app was
decrypting a largish file, and perhaps that's relevant. It's

/usr/bin/gpg --no-tty --pinentry-mode loopback --fixed-list-mode \
- --with-colons --with-fingerprint --with-fingerprint --list-public-keys

   Looking through the documentation, I don't see anything related to
collecting pass phrases for secret keys, but it's possible that I
missed it. Please let me know if that's the case.

 .Ron

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

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

Versions of packages libqca-qt5-2:amd64 depends on:
ii  libc6 2.33-7
ii  libgcc-s1 12-20220319-1
ii  libqt5core5a  5.15.2+dfsg-16
ii  libstdc++612-20220319-1

Versions of packages libqca-qt5-2:amd64 recommends:
ii  ca-certificates   20211016
ii  libqca-qt5-2-plugins  2.3.4-1

libqca-qt5-2:amd64 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJfOwcOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52G3Ow//a+u92Kix9NZ17BhIvi86d3U076pDxMi+zMql
2T1UixZqTerckymfWiP63KYgV8FLFEZihdby2bgNYvgc17bmAcG6AL7/pAFwaQc2
6S2f+90nxggOCfyW+6BggkttIBZ5uJPVmdrjQnonk7cgpPn+NFHhpBMFcP1J0bFv
x7uvG/Q/NTjB+cpMvdyn1EuHDtxL+qimnCdPEvzUjmz1tVe0DlP0sXdRG2Wr+HwS
KKB5IzsDE2b2Ysa2N4alfYcQ0ioraD1Y9Xt1IU1jd0aRTEwwUmM655PMqNg6pCv7
mcBZH3Jf0+sPkxjR2NT+NyF7hbGg2JbMaxIINex9rWRXMG6TJDVDBvw6tWuzxnat
RJYPNWS82Y1ZOjNmkqAbVMmpaD7bT+s1wyd5I/NZE6Roviu+ubvohw2XI2PETwJy
XAds4jr96Oxy6VYvSWqdUoVYvy96EvnoMFLsYTy+nRjwva3qJbkKe0eWNknKs99s
CHsIvHQC6fqnFkuNRQsowVCDJAPHLz6M39f2Pw/RqvEH28qwFkguE2+rWjy6MP93
WTthn0aIVjrxw702qsf2s1eG9/BnY4RbHOhYpV3m4D5QYhg6D67MEuygnS+xJly8
mbG1XT52mnjCexqWU5kt9S7KhjPo7sj29P+/T3nvLdi+tZQAzxg31b62pmcNm+j8
eVgw0xE=
=ZfLf
-END PGP SIGNATURE-

Bug#1009827: plocate updatedb is not being run

[Ron Murray]

You're right, of course.

However, I'm the only user of this box, and I'd never heard of systemd
timers, or even plocate, until yesterday. I certainly don't recall
disabling it. Strange.

Anyway, let's see if it runs tonight, and if it does, we can close this
bug.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


On Mon, 2022-04-18 at 21:52 +0200, Steinar H. Gunderson wrote:
> On Mon, Apr 18, 2022 at 03:46:21PM -0400, Ron Murray wrote:
> > root@khufu:~# systemctl status plocate-updatedb.timer
> > ○ plocate-updatedb.timer - Update the plocate database daily
> > Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer;
> > disabled;
> > vendor preset: enabled)
> 
> The postinst script enables it (through dh_installsystemd), so this
> really
> indicates something or someone disabled it after installation.
> 
> /* Steinar */

Bug#1009827: plocate updatedb is not being run

[Ron Murray]

Here's what it says:

root@khufu:~# systemctl status plocate-updatedb.timer
○ plocate-updatedb.timer - Update the plocate database daily
Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; disabled;
vendor preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● plocate-updatedb.service

I noticed the "disabled" line, so I enabled it. Now it says

root@khufu:~# systemctl status plocate-updatedb.timer
○ plocate-updatedb.timer - Update the plocate database daily
Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; enabled;
vendor preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● plocate-updatedb.service

We'll see how it goes tonight.

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


On Mon, 2022-04-18 at 20:49 +0200, Steinar H. Gunderson wrote:
> On Mon, Apr 18, 2022 at 02:34:22PM -0400, Ron Murray wrote:
> >    The daily update.db job for plocate is not being run. Last time
> > it
> > ran on my system was December 30, 2021. Manual updates work fine.
> 
> What does systemd say about the timer? (E.g., sudo systemctl status
> plocate-updatedb.timer.)
> 
> /* Steinar */

Bug#1009827: plocate updatedb is not being run

[Ron Murray]

Package: plocate
Version: 1.1.15-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   The daily update.db job for plocate is not being run. Last time it
ran on my system was December 30, 2021. Manual updates work fine.

   This job should be run by systemd's timer system, but that doesn't
seem to be working for some reason, although other jobs (logrotate for
example) have been run successfully. systemd's timer system leaves its
timestamps in /var/lib/systemd/timers; the timestamp for
plocate-updatedb (indicating the last time that systemd ran it) is
dated December 30, 2021, same as the date of the last automatic run.

   The .service and .timer files for plocate-updatedb look ok to my
(admittedly untrained) eye. Permissions on them are identical to other
files in /lib/systemd/system, and I don't see any mention of plocate
(error or otherwise) in journalctl.

   It seems, then, that systemctl isn't running this job for some
reason, but not logging any errors.

 .Ron

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

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

Versions of packages plocate depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libstdc++6  12-20220319-1
ii  liburing2   2.1-2
ii  libzstd11.5.2+dfsg-1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv250.4-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJdrxsOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52EW5Q//YSH544LLZs4Br2TqVQQbbphi+v4OFOjKoBSr
H5B9zH+mVYQgKZPP3AEwwbsiaswDM4m+JiOMAiDR0n3+RTF+5KY3l6uy2uzA2dbx
XkRowTvD/XzfSCuBR5CZEnLTAZoQW42uiQ6hH/fdmqVmw7MDr5twMgHrfjpeGws+
sbQMWlu52nMAfcu1Dnfi7DtST2jX9Bs+2ItPmzKnvodldMItFRqzjPEKqzTnICa0
/OrWNeX1JKfvcAqmFqNp0WUh3htpY7GhCqUY/92mupr4dCibZMzvBl9A8PPEN8Eu
l/PkBKQDbT3OUQ48T1F8vtQP8wH0hSNuLCgkzfB77bedVzbpX4+t/OBMWkSIWfYF
9TxJZwTBKIcLuRHd+HO8UwkPjbX2Mo6i6c8BdlTWlkF18lktSYRoezSskjbQ1uyq
Hz6LBW66lfYCENNbXB/hoipYLKGgB3jsctr6w5XmTPcEseUjg69TXcdIkF6WSdaT
lDtT0Bt+r4BVtska2zJKEm4zJE7bzZIdmdD23EGzY/zn1cTYuYF+hIsRMlmI+2te
Z6WfyMbconPNIQ3yn2hsb/TNIwSvato8hcqAQ2vVzMISodekPxxHgU9er2Isj2Ps
haZXJoXuOF4QVriUcWxcoNG4WjCotti4IW5ZbCVdJHSviuOfLwQt+4OAa5cBHt8d
5rg1Vp0=
=l+qe
-END PGP SIGNATURE-

Bug#1009143: plocate: Similar issue here

[Ron Murray]

Yes. Once I've figured out what the problem is, I'll file another bug
report.

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


On Sun, 2022-04-17 at 23:27 +0200, Steinar H. Gunderson wrote:
> On Sun, Apr 17, 2022 at 04:39:30PM -0400, Ron Murray wrote:
> >    Sorry, perhaps I wasn’t too clear. Running updatedb manually
> > works fine.
> >    I just had to do it again. I think the only issue is the auto
> > update.
> 
> I think that should be on a different bug, then.
> 
> /* Steinar */

Bug#1009143: plocate: Similar issue here

[Ron Murray]

Ah.

   Sorry, perhaps I wasn’t too clear. Running updatedb manually works fine. I 
just had to do it again. I think the only issue is the auto update.

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761

> On Apr 17, 2022, at 16:14, Steinar H. Gunderson  wrote:
> 
> On Sun, Apr 17, 2022 at 04:07:21PM -0400, Ron Murray wrote:
>> I think the problem is that the cron.daily plocate job isn't being run.
>> I'd suspect the systemd timer doesn't work, but I'm not sure. I'll hack
>> the cron.daily/plocate script to save some diagnostic information, and
>> perhaps that'll help.
> 
> If so, I don't understand why running updatedb manually doesn't do anything.
> Perhaps there are multiple issues in play on the same bug number.
> 
> /* Steinar */
> -- 
> Homepage: https://www.sesse.net/

Bug#1009143: plocate: Similar issue here

[Ron Murray]

I think the problem is that the cron.daily plocate job isn't being run.
I'd suspect the systemd timer doesn't work, but I'm not sure. I'll hack
the cron.daily/plocate script to save some diagnostic information, and
perhaps that'll help.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


On Sun, 2022-04-17 at 21:38 +0200, Steinar H. Gunderson wrote:
> On Sat, Apr 09, 2022 at 07:50:09PM -0400, Ron Murray wrote:
> >    Steinar, you may be right about problems with the upgrade. I
> > started
> > looking into this earlier today because 'locate' couldn't find
> > files
> > that I knew were present in the filesystem. Based on what you said,
> > I
> > checked plocate.db and siscovered that it hadn't been updated since
> > December 30. The files I was looking for had, of course, been added
> > since then.
> 
> That's strange; do you know if the updatedb.plocate command was ever
> actually
> run? Did it output anything to the error log?
> 
> I've tried reproducing this by installing mlocate and then upgrading,
> but I can't get it to break.
> 
> >    I also note that there's still a 'locate' in /etc/cron.daily,
> > which
> > runs '/usr/bin/updatedb.findutils'. Should these be still on the
> > sysytem? Could they be interfering with plocate?
> 
> No, it's entirely independent.
> 
> /* Steinar */

Bug#1009283: caffeine fails immediately on starting

[Ron Murray]

Package: caffeine
Version: 2.9.10-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   caffeine does't come up when I try to start it. Here's what happens
when I try to start it from the command line:

- ---
ron@khufu:~$ caffeine
Gtk-Message: 20:20:56.219: Failed to load module "xapp-gtk3-module"
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 1.16.0-unknown is an invalid version and will 
not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 2.9.0.Odd.Olm is an invalid version and will 
not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an 
invalid version and will not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: -VERSION- is an invalid version and will not be 
supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
PkgResourcesDeprecationWarning: 
2.0.5-build-libtorrent-rasterbar-Cemion-libtorrent-rasterbar-2.0.5-bindings-python
 is an invalid version and will not be supported in a future release
  warnings.warn(
Traceback (most recent call last):
  File "/usr/bin/caffeine", line 35, in 
parser.add_argument('-V', '--version', action='version', 
version=PROGRAM_NAME + ' ' + pkg_resources.require(PROGRAM_NAME)[0].version)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 891, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 777, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'caffeine' distribution was not found 
and is required by the application
- ---

Thanks,

 .Ron

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

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

Versions of packages caffeine depends on:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.90-8
ii  gir1.2-gtk-3.0   3.24.33-1
ii  python3  3.9.8-1
ii  python3-ewmh 0.1.6-2
ii  python3-gi   3.42.0-3
ii  python3-pkg-resources59.6.0-1.2
ii  python3-xlib 0.29-1
ii  xdg-utils1.1.3-4.1

caffeine recommends no packages.

caffeine suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJTdiAOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52FYgxAAnSOJndCgg2LMctcugJ98f8YtjpnJAmmdhExG
jZ2CSsIYAfc8JXfgzDnV0qH4SOQznPornaec5jrzBX3sOTu9x7W1yUDmV1SO6LXs
qY8JI3PIltOF39eSoGgJnecApHueZq3GFdXXXqWPMCzY1/XglGGImBvJn76otJM1
nnj9RG9ps+n/MVXj8mx1g/6BU8l6ee93dGK1ltKG8X1hfmjog36eludsrnmIrWDN
zqWiFfk6XwBFCOwsHFQy+z9lIMf33ozH94cL9vjnMlay1Xqskjy4B+44BmErdLRd
ZSSrjyKzdYiIwU0JaO91alQ4fLMs/Fw9WDA9j/y/pEQHIjlq61urwm7jvGz8QjTn
2v6pNwq79f+JGtbADd/jlAu7/081T5pF8YHDEI1CdPuGm4r4f9KF2XIm5zf6JUy4
M56hSOJJ2asQj9Z/fXoBspHeHWhb+eBaoglmHaVykYxaDbYTQtjx0DnZFW9Gtfmu
dAPyw35hoGheAyfMQo9fXdcayMEhce0KR256anAOvhPEwKsYmHRbcrfI7yK1rY4I
mAP31W0Zjp8oGmbmX7fY1xPLRGSNnhPyR/iXqZA0FFUgN57MYMG5NPeNvVmeA3tf
QSMqNitMZnPD77N+uaWRMBpGIzBeTbk7MrM9U8d0kc1EcIUp2tqRw9aak9lK3k8p
BN4I0OA=
=28WY
-END PGP SIGNATURE-

Bug#1009143: plocate: Similar issue here

[Ron Murray]

Package: plocate
Version: 1.1.15-2
Followup-For: Bug #1009143

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

   Steinar, you may be right about problems with the upgrade. I started
looking into this earlier today because 'locate' couldn't find files
that I knew were present in the filesystem. Based on what you said, I
checked plocate.db and siscovered that it hadn't been updated since
December 30. The files I was looking for had, of course, been added
since then.

   So I rm'd plocate.db and ran updatedb, and now plocate can find
files.

   It seems, then, that the plocate database is not being updated (at
least on my box, anyway. I'm not sure of the exact cause of this
problem. I looked at 'plocate' in /etc/cron.daily, and noted that it
relies on systemd to launch updatedb using the timer function. I'm not
too familiar with that function (yet), but there seems to be a
plocate-updatedb.timer file in
/lib/systemd/system/plocate-updatedb.timer, echoed in other places.

   I also note that there's still a 'locate' in /etc/cron.daily, which
runs '/usr/bin/updatedb.findutils'. Should these be still on the
sysytem? Could they be interfering with plocate?

Thanks,

 .Ron

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

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

Versions of packages plocate depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libstdc++6  12-20220319-1
ii  liburing2   2.1-2
ii  libzstd11.4.10+dfsg-1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv250.4-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJSG6AOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52Ej5RAArhBI7eazbkL0u767wc/EN1Bq1n2Hm7Eu/+/d
ja3YG+a8yT3oFCqMNvn8wzAp65AGnwQCQkm/2/MVyKYbR0z6CBUszRfGXDFvBSLn
fypPhSO6McE4HMGDuH/iN/a94kILGqX6/C/wUVACcKVPogn8W+Me4qz29gKB1E9U
fm07NT3riao7jgZxDJWKlG990Cg/sp0Wzn3CBnsB/0BdQK3WPbpAmMPw1I1BvRyq
WyR5zm5jeeBId04eC01ddvt29oGFSlSWQABufItviQH3JEo/vFUhu/6Uo89hsjO0
47CRSNZpNAqpwA3bEO51eH9j4DrPqp2tBAuchq5wcBIenJ++hd0ywADggpB4YWrS
Hv7HophbGI7wEUIWx40XvSea/5wNVJPOcGHXLAg9rhemERvNNcqk+lIiUL2mK4aw
6BOSswbvD4HxTvUMyxdWCn974Kuu8vRYbaVRMNyL1wZEgAG6PToFCML3WYthH2iS
8r2vutssqhHXaYzuOXtVvM5XtWyoBwwQMXnTqN9DuY9wQ/KgNRfji/CJ2+iUXfJu
0mXYUutZGK4bJqzy/BjBGcW75sPGqvdAiCNJM1XAlRqX7uWCzP5Bw2GSRSI7F5yg
fXC6XFEKNyPk+o5Nz7rAJwrEFBqJrhiZYpbiz106tJ7rXz9r2e11mBmyEsNa5tNL
mWZbmB4=
=CcIJ
-END PGP SIGNATURE-

Bug#1007103: Rosegarden: malloc_consolidate(): unaligned fastbin chunk detected

[Ron Murray]

I have the same problem here. Removing lmms and fluidsynth-dssi made no
difference.

I did a debug build and ran it with gdb. The resullt is attached.


-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from rosegarden...
(gdb) r
Starting program: 
/home/ron/wombat/Debian/rosegarden/rosegarden-21.12/obj-x86_64-linux-gnu/rosegarden
 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7126c640 (LWP 1582992)]
[main] System Locale: "en_US"
[main] Qt translations path:  "/usr/share/qt5/translations"
[main] Qt translations loaded successfully.
[main] RG Translation: trying to load :locale/ "en_US"
[main] RG Translations loaded successfully.
[main] Loaded application icon " "rg-rwb-rose3-16x16" "
[main] Loaded application icon " "rg-rwb-rose3-32x32" "
[main] Loaded application icon " "rg-rwb-rose3-48x48" "
[main] Loaded application icon " "rg-rwb-rose3-64x64" "
[main] Loaded application icon " "rg-rwb-rose3-128x128" "
[main] Unbundling examples...
[main] Unbundling templates...
[main] Unbundling libraries (device files)...
[New Thread 0x7fffe7a9b640 (LWP 1583819)]
[main] Creating RosegardenMainWindow instance...
[New Thread 0x7fffe711d640 (LWP 1584216)]
[SequencerThread] run()
[New Thread 0x7fffe691c640 (LWP 1584223)]
[PluginFactory] PluginFactory::instance( "dssi" ): creating new 
DSSIPluginFactory
[JackDriver] initialise() begin...
[New Thread 0x7fffe611b640 (LWP 1584314)]
[New Thread 0x7fffe5f26640 (LWP 1584322)]
[JackDriver] initialise() - JACK sample rate =  48000 Hz, buffer size =  1024
[JackDriver] initialise() - creating disk thread...
[New Thread 0x7fffe5cef640 (LWP 1584368)]
[New Thread 0x7fffe59aa640 (LWP 1584372)]
[JackDriver] initialise() - found  6  JACK physical outputs
[JackDriver] initialise() - connecting from  " rosegarden:master out L " to " 
system:playback_1 "
[JackDriver] initialise() - connecting from  " rosegarden:master out R " to " 
system:playback_2 "
[JackDriver] initialise() - found  2  JACK physical inputs
[JackDriver] initialise() - connecting from  " system:capture_1 " to " 
rosegarden:record in 1 L "
[JackDriver] initialise() - connecting from  " system:capture_2 " to " 
rosegarden:record in 1 R "
[JackDriver] initialise() - initialised JACK audio subsystem
malloc_consolidate(): unaligned fastbin chunk detected

Thread 5 "QThread" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe691c640 (LWP 1584223)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x75fe8546 in __GI_abort () at abort.c:79
#2  0x7603feb8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7615da78 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3  0x7604791a in malloc_printerr
(str=str@entry=0x7615fde8 "malloc_consolidate(): unaligned fastbin 
chunk detected") at malloc.c:5628
#4  0x760489c4 in malloc_consolidate (av=av@entry=0x7fffdc20) at 
malloc.c:4709
#5  0x7604a855 in _int_malloc (av=av@entry=0x7fffdc20, 
bytes=bytes@entry=1218) at malloc.c:3924
#6  0x7604d191 in __libc_calloc (n=, 
elem_size=) at malloc.c:3639
#7  0x77fd8431 in calloc (b=1, a=) at 
../include/rtld-malloc.h:44
#8  _dl_new_object
(realname=realname@entry=0x7fffdc1d9230 "/usr/lib/dssi/whysynth.so", 
libname=libname@entry=0x7fffdc1a3e30 "/usr/lib/dssi/whysynth.so", 
type=type@entry=2, loader=loader@entry=0x0, mode=mode@entry=-1879048191, 
nsid=nsid@entry=0)
at dl-object.c:89
#9  0x77fd42fa in _dl_map_object_from_fd
(name=name@entry=0x7fffdc1a3e30 "/usr/lib/dssi/whysynth.so", 
origname=origname@entry=0x0

Bug#1005870: Unable to activate singularity container from within boot service script

[Fox, Ron]

Thanks for your work.  I’m able to activate containers from within  a script 
run at boot time.  The update did the trick.


Ron.


Ron Fox
Senior Scientist
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824, USA
Tel. 517-908-7349
Email: f...@frib.msu.edu

[cid:image001.jpg@01D823DD.5CA436C0]



From: Nilesh Patra<mailto:nil...@nileshpatra.info>
Sent: Sunday, February 27, 2022 1:54 AM
To: Fox, Ron<mailto:f...@nscl.msu.edu>
Cc: 1005...@bugs.debian.org<mailto:1005...@bugs.debian.org>
Subject: Re: Unable to activate singularity container from within boot service 
script

[EXTERNAL] This email originated from outside of FRIB

On Wed, Feb 23, 2022 at 11:50:30PM +, Fox, Ron wrote:
> Thank you we'll give it a try as soon as it migrates out to our internal 
> mirrors.

Ron,
Any update on this - if it is there on your internal servers by now?

Regards,
Nilesh

Bug#1005870: Unable to activate singularity container from within boot service script

[Fox, Ron]

We just got it Friday I'll test this tomorrow thanks.
Ron

On Feb 27, 2022 01:54, Nilesh Patra  wrote:
[EXTERNAL] This email originated from outside of FRIB

On Wed, Feb 23, 2022 at 11:50:30PM +, Fox, Ron wrote:
> Thank you we'll give it a try as soon as it migrates out to our internal 
> mirrors.

Ron,
Any update on this - if it is there on your internal servers by now?

Regards,
Nilesh

Bug#1005870: Unable to activate singularity container from within boot service script

[Fox, Ron]

Thank you we'll give it a try as soon as it migrates out to our internal 
mirrors.

RF

On Feb 23, 2022 14:12, Nilesh Patra  wrote:
[EXTERNAL] This email originated from outside of FRIB


On Wed, 16 Feb 2022 12:58:57 + "Fox, Ron"  wrote:

>  On Debian 11 note this comes from debian-unstable.

> I am attempting to activate a singularity squashfs image from a script that 
> runs

> at boot time.   Singularity segfaults with the attached debug/traceback in

> the attached file portmanager

>

> Here is the tail of that file in case the bug reporting system does not 
> support attachments:

> [...]



There has been a new release that was uploaded to unstable a few hours ago.

Can you please check with this one if the problem still persists?



Regards,

Nilesh

Bug#1006197: gpg hangs when importing keys with "gpg: waiting for lock (held by xxxxxxx) (deadlock?)"

[Ron Murray]

   After thinking about this a little more, I wondered whether the
trust db may have been corrupted (even a "list-keys" took a long time,
displaying messages about the trust db. Some Googling led me to the "--
update-trustdb" for gpg. It took a while to run, but it seems to have
fixed the problem.

   You can probably close this bug.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761



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

Bug#1006197: gpg hangs when importing keys with "gpg: waiting for lock (held by xxxxxxx) (deadlock?)"

[Ron Murray]

Package: gpg
Version: 2.2.27-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   When importing public keys, gpg hangs for several minutes with
something like

gpg: waiting for lock (held by 1308345) (deadlock?) ...

   Process 1308345, in this case, was

1308345 ?RL gpg --disable-dirmngr --batch --no-sk-comments 
--status-fd 21 --no-tty --charset utf8 --enable-progress-filter 
--exit-on-status-write-error --display :0.0 --logger-fd 25 --with-colons 
--with-secret --with-keygrip --list-keys --

   ... and the only other gpg process was

1307658 pts/2SL+0:00 gpg --edit-key 
5B80C5754298F0CB55D8ED6ABCEF7E294B092E28

   I first noticed this problem almost a year ago, but didn't report
it at the time. I looks to me as if process 1308345 is waiting for an
input, but I don't see any prompts or dialog boxes.

   Problem seems to time out eventually, so importing keys is still
(vaguely) possible, so I'm leaving this report marked as "normal".

Thanks,

 .Ron

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

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

Versions of packages gpg depends on:
ii  gpgconf2.2.27-3
ii  libassuan0 2.5.5-1
ii  libbz2-1.0 1.0.8-5
ii  libc6  2.33-6
ii  libgcrypt201.9.4-5
ii  libgpg-error0  1.43-3
ii  libreadline8   8.1.2-1
ii  libsqlite3-0   3.37.2-2
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gpg recommends:
ii  gnupg  2.2.27-3

gpg suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmIS9oYOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52HiAg//eEasBs7zU9MefiCFcmgtg6Oi6hxPkYPlAgrH
b4BA3owGigPA/tEcAoDkY7IfKdslMrPGwV3JWCMh38dE10/yiQ5aAaaw892R+iYL
mIPYoirWFiiaAW5oIFCiYf4JKLi6a1QTdTeuznaz1cJzNo98y00VNa7kuyTuB803
i0pwm4TNJf6e9mezhTKvfg+U6S7BMIsw5RLDTK1uGjDfk8wQ8fD/6ReCSVPqb0W7
fhDfb6epmj7FPv9MfH9RxzScdHtza/js0OCsyp43iMl334nwgt5OACynLcC4FE2g
L2hx8cuTt/Wz2ZqB2j3JhfMqZ6nAdORKDQOO0vJy9kfxjzAclwPjKhzUOpfy10TB
6bxn8UUBTurHeewlBXgrsQxtO7f7VwynD1Ws2PCfPzu7+QfcA3ChMOU5t7DfcqMP
6UuMjQ67ZWSXTSUKLrkLeFiYsvzclQNqDKGCh2I99HuXHJJG2ytMmhCDp8GOiLqt
d4qWQ4D7AjcNhBkMGEtMIfjYeTzjUZmYhc1iP6WSZpebw7my+9v34BDk39lKmNvj
IKDTrvkBICQEU2ufgsF4ef76kzeCKo7xiVyfw4p7hdJJapn3aK7p3IPnAVVkf600
fPadXSjFSPZy9KvwYUc3ijGU7viGqeMQ2tXtesCSOHJqYbOMYUDjWyyDWcf0RfS8
YokE8/E=
=rIFO
-END PGP SIGNATURE-

Bug#1005870: Unable to activate singularity container from within boot service script

[Fox, Ron]

Package: singularity-container
Version: 3.5.2+ds2-1
Severity: important

On Debian 11 note this comes from debian-unstable.
I am attempting to activate a singularity squashfs image from a script that runs
at boot time.   Singularity segfaults with the attached debug/traceback in
the attached file portmanager

Here is the tail of that file in case the bug reporting system does not support 
attachments:

sandbox format initializer returned: not a directory image
[0mDEBUG   [0m[U=0,P=1210]   Init()Check for sif 
image format
[0mDEBUG   [0m[U=0,P=1210]   Init()sif format 
initializer returned: SIF magic not found
[0mDEBUG   [0m[U=0,P=1210]   Init()Check for 
squashfs image format
[0mDEBUG   [0m[U=0,P=1210]   Init()squashfs image 
format detected
[0mDEBUG   [0m[U=0,P=1210]   setSessionLayer() Overlay seems 
supported and allowed by kernel
[0mDEBUG   [0m[U=0,P=1210]   setSessionLayer() Attempting to 
use overlayfs (enable overlay = try)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x606f8a]

goroutine 7 [running]:
github.com/sylabs/singularity/internal/pkg/runtime/engine/config/starter.(*Config).SetCapabilities(0xc109c8,
 {0x8e7c7e, 0x0}, {0xc00046eb00, 0x29, 0x0})
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/pkg/runtime/engine/config/starter/starter_linux.go:403
 +0x26a
github.com/sylabs/singularity/internal/pkg/runtime/engine/singularity.(*EngineOperations).PrepareConfig(0xc0003b7d60,
 0xc109c8)
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/pkg/runtime/engine/singularity/prepare_linux.go:140
 +0x5ab
github.com/sylabs/singularity/internal/app/starter.StageOne(0x988d40, 
0xc0ed08)
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/app/starter/stage_linux.go:27
 +0x6a
main.startup()
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/cmd/starter/main_linux.go:56
 +0x1ed
created by main.main
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/cmd/starter/main_linux.go:102
 +0x25
VERBOSE [U=0,P=835]wait_child()  stage 1 exited with 
status 2
[0m

Once the system is booted, I can activate the image in the same way
with no problem (same command).  I can even do this as an unprivileged user.

Here are excerpts from the script which show what I'm doing when that happens:


#!/bin/sh
### BEGIN INIT INFO
# Provides:  nscldaq
# Required-Start:$network $time $named $remote_fs $syslog
# Required-Stop: $network $time $named $remote_fs $syslog
# Should-Start:  nscldaq
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: NSCL data acquisition daemons
# Description:   NSCL data acquisition daemons
### END INIT INFO
export _SYSTEMCTL_SKIP_REDIRECT=true

...


##
#  Some definitions:
#

#  We run the port manager and the ring master under the following singularity 
container
#  with BUSTEROPT bound to /usr/opt

SINGULARITY_CONTAINER="/usr/opt/nscl-buster.img"
USROPT="/usr/opt/opt-buster"

...
PIDDIR="/scratch/nscldaq/run"
LOGDIR="/scratch/nscldaq/log"

DAQHOME="/usr/opt/daq/current"
DAQBIN="${DAQHOME}/bin"

DAQPORTMANAGER="${DAQBIN}/DaqPortManager"
DAQPORTMANAGERPIDFILE="${PIDDIR}/portmgr.pid"
DAQPORTMANAGERLOGFILE="${LOGDIR}/portmgr.log"


...

start_portmanager() {
nohup singularity -d  exec --bind ${USROPT}:/usr/opt,/scratch --no-home 
${SINGULARITY_CONTAINER}
  \
  ${DAQPORTMANAGER} \
  -log ${DAQPORTMANAGERLOGFILE} \
  -pidfile ${DAQPORTMANAGERPIDFILE}  \
  /scratch/portmanager 2>&1 &
   log_daemon_msg portmanager
sleep 3 # Let the port manager start.

}


Note that I have attempted to do the same thing after converting the container 
image to a .sif file and that too failed with essentially the same result.

Thank you for any help you might be able to provide. I'd be happy to provide any
additional information.

Ron.


portmanager
Description: portmanager

Bug#998090: libvirt-daemon-system: Please defer starting libvirtd.socket until libvirtd.service dependencies can be met

[Ron]

Hi Guido,

On Wed, Nov 03, 2021 at 07:15:37PM +0100, Guido Günther wrote:
> Hi Ron,
> 
> Sorry for the broken boot. That's always annoying.

Thanks for looking at the details.  I filed these bugs because even
though I can step around the problem in the permutation that involves
something I maintain - if we don't fill in *all* of the contributing
potholes, then I can't prevent some other combination which I have no
control over making a reboot after some future upgrade crash on the
same sharp corner case.

So it really would be nice if we can make this as naturally robust
as possible.  That we have "three corner" accidents like this, where
the problem would not have occurred if any one of the contributors
did not have some window for trouble, and that nobody detected and
reported this through the stable release cycle, says to me that we
ought to close every window for this that we see when we see it ...


> On Sat, Oct 30, 2021 at 05:39:45PM +1030, Ron wrote:
> > The race occurs because the .socket unit creates the libvirt control
> > socket very early in the boot, before even the network-pre target is
> > reached, and so long before the libvirtd.service dependencies are
> > satisfied and the daemon itself can be started to handle requests.
> > 
> > The deadlock in my case occurs when a udev rule for a device already
> > attached at boot tries to assign that device to a VM.
> > 
> > Prior to Bullseye, what would occur is:
> > 
> >  The udev rule calls a small script on device hot/cold plug which
> >  checks a config file, and if the device is allocated to a VM, then
> >  calls virsh to attach it to that VM.
> 
> Is that a sync call to virsh from udev via RUN ? 

It's a call to virsh attach-device - which unless I'm missing something
has no option except to be a "sync" call?

But also unless I'm really missing something, there really is no reason
that particular operation should ever block or be "long running" when
called for a local domain.  Either it fails out immediately because
the local libvird is not running (prior to socket activation), it fails
out immediately because the requested domain is not running, or it
succeeds or fails "almost immediately" because the device could (not)
be attached to it.

I agree there are cases where virsh *could* be "long running" (I
wouldn't try to spin up a new VM from udev RUN :), and pathological
cases where *any* process, even the most trivial, could become
"long running" - but neither of those are involved in the failure
mode I'm currently looking at avoiding.


> >  This 'immediately' either succeeds, fails because the desired VM
> >  is not actually running (yet), or fails because libvirtd is not
> >  running and virsh did not find its socket present.
> > 
> >  If either of the failure cases occur, the calling script fails
> >  gracefully, and a QEMU hook will later handle attaching the device
> >  if/when libvirtd and the desired VM is actually started.
> > 
> > But in Bullseye there's a three-way race, and if the zombie socket is
> > created before the udev rule runs, then virsh connects to it, but hangs
> > indefinitely waiting for libvirtd.service to be able to start and
> > respond to the request.
> 
> So far sounds like expected behaviour for socket activation.

Yes, I think that's the crux here.  I understand the wishful thinking in
the design of socket activation, where you just fire the starting gun
early and let everything race for the finish line with no explicit
ordering, hoping that it will just shake out as an emergent property ...

But that only works if none of the dependency relationships are cyclic,
as soon as there's a cycle (which is what we have here), the emergent
property is you can't predict what it will break ...  and the only
tie-breaker is to time-out and kill something.

In the case I got to analyse here, the problem doesn't depend on the
bit-babbler package, or even anything being called by udev RUN.  Any
early-start service, with an ordering dependency that requires it first
started before any of libvirtd.service's After list, which calls virsh
for any reason would also fall into the same trap.

So the problem in libvirt's circle of influence isn't "a long running
service" spawned by udev, it's that it's now not safe for *anything*
to call virsh without an explicit dependency somehow declaring it must
not be required to complete before libvirtd.service is successfully
started ...

Otherwise libvirtd will never start, and virsh will never return.
Which might seem like a trivial problem to avoid, but as we see here,
it's quite easy to create it accidentally in the tangle of multiple
independent requirements created by multiple independent authors.

And I assume this would be true for even th

Bug#998088: why bugs involving systemd are so hard to get fixed ...

[Ron]

On Tue, 02 Nov 2021 15:34:01 +0100 Michael Biebl  wrote:
> I tried to explain this to Ron on IRC, but he decided to ignore my advice.

Oh Please Michael, now you're just sounding like a child whose lolly has
fallen in the dirt ...

I did run the issue with (some) socket units and circular dependencies
past #systemd hoping for some sensible analysis of the problem, but all
I got was the same penchant to just sweep it under the nearest handy
rug.  What you seem to call "advice" was the same as here, just an
apparently willful effort to completely ignore everything I actually
wrote about the (several) problems here, and instead invent your own
problem that fit the answers in your standard divert blame kit ...

If you genuinely want to help here, actually read what I wrote, and
actually address the problems which should be very clear from the
analysis I wrote of it (or if they are not, I'll gladly clarify).

None of what I reported for libvirt or ifupdown are problems which
depend the bit-babbler udev rules to occur.  A quick search will find
you many people whose systems fell into the same holes these problems
create.  The problem space that each is separately subject to is created
in the domain of those packages.  There is no "one problem with one
quick answer" here (unless you count how easy it appears to still be
for people to accidentally create problems with systemd units, but I'm
not ranting about that, I'm trying to get concrete instances fixed).

I'm not going to give a long list of links here because I'm not
interested in rolling in the mud with you, I'm interested in making
packages I use a lot as robust and bug free as possible.  Except I
will highlight https://bugs.debian.org/899002 ...  In which you
showed the same complete lack of understanding of the problem - and
amusingly even argued *against* the very change to ifupdown, which
I've pointed out the one small rough edge that needs polishing, that
you now have flipped your position to say "Is perfect, don't touch it".

So can we please stop this side-show and actually look at the bugs
which I *did* report, not the invented one which I didn't ...

  Thanks,
  Ron

Bug#998090: libvirt-daemon-system: Please defer starting libvirtd.socket until libvirtd.service dependencies can be met

[Ron]

Package: libvirt-daemon-system
Version: 7.0.0-3
Severity: important

Hi,

Systemd has a class of boot-time races which can result in deadlock,
which I learned more than I ever wanted to know about when Buster to
Bullseye upgrades started leaving me with machines that were off the
network when they were rebooted ...  The reason for that is a bit of a
tangle of otherwise unrelated packages, and there are many ways this
*could* happen, but the root of it in my particular case was the libvirt
package switching to use socket activation instead of letting the daemon
create its own socket when it is ready to respond to requests on it.

The race occurs because the .socket unit creates the libvirt control
socket very early in the boot, before even the network-pre target is
reached, and so long before the libvirtd.service dependencies are
satisfied and the daemon itself can be started to handle requests.

The deadlock in my case occurs when a udev rule for a device already
attached at boot tries to assign that device to a VM.

Prior to Bullseye, what would occur is:

 The udev rule calls a small script on device hot/cold plug which
 checks a config file, and if the device is allocated to a VM, then
 calls virsh to attach it to that VM.

 This 'immediately' either succeeds, fails because the desired VM
 is not actually running (yet), or fails because libvirtd is not
 running and virsh did not find its socket present.

 If either of the failure cases occur, the calling script fails
 gracefully, and a QEMU hook will later handle attaching the device
 if/when libvirtd and the desired VM is actually started.


But in Bullseye there's a three-way race, and if the zombie socket is
created before the udev rule runs, then virsh connects to it, but hangs
indefinitely waiting for libvirtd.service to be able to start and
respond to the request.

The deadlock in this specific case then happens when ifupdown-pre (but
it could be any of many other things) calls udevadm settle to give the
initial network devices a chance to be fully set up and available before
the networking.service brings them up.

Which in turn then hangs waiting for the (otherwise unrelated) udev rule
above to complete, which won't happen until libvirtd is started, which
won't happen until the udev rule returns (or udevadm settle times out)
and network.target (among others) can be reached.

Everything stops for two minutes until the systemd "bug solver" of
arbitrary timeouts starts killing things, and the machine finishes
booting without any network devices.


The latter can be avoided (in most cases at least) with a tweak to
the networking.service dependencies (the bug I've reported here
https://bugs.debian.org/998088 has more of the gory details of this
problem from the perspective of ifupdown's entanglement in it).

But we can avoid this specific incarnation of it completely if the
libvirtd.socket unit declared the same ordering dependencies as the
libvirtd.service does, so that anything calling virsh, at any time,
can reasonably expect an answer in finite time instead of blocking
indefinitely to wait for a service (that systemd already knows
does not even have the basic preconditions to make it eligible to
start yet but ignores that to create the socket anyway).

Unless systemd gets smarter about this, there may always be a race
with the possibility of circular deadlocks if creation of the
socket and responding to requests for it are not atomic with the
creation of the service using it - so it may actually be better to
just go back to letting the daemon create and manage the socket
itself (as its "activation" signal to users of that socket) - but
we can at least narrow the window for losing it significantly if
we defer creation of the socket until at least the point where
systemd thinks it can attempt to start the daemon (though with
no guarantee of success at that still ...)


I hope I haven't missed anything that makes this make sense in the
context of libvirt ...  trying to look at and describe this from four
entirely independent points of view, each that doesn't directly care
about any of the others, is a bit of a hall of mirrors with small
parts of the problem stuck to each of them!

  Cheers,
  Ron


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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  gettext-base0.21-4
ii  iptables1.8.7-1
ii  libvirt-clients 7.0.0-3
ii  libvirt-daemon  7.0.0-3
ii  libvirt-daemon-config-network  

Bug#998088: ifupdown: Please use Wants=ifupdown-pre.service instead of Requires in networking.service

[Ron]

Package: ifupdown
Version: 0.8.36
Severity: important
Tags: patch

Hi!

Systemd has a class of boot-time races which can result in deadlock
while the ifupdown-pre.service is waiting for udevadm settle - in most
of the cases where that occurs ifupdown is an innocent victim of the
interactions between other things with poorly specified or insufficient
dependency and ordering relationships - but when those get trapped on
either side of ifupdown (reasonably enough) waiting for the initial
set of network devices to become available, people get locked out of
their remote machines after udevadm settle times out, ifupdown-pre
'fails', and then the networking.service is simply not started.


It seems there have been many instances, and many permutations, of
people effected by this class of systemd race-to-deadlock bugs, they
can be intermittent, very hard to get to the bottom of, and in almost
all of the reported cases I've found so far, people just gave up
trying to diagnose them and masked the ifupdown-pre.service as a
workaround.

But in almost all of those cases that's the wrong kludge as there was
nothing which had actually failed about waiting for the network devices
to be available, and nothing which would have subsequently prevented
networking.service from successfully starting ...

So I'd like to suggest a much better workaround, which should be the
default in ifupdown instead, is simply to change:

diff --git a/debian/networking.service b/debian/networking.service
index 593172b..b645409 100644
--- a/debian/networking.service
+++ b/debian/networking.service
@@ -2,7 +2,7 @@
 Description=Raise network interfaces
 Documentation=man:interfaces(5)
 DefaultDependencies=no
-Requires=ifupdown-pre.service
+Wants=ifupdown-pre.service
 Wants=network.target
 After=local-fs.target network-pre.target apparmor.service 
systemd-sysctl.service systemd-modules-load.service ifupdown-pre.service
 Before=network.target shutdown.target network-online.target


With this, networking.service will still wait for ifupdown-pre to
complete, either normally or by systemd's "bug fixing" timeout
when other services deadlock around it - and then in either case
the networking.service will independently either succeed (in the
probable case where networking devices were not part of the race
that deadlocked), or fail to bring up only the network devices
that were effected by that problem.  But it will be *much* less
likely for people to get locked out of remote access to fix the
real problem when the next dist-upgrade brings some change to the
set of unit files on their system which introduces this race in a
way their machine will lose (which was how I hit this on Buster
to Bullseye upgrades).


As a side note to all that, the TimeoutSec=180 in ifupdown-pre
is a bit misleading, as udevadm settle will itself time out in
120 seconds unless it is told to do otherwise.

  Cheers,
  Ron


As a postscript for anyone who might be interested, here is the
details of the particular race instance that first bit me and
got me digging into this:

 The BitBabbler package has udev rules and configuration for assigning
 hardware RNG devices directly to VM instances instead of to the host.

 It does this with a call to virsh, which in normal use (or prior to
 Bullseye) will 'immediately' either:

  - succeed
  - fail because the desired VM is not active
  - or fail because libvirtd has not yet started (or is not running)
and its communication socket is not present.

 In no case was that operation ever expected to block for any extended
 duration, nor does it have any reason to.

 But in Bullseye, libvirt changed from managing its control socket
 itself to using a "socket activation" unit, which is created (aiui
 on the naive advice of systemd advocates) very early in the boot
 process - long before it would be able to start the service, as the
 service's own dependencies are not yet satisfied, and those are not
 applied transitively to the .socket unit which would be requesting
 the (as yet unstartable) service.

 So now we have a race where the kernel or a udev cold-plug trigger
 for an already attached BitBabbler triggers a call to virsh which
 is racing with the creation of the libvirtd.socket, if the socket
 unit has not yet created it, that fails (as expected) and everything
 runs normally, with the device being attached to the VM later when
 it is eventually started.

 But if the socket unit has already created a zombie socket, virsh
 will send its request to it and then wait for a response, which is
 never going to come because libvirtd being started is trapped on
 the other side of network.target being reached.

 And then ifupdown-pre innocently stumbles into this crime scene
 because calling udevadm settle at this point will in turn block
 until the call to virsh completes, and even though the network
 device events have probably been processed normally, probably
 before this whole chain of events even started, we now have

Bug#996284: Solved

[Ron Murray]

Problem was caused by there being no entry for "bookworm" in
/usr/share/live/build/data/debian-cd. Fixed by

# cd /usr/share/live/build/data/debian-cd
# ln -s squeeze bookworm

This bug can now be closed.


-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

Bug#994910: tripwire segfaults while reading files in /etc

[Ron Murray]

Package: tripwire
Version: 2.4.3.7-3+b3
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I've been using tripwire for several years now, and never had troubles
with it until this morning (perhaps [not] coincidentally with the
updated glibc6).

Now it segfaults a short time after starting. An strace of it comes
out something like this at the end:

openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=545, ...}) = 0
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 545
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe0} ---
write(2, "Software interrupt forced exit: "..., 51Software interrupt 
forced exit: Segmentation Fault
) = 51
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x421} ---
+++ killed by SIGSEGV (core dumped) +++

I did this several times, and other files in /etc failed instead of
nsswitch.conf (passwd was one).

Since there's no dbgsym package for this version of tripwire, I
rebuilt from source (using gcc 10), and, after installing, it worked
fine with no segfault. However, this was version 2.4.3.7-3, not
2.4.3.7-3+b3: there doesn't seem to be a source for the "+b3" version.

I have coredumps and full strace if anyone needs it.

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

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

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]1.5.77
ii  sendmail-bin [mail-transport-agent]  8.15.2-23

tripwire recommends no packages.

tripwire suggests no packages.

- -- Configuration Files:
/etc/tripwire/twpol.txt changed:
@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;
@@section FS
SEC_CRIT  = $(IgnoreNone)-SHa ; # Critical files that cannot change
SEC_BIN   = $(ReadOnly) ;# Binaries that should not change
SEC_CONFIG= $(Dynamic) ; # Config files that are changed
# infrequently but accessed
# often
SEC_LOG   = $(Growing) ; # Files that grow, but that
 # should never change ownership
SEC_INVARIANT = +tpug ;  # Directories that should never
# change permission or ownership
SIG_LOW   = 33 ; # Non-critical files that are of
 # minimal security impact
SIG_MED   = 66 ; # Non-critical files that are of
 # significant security impact
SIG_HI= 100 ;# Critical files that are
 # significant points of
 # vulnerability
(
  rulename = "Tripwire Binaries",
  severity = $(SIG_HI)
)
{
$(TWBIN)/siggen -> $(SEC_BIN) ;
$(TWBIN)/tripwire   -> $(SEC_BIN) ;
$(TWBIN)/twadmin-> $(SEC_BIN) ;
$(TWBIN)/twprint-> $(SEC_BIN) ;
}
(
  rulename = "Tripwire Data Files",
  severity = $(SIG_HI)
)
{
$(TWVAR)/$(HOSTNAME).twd-> $(SEC_CONFIG) -i ;
$(TWETC)/tw.pol -> $(SEC_BIN) -i ;
$(TWETC)/tw.cfg -> $(SEC_BIN) -i ;
$(TWETC)/$(HOSTNAME)-local.key  -> $(SEC_BIN) ;
$(TWETC)/site.key   -> $(SEC_BIN) ;
#don't scan the individual reports
$(TWVAR)/report -> $(SEC_CONFIG) (recurse=0) ;
}
(
  rulename = "Critical system boot files",
  severity = $(SIG_HI)
)
{
/boot   -> $(SEC_CRIT) ;
/lib/modules-> $(SEC_CRIT) ;
}
(
  rulename = "Boot Scripts",
  severity = $(SIG_HI)
)
{
/etc/init.d -> $(SEC_BIN) ;
/etc/rcS.d  -> $(SEC_BIN) ;
/etc/rc0.d  -> $(SEC_BIN) ;
/etc/rc1.d  -> $(SEC_BIN) ;
/etc/rc2.d  -> $(SEC_BIN) ;
/etc/rc3.d  -> $(SEC_BIN) ;
/etc/rc4.d  -> $(SEC_BIN) ;
/etc/rc5.d  -> $(SEC_BIN) ;
/etc/rc6.d  -> $(SEC_BIN) ;
/etc/systemd-> $(SEC_BIN) ;
}
(
  rulename = "Root file-system executables",
  severity = $(SIG_HI)
)
{
/bin-> $(SEC_BIN) ;
/sbin   -> $(SEC_BIN) ;
}
(
  rulename = "Root file-system libraries",
  severity = $(SIG_HI)
)
{
/lib-> $(SEC_BIN) ;
}
(
  rulename = "Security 

Bug#993766: vim not available to edit vimrc during buster->bullseye upgrade

[Ron]

ist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/gvim is dangling; it will be 
updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/gvim (gvim) 
in auto mode
  update-alternatives: warning: alternative /usr/bin/vim.gtk (part of link 
group gview) doesn't exist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/gview is dangling; it will be 
updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/gview 
(gview) in auto mode
  update-alternatives: warning: alternative /usr/bin/vim.gtk (part of link 
group rgview) doesn't exist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/rgview is dangling; it will 
be updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/rgview 
(rgview) in auto mode
  update-alternatives: warning: alternative /usr/bin/vim.gtk (part of link 
group rgvim) doesn't exist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/rgvim is dangling; it will be 
updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/rgvim 
(rgvim) in auto mode
  update-alternatives: warning: alternative /usr/bin/vim.gtk (part of link 
group evim) doesn't exist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/evim is dangling; it will be 
updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/evim (evim) 
in auto mode
  update-alternatives: warning: alternative /usr/bin/vim.gtk (part of link 
group eview) doesn't exist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/eview is dangling; it will be 
updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/eview 
(eview) in auto mode
  update-alternatives: warning: alternative /usr/bin/vim.gtk (part of link 
group gvimdiff) doesn't exist; removing from list of alternatives
  update-alternatives: warning: /etc/alternatives/gvimdiff is dangling; it will 
be updated with best choice
  update-alternatives: using /usr/bin/vim.gtk3 to provide /usr/bin/gvimdiff 
(gvimdiff) in auto mode
  Setting up vim-gtk (2:8.2.2434-3) ...


The workaround of course is easy, just bypass the alternative link and
invoke one of the copies of vim that does exist directly - but if
vim-gtk really needs to be renamed to vim-gtk3, then the dummy vim-gtk
probably needs to fix the alternative before it removes the binary that
it might have been pointing to, in preinst, rather than leaving the
other packages to stumble through a mess that needs cleaning up.

There might be something more to it than that - but after digging though
the logs you might need to reproduce this, I *think* it actually is as
simple as the vim-gtk binary vanishing without first explicitly telling
update-alternatives the package is removing it, not replacing it ...


This is the set I have after the upgrade:

$ dpkg -l | grep vim
ii  vim2:8.2.2434-3
ii  vim-common 2:8.2.2434-3
ii  vim-gtk2:8.2.2434-3
ii  vim-gtk3   2:8.2.2434-3
ii  vim-gui-common 2:8.2.2434-3
ii  vim-runtime2:8.2.2434-3
ii  vim-scripts20210124.1
ii  vim-tiny   2:8.2.2434-3


  Cheers,
  Ron

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Ron]

On Tue, Aug 03, 2021 at 10:08:42PM +0200, Aurelien Jarno wrote:
> On 2021-08-01 00:05, Ron wrote:
> > 
> > Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
> > Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > Preparing to unpack .../runit-helper_2.10.3_all.deb ...
> > Unpacking runit-helper (2.10.3) ...
> > Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
> > Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > Preparing to unpack .../libc6_2.31-13_amd64.deb ...
> > Checking for services that may need to be restarted...
> > Checking init scripts...
> > Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
> > Setting up libc6:amd64 (2.31-13) ...
> > Checking for services that may need to be restarted...
> > Checking init scripts...
> > Services to restart for GNU libc library upgrade:
> > cron atd
> > Restarting services possibly affected by the upgrade:
> >   cron: restarting...done.
> >   atd: restarting...done.
> > Services restarted successfully.
> > Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
> > Unpacking libc-bin (2.31-13) over (2.28-10) ...
> > Setting up libc-bin (2.31-13) ...
> >  ...
> >  
> >  ...
> > Setting up openssh-server (1:8.4p1-5) ...
> 
> Thanks for this upgrade log, with it I have been able to understand and
> reproduce the issue. The libc restart logic looks for installed
> packaged, however due to all the breaks and depends between
> openssh-server and libc6 in the buster -> bullseye upgrade path, it
> could happen that at the moment the libc6 postinst script is ran, the
> openssh-server has been degraded from installed to unpacked.
> 
> I have tested the following fix, which works well when used in the same
> conditions as the above log:
> 
> diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
> index 8406a543..ee99ac16 100644
> --- a/debian/script.in/nsscheck.sh
> +++ b/debian/script.in/nsscheck.sh
> @@ -1,8 +1,8 @@
>   echo -n "Checking for services that may need to be restarted..."
>   # Only get the ones that are installed, of the same architecture
>   # as libc (or arch all) and configured
> - check=$(dpkg-query -W -f='${binary:Package} ${Status} 
> ${Architecture}\n' $check 2> /dev/null | \
> - grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | 
> sed 's/[: ].*//')
> + check=$(dpkg-query -W -f='${binary:Package} ${db:Status-Want} 
> ${Architecture}\n' $check 2> /dev/null | \
> + grep -E "(install|hold) 
> (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
>   # some init scripts don't match the package names
>   check=$(echo $check | \
>   sed -e's/\bapache2.2-common\b/apache2/g' \
> 
> However before uploading such a fix so close to the release, I think it
> requires a review by many more pair of eyes.

Again flying blind to a lot of important details -- but what happens if
libc postinst tries to restart a service that is unpacked but not yet
configured?

I'm guessing that depends a lot on what the service post* do, but how
horrible could that get?  Does this really need to be a trigger that
(also?) restarts each of the half-installed services after they are
fully (re)configured again?

I was able to restart ssh manually during the upgrade, but by the time I
figured out that was what was needed, the install was probably far enough
through that it had likely been configured and was fully installed again ...

  Cheers,
  Ron

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Ron]

Hi,

Sadly I can confirm this problem still persists in 2.31-13 too.  I found
it (before I found this report of it) yesterday upgrading a fully up to
date buster vm to bullseye ...

In my case I noticed it at the first conffile prompt when trying to ssh
a new connection into the vm failed, which was after the first prompting
from libc to restart services (and ssh was not included in the list of
services to restart then).

I can confirm that manually restarting ssh (while the upgrade was still
in progress) did fix it to enable logins again.

The interesting bit of the upgrade log is included below - I'm not sure
offhand exactly how the libc restart logic is coded, but at first blush
I'd note the new openssh-server is unpacked but not set up at the time
the libc service restart takes place ...

  Cheers,
  Ron

Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../runit-helper_2.10.3_all.deb ...
Unpacking runit-helper (2.10.3) ...
Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../libc6_2.31-13_amd64.deb ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
Setting up libc6:amd64 (2.31-13) ...
Checking for services that may need to be restarted...
Checking init scripts...
Services to restart for GNU libc library upgrade:
cron atd
Restarting services possibly affected by the upgrade:
  cron: restarting...done.
  atd: restarting...done.
Services restarted successfully.
Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
Unpacking libc-bin (2.31-13) over (2.28-10) ...
Setting up libc-bin (2.31-13) ...
 ...
 
 ...
Setting up openssh-server (1:8.4p1-5) ...

Bug#989282: handbrake: Handbrake finished queue, then deleted first entry and started again

[Ron Murray]

Package: handbrake
Version: 1.3.1+ds1-2+b3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I made a 22-encode-long queue for Handbrake to encode to .m4v
files. Upon completion, it deleted the .m4v file at the beginning of
the queue and started again. I assume it would have done the same for
the rest of the queue if I hadn't stopped it.

   I've used Handbrake quite often, and this is the first time I've
encountered this problem. The only thing I did different this time was
to export the queue to a file (Queue window-->Options-->Export queue)
while the final encode was being processed. I don't know whether this
caused the problem or not.

   Unless this is by design, it raises two questions:

- - Why did Handbrake start again from the beginning of the queue?
- - Should Handbrake check if the output file is already there, and
  either abort the encoding as a whole, or skip that particular
  encode, or perhaps ask the user?

Thanks,

 .....Ron


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

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

Versions of packages handbrake depends on:
ii  libass91:0.15.0-1
ii  libavcodec-extra58 [libavcodec58]  7:4.3.2-0+deb11u1
ii  libavfilter-extra7 [libavfilter7]  7:4.3.2-0+deb11u1
ii  libavformat58  7:4.3.2-0+deb11u1
ii  libavutil567:4.3.2-0+deb11u1
ii  libbluray2 1:1.2.1-4
ii  libc6  2.31-12
ii  libcairo2  1.16.0-5
ii  libdvdnav4 6.1.0-1+b1
ii  libdvdread86.1.1-2
ii  libgdk-pixbuf2.0-0 2.40.2-2
ii  libglib2.0-0   2.66.8-1
ii  libgstreamer-plugins-base1.0-0 1.18.4-2
ii  libgstreamer1.0-0  1.18.4-2
ii  libgtk-3-0 3.24.24-4
ii  libgudev-1.0-0 234-1
ii  libjansson42.13.1-1.1
ii  libpango-1.0-0 1.46.2-3
ii  libswresample3 7:4.3.2-0+deb11u1
ii  libswscale57:4.3.2-0+deb11u1
ii  libtheora0 1.1.1+dfsg.1-15
ii  libvorbis0a1.3.7-1
ii  libvorbisenc2  1.3.7-1
ii  libx264-1602:0.160.3011+gitcde9a93-2+b2
ii  libx265-1923.4-2
ii  libxml22.9.10+dfsg-6.7

Versions of packages handbrake recommends:
ii  gstreamer1.0-alsa1.18.4-2
ii  gstreamer1.0-libav   1.18.4-3
ii  gstreamer1.0-pulseaudio  1.18.4-2
ii  gstreamer1.0-x   1.18.4-2

handbrake suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmC0MggOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52FLWA/+K7a2jM1QkgdpcLT4xJjyretyr/F1MwGp+b5n
PXUmHVyKMFYGWY09Zr2DQz7GfFzL6JJTVmOZGHyQbjmjMWh/kXuOgWxX+LrnY0YK
O2tunST7HHQgc/VryzmqyKcVYOcsqpb7AlKXDZg9BdcuwJcGAY4hcx9XOCrpTlzl
LkyQGobIkIGxYK+GuXw8rImPCD/wZzd9BryrcIphHj+PKn1GwrxdvKJVXfY1HBEm
3WzBeKOdFm4CKIoYKnqJ1JhCIOw7JmWi0r/XZNgweCTedpf4c6CSNzwYeYfZNHc/
ezB84BtaKnyFvdUwX8mc4P+W3d0wmUD7lcXpddy8g+Qu40feRgp1jZfUcAPqme5H
FSxxK9+vz9ltV1r0Bl0llYG7C96MgraWmLC8IZzvUhpfjwaTiph5pxJ/C/oB6nzG
4qZxa2SXjOT0oed+KqVb6XFE/AfAfhdIDU5MUIFKvggjEiTagi7dO93t7kg4bbU8
qsc/d3tLbhzMiRvP9ZpKRFZGVE1C38D2wq+oU/mJDXr7ab+/fkKJonom6qdZ9lbf
nZ7ULPL60tCmBCOLiLFC2mAEDjmUtGD8p7qdfV5Ylc7VaQquKTICvn/JM5mrDlU3
JLzg21XGP11nLLeVB2lp4jNOGKgvVeHgP6dtanzCAPnYslp61fFAOfVTM4OH8h0R
ZlJqwaM=
=TqOW
-END PGP SIGNATURE-

Bug#986267: xfce4-appfinder: Application Finder doesn't show up xfce4's "Add New Items" window

[Ron Murray]

Never mind. I thought I'd point out a deficiency, but you seem to be
more interested in how I found it than the deficiency itself.


On Sun, 2021-04-18 at 18:32 +0200, Yves-Alexis Perez wrote:
> On Fri, 2021-04-02 at 00:57 -0400, Ron Murray wrote:
> > 
> >    I noticed "Application Finder" in a Debian Live build I'd made,
> > and
> > wondered why I'd never seen it on my normal Debian box. So I tried
> > to
> > add it with xfce4's "Add New Items" option, but it doesn't show up
> > there.
> > 
> Hi Ron,
> 
> sorry but it's unclear to me what you mean when you say “I noticed …”
> where
> exactly you noticed and what exactly you tried to do next. What is
> this “Add
> new items” menu you're talking about ? If it is the panel plugin
> menu, then
> there is no “application finder plugin”, but you should be able to
> add a
> launcher, and then use the application finder as the application to
> be
> launched.
> 
> Regards,

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761



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

Bug#186278: Missing files

[Ron Murray]

Hi Chris.

   I use autoproject occasionally, whenever I start up a new project
that requires GNU make (say, once or twice a year). It's handy for
creating all those weird files that go with GNU make.

   It's ok with me if you want to remove it from Debian. I'll just grab
the source and maintain it myself.

Thanks,

 .Ron

On Wed, 2021-04-07 at 22:07 +0200, Chris Hofstaedtler wrote:
Hello Ron,

* Ron Murray  [210407 20:05]:
>    I'm not going to supply a patch because I feel that this should be
> the decision of the maintainer.

There is no maintainer.

> PS FFS, this bug is *18* *years* *old*. 

Are you actively using autoproject? Upstream appears to have
vanished a long time ago.

Personally I would push for removing autoproject from Debian if
nobody speaks up ...

Chris


-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

Bug#186278: Missing files

[Ron Murray]

   The cause of this bug seems to be that there aren't any skeleton
files under /usr/share/autoproject/cli/c++ for any parser generator
option other than 'none'. Works fine when 'none' is (auto)selected as
the parser generator.

   The options to fix this bug seem to be:
1. Supply the missing parser generator files.
2. Only allow 'none' to be selected as the parser generator when using
c++.

   I'm not going to supply a patch because I feel that this should be
the decision of the maintainer.

 .Ron

PS FFS, this bug is *18* *years* *old*. 

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761



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

Bug#986267: xfce4-appfinder: Application Finder doesn't show up xfce4's "Add New Items" window

[Ron Murray]

Package: xfce4-appfinder
Version: 4.16.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I noticed "Application Finder" in a Debian Live build I'd made, and
wondered why I'd never seen it on my normal Debian box. So I tried to
add it with xfce4's "Add New Items" option, but it doesn't show up
there.

   I tried reinstalling the package, but it made no difference.

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

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

Versions of packages xfce4-appfinder depends on:
ii  libc62.31-10
ii  libgarcon-1-04.16.1-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2

xfce4-appfinder recommends no packages.

xfce4-appfinder suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmBmpEEOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52F04xAArMNAHq2ONetNwTnDYDUUD7C8YkpJnU5JQKgu
Q+pFhqfZlBHLFceslYTOIFS8OoBNJxmZJuD7qaRe0eDz6J/RGvOyS8lCAaNi4rla
Es+U9Qs6wsTupbyD7+fr4ysYXVteasaLUBtU6nKjTKmVnvyNEDnSCJQ9LnVg9Z+O
FazZhvQmdzWjL3wo3zRc98s39Ss5Q2QhShNXIxFTal7jiUKKW1SAfOosCEAaeL+6
oBFSXT05+LvGQkrLD9+08t2TvOaO11SxIA5tVVPAI7tfRZL0BNHDKazIWi6grMDT
bwMQmG4b6VndliKnlIAlpQbgwmAuvgQ0uo2Sb3nCBP7PfyANuanxBE4LGS+9LrDO
pbuR1hNDOgX9kXmgfNhkyQIjd1SWpUTk7TuuOHVidrZI0GON1ACNWHgqThNEeOrH
86PyAJ/SIvuKCLdYFaXnjfEOwV3ISrdapTMANX4pHKLocCUOFepzmLmpOPbizPwr
aHS6L6q6kCq6h4Gtm3FXYP0b1zo8W5aFof+B1IynTIFNo5UZQE7z1nI5Nda7V+B5
SbZ2NUVdgYG8sJu2EzRHtnAvVQpAIFYixfqIeBaa6B1R3HGuD+F12QlhaL5InBsC
yhPqf9yuA0AZ8QyQUIBAs0BLCrHEZYXRhZv6Rf3mAJiCq+YohIL1MLYJZaxMFkOv
DP2rsR4=
=1xzi
-END PGP SIGNATURE-

Bug#847962: rng-tools: Patch to fix the broken FIPS 140-2 runs test

[Ron]

On Mon, Nov 23, 2020 at 07:59:52PM +0100, Diederik de Haas wrote:
> On Sat, 24 Jan 2015 20:46:02 +1030 Ron  wrote:
> > Tags: patch
> > 
> > And if reportbug --attach actually worked, the git-format-patch export
> > should be included in this mail.  There's a full description of the
> > bugs in the commit message of it.
> 
> Hi Ron,
> 
> Can you submit your patch as a PR here: https://github.com/nhorman/rng-tools/
> pulls ?
> 
> I could do it, but it would make much more sense that you'd do it.

Hi Diederik,

I'm not on github - but it's definitely applicable upstream, I'd sent it
there (to Jeff Garzik and HPA who were the maintainers at the time),
the same day I pushed the patch into the Debian BTS ... but I never
heard back from either of them at the time either.  If he doesn't
want to git-am the patch file, he should be able to pull it from here:

https://salsa.debian.org/ron/rng-tools/-/commit/27c260ae79e3b02f81062328497648b1e5f46613

Which is the new working repo copy since the old anonscm.d.o link died
when alioth went away ...

  Cheers,
  Ron

Bug#972594: ITS: tftp-hpa

[Ron]

Hi Romain,

On Tue, Oct 20, 2020 at 10:39:34PM +0200, Romain Porte wrote:
> I intent to salvage this package with your approval, or after the 21
> days delay as mentioned in the developer guide:
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package
> 
> I have reworked the package locally to fix almost all lintian warnings,
> moved format from 1.0 to 3.0 (quilt) and updated to the latest standards
> version. I already did a previous NMU (on top of another NMU) that
> fixed the IPv6 bugs. I received thanks from bug authors as it solved
> their issues (and mine too).
> 
> I was originally trying to publish this big change as a NMU, but it
> would make more sense to first adopt the package and then make a proper
> -2 release instead of a 1.3 NMU.

I've been AFK a fair bit lately (and so sorry for this slow reply too,
I've only just caught up on mail enough to see this now) - so you have
my thanks for taking an interest in keeping this one maintained too.

I do still actively use this package on systems I maintain, so whatever
happens I am still going to have an enduring interest in ensuring it
works as needed for those too, whether that's as a (co)maintainer for
the distro package, or in a local repository of my own.

I can't say I'm a huge fan of format 3.0 (quilt), especially in this
day and age where both the package and upstream are maintained in git,
and doubly so for a package like this one, where I was able to upstream
all the local patches it was carrying in about the first week that I
started maintaining it ...

So if you can be happy not to make major changes that are essentially
gratuitous and don't actually add anything of value or fix any really
existing problem (or at least not go down that road without first
talking about what real advantage you think it might add), I would
certainly be happy to see this package have all the people with a
genuine interest in it helping to actively maintain it.

It is essentially a "finished" piece of software - it does the job
of implementing the protocol - so mostly the only work it should
need is when something external changes that breaks its environment.
If you want to add yourself to uploaders and contribute to fixing
real bugs with a Proper Maintainer hat on, I'd absolutely welcome
that.  Does that sound like a more long-term viable way forward on
this one to you?  It is the nature of this game for people's needs
with packages like this one to be cyclical, and I'll guess it will
be no different for you once your immediate need is scratched as
well.

  Cheers,
  Ron

Bug#964914: live-build: Build for bullseye with security=true fails

[Ron Murray]

Package: live-build
Version: 1:20191221
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Build for bullseye with security=false works fine.
Build for security=true fails with:

> E: The repository 'http://security.debian.org bullseye/updates Release'
> does not have a Release file.

This is presumably because http://security.debian.org/dists/ contains
"bullseye-security" and not "bullseye". This appears to be a recent change.

- -- Package-specific info:

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

Kernel: Linux 5.7.8.khufu (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-build depends on:
ii  debootstrap  1.0.123

Versions of packages live-build recommends:
ii  apt-utils   2.1.7
ii  bzip2   1.0.8-3
ii  cpio2.13+dfsg-2
ii  file1:5.38-5
ii  live-boot-doc   1:20190614
ii  live-config-doc 11.0.1
ii  live-manual 2:20151217.1
ii  live-manual-epub [live-manual]  2:20151217.1
ii  live-manual-html [live-manual]  2:20151217.1
ii  live-manual-odf [live-manual]   2:20151217.1
ii  live-manual-pdf [live-manual]   2:20151217.1
ii  live-manual-txt [live-manual]   2:20151217.1
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages live-build suggests:
ii  e2fsprogs  1.45.6-1
ii  mtd-utils  1:2.1.1-1
ii  parted 3.3-4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAl8KfMwOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52F0yg/5Adoryfv267uLrlbnFkRaGaFW0pRQn01cKvEp
i4+8xUFAxDanZFVF82JuIWe0d9MbdiLdFZtR9A4uRHTzpN9R+/C4ihjQlDD/5w1U
jCeDQ6E8do9kQWH4ARirmoSXNI+t98Bkb2f5wYJ3LNnzwQa0u/FoNWYzh1FxfKOT
6pqDdvRE7Jv58Y6GZHvMbSd0K9yc3hykWPvESw4CSRBPRvXStYkqNOt0TDf1i/EV
nOgOIO76Nm6iz1ZgU0dzJvewLNi1zBp15BaBbvsumcc1dz9h7i0uOWKDPgQrqGNE
IEKkiRBp9h/2MmFufO41L2EWR7zEfK9kZm1YZhZbNiLtoag3FEYFAw3+0pD6jXon
SP6yHy/lI+c3BYIfbm38amOdEtLX+tlylsytmPfgreA/PN62UxsxGvXeTWThme0g
xEcYIdzKImKcrvoVrt96JBD0UIxk1givmwUotD0PqlQ7TqufgubRga6BwxfZ+JI0
DKJ7Cbmi6iWWGbcwCSiQxX21GySCB8Bt4Y+ABMNt6oUE8EfNXfFWSC515iCKBZt/
IUMmN8v1VFIl4H9cslqifRRF3hjh2kFKwJ7M+IRvm5iwdO+y7/cWhHPSRzSFciNe
dHt+o/uP0SvY4UBssfX5kfa5SOol+kAMQTCRn4sPXIhet4jgfU7HrfAg1Bh+xoym
s+QM8KQ=
=fOlc
-END PGP SIGNATURE-

Bug#956681: /etc/logrotate.d/fail2ban cause logrotate failures when fail2ban isn't running.

[Ron Varburg]

 Hello,
I won't follow your suggestion to report it upstream. I think he does the right 
thing
when fail2ban-client flushlogs exits with an error code when fail2ban is 
running.
That said, I think logrotate shouldn't fail either in these circumstances. It 
could be
that the administrator stopped fail2ban for his own reasons, or that he just 
installed
the package and still hasn't ran it at all. It could also be there is a problem 
and
fail2ban stopped running without any one aware of that. And there could be other
circumstances why fail2ban is not running. Still, I think the right action, if 
at all, to
make someone aware of it is not by creating logrotate failures.
 On Tuesday, April 14, 2020, 10:45:15 AM GMT+1, Sylvestre Ledru 
 wrote:  
 
 Hello

Thanks for your patch!

Le 14/04/2020 à 11:30, Ron Varburg a écrit :
> Package: fail2ban
> Version: 0.10.2-2.1
> Severity: normal
> Tags: patch
> 
> The following patch:
> 1. Prevents logrotate failures when fail2ban doesn't run for any reason.
>      When fail2ban  isn't running, fail2ban-client flushlogs exits with an 
>error
>      code. I think announcing fail2ban isn't running should not be made by
>      making logrotate to fail.
This should be fixed upstream in "fail2ban-client flushlogs" I think.
Could you please report an issue there?

> 2. Doesn't rotate empty log files.
agreed & pushed. thanks

Cheers,
Sylvestre
  

Bug#953139: Bug #953139 confirmation of fix

[Ron Lovell]

Update 4.6.3-3 adds a depends for python3-distutils. Thank for the quick
fix!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Info on other distros

[Ron Lovell]

I checked a couple of other distros I run. In Arch Linux distutils/util.py
is provided by the base "python" pkg. In openSUSE Tumbleweed it is provided
by python3-base. So among my installations, Debian Buster and Sid are the
odd ducks in that they require an optional pkg installation to provide
distutils/util.py.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Reply to Msg #20

[Ron Lovell]

Probably "what's different" is just that I decided to test qtconsole on by
Sid guest VM. I would normally run qtconsole on my host Buster system,
where jupyter_core/paths.py does not import from distutils.util, and
besides python3-distutils is already installed since it's needed by other
things I have installed like python3-pip and python3-dev.  I doubt that I
ever removed python3-distutils on Sid, it's just that I never installed
anything that explicitly deps on it.

Still, jupyter_core/paths.py in 4.6.3 does have a runtime dependency on
distutils.util, so I would recommend having python3-jupyter-core depend on
python3-distutils just in case the latter hasn't been brought in by another
dependency.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Update after python 3.8 default

[Ron Lovell]

With the latest python3-talloc update, the upgrade to python3 3.8.2
completed on my Sid host. I temporarily removed python3-distutils to verify
the situation has not changed: "juypter qtconsole" still requires
python3-distutils, and nothing brought it in as a dependency.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Correction

[Ron Lovell]

> Should I have python3 installed?

Meant: Should I have python3-all installed?
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: python3-jupyter-core: Sid python3-jupyter-core 4.6.3-2 Needs python3-distutils

[Ron Lovell]

Package: python3-jupyter-core
Version: 4.6.3-2
Severity: important

After recent updates to the jupyter packages and for the Python
3.8 tranision in Sid, I decided to give qtconsole a spin just to
see how it's working. It's not able to load:

$ jupyter qtconsole
Traceback (most recent call last):
  File "/usr/bin/jupyter", line 11, in 
load_entry_point('jupyter-core==4.6.3', 'console_scripts', 'jupyter')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in 
load_entry_point

...

  File "/usr/lib/python3/dist-packages/jupyter_core/command.py", line 25, in 

from . import paths
  File "/usr/lib/python3/dist-packages/jupyter_core/paths.py", line 21, in 

from distutils.util import strtobool
ModuleNotFoundError: No module named 'distutils.util'

I was able to resolve this by installing python3-distutils, which
installs both Python 3.7 and 3.8 versions of distutils.util.

The latest /usr/lib/python3/dist-packages/jupyter_core/paths.py
module from Debian package python3-jupyter-core does import from
distutils.util. The python3-jupyter-core 4.4.0-2 installed on my
Buster host does not.

Should python3-jupyter-core now depend on package python3-distutils?

CAVEATS: The Python 3.8 transition is still a work-in-progress
on my Sid host, as I expect it is on other users'. Upgrades of
python3 libpython3-stdlib python3-minimal from 3.7.5-3 -> 3.8.2-1
are blocked because python3-talloc requires python3 (< 3.8), and
python3-talloc is (ultimately) required by gnome-control-center
via GVFS/Samba dependencies.

Also, I DO NOT have python3-all installed, which would bring in
python3-distutils. Should I have python3 installed?

My sincere apologies if I've jumped the gun and this issue would
have worked itself out as the 3.8 transition progresses. But this
could affect other qtconsole users, so I thought I should report it.

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

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

Versions of packages python3-jupyter-core depends on:
hi  python33.7.5-3
ii  python3-traitlets  4.3.3-2

python3-jupyter-core recommends no packages.

Versions of packages python3-jupyter-core suggests:
pn  python3-pip  

-- no debconf information

Bug#948112: python3-pyqt5: Unstable python3-pyqt5 Is Not Installable With libqt5qui5-gles Installed

[Ron Lovell]

Package: python3-pyqt5
Version: 5.13.2+dfsg-1
Severity: important

Currently in Sid the python3-pyqt5 package has deps:
libqt5gui5 (>= 5.1.0)
libqt5gui5 (>= 5.12.2) | libqt5qui5-gles (>= 5.12.2)

I recently performed the tranition from libqt5gui5 to the -gles variant
just to try it out. I had to remove python3-pyqt5 and and its dependents
(e.g. python3-qtconsole). I expected it might take a while to complete
the ongoing transition, and in fact in the transition tracking web
page pyqt5 still shows as in progress (or whatever orange means). But
after looking over the transition Bug #919218, especially the comments
about a similar dependency in libqt5quick5, I'm wondering if there's
going to be a resolution soon for python3-pyqt5.  If so, I can wait. If
not, I need to go back to libqt5gui5 so I can have jupyter qtconsole.

If I'm just being too impatient (we did just celebrate the holidays),
my apologies.


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

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

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.29-7
ii  libgcc1   1:9.2.1-21
ii  libpython3.7  3.7.6-1
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-5
ii  libqt5dbus5   5.12.5+dfsg-5
pn  libqt5designer5   
ii  libqt5gui5-gles   5.12.5+dfsg-1
pn  libqt5help5   
ii  libqt5network55.12.5+dfsg-5
pn  libqt5printsupport5   
pn  libqt5test5   
ii  libqt5widgets55.12.5+dfsg-5
pn  libqt5xml5
ii  libstdc++69.2.1-21
ii  python3   3.7.5-3
pn  sip-py3api-12.7   

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

NOTE: I have libqt5gui5-gles 5.12.5+dfsg-1 installed.

Bug#945121: Bug #945121 Confirmation of resolution

[Ron Lovell]

I noticed that libopenmpi-dev 4.0.2-3 now depends on libevent-dev.  Thanks!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#945120: Bug #945120 Confirmation of resolution

[Ron Lovell]

Wow, that was fast!  The Open MPI 4.0.2-3 updates appear to resolve the
issue. I say "appear" because I can't really reproduce an upgrade from
3.1.3 to 4.0.2-3.

Upgrading from 4.0.2-2 to 4.0.2-3 worked fine.

In order to test a new installation of Open MPI, I removed all Open MPI and
OpenCoarrays packages, then installed mpi-default-bin and mpi-default-dev
to bring them back. I used apt-get for that in case I needed to capture
some messages. There were no issues reported, and 4.0.2-3 works fine on my
test programs, including Co-Array Fortran tests.

I also noticed that libopenmpi-dev now depends on libevent-dev as I
suggested in Bug #945121.

Great work, guys!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#945121: libopenmpi-dev: Sid The libopenmpi-dev 4.0.x package should probably depend on libevent-dev

[Ron Lovell]

Package: libopenmpi-dev
Version: 4.0.2-2
Severity: normal

While testing the newly upgraded Open MPI 4.0.2-2 packages in Sid I
found that builds with mpicc etc. will be expecting libevent.so and
libevent_pthreads.so, which are provided by libevent-dev.

Starting with 4.0.x, shouldn't libopenmpi-dev depend on or at least
recommend libevent-dev?

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

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libhwloc-dev  1.11.13-1
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-2
ii  openmpi-bin   4.0.2-2
ii  openmpi-common4.0.2-2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.8.0-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#945120: libopenmpi-dev: Sid upgrade to libopenmpi-dev 4.0.2-2 has issues in setup step

[Ron Lovell]

Package: libopenmpi-dev
Version: 4.0.2-2
Severity: important

Dear Maintainer,

The upgrade of Open MPI components from 3.1.3 to 4.0.2-2 did not
complete successfully. During upgrade I got these warnings:

Setting up libopenmpi-dev:amd64 (4.0.2-2) ...
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/x86_64-linux-gnu/openmpi/include because link group 
mpi-x86_64-linux-gnu is broken
update-alternatives: warning: skip creation of 
/usr/lib/x86_64-linux-gnu/libmpi++.so because associated file 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (of link group 
mpi-x86_64-linux-gnu) doesn't exist
update-alternatives: warning: skip creation of 
/usr/lib/x86_64-linux-gnu/libmpi.so because associated file 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (of link group 
mpi-x86_64-linux-gnu) doesn't exist

As installed the libraries were not usable:

$ make
mpicc -O2 -march=native -fpie -std=c11  -D_Linux -D_XOPEN_SOURCE=700  -o 
mpi_mm.o -c mpi_mm.c
mpicc mpi_mm.o  -pie -Wl,-z,now -Wl,-z,relro  -o mpi_mm_c.linux-gnu.x86_64
/usr/bin/ld: cannot find -lmpi
/usr/bin/ld: cannot find -levent
/usr/bin/ld: cannot find -levent_pthreads
collect2: error: ld returned 1 exit status
make: *** [makefile:31: mpi_mm_c.linux-gnu.x86_64] Error 1

I found that the failure to locate -levent and -levent_pthreads was
because libevent-dev needs to be installed.

The -lmpi load failure is because the symlink

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.40.20.2

was missing when setup tried to create the symlinks

/etc/alternatives/libmpi.so-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

and

/usr/lib/x86_64-linux-gnu/libmpi.so -> 
/etc/alternatives/libmpi.so-x86_64-linux-gnu

Running dpkg-query -L libopenmpi-dev shows that

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

should have been created, but it wasn't.

On the off chance that a reinstallation might help, I reinstalled
all the 4.0.2-2 packages.  That time there were no issues reported,
the symlinks appear to be good, and Open MPI 4.0.2 works on my
test programs.

$ showlinks /usr/lib/x86_64-linux-gnu/libmpi.so
lrwxrwxrwx 1 root root 44 Nov 19 18:11 /usr/lib/x86_64-linux-gnu/libmpi.so -> 
/etc/alternatives/libmpi.so-x86_64-linux-gnu
lrwxrwxrwx 1 root root 47 Nov 19 18:11 
/etc/alternatives/libmpi.so-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
lrwxrwxrwx 1 root root 17 Nov 19 05:55 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.40.20.2
-rw-r--r-- 1 root root 1126552 Nov 19 05:55 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so.40.20.2

That's similar to the 3.1.3 scheme that I still have on my Buster host.

Is it possible that the installation script has a sequencing problem
such that it tries to target 

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

with a symlink from /etc/alternatives before it's been created?

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

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libhwloc-dev  1.11.13-1
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-2
ii  openmpi-bin   4.0.2-2
ii  openmpi-common4.0.2-2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.8.0-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#922275: Bug #922275 Still Relevant for LLVM/libomp 9

[Ron Lovell]

Although I can no longer install flang-7 on my Sid host since the upgrades
to LLVM 8 and now non-default LLVM 9, the general situation described still
applies to libomp-9-dev. If a user compiles with the -fopenmp= option
(instead of simply -fopenmp), it's much better if  doesn't change from
version to version of the toolchain. It would still be helpful to have the
libomp--dev package install a symlink:

/usr/lib//libomp.so -> libomp5.so

The target libomp5.so is already maintained by libomp--dev to point
into the current  /usr/lib/llvm- directory.

I continue to keep that symlink in place as a workaround, so I'm not
suffering myself so long as I remember to create it on new installations.

Thanks for considering this request.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#932598: Upgrade to buster fails with start-stop-daemon error

[Ron Murray]

On 7/30/19 4:14 PM, Andreas Beckmann wrote:
> Hi Ron,
>
> On 21/07/2019 05.42, Ron Murray wrote:
>> On upgrade to buster, sendmail upgrade failed with this message:
>>
>>> start-stop-daemon: matching only on non-root pidfile 
>>> /var/run/sendmail/mta/sendmail.pid is insecure
>> Some work with Google found Debian bug #922395, which, although not
>> for sendmail, pointed the way to the solution.
> I've just uploaded sendmail 8.15.2-13 to unstable, it would be great if
> you could test this s.t. I have a datapoint whether this fix should be
> applied to buster, too.
>
> Thanks
>
> Andreas

Thanks for the update. The same problem occurred when I upgraded to
8.15.2-13 on my two testing (bullseye) boxes. Deleting the
/var/run/sendmail/mta/sendmail.pid file and re-running aptitude fixed it.

Sadly, I wasn't smart enough to get the details on the file before I
deleted it. I'm not even certain why it was there: I would have thought
that shutting down sendmail before the upgrade should have deleted it.
Perhaps this was the problem all along.

After getting sendmail started, the file looks like this:

> -rw-r----- 1 root  smmta  53 Aug  5 22:14 sendmail.pid

Thanks,


 ,Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761




signature.asc
Description: OpenPGP digital signature

Bug#933782: Bug #933782 Workaround

[Ron Lovell]

Patrice, thanks for filing the bug report. I was just looking at that bug
myself. The definition of g_tclextlib at line 41 is in new code added since
the version 4.2.2 that's in Buster.

I'm NOT a Tcl programmer or Modules guru. But is "prefix" something that
should be compiled into the modules at build time, or initialized in
/etc/environment-modules/siteconfig.tcl, or maybe in a file
/etc/environment-modules/rc?

As a workaround I edited modulecmd.tcl to replace "${prefix}" with "/usr"
at line 41. That allows /usr/share/modules/init/bash to complete
successfully and define function "module" correctly.

Hope this helps.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#933732: Bug #933732

[Ron Lovell]

Sorry, that comment was intended for Bug #933782. Pls disregard.

On Sat, Aug 3, 2019 at 9:13 AM Ron Lovell  wrote:

> Patrice, thanks for filing the bug report. I was just looking at that bug
> myself. The definition of g_tclextlib at line 41 is in new code added
> since the version 4.2.2 that's in Buster.
>
> I'm NOT a Tcl programmer or Modules guru. But is "prefix" something that
> should be compiled into the modules at build time, or initialized in
> /etc/environment-modules/siteconfig.tcl, or maybe in a file
> /etc/environment-modules/rc?
>
> As a workaround I edited modulecmd.tcl to replace "${prefix}" with "/usr"
> at line 41. That allows /usr/share/modules/init/bash to complete
> successfully and define function "module" correctly.
>
> Hope this helps.
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#933732: Bug #933732

[Ron Lovell]

Patrice, thanks for filing the bug report. I was just looking at that bug
myself. The definition of g_tclextlib at line 41 is in new code added since
the version 4.2.2 that's in Buster.

I'm NOT a Tcl programmer or Modules guru. But is "prefix" something that
should be compiled into the modules at build time, or initialized in
/etc/environment-modules/siteconfig.tcl, or maybe in a file
/etc/environment-modules/rc?

As a workaround I edited modulecmd.tcl to replace "${prefix}" with "/usr"
at line 41. That allows /usr/share/modules/init/bash to complete
successfully and define function "module" correctly.

Hope this helps.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#932598: Upgrade to buster fails with start-stop-daemon error

[Ron Murray]

Package: sendmail
Version: 8.15.2-12
Severity: grave
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On upgrade to buster, sendmail upgrade failed with this message:

> start-stop-daemon: matching only on non-root pidfile 
> /var/run/sendmail/mta/sendmail.pid is insecure

Some work with Google found Debian bug #922395, which, although not
for sendmail, pointed the way to the solution.

The following patch for /etc/init.d/sendmail should fix the problem:

- - CUT HERE --
*** sendmail.orig   2019-07-20 23:35:49.360737086 -0400
- --- sendmail  2019-07-20 22:40:04.782571907 -0400
***
*** 149,163 
- --- 149,166 
--start";
STOP_MTAL_CMD="start-stop-daemon \
--pidfile $MTAL_PIDFILE \
+   --exec $MTA_DAEMON \
--name sendmail-mta \
--stop";
SIGNAL_MTAL_CMD="start-stop-daemon \
--pidfile $MTAL_PIDFILE \
+   --exec $MTA_DAEMON \
--name sendmail-mta \
--stop";
START_MTAQ_CMD="start-stop-daemon \
--pidfile $MTAQ_PIDFILE \
--make-pidfile \
+   --exec $MTA_DAEMON \
--startas $MTA_COMMAND \
--start";
STOP_MTAQ_CMD="start-stop-daemon \
***
*** 165,170 
- --- 168,174 
--stop";
SIGNAL_MTAQ_CMD="start-stop-daemon \
--pidfile $MTAQ_PIDFILE \
+   --exec $MTA_DAEMON \
--name sendmail-mta \
--stop";
START_MSP_CMD="start-stop-daemon \
- - CUT HERE --

It may also be necessary to delete /var/run/sendmail/mta/sendmail.pid
as well.

Note:
Although probably not a sendmail problem (start-stop daemon?), it
might be advisable to re-word the error message. "matching only on
non-root pidfile xxx.pid is insecure" is rather cryptic, and does not
point the way to fixing the problem.

 .Ron Murray

- -- Package-specific info:
Output of /usr/share/bug/sendmail/script:

ls -alR /etc/mail:
/etc/mail:
total 568
drwxr-sr-x   8 smmta smmsp  4096 Jul 20 22:42 .
drwxr-xr-x 260 root  root  16384 Jul 20 23:16 ..
- -rwxr-xr--   1 root  smmsp 12904 Jul 20 22:42 Makefile
- -rw---   1 root  smmsp  5526 Jul 20 22:42 access
- -rw-r-   1 smmta smmsp 12288 Jul 20 22:42 access.db
- -rw-r--r--   1 root  smmsp  5432 Jul  2  2018 access.old
- -rw---   1 root  root   2084 Nov  4  2014 access.orig
- -rw-r--r--   1 root  root281 Sep  5  2004 address.resolve
lrwxrwxrwx   1 root  smmsp10 Mar 28  2015 aliases -> ../aliases
- -rw-r-   1 smmta smmsp 12288 Jul 21  2017 aliases.db
- -rw-r--r--   1 root  root   1040 Nov 25  2007 aliases.orig
drwx--S---   2 root  smmsp45 Jun 18  2017 auth
- -rw-r--r--   1 root  root   3722 Jul 20 22:42 databases
- -rw-r--r--   1 root  root   3720 Oct 22  2014 databases.orig
- -rw-r-   1 smmta smmsp42 Apr  7  2004 default-auth-info
- -rw-r--r--   1 smmta smmsp 0 Oct  1  2000 domaintable
- -rw-r--r--   1 root  root   5659 Dec  8  2016 helpfile
- -rw-r--r--   1 smmta smmsp21 Apr  7  2004 local-host-names
drwxr-sr-x   2 smmta smmsp81 Jul 20 20:54 m4
- -rw-r--r--   1 smmta smmsp15 Sep 25  2008 mailertable
- -rw-r-   1 root  smmsp 12288 Jun 18  2017 mailertable.db
- -rw-r--r--   1 smmta smmsp 12973 Jun  4  2015 mimedefang-filter
- -rw-r--r--   1 smmta smmsp 12973 Jun  4  2015 mimedefang-filter.spamassassin
- -rw-r--r--   1 smmta smmsp  4108 Aug 18  2006 mimedefang.conf.12596
- -rw-r--r--   1 smmta smmsp  4108 Dec 28  2006 mimedefang.conf.13657
- -rw-r--r--   1 smmta smmsp  4108 Jan 30  2007 mimedefang.conf.15047
- -rw-r--r--   1 smmta smmsp  4108 Mar 16  2007 mimedefang.conf.25782
- -rw-r--r--   1 smmta smmsp  4108 Apr 26  2005 mimedefang.conf.5937
- -rw-r--r--   1 smmta smmsp  4108 Nov 21  2006 mimedefang.conf.6382
- -rw-r--r--   1 smmta smmsp  4108 Mar 27  2006 mimedefang.conf.7263
- -rw-r--r--   1 root  root276 Feb 11  2005 mimedefang.pl.conf
drwxr-xr-x   2 root  root 21 Jul 20 20:51 peers
- -rw-r--r--   1 smmta smmsp 0 Jan 30  2002 relay-domains
- -rw-r--r--   1 root  root   4297 May 14  2018 sa-mimedefang.cf
drwxr-xr-x   2 smmta smmsp   132 May 24  2015 sasl
- -rw-r--r--   1 smmta smmsp54 Apr  4  2015 sendmail.cN
- -rw-r--r--   1 root  smmsp 75517 Jul 20 22:42 sendmail.cf
- -rw-r--r--   1 root  root  75514 Jul 20 22:42 sendmail.cf.old
- -rw-r--r--   1 root  root  12235 Jul 20 22:42 sendmail.conf
- -rw-r--r--   1 root  root  1 Oct 22  2014 sendmail.conf.orig
- -rw-r--r--   1 smmta smmsp15 Apr  3  2015 sendmail.ct
- -rw-r--r--   1 smmta smmsp   209 Mar  2  2008 sendmail.cw
- -rw-r--r--   1 root  smmsp  8600 Jul 20 22:42 sendmail.mc
- -rw-r--r--   1 root  root148 Sep 15  2018 service.switch
- -rw-r--r--   1 root  root179 Sep 15  2018 service.switch-nodns
drwxr

Bug#930628: Bug #930628 Warning to Remove the Symlink Workaround

[Ron Lovell]

If anyone happened to have used my workaround of installed a temporary
symlink flang-mod-33 -> flang-mode-34, be sure the remove that symlink
before doing the update.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: Bug #930628 Confirmation of Fix

[Ron Lovell]

Yep, update 20190329-2 fixes the issue on my system. Thanks for the great
work!
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: Bug #930628 Another Workaround

[Ron Lovell]

Another workaround is to install a symlink:

/usr/lib/x86_64-linux-gnu/fortran/flang-mod-33 -> flang-mod-34

That's easier since it doesn't require changing my build specs.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: flang-7: Flang-7 20190329-1 Does Not See Its Standard Modules

[Ron Lovell]

Package: flang-7
Version: 20190329-1
Severity: important

Dear Maintainer,

A program which uses iso_fortran_env fails to compile using the
20190329-1 build of flang-7 because flang cannot find the module:

flang -Ifortran_characters@exe -I. -I.. -Xclang -fcolor-diagnostics -pipe 
-D_FILE_OFFSET_BITS=64 -Minform=inform -O3 -march=native 
-fstack-protector-strong -std=f2003 -module fortran_characters@exe   -o 
'fortran_characters@exe/globals.f90.o' -c ../globals.f90
F90-F-0004-Unable to open MODULE file iso_fortran_env.mod (../globals.f90: 2)
F90/x86-64 Linux Flang - 1.5 2017-05-01: compilation aborted

The same program compiles successfully using the 20181226-2 build of
flang-7.

The problem can be worked around by adding this compiler option:

-I /usr/lib/x86_64-linux-gnu/fortran/flang-mod-34

In the upgrade from 20181226-2 to 20190329-1 the *.mod files moved from
a subdirectory flang-mod-33 to flang-mod-34. Does something need to be
updated in flang-7 to adjust the default module search path?


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

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

Versions of packages flang-7 depends on:
ii  libc6 2.28-10
ii  libflang-dev  20190329-1
ii  libflang0d-7  20190329-1
ii  libgcc1   1:8.3.0-7
ii  libllvm7  1:7.0.1-8
ii  libomp-7-dev  1:7.0.1-8
ii  libstdc++68.3.0-7

flang-7 recommends no packages.

flang-7 suggests no packages.

-- no debconf information

Bug#927221: Note Bug #927291 Files

[Ron Lovell]

I just filed Bug #927291 against fuse3 to suggest making fuse and fuse3
co-installable. I recommend the Arch Linux approach of adding a fuse-common
file to supply mount.fuse and fuse.conf for both fuse and fuse3.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927291: Correction

[Ron Lovell]

In the leading paragraph, that should have been:

Currently on Buster and Sid the installation of fuse3 requires removal of
fuse.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927291: fuse3: More Work Needed to Make fuse and fuse3 Co-Installable

[Ron Lovell]

Package: fuse3
Version: 3.4.1-1
Severity: wishlist

Dear Maintainer,

Currently on Buster and Sid the installation of fuse requires removal of
fuse. It would be better if they were co-installable, as is the case on
other distros I run.

Currently pkg fuse3 has to have a "breaks" on fuse because they share
files mount.fuse, fusermount, and fuse.conf (possibly others e.g. docs).
Please see Mr. Simon McVittie's comments in Bug #927221. Please also see
my comments in #927221 about how Arch Linux and openSUSE Tumbleweed have
handled the situation so that fuse[2] and fuse3 are co-installable on
those distros.

On the face of it, the Arch approach is appealing. They provide a
fuse-common package which provides fuse.conf and a mount.fuse that works
for fuse2 and fuse3. Their fuse2 supplies fusermount, and their fuse3
supplies fusermount3.

The Arch fuse3 pkg supplies versioned names for man pages, libs, and
/usr/include/fuse3 subdir, so there are no filename conflicts with
fuse2. I can provide pkg file listings if needed.

For convenience, here are the files supplied by Arch fuse-common:

$ pacman -Ql fuse-common
fuse-common /etc/
fuse-common /etc/fuse.conf
fuse-common /usr/
fuse-common /usr/bin/
fuse-common /usr/bin/mount.fuse
fuse-common /usr/lib/
fuse-common /usr/lib/udev/
fuse-common /usr/lib/udev/rules.d/
fuse-common /usr/lib/udev/rules.d/99-fuse3.rules
fuse-common /usr/share/
fuse-common /usr/share/man/
fuse-common /usr/share/man/man8/
fuse-common /usr/share/man/man8/mount.fuse3.8.gz

If that approach is taken, then in Debian both fuse and fuse3 would
be changed to require a new fuse-common package.

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

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

Versions of packages fuse3 depends on:
ii  adduser 3.118
ii  libc6   2.28-8
ii  libfuse3-3  3.4.1-1
ii  lsb-base10.2019031300
ii  mount   2.33.1-0.1
ii  sed 4.7-1

fuse3 recommends no packages.

fuse3 suggests no packages.

-- Configuration Files:
/etc/fuse.conf [Errno 2] No such file or directory: '/etc/fuse.conf'
[Strange but true -- Even though fuse3 should install a /etc/fuse.conf,
there is none, even after reinstallating fuse3.]

-- no debconf information

Bug#921528: More Work Needed to Co-install fuse and fuse3

[Ron Lovell]

Apologies, that msg was intended for #912528. Pls disregard.

Bug#921528: More Work Needed to Co-install fuse and fuse3

[Ron Lovell]

Pls see Bug #927221 against gvfs-fuse, in particular Mr. Simon McVittie's
comments. For fuse and fuse3 to be co-installable, changes need to be made
to handle the file conflicts for mount.fuse,  fusermount, and fuse.conf.
Pls see my comments on how Arch and openSUSE have handled that so that
fuse[2] and fuse3 are co-installable on those distros.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#918984: Comment on Message #15

[Ron Lovell]

I really should learn to look before I speak. I just checked Buster, and
ntfs-3g and exfat-fuse don't require a version of fuse and should coexist
with fuse3. (I have exfat-fuse installed with fuse3 on Sid). Current
gvfs-fuse has a versioned requirement; the update to close #927221 changes
that to unversioned. On my Buster system it appears pkgs archivemount and
zfs-fuse have versioned dep on fuse.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#918984: Comment on Message #15

[Ron Lovell]

Several of the dependent packages including ones you listed could coexist
with fuse3 if the fuse3 package provided a versioned "fuse" instead of the
unversioned "fuse" it provides in 3.4.1-1. Pls see Bug #927221, where
gvfs-fuse is changed to require simply "fuse", but that's the hard way to
do it. Pls see Mr. McVittie's comments in #927221.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927221: Comparisons to Other Distros

[Ron Lovell]

Correction: On Tumbleweed, pkg fuse3 supplies mount.fuse3, not mount.fuse.
On Tue, Apr 16, 2019 at 9:14 PM Ron Lovell  wrote:

> Wow, that was quick.
>
> As a sanity check, I took a look at my Arch Linux and openSUSE Tumbleweed
> installations.  Each has both fuse[2] and fuse3 installed, each has the
> corresponding library installed.
>
> For Arch, a fuse-common pkg supplies /usr/bin/mount.fuse, which happens to
> be dyn linked to libfuse 3 (per ldd(1)).  Pkg fuse2 supplies
> /usr/bin/fusermount, not dyn linked to libfuse per ldd. Pkg fuse3 supplies
> /usr/bin/fusermount3, again not linked.
> gvfsd-fuse requires fuse2 and is linked to libfuse 2. sshfs requires fuse3
> and is linked to libfuse 3.
>
> For Tumbleweed, pkg fuse supplies /usr/sbin/mount.fuse, not linked to
> libfuse per ldd. Pkg fuse3 supplies /usr/sbin/mount.fuse which links to
> libfuse 3. Pkg fuse supplies /usr/bin/fusermount, not linked. Pkg fuse3
> supplies /usr/bin/fusermount3, not linked.
>
> On both systems I was able to use the fuse2 fusermount to unmount an sshfs
> (fuse3) mount, but that doesn't mean much.
>
> So I'm a wee bit worried that not having BOTH fuse and fuse co-installed
> might uncover problems in Debian. Time for lots of testing when the bits
> are available. I'll try to help out there.
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#927221: Comparisons to Other Distros

[Ron Lovell]

Wow, that was quick.

As a sanity check, I took a look at my Arch Linux and openSUSE Tumbleweed
installations.  Each has both fuse[2] and fuse3 installed, each has the
corresponding library installed.

For Arch, a fuse-common pkg supplies /usr/bin/mount.fuse, which happens to
be dyn linked to libfuse 3 (per ldd(1)).  Pkg fuse2 supplies
/usr/bin/fusermount, not dyn linked to libfuse per ldd. Pkg fuse3 supplies
/usr/bin/fusermount3, again not linked.
gvfsd-fuse requires fuse2 and is linked to libfuse 2. sshfs requires fuse3
and is linked to libfuse 3.

For Tumbleweed, pkg fuse supplies /usr/sbin/mount.fuse, not linked to
libfuse per ldd. Pkg fuse3 supplies /usr/sbin/mount.fuse which links to
libfuse 3. Pkg fuse supplies /usr/bin/fusermount, not linked. Pkg fuse3
supplies /usr/bin/fusermount3, not linked.

On both systems I was able to use the fuse2 fusermount to unmount an sshfs
(fuse3) mount, but that doesn't mean much.

So I'm a wee bit worried that not having BOTH fuse and fuse co-installed
might uncover problems in Debian. Time for lots of testing when the bits
are available. I'll try to help out there.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Ron Lovell]

On Tue, 16 Apr 2019 14:24:21 +0100 Simon McVittie 
wrote:

> Does fuse3 provide everything that's needed to mount and unmount
older
> FUSE filesystems that are still linked to libfuse2, like gvfs-fuse?
> 
> If it does, then gvfs-fuse can depend on fuse (>= 2.8.4) | fuse3, or
> just depend on plain "fuse" which is provided by fuse3 (since 2.8.4
is

Hello, Simon,

Thanks for your quick reply. Clearly I've been focused on library deps
only and didn't understand the importance of the utility commands. Let
me dig down and understand this better. BTW, I posted the message #15
about co-installability of fuse and fuse3 before I saw your message.
Did #912528 only solve part of the problem? There appears to be a
disconnect between the Bugs database and reality.

Building a modified package locally is something I certainly need to
learn how to do, so I'll work on that. Then I know I can test fuse-
exfat, the existing sshfs 2, and set up a Samba server.

Thanks for your very informative replay.
Best regards,
Ron

Bug#927221: gvfs dep on fuse

[Ron Lovell]

I should have mentioned that I've sidestepped the whole topic of
co-installability of pkgs fuse and fuse3. Despite closure of # 912528, on
my Sid system fuse3 3.4.1-1 has an explicit "breaks" on pkg fuse. At least,
that appears to be why installing fuse3 requires removing fuse. I could be
missing something. Resolution of that situation could make gvfs-fuse
versioned dep on fuse a moot point. My suggestion assumes no resolution of
that situation and just deals with things as they are.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Ron Lovell]

Package: gvfs-fuse
Version: 1.38.1-3
Severity: important

Dear Maintainer,

Basically this regards the transition from fuse to fuse3, my primary
motivation being to make the (Debian) world safe for a modern sshfs
(3.5+). As others have pointed out (g.e. Bug #918984), trying to replace
fuse with fuse3 would require removal of gnome-core and
task-gnome-desktop. On my Sid system, at least, it all comes down to
the dependency of gvfs-fuse on fuse (>= 2.8.4). The fuse3 package
provides "fuse", but apparently that doesn't satisfy the
version-specific dependency.

Note that there's no problem (on my system) co-installing libfuse2
and libfuse3-3. So a gvfs-fuse dependency on libfuse2 should not
be a problem.

Is the current dependency of gvfs-fuse on fuse (>=2.8.4) really
necessary? Would a dep on simply 'fuse' suffice? Or dep on libfuse2?

I'm currently working around this issue by removing gvfs-fuse,
gnome-core, and task-gnome-desktop, but manually keeping many of
the otherwise-unused dependencies. I wouldn't want to try to keep
this up long-term.

I agree this sounds more like a wishlist than important issue. But
the transition to fuse3 and sshfs 3+ seems to have hit a logjam,
and I'm just trying to help move things along. Hence the 'important'
severity level. It would be great if we could have sshfs 3.5.1+ in
Buster, or if not, at least in Sid soon.

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

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

Versions of packages gvfs-fuse depends on:
ii  fuse3 [fuse]  3.4.1-1
ii  gvfs  1.38.1-3
ii  libc6 2.28-8
ii  libfuse2  2.9.9-1
ii  libglib2.0-0  2.58.3-1

gvfs-fuse recommends no packages.

gvfs-fuse suggests no packages.

Note: The info about about fuse3 [fuse] 3.4.1-1 is misleading.
gvfs-fuse is not installable with fuse3 installed.

Bug#922275: libomp-7-dev

[Ron Lovell]

Or alternatively have /usr/lib//libomp.so point to libomp5.so so it
won't have to changed with LLVM version. The libomp5.so symlink is already
maintained by libomp-dev, so it will be updated with the libomp-dev release
updates.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#870608: There is a possible patch available

[Ron]

On Wed, Mar 06, 2019 at 03:15:40AM +0100, Elimar Riesebieter wrote:
> Hi all,
> 
> did someone checked
> 
> https://git.xiph.org/?p=libao.git;a=commit;h=d5221655dfd1a2156aa6be83b5aadea7c1e0f5bd
>  

You mean the commit which has :?

 authorRon   Sat, 13 Jan 2018 09:49:20 + (20:19 +1030)
 committer Ron   Sat, 13 Jan 2018 15:19:59 + (01:49 +1030)

It was a while ago now, but yeah, I *probably* looked at that one ...


For the people on the other bug(s), the analysis behind that is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870608#14

And the tldr version is, you can't punt this back to libao, and that
patch doesn't fix your bug.  AFAICS there is no bug in libao detected
by this "CVE", its test case explodes in libmad, not libao - and the
patch above just fixes some other potential issues I saw by eye while
auditing libao enough to give the analysis above.


And since Kurt seems to have done the same for libmad in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870406#25

It looks like the ball is squarely in the court of whoever cares about
mpg321 to do some debugging next and find what it's doing wrong.  And
then _possibly_ push back if some flaw in a support library really is
exacerbating the mistake it makes.

  Cheers,
  Ron

Bug#922275: libomp-7-dev: Feature Request To Have libomp-7-dev Install Symlink /usr/lib//libomp.so

[Ron Lovell]

Package: libomp-7-dev
Version: 1:7.0.1-6
Severity: wishlist

Dear Maintainer,

While testing flang-7 for OpenMP programs, I noticed that 'flang
-fopenmp=libomp' doesn't know to link libomp. (clang -fopenmp=libomp
has no problem.) It's easy enough to work around that by using linker
option -L/usr/lib/llvm-7/lib in the case of libomp-7-dev, with some
smarts in my meson.build to adjust to versions other than 7.

But it would be even better if libomp--dev installed a
symlink /usr/lib//libomp.so -> ../llvm-/lib/libomp.so
Then flang and other programs would find it in a standard library
directory.

It does install a /usr/lib//libomp5.so symlink, but Clang
doesn't accept -fopenmp=libomp5.

P.S. Wondering how I'm using Meson to build programs with Flang?
I hacked Meson. Let me know if you're interested.

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

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

Versions of packages libomp-7-dev depends on:
ii  libc6   2.28-7
ii  libgcc1 1:8.2.0-20
ii  libomp5-7   1:7.0.1-6
ii  libstdc++6  8.2.0-20

libomp-7-dev recommends no packages.

Versions of packages libomp-7-dev suggests:
pn  libomp-7-doc  

-- no debconf information

Bug#922102: ITP: libopusenc -- High-level API for encoding Ogg Opus audio streams

[Ron]

Package: wnpp
Severity: wishlist
Owner: Ron 

* Package name: libopusenc
  Version : 0.2.1
  Upstream Author : Xiph.Org
* URL : http://opus-codec.org/development/
* License : BSD
  Programming Lang: C
  Description : High-level API for encoding Ogg Opus audio streams

libopusenc provides a convenient high-level API for creating .opus files or
streaming Ogg Opus data.  It is implemented as a layer on top of Xiph.Org's
reference libopus library.


This library is now a dependency for future versions of opus-tools, and
it is intended to be a simple interface for other applications to use
too.

Bug#920882: Confirmation of Fix in libpmix2 3.1.2-2

[Ron Lovell]

My MPI issues were resolved by 3.1.2-2.
Great work, guys.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#920882: libpmix2 and Open MPI

[Ron Lovell]

The libpmix2 update causes my MPI programs compiled with
gcc/gfortran/clang  to fail at runtime with the same messages.
-- 
James Ronald Lovell 

Bug#917556: mesa: glxinfo Reports Mesa 18.2.7 for After 18.2.8-1 Upgrade

[Ron Lovell]

Source: mesa
Version: 18.2.8-1
Severity: normal

Dear Maintainer,

After upgrading to the Mesa 18.2.8-1 packages, glxinfo(1) still reports
the previous version:

lovelld@ron5sid:~$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: SVGA3D; build: RELEASE;  LLVM;
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 18.2.7
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.2.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Does a version string need to be updated in the source?

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

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

Newly updated Mesa packages include:
libegl1-mesa:amd64 18.2.8-1
libegl1-mesa-dev:amd64 18.2.8-1
libegl-mesa0:amd64 18.2.8-1
libgbm1:amd64 18.2.8-1
libgl1-mesa-dev:amd64 18.2.8-1
libgl1-mesa-dri:amd64 18.2.8-1
libgl1-mesa-glx:amd64 18.2.8-1
libglapi-mesa:amd64 18.2.8-1
libgles2-mesa-dev:amd64 18.2.8-1
libglx-mesa0:amd64 18.2.8-1
libwayland-egl1-mesa:amd64 18.2.8-1
libxatracker2:amd64 18.2.8-1
mesa-common-dev:amd64 18.2.8-1
mesa-va-drivers:amd64 18.2.8-1
mesa-vdpau-drivers:amd64 18.2.8-1
mesa-vulkan-drivers:amd64 18.2.8-1

Bug#916988: xserver-xorg-core: Upgrade does not apparently replace /usr/lib/xorg/modules/extensions/libglx.so

[Ron Murray]

Package: xserver-xorg-core
Version: 2:1.20.3-1rjmx0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   It seems that the upgrade to 2:1.20.3.1 did not replace
/usr/lib/xorg/modules/extensions/libglx.so for some reason and the
previous version was left in place. This kills attempts to use nvidia
4xx series video drivers, as X segfaults similar to this:

> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x58c349]
> (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7fb54db225ff]
> (EE) 2: /usr/lib64/xorg/modules/extensions/libglx.so 
> (GlxSetVisualConfigs+0x4cc) [0x7fb54c85fbdc]
> (EE) 3: /usr/lib64/xorg/modules/extensions/libglx.so (_init+0x193f2) 
> [0x7fb54c878272]
> (EE) 4: /usr/lib64/xorg/modules/extensions/libglx.so (_init+0x187fa) 
> [0x7fb54c876aea]
> (EE) 5: /usr/libexec/Xorg (InitExtensions+0x89) [0x4a8dd9]
> (EE) 6: /usr/libexec/Xorg (InitFonts+0x1db) [0x442f4b]
> (EE) 7: /lib64/libc.so.6 (__libc_start_main+0xeb) [0x7fb54d74b3db]
> (EE) 8: /usr/libexec/Xorg (_start+0x2a) [0x42de4a]
> (EE)
> (EE) Segmentation fault at address 0x7fb54c809138
> (EE)
> Fatal server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting


   Fedora apparently have the same problem: see

https://devtalk.nvidia.com/default/topic/1044851/linux/fyi-nvidia-410-78-driver-fails-with-segmentation-fault-on-fedora-fc29-workstation-with-nvs-510-card/post/5301228

   ... which is how I found the problem.

Excerpts from a failing Xorg.0.log:

> [94.098] xorg-server 2:1.20.3-1 (https://www.debian.org/support) 

...

> [94.107] (II) Module glx: vendor="X.Org Foundation"
> [94.107]  compiled for 1.19.3, module version = 1.0.0
> [94.107]  ABI class: X.Org Server Extension, version 10.0

   Note the correct version in the first excerpt (2:1.20.3-1) and that the
glx module (second excerpt, 1.19.3) is a different version.

   Please ignore the slighly different version number in this report:
I did a local build of the package to see if it helped. It did not.

   Currentlt the problem can be fixed by uninstalling
xserver-xorg-core and its dependencies (uninstall any nvidia drivers
first), check that the directory /usr/lib/xorg/modules/extensions/ is
non-existent, or at least empty. Then reinstall xserver-xorg-core and 
dependencies.

 .Ron Murray

- -- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
- --
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 
770] [10de:1184] (rev a1)

Xorg X server configuration file status:
- 
- -rw-r--r-- 1 root root 1259 Dec 20 23:31 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
- ---
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 415.25


Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Unknown"
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
Depth   24
EndSubSection
EndSection


/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
- ---
Linux version 4.19.11.khufu (ron@khufu) (gcc version 8.2.0 (Debian 8.2.0-12)) 
#0 SMP PREEMPT Wed Dec 19 23:38:15 EST 2018

Xorg X server log files on system:
- --
- -rw-r--r-- 1 root root 38288 Dec 20 23:34 /var/log/Xorg.0.log

Contents of most r

Bug#541544: [PATCH] ash: reset tokpushback before prompting while parsing heredoc

[Ron Yorston]

Alexander Dahl wrote:
>By chance, is that old Debian Bug here referencing the same problem?
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541544

It's not the same.  The Debian bug is fixed by dash commit 51e2d88
(parser: Save/restore here-documents in command substitution) from
19 May 2018.

Ron

Bug#913811: Bug #913811 Correction to previous

[Ron Lovell]

Oops. Last one should be:

[ -d path ] && [ ! -L path ]

-- 
James Ronald Lovell 

Bug#913811: Bug #913811iptables

[Ron Lovell]

I still remember the first time that one bit me: "[ -e path]" fails if path
is a dead symlink. There are other pitfalls testing symlinks.  Some idioms
I use:

Does path exist?
[ -e path ] || [ -L path ]

Is path really a regular file?
[ -f path ] && [ ! -L path ]

A directory?
[ -d path ] && [ ! -d path ]
-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#910251: Bug@910251 Confirmation of Fix

[Ron Lovell]

The delays and warning messages for my MPI programs on Sid were resolved by
the workaround fix in libpsm2 11.2.68-2. You can close this one as far as
I'm concerned.

Thanks,
Ron
-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#910251:

[Ron Lovell]

That should be libpsm2-2 11.2.68-1, not .78.

On Mon, Oct 8, 2018 at 1:39 PM Ron Lovell  wrote:

> Alastair,
>
> Thanks for the quick update. I see that I upgraded to libpsm2-2 11.2.78-1
> on 01 Oct 2018, so the timing fits.
>
> Thanks,
> Ron
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>


-- 
James Ronald Lovell 
Huntsville, AL, USA