Bug#995265: ethtool: Buffer overflow booting up network interface

[Salvatore Bonaccorso]

Hi Dario,

On Tue, Sep 28, 2021 at 02:04:39PM -0300, Dario Susman wrote:
> Package: ethtool
> Version: 1:5.9-1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> Upgraded to latest testing branch, the attached dmesg output displays a
> buffer overflow from/on ethtool. May be is kernel related. I'm not sure.
> 
> While the bug does not appear to hamper network connectivity so far, the
> buffer overflow kernel message shows up quite often.

This should be #995265.

Regards,
Salvatore

Bug#995282: amule crashes on start

[Stefan Rücker]

Package: amule
Version: 1:2.3.3-1
Severity: grave

(gdb) run
Starting program: /usr/bin/amule
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 7263]
 2021-09-29 07:08:05: Initialising aMule 2.3.3 compiled with wxGTK2 v3.0.5 and
Boost 1.74
 2021-09-29 07:08:05: Checking if there is an instance already running...
 2021-09-29 07:08:05: No other instances are running.

Program received signal SIGSEGV, Segmentation fault.
0x77ca062c in CryptoPP::SecureWipeBuffer
(n=2305843009213693951, buf=0x2) at misc.h:1442
1442misc.h: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x77ca062c in CryptoPP::SecureWipeBuffer
(n=2305843009213693951, buf=0x2) at misc.h:1442
#1  CryptoPP::SecureWipeArray (n=2305843009213693951, buf=0x2)
at misc.h:1493
#2  CryptoPP::AllocatorWithCleanup::deallocate
(size=2305843009213693951, ptr=0x2, this=) at secblock.h:235
#3  CryptoPP::StandardReallocate > (oldPtr=0x2,
oldSize=2305843009213693951, newSize=8, preserve=, alloc=...) at
secblock.h:172
#4  0x77ca350a in CryptoPP::AllocatorWithCleanup::reallocate (preserve=false, newSize=8, oldSize=,
oldPtr=, this=) at secblock.h:259
#5  CryptoPP::SecBlock >::New (newSize=8, this=) at secblock.h:1128
#6  CryptoPP::SecBlock >::CleanNew (newSize=8, this=) at secblock.h:1145
#7  CryptoPP::Integer::Decode (this=0x56c4ee20, bt=..., inputLen=, s=) at integer.cpp:3397
#8  0x77caae4e in CryptoPP::Integer::BERDecode
(this=this@entry=0x56c4ee20, bt=...) at asn.h:405
#9  0x77dfea1b in CryptoPP::InvertibleRSAFunction::BERDecodePrivateKey
(this=0x56c4ed48, bt=...) at rsa.cpp:211
#10 0x77cb6e98 in CryptoPP::PKCS8PrivateKey::BERDecode
(this=this@entry=0x56c4edc8, bt=...) at asn.cpp:679
#11 0x5575e7fb in CryptoPP::InvertibleRSAFunction::BERDecode (bt=...,
this=0x56c4ed48) at /usr/include/cryptopp/rsa.h:100
#12
CryptoPP::PK_FinalTemplate, CryptoPP::RSA,
CryptoPP::PKCS1v15_SignatureMessageEncodingMethod, CryptoPP::SHA1> >
>::PK_FinalTemplate (
bt=..., this=0x56c4ed30) at /usr/include/cryptopp/pubkey.h:2196
#13 CClientCreditsList::InitalizeCrypting (this=0x56ddd230) at
../../src/ClientCreditsList.cpp:311
#14 0x5575fa24 in CClientCreditsList::CClientCreditsList
(this=0x56ddd230) at ../../src/ClientCreditsList.cpp:54
#15 0x55745ffe in CamuleApp::OnInit (this=this@entry=0x55c3bc20) at
../../src/amule.cpp:513
#16 0x558079f7 in CamuleGuiApp::OnInit (this=0x55c3bc20) at
../../src/amule-gui.cpp:288
#17 0x770093aa in wxEntry (argc=, argv=)
at ../src/common/init.cpp:490
#18 0x5571b562 in main (argc=, argv=) at
../../src/amule-gui.cpp:95

(gdb) bt full
#0  0x77ca062c in CryptoPP::SecureWipeBuffer
(n=2305843009213693951, buf=0x2) at misc.h:1442
p = 0x2
#1  CryptoPP::SecureWipeArray (n=2305843009213693951, buf=0x2)
at misc.h:1493
No locals.
#2  CryptoPP::AllocatorWithCleanup::deallocate
(size=2305843009213693951, ptr=0x2, this=) at secblock.h:235
No locals.
#3  CryptoPP::StandardReallocate > (oldPtr=0x2,
oldSize=2305843009213693951, newSize=8, preserve=, alloc=...) at
secblock.h:172
No locals.
#4  0x77ca350a in CryptoPP::AllocatorWithCleanup::reallocate (preserve=false, newSize=8, oldSize=,
oldPtr=, this=) at secblock.h:259
No locals.
#5  CryptoPP::SecBlock >::New (newSize=8, this=) at secblock.h:1128
No locals.
#6  CryptoPP::SecBlock >::CleanNew (newSize=8, this=) at secblock.h:1145
No locals.
#7  CryptoPP::Integer::Decode (this=0x56c4ee20, bt=..., inputLen=, s=) at integer.cpp:3397
b = 30 '\036'
#8  0x77caae4e in CryptoPP::Integer::BERDecode
(this=this@entry=0x56c4ee20, bt=...) at asn.h:405
dec = { =
{
>> = {> =
{ = { =
{ = {_vptr.Clonable = 0x77f1fed8 }, },  =
{_vptr.Waitable = 0x77f20070 },
m_buf = "\001\000\000\000\000\000\000"}, },
  m_autoSignalPropagation = -1}, m_messageEnd = false}, m_inQueue =
@0x7fffd640, m_length = 48, m_finished = false, m_definiteLength = true}
#9  0x77dfea1b in CryptoPP::InvertibleRSAFunction::BERDecodePrivateKey
(this=0x56c4ed48, bt=...) at rsa.cpp:211
privateKey = { = { =
{
>> = {> =
{ = { =
{ = {_vptr.Clonable = 0x77f1e840 }, },  =
{_vptr.Waitable = 0x77f1e9d8 },
m_buf = "`\327\377\377\377\177\000"}, },
m_autoSignalPropagation = -1}, m_messageEnd = false}, m_inQueue =
@0x7fffd760, m_length = 182, m_finished = false, m_definiteLength = true},
}
version = 0
#10 0x77cb6e98 in CryptoPP::PKCS8PrivateKey::BERDecode
(this=this@entry=0x56c4edc8, bt=...) at asn.cpp:679
privateKeyInfo = { = { =
{
>> = {> =
{ = { =
{ = {_vptr.Clonable = 0x77f1e840 }, },  =
{_vptr.Waitable = 0x77f1e9d8 },
m_buf = "\000\000\000\000\000\000\000"}, },
m_autoSignalPropagation = -1}, m_messageEnd = false}, m_inQueue =
@0x7fffd950, 

Bug#995281: lomiri-download-manager: FTBFS due to symbols changes

[Steve Langasek]

Source: lomiri-download-manager
Version: 0.1.0-8
Severity: serious

Hi Mike,

The lomiri-download-manager package fails to build in unstable, because of
some symbols file mismatches:

[...]
dpkg-gensymbols: warning: 
debian/liblomiri-download-manager-common0/DEBIAN/symbols doesn't match 
completely debian/liblomiri-download-manager-common0.symbols
--- debian/liblomiri-download-manager-common0.symbols 
(liblomiri-download-manager-common0_0.1.0-8_amd64)
+++ dpkg-gensymbolsKFBfk1   2021-09-29 04:28:53.866805288 +
@@ -34,8 +34,8 @@
  _ZN6Lomiri15DownloadManager19GroupDownloadStructC2ERK7QStringS4_S4_@Base 0.1.0
  _ZN6Lomiri15DownloadManager19GroupDownloadStructC2ERKS1_@Base 0.1.0
  _ZN6Lomiri15DownloadManager19GroupDownloadStructC2Ev@Base 0.1.0
- (arch=armel armhf)_ZN6Lomiri15DownloadManager19GroupDownloadStructD1Ev@Base 
0.1.0
- (arch=armel armhf)_ZN6Lomiri15DownloadManager19GroupDownloadStructD2Ev@Base 
0.1.0
+ _ZN6Lomiri15DownloadManager19GroupDownloadStructD1Ev@Base 0.1.0
+ _ZN6Lomiri15DownloadManager19GroupDownloadStructD2Ev@Base 0.1.0
  _ZN6Lomiri15DownloadManager19GroupDownloadStructaSERKS1_@Base 0.1.0
  _ZN6Lomiri15DownloadManagerlsER13QDBusArgumentRKNS0_14DownloadStructE@Base 
0.1.0
  
_ZN6Lomiri15DownloadManagerlsER13QDBusArgumentRKNS0_19DownloadStateStructE@Base 
0.1.0
dpkg-gensymbols: warning: 
debian/liblomiri-download-manager-client0/DEBIAN/symbols doesn't match 
completely debian/liblomiri-download-manager-client0.symbols
--- debian/liblomiri-download-manager-client0.symbols 
(liblomiri-download-manager-client0_0.1.0-8_amd64)
+++ dpkg-gensymbolsUJ6Ro5   2021-09-29 04:28:53.982805242 +
@@ -131,14 +131,14 @@
  _ZNK6Lomiri15DownloadManager9DBusError10metaObjectEv@Base 0.1.0
  _ZNK6Lomiri15DownloadManager9HashError10metaObjectEv@Base 0.1.0
  _ZNK6Lomiri15DownloadManager9HttpError10metaObjectEv@Base 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13DownloadsListEEEC1ERKS5_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13DownloadsListEEEC2ERKS5_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13GroupDownloadEEEC1ERKS5_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13GroupDownloadEEEC2ERKS5_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager8DownloadEEEC1ERKS5_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager8DownloadEEEC2ERKS5_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvRK7QStringS2_PN6Lomiri15DownloadManager13DownloadsListEEEC1ERKS8_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvRK7QStringS2_PN6Lomiri15DownloadManager13DownloadsListEEEC2ERKS8_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13DownloadsListEEEC1ERKS5_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13DownloadsListEEEC2ERKS5_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13GroupDownloadEEEC1ERKS5_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager13GroupDownloadEEEC2ERKS5_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager8DownloadEEEC1ERKS5_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvPN6Lomiri15DownloadManager8DownloadEEEC2ERKS5_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvRK7QStringS2_PN6Lomiri15DownloadManager13DownloadsListEEEC1ERKS8_@Base
 0.1.0
+#MISSING: 0.1.0-8# 
(optional=templinst|arch=amd64)_ZNSt8functionIFvRK7QStringS2_PN6Lomiri15DownloadManager13DownloadsListEEEC2ERKS8_@Base
 0.1.0
  _ZTIN6Lomiri15DownloadManager12NetworkErrorE@Base 0.1.0
  _ZTIN6Lomiri15DownloadManager12ProcessErrorE@Base 0.1.0
  _ZTIN6Lomiri15DownloadManager13DownloadsListE@Base 0.1.0
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:54: binary] Error 25
[...]

I discovered this error because the package also fails to build in Ubuntu,
albeit with a different set of symbol errors:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file
: see diff output below
dpkg-gensymbols: warning: debian/libldm-common0/DEBIAN/symbols doesn't match com
pletely debian/libldm-common0.symbols
--- debian/libldm-common0.symbols (libldm-common0_0.1.0-8_amd64)
+++ dpkg-gensymbolsRpfeei   2021-09-29 02:38:00.468167849 +
@@ -75,9 +75,9 @@
  _ZN6Lomiri9Transfers6System14DBusConnectionC1EP7QObject@Base 0.1.0
  _ZN6Lomiri9Transfers6System14DBusConnectionC2E15QDBusConnectionP7QObject@Base 
0.1.0
  

Bug#990210: fixed in cups-pdf 3.0.1-12

[Martin-Éric Racine]

Reopening.

It seems that Andre was talking about an entirely different issue
(deprecated Ghostscript option) and somehow tagged along onto this
bug.

Getting back to your issue, a few things come to mind:

1) Bug#931363
2) Upgrade from an older CUPS-PDF that didn't use the Cairo backend.
The maintainer make no attempt to change the backend used.
3) Ghostscript version.

Martin-Éric

ti 28. syysk. 2021 klo 22.54 наб (nabijaczlew...@nabijaczleweli.xyz) kirjoitti:
>
> On Tue, Sep 28, 2021 at 03:30:40PM +0300, Martin-Éric Racine wrote:
> > I'd still like to hear from the bug submitter before I decide on
> > backporting anything to stable-updates.
>
> Having not had updated in a while, I have the same cups as bullseye
> (2.3.3op2-3+deb11u1); combining this with cups-pdf 3.0.1-12,
> "lp -dPDF POSIX.2.ps" gives me:
> -- >8 --
> Tue Sep 28 21:37:09 2021  [DEBUG] *** Final Configuration ***
> Tue Sep 28 21:37:09 2021  [DEBUG] AnonDirName= 
> "/var/spool/cups-pdf/ANONYMOUS"
> Tue Sep 28 21:37:09 2021  [DEBUG] AnonUser   = "nobody"
> Tue Sep 28 21:37:09 2021  [DEBUG] GhostScript= "/usr/bin/gs"
> Tue Sep 28 21:37:09 2021  [DEBUG] GSCall = "%s -q 
> -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite 
> -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false 
> -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s"
> Tue Sep 28 21:37:09 2021  [DEBUG] Grp= "lpadmin"
> Tue Sep 28 21:37:09 2021  [DEBUG] GSTmp  = "TMPDIR=/var/tmp"
> Tue Sep 28 21:37:09 2021  [DEBUG] Log= "/var/log/cups"
> Tue Sep 28 21:37:09 2021  [DEBUG] PDFVer = "1.2"
> Tue Sep 28 21:37:09 2021  [DEBUG] PostProcessing = ""
> Tue Sep 28 21:37:09 2021  [DEBUG] Out= "${HOME}/PDF"
> Tue Sep 28 21:37:09 2021  [DEBUG] Spool  = 
> "/var/spool/cups-pdf/SPOOL"
> Tue Sep 28 21:37:09 2021  [DEBUG] UserPrefix = ""
> Tue Sep 28 21:37:09 2021  [DEBUG] RemovePrefix   = ""
> Tue Sep 28 21:37:09 2021  [DEBUG] OutExtension   = "pdf"
> Tue Sep 28 21:37:09 2021  [DEBUG] Cut= 3
> Tue Sep 28 21:37:09 2021  [DEBUG] Truncate   = 64
> Tue Sep 28 21:37:09 2021  [DEBUG] DirPrefix  = 0
> Tue Sep 28 21:37:09 2021  [DEBUG] Label  = 1
> Tue Sep 28 21:37:09 2021  [DEBUG] LogType= 7
> Tue Sep 28 21:37:09 2021  [DEBUG] LowerCase  = 1
> Tue Sep 28 21:37:09 2021  [DEBUG] TitlePref  = 0
> Tue Sep 28 21:37:09 2021  [DEBUG] DecodeHexStrings   = 1
> Tue Sep 28 21:37:09 2021  [DEBUG] FixNewlines= 0
> Tue Sep 28 21:37:09 2021  [DEBUG] AllowUnsafeOptions = 0
> Tue Sep 28 21:37:09 2021  [DEBUG] AnonUMask  = 
> Tue Sep 28 21:37:09 2021  [DEBUG] UserUMask  = 0077
> Tue Sep 28 21:37:09 2021  [DEBUG] *** End of Configuration ***
> Tue Sep 28 21:37:09 2021  [DEBUG] set new gid: lpadmin
> Tue Sep 28 21:37:09 2021  [DEBUG] initialization finished: v3.0.1
> Tue Sep 28 21:37:09 2021  [DEBUG] user identified: nabijaczleweli
> Tue Sep 28 21:37:09 2021  [DEBUG] output directory name generated: 
> /home/nabijaczleweli/PDF
> Tue Sep 28 21:37:09 2021  [DEBUG] user information prepared
> Tue Sep 28 21:37:09 2021  [DEBUG] spoolfile name created: 
> /var/spool/cups-pdf/SPOOL/cups2pdf-7550
> Tue Sep 28 21:37:09 2021  [DEBUG] source stream ready
> Tue Sep 28 21:37:09 2021  [DEBUG] destination stream ready: 
> /var/spool/cups-pdf/SPOOL/cups2pdf-7550
> Tue Sep 28 21:37:09 2021  [DEBUG] owner set for spoolfile: 
> /var/spool/cups-pdf/SPOOL/cups2pdf-7550
> Tue Sep 28 21:37:09 2021  [DEBUG] using traditional fgets
> Tue Sep 28 21:37:09 2021  [DEBUG] found beginning of postscript code: 
> %!PS-Adobe-3.0
>
> Tue Sep 28 21:37:09 2021  [DEBUG] now extracting postscript code
> Tue Sep 28 21:37:09 2021  [DEBUG] found title in ps code: stdin
> nabijaczleweli/PDF
> Tue Sep 28 21:37:09 2021  [DEBUG] found end of postscript code: %%EOF
>
> Tue Sep 28 21:37:09 2021  [DEBUG] all data written to spoolfile: 
> /var/spool/cups-pdf/SPOOL/cups2pdf-7550
> Tue Sep 28 21:37:09 2021  [DEBUG] trying to use PS title: stdin
> nabijaczleweli/PDF
> Tue Sep 28 21:37:09 2021  [STATUS] ***Experimental Option: DecodeHexStrings
> Tue Sep 28 21:37:09 2021  [DEBUG] checking for hex strings: stdin
> nabijaczleweli/PDF
> Tue Sep 28 21:37:09 2021  [DEBUG] not a hex string, has no start marker: stdin
> nabijaczleweli/PDF
> Tue Sep 28 21:37:09 2021  [DEBUG] calling alternate_replace_string
> Tue Sep 28 21:37:09 2021  [DEBUG] removing alternate special characters from 
> title: stdin
> nabijaczleweli/PDF
> Tue Sep 28 21:37:09 2021  [DEBUG] title successfully retrieved: 
> job_21-stdin_nabijaczleweli_PDF
> Tue Sep 28 21:37:09 2021  [DEBUG] input data read from stdin
> Tue Sep 28 21:37:09 2021  [DEBUG] output filename created: 
> /home/nabijaczleweli/PDF/job_21-stdin_nabijaczleweli_PDF.pdf
> Tue Sep 28 21:37:09 2021  [DEBUG] ghostscript commandline built: /usr/bin/gs 
> -q 

Bug#995276: linux-image-5.14.0-1-arm64: missing vmwgfx graphics driver

[Ronny Kotzschmar]

Package: src:linux
Version: 5.14.6-2
Severity: wishlist
X-Debbugs-Cc: ro...@me.com

Dear Maintainer,

please include the "DRM driver for VMware Virtual GPU“. This driver is available
for the X86 and ARM64 architectures and in "linux-image-5.14.0-1-amd64“ already
included.

Thank you
Ronny Kotzschmar

Bug#868580: closed by Simon McVittie (Re: Bug#868580: cairo: CVE-2017-9814)

[Salvatore Bonaccorso]

Simon,

On Tue, Sep 28, 2021 at 09:47:31PM +0100, Simon McVittie wrote:
> On Tue, 28 Sep 2021 at 22:07:26 +0200, Salvatore Bonaccorso wrote:
> > > This appears to have been fixed in 1.15.14, which means it's fixed in
> > > buster and bullseye.
> > 
> > I cannot check right now, but is this correct? The upstream issue
> > https://gitlab.freedesktop.org/cairo/cairo/-/issues/264 seems to have
> > been closed only very recently a few weeks ago, or where those only
> > additional followups?
> 
> Those were additional followups, as far as I can tell. If they fixed
> additional security issues in the same pattern, then those additional
> security issues would need a separate CVE.

Ack, thank you. Updated the security-tracker earlier then with the
fixed version.

Regards,
Salvatore

Bug#995280: gnome-builder cannot open or create projects

[Stephan Verbücheln]

Package: gnome-builder
Version: 41.1-1

When I try to open or create a project, gnome-builder gets stuck. It
prints the following warning, which may be related:

$ gnome-builder 
05:18:55.3027  ide-subproces-supervisor[ 7160]: 
WARNING: Failed to execute child process “/usr/libexec/gnome-builder-
flatpak” (No such file or directory)

The corresponding binary does not exist in this path or anywhere else
in /usr.

I am using Debian Sid with all recent package versions. I did not
experience this problem with gnome-builder 3.40.x.

Bug#590600: rdiff-backup to an nfs

[Pablo Mestre]

Hi Moritz Molle

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 


Moritz Molle it is possible to report this error at
https://github.com/rdiff-backup/rdiff-backup/issues 


Greetings

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#684764: rdiff-backup_1.2.8-7_amd64 python (>= 2.6.6-7~) dependency problem

[Pablo Mestre]

Hi

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#781844: rdiff-backup: crashed after hitting process memory limit

[Pablo Mestre]

Hi Matt Taggart 

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#774834: rdiff-backup: When backing up to a vfat partition on a remote host, rdiffbackup fails on case-sensitive dirnames

[Pablo Mestre]

Hi Kasper Loopstra

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#819370: rdiff-backup: does not follow symlinks to directories given on the command line

[Pablo Mestre]

Hi Christian Pernegger

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#557951: option to force backup (--include-if-present)

[Pablo Mestre]

As this bugs is a request for the upstreamer I open an issue [1] and
forward the request to this bug.

[1] https://github.com/rdiff-backup/rdiff-backup/issues/625

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#995279: ayatana-indicator-datetime: Fails to build from source

[Jeremy Bicha]

Source: ayatana-indicator-datetime
Version: 0.8.2-1
Severity: serious
Tags: patch sid bookworm
Control: blocks 993945 by -1

Please apply this commit to Debian to fix this package's failure to
build from source.

https://github.com/AyatanaIndicators/ayatana-indicator-datetime/commit/19923632

This is needed to complete the evolution-data-server 3.42 transition.

Thanks,
Jeremy Bicha

Bug#500399: Please improve the following message "No space left on device"

[Pablo Mestre]

As this bugs is a request for the upstreamer I open an issue [1] and
forward the request to this bug.

[1] https://github.com/rdiff-backup/rdiff-backup/issues/624

 -- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#536750: option to not chmod() on destination at all

[Pablo Mestre]

As this bugs is a request for the upstreamer I open an issue [1] and
forward the request to this bug.

[1] https://github.com/rdiff-backup/rdiff-backup/issues/623

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Elliott Mitchell]

On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote:
> On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote:
> >
> > > Could the domain ID be used for that?
> >
> > I don't like it because it only says how recent a domain was
> > started relative to others, not any intention about start/stop
> > order. Shut one down manually (or crash) and start it again and it
> > gets a new domid higher than all existing.
>
> It is a (really) simple heuristic and likely too simple.
> But at first glance it seemed (to me) to actually do the right thing.

It is *definitely* too simple to do a good job; however, this has the
advantages of being a significant improvement and simple enough to be in 
service quickly.


On Wed, Sep 29, 2021 at 01:24:58AM +0200, Diederik de Haas wrote:
> On Wednesday, 29 September 2021 00:02:46 CEST Andy Smith wrote:
> > On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote:
> > The idea of the domid controlling/influencing order of shutdown
> 
> It was just an idea that popped in my head. All in all I've likely spend less 
> then a minute thinking about the domid idea.
> Don't spend more on it then you already have ;)

The record shows I suggested it first:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452721#35

This isn't an adaquate solution, but is a distinct improvement.


> > > I really agree with the 'upstream' tag as not only should it be
> > > fixed/adjusted there, but it also engages a (much) larger audience who
> > > think of scenarios we likely didn't think about.
> > 
> > Should we move discussion to xen-us...@lists.xen.org then?
> 
> I can make a case for both xen-users and xen-devel.
> xen-users:
> It could be that a solution already exists. I know that in Qubes (which uses 
> Xen) has some dependency mechanism in that if you start vmA which depends on 
> vmB, then it first starts vmB and then vmA. I don't know if that is a Qubes 
> 'extension' or that they simply use available functionality of Xen.

Could be interesting to learn of what solutions are already out there and
what features are must have.  Most existing solutions likely have
problems.  Some may be GPL-incompatible.  Most are likely very limited.


> xen-devel:
> If needed functionality doesn't yet exist and needs to be built anew, then 
> xen-devel is the right place to discuss that.
> 
> It could be that the best place to start is xen-users which then may/could 
> 'transition' to xen-devel.
> 
> Let's hear others first what they think is the best approach.

Perhaps.  Question is how much person-time is available for this?

If a great deal of xen-devel person-time can be devoted to this a very
ambitious solution might be viable.  If only a little bit of xen-devel
person-time is available, the approach would need to be very limited.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#995278: bullseye-pu: package iotop-c/1.17-1

[Boian Bonev]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Please discard the upload of iotop-c_1.19-1~bpo11+1 from the proposed updates 
queue.

I was targeting bullseye-backports but have built it in the wrong sbuild chroot 
and didn't notice that the changes file contains the wrong distribution.

Sorry for the noise :(

Bug#995187: qtwebengine-opensource-src FTBFS on mips*: unistd_nr_{n32,n64,o32}.h no linger exported by the kernel

[YunQiang Su]

YunQiang Su  于2021年9月28日周二 下午12:20写道：
>
> Adrian Bunk  于2021年9月28日周二 上午12:06写道：
> >
> > Source: qtwebengine-opensource-src
> > Version: 5.15.5+dfsg-2
> > Severity: serious
> > Tags: ftbfs
> >
> > https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src=mips64el=5.15.6%2Bdfsg-1=1632387575=0
> >
> > ...
> > FAILED: obj/sandbox/linux/seccomp_bpf/syscall_set.o
> > /usr/bin/g++ -MMD -MF obj/sandbox/linux/seccomp_bpf/syscall_set.o.d 
> > -DSANDBOX_IMPLEMENTATION -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 
> > -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 
> > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES 
> > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND 
> > -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -Igen 
> > -I../../3rdparty/chromium 
> > -I../../3rdparty/chromium/third_party/perfetto/include 
> > -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen 
> > -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/abseil-cpp 
> > -I../../3rdparty/chromium/third_party/boringssl/src/include 
> > -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out 
> > -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector 
> > -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread 
> > -D__SANE_USERSPACE_TYPES__ -mips64r2 -Wa,-mips64r2 -Wall -U_FORTIFY_SOURCE 
> > -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
> > -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments 
> > -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers 
> > -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections 
> > -fno-omit-frame-pointer -g0 -fvisibility=hidden -std=gnu++14 -Wno-narrowing 
> > -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess 
> > -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type 
> > -Wno-deprecated-copy -fno-exceptions -fno-rtti -fvisibility-inlines-hidden 
> > -c ../../3rdparty/chromium/sandbox/linux/bpf_dsl/syscall_set.cc -o 
> > obj/sandbox/linux/seccomp_bpf/syscall_set.o
> > In file included from 
> > ../../3rdparty/chromium/sandbox/linux/bpf_dsl/syscall_set.cc:12:
> > ../../3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h:47:10: 
> > fatal error: asm/unistd_nr_n64.h: No such file or directory
> >47 | #include   // for __NR_64_Linux and 
> > __NR_64_Linux_syscalls
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccb21774863add648e709337919d2cfeefe4be49
> This commit change the struct of unistd*.h files.
> And I guess that we can just drop mipsel-linux-5.patch now.
> I am testing it.
>

Ohh, the new mips linux kernel removes some macros: so now we can use
the same code as x86:

Index: 
qtwebengine-opensource-src-5.15.6+dfsg/src/3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h
===
--- 
qtwebengine-opensource-src-5.15.6+dfsg.orig/src/3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h
+++ 
qtwebengine-opensource-src-5.15.6+dfsg/src/3rdparty/chromium/sandbox/linux/bpf_dsl/linux_syscall_ranges.h
@@ -35,18 +35,11 @@
 #define MIN_GHOST_SYSCALL   (MIN_PRIVATE_SYSCALL + 0xfff0u)
 #define MAX_SYSCALL (MIN_GHOST_SYSCALL + 4u)

-#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_32_BITS)
+#elif defined(ARCH_CPU_MIPS_FAMILY)

-#include   // for __NR_O32_Linux and __NR_Linux_syscalls
-#define MIN_SYSCALL __NR_O32_Linux
-#define MAX_PUBLIC_SYSCALL  (MIN_SYSCALL + __NR_Linux_syscalls)
-#define MAX_SYSCALL MAX_PUBLIC_SYSCALL
-
-#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(ARCH_CPU_64_BITS)
-
-#include   // for __NR_64_Linux and __NR_64_Linux_syscalls
-#define MIN_SYSCALL __NR_64_Linux
-#define MAX_PUBLIC_SYSCALL  (MIN_SYSCALL + __NR_64_Linux_syscalls)
+#include 
+#define MIN_SYSCALL __NR_Linux
+#define MAX_PUBLIC_SYSCALL  (MIN_SYSCALL + 999u)
 #define MAX_SYSCALL MAX_PUBLIC_SYSCALL

 #elif defined(__aarch64__)

>
> >   |  ^
> > compilation terminated.
> > ...
> >
> >
> > Context:
> > https://sources.debian.org/src/qtwebengine-opensource-src/5.15.6+dfsg-1/debian/patches/mipsel-linux-5.patch/
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccb21774863a
> >
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#995214: Wide apostrophe ending up on single width pages

[Yao Wei (魏銘廷)]

Hi,

> On Sep 28, 2021, at 13:54, 積丹尼 Dan Jacobson  wrote:
> 
> Why is this happening in Firefox and Chrome?
> $ LC_CTYPE=zh_TW.UTF-8 $BROWSER http://ud.taichung.gov.tw/

See

https://github.com/adobe-fonts/source-han-sans/issues/28

On the font perspective the same codepoints for curly apostrophes and quotation 
marks are used for Japanese and Korean and they are full-width.

You can try preferring Latin fonts to CJK fonts.

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

Bug#995271: nvidia-kernel-dkms: does not install with linux-image-5.14-amd64

[ElectronBadger]

Package: nvidia-kernel-dkms
Version: 470.57.02-2
Severity: important
X-Debbugs-Cc: electron.bad...@tutanota.com

Dear Maintainer,

   * What led up to the situation?

Upgrading kernel from 5.10.8 (amd64) to 5.14 (amd64)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

sudo apt install linux-image-5.14.0-1-amd64

   * What was the outcome of this action?

Building initial module for 5.14.0-1-amd64
Error! Bad return status for module build on kernel: 5.14.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/470.57.02/build/make.log for more 
information.
dpkg: error processing package nvidia-kernel-dkms (--configure):
 installed nvidia-kernel-dkms package post-installation script subprocess 
returned error exit status 10
Errors were encountered while processing:
 nvidia-kernel-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)

After that the system does not start X after reboot.

   * What outcome did you expect instead?

Usable nvidia drivers.

-- Package-specific info:
uname -a:
Linux shogun 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 
GNU/Linux

/proc/version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  470.57.02  Tue Jul 13 16:14:05 
UTC 2021
GCC version:  gcc version 10.3.0 (Debian 10.3.0-11) 

lspci 'display controller [030?]':
48:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106GL [Quadro 
P2200] [10de:1c31] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation GP106GL [Quadro P2200] [10de:131b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Sep 28 19:48 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Sep 28 19:48 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Sep 28 19:48 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Sep 28 19:48 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Sep 28 19:48 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Sep 28 19:48 pci-:48:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Sep 28 19:48 pci-:48:00.0-render -> ../renderD128
video:x:44:eb

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1857 Aug 30 11:39 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Apr 25 22:47 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Apr 25 23:34 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   51 Apr 25 22:47 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Apr 25 23:34 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Apr 25 23:34 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   50 Apr 25 22:47 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Apr 25 22:47 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 Apr 25 23:34 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Apr 25 23:34 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   57 Apr 25 22:47 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Apr 25 22:47 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   52 Apr 25 23:34 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 Apr 25 23:34 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   54 Apr 25 22:47 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Apr 25 22:47 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   44 Apr 25 22:47 

Bug#995214: Wide apostrophe ending up on single width pages

[Yao Wei (魏銘廷)]

> On Sep 29, 2021, at 08:58, Yao Wei (魏銘廷)  wrote:
> 
> On the font perspective the same codepoints for curly apostrophes and 
> quotation marks are used for Japanese and Korean and they are full-width.

My mistake. It's Traditional and Simplified Chinese that's full-width by 
default.

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

[Reinhard Tartler]

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

Please unblock package golang-github-klauspost-compress

The problem is with autopkgtest, on armel and armhf, the test
machines frequently run out of memory when executing the extensive
test suite.

I suggest the folling hints:

force-badtest golang-github-klauspost-compress/*/armhf
force-badtest golang-github-klauspost-compress/*/armel


(not sure what's the difference between /*/ and /all/ is).

Thanks for your help!

Bug#995275: mirror submission for mirrors.sonic.net

[Sonic System Operations]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.sonic.net
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 ppc64el s390x
Archive-http: /debian/
Maintainer: Sonic System Operations 
Country: US United States
Location: Santa Rosa, CA
Sponsor: Sonic. https://www.sonic.com




Trace Url: http://mirrors.sonic.net/debian/project/trace/
Trace Url: http://mirrors.sonic.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.sonic.net/debian/project/trace/mirrors.sonic.net

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Alexandre Viau]

Hello Nicholas, Hannah,

> Oh, and Alexandre was my first Debian contact.

Aww. This is giving me Debconf nostalgia <3.

> I'm CCing you to ask if you'd appreciate help packaging deps for
> Syncthing 1.18.2,

Help for packaging new dependencies of syncthing is always welcome!

I have the habit of keeping a TODO list in the changelog:
- 
https://salsa.debian.org/go-team/packages/syncthing/-/blob/b356f757a44765ff2bb1e2a53df6d64b08dbdd25/debian/changelog

I am not very territorial with my TODO list. Feel free to steal as
many tasks as you like. If it ever runs out, I am sure we can add even
more things to it ;).

At the time of writing this email, there are three things that need to be done:
- Bump the version of github.com/shirou/gopsutil/v3/disk in Debian
- Package github.com/AudriusButkevicius/recli
- Package github.com/flynn-archive/go-shlex

Cheers,

--
Alexandre Viau
av...@debian.org

On Sun, 26 Sept 2021 at 21:33, Nicholas D Steeves  wrote:
>
> Hi Hannah!
>
> Reply follows inline.
>
> Hi Alexandre!
>
> I'm CCing you to ask if you'd appreciate help packaging deps for
> Syncthing 1.18.2, because the working copy of Syncthing Tray that Hannah
> prepared has an embedded copy of this version's libsyncthing that should
> be unbundled.
>
> Hannah Rittich  writes:
>
> > Hey Nicholas,
> >
> > nice to hear that you are still interested.
> >
>
> Yes, definitely!  Long ago Alexandre Viau (Syncthing maintainer in
> Debian) convinced me of the usefulness of Syncthing, and a more friendly
> and convenient UI for our KDE Plasma users is *long overdue*.  Oh, and
> Alexandre was my first Debian contact.  By the way, is this your first
> Debian contribution?  If so, welcome! :-)
>
> > I have read this BTS entry, as well as the related GitHub issue [1].
> > Indeed, libc++utilities and libqtutilities are quite generic names. I
> > think, there are three ways to deal with this.
> >
> > 1.  Rename the libraries. Build a package for each one.
> > 2.  Build a syncthingtray package that includes the libraries and
> > installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use
> > of the multiple tarball support.
> > 3.  Acceptance. Keep the names as they are. Build a package for each
> > one.
> >
> > The three approaches have pros and cons.
> >
> > 1.  + More specific package name.
> > - More work: requires changing the build process and changes to
> >   upstream might be necessary.
> > - Increases long term maintenance cost, since higher complexity
> >   increases the chance of errors.
> > - Can break on updates, if upstream does not want to include the
> >   changes.
> >
> > 2.  + A hypothetical name collision is avoided.
> > o Probably less work than 1.
> > - Additional work: requires a more complicated build process.
> > - Increases long term maintenance cost, since higher complexity
> >   increases the chance of errors.
> > - Libraries cannot be used by other packages. (The author has other
> >   applications that might be of interest. They use the same
> >   libraries.)
> >
> > 3.  + Much simpler than 1. and 2.
> > + Debian package is very close to the upstream package.
> > + Low maintenance cost and more stable build process.
> > - A hypothetical name collision can occur.
> >
> > I, would suggest option 3. A name collision, at this point, is just
> > hypothetical, while the drawbacks of the other options are real.
> >
> > I have checked the package database and there is currently no name
> > collision with these package names, and the Debian Policy
> > Manual just requires a name to be unique in Debian [2], which they are.
> >
> > Furthermore, the chance of a name collision is rather small. Yes,
> > libc++utilities is a rather generic name. However, for the same reason
> > you are concerned about the name, most people will not consider to use
> > such a generic name for a project; it is actually a bold move to choose
> > such a name. In case a more important package needs this name, however,
> > the packages can still be renamed. Hence, I do not see a reason to
> > significantly increase the effort of packaging when there is no concrete
> > reason to do so at the moment. There is the saying "done is better than
> > perfect."
> >
> > If you insist, one could add a section to the README.Debian file that
> > the package will be renamed in case the name is needed by a more
> > important package.
> >
>
> So option #1 is patching the library, and not using a different package
> name at the dpkg level.  I wonder about namespacing the dependencies'
> names at the dpkg level, without patching the library?  Eg:
> src:marchus-cpp-utilities (which generates
> bin:marchus-libc++utilities5).  What do you think?  I think this would
> be less confusing to users/devs, and I feel like it's likely that there
> will be a cpp-utilities from glibc or LLVM somewhere in the future.
> What I mean by "confusing" is I really don't think that it's appropriate
> 

Bug#995267: devhelp doesn't load the selected content

[Jeremy Bicha]

Control: reassign -1 webkit2gtk 2.33.3-1
Control: affects devhelp

On Tue, Sep 28, 2021 at 2:09 PM crvi  wrote:
> Opening devhelp succeeds, but the content is not getting loaded in the right
> side pane.

Yes, I reported a similar issue on Ubuntu, but hadn't gotten around to
testing on Debian yet. Ubuntu's webkit2gtk packaging has diverged a
bit so I didn't know whether Debian was affected too. Let's reassign
to webkit2gtk.

https://launchpad.net/bugs/1942951

Thanks,
Jeremy Bicha

Bug#995274: needrestart: false positive: rabbitmq-server

[Antonio Terceiro]

Package: needrestart
Version: 3.5-4
Severity: normal

Dear Maintainer,

Recently every time I install something, needrestart seems to think that
rabbitmq-server needs to be restart, even when there were norelated
upgrades. I tried calling needrestart right after booting, and even then
it reported rabbitmq-server as needing a restart.

This can easily be reproduced in a clean testin VM:

8<8<8<-
root@host:~# apt update -q=2
20 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@host:~# apt install -q=2 -y needrestart
[...]
root@host:~# apt install -q=2 -y rabbitmq-server
[...]
Package configuration





┌┤ Daemons using outdated libraries ├─┐
│ │
│ │
│ Which services should be restarted? │
│ │
│[*] rabbitmq-server.service  │
│ │
│ │
│ │
│ │
└─┘






 systemctl restart rabbitmq-server.service

No containers need to be restarted.

No user sessions are running outdated binaries.
8<8<8<-

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

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

Versions of packages needrestart depends on:
ii  binutils   2.37-7
ii  dpkg   1.20.9
ii  gettext-base   0.21-4
ii  libintl-perl   1.26-3
ii  libmodule-find-perl0.15-1
ii  libmodule-scandeps-perl1.31-1
ii  libproc-processtable-perl  0.611-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1+b2
ii  perl   5.32.1-6
ii  xz-utils   5.2.5-2

Versions of packages needrestart recommends:
ii  libpam-systemd  247.9-1

Versions of packages needrestart suggests:
ii  iucode-tool2.3.1-1
ii  libnotify-bin  0.7.9-3

-- no debconf information


signature.asc
Description: PGP signature

Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Diederik de Haas]

Hi Andy,

On Wednesday, 29 September 2021 00:02:46 CEST Andy Smith wrote:
> On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote:
> The idea of the domid controlling/influencing order of shutdown

It was just an idea that popped in my head. All in all I've likely spend less 
then a minute thinking about the domid idea.
Don't spend more on it then you already have ;)

> > I really agree with the 'upstream' tag as not only should it be
> > fixed/adjusted there, but it also engages a (much) larger audience who
> > think of scenarios we likely didn't think about.
> 
> Should we move discussion to xen-us...@lists.xen.org then?

I can make a case for both xen-users and xen-devel.
xen-users:
It could be that a solution already exists. I know that in Qubes (which uses 
Xen) has some dependency mechanism in that if you start vmA which depends on 
vmB, then it first starts vmB and then vmA. I don't know if that is a Qubes 
'extension' or that they simply use available functionality of Xen.

xen-devel:
If needed functionality doesn't yet exist and needs to be built anew, then 
xen-devel is the right place to discuss that.

It could be that the best place to start is xen-users which then may/could 
'transition' to xen-devel.

Let's hear others first what they think is the best approach.

Cheers,
  Diederik

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

Bug#988597: trash-cli version too old

[Jonathan Dowland]

Hello,

On Sun, May 16, 2021 at 06:08:09PM +0200, Andrea Francia wrote:

I've seen in https://salsa.debian.org/debian/trash-cli that I can also send
a Merge Request, I could try do it by myself but I don't know yet how
importing from sources from upstream works and which check I've to do after
the source code modifications to check the packages.


I've begun work on updating to 0.21.7.24. I've pushed my in-progress
work here:


The issue that I need to fix is that tests/test_bump.py fails because
the 'script' directory is not present in PYTHONPATH when the test is
invoked under the chroot environment that Debian packages are built
with.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Hello!

On 9/29/21 00:38, John Paul Adrian Glaubitz wrote:
> There is actually a baseline violation on i386 as "-march=amdfam10" is
> passed to the compiler, see the build log in [1], for example.

Comparing the build logs, it seems that this an issue with the newer version
of autoconf that was used to build version 3.4.2-2. Looking at the log for
3.4.2-2, a lot of autoconf warnings can be seen which are not present in the
log for 3.4.1-1.

> https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-1=1626443428=0
> https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-2=1632868252=0

So, upstream needs to fix compatibility issues with the newer autoconf version.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Hi!

On 9/28/21 22:40, John Paul Adrian Glaubitz wrote:
> We should therefore pass "--enable-portable-binary" in debian/rules.

There is actually a baseline violation on i386 as "-march=amdfam10" is
passed to the compiler, see the build log in [1], for example.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libffi=i386=3.4.2-2=1632469242=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995273: RM: antlr3.2 -- RoQA; newer version in the archive

[Bastian Germann]

Source: antlr3.2
Severity: normal

With its last reverse dependency jython having switched to antlr3, keeping antlr3.2 is no longer 
necessary and it should be removed from the archive. Please reassign this issue to ftp.debian.org if 
you agree.

Bug#957954: wmwave: diff for NMU version 0.4-11.1

[Francisco Vilmar Cardoso Ruviaro]

Control: tags 957954 + patch
Control: tags 957954 + pending


Dear maintainer,

I've prepared an NMU for wmwave (versioned as 0.4-11.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards.

diff -Nru wmwave-0.4/debian/changelog wmwave-0.4/debian/changelog
--- wmwave-0.4/debian/changelog 2019-10-25 21:59:08.0 +
+++ wmwave-0.4/debian/changelog 2021-02-12 22:18:49.0 +
@@ -1,3 +1,11 @@
+wmwave (0.4-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/Fix-compilation-with-gcc-10.patch.
+Thanks to Logan Rosen . (Closes: #957954)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Fri, 12 
Feb 2021 22:18:49 +
+
 wmwave (0.4-11) unstable; urgency=medium
 
   [ Guido Günther ]
diff -Nru wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch 
wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch
--- wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch 1970-01-01 
00:00:00.0 +
+++ wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch 2021-02-12 
22:18:49.0 +
@@ -0,0 +1,29 @@
+Description: Fix compilation with GCC 10.
+Author: Logan Rosen 
+Bug-Debian: https://bugs.debian.org/957954
+Forwarded: no
+Reviewed-By: Francisco Vilmar Cardoso Ruviaro 
+Last-Update: 2021-02-12
+
+--- a/wmgeneral.h
 b/wmgeneral.h
+@@ -36,7 +36,7 @@
+  /* Global variable */
+ /***/
+ 
+-Display   *display;
++extern Display*display;
+ 
+   /***/
+  /* Function Prototypes */
+--- a/wmwave.c
 b/wmwave.c
+@@ -79,6 +79,8 @@
+ 
+ int mode = 0;// default: no card detected
+ 
++Display *display;
++
+ void usage(void);
+ void printversion(void);
+ void BlitString(char *name, int x, int y);
diff -Nru wmwave-0.4/debian/patches/series wmwave-0.4/debian/patches/series
--- wmwave-0.4/debian/patches/series2019-10-25 21:28:57.0 +
+++ wmwave-0.4/debian/patches/series2021-02-12 22:18:49.0 +
@@ -1,2 +1,3 @@
 Debian-delta.patch
 Move-libraries-to-the-end.patch
+Fix-compilation-with-gcc-10.patch

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
diff -Nru wmwave-0.4/debian/changelog wmwave-0.4/debian/changelog
--- wmwave-0.4/debian/changelog 2019-10-25 21:59:08.0 +
+++ wmwave-0.4/debian/changelog 2021-02-12 22:18:49.0 +
@@ -1,3 +1,11 @@
+wmwave (0.4-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/Fix-compilation-with-gcc-10.patch.
+Thanks to Logan Rosen . (Closes: #957954)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Fri, 12 
Feb 2021 22:18:49 +
+
 wmwave (0.4-11) unstable; urgency=medium
 
   [ Guido Günther ]
diff -Nru wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch 
wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch
--- wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch 1970-01-01 
00:00:00.0 +
+++ wmwave-0.4/debian/patches/Fix-compilation-with-gcc-10.patch 2021-02-12 
22:18:49.0 +
@@ -0,0 +1,29 @@
+Description: Fix compilation with GCC 10.
+Author: Logan Rosen 
+Bug-Debian: https://bugs.debian.org/957954
+Forwarded: no
+Reviewed-By: Francisco Vilmar Cardoso Ruviaro 
+Last-Update: 2021-02-12
+
+--- a/wmgeneral.h
 b/wmgeneral.h
+@@ -36,7 +36,7 @@
+  /* Global variable */
+ /***/
+ 
+-Display   *display;
++extern Display*display;
+ 
+   /***/
+  /* Function Prototypes */
+--- a/wmwave.c
 b/wmwave.c
+@@ -79,6 +79,8 @@
+ 
+ int mode = 0;// default: no card detected
+ 
++Display *display;
++
+ void usage(void);
+ void printversion(void);
+ void BlitString(char *name, int x, int y);
diff -Nru wmwave-0.4/debian/patches/series wmwave-0.4/debian/patches/series
--- wmwave-0.4/debian/patches/series2019-10-25 21:28:57.0 +
+++ wmwave-0.4/debian/patches/series2021-02-12 22:18:49.0 +
@@ -1,2 +1,3 @@
 Debian-delta.patch
 Move-libraries-to-the-end.patch
+Fix-compilation-with-gcc-10.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#957923: webalizer: diff for NMU version 2.23.08-3.2

[Francisco Vilmar Cardoso Ruviaro]

Control: tags 957923 + patch
Control: tags 957923 + pending


Dear maintainer,

I've prepared an NMU for webalizer (versioned as 2.23.08-3.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards.

diff -Nru webalizer-2.23.08/debian/changelog webalizer-2.23.08/debian/changelog
--- webalizer-2.23.08/debian/changelog  2018-10-15 15:03:02.0 +
+++ webalizer-2.23.08/debian/changelog  2021-02-12 21:04:51.0 +
@@ -1,3 +1,11 @@
+webalizer (2.23.08-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/27_fix_compilation_with_gcc-10.diff.
+Thanks to Logan Rosen . (Closes: #957923)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Fri, 12 
Feb 2021 21:04:51 +
+
 webalizer (2.23.08-3.1) unstable; urgency=medium
 
   * Non-maintainer upload with maintainer consent.
diff -Nru webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff 
webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff
--- webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff
1970-01-01 00:00:00.0 +
+++ webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff
2021-02-12 20:58:29.0 +
@@ -0,0 +1,25 @@
+Description: Fix compilation with GCC 10.
+Author: Logan Rosen 
+Bug-Debian: https://bugs.debian.org/957923
+Forwarded: no
+Reviewed-By: Francisco Vilmar Cardoso Ruviaro 
+Last-Update: 2021-02-12
+
+--- a/dns_resolv.c
 b/dns_resolv.c
+@@ -78,11 +78,11 @@
+ 
+ struct   dns_child child[MAXCHILD];/* DNS child pipe data  */
+ 
+-DNODEPTR host_table[MAXHASH];  /* hostname/ip hash table   */
++extern DNODEPTR host_table[MAXHASH];   /* hostname/ip hash table   */
+ 
+-char buffer[BUFSIZE];  /* log file record buffer   */
+-char tmp_buf[BUFSIZE]; /* used to temp save above  */
+-struct   utsname system_info;  /* system info structure*/
++extern char buffer[BUFSIZE];   /* log file record buffer   */
++extern char tmp_buf[BUFSIZE];  /* used to temp save above  */
++extern struct   utsname system_info;   /* system info structure*/
+ 
+ int  raiseSigChild = 1;
+ 
diff -Nru webalizer-2.23.08/debian/patches/series 
webalizer-2.23.08/debian/patches/series
--- webalizer-2.23.08/debian/patches/series 2018-10-15 15:03:02.0 
+
+++ webalizer-2.23.08/debian/patches/series 2021-02-12 21:01:24.0 
+
@@ -15,3 +15,4 @@
 24_gettext_generated.diff
 25_add_convertlang2po.diff
 26_gettext_po_files.diff
+27_fix_compilation_with_gcc-10.diff

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
diff -Nru webalizer-2.23.08/debian/changelog webalizer-2.23.08/debian/changelog
--- webalizer-2.23.08/debian/changelog  2018-10-15 15:03:02.0 +
+++ webalizer-2.23.08/debian/changelog  2021-02-12 21:04:51.0 +
@@ -1,3 +1,11 @@
+webalizer (2.23.08-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/27_fix_compilation_with_gcc-10.diff.
+Thanks to Logan Rosen . (Closes: #957923)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Fri, 12 
Feb 2021 21:04:51 +
+
 webalizer (2.23.08-3.1) unstable; urgency=medium
 
   * Non-maintainer upload with maintainer consent.
diff -Nru webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff 
webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff
--- webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff
1970-01-01 00:00:00.0 +
+++ webalizer-2.23.08/debian/patches/27_fix_compilation_with_gcc-10.diff
2021-02-12 20:58:29.0 +
@@ -0,0 +1,25 @@
+Description: Fix compilation with GCC 10.
+Author: Logan Rosen 
+Bug-Debian: https://bugs.debian.org/957923
+Forwarded: no
+Reviewed-By: Francisco Vilmar Cardoso Ruviaro 
+Last-Update: 2021-02-12
+
+--- a/dns_resolv.c
 b/dns_resolv.c
+@@ -78,11 +78,11 @@
+ 
+ struct   dns_child child[MAXCHILD];/* DNS child pipe data  */
+ 
+-DNODEPTR host_table[MAXHASH];  /* hostname/ip hash table   */
++extern DNODEPTR host_table[MAXHASH];   /* hostname/ip hash table   */
+ 
+-char buffer[BUFSIZE];  /* log file record buffer   */
+-char tmp_buf[BUFSIZE]; /* used to temp save above  */
+-struct   utsname system_info;  /* system info structure*/
++extern char buffer[BUFSIZE];   /* log file record buffer   */
++extern char tmp_buf[BUFSIZE];  /* used to temp save above  */
++extern struct   utsname system_info;   /* system info structure*/
+ 
+ int  raiseSigChild = 1;
+ 
diff -Nru webalizer-2.23.08/debian/patches/series 
webalizer-2.23.08/debian/patches/series
--- webalizer-2.23.08/debian/patches/series 2018-10-15 

Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Andy Smith]

Hi Diederik,

On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote:
> On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote:
> > We agree about reverse order, I think we only disagree about when to
> > shut down domains that don't have a preference set. 
> 
> Indeed.

Okay, well I am satisfied by the lesser idea of having to specify
order of all domains but if the implementer of the solution isn't
and decides to implement it so not-specified domains shut down first
then that works for me too so have no objection to it.

The idea of the domid controlling/influencing order of shutdown
would not work for me as to me that is not much different to how we
have things now - domains shut down in increasing order of domid. I
can't control it so I just would continue using my own shutdown
script.

> I really agree with the 'upstream' tag as not only should it be 
> fixed/adjusted 
> there, but it also engages a (much) larger audience who think of scenarios we 
> likely didn't think about.

Should we move discussion to xen-us...@lists.xen.org then?

Cheers,
Andy

Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes

[Lyndon Brown]

With bullseye now released, can we please now progress with the
necessary transition to upgrade and thus address the security issue?

Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Diederik de Haas]

Hi Andy,

On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote:
> > If that's correct, then I find it more logical to do *everything* in
> > reverse. The VM that was started first, should be saved/shutdown last and
> > IIUC your proposal would not do that.
> 
> No, that's what I am suggesting too: again walk the "auto" directory
> but in reverse order.

I understood that. My point was about the sequence of auto vs non-auto
 
> > Once all the "remaining" ones have been saved/shutdown, THEN do
> > the auto ones in reverse order.
> 
> A problem here would be excluding the domains that have a specified
> order from the initial round of shutdowns

That may involve some scripting/programming, but *I* don't consider that a 
valid argument to not do it... 

> which is why I suggested doing it in reverse order by the "auto" directory
> and THEN shutting down anything that's left as normal, since that way you
> don't need to check anything.

... and I think that's wrong.
The use case I'm imagining is some domains are important or even essential for 
the working of other domains and that's why you want/need to start them as 
soon as possible with (potentially) a dependence between them, therefor you 
specify the correct order in the auto directory.

Let's say you have a special storage domain which provides storage for all the 
domU domains. Without that domain running you CANNOT start any other domain, 
so you start that domain first in the auto directory.
If you start the shutdown/save-all-domains procedure the storage domain MUST 
be the last one to be shutdown, because otherwise you'd pulling the storage 
under live domains, which likely will make them crash. In any case, they will 
not be able to shutdown cleanly or save their current state to disk ... 
because the disks are gone.

> As you've pointed out, this does mean that if you had linked say
> /etc/xen/auto/010-important.cfg with the intention that it be
> started first and shut down last, you would have to also link in
> every other domain in its correct order otherwise the not-mentioned
> ones would be shut down after 010-important.

Indeed. I hope that I explained sufficiently why that is wrong or can even be 
catastrophic AFAICT.
 
> However, I feel like people who use the /etc/xen/auto directory do
> already link all or the majority of their domains in there

I think that that is a (too) dangerous assumption.
You could use (say) 3 domains which provide essential services to all other 
domains, but after that every user is free to do whatever (s)he wants.

> - I  certainly do. I don't find it onerous to say that if you want to
> specify shutdown order then you must link all of the domains in
> /etc/xen/auto not just some of them.

That would make the scenario I described above unworkable or needlessly 
complex, so I don't think that's a good/valid solution.
 
> > Could the domain ID be used for that?
> 
> I don't like it because it only says how recent a domain was
> started relative to others, not any intention about start/stop
> order. Shut one down manually (or crash) and start it again and it
> gets a new domid higher than all existing.

It is a (really) simple heuristic and likely too simple.
But at first glance it seemed (to me) to actually do the right thing.
 
> We agree about reverse order, I think we only disagree about when to
> shut down domains that don't have a preference set. 

Indeed.

> I am all for keeping it simple by saying ordering must be set for all
> domains otherwise ordering for remaining ones is not defined.

I like simple too, but I think this actually makes it complex.

I really agree with the 'upstream' tag as not only should it be fixed/adjusted 
there, but it also engages a (much) larger audience who think of scenarios we 
likely didn't think about.
And they're certainly much more knowledgeable then I am.

Cheers,
  Diederik

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

Bug#995272: libsql-abstract-pg-perl: trying to overwrite '/usr/share/man/man3/SQL::Abstract::Pg.3pm.gz', which is also in package libmojo-pg-perl 4.24-1

[Axel Beckert]

Package: libsql-abstract-pg-perl,libmojo-pg-perl
Severity: serious
Version: libsql-abstract-pg-perl/1.0-1
Version: libmojo-pg-perl/4.24-1

Trying to install libsql-abstract-pg-perl when libmojo-pg-perl is
already installed results in a file conflict as follows:

Preparing to unpack .../libsql-abstract-pg-perl_1.0-1_all.deb ...
Unpacking libsql-abstract-pg-perl (1.0-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libsql-abstract-pg-perl_1.0-1_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/SQL::Abstract::Pg.3pm.gz', which is 
also in package libmojo-pg-perl 4.24-1
Errors were encountered while processing:
 /var/cache/apt/archives/libsql-abstract-pg-perl_1.0-1_all.deb

I'm not sure if it is intentional that both packages ship the same
file(s) and how they relate to each other (as libsql-abstract-pg-perl
mentions libmojo-pg-perl in its package description), so I'm not sure
what's the right way to solve this.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#578764: Wir steigen um!

[Sparkasse Sicherheitshinweis]

Content-type: text/html;charset=utf-8

Content-Transfer-Encoding: base64



PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs

Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9

ImRlIj4KPGhlYWQ+IDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4

dC9odG1sOyBjaGFyc2V0PVVURi04Ij4gPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9Indp

ZHRoPWRldmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0xIj4gPG1ldGEgaHR0cC1lcXVpdj0iWC1V

QS1Db21wYXRpYmxlIiBjb250ZW50PSJJRT1lZGdlIj4gPHRpdGxlPldpY2h0aWdlIE1pdHRlaWx1

bmc8L3RpdGxlPiA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPiBib2R5IHtmb250LWZhbWlseTogYXJp

YWwsICJoZWx2ZXRpY2EgbmV1ZSIsIGhlbHZldGljYSwgc2Fucy1zZXJpZjt9IC54aWtobEJ3IHNl

Y3Rpb24geyB0ZXh0LWFsaWduOmNlbnRlcjsgbWF4LXdpZHRoOjE0MzBweDt9IC54aWtobEJ3IHtj

b2xvcjojZmQyNDAwOyBwYWRkaW5nOjVweDt9IC54aWtobEJ3IGgxIHtmb250LXNpemU6MzJweDt9

IC56V2NZcnZkIHtjb2xvcjojNjY2OyBwYWRkaW5nOjVweDsgbWF4LXdpZHRoOjE0MzBweDt9IC5M

Y0FlVGJ1IHttYXJnaW46MDsgcGFkZGluZzowOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDEsIDEs

IDE5MiwgMC4wMyk7fSAuQ1pEblZ3bCB7IG1pbi1oZWlnaHQ6MjU4cHg7YmFja2dyb3VuZC1jb2xv

cjojRkZGOyBwYWRkaW5nLXRvcDoxMHB4O30gLkNaRG5Wd2wgcCB7Y29sb3I6IzY2NjsgcGFkZGlu

ZzoxNXB4OyBmb250LXNpemU6MTRweDt9IC5DWkRuVndsIGgzIHtmb250LXNpemU6MTZweDt9IC55

RFFPSWxVIHtjb2xvcjojZmQyNDAwOyBtYXJnaW4tbGVmdDogMTVweDt9IC5lbWt3emFMIHtmb250

LXdlaWdodDpib2xkOyBiYWNrZ3JvdW5kLWNvbG9yOiNmZDI0MTY7IGNvbG9yOiNGRkY7IHdpZHRo

OjI2OHB4O2hlaWdodDo2MHB4OyBwYWRkaW5nLWxlZnQ6MjlweDsgcGFkZGluZy1yaWdodDoyOXB4

O3BhZGRpbmctdG9wOjEycHg7cGFkZGluZy1ib3R0b206MTJweDsgYm9yZGVyLXJhZGl1czo3cHg7

fSAuQXBIckN5SyB7IG1hcmdpbjogYXV0bzsgd2lkdGg6IDUxJTsgcGFkZGluZzogMTBweDsgdGV4

dC1hbGlnbjpsZWZ0Owp9IC55T2hvbXhYIHtmb250LXdlaWdodDo2MDA7IGZvbnQtc2l6ZTogMTdw

eDsgfSAuSVFBQkhBaCB7IGJvcmRlcjogMDsgaGVpZ2h0OiAwOyBib3JkZXItdG9wOiAxcHggc29s

aWQgcmdiYSgwLCAwLCAwLCAwLjEpOyBib3JkZXItYm90dG9tOiAxcHggc29saWQgcmdiYSgyNTUs

IDI1NSwgMjU1LCAwLjMpO30gLnd6Z3R5YlQgcCB7IGNvbG9yOiAjYWVhZWFlIWltcG9ydGFudDsg

Zm9udC1zaXplOiAxMHB4IWltcG9ydGFudDt9IC5lSHZsakdJIHttYXJnaW4tbGVmdDo2cHg7IHdp

ZHRoOjIxcHg7IHZlcnRpY2FsLWFsaWduOiAtNnB4Owp9IDwvc3R5bGU+IDwvaGVhZD4KPGJvZHkg

Y2xhc3M9IkxjQWVUYnUgSUVSSXhFZjpKdHp6RE11IGlMYXJVZUE6VFFtYnBOWCB2TUluTHVjOmFY

dmdsSEwgQ21mdWdxTzpETlVLVFhiIFFyak1Hdkg6ZVhUSlV5bSBBQldjb2l5Om5sSm1jRWkiPiA8

dGFibGUgaWQ9ImZ3a01EaWUiIGNsYXNzPSJMbFFta3hEOnJKaUxldlkgVEdQSGJPYTpsVVZuWk1h

IFpnUUVGd1k6enBWbVdrZSBVSENlSHZvOkFVTG1IUlkgWlpueU1TYTpDaWFRWWhzIEZ4c0RCTEk6

Unh3ZXhSZSBHYm1pYkhhOnFCUVRyY1ogZHBuTVBldjpLY2puY3VEICIgd2lkdGg9IjEwMCUiIGNl

bGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiIGJnY29sb3I9IiNmZDI0MTYiPiA8dHIgY2xhc3M9IkVr

R1laQlo6RFljbWh2ZyBqaGpxdHVEOmZyWWd0S3ggcnRsSHhLRjpVdXRsbHpNIEVRUEVhTWg6dW9H

RFVyeiBldE1ZdUdVOnF6TGFobWEgS1dyYUtSWTplR0NFRGZJIHVib3pVeVU6UnZNT3lkaCAiPiA8

dGQgY2xhc3M9Ik90S0pQaGo6QlVZWm52diBEaU5mVUFKOlFLdHhVdmkgZmRieHprVTp0c0FlYVB1

IE1JWXBVZ2M6UmlQUWxtSCByaXhRa2xqOndiVFBwdXAgQVpuRFdTaTpXb1ZjdlJxIEtRUFJsWHQ6

Z2hGT1VGciIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZvbnQtc2l6ZToxMHB4OyBsaW5lLWhlaWdodDox

MHB4OyI+Jm5ic3A7PC90ZD4gPC90cj4gPHRyPiA8dGQgYWxpZ249ImxlZnQiIHZhbGlnbj0idG9w

IiBjbGFzcz0iYWR1YWxIcTpmeVBQbGlwIj4gPHRhYmxlIGlkPSJ5amV6bHpVIiB3aWR0aD0iMTAw

JSIgY2xhc3M9IkFwSHJDeUsiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiPiA8dHIgY2xhc3M9

InNhTVVtWlM6R1J5alFXTCBvS2lJWXpSOmZSWGRmd2wgc25FT0Fncjphcm9PSVZVIGdOR3JCYno6

R2lFcGtaTSB4VmVKQ2hlOk5pd2l3VE8gemlvd1ZZdzpIWHZFTUpDIE1xZUFDQUU6akxXa0NhWCAi

PiA8dGQgYWxpZ249ImxlZnQiIHZhbGlnbj0idG9wIiBjbGFzcz0iWERmY1JzQzpsYWZUeUtFIFhI

blBJRVA6UnJYbkdHRiBxRkJDa2dSOkxCS0JoUlkgTFBDTUdrTDp1dWt2c3NlIj4gPC90ZD4gPC90

cj4gPC90YWJsZT4gPC90ZD4gPC90cj4gPHRyIGNsYXNzPSJnZFBOZGFtOkxDWk5lT3EgVmZWZWpY

ZzpTU1NNUlFCIHRHZUxQV0k6S2l5dVNEVSBWa2NBdlZuOkZaRGlMeUMgSXBJcHVwcTpkaEdaQWJT

Ij4gPHRkIGhlaWdodD0iMTEiIGNsYXNzPSJwRWVuWWpMOm9TQkZ2VkUgWUlZWWtGTjpSRkh1VWZk

IFhmRG5VbHI6dHJjWnpkWSIgc3R5bGU9ImZvbnQtc2l6ZTo1MXB4OyBsaW5lLWhlaWdodDoxMHB4

OyI+Jm5ic3A7PC90ZD4gPC90cj4gPC90YWJsZT4gPGRpdiBpZD0ibll5TllPRiIgY2xhc3M9IkFw

SHJDeUsgU251dU5kQjpUVFBjbFZNIj48ZGl2IGNsYXNzPSJ4aWtobEJ3IFNxVXpTdkU6YXpVSE9O

SSI+IDxoMSBjbGFzcz0iVUd4Z2xJbDp5R3FUalhPIHpxUldEc0c6U3JwYldUdiBDQnhXZFNNOml0

d01yUVAgSU9peHV5dDpXRGtiaXh4IEpXWUJJVHk6SXFuaEZvRCBRcEhxaFFuOmxrcExDYmwgT0tr

V0doRDpDU290VlNsICI+PHNwYW4+WmVpdG5haGUgw4RuZGVydW5nIHVuc2VyZXIgU2ljaGVyaGVp

dHN2ZXJmYWhyZW48L3NwYW4+PC9oMT4gPC9kaXY+IDxkaXYgaWQ9IlR2Z1BXSWoiIHN0eWxlPSJk

aXNwbGF5Om5vbmU7IiBjbGFzcz0idWdnWWdJRDpPWXptakJCIERYZlBxSlE6RWRzWEVjUSBYSldR

a2pzOmd5YW1jckciPiA8ZGl2IGlkPSJKd3NwU0R6IiBjbGFzcz0iV0hlSHhaeTpiU3NsckNyIEZ3

WWhnb0w6bXVIZ0JQVyBienBKYVBrOkZWeVdhT0oiPiA8ZGl2IGlkPSJNanRPeVZTIiBjbGFzcz0i

eldjWXJ2ZCBnU1hSa3RhOm1aRFpDS3MgZmhlS3NiWDpIdmZMbGpIIGpjWkxLakY6Wlp2WkJnbiI+

IDxwPjxzcGFuIGNsYXNzPSJ5T2hvbXhYIFZmS1ZBSEM6b1d0UGZzaCBQTER2T2V6Old2enRvQ2kg

RlFrWUFIWDpmY2RydVlqIj5XaWNodGlnZSBNaXR0ZWlsdW5nPC9zcGFuPjxicj48L3A+IDwvZGl2

PiA8L2Rpdj4gPC9kaXY+IDwvZGl2PiA8ZGl2IGlkPSJ3eEFCZmtBIiBjbGFzcz0iQ1pEblZ3bCBB

cEhyQ3lLIExrdnFNaG06VVRmdlJhUSBvYml1R2FXOkZNSkF0ZWUiID4gPGgzPiA8ZGl2IGlkPSJG

WWdGZWF1IiBjbGFzcz0ieURRT0lsVSBPaUlkakpVOk1Cck14UHQgdU5tVHBjSjpmdmxMak1NIj5T

Bug#994971: OpenCL not working with latest Nvidia driver

[Sebastian Ramacher]

On 2021-09-26 18:58:48 +0200, Andreas Beckmann wrote:
> Control: severity -1 serious
> 
> On 26/09/2021 18.07, Klaus Ethgen wrote:
> > > available somewhere in /var/log/apt/term.log*, it might give some hints 
> > > what
> > > happened.
> > 
> > Here it is.
> 
> Thanks. You had modifications in nvidia-modprobe.conf, didn't try that
> before. And dpkg messed it up. I could reproduce the disappearance of the
> file. Will try to reproduce with a conffile outside nvidia stuff...

This smells like #994919 in debhelper, i.e, nvidia-driver needs to be
rebuilt with a fixed debhelper version.

Cheers

> 
> > By the way, make it sense to include all involved persons in reply?
> > Doesn't the bugtracker send notification too?
> 
> Only the maintainer gets notifications by default, everyone else has to
> subscribe manually. So let's keep the Cc:s.
> 
> Andreas
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#991919: Bioconductor API Bump to 3.13

[Sebastian Ramacher]

On 2021-09-28 07:09:11 +0200, Andreas Tille wrote:
> On Tue, Sep 28, 2021 at 12:07:49AM +0200, Sebastian Ramacher wrote:
> > > > I think we should now focus on autopkgtests of the r-bioc-* packages
> > > > since some test were depending from packages in a higher transition
> > > > level.
> > 
> > I've made a pass an filed bugs. A bunch of packages also seem to be
> > blocked by hdf5 which causes autopkgtest regressions in pytables and
> > r-bioc-rhdf5, r-bioc-rhdf5lib.

hdf5 migrated. Since all of the r-bioc-* packages have to migrate
together, it would help if the set of of affected packages could settle
down for a bit. That would allows us to track down the remaining
blockers.

Cheers

> 
> Thanks a lot
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#981699: fixed in thinkfan 1.2.1-3.1

[Thorsten Glaser]

Debian FTP Masters dixit:

>   * Don't ship an example config in /etc/thinkfan.yaml (Closes: #983727)
>   * Ship example config in /usr/share/doc/thinkfan/examples/

I don’t think these resolve my issue with the newer thinkfan releases.

I’ve looked at the example configuration, and it refers to multiple
hwmon and other files, which caused problems with my laptop. With the
older thinkfan release, my configuration literally consisted of only
the temperatures, nothing else, and it worked (Thinkpad X61), and the
new configuration file doesn’t have a “user’s PoV” documentation for
how to achieve an at-all working configuration.

bye,
//mirabilos
-- 
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against
 ╳  HTML eMail! Also,
╱ ╲ header encryption!

Bug#868580: closed by Simon McVittie (Re: Bug#868580: cairo: CVE-2017-9814)

[Simon McVittie]

On Tue, 28 Sep 2021 at 22:07:26 +0200, Salvatore Bonaccorso wrote:
> > This appears to have been fixed in 1.15.14, which means it's fixed in
> > buster and bullseye.
> 
> I cannot check right now, but is this correct? The upstream issue
> https://gitlab.freedesktop.org/cairo/cairo/-/issues/264 seems to have
> been closed only very recently a few weeks ago, or where those only
> additional followups?

Those were additional followups, as far as I can tell. If they fixed
additional security issues in the same pattern, then those additional
security issues would need a separate CVE.

smcv

Bug#995239: pam: please use debian/patches/ for patch series

[Simon McVittie]

On Tue, 28 Sep 2021 at 14:35:19 -0600, Sam Hartman wrote:
> That said, while working on the package, I did notice that dh-quilt had
> a couple of advantages over gbp pq that I'm failing to remember now.

If the advantages you're thinking of are workflow advantages of quilt
over gbp pq for how you manage the patches, then there's nothing to stop
you from continuing to manage patches with quilt, and still receiving
contributions from people who used gbp pq - they're interoperable,
as long as you configure quilt to work with debian/patches/.

If they're advantages of dh-quilt over 3.0 (quilt) while actually
building the package, then you'll have to make a decision about whether
those advantages are more important than the advantages of using a more
common package setup, because applying your patches via the 3.0 (quilt)
patch system is not compatible with applying your patches via the dh-quilt
debhelper addon: that's an either/or decision.

smcv

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Control: severity -1 serious

Hello!

It turns out that m4/ax_gcc_archflag.m4 contains code to detect the
baseline of the host system and sets the GCC architecture accordingly.

Thus, a libffi compiled on a POWER8 machine will not work on a POWER5
machine as the compiler is emitting POWER8 instructions in this case.

Since the m4 script contains such a host enviroment detection for aarch64
as well [1], this bug can potentially affect arm64 which is a release
architecture.

We should therefore pass "--enable-portable-binary" in debian/rules.

Adrian

> [1] https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L209

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995239: pam: please use debian/patches/ for patch series

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> It would be great if the pam source package used
Simon> debian/patches/ instead of debian/patches-applied/ for the
Simon> patch series. That would make configuration transferrable
Simon> between pam and other source packages, and would enable use
Simon> of more powerful tools like git-buildpackage's gbp-pq.

Steve, I'd like to make this change.
What are your thoughts?

The patches-applied directory is an artifact of when I maintained PAM in
CVS, and at that time pam was stored in a patches-applied format, but I
kept a copy of the patches to make my life easier when I  updated to new
upstreams.

When Steve migrated to bzr he moved to patches unapplied but kept the
directory prefix.

That said, while working on the package, I did notice that dh-quilt had
a couple of advantages over gbp pq that I'm failing to remember now.
Overall I prefer debian/patches, but want to check with Steve.

Bug#877297: [Debian-lego-team] Bug#877297: libnxt: usb:v03EBp* too inclusive, leads to false positive matches

[Nicolas Schodet]

* Petter Reinholdtsen [2021-09-27 10:09]:
> I had a look in /var/lib/usbutils/usb.ids to figure out what the ID is
> registered for.  As far as I can tell it is not connected to any 
> USB device in the USB ID database.  Perhaps it is a good idea to get
> both IDs registered there?  The ID in question is supposed to be the NXT
> in 'flash mode'.  Not quite sure when that happen and if it is supposed
> to have a unique ID in that mode.

Actually, the NXT in flash mode is using the Atmel ROM bootloader which
uses 0x03eb:0x6124. Every devices using the SAM-BA bootloader on Atmel
AT91SAM chips will use this identifiers.

Nicolas.

Bug#995270: fwupdmgr: WARNING: Firmware can not be updated in legacy BIOS mode

[Thorsten Glaser]

Package: fwupd
Version: 1.5.7-4
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

tglase@tglase-nb:~ $ sudo fwupdmgr get-devices
WARNING: Firmware can not be updated in legacy BIOS mode
  See https://github.com/fwupd/fwupd/wiki/PluginFlag:legacy-bios for more 
information.
[…]

I’ve followed the instructions on the listed page and added uefi
to the list of disabled plugins, but the message still is shown.

This laptop doesn’t have EFI.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages fwupd depends on:
ii  libc6  2.31-13
ii  libcurl3-gnutls7.74.0-1.3+b1
ii  libefiboot137-6
ii  libelf10.183-3
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-4
ii  libfwupdplugin11.5.7-4
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-5
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-31
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
pn  bolt   
ii  dbus   1.12.20-2
pn  fwupd-signed   
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- Configuration Files:
/etc/fwupd/daemon.conf changed:
[fwupd]
DisabledDevices=
DisabledPlugins=test;test_ble;invalid;uefi
ArchiveSizeMax=0
IdleTimeout=7200
VerboseDomains=
UpdateMotd=true
EnumerateAllDevices=false
ApprovedFirmware=
BlockedFirmware=
UriSchemes=


-- no debconf information

Bug#995261: marked as pending in lintian

[Axel Beckert]

Hi Felix,

Felix Lechner wrote:
> Bug #995261 in lintian reported by you has been fixed in the
> Git repository and is awaiting an upload.

Thanks for the prompt fix!

> https://salsa.debian.org/lintian/lintian/-/commit/ff849348dd061101bdf482057a44d06c5478d409

Elegant! Especially more elegant than my again nested solution. :-)

> Do not expect files in sudoers.d to have standard file permissions. (Closes: 
> #995261)
> 
> The bug was probably introduced when the 'files' check was broken up. Over
> several days, the nesting depth of conditionals was reduced (as well as their
> absolute number) to make the code easier to read.

And thanks for your always well written and detailed commit messages!
Always a pleasure to read!

> Perhaps it at least helped the reporting party to locate the bug
> quickly.

Yep, probably. I at least found the right spot rather quickly. And
this wasn't always the case in the past with Lintian. :-)

> Thanks to Axel Beckert for the detailed and helpful bug report, and also for
> the patch!

You're welcome!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#994218: RFS: r-cran-partitions (NEW)

[Torrance, Douglas]

Control: tags -1 pending

I've just finished packaging r-cran-partitions (ITP #994218), which would be
headed for the NEW queue and so needs a binary upload.  Since I'm only a DM,
would anyone be able to review/sponsor?

https://salsa.debian.org/r-pkg-team/r-cran-partitions

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#995195: debugedit segfaults while changing binutils' build-id

[Helmut Grohne]

Control: tags -1 - fixed-upstream patch
Control: notforwarded -1

On Mon, Sep 27, 2021 at 10:32:25PM +0200, Helmut Grohne wrote:
> Adrian Bunk found the relevant commit fixing the issue in that separate
> upstream.

Alexey Brodkin checked that said fix is already present in unstable and
that the new upstream also segfaults on my sample.

We're back to square one. Worse, debugedit was rejected from NEW.

Helmut

Bug#868580: closed by Simon McVittie (Re: Bug#868580: cairo: CVE-2017-9814)

[Salvatore Bonaccorso]

Hi Simon,

> Version: 1.16.0-1
> 
> On Sun, 16 Jul 2017 at 22:52:11 +0200, Salvatore Bonaccorso wrote:
> > CVE-2017-9814[0]:
> > | cairo-truetype-subset.c in cairo 1.15.6 and earlier allows remote
> > | attackers to cause a denial of service (out-of-bounds read) because of
> > | mishandling of an unexpected malloc(0) call.
> 
> This appears to have been fixed in 1.15.14, which means it's fixed in
> buster and bullseye.

I cannot check right now, but is this correct? The upstream issue
https://gitlab.freedesktop.org/cairo/cairo/-/issues/264 seems to have
been closed only very recently a few weeks ago, or where those only
additional followups?

Regards,
Salvatore

Bug#995269: glibc-source: Please enable MTE (heap) checking on arm64

[Wookey]

Package: glibc-source
Severity: wishlist
Tags: patch

glibc 2.33 onwards has support for 'Memory Tagging Extension' on
arm64. Could you please enable this feature (by setting
--enable-memory-tagging in the config).

The effect is to add colouring bits into heap pointers so that typical
illegal accesses (either temporally or spatially) can be detected and
faulted. Glibc just has the userspace heap tagging - there is also
corresponding kernel support.

The functionality operates on arm ISA 8.5 or later, which has extra
instructions to manipulate the tag bits in pointers.

The details are explained in
https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Arm_Memory_Tagging_Extension_Whitepaper.pdf

The implementation has been designed so that it is safe to enable in
distros (which makes a change!). ifunc and HWCAP are used to link
MTE-ready versions of relevant functions on hardware supporting
ARMv8.5 instruction set or later. On eailer hardware things will work
just as they do now.

Here is the (trivial) patch:
diff -u debian/sysdeps/arm64.mk~ debian/sysdeps/arm64.mk
--- debian/sysdeps/arm64.mk~2021-08-24 14:31:06.0 +
+++ debian/sysdeps/arm64.mk 2021-09-28 19:43:58.782118977 +
@@ -1,2 +1,2 @@
 # configuration options for all flavours
-extra_config_options = --enable-multi-arch --enable-static-pie
+extra_config_options = --enable-multi-arch --enable-static-pie 
--enable-memory-tagging


--
Wookey

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

[Samuel Henrique]

Hello Eugene,

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

Yes, I'm not setting the required libc6 version anywhere, that's
automatically done by dpkg.

>  To build version dependency automatically script should have access
>  to the whole history of all versions of libc6, with list of symbols
>  and markers when each symbol become usable.

We have that, you can read about it here[0][1][2], if you're interested.

> Note that presense of
>  symbol is not mean usability: for libc6-2.30 entry "lchown()" is
>  definitely present (ltrace confirms it), but attemptp to call it
>  return an error "not implemented", i.e. this version contains only
>  stub code (symbol is reserved for future use).

Yes, that's why the version automatically picked doesn't solve this
issue; the symbol was there before, it just changed behavior.
The symbols are also provided by a human so there's always room for
mistakes there, but that's not the case here.

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

We can also do it manually when needed, and that's my plan B[3].

> > The bug we are facing comes from libc6, as we can see in the upstream
> > bug report, and rsync is trying to workaround that issue (the patch I
> > introduced on 3.2.3-7).
>
>  I did not look through the code, but probably it detects presence of
>  lchown() but don't cover the situation when this entry is not functional.

Yes, I believe that could be what's happening with rsync's workaround.

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

I would disagree on the definition of a normal upgrade process, one
would never end up with a combination of incompatible rsync + libc,
that can only happen if somebody installs a package that is not
supported by Debian (not from the official repos) and that package
holds libc back (thus running an unsupported version)[4].
This doesn't necessarily mean your bug report is not valid, this issue
could mean I wouldn't be able to backport rsync, so I appreciate you
reporting it.

>  OK, I expressed my thoughts, technical problem is clear, so
>  it's left for you and upstream to find the best and right solution.

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

It might be possible that the issue you're seeing only affects libc
between 2.28 and 2.31, if that's the case, it will be very tricky for
me to reproduce since Debian only supports 2.28, 2.31 and 2.32.
I want to try it again, but this time by trying to reproduce the
issues I've seen in our CI system, let's see how it goes.

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

Just a small correction, I see you mentioned lchown, but the issue is
related to lchmod. I reckon you understand this, and it was just a
typo (easy to mix both together). I'm only mentioning this to avoid
confusion from someone else reading this.

[0] 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-symbols
[1] 
https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols
[2] https://wiki.debian.org/UsingSymbolsFiles
[3] That is, if we confirm that this is a bug and upstream doesn't
address it, though it's looking like upstream would be happy to fix
it, removing the need for the version requirement.
[4] It could also happen if a person does a partial upgrade between
releases with official packages only, but then it's something we can't
really say we support.
[5] https://github.com/WayneD/rsync/issues/109#issuecomment-927481747

Thank you,

-- 
Samuel Henrique 

Bug#995268: RFA: popt -- lib for parsing cmdline parameters - development files

[Michael Jeanson]

Package: wnpp
Severity: normal
Control: affects -1 src:popt

I request an adopter for the popt package, I don't have time to properly
maintain it. The package is in pretty good shape but there is some
patches and bugs to triage and address.

The package description is:
 Popt was heavily influenced by the getopt() and getopt_long() functions,
 but it allows more powerful argument expansion. It can parse arbitrary
 argv[] style arrays and automatically set variables based on command
 line arguments. It also allows command line arguments to be aliased via
 configuration files and includes utility functions for parsing arbitrary
 strings into argv[] arrays using shell-like rules.
 .
 This package contains the popt static library and header file.

Bug#995254: ITP: ruby-gaffe -- handles Rails error pages in a clean, simple way

[Mohd Bilal]

Package: wnpp
Severity: wishlist
Owner: Mohammed Bilal 

* Package name : ruby-gaffe
Version : 1.2.0
Upstream Author : Mirego
* URL : https://github.com/mirego/gaffe/
* License : Expat
Programming Lang: Ruby
Description : Gaffe handles Rails error pages in a clean, simple way.
 

This gem is a dependency of pupilfirst(pupilfirst.com)

Bug#990519: RFS: sentry-python/1.4.2-1 -- new version of Python SDK for Sentry.io

[Sandro Tosi]

please look at my comments at
https://lists.debian.org/debian-python/2021/09/msg00080.html

On Tue, Sep 28, 2021 at 12:12 PM Eberhard Beilharz  wrote:
>
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> Package updated to 1.4.2
>
> https://mentors.debian.net/package/sentry-python/



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#994453: Hit with linux-image-5.14.0-1-amd64 on Ryzen 5 3500U

[Jonathan McDowell]

I've hit this issue with the linux-image-5.14.0-1-amd64 (5.14.6-2) that
has made its way to testing this week; symptom is grub never shows
anything after the loading the initrd message. earlycon=efifb and
earlyprintk=efi didn't give any extra output. mem_encrypt=off resulted
in a successful boot.

Hardware is a Ryzen 3 3500U laptop. It seems like this is a potential
interaction between the memory encryption and amdgpu?

J.

-- 
... "What's the philosophical difference between a killfile and the
automoderation?" "A killfile throws away good posts.  Automoderation
throws away bad posts." -- Jonathan H N Chin to Calle Dybedahl

Bug#994888: chromium: chrome://extensions/ broken

[Reto Schoch]

For me the same:
chrome://bookmarks/, chrome://downloads/, chrome://history/ are broken.

Version 93.0.4577.82 (Entwickler-Build) built on Debian bookworm/sid,
running on Debian bookworm/sid (64-Bit)

Best regards
Reto

Bug#995267: devhelp doesn't load the selected content

[crvi]

Package: devhelp
Version: 41.1-1
Severity: important
X-Debbugs-Cc: crvi...@gmail.com

Dear Maintainer,

Opening devhelp succeeds, but the content is not getting loaded in the right
side pane.

Attached a screenshot of the issue.

Thanks!

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

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

Versions of packages devhelp depends on:
ii  libc6 2.32-4
ii  libdevhelp-3-641.1-1
ii  libglib2.0-0  2.70.0-1+b1
ii  libgtk-3-03.24.30-3
ii  libpango-1.0-01.48.10+ds1-1
ii  libwebkit2gtk-4.0-37  2.34.0-1
ii  python3   3.9.2-3

Versions of packages devhelp recommends:
ii  libglib2.0-doc   2.70.0-1
ii  libgtk-3-doc 3.24.30-3
ii  libpango1.0-doc  1.48.10+ds1-1

devhelp suggests no packages.

Bug#845501: Does not erase pid on loss of connection

[arnold metselaar]

Dear Pablo,

Unfortunately I will not be able to check any time soon.
You may wish to check yourself, or to simply close the bug report.

Kind regards,
Arnold

Op do 23 sep. 2021 22:21 schreef Pablo Mestre :

> Hi Arnold
>
> Thank you very much for reporting this error.
>
> I would like to ask you if this error is still present in the most
> recent versions of rdiff-backup. Currently after a series of
> improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]
>
> It would be very helpful if you checked again if this bug is still
> present. Otherwise we can agree to close the bug,
>
> [1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 <
> https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5>
>
> --
>   ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
>   ⣾⠁⢠⠒⠀⣿⡁  --
>   ⢿⡄⠘⠷⠚⠋   https://debian.org
>   ⠈⠳⣄  Debian, the universal operating system.
>
>

Bug#995266: openmpi: binary-all FTBFS

[Adrian Bunk]

Source: openmpi
Version: 4.1.2~rc1-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=openmpi=all=4.1.2~rc1-3=1632846883=0

...
   dh_missing -i
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/allclasses-index.html exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/allclasses.html 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/allpackages-index.html exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/constant-values.html 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/deprecated-list.html 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/element-list exists 
in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/help-doc.html exists 
in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/index-all.html 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/index.html exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/external/jquery/jquery.js exists 
in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-bg_glass_55_fbf9ee_1x400.png
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-bg_glass_65_dadada_1x400.png
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-bg_glass_75_dadada_1x400.png
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-bg_glass_75_e6e6e6_1x400.png
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-bg_glass_95_fef1ec_1x400.png
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-bg_highlight-soft_75_cc_1x100.png
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-icons_22_256x240.png 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-icons_2e83ff_256x240.png 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-icons_454545_256x240.png 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-icons_88_256x240.png 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/images/ui-icons_cd0a0a_256x240.png 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-3.5.1.js exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-ui.css 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-ui.js 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-ui.min.css exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-ui.min.js exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-ui.structure.css exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jquery-ui.structure.min.css exists 
in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jszip-utils/dist/jszip-utils-ie.js 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jszip-utils/dist/jszip-utils-ie.min.js
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jszip-utils/dist/jszip-utils.js 
exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jszip-utils/dist/jszip-utils.min.js
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
usr/share/doc/openmpi/javadoc-openmpi/jquery/jszip/dist/jszip.js 

Bug#995265: ethtool: Buffer overflow booting up network interface

[Dario Susman]

Package: ethtool
Version: 1:5.9-1
Severity: normal

Dear Maintainer,


Upgraded to latest testing branch, the attached dmesg output displays a
buffer overflow from/on ethtool. May be is kernel related. I'm not sure.

While the bug does not appear to hamper network connectivity so far, the
buffer overflow kernel message shows up quite often.

Best regards,
Dario Susman


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

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

Versions of packages ethtool depends on:
ii  libc62.32-4
ii  libmnl0  1.0.4-3

ethtool recommends no packages.

ethtool suggests no packages.

-- no debconf information
[Tue Sep 28 13:56:06 2021] Linux version 5.14.0-1-amd64 
(debian-ker...@lists.debian.org) (gcc-10 (Debian 10.3.0-10) 10.3.0, GNU ld (GNU 
Binutils for Debian) 2.37) #1 SMP Debian 5.14.6-2 (2021-09-19)
[Tue Sep 28 13:56:06 2021] Command line: 
BOOT_IMAGE=/boot/vmlinuz-5.14.0-1-amd64 
root=UUID=16e84623-5d05-4f7b-b741-ad28bcc81a9f ro initrd=/install/initrd.gz 
text fbcon=scrollback:4096k net.ifnames=0 apparmor=0
[Tue Sep 28 13:56:06 2021] x86/fpu: Supporting XSAVE feature 0x001: 'x87 
floating point registers'
[Tue Sep 28 13:56:06 2021] x86/fpu: Supporting XSAVE feature 0x002: 'SSE 
registers'
[Tue Sep 28 13:56:06 2021] x86/fpu: Supporting XSAVE feature 0x004: 'AVX 
registers'
[Tue Sep 28 13:56:06 2021] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  
256
[Tue Sep 28 13:56:06 2021] x86/fpu: Enabled xstate features 0x7, context size 
is 832 bytes, using 'compacted' format.
[Tue Sep 28 13:56:06 2021] signal: max sigframe size: 1776
[Tue Sep 28 13:56:06 2021] BIOS-provided physical RAM map:
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x-0x0009d3ff] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0009d400-0x0009] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x000e-0x000f] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0010-0x09d7] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x09d8-0x09ff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0a00-0x0a1f] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0a20-0x0a209fff] ACPI NVS
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0a20a000-0x0aff] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0b00-0x0b01] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0b02-0xdcdc3fff] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xdcdc4000-0xdcf2cfff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xdcf2d000-0xdd0aefff] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xdd0af000-0xdd4c2fff] ACPI NVS
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xdd4c3000-0xde661fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xde662000-0xdeff] usable
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xdf00-0xdfff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xf800-0xfbff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfd10-0xfdff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfea0-0xfea0] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfeb8-0xfec01fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfec1-0xfec10fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfec3-0xfec30fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfed0-0xfed00fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfed4-0xfed44fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfed8-0xfed8] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfedc2000-0xfedc] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfedd4000-0xfedd5fff] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xfee0-0xfeef] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0xff00-0x] reserved
[Tue Sep 28 13:56:06 2021] BIOS-e820: [mem 
0x0001-0x00021f37] usable
[Tue Sep 28 13:56:06 2021] NX (Execute Disable) protection: active
[Tue Sep 28 13:56:06 2021] SMBIOS 2.8 present.
[Tue Sep 28 13:56:06 2021] DMI: Micro-Star International Co., Ltd. MS-7A32/X370 
GAMING PRO CARBON (MS-7A32), BIOS 1.L0 01/21/2019
[Tue Sep 28 13:56:06 2021] tsc: Fast TSC calibration failed
[Tue Sep 

Bug#995260: closed by Vincent Blut (Re: Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon)

[S Egbert]

so why did it not use the Unix socket but fell back to 127.0.0.1 approach?

i wonder what happens if i do ‘cmddeny all’?

Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon

[Vincent Blut]

Hi,

Le 2021-09-28 11:55, Steve Egbert a écrit :
> Package: chrony
> Version: 4.0-8
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> X-Debbugs-Cc: s.egb...@sbcglobal.net
> 
> Dear Maintainer,
> 
> 
> The filename construct for a UNIX socket to be shared
> between the Chrony (chronyd) daemon and its Chrony CLI (chronyc) client
> admin tool are not in sync, as client's UNIX filename uses a PID value
> whereas server's UNIX filename does not use PID value.
> 
> This appears to be a Debian-only issue.

What makes you think that this issue, if at all, is specific to Debian?

> Fired up its daemon and doubled checked that a UNIX socket was made:
> 
> $ ls -1 /run/chrony
> chrony.sock
> chrony.pid

chrony in Debian will create by default the chronyd.{pid,sock} files. The
above shows that you are tweaked chronyd's configuration. What changes did you
make?
 
> Execute the client and no successful UNIX socket opened.
> 
> Using List Open File (lsof) tool, I show the daemon's opened files:
> 
> COMMAND   PID USER   FD   TYPE NODE NAME
> 
> chronyd  3597  _chrony3u  unix 0x \
> type=DGRAM
> chronyd  3597  _chrony5u  IPv4 UDP 127.0.0.1:323 
> chronyd  3597  _chrony6u  IPv6 UDP [::1]:323 
> chronyd  3597  _chrony7u  unix 0x \
> /run/chrony/chronyd.sock type=DGRAM
> chronyd  3597  _chrony8u  unix 0x type=SEQPACKET
> chronyc  3809johnd3u  IPv4 UDP \
> 127.0.0.1:33911->127.0.0.1:323 
> 
> No socket in the dispatcher part of the daemon, now to check the other
> forked part of the daemon used to carry on the connection with
> its chronyc client, same 'lsof' output.
> 
> COMMAND   PID USER   FD   TYPE NODE NAME
> 
> chronyd  3597  _chrony5u  IPv4 UDP 127.0.0.1:323 
> chronyd  3597  _chrony6u  IPv6 UDP [::1]:323 
> chronyd  3598  _chrony9u  unix 0x type=SEQPACKET
> chronyc  3809johnd3u  IPv4 UDP \
> 127.0.0.1:33911->127.0.0.1:323 
> 
> Appears that client failed socket open and fell back to a
> different approach which is using an IP loopback address.
> 
> Investigated why socket open failed... by using 'strace -f chrony[c|d]'.
> 
> For the chronyd v4.0 having opened a Debian-tweaked '/run/chrony/chrony.sock',
> I show the corresponding chronyc v4.0 version:
> 
> $ chronyc -v
> chronyc (chrony) version 4.0 (+READLINE +SECHASH +IPV6 -DEBUG)
> 
> And ran strace against this v4.0 client and grep'd for 'sock' word pattern:
> 
> $ strace -f /usr/bin/chronyc 
> socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> unlink("/run/chrony/chronyc.3875.sock") = -1 EACCES (Permission denied)
> 
> bind(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.3875.sock"}, 
> 110) = -1 EACCES (Permission denied)
> getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
> close(3)= 0
> 
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(323), 
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> 
> Noticed the 'PID' number being inserted into the 
> '/run/chrony/chronyc.3875.sock'?  
> This is the chronyc client doing "PID-sock" filenaming convention, whereas 
> its daemon is doing a different "just-sock" filenaming convention.

The PID is included to have the ability to run multiple chronyc instances at
the same time. Nothing wrong with that.
 
> The v4.1 client does exactly the same.
> 
> chronyc (chrony) version DEVELOPMENT (-READLINE -SECHASH +IPV6 +DEBUG)
> 
> socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> unlink("/var/run/chrony/chronyc.3885.sock") = -1 EACCES (Permission 
> denied)
> 
> bind(3, {sa_family=AF_UNIX, 
> sun_path="/var/run/chrony/chronyc.3885.sock"}, 110) = -1 EACCES (Permission 
> denied)
> getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
> close(3)= 0
> 
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(323), 
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
> read(0, ^Cstrace: Process 3885 detached
>  
> 
> It  would be nice to use consistent filenaming convention for the UNIX socket
> for both client and daemon.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995207: Acknowledgement (chrony: Using 'bindacqdevice' directive causes a SIGSYS error)

[S Egbert]

Trying attachment again.

It failed under iPhone 14.5.
Should succeed with Thunderbird/macOS

# ps auxwww | grep chronyd
_chrony 3597  0.0  0.0  18972  3696 ?S11:00   0:00 
/usr/sbin/chronyd -F 1 -L 0
_chrony 3598  0.0  0.0  10780  2984 ?S11:00   0:00 
/usr/sbin/chronyd -F 1 -L 0
root4142  0.0  0.0   6180   716 pts/0S+   12:10   0:00 grep chronyd

# systemctl restart chronyd

# ps auxwww | grep chronyd
root4156  0.0  0.0   6180   712 pts/0S+   12:11   0:00 grep chronyd

# systemctl status chronyd
chrony.service - chrony, an NTP client/server
 Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Tue 2021-09-28 12:11:06 EDT; 13s ago
   Docs: man:chronyd(8)
 man:chronyc(1)
 man:chrony.conf(5)
Process: 4147 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=exited, 
statusm 0/SUCCESS)
   Main PID: 4149 (code=killed, signal=SYS)
CPU: 36ms

Sep 28 12:11:06 localhost chronyd[4149]: chronyd version 4.0 starting (+CMDMON 
+NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 
-DEBUG)
Sep 28 12:11:06 localhost systemd[1]: chrony.service: Succeeded.
Sep 28 12:11:06 localhost chronyd[4149]: Frequency -3.305 +/- 0.025 ppm read 
from /v ar/lib/chrony/chrony.drift
Sep 28 12:11:06 localhost systemd[1]: Stopped chrony, an NTP client/server.
Sep 28 12:11:06 localhost chronyd[4149]: Using right/UTC timezone to obtain 
leap second data
Sep 28 12:11:06 localhost systemd[1]: Starting chrony, an NTP client/server...
Sep 28 12:11:06 localhost chronyd[4149]: Loaded seccomp filter
Sep 28 12:11:06 localhost systemd[1]: Started chrony, an NTP client/server.
Sep 28 12:11:06 localhost systemd[1]: 
chrony.service: Main process exited, code=kill
lines 1-19, status=31/SYS
lines 2-19 12:11:06 localhost systemd[1]: mchrony.service: Failed with 
result 'signal'.
lines 2-20 lines 2-20/20 (END)
lines 2-20/20 (END)
lines 2-20/20 (END)
# 
# # maintainer request
# strace -o chronyd_debug.txt chronyd -d -F 1
chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER 
+SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
2021-09-28T16:12:06Z Frequency -3.305 +/- 0.025 ppm read from 
/var/lib/chrony/chrony.drift
2021-09-28T16:12:06Z Using right/UTC timezone to obtain leap second data
2021-09-28T16:12:06Z Loaded seccomp filter
Bad system call
# cat chronyd_debug.txt
execve("/usr/sbin/chronyd", ["chronyd", "-d", "-F", "1"], 0x7ffecfacd628 /* 18 
vars */) = 0
brk(NULL)   = 0x55a4c537d000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=45532, ...}) = 0
mmap(NULL, 45532, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f84986a7000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", 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\0\0\362\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1321344, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f84986a5000
mmap(NULL, 1323280, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8498561000
mmap(0x7f849857, 630784, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7f849857
mmap(0x7f849860a000, 626688, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xa9000) = 0x7f849860a000
mmap(0x7f84986a3000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x141000) = 0x7f84986a3000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnettle.so.8", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\314\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=290416, ...}) = 0
mmap(NULL, 292416, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8498519000
mprotect(0x7f8498525000, 233472, PROT_NONE) = 0
mmap(0x7f8498525000, 139264, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f8498525000
mmap(0x7f8498547000, 90112, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2e000) = 0x7f8498547000
mmap(0x7f849855e000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x44000) = 0x7f849855e000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgnutls.so.30", O_RDONLY|O_CLOEXEC) = 
3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@y\3\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=2086552, ...}) = 0
mmap(NULL, 2094888, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8498319000
mmap(0x7f849834d000, 1183744, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x34000) = 0x7f849834d000
mmap(0x7f849846e000, 614400, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x155000) = 

Bug#995264: thunderbird: Save As saves empty file or gibberish

[David Christensen]

Package: thunderbird
Version: 1:78.14.0-1~deb10u1
Severity: important

Dear Maintainer,

I received an e-mail with attachments.  If I right-click on an
attachment and choose Save As, Thunderbird variously writes an empty
file or a file containing gibberish:

$ hexdump Ameriprise\ Planning.pdf 
  4e 18 ac 6e 87 72 a5 aa  ed c2 29 65 6d e7 68 c2  |N..n.r)em.h.|
0010  79 68 69 d7 9d a2 77 5e  99 a9 dd |yhi...w^...|
001b

$ hexdump 'Christensen NB.xlsx' 


David



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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.8.6.1
ii  fontconfig  2.13.1-2
ii  libatk1.0-0 2.30.0-2
ii  libbotan-2-92.9.0-2
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4+deb10u1
ii  libcairo2   1.16.0-4+deb10u1
ii  libdbus-1-3 1.12.20-0+deb10u1
ii  libdbus-glib-1-20.110-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libffi6 3.2.1-9
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libjson-c3  0.12.1+ds-2+deb10u1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u2
ii  libx11-xcb1 2:1.6.7-1+deb10u2
ii  libxcb-shm0 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.2-1
ii  x11-utils   7.7+4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:6.2.0-1
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-3+deb10u2
ii  libgtk2.0-0   2.24.32-3

-- no debconf information

Bug#995262: thunderbird: Detach All saves 27 bytes of gibberish

[David Christensen]

Package: thunderbird
Version: 1:78.14.0-1~deb10u1
Severity: important

Dear Maintainer,

I received a message with several attachments.  When I seleected
Detach All, Thunderbird wrote files containing the same gibberish:

$ hexdump image001.png 
  4e 18 ac 6e 87 72 a5 aa  ed c2 29 65 6d e7 68 c2  |N..n.r)em.h.|
0010  79 68 69 d7 9d a2 77 5e  99 a9 dd |yhi...w^...|
001b


David



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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.8.6.1
ii  fontconfig  2.13.1-2
ii  libatk1.0-0 2.30.0-2
ii  libbotan-2-92.9.0-2
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4+deb10u1
ii  libcairo2   1.16.0-4+deb10u1
ii  libdbus-1-3 1.12.20-0+deb10u1
ii  libdbus-glib-1-20.110-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libffi6 3.2.1-9
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libjson-c3  0.12.1+ds-2+deb10u1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u2
ii  libx11-xcb1 2:1.6.7-1+deb10u2
ii  libxcb-shm0 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.2-1
ii  x11-utils   7.7+4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:6.2.0-1
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-3+deb10u2
ii  libgtk2.0-0   2.24.32-3

-- no debconf information

Bug#995263: user-mode-linux: build-depends on removed package.

[peter green]

Source: user-mode-linux
Version: 5.10um3
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release."
Tags: bookworm, sid

user-mode-linux build-depends on linux-source-5.10 which is no longer built by 
the linux
source package. It is still present in unstable as a cruft package but is 
completely gone
from testing.

Bug#995256: [Aptitude-devel] Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error

[Axel Beckert]

Hi IOhannes,

IOhannes m zmoelnig wrote:
> - aptitude opens new *red* window where it prints
> 
> > E: Can't find a source to download version 'VERSION' of 'PACKAGE'
> 
> - the error window grows as one such line is printed about every 500ms
>   until it finally fills the entire height of the screen

I think I've seen that once or twice, too, but way to seldom to
actually bother as I considered it to be caused by inconsistencies
outside aptitude.

> - quitting aptitude and restarting it makes the problem go away

H.

> I have no idea why this happens, but originally thought it might be related to
> not having run 'update' as a first step.

I'd rather imagine something the other way round:

I wonder if there is a kind of race condition if aptitude is running
and then either on the admin on the commandline or a background job
runs "apt update".

> in the meantime i'm not so sure about this anymore (e.g. as i think i don't 
> have
> to run 'update' in the restarted aptitude).

No, you don't have to. Aptitude more or less just reads what files are
in /var/lib/apt/lists/ (and some more state files).

> in any case, i have not been able to find a way to reliably reproduce the
> problem (it just happens every now and then).

Ack.

> i've seen this problem for a "long time" by now (probably pre 2021)

Yes, haven't seen it recently.

> i've attached a screenshot.

Thanks! There's an interesting fact visible. First let's look at that
package:

  ~ → apt-cache show texlive-fonts-recommended
  Package: texlive-fonts-recommended
  Source: texlive-base
  Version: 2021.20210921-1
  Installed-Size: 15031
  Maintainer: Debian TeX Task Force 
  Architecture: all

So this package in question is arch:all.

But according to the screenshot, aptitude wants
texlive-fonts-recommended:amd64 for whatever reason — which indeed
does not exist. So it's probably _not_ related to updating package
lists in the background.

And yes, I've recently seen such an issue elsewhere, namely here:
https://salsa.debian.org/debian/zsh/-/jobs/1950702#L1463

The relevant lines are:

  The following packages have unmet dependencies:
  zsh-cross-build-deps:arm64 : Depends: cm-super-minimal:arm64 which is a 
virtual package and is not provided by any available package
  Unable to resolve dependencies!  Giving up...

(And yes, cm-super-minimal is arch:all as well.)

Then again, the above was already during dependency resolution and not
in the preview. It though still might be caused by the same bug mixing
up arch:all with arch:any packages as the above error message stems
from src/cmdline/cmdline_resolver.cc and hence is commandline-specific.

I tried to fix this in zsh like this:
https://salsa.debian.org/debian/zsh/-/commit/801f5e105ad6d1f767d28c8311edd263790f419f

And it indeed fixed the crossbuild CI check:
https://salsa.debian.org/debian/zsh/-/jobs/1946010

But unfortunately then on the buildds it failed for the arch:all build
with "B-D uninstallable" (note the missing 5.8-8 upload on
https://buildd.debian.org/status/logs.php?pkg=zsh=all) and I had
to revert that "fix".

> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

I wonder if this is a multiarch related bug since the case I mentioned
above was a cross-build and hence also has multiarch involved.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#994627: bullseye-pu: package debian-edu-config/2.11.56+deb11u1

[Holger Levsen]

On Sun, Sep 19, 2021 at 12:16:28AM +0200, Wolfgang Schweer wrote:
> [ Other info ]
> Holger Levsen will upload the package in case of approval.

Given a certain three year old^wnew policy I've went ahead and uploaded this 
now.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The upcoming clima apocalypse is the big elephant in every room now.


signature.asc
Description: PGP signature

Bug#994867: Please have a look in some packages in new [Was: Bug#994867: ITP: r-cran-jquerylib -- obtain 'jQuery' as an HTML dependency object in GNU R]

[Thorsten Alteholz]

Hi Andreas,

On 22.09.21 14:05, Andreas Tille wrote:

I'd like to add some comment to this package since I was personally
quite unhappy to see this new dependency from code copies of what we
have in Debian.  However, this was only first sight, since we do not
have jQuery version 1 and 2 any more and for the CRAN packages we also
need to pin the minor version of version 3 code for the CRAN packages.


there is a reason why those older versions should not be part of Debian 
anymore.

They are no longer supported by upstream and do not get any security fixes.


After second thought about it these code copies are on one hand not
worse than several others uncovered by my research


So please file bug against packages that contain open security issues.

  Thorsten

Bug#995160: transition: schroedinger-coordgenlibs

[Sebastian Ramacher]

On 2021-09-28 08:12:11, Andrius Merkys wrote:
> Hi Sebastian,
> 
> On 2021-09-28 00:40, Sebastian Ramacher wrote:
> > Please go ahead
> 
> Thanks! By the way, did you intend to close the transition bug? AFAIR,
> such bugs were kept open until the completion of transitions before.

This was a mistake. In any case, the binNMUs have been scheduled, but
the failed. The issue is tracked in #995241

Cheers
-- 
Sebastian Ramacher

Bug#995259: python-pybedtools: please make the build reproducible

[Chris Lamb]

forwarded 995259 https://github.com/daler/pybedtools/pull/349
thanks

I've forwarded this upstream here:

  https://github.com/daler/pybedtools/pull/349


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"

[Prof. Dr. Christian Baun]

Hello Anthony
Hello Omar,

Is there anything now on this wminput bug?
Any best practices? :-)

In Debian 11, the error message is still present and wminput does not work.

$ wminput
ImportError: 
/usr/lib/python3/dist-packages/cwiid.cpython-39-x86_64-linux-gnu.so:
undefined symbol: PyVarObject_CallFunction

$ wminput 00:1F:32:FA:82:95 -c ~/.cwiid/wminput -w -r
ImportError: 
/usr/lib/python3/dist-packages/cwiid.cpython-39-x86_64-linux-gnu.so:
undefined symbol: PyVarObject_CallFunction

$ uname -srvm
Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-5 (2021-09-23) x86_64

BTW: wmgui works well, but this does not help here much... ;-)

Best regards
   Christian

On Fri, 08 Jan 2021 16:32:04 -0600 Omar Jair Purata Funes
 wrote:
> Package: wminput
> Version: 0.6.91-2+b1
> Followup-For: Bug #976439
> X-Debbugs-Cc: omarpura...@gmail.com
>
> Also experiencing this on bullseye. I'm trying to use the mentioned forks 
> above but none of them seem to work properly yet. Would be glad to help patch 
> testing in case something turns out.
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
> Locale: LANG=es_MX.UTF-8, LC_CTYPE=es_MX.UTF-8 (charmap=UTF-8), 
> LANGUAGE=es_MX:es
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages wminput depends on:
> ii  libbluetooth3  5.55-3
> ii  libc6  2.31-6
> ii  libcwiid1  0.6.91-2+b1
> ii  libpython3.9   3.9.1-1
> ii  python3-cwiid  0.6.91-2+b1
>
> wminput recommends no packages.
>
> wminput suggests no packages.
>
> -- Configuration Files:
> /etc/cwiid/wminput/gamepad changed:
> Classic.Dpad.X = ABS_X
> Classic.Dpad.Y = ABS_Y
> Classic.LStick.X = ABS_HAT0X
> Classic.LStick.Y = ABS_HAT0Y
> Classic.RStick.X = ABS_HAT1X
> Classic.RStick.Y = ABS_HAT1Y
> Classic.LAnalog = ABS_GAS
> Classic.RAnalog = ABS_BRAKE
> Classic.A = BTN_A
> Classic.B = BTN_B
> Classic.X = BTN_X
> Classic.Y = BTN_Y
> Classic.Minus = BTN_SELECT
> Classic.Plus  = BTN_START
> Classic.Home  = BTN_MODE
> Classic.L  = BTN_TL
> Classic.R  = BTN_TR
> Classic.ZL = BTN_TL2
> Classic.ZR = BTN_TR2
> Classic.Down = BTN_THUMBL
> Classic.Up = BTN_THUMBR
>
>
> Wiimote.Up = KEY_U
> Wiimote.Down = KEY_D
> Wiimote.Left = KEY_L

Bug#990519: RFS: sentry-python/1.4.2-1 -- new version of Python SDK for Sentry.io

[Eberhard Beilharz]

X-Debbugs-Cc: debian-pyt...@lists.debian.org

Package updated to 1.4.2

https://mentors.debian.net/package/sentry-python/  

Bug#995261: lintian: non-standard-file-perm false positives for files in /etc/sudoers.d/ (missing "return"?)

[Axel Beckert]

Package: lintian
Version: 2.106.1
Severity: normal
Tags: patch

Hi,

lintian today showed me the following warning:

  W: hobbit-plugins: non-standard-file-perm etc/sudoers.d/xymon 0440 != 0644

But /etc/sudoers.d/README (at least in Debian 11 Bullseye) reads:

  # Note that there must be at least one file in the sudoers.d directory (this
  # one will do), and all files in this directory should be mode 0440.

Looking at lib/Lintian/Check/Files/Permissions.pm there is already a
special handling for files in /etc/sudoers.d/:

183 # sudo requires sudoers files to be mode oct(440)
184 if (   $file->name =~ m{^ etc/sudoers.d/ }msx
185 && $file->operm != $SUDOERS_FILE) {
186 
187 $self->hint(
188 'bad-perm-for-file-in-etc-sudoers.d',$file->name,
189 $file->octal_permissions, $NOT_EQUAL,
190 sprintf('%04o', $SUDOERS_FILE));
191 
192 return;
193 }
194 
195 $self->hint(
196 'non-standard-file-perm', $file->name,
197 $file->octal_permissions, $NOT_EQUAL,
198 sprintf('%04o', $STANDARD_FILE)
199 )unless $file->operm == $STANDARD_FILE;

But if the file in /etc/sudoers.d/ has the expected permissions, the
code continues to check against standard permissions instead of
returning already.

So I think that this if clause in line 184/185 needs to be split up to
call return even if the tag is not emitted:

# sudo requires sudoers files to be mode oct(440)
if ( $file->name =~ m{^ etc/sudoers.d/ }msx ) {
if ( $file->operm != $SUDOERS_FILE) {
$self->hint(
'bad-perm-for-file-in-etc-sudoers.d',$file->name,
$file->octal_permissions, $NOT_EQUAL,
sprintf('%04o', $SUDOERS_FILE));
}

return;
}

(Code untested. Might work, though. Can also apply and test the code
myself, but I'd appreciate at least a short acknowledgement that the
current code is indeed _not_ working as intended. Probably should get a
test case, too. :-)

Thanks in advance!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.37-7
ii  bzip2   1.0.8-4
ii  clzip   1.12-2
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.26-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdigest-sha-perl  6.02-1+b3
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.12-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.611-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  

Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon

[Steve Egbert]

Package: chrony
Version: 4.0-8
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: s.egb...@sbcglobal.net

Dear Maintainer,


The filename construct for a UNIX socket to be shared
between the Chrony (chronyd) daemon and its Chrony CLI (chronyc) client
admin tool are not in sync, as client's UNIX filename uses a PID value
whereas server's UNIX filename does not use PID value.

This appears to be a Debian-only issue.

Fired up its daemon and doubled checked that a UNIX socket was made:

$ ls -1 /run/chrony
chrony.sock
chrony.pid

Execute the client and no successful UNIX socket opened.

Using List Open File (lsof) tool, I show the daemon's opened files:

COMMAND   PID USER   FD   TYPE NODE NAME

chronyd  3597  _chrony3u  unix 0x \
type=DGRAM
chronyd  3597  _chrony5u  IPv4 UDP 127.0.0.1:323 
chronyd  3597  _chrony6u  IPv6 UDP [::1]:323 
chronyd  3597  _chrony7u  unix 0x \
/run/chrony/chronyd.sock type=DGRAM
chronyd  3597  _chrony8u  unix 0x type=SEQPACKET
chronyc  3809johnd3u  IPv4 UDP \
127.0.0.1:33911->127.0.0.1:323 

No socket in the dispatcher part of the daemon, now to check the other
forked part of the daemon used to carry on the connection with
its chronyc client, same 'lsof' output.

COMMAND   PID USER   FD   TYPE NODE NAME

chronyd  3597  _chrony5u  IPv4 UDP 127.0.0.1:323 
chronyd  3597  _chrony6u  IPv6 UDP [::1]:323 
chronyd  3598  _chrony9u  unix 0x type=SEQPACKET
chronyc  3809johnd3u  IPv4 UDP \
127.0.0.1:33911->127.0.0.1:323 

Appears that client failed socket open and fell back to a
different approach which is using an IP loopback address.

Investigated why socket open failed... by using 'strace -f chrony[c|d]'.

For the chronyd v4.0 having opened a Debian-tweaked '/run/chrony/chrony.sock',
I show the corresponding chronyc v4.0 version:

$ chronyc -v
chronyc (chrony) version 4.0 (+READLINE +SECHASH +IPV6 -DEBUG)

And ran strace against this v4.0 client and grep'd for 'sock' word pattern:

$ strace -f /usr/bin/chronyc 
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
unlink("/run/chrony/chronyc.3875.sock") = -1 EACCES (Permission denied)

bind(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.3875.sock"}, 110) 
= -1 EACCES (Permission denied)
getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
close(3)= 0

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(323), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0

Noticed the 'PID' number being inserted into the 
'/run/chrony/chronyc.3875.sock'?  
This is the chronyc client doing "PID-sock" filenaming convention, whereas 
its daemon is doing a different "just-sock" filenaming convention.

The v4.1 client does exactly the same.

chronyc (chrony) version DEVELOPMENT (-READLINE -SECHASH +IPV6 +DEBUG)

socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
unlink("/var/run/chrony/chronyc.3885.sock") = -1 EACCES (Permission denied)

bind(3, {sa_family=AF_UNIX, sun_path="/var/run/chrony/chronyc.3885.sock"}, 
110) = -1 EACCES (Permission denied)
getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
close(3)= 0

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(323), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
read(0, ^Cstrace: Process 3885 detached
 

It  would be nice to use consistent filenaming convention for the UNIX socket
for both client and daemon.



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

Kernel: Linux 5.10.46 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_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 chrony depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  iproute2 5.10.0-4
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libedit2 3.1-20191231-2+b1
ii  libgnutls30  3.7.1-5
ii  libnettle8   3.7.3-1
ii  libseccomp2  2.5.1-1
ii  tzdata   2021a-1
ii  ucf  3.0043

chrony recommends no packages.

Versions of packages chrony suggests:
ii  bind9-dnsutils [dnsutils]  1:9.16.15-1
pn  networkd-dispatcher

-- 

Bug#995259: python-pybedtools: please make the build reproducible

[Chris Lamb]

Source: python-pybedtools
Version: 0.8.0-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
python-pybedtools could not be built reproducibly.

This is because it includes output inherited from non-deterministic
filesystem ordering:

/usr/lib/python3/dist-packages/pybedtools/cbedtools.cpp:

│ │ │ │ @@ -16,17 +16,17 @@
│ │ │ │  "z"
│ │ │ │  ],
│ │ │ │  "name": "pybedtools.cbedtools",
│ │ │ │  "sources": [
│ │ │ │  "pybedtools/cbedtools.pyx",
│ │ │ │ -"pybedtools/include/fileType.cpp",
│ │ │ │  "pybedtools/include/bedFile.cpp",
│ │ │ │ -"pybedtools/include/gzstream.cpp"
│ │ │ │ +"pybedtools/include/gzstream.cpp",
│ │ │ │ +"pybedtools/include/fileType.cpp"
│ │ │ │  ]
│ │ │ │  },
│ │ │ │  "module_name": "pybedtools.cbedtools"
│ │ │ │  }

Patch attached that sorts these entries in setup.py.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-builds.patch  1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-builds.patch  2021-09-28 16:37:45.666272543 
+0100
@@ -0,0 +1,24 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-09-28
+
+--- python-pybedtools-0.8.0.orig/setup.py
 python-pybedtools-0.8.0/setup.py
+@@ -199,7 +199,7 @@ extensions = [
+ depends=glob.glob('pybedtools/include/*h'),
+ libraries=['stdc++', 'z'],
+ include_dirs=['pybedtools/include/'],
+-sources=['pybedtools/cbedtools' + EXT] + 
glob.glob('pybedtools/include/*.cpp'),
++sources=['pybedtools/cbedtools' + EXT] + 
sorted(glob.glob('pybedtools/include/*.cpp')),
+ language='c++'),
+ 
+ Extension(
+@@ -207,7 +207,7 @@ extensions = [
+ depends=glob.glob('pybedtools/include/*h'),
+ libraries=['stdc++', 'z'],
+ include_dirs=['pybedtools/include/'],
+-sources=['pybedtools/featurefuncs' + EXT] + 
glob.glob('pybedtools/include/*.cpp'),
++sources=['pybedtools/featurefuncs' + EXT] + 
sorted(glob.glob('pybedtools/include/*.cpp')),
+ language='c++'),
+ ]
+ 
--- a/debian/patches/series 2021-09-28 16:33:12.425681025 +0100
--- b/debian/patches/series 2021-09-28 16:37:44.886270948 +0100
@@ -8,3 +8,4 @@
 remove_badges_from_documentation.patch
 parseDebianVersions.patch
 add_missing_shebang.patch
+reproducible-builds.patch

Bug#995258: python-pairix: please make the build reproducible

[Chris Lamb]

Source: python-pairix
Version: 0.3.7-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
python-pairix could not be built reproducibly.

This is because whilst the generation of samples.tar.xz correctly uses
--mode, --owner, --group as well as --numeric-owner, it misses
--sort=name. It, therefore, inherits the underlying and
nondeterministic filesystem ordering.

A patch is attached that adds precisely this.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


--- a/debian/rules  2021-09-28 16:31:43.781471389 +0100
--- b/debian/rules  2021-09-28 16:38:20.346343067 +0100
@@ -10,7 +10,7 @@
dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_install:
-   tar caf samples.tar.xz samples --mode=go=rX,u+rw,a-s --owner=0 
--group=0 --numeric-owner
+   tar caf samples.tar.xz samples --mode=go=rX,u+rw,a-s --owner=0 
--group=0 --numeric-owner --sort=name
dh_install
find debian/python3-$(PYBUILD_NAME)/usr/lib -name samples -type d | 
xargs rm -rf
find debian/*/usr/lib -name VERSION.txt -delete

Bug#995257: backintime-qt4: does not check if backup directory exists (or drive is mounted)

[wim]

Package: backintime-qt4
Version: 1.1.24-0.1
Severity: important

Hello,

when u use backintime and backintime-qt4 on a desktop,
the backup files are mostly on a remote medium, likely physically different 
storage,
so this external location should be mounted before the backup is made.

* backup are mostly run regular basis, using (cron) anacron in this case
* a use case is an external usb-drive (harddisk)

the observed behaviour:
* if the backupdrive is mounted, no problem
* if the backupdrive is not mounted, the backup is made on the mountpoint 
itself,
(eating up local storage)
* if later the backupdrive is mounted again for a another backup, the backup 
continues, no problem
* but in the meanwhile there is local storage that is being occupied for 
everytime the backup did not got to the backup drive (ie it was not mounted), 
but the directory referring to the local mountpoint

so the problem: after a while using a laptop, with not always the backup-drive 
connected, the hard drive gets filled with locally backup files,
that are not visible the backup is mounted, so one starts to wonder where all 
the diskspace went :)

expected behaviour:
* no backup is made when the external drive is not mounted

more info about the cronjob

cat /var/spool/cron/crontabs/root 
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/tmpisqqmnvj installed on Fri Nov 22 16:55:30 2019)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#Back In Time system entry, this will be edited by the gui:
*/15 * * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime 
backup-job >/dev/null 2>&1

while the setting is once a day in the gui,
and this seems the case in reality,
but this is not the reason, just a note

for now a manual fix is to change the cron entry with a preceeding mountpoint 
check

hth,
Wim

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

Kernel: Linux 5.10.0-0.bpo.8-amd64 (SMP w/16 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE.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 backintime-qt4 depends on:
ii  backintime-common 1.1.24-0.1
ii  libnotify-bin 0.7.7-4
ii  policykit-1   0.105-25
ii  python3   3.7.3-1
ii  python3-dbus.mainloop.qt  4.12.1+dfsg-2+b1
ii  python3-pyqt4 4.12.1+dfsg-2+b1
ii  x11-utils 7.7+4

Versions of packages backintime-qt4 recommends:
ii  python3-secretstorage  2.3.1-2

Versions of packages backintime-qt4 suggests:
ii  kompare  4:18.08.1-1
ii  meld 3.20.0-2

-- no debconf information

Bug#995248: umockdev 0.16.3-1 breaks autopkgtest of bolt

[Martin Pitt]

Control: reassign -1 bolt  0.9.1-1
Control: affects -1 umockdev
Control: tag -1 upstream pending
Control: forwarded -1 
https://gitlab.freedesktop.org/bolt/bolt/-/merge_requests/246

Hello Christian,

as I mentioned on the LP bug already, I noticed that bolt regression and sent
an upstream fix for bolt.

Thanks,

Martin

Bug#995255: ITP: r-bioc-isoformswitchanalyzer -- Identify, Annotate and Visualize Alternative Splicing and

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-isoformswitchanalyzer -- Identify, Annotate and Visualize 
Alternative Splicing and
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-isoformswitchanalyzer
  Version : 1.14.0
  Upstream Author : Kristoffer Vitting-Seerup
* URL : https://bioconductor.org/packages/IsoformSwitchAnalyzeR/
* License : GPL-2+
  Programming Lang: GNU R
  Description : Identify, Annotate and Visualize Alternative Splicing and
 Isoform Switches with Functional Consequences from both short- and
 long-read RNA-seq data. Analysis of alternative splicing and
 isoform switches with predicted functional consequences (e.g.
 gain/loss of protein domains etc.) from quantification of all
 types of RNASeq by tools such as Kallisto, Salmon, StringTie,
 Cufflinks/Cuffdiff etc.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-isoformswitchanalyzer

Bug#995251: xymon-client: missing /etc/xymon/graphs.d/mq.cfg

[Axel Beckert]

Control: tag -1 + confirmed pending
Control: found -1 20170219

Hi Carsten,

Carsten Leonhardt wrote:
> the plugin mq reports data for graphing, but there is no corresponding
> file for the server side (/etc/xymon/graphs.d/mq.cfg).

Indeed, thanks for that bug report!

> Since one of the maintainers wrote the plugin, maybe you have the
> file and just forgot to include it?

Looks very much like that, yes. :-)

And yes I found the file. I've also attached it to this mail and
committed it to git, so it will be included in the next upload.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
[mq_mails]
FNPATTERN mq,(.*)mails.rrd
TITLE Mails in Mail Queue
YAXIS Mails
DEF:activemails@RRDIDX@=@RRDFN@:activemails:AVERAGE
LINE2:activemails@RRDIDX@#0f0:active
-o
-l 0.8
-r
GPRINT:activemails@RRDIDX@:LAST:   \: %5.1lf (cur)
GPRINT:activemails@RRDIDX@:MAX: \: %5.1lf (max)
GPRINT:activemails@RRDIDX@:MIN: \: %5.1lf (min)
GPRINT:activemails@RRDIDX@:AVERAGE: \: %5.1lf (avg)\n
DEF:deferredmails@RRDIDX@=@RRDFN@:deferredmails:AVERAGE
LINE2:deferredmails@RRDIDX@#f00:deferred
-o
-l 0.8
-r
GPRINT:deferredmails@RRDIDX@:LAST: \: %5.1lf (cur)
GPRINT:deferredmails@RRDIDX@:MAX: \: %5.1lf (max)
GPRINT:deferredmails@RRDIDX@:MIN: \: %5.1lf (min)
GPRINT:deferredmails@RRDIDX@:AVERAGE: \: %5.1lf (avg)\n
DEF:holdmails@RRDIDX@=@RRDFN@:holdmails:AVERAGE
LINE2:holdmails@RRDIDX@#00f:hold
-o
-l 0.8
-r
GPRINT:holdmails@RRDIDX@:LAST: \: %5.1lf (cur)
GPRINT:holdmails@RRDIDX@:MAX: \: %5.1lf (max)
GPRINT:holdmails@RRDIDX@:MIN: \: %5.1lf (min)
GPRINT:holdmails@RRDIDX@:AVERAGE: \: %5.1lf (avg)\n

[mq_recipients]
FNPATTERN mq,(.*)recipients.rrd
TITLE Recipients in Mail Queue
YAXIS Recipients
DEF:activerecipients@RRDIDX@=@RRDFN@:activerecipients:AVERAGE
LINE2:activerecipients@RRDIDX@#0f0:active
-o
-l 0.8
-r
GPRINT:activerecipients@RRDIDX@:LAST:   \: %5.1lf (cur)
GPRINT:activerecipients@RRDIDX@:MAX: \: %5.1lf (max)
GPRINT:activerecipients@RRDIDX@:MIN: \: %5.1lf (min)
GPRINT:activerecipients@RRDIDX@:AVERAGE: \: %5.1lf (avg)\n
DEF:deferredrecipients@RRDIDX@=@RRDFN@:deferredrecipients:AVERAGE
LINE2:deferredrecipients@RRDIDX@#f00:deferred
-o
-l 0.8
-r
GPRINT:deferredrecipients@RRDIDX@:LAST: \: %5.1lf (cur)
GPRINT:deferredrecipients@RRDIDX@:MAX: \: %5.1lf (max)
GPRINT:deferredrecipients@RRDIDX@:MIN: \: %5.1lf (min)
GPRINT:deferredrecipients@RRDIDX@:AVERAGE: \: %5.1lf (avg)\n
DEF:holdrecipients@RRDIDX@=@RRDFN@:holdrecipients:AVERAGE
LINE2:holdrecipients@RRDIDX@#00f:hold
-o
-l 0.8
-r
GPRINT:holdrecipients@RRDIDX@:LAST: \: %5.1lf (cur)
GPRINT:holdrecipients@RRDIDX@:MAX: \: %5.1lf (max)
GPRINT:holdrecipients@RRDIDX@:MIN: \: %5.1lf (min)
GPRINT:holdrecipients@RRDIDX@:AVERAGE: \: %5.1lf (avg)\n

Bug#994972: devscripts: uscan signature verification fails, probably due to gpgv not supporting armored keyrings

[Mattia Rizzolo]

Control: close -1

On Tue, Sep 28, 2021 at 04:05:23PM +0100, Nikolaus Rath wrote:
> On Sep 28 2021, Mattia Rizzolo  wrote:
> > % gpg --export --export-options export-minimal --armor nikol...@rath.org > 
> > debian/upstream/signing-key.asc
> > % uscan -ddd
> > [same result as above]
> 
> I am mystified. I am on the same system as before and this time it works
> for me too.
> 
> I guess you can close this bug since I can't reproduce it
> anymore.. weird.

Good then :)
You can merge my branch into master to turn it into ascii-armored :P

> Sorry for wasting your time.

np!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#995253: lintian: uses-dpkg-database-directly triggered on comments in script

[Mintytail]

Package: lintian
Version: 2.62.0ubuntu1
Severity: normal

I have a sample output of `apt-cache policy $PACKAGE` in my script
comments:
```
#   Installed: 2.0.8
#   Candidate: 2.0.10
#   Version table:
#   2.0.10 500
#   500 https://deb...com/apt/debian bionic/main arm64 Packages
#   500 https://deb...com/apt/debian bionic/main armhf Packages
#   *** 2.0.8 100
#   100 /var/lib/dpkg/status
```

Lintian is triggered by the last line. If i change `dpkg` to `_dpkg` in
it, the warning uses-gpkg-database-directly is gone.

The script first line is `#!/bin/sh`


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

Kernel: Linux 5.8.0-59-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.34-6ubuntu1.1
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7ubuntu3
ii  dpkg-dev 1.19.7ubuntu3
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10build1
ii  gpg  2.2.19-3ubuntu2.1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36build3
ii  libarchive-zip-perl  1.67-2
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3build3
ii  libclone-perl0.43-2
ii  libcpanel-json-xs-perl   4.19-1build1
ii  libdevel-size-perl   0.83-1build1
ii  libdpkg-perl 1.19.7ubuntu3
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1build5
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libsereal-decoder-perl   4.011+ds-1build1
ii  libsereal-encoder-perl   4.011+ds-1build1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  libunicode-utf8-perl 0.62-1build1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-1build1
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.30.0-9ubuntu0.2
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1ubuntu1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1build5

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- debconf-show failed

Bug#995252: ITP: r-bioc-drimseq -- Differential transcript usage and tuQTL analyses with

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-drimseq -- Differential transcript usage and tuQTL 
analyses with
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-drimseq
  Version : 1.20.0
  Upstream Author : Malgorzata Nowicka
* URL : https://bioconductor.org/packages/DRIMSeq/
* License : GPL-3+
  Programming Lang: GNU R
  Description : Differential transcript usage and tuQTL analyses with
 Dirichlet-multinomial model in RNA-seq The package provides two
 frameworks. One for the differential transcript usage analysis
 between different conditions and one for the tuQTL analysis. Both
 are based on modeling the counts of genomic features (i.e.,
 transcripts) with the Dirichlet-multinomial distribution. The
 package also makes available functions for visualization and
 exploration of the data and results.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-drimseq

Bug#995251: xymon-client: missing /etc/xymon/graphs.d/mq.cfg

[Carsten Leonhardt]

Package: xymon-client
Version: 
Severity: normal

Dear Maintainer,

the plugin mq reports data for graphing, but there is no corresponding
file for the server side (/etc/xymon/graphs.d/mq.cfg). Since one of the
maintainers wrote the plugin, maybe you have the file and just forgot to
include it?

Regards

Carsten

Bug#995250: Fwd: Cannot login after installing an NVIDIA video driver

[Tibor Gacs]

Package: nvidia
Version: latest

Dear Debian Support Team,
I have recently installed the latest driver for the NVIDIA GeForce
GT210/GT218 card found on the NVIDIA website on a desktop machine running
Debian 10 with KDE Plasma. According to the instructions I've added
NVIDIA's repository to the sources list of apt, ran the update and
installed the driver, then rebooted after the installation, as it was
suggested by the guide. Unfortunately after the restart the login screen
was not displayed, only a small underscore mark in the corner (not
blinking) and a mouse cursor. When opening the console, I was prompted for
login, but when typing in either the username, or "root" I wasn't asked for
a password, but received the error message "Incorrect login". The issue
remained even after removing the graphics card and using the integrated VGA
port of the motherboard, or when trying to start the system in recovery
mode. This way I'm not even able to log in just to purge the driver and
continue using the one shipped with Debian 10. Please let me know how I can
fix this issue. Thank you in advance for your help!
Best regards,
Tibor Gacs

PS: since I can't login, I'm not able to use the reportbug program, sorry
for that.

Bug#995235: debian-installer-11-netboot-arm64: debian installer live and firmware fail on empty machine

[r]

Package: debian-installer-11-netboot-arm64
Severity: important

Dear Reader,

0 The troubles happen on a new and empty machine (specially bought for Debian)
:
- Intel Core i3-10100
- Gigabyte B560 HD3
- Kingston Fury beast 16 Go
- Crucial P2 M.2 PCIe NVMe 500 Go (SSD)

1 I download debian-live-11.0.0-amd64-gnome.iso, put it on a key and execute
the whole graphical installation.
It works fine but when the machine starts to reboot
- few lines appear very very fast (RAM something, processor something ...) and
then
- black screen with only a cursor in the top left quarter for 2 seconds and
then
- back to bios where I see the ssd disk with the right name, manually exit and
then
- few lines appear ...
- black screen ...
and again and again
The only possibility was to power off.


2 I download debian-11.0.0-amd64-netinst.iso, put it on a key ..
It works fine but ...
Same story as 1.
I install 2 other times but the result remains the same.


3 I use reportbug (#995089) but not knowing the name of the package the answer
starts with "There is no such package in Debian".
The suggestion is to use an installer containing firmware.


4 I download firmware-11.0.0-amd64-netinst.iso an start graphical installation.
Things start the right way but the mirror gets slower and slower and completely
stops to send files.
I wait 2 hours but nothing happens.
I power off the modem and disconnect the cable of the machine.
The screen offers no possibility to stop the running operation so I can only
power off the machine.


5 Then modem on, cable connected, key always in its proper place, machine on
- first of all, very fast on black screen something like "hardware error cpu
machine check" and 3 or 4 other lines talking about hardware
- bios, key was always selected
- installing starts but is not able to deal with dhcp
- many tries (even debian-live-11.0.0-amd64-gnome.iso again) but the installer
does not see the network card anymore
- the bios sees the card, so it looks like installer and card don't like each
other

When the key is in its place I found that there is a little console (Nano) but
I don't know what to do with it (reach logs, clean, ...)
I have the datasheet of each component.

Programmer during the last 35 years (tons of SQL on W machines), but new in
Debian (04/2021, Debian GNU/Linux 10 (buster) on a W7 existing machine).
I want to stay in this free software and try to help (Diversité et équité).


Many thanks
Renaud Roche (Marseille France)



-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

Bug#994972: devscripts: uscan signature verification fails, probably due to gpgv not supporting armored keyrings

[Mattia Rizzolo]

Hi,

sorry it took me a bit longer to verify this.

On Fri, Sep 24, 2021 at 11:02:55AM +0100, Nikolaus Rath wrote:
> On Fri, 24 Sep 2021, at 11:00, Mattia Rizzolo wrote:
> >> At first I thought that the upstream signature file was corrupted, but
> >> it seems that gpgv can't deal with a the keyring if it is generated the
> >> way that uscan(1) says it should be:
> >
> > I'll need to check your specifc case, but I can assure you that armored
> > keys are very much fine and I'm using them all the time with uscan.
> 
> 
> Thanks for the quick response. Let me know if I can help in any way -
> I don't see myself doing anything special, just executing the commands
> given in uscan(1) on a bullseye system (with devscripts installed from
> unstable, just in case).

I'm still convinced you did something weird.

So I cloned your s3ql repo and

% git checkout a8a5cd2633e372e238595004e92a6e93f94d6714^
% cd debian
% mkdir upstream
% mv upstream-signing-key.pgp upstream/signing-key.asc
% ..
% uscan
uscan info: uscan (version 2.21.4) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="s3ql" version="3.7.0+dfsg-3" (as seen in debian/changelog)
uscan info: package="s3ql" version="3.7.0+dfsg" (no epoch/revision)
...
uscan: Newest version of s3ql on remote site is 3.7.3+dfsg, local version is 
3.7.0+dfsg
uscan:  => Newer package available from:
=> 
https://github.com/s3ql/s3ql/releases/download/release-3.7.3/s3ql-3.7.3.tar.bz2
uscan info: Downloading upstream package: s3ql-3.7.3.tar.bz2
uscan info: Requesting URL:
   
https://github.com/s3ql/s3ql/releases/download/release-3.7.3/s3ql-3.7.3.tar.bz2
uscan info: Successfully downloaded package: s3ql-3.7.3.tar.bz2
uscan info: Downloading OpenPGP signature from:
   
https://github.com/s3ql/s3ql/releases/download/release-3.7.3/s3ql-3.7.3.tar.bz2.asc
 (pgpsigurlmangled)
   as s3ql-3.7.3.tar.bz2.asc
uscan info: Requesting URL:
   
https://github.com/s3ql/s3ql/releases/download/release-3.7.3/s3ql-3.7.3.tar.bz2.asc
uscan info: Verifying OpenPGP signature ../s3ql-3.7.3.tar.bz2.asc for 
../s3ql-3.7.3.tar.bz2
gpgv: Signature made Thu 03 Jun 2021 09:40:47 PM CEST
gpgv:using RSA key ED31791B2C5C1613AF388B8AD113FCAC3C4E599F
gpgv: Good signature from "Nikolaus Rath "
uscan info: New orig.tar.* tarball version (oversionmangled): 3.7.3+dfsg
uscan info: Launch mk-origtargz with options:
   --package s3ql --version 3.7.3+dfsg --rename --signature 1 --signature-file 
../s3ql-3.7.3.tar.bz2.asc --compression default --directory .. --copyright-file 
debian/copyright ../s3ql-3.7.3.tar.bz2
Skip adding upstream signature since upstream file is repacked.
Successfully repacked ../s3ql-3.7.3.tar.bz2 as ../s3ql_3.7.3+dfsg.orig.tar.xz, 
deleting 108 files from it.
uscan info: New orig.tar.* tarball version (after mk-origtargz): 3.7.3+dfsg
uscan info: Scan finished


I didn't even bother to export it anew, since what you have (although
with a .pgp extension) already was armored.

Anyway, since you are DM and I already have your key in my local copyof
the keyring:

% gpg --export --export-options export-minimal --armor nikol...@rath.org > 
debian/upstream/signing-key.asc
% uscan -ddd
[same result as above]


(btw, you should use both `export-clean,export-minimal`, not just
`export-minimal`).

For you to try I pushed what works for me (once I got to this point, I'm
not sure anymore why I checked branch above…) to a "test-uscan" branch
of s3ql.  In there `uscan -ddd` downloads and verify appropriately.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#971345: WebKitNetworkProcess: random crashes (SIGABRT)

[Paul Wise]

On Tue, 2021-09-28 at 12:06 +0200, Alberto Garcia wrote:

> Let me see if I understood correctly, what happens is that you upgrade
> the webkit packages and then the webkit-based programs that were
> already running start to crash, is that right?

Right, except there is a time delay before the crashes and I don't
think the programs themselves crash, just the WebKitNetworkProcess
subprocesses running under them crash, I'm not sure if the crashing
subprocesses were started before or after the upgrade though. If you
like I can downgrade WebKit and test this again to find out. The
crashes are because WebKitNetworkProcess receives an invalid message
that it did not expect (NetworkProcess_ContinueWillSendRequest).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#995249: virtualbox: VMs hang on start on debian testing (just seeing starting VM window)

[Wagenhuber Peter]

Package: virtualbox
Version: 6.1.26-dfsg-4
Severity: normal
X-Debbugs-Cc: pe...@servus.at

Dear Maintainer,

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

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

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


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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  5.14.0-1
ii  libc6 2.32-4
ii  libcurl3-gnutls   7.74.0-1.3+b1
ii  libdevmapper1.02.12:1.02.175-2.1
ii  libgcc-s1 11.2.0-7
ii  libgl11.3.4-2+b1
ii  libgsoap-2.8.117  2.8.117-2
ii  liblzf1   3.6-3
ii  libopus0  1.3.1-0.1
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.7-2
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libssl1.1 1.1.1l-1
ii  libstdc++611.2.0-7
ii  libvncserver1 0.9.13+dfsg-3
ii  libvpx6   1.10.0-2
ii  libx11-6  2:1.7.2-2+b1
ii  libxcursor1   1:1.2.0-2
ii  libxml2   2.9.12+dfsg-5
ii  libxt61:1.2.0-1
ii  procps2:3.3.17-5
ii  python3   3.9.2-3
ii  python3.9 3.9.7-2
ii  virtualbox-dkms [virtualbox-modules]  6.1.26-dfsg-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages virtualbox recommends:
ii  libqt5core5a5.15.2+dfsg-12
ii  libqt5gui5  5.15.2+dfsg-12
ii  libqt5opengl5   5.15.2+dfsg-12
ii  libqt5widgets5  5.15.2+dfsg-12
ii  libxcb1 1.14-3
ii  libxext62:1.3.4-1
ii  virtualbox-qt   6.1.26-dfsg-4

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  6.1.26-1
execve("/usr/bin/vboxmanage", ["vboxmanage", "startvm", "d11-wg0"], 
0x7ffe3422b780 /* 48 vars */) = 0
brk(NULL)   = 0x55e010141000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=198078, ...}) = 0
mmap(NULL, 198078, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4df3abd000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", 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\0\200\177\2\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1839168, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4df3abb000
mmap(NULL, 1852480, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4df38f6000
mprotect(0x7f4df391c000, 1658880, PROT_NONE) = 0
mmap(0x7f4df391c000, 1347584, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f4df391c000
mmap(0x7f4df3a65000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x16f000) = 0x7f4df3a65000
mmap(0x7f4df3ab1000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7f4df3ab1000
mmap(0x7f4df3ab7000, 13376, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4df3ab7000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4df38f4000
arch_prctl(ARCH_SET_FS, 0x7f4df3abc5c0) = 0
mprotect(0x7f4df3ab1000, 12288, PROT_READ) = 0
mprotect(0x55e00f4c9000, 8192, PROT_READ) = 0
mprotect(0x7f4df3b18000, 4096, PROT_READ) = 0
munmap(0x7f4df3abd000, 198078)  = 0
getuid()= 1000
getgid()= 1000
getpid()= 4411
rt_sigaction(SIGCHLD, {sa_handler=0x55e00f4beae0, sa_mask=~[RTMIN RT_1], 
sa_flags=SA_RESTORER, sa_restorer=0x7f4df3932ef0}, NULL, 8) = 0
geteuid()   = 1000
brk(NULL)   = 0x55e010141000
brk(0x55e010162000) = 0x55e010162000
getppid()   = 4408
stat("/home/peda", 

Bug#995248: umockdev 0.16.3-1 breaks autopkgtest of bolt

[Christian Ehrhardt]

Package: umockdev
Version: 0.16.3-1

Hi,
the new version fails the tests of bolt as seen at
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

That crash seem weird, but it actually is only an effect of a fail
with a mocked directory.
The bolt tests would behave the same way if not mocked at all.
The root cause for this is in this change in 0.16.3
https://github.com/martinpitt/umockdev/commit/5e829601434

That breaks the bolt tests here
https://gitlab.freedesktop.org/bolt/bolt/-/blob/master/tests/mock-sysfs.c#L183

Due to $tmp/sys/bus now already existing the g_mkdir fails and that
breaks the test.

So we either need to stop umockdev from doing that (but that will
re-break whatever it fixed) or we need to teach bolt tests to be ok,
if the directory already exists.
I can't make the call which approach is better, but since Pitti owns
this Debian package and upstream I hope he will see this bug and make
the call where to better fix it.

P.S.
I have started to analyze this in Ubuntu, so there is a related bug
and I'd appreciate a bug ref in the changelog if there is an upload
for this.
=> https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1945321

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#995247: ITP: r-bioc-mofa2 -- Multi-Omics Factor Analysis v2

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-mofa2 -- Multi-Omics Factor Analysis v2
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-mofa2
  Version : 1.2.2+ds
  Upstream Author : Ricard Argelaguet
* URL : https://bioconductor.org/packages/MOFA2/
* License : GPL-2+
  Programming Lang: GNU R
  Description : Multi-Omics Factor Analysis v2
 The MOFA2 package contains a collection of tools for training and
 analysing multi-omic factor analysis (MOFA). MOFA is a probabilistic
 factor model that aims to identify principal axes of variation from data
 sets that can comprise multiple omic layers and/or groups of samples.
 Additional time or space information on the samples can be incorporated
 using the MEFISTO framework, which is part of MOFA2. Downstream analysis
 functions to inspect molecular features underlying each factor,
 vizualisation, imputation etc are available.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-mofa2

Bug#995246: ITP: apfsprogs -- Experimental APFS tools for Linux

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: apfsprogs
  Version : 0+git20210928
  Upstream Authors: Ernesto A. Fernández 


* URL : https://github.com/linux-apfs/apfsprogs
* License : GPL-2-or-later
  Description : Experimental APFS tools for Linux
 This is a suite of userland software to work with the Apple File System 
on
 Linux. For now only mkfs and fsck tools are available, both functional 
but
 lacking in features. Compatibility with the Apple implementations has 
barely

 been tested; please exercise caution.

See for WIP: https://mentors.debian.net/package/apfsprogs/

Bug#995245: google-authenticator: Please update URL of upstream

[Nobuhiro Iwamatsu]

Source: google-authenticator
Version: 20191231-2
Severity: wishlist

Dear Maintainer,

The URL for google-authenticator has been changed.
  
  https://github.com/google/google-authenticator-libpam

Could you update it?

Best regards,
  Nobuhiro

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

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

Bug#995244: rxvt-unicode: confirm-paste considers [] as control chars

[Jakub Wilk]

Package: rxvt-unicode
Version: 9.26-2
Tags: patch

The confirm-paste extension gives me spurious warning when I try to 
paste square brackets:


  Pasting 2 control characters, continue? (y/n)
  []

The attached patch fixes this.

--
Jakub Wilk
--- a/src/perl/confirm-paste
+++ b/src/perl/confirm-paste
@@ -21,7 +21,7 @@ sub msg {
 sub on_tt_paste {
my ($self, $str) = @_;
 
-   my $count = ($str =~ tr/[\x00-\x1f\x80-\x9f]//);
+   my $count = ($str =~ tr/\x00-\x1f\x80-\x9f//);
 
return unless $count;
 

Bug#995238: libdatetime-timezone-perl 2.23-1+2021b flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995238 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.23-1+2021b

Explanation: new upstream stable release; update DST rules for Samoa and 
Jordon; confirmation of no leap second on 2021-12-31

Bug#995237: libdatetime-timezone-perl 2.47-1+2021b flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995237 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.47-1+2021b

Explanation: new upstream stable release; update DST rules for Samoa and 
Jordon; confirmation of no leap second on 2021-12-31