Bug#1019867: ITP: qrterminal -- Display QR Codes in terminal

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: qrterminal
  Version : 3.0.0-1
  Upstream Author : Mark Percival
* URL : https://github.com/mdp/qrterminal
* License : Expat
  Programming Lang: Go
  Description : Display QR Codes in terminal

 A golang library for generating QR codes in the terminal.
 
 Originally this was a port of the NodeJS version. Recently it's been updated
 to allow for smaller code generation using ASCII 'half blocks'

This package will be team maintained by the go team. This is a dependency of
wormhole-william, which is in turn a dependency of termshark 4.2.0

Bug#1019393: hdf5 breaks libsis-jhdf5-java autopkgtest: Could not initialize class

[Steven Robbins]

On Thu, 8 Sep 2022 16:11:33 +0200 Paul Gevers  wrote:

> With a recent upload of hdf5 the autopkgtest of libsis-jhdf5-java fails 
> in testing when that autopkgtest is run with the binary packages of hdf5 
> from unstable. It passes when run with only packages from testing.

I find the same holds for simple BUILDING of the libsis-jhdf5-java source 
package.  The build succeeds when using libhdf5-dev from testing, but fails 
with the  package from  unstable. 

The failure happens when running tests.  Below is output from first test 
failure.

-Steve

FAILED: testCreateVerifyContentArtificialRootRoundtripOK
java.lang.ExceptionInInitializerError
at hdf.hdf5lib.HDF5Constants.(HDF5Constants.java:29)
at 
ch.systemsx.cisd.hdf5.IHDF5WriterConfigurator$FileFormatVersion.(IHDF5WriterConfigurator.java:
74)
at 
ch.systemsx.cisd.hdf5.IHDF5WriterConfigurator$FileFormatVersionBounds.(IHDF5WriterConfigurator.java:
127)
at 
ch.systemsx.cisd.hdf5.h5ar.HDF5Archiver.(HDF5Archiver.java:112)
at 
ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverFactory.open(HDF5ArchiverFactory.java:
41)
at 
ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverTest.testCreateVerifyContentArtificialRootRoundtripOK(HDF5ArchiverTest.java:
330)
at java.base/
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:
104)
at java.base/java.lang.reflect.Method.invoke(Method.java:577)
at 
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:
100)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:646)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:811)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1129)
at 
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:
129)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:
112)
at org.testng.TestRunner.privateRun(TestRunner.java:746)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1264)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1189)
at org.testng.TestNG.runSuites(TestNG.java:1104)
at org.testng.TestNG.run(TestNG.java:1076)
at org.testng.TestNG.privateMain(TestNG.java:1405)
at org.testng.TestNG.main(TestNG.java:1374)
Caused by: java.lang.UnsupportedOperationException: No suitable HDF5 native 
library found for this platform.
at hdf.hdf5lib.H5.loadH5Lib(H5.java:240)
at hdf.hdf5lib.H5.(H5.java:230)
... 28 more

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

Bug#1019866: linux-image-5.18.0-0.deb11.4-amd64: Noise first before actual sound whenever any sound is played

[Sten Heinze]

Package: src:linux
Version: 5.18.16-1~bpo11+1
Severity: normal
X-Debbugs-Cc: sten.hei...@gmx.de

Dear Maintainer,

Since upgrading to this kernel, a noise is played first before any sound 
anytime a sound is starting. After the noise, the actual sounds play just 
fine. 

The problem immediately does away if I switch back to the previous kernel,
linux-image-5.18.0-0.bpo.1-amd64 (5.18.2 instead of the current 5.18.16).
The problem also goes away when using the workaround of disabling the 
pulseaudio suspend-on-idle module described here [1].

Now I can temporalily use the workaround or the previous kernel, however
I'd prefer a fix that still allows for the suspend on idle.

Thanks!


[1] 
https://forum.manjaro.org/t/noise-starting-sound-on-amd-ellesmere-hdmi-audio-radeon-rx-590/117101/6


-- Package-specific info:
** Version:
Linux version 5.18.0-0.deb11.4-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 PREEMPT_DYNAMIC Debian 5.18.16-1~bpo11+1 (2022-08-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.18.0-0.deb11.4-amd64 
root=UUID=0a37c2d3-0cfa-4a80-b172-406cc4b54977 ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: P4.50
board_vendor: ASRock
board_name: B450 Gaming-ITX/ac
board_version: 

** Loaded modules:
ccm
rfcomm
cmac
algif_hash
algif_skcipher
af_alg
intel_rapl_msr
intel_rapl_common
bnep
edac_mce_amd
btusb
iwlmvm
btrtl
kvm_amd
btbcm
btintel
btmtk
kvm
mac80211
binfmt_misc
bluetooth
irqbypass
snd_hda_codec_realtek
ghash_clmulni_intel
snd_hda_codec_generic
ledtrig_audio
libarc4
uvcvideo
snd_hda_codec_hdmi
videobuf2_vmalloc
iwlwifi
videobuf2_memops
nls_ascii
aesni_intel
snd_usb_audio
videobuf2_v4l2
snd_hda_intel
nls_cp437
jitterentropy_rng
videobuf2_common
snd_intel_dspcfg
vfat
snd_intel_sdw_acpi
crypto_simd
fat
snd_hda_codec
snd_usbmidi_lib
videodev
cryptd
sha512_ssse3
snd_rawmidi
sha512_generic
cfg80211
snd_hda_core
snd_seq_device
joydev
mc
ctr
snd_hwdep
snd_pcm
rapl
drbg
wmi_bmof
snd_timer
ansi_cprng
ccp
snd
efi_pstore
pcspkr
sp5100_tco
ecdh_generic
ecc
watchdog
k10temp
soundcore
rng_core
crc16
rfkill
evdev
acpi_cpufreq
nct6775
hwmon_vid
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
btrfs
blake2b_generic
xor
raid6_pq
zstd_compress
libcrc32c
crc32c_generic
hid_logitech_hidpp
hid_logitech_dj
hid_generic
usbhid
hid
amdgpu
gpu_sched
drm_dp_helper
cec
rc_core
drm_ttm_helper
ttm
drm_kms_helper
ahci
libahci
xhci_pci
libata
igb
xhci_hcd
nvme
drm
nvme_core
scsi_mod
usbcore
dca
t10_pi
crc32_pclmul
ptp
crc32c_intel
pps_core
i2c_piix4
crc64_rocksoft
i2c_algo_bit
crc64
crc_t10dif
crct10dif_generic
crct10dif_pclmul
usb_common
scsi_common
crct10dif_common
wmi
gpio_amdpt
gpio_generic
button

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
Root Complex [1022:1480]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root 
Complex [1022:1480]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
GPP Bridge [1022:1483] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- 

Bug#1019865: Hangs and goes to 100% CPU usage on compose

[Nikolai Lusan]

Package: evolution
Version: 3.45.3-2
Severity: grave

After a recent update everytime I open Evolution it successfully checks all my 
IMAP folders,
and CalDAV/CardDAV accounts. However if I try to compose a new message, or 
reply to any message
the evolution proccess amps up to 100% CPU usage and hangs. Even leaving it for 
an extended
period does not allow the problem to resolve itself. 

My suspicion is that it happened in the 3.45.3-1 -> 3.45.3-2 upgrade, so a 
regression _might_
solve the issue. This has not been tested though.


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.0-2
ii  dbus-broker [dbus-system-bus]   32-1
ii  evolution-common3.45.3-2
ii  evolution-data-server   3.45.3-1.2
ii  libc6   2.34-8
ii  libcamel-1.2-64 3.45.3-1.2
ii  libecal-2.0-2   3.45.3-1.2
ii  libedataserver-1.2-27   3.45.3-1.2
ii  libevolution3.45.3-2
ii  libglib2.0-02.73.3-3
ii  libgtk-3-0  3.24.34-3
ii  libical33.0.14-1+b1
ii  libnotify4  0.8.1-1
ii  libxml2 2.9.14+dfsg-1+b1
ii  psmisc  23.5-3

Versions of packages evolution recommends:
ii  evolution-plugin-pstimport 3.45.3-2
ii  evolution-plugin-spamassassin  3.45.3-2
ii  evolution-plugins  3.45.3-2
ii  yelp   42.1-2

Versions of packages evolution suggests:
pn  evolution-ews   
ii  evolution-plugins-experimental  3.45.3-2
ii  gnupg   2.2.39-1
ii  network-manager 1.40.0-1

-- no debconf information

Bug#1019863: opencv.jar: broken symbolic link to opencv4/opencv-454d.jar

[Steve M. Robbins]

Package: libopencv-java
Version: 4.6.0+dfsg-6+b1
Severity: important

This bug makes the build of (unrelated) package libsis-jhdf5-java fail.


$ dpkg --search /usr/share/java/opencv.jar
libopencv-java: /usr/share/java/opencv.jar
$ file /usr/share/java/opencv.jar
/usr/share/java/opencv.jar: broken symbolic link to opencv4/opencv-454d.jar


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libopencv-java depends on:
ii  libopencv406-jni  4.6.0+dfsg-6+b1

libopencv-java recommends no packages.

libopencv-java suggests no packages.

-- no debconf information

Bug#1010665: sbuild-createchroot should not hardcode a default mirror

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Mattias Jernberg (2022-05-06 14:34:22)
> sbuild-createchroot has an optional mirror argument, however if this is not
> provided it has its own hardcoded mirror it uses when calling debootstrap.
> 
> This is unfortunate as debootstrap (and by extension sbuild) will happily work
> with other distributions (such as ubuntu).
> 
> Included is a patch which makes sbuild let debootrap pick the mirror instead.

thanks for the patch! It's now committed to the main branch and will be part of
the next sbuild release.

Just to confirm: you are using sbuild-createchroot to create sbuild chroots for
the default schroot backend, correct?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

On 2022-09-14 19:37:10 +0200, Francesco Poli wrote:
> On Wed, 14 Sep 2022 12:55:26 +0200 Vincent Lefevre wrote:
> [...]
> > On 2022-09-14 12:18:58 +0200, Vincent Lefevre wrote:
> > > It seems that some upgrade broken apt-listbugs. From aptitude:
> > > 
> > > Performing actions...
> > > E: undefined method `default' for "  # returns password\n":String
> > > E: Sub-process /usr/bin/apt-listbugs apt returned an error code (1)
> > > E: Failure running script /usr/bin/apt-listbugs apt
> > 
> > Currently, I cannot reproduce this issue. But perhaps it depends on
> > what the server returns.
> 
> Nor can I...   :-(

It would be interesting to know where this error could come from
in the source.

Concerning the string "  # returns password\n":

zira:~> grep -r -A2 -B3 'returns password' /usr/lib/ruby
/usr/lib/ruby/3.0.0/uri/generic.rb-def password=(password)
/usr/lib/ruby/3.0.0/uri/generic.rb-  check_password(password)
/usr/lib/ruby/3.0.0/uri/generic.rb-  set_password(password)
/usr/lib/ruby/3.0.0/uri/generic.rb:  # returns password
/usr/lib/ruby/3.0.0/uri/generic.rb-end
/usr/lib/ruby/3.0.0/uri/generic.rb-
--
/usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb-def 
password=(password)
/usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb-  
check_password(password)
/usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb-  
set_password(password)
/usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb:  # returns 
password
/usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb-end
/usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb-

The "# returns password" seems to be a comment, and I'm wondering why
one gets an error on a comment. But I don't know Ruby at all...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1019862: libreoffice-kf5: Libreoffice impress problems with libreoffice-kf5

[Bob Wong]

Package: libreoffice-kf5
Version: 1:7.4.1~rc1-3+b1
Severity: normal
X-Debbugs-Cc: ybx...@gmail.com

Dear Maintainer,


When I use libreoffice with libreoffice-kf5, it will give the following errors:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
This plugin supports grabbing the mouse only for popup windows

Also, with kf5 backend, some animations in the impress won't work at all under
wayland.


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

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

Versions of packages libreoffice-kf5 depends on:
ii  kio  5.97.0-1
ii  libc62.34-7
ii  libgcc-s112.2.0-1
ii  libkf5kiofilewidgets55.97.0-1
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5widgets5   5.15.4+dfsg-5
ii  libreoffice-core 1:7.4.1~rc1-3+b1
ii  libreoffice-qt5  1:7.4.1~rc1-3+b1
ii  libstdc++6   12.2.0-1
ii  libuno-cppu3 1:7.4.1~rc1-3+b1
ii  libuno-cppuhelpergcc3-3  1:7.4.1~rc1-3+b1
ii  libuno-sal3  1:7.4.1~rc1-3+b1
ii  uno-libs-private 1:7.4.1~rc1-3+b1

Versions of packages libreoffice-kf5 recommends:
ii  libreoffice-style-breeze  1:7.4.1~rc1-3

libreoffice-kf5 suggests no packages.

-- no debconf information

Bug#1019861: ccp4: New version 8.0 available

[Stefan Brüns]

Package: libccp4
Version: 6.5.1

Directory listing: https://ftp.ccp4.ac.uk/opensource/
Source URL: https://ftp.ccp4.ac.uk/opensource/libccp4-8.0.0.tar.gz

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019

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

Bug#1019860: ITP: ruby-version-gem -- Enhance your VERSION! Sugar for Version modules.

[Ajayi Olatunji O.]

Package: wnpp
Severity: wishlist
Owner: "Ajayi Olatunji O." 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-version-gem
  Version : 1.1.0
  Upstream Author : Peter Boling 
* URL : https://github.com/pboling/version_gem
* License : MIT/X
  Programming Lang: Ruby
  Description : Enhance your VERSION! Sugar for Version modules.

Versions are good. Versions are cool. Versions will win.

 - This package is relevant because it is required as a build dependency
   for updating ruby-oauth2 which is also required for gitlab 15.3.0
 - The package will be uploaded as a team upload for the Ruby team, so that
   anytime gitlab is to be updated it would also be uploaded with the suite
   of other dependencies, the package would be sponsors by any member of the
   Ruby team.

Bug#1014120: libowfat FTBFS: ln: failed to create hard link 'libowfat/buffer.h'

[Bo YU]

Hi,
On Wed, Sep 14, 2022 at 10:50:36PM +0200, Bastian Germann wrote:

I have tried to fix this but as I am not able to reproduce this locally I am at 
a loss here.
Maybe someone else has an idea...


Some days ago I want to fix the issue but can not to reprodule also.
It was the new issue:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017157




--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1019859: ITP: golang-gitlab-jonas.jasas-condchan -- TODO

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gitlab-jonas.jasas-condchan
  Version : 0.0~git20190210.36637ad-1
  Upstream Author : Jonas Jasas
* URL : https://gitlab.com/jonas.jasas/condchan
* License : Expat
  Programming Lang: Go
  Description : Cancellable sync.Cond

 CondChan is a sync.Cond with the ability to wait in select statement.

 - Adds waiting in select statement feature
 - Implements all sync.Cond interface
 - Passes all sync.Cond tests
 - Implemented using channels
 - Just ~37% slower comparing to sync.Cond

This package will be team-maintaned. This is a dependency of termshark

Bug#1019841: amule: Please transition to wxwidgets3.2

[Scott Talbert]

On Wed, 14 Sep 2022, Sandro Tosi wrote:


control: forwarded -1 https://github.com/amule-project/amule/issues/340

Hello Scott,


For most packages, the transition should be as simple as changing
Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some
packages may require small patches; I'm happy to help with those (and
I have some already from working on this transition in Fedora
already).


it looks like an attempt was made in fedora to build amule with 3.2
and quickly reverted (i dont know the details, just what's in the git
repo), see the links in the gh issue (which i think you may want to
subscribe to, if you have a user on gh).

would you be able to have a look at amule and wxwidgets3.2 compatibility?


It seems amule isn't in Fedora proper - it's in RPMFusion, which is why I 
didn't see it in my repoquery.


I seem to recall amule is some sort of P2P client, which I'd rather not 
try to connect to.  Can you try the changes in this pull request?  A few 
users seem to report success with those.


https://github.com/amule-project/amule/pull/168

Thanks,
Scott

Bug#1001022: block 998499 with 1001022, block 998499 with 997310

[dane neely]

Date: Thu, 02 Dec 2021 20:46:34 +0100
>From: Daniel Leidert 
>-
>Body: ur-type{header=Received: (at submit) by bugs.debian.org; 2 Dec 2021 
>19:34:46 +
>From dleid...@debian.org Thu Dec 02 19:34:46 2021
>X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
> (2018-09-13) on buxtehude.debian.org
>X-Spam-Level:
>X-Spam-Status: No, score=-24.5 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
> FOURLA,FROMDEVELOPER,FVGT_m_MULTI_ODD,HAS_PACKAGE,MURPHY_DRUGS_REL8,
> PGPSIGNATURE,SPF_HELO_NONE,SPF_NONE,TXREP,XMAILER_REPORTBUG
> autolearn=ham autolearn_force=no
> version=3.4.2-bugs.debian.org_2005_01_02
>X-Spam-Bayes: score:0. Tokens: new, 87; hammy, 150; neutral, 125; spammy,
> 0. spammytokens: hammytokens:0.000-+--sk:iQIzBAE, 0.000-+--sk:iqizbae,
> 0.000-+--sha512, 0.000-+--SHA512, 0.000-+--H*r:key-exchange
>Return-path: 
>Received: from mail.wgdd.de ([5.39.82.225]:36116)
> by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
> (Exim 4.92)
> (envelope-from )
> id 1msrqv-00075s-Rr
> for sub...@bugs.debian.org; Thu, 02 Dec 2021 19:34:46 +
>Received: from [127.0.1.1] (ip5f5aad27.dynamic.kabel-deutschland.de 
>[95.90.173.39])
> (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
> key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest 
> SHA256)
> (No client certificate requested)
> (Authenticated sender: dleidert)
> by mail.wgdd.de (Postfix) with ESMTPSA id E133A817F0
> for ; Thu, 2 Dec 2021 19:34:41 + (UTC)
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>From: Daniel Leidert 
>To: Debian Bug Tracking System 
>Subject: ruby-pathutil: Not Ruby 3.0 compatible due to kwargs issues
>Message-ID: <163847368027.50071.9447108658119765375.reportbug@vogon>
>X-Mailer: reportbug 11.1.0
>Date: Thu, 02 Dec 2021 20:34:40 +0100
>Delivered-To: sub...@bugs.debian.org

[dane neely - Chat @ 
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=1q7khj)   
[1q7khj]

Bug#1019858: O: tcsh -- TENEX C Shell, an enhanced version of Berkeley csh

[Thomas Lange]

Package: wnpp
Severity: normal

I request an adopter for the tcsh package.
I no longer use tcsh. I'll orphan this package.

-- 
regards Thomas

Bug#1019738: searchandrescue: FTBFS on riscv64: add library search path

[Paul Wise]

On Wed, 2022-09-14 at 21:32 +0800, Sakura286 wrote:

> Simply add library search path to sar/platform.ini and it works.

That means that future Debian porters will have to do the same porting,
it is better to invest a little more time up front to make the package
portable to any architecture instead of adding more hardcoding for a
single architecture that will not be useful to other new architectures.

Looking at the pconf code, I noticed that if you allow environment
variables to be used then it adds LD_LIBRARY_PATH to the library search
path, so if you change the ./configure in debian/rules to this:

   LD_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH) ./configure Linux

Then all the Debian customisations to PlatformSearchPathLib in
sar/platforms.ini can be removed and the package will still build fine.

libc also uses LD_LIBRARY_PATH, but this use is compatible with it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1019778: wxWidgets 3.2 works fine

[tony mancill]

On Wed, Sep 14, 2022 at 07:39:19PM -0400, Rick Murphy wrote:
> TrustedQSL works with wxWidgets 3.2 - this should be a transparent change by
> updating the dependency.

Thank you Rick.  I will get it updated and uploaded soon.

Cheers,
tony KG7IEL


signature.asc
Description: PGP signature

Bug#1019857: fetchmail: Running as root is discouraged / no mailservers have been specified

[T.A. van Roermund]

Package: fetchmail
Version: 6.4.33-1
Severity: normal

Dear Maintainer,

I'm getting the following messages in the syslog:

Sep 15 01:03:21 systemd[1]: Starting LSB: init-Script for system wide fetchmail 
daemon...
Sep 15 01:03:21 fetchmail[2245]: Starting mail retriever agent: fetchmail.
Sep 15 01:03:21 systemd[1]: Started LSB: init-Script for system wide fetchmail 
daemon.
Sep 15 01:03:21 fetchmail[2263]: starting fetchmail 6.4.33 daemon
Sep 15 01:03:25 fetchmail[2310]: fetchmail: WARNING: Running as root is 
discouraged.
Sep 15 01:03:25 fetchmail[2310]: fetchmail: no mailservers have been specified.
Sep 15 01:03:25 systemd[2293]: fetchmail.service: Main process exited, 
code=exited, status=5/NOTINSTALLED
Sep 15 01:03:25 systemd[2293]: fetchmail.service: Failed with result 
'exit-code'.
Sep 15 01:03:25 systemd[2293]: fetchmail.service: Scheduled restart job, 
restart counter is at 1.
Sep 15 01:03:25 fetchmail[2338]: fetchmail: WARNING: Running as root is 
discouraged.
Sep 15 01:03:25 fetchmail[2338]: fetchmail: no mailservers have been specified.
Sep 15 01:03:25 systemd[2293]: fetchmail.service: Main process exited, 
code=exited, status=5/NOTINSTALLED
Sep 15 01:03:25 systemd[2293]: fetchmail.service: Failed with result 
'exit-code'.
Sep 15 01:03:26 systemd[2293]: fetchmail.service: Scheduled restart job, 
restart counter is at 2.
Sep 15 01:03:26 fetchmail[2342]: fetchmail: WARNING: Running as root is 
discouraged.
Sep 15 01:03:26 fetchmail[2342]: fetchmail: no mailservers have been specified.
Sep 15 01:03:26 systemd[2293]: fetchmail.service: Main process exited, 
code=exited, status=5/NOTINSTALLED
Sep 15 01:03:26 systemd[2293]: fetchmail.service: Failed with result 
'exit-code'.
Sep 15 01:03:26 systemd[2293]: fetchmail.service: Scheduled restart job, 
restart counter is at 3.
Sep 15 01:03:26 fetchmail[2343]: fetchmail: WARNING: Running as root is 
discouraged.
Sep 15 01:03:26 fetchmail[2343]: fetchmail: no mailservers have been specified.
Sep 15 01:03:26 systemd[2293]: fetchmail.service: Main process exited, 
code=exited, status=5/NOTINSTALLED
Sep 15 01:03:26 systemd[2293]: fetchmail.service: Failed with result 
'exit-code'.
Sep 15 01:03:27 systemd[2293]: fetchmail.service: Scheduled restart job, 
restart counter is at 4.
Sep 15 01:03:27 fetchmail[2344]: fetchmail: WARNING: Running as root is 
discouraged.
Sep 15 01:03:27 fetchmail[2344]: fetchmail: no mailservers have been specified.
Sep 15 01:03:27 systemd[2293]: fetchmail.service: Main process exited, 
code=exited, status=5/NOTINSTALLED
Sep 15 01:03:27 systemd[2293]: fetchmail.service: Failed with result 
'exit-code'.
Sep 15 01:03:27 systemd[2293]: fetchmail.service: Scheduled restart job, 
restart counter is at 5.
Sep 15 01:03:27 systemd[2293]: fetchmail.service: Start request repeated too 
quickly.
Sep 15 01:03:27 systemd[2293]: fetchmail.service: Failed with result 
'exit-code'.

It seems that this started a few days ago, after upgrading fetchmail from 
version 6.4.32-1 to 6.4.33-1.

However, the fetchmail daemon is running as user fetchmail and not as root:

$ ps aux | grep fetchmail
fetchma+3239  0.0  0.0  13712  7340 ?Ss   01:25   0:00 
/usr/bin/fetchmail -f /etc/fetchmailrc --pidfile 
/var/run/fetchmail/fetchmail.pid --syslog

And the file /etc/fetchmailrc exists and is readable by user fetchmail:

$ dir /etc/fetchmailrc
-rw--- 1 fetchmail root 2.3K Oct 17  2021 /etc/fetchmailrc

Hence, I don't understand why I all of a sudden get these warnings "Running as 
root is discouraged." and "no mailservers have been specified."



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'stable'), 
(400, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
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 fetchmail depends on:
ii  adduser  3.129
ii  debianutils  5.7-0.3
ii  init-system-helpers  1.64
ii  libc62.34-7
ii  libcom-err2  1.46.5-2
ii  libgssapi-krb5-2 1.20-1
ii  libkrb5-31.20-1
ii  libssl3  3.0.5-2
ii  lsb-base 11.2

Versions of packages fetchmail recommends:
ii  ca-certificates  20211016

Versions of packages fetchmail suggests:
ii  exim4-daemon-heavy [mail-transport-agent]  4.96-3
pn  fetchmailconf  
pn  resolvconf 

-- Configuration Files:
/etc/default/fetchmail changed [not included]

-- no debconf information

Bug#1019778: wxWidgets 3.2 works fine

[Rick Murphy]

TrustedQSL works with wxWidgets 3.2 - this should be a transparent 
change by updating the dependency.

Bug#1019856: ITP: golang-github-flytam-filenamify -- Convert a string to a valid safe filename on Golang

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-flytam-filenamify
  Version : 1.1.1-1
  Upstream Author : tanjiahui
* URL : https://github.com/flytam/filenamify
* License : Expat
  Programming Lang: Go
  Description : Convert a string to a valid safe filename

 Converts a string to a valid safe filename.

Package will be team maintained by the go team. A new dependency of termshark
2.4.0

Bug#1019751: The Kerberos Principal should be afs/cellname

[Jeffrey Eric Altman]

When searching for a service principal, aklog will search for principals in 
this order
afs/your-cell-name.com@   referral request sent to the client principal's REALM
afs/your-cell-name.com@REALM
afs@REALM
If afs/your-cell-name.com@REALM does not exist, there will be a negative lookup 
and the cost of the extra round trips.  

"afs@REALM" should not be used for a new cell.  That name made sense when there 
was a one-to-one mapping between cell and realm due to the existence of 
"kaserver".  

The preference for afs/your-cell-name.com@REALM over afs@REALM has been present 
in OpenAFS since the MIT AFS-Kerberos 5 Migration Kit was merged in November 
2004.

OpenAFS 1.4.0 was the first release which integrated Kerberos v5 support.





smime.p7s
Description: S/MIME cryptographic signature

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[debian-bug-report]

Package: libc6
Version: 2.31-13+deb11u4
Severity: critical

Dear Maintainer,

After an upgrade to version +deb11u4 on my system running Haswell
(4th gen Intel Core) CPU, most of the programs including bash or dpkg
are immediately crashing with SIGILL. The problem seems to be caused/
related to AVX2 and changes made to some functions utilizing this 
instruction set. I don't know much about Debian bug reporting, so 
forgive me any mistakes I've made.

The issue is on both host, LXC and Docker.
I have described more on this link:
https://github.com/debuerreotype/docker-debian-artifacts/issues/175
where I also linked my coredump from example program and described stuff 
more thoroughly.


Coredump link directly just in case: 
https://github.com/debuerreotype/docker-debian-artifacts/files/9569748/core.bash.10.2663c40e671041e6b40c882a70b83c3f.1480736.166318582400.zip


Also log lines from kernel:
kernel: [834669.721253] traps: dpkg[1455373] trap invalid opcode 
ip:7fa39701951d sp:7ffc4ad26e58 error:0 in libc-2.31.so[7fa396edd000+15a000]
kernel: [834669.732958] traps: dpkg[1455374] trap invalid opcode 
ip:7f529ca9551d sp:7fffb6f0a238 error:0 in libc-2.31.so[7f529c959000+15a000]
kernel: [834669.840128] traps: dpkg[1455375] trap invalid opcode 
ip:7f1874cc951d sp:7fffc2c2f5d8 error:0 in libc-2.31.so[7f1874b8d000+15a000]
kernel: [834669.907918] traps: dpkg[1455378] trap invalid opcode 
ip:7f3b4f8d851d sp:7fff3ec970f8 error:0 in libc-2.31.so[7f3b4f79c000+15a000]
kernel: [834712.152139] traps: passwd[1455693] trap invalid opcode 
ip:7fefee4b52b7 sp:7cb506b8 error:0 in libc-2.31.so[7fefee37d000+15a000]


Not sure what exactly might be causing the issue, but if these changes 
aren't pulled, potentially anyone with this or similar CPU as me will 
upgrade and end up with bricked system.
I will proceed to try using `clearcpuid=293` kernel flag myself, but 
consider how many distros depend on Debian, live CDs etc, with people 
unable to figure out why their system became useless, unable to trace 
the source, and blaming it just on Linux...


I'm filling this bug report from my downgraded host system to the 
previous libc6 version.


   * What led up to the situation? apt upgrade...
   * What exactly did you do (or not do) that was effective (or
 ineffective)? downgrade to +deb11u3
   * What was the outcome of this action? everything works on the older 
version

   * What outcome did you expect instead?


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.15.39-1-pve (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.18-4
ii  libgcc-s1  10.2.1-6

Versions of packages libc6 recommends:
ii  libidn2-0   2.3.0-5
pn  libnss-nis  
pn  libnss-nisplus  

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.77
pn  glibc-doc  
ii  libc-l10n  2.31-13+deb11u3
ii  locales2.31-13+deb11u3

-- debconf information:
  glibc/disable-screensaver:
  glibc/restart-services:
  glibc/kernel-not-supported:
  glibc/kernel-too-old:
  libraries/restart-without-asking: false
  glibc/restart-failed:
  glibc/upgrade: true

Bug#1019854: firmware-nonfree: Please consider to update this package and its binaries

[Zhian Chen]

Package: firmware-nonfree
Version: 20210818-1
Severity: wishlist
X-Debbugs-Cc: tansuanyinliao8...@gmail.com

Dear Maintainer,

After I install nonfree firmware I notice that firmware missing warnings
appeared (for intel iwlwifi). I search the missing firmwares and find them in
Linux kernel firmware tree.

As these missing firmwares aims to provide basic functionality for hardwares, I
think it's important to keep this package in pace with linux kernel nonfree
firmware collections, or at least At least not too far behind the upstream.

Please consider to make an update to this package and its binaries. Thank you.


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1019853: gucharmap: New upstream version 15

[Jeremy Bicha]

Source: gucharmap
Version: 1:14.0.3-1
Severity: wishlist
Control: block -1 by 1019852

There is a new gucharmap release for Unicode 15. This is waiting for
unicode-data 15 to be packaged for Debian.

Thank you,
Jeremy Bicha

Bug#1019852: unicode-data: Please update for the new 15 release

[Jeremy Bicha]

Source: unicode-data
Version: 14.0.0-1.1
Severity: wishlist

Unicode 15 has just been released. Please package the new version.

https://unicode.org/versions/Unicode15.0.0/

I believe this needs a minor transition with node-unicode and
gucharmap. I will update gucharmap once unicode-data 15 reaches
Unstable.

Thank you,
Jeremy Bicha

Bug#1019851: lintian: init.d-script-needs-depends-on-lsb-base is obsolete + wrong

[Adam Borowski]

Package: lintian
Version: 2.115.3
Severity: normal

Hi!
The tag init.d-script-needs-depends-on-lsb-base has been redundant for
quite a while, as lsb-base was transitively essential.  Now it's even more
redundant, as the package is no more (it was an implementation detail of
the init script boilerplate that cost us 55KB of metadata).

Removing the dependency from individual packages would be the usual
clean-up that tends to linger for 20 years and no one cares -- but it
turned out that debootstrap doesn't understand Provides.  Thus, we
had to bring back a dummy package that costs us all the required files:
 * changelog
 * copyright
 * dpkg/info/.list
 * dpkg/info/.md5sums
 * 20 lines in dpkg/status
 * ~1KB of cruft + uncompressible hashes in apt indices

Of course, shaving a bit off the minimal install isn't _that_ important,
but as only 3(?) packages get installed by debootstrap, I'd still want
to drop that by Bookworm.

And for that purpose, I'd prefer to not annoy maintainers by lintian
warnings, make them add overrides, and otherwise waste time.

Thus: please drop this tag soon.

Then you could add a reverse tag, lsb-base-depends-is-obsolete, but
that's an aforemented 20 years cleanup that has no urgency.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-rc5-00016-g0b0aebee76ce (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.38.90.20220713-2
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.39-1
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-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.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.122-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1
ii  libsereal-encoder-perl  5.001+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.12-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.84+ds-1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.10.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian 

Bug#1019566: r-cran-poorman: typo in package description

[Jakub Wilk]

* Jakub Wilk , 2022-09-12 13:04:

there's another one:

sependency → dependency


This one is still not fixed.

--
Jakub Wilk

Bug#1019850: kshutdown: [INTL:pt] Updated Portuguese translation - prog messages

[Américo Monteiro]

Package: kshutdown
Version: 4.2-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for  kshutdown's messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


kshutdown_4.2-1_pt.po.gz
Description: application/gzip

Bug#1019849: python3-virtualenv: Please do not depend on python3-pip

[Benjamin Moody]

Package: python3-virtualenv
Version: 20.4.0+ds-2+deb11u1
Severity: normal

Dear Maintainer,

In older versions of Debian, python-virtualenv and python3-virtualenv
did not depend on the python-pip or python3-pip packages (only
python-pip-whl).

It is convenient to be able to install and use virtualenv *without*
having /usr/bin/pip and /usr/bin/pip3 installed, so that one does not
accidentally install stuff into ~/.local/lib while intending to use a
virtualenv prefix.

(I don't know of any reason a user would ever want to invoke the
/usr/bin/pip binary in connection with using virtualenv.)

It's not apparent why this dependency was added, since
python3-virtualenv now depends on *both* python3-pip and
python-pip-whl.  And the basic functionality, at least, of
/usr/bin/virtualenv works correctly after forcibly removing the
python3-pip package.

So please remove this dependency, or downgrade to a Suggests at best.

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

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

Versions of packages python3-virtualenv depends on:
ii  python-pip-whl  20.3.4-4+deb11u1
ii  python3 3.9.2-3
ii  python3-appdirs 1.4.4-1
ii  python3-distlib 0.3.2+really+0.3.1-0.1
ii  python3-distutils   3.9.2-1
ii  python3-filelock3.0.12-2
ii  python3-importlib-metadata  1.6.0-2
ii  python3-pip 20.3.4-4+deb11u1
ii  python3-pkg-resources   52.0.0-4
ii  python3-six 1.16.0-2

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- debconf-show failed

Bug#1019593: hp-plugin: Failure to download plugin

[Brian Potkin]

On Wed 14 Sep 2022 at 21:04:41 +0200, martin f krafft wrote:

> Thanks Brian for your quick response. Yeah, it's cool that I can use 
> the printer for driverless printing, but unfortunately, the scanning 
> functionality still requires the plugin.

On unstable libsane1 installs the recommended sane-airscan. This
gives driverless scanning, which is supported by your deice. Color
me perplexed! Please give

 scanimage -L
 airscan-discover

> It is also true that the issue seems to be in code downloaded 
> on-the-fly from upstream, so you're right in closing the bug.

Coincidentally; another two reports:

 https://bugs.launchpad.net/hplip/+bug/1989508
 https://bugs.launchpad.net/hplip/+bug/1989592

Cheers,

Brian.

Bug#1019848: mupdf: insecure use of /var/tmp

[Jakub Wilk]

Package: mupdf
Version: 1.20.3+ds1-1
Tags: security

mupdf opens predictably-named files in /var/tmp/.
Local users can exploit it for denial of service, maybe worse.

Proof of concept:

  $ mkfifo -m 644 
/var/tmp/usr%share%doc%debian-history%docs%project-history.en.epub.accel

  $ mupdf /usr/share/doc/debian-history/docs/project-history.en.epub
  [hangs forever]


-- System Information:
Architecture: i386

Versions of packages mupdf depends on:
ii  freeglut32.8.1-6
ii  libc62.34-8
ii  libfreetype6 2.12.1+dfsg-3
ii  libgl1   1.5.0-1
ii  libgumbo10.10.1+dfsg-4
ii  libharfbuzz0b2.7.4-1+b1
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.2-1
ii  libmujs2 1.2.0-3
ii  libopenjp2-7 2.5.0-1
ii  libssl3  3.0.5-2
ii  libx11-6 2:1.8.1-2
ii  libxext6 2:1.3.4-1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages mupdf suggests:
ii  mupdf-tools  1.20.3+ds1-1

--
Jakub Wilk

Bug#662718: cpio: LowNMU 2.13+dfsg-7.1

[Bastian Germann]

I have NMUed a fixed version to DELAYED/3.
The debdiff is attached.diff -Nru cpio-2.13+dfsg/debian/changelog cpio-2.13+dfsg/debian/changelog
--- cpio-2.13+dfsg/debian/changelog 2021-08-22 07:21:53.0 +0200
+++ cpio-2.13+dfsg/debian/changelog 2022-09-14 21:45:55.0 +0200
@@ -1,3 +1,12 @@
+cpio (2.13+dfsg-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Suggest libarchive-dev (Closes: #662718).
+  * d/copyright: Convert to machine-readable format.
+  * Fix CRC with new ASCII format when file > 2GB (Closes: #962188).
+
+ -- Bastian Germann   Wed, 14 Sep 2022 21:45:55 +0200
+
 cpio (2.13+dfsg-7) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff -Nru cpio-2.13+dfsg/debian/control cpio-2.13+dfsg/debian/control
--- cpio-2.13+dfsg/debian/control   2020-02-01 14:11:00.0 +0100
+++ cpio-2.13+dfsg/debian/control   2022-09-14 21:45:55.0 +0200
@@ -17,7 +17,7 @@
 Replaces: cpio-mt
 Conflicts: mt-st (<< 0.6), cpio-mt
 Multi-Arch: foreign
-Suggests: libarchive1
+Suggests: libarchive-dev
 Description: GNU cpio -- a program to manage archives of files
  GNU cpio is a tool for creating and extracting archives, or copying
  files from one place to another.  It handles a number of cpio formats
diff -Nru cpio-2.13+dfsg/debian/copyright cpio-2.13+dfsg/debian/copyright
--- cpio-2.13+dfsg/debian/copyright 2020-02-01 14:11:00.0 +0100
+++ cpio-2.13+dfsg/debian/copyright 2022-09-14 21:45:55.0 +0200
@@ -1,16 +1,39 @@
-This is the Debian GNU/Linux prepackaged version of GNU cpio
-(including mt).
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This is the Debian GNU/Linux prepackaged version of GNU cpio
+ (including mt).
+ .
+ This package was put together by Clint Adams .
+Source: ftp://ftp.gnu.org/gnu/cpio
 
-This package was put together by Clint Adams ,
-from sources obtained from ftp://ftp.gnu.org:/gnu/cpio
+Files: *
+Copyright: (C) 1984-2019 Free Software Foundation, Inc.
+License: GPL-3+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3, or (at your option)
+ any later version.
+Comment:
+ The text of the GPL version 3 can be found on Debian systems in
+ /usr/share/common-licenses/GPL-3.
 
-GNU cpio is Copyright (C) 1990, 1991, 1992, 2001, 2003, 2004, 2005,
-2006, 2007 Free Software Foundation, Inc.
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-The text of the GPL can be found on Debian systems in
-/usr/share/common-licenses/GPL-3 .
+Files: tests/argcv.*
+   src/tar.h
+Copyright: (C) 1992-2017 Free Software Foundation, Inc.
+License: LGPL-3+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 3 of the License, or (at your option) any later version.
+ .
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ Lesser General Public License for more details.
+ .
+ You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301  USA
+Comment:
+ The text of the LGPL version 3 can be found on Debian systems in
+ /usr/share/common-licenses/LGPL-3.
diff -Nru cpio-2.13+dfsg/debian/patches/series 
cpio-2.13+dfsg/debian/patches/series
--- cpio-2.13+dfsg/debian/patches/series2021-08-22 07:21:27.0 
+0200
+++ cpio-2.13+dfsg/debian/patches/series2022-09-14 21:45:55.0 
+0200
@@ -1,6 +1,7 @@
 695717-no-cpio.info-2.patch
 fix.win32-compat.patch
 autoreconf.patch
+Wrong-CRC-with-ASCII-CRC-for-large-files.patch
 fix.better.handle.device.nodes.cramfs.565474.patch
 fix.fatal.exits.mt.576637.patch
 fix.other.bugs.patch
diff -Nru 
cpio-2.13+dfsg/debian/patches/Wrong-CRC-with-ASCII-CRC-for-large-files.patch 
cpio-2.13+dfsg/debian/patches/Wrong-CRC-with-ASCII-CRC-for-large-files.patch
--- 
cpio-2.13+dfsg/debian/patches/Wrong-CRC-with-ASCII-CRC-for-large-files.patch
1970-01-01 01:00:00.0 +0100
+++ 
cpio-2.13+dfsg/debian/patches/Wrong-CRC-with-ASCII-CRC-for-large-files.patch
2022-09-14 21:45:55.0 +0200
@@ -0,0 +1,34 @@
+From: Stefano Babic 
+Date: Fri, 28 Jul 2017 13:20:52 +0200
+Subject: Wrong CRC with ASCII CRC for large files
+
+Due to signedness, the checksum is not computed when filesize is bigger
+a 2GB.
+
+Signed-off-by: Stefano Babic 
+---
+ src/copyout.c | 8 
+ 1 file changed, 4 

Bug#1014813: reverse dependencies

[Utkarsh Gupta]

Control: tags -1 - moreinfo

Hi Thorsten,

I've addressed the issue at hand and src:redmine/5.0.2-2 is in good
shape now. Can you please process the removal of
ruby-deckar01-task-list so that ruby-task-list and redmine can migrate
to testing? TIA! \o/


- u

Bug#1019846: Backports for borgmatic?

[Iustin Pop]

Source: borgmatic
Version: 1.6.3-1
Severity: wishlist

Hi,

While borg has backports, I don't see any for borgmatic. But looking at
the release history for it (borgmatic), I can see some new features that
I think are worth having in stable (as a backport), e.g.:

- 1.5.15 with 425: Run arbitrary Borg commands with new "borgmatic borg"
  action (greatly simplifies interacting with repositories, IMO).
- 1.5.23 with #394: Compact repository segments and free space with new
  "borgmatic compact" action. Borg 1.2+ only. Also run "compact" by
  default when no actions are specified, as "prune" in Borg 1.2 no
  longer frees up space unless "compact" is run. (borg 1.2 is in
  backports, and without this, space will leak)
- 1.6.2 with #523: Reduce the default consistency check frequency and
  support configuring the frequency independently for each check

Now, I see upstream as very active and not sure what the policy for
backports should be (one-off? continuous update? etc.), but I think it
would be good to have some consistency between borg's backports policy
and borgmatic's. It might be that if borg 2.0 gets into sid and then via
backports into bullseye, borgmatic in bullseye will completely stop
working with it.

thanks!
iustin

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

Kernel: Linux 5.15.61-teal0 (SMP w/24 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1019347: Please package new upstream which includes the fix

[Iustin Pop]

>From what I see, upstream version 1.7.1 fixes this
(https://github.com/borgmatic-collective/borgmatic/releases/tag/1.7.1):

#574: Fix for potential data loss (data not getting backed up) when the 
"patterns" option was
used with "source_directories" (or the "~/.borgmatic" path existed, which got 
injected into
"source_directories" implicitly). The fix is for borgmatic to convert 
"source_directories" into
patterns whenever "patterns" is used, working around a potential Borg bug:
borgbackup/borg#6994

Could you please package that (or the newer 1.7.2) to work around this?

thanks!
iustin

Bug#1014120: libowfat FTBFS: ln: failed to create hard link 'libowfat/buffer.h'

[Bastian Germann]

I have tried to fix this but as I am not able to reproduce this locally I am at 
a loss here.
Maybe someone else has an idea...

Bug#1018102: idle detection failure

[Antoine Beaupré]

Oh and I found more information about this in the arch wiki:

https://wiki.archlinux.org/title/Session_lock#xss-lock

That seems to say that this command is supposed to trigger a lock:

loginctl lock-session

and it does *not* work here. Does it work for you?

It seems the `xset s` mechanism i am using is the "DPMS" hook. They do
have a note there:

> Note: When using xss-lock with DPMS, you will have to blank the screen
> yourself. It will not be triggered when looking at videos.

It is not exactly to me what that means ("blank the screen
yourself"??). But it does hint that something else (a video player i
guess?) will prevent screen locking, which begs the question of what
qualifies as a video player. Maybe if i have a video player playing
somewhere that I didn't know about? I did have a tab opened on some
youtube thing earlier, but i tried closing that tab (and indeed, all of
firefox in fact) and that didn't do it.

It would sure be nice if one could tell wth is preventing this thing
from sending locking signals. :)

I also found out on that wiki that you can use systemd to send those
signals:

https://wiki.archlinux.org/title/Session_lock#Inactivity

... but considering that loginctl lock-session doesn't work in the first
place, i wonder how this could work at all anyways... maybe worth a try?
-- 
Freedom is being able to make decisions that affect mainly you. Power
is being able to make decisions that affect others more than you. If
we confuse power with freedom, we will fail to uphold real freedom.
- Richard Stallman

Bug#1018102: idle detection failure

[Antoine Beaupré]

On 2022-09-04 07:57:11, Ian Campbell wrote:
> On Thu, 2022-08-25 at 13:27 -0400, Antoine Beaupre wrote:
>> I have xss-lock setup to start xsecurelock automatically after the
>> delay prescribed by my `xset` configuration.
>
> FWIW I've never seen it used with xsecurelock (I use i3lock) but I do
> `xset b off` in my session (but not the `s 60 3` thing you do) and
> autolocking does work for me as expected -- although in practice mostly
> lock via a key binding as I walk away, but if I forget it does lock
> itself.

Hmm... `xset b off` just turns off the bell, it doesn't touch the screen
saver at all.. how does that relate?

>> I wonder if I'm missing a key service in my session, or how to debug
>> the screensaver in Xorg
>
> I'm afraid I don't know about any of this sort stuff, I just package
> the tool as a user.

Gotcha. :)

> As you say `xset s activate` works I'm inclined to suggest the issue is
> elsewhere in the stack. But here are some random thoughts nonetheless:
>
> You pass --verbose but I assume the journald output for xss-
> lock.service has nothing of use?

So interestingly, today, I reproduced this on another workstation which
I didn't expect would have this problem. Here's the journal of that
service since last boot:

sep 14 08:42:59 emma systemd[2011]: Started xss-lock - use external locker as X 
screen saver.
sep 14 08:56:51 emma xss-lock[2115]: notifier exited abnormally: Le processus 
fils a été tué par le signal 15
sep 14 13:24:54 emma xss-lock[2115]: notifier exited abnormally: Le processus 
fils a été tué par le signal 15
sep 14 13:32:21 emma xss-lock[2115]: notifier exited abnormally: Le processus 
fils a été tué par le signal 15

I'm not sure what those errors are about, but when I returned to the
computer just now, the screen was unlocked.

> You could switch xsecurelock out for a wrapper which logs and then
> forwards to the real thing, at least then you would know if it was
> being called at all.

I am pretty confident xsecurelock is not being called at all.

> Have you compared the process lists on the working and non-working
> systems, that might give a hint about a missing process/service in your
> session.

I have not, since now the working machine is actually broken so it's
hard for me to access that information (i'd need to restore from
backups)...

> Perhaps also look for anything which is inhibiting screenlock, e.g. a
> "Presentation Mode" setting? I think this is logind related
> functionality so perhaps there is a way to query the underlying setting
> via that? In the past I've seen these options having different setting
> for mains power vs battery, which could explain a laptop vs desktop
> difference.

Yeah, so that's definitely an interesting avenue. I looked at loginctl
and it says my session is "active":

anarcat@emma:~$ loginctl session-status  | grep State
   State: active
anarcat@emma:~$ loginctl user-status  | grep State
   State: active

I am not sure if that's what we're looking for.

I have tried xprintidle:

https://github.com/g0hl1n/xprintidle

So I did this:

xset s 5 3
watch xprintidle

I can see the idle counter incrementing past 5 seconds, and the screen
doesn't lock. 

I have also tried to replace xsecurelock with this wrapper, and can
confirm it never gets called (the echo doesn't show up and the stamp
file is not created):

#!/bin/sh

echo "callling xsecurelock"
touch $XDG_RUNTIME_DIR/xsecurelock.stamp

exec xsecurelock

So there is one of two things happening:

 1. xprintidle believes Xorg is idle while it is really not
 2. xorg is not telling xss-lock about idleness for some reason

I am not sure I believe 1. And I don't know how to debug 2.

Happy to test more ideas. :)

-- 
Be who you are and say what you feel
Because those who mind don't matter
And those who matter don't mind.
 - Dr. Seuss

Bug#893834: [cpio] Empty man page

[Bastian Germann]

Control: tags -1 wontfix
Control: notfound -1 2.11+dfsg-5ubuntu1

This is Debian, not Ubuntu. So the bug is invalid.

Bug#1019845: transition: glibc 2.35

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gl...@lists.debian.org

Dear release team,

I would like to get a transition slot for glibc 2.35. It has been
available in experimental for one month and does not have any known
major issue. It has been built successfully on all release architectures
and many ports architectures. A few issues found through the autopkgtest
pseudo excuses for experimental have been fixed. The remaining ones are
due to britney bugs, broken autopkgtest or packages parts of the
transition.

As glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition. Here is the corresponding ben file:

  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#1019554: Stamp files are not updated

[Helge Kreutzmann]

Hello Lance,
On Tue, Sep 13, 2022 at 12:22:07PM +, Lance Lin wrote:
> Thank you for your report. I'm happy to work on this.

Thank you very much, this is highly appreciated.

> > So cron.weekly is now overdue and cron.daily did not get touched since
> > the 5th, consistent with the update of the package.
> > 
> 
> > Cron itself works, cron.hourly (which is not managed by anacron)
> > works.
> > 
> 
> > I'm continuing to investigate, but I'm inclined to raise the severity.
> 
> Can you check to see if the anacron service is running? Richard Newton replied
> in the thread and said the service was not running after the upgrade and it 
> worked
> after manually starting it.

helge@twentytwo:~$ ps aux | grep ana
helge   6448  0.0  0.0   7036  2272 tty4 S+   22:08   0:00 grep ana

root@twentytwo:~# systemctl status anacron.service
◈ anacron.service - Run anacron jobs
 Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: 
enabled)
 Active: inactive (dead)
   Docs: man:anacron
 man:anacrontab

> The change I made was very small, adding 'TimeoutStopSec=infinity' to the 
> service
> based on an improvement that a user provided. I don't think this caused the 
> issue
> you are seeing.
> 
> I was able to verify that if I manually start the service, the 
> cron.weekly/cron.daily
> are updated with the current time. The upgrade went fine on my end but I 
> would like 
> 
> to track this down.
> 
> Perhaps the issue is that the service was already running when the upgrade 
> happens 
> 
> that the "new" service doesn't start? If so, I could add a preinst script to 
> stop
> the anacron service if it is running.

Do you want me to try out something else, or should I now try to start it?

Btw., this machine is rebooted daily (i.e. only runs a few hours a day), so I 
would have expected that after the next reboot anacron would come up …

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1019844: golang-v2ray-core FTBFS: undefined: quic.Session

[Adrian Bunk]

Source: golang-v2ray-core
Version: 4.34.0-7
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=golang-v2ray-core=4.34.0-7%2Bb1

...
# v2ray.com/core/app/dns
src/v2ray.com/core/app/dns/nameserver_quic.go:41:19: undefined: quic.Session
src/v2ray.com/core/app/dns/nameserver_quic.go:319:22: undefined: quic.Session
src/v2ray.com/core/app/dns/nameserver_quic.go:328:45: undefined: quic.Session
src/v2ray.com/core/app/dns/nameserver_quic.go:329:19: undefined: quic.Session
src/v2ray.com/core/app/dns/nameserver_quic.go:362:46: undefined: quic.Session
...
make[1]: *** [debian/rules:31: override_dh_auto_build] Error 25

Bug#1019549: fetchmail: can't accept options while a background fetchmail is running.

[Helge Kreutzmann]

Hello László,
On Tue, Sep 13, 2022 at 08:05:50PM +0200, László Böszörményi (GCS) wrote:
> Control: tags -1 +moreinfo
> 
> Hi,
> 
> On Sun, Sep 11, 2022 at 9:42 PM Helge Kreutzmann  wrote:
> > Since upgrading I get the error message:
> > fetchmail: can't accept options while a background fetchmail is running.
> > argc = 3, arg list:
> > arg 1 = "-a"
> > arg 2 = "-s"
> >
> > This also happens when called on the command line.
> >
> > However, fetchmail is not intended to run in the background, expecially:
> >
> > # cat /etc/default/fetchmail
> > …
> > # Declare here if we want to start fetchmail. 'yes' or 'no'
> > START_DAEMON=no
>  Yes, this is for the initscripts.

Ok, but this is not clear and it used to work until very recently.

> > But somehow it is in the background:
> > helge   2994  0.0  0.0  13984  8216 ?Ss   20:07   0:00 
> > fetchmail --nodetach --daemon 300
>  I think it is started by systemd. What do you get when issuing the
> following commands?
> $ systemctl --user status fetchmail.service

• fetchmail.service - Fetchmail Daemon
 Loaded: loaded (/usr/lib/systemd/user/fetchmail.service; enabled; preset: 
enabled)
 Active: active (running) since Wed 2022-09-14 21:46:46 CEST; 15min ago
   Docs: man:fetchmail(1)
   Main PID: 2926 (fetchmail)
  Tasks: 1 (limit: 37643)
 Memory: 1.6M
CPU: 24ms
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/app.slice/fetchmail.service
 └─2926 fetchmail --nodetach --daemon 300

Sep 14 21:46:46 twentytwo fetchmail[2926]: fetchmail: starting fetchmail 6.4.33 
daemon
Sep 14 21:46:46 twentytwo systemd[2910]: Started Fetchmail Daemon.


> $ systemctl --user disable fetchmail.service

// No response

> $ systemctl --user stop fetchmail.service

// No response

> # systemctl --global disable fetchmail

Removed "/etc/systemd/user/default.target.wants/fetchmail.service".

> (Please be aware the last command is run as root.)
> 
> > In the system logs (from boot until now) I get lots of errors:
>  This means the service is indeed installed and is in use.

I checked it and mail was still received.

> After executing the commands above, run your "fetchmail -a -s" again
> and see how it goes now.

Now this works as expected, i.e. no error output.

> Sorry for the inconvenience,

No problem, this is what testing is for, to find the bugs before
stable users encounter them.

So I suppose when "START_DAEMON=no" then the above commands need to 
be issued in the postinst? 

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1019843: php-mysqlnd-ms FTBFS: PHP_DEFAULT_VERSION cannot be empty

[Adrian Bunk]

Source: php-mysqlnd-ms
Version: 1.6.0+svn333622-12
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/php-mysqlnd-ms.html

...
 fakeroot debian/rules clean
PHP_DEFAULT_VERSION_DEFAULT := "8.1"
PHP_DEFAULT_VERSION_OVERRIDE := "5.6"
AVAILABLE_PHP_VERSIONS := "8.1"
/usr/share/dh-php/pkg-pecl.mk:39: *** PHP_DEFAULT_VERSION cannot be empty.  
Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2

Bug#1019425: dkms 3.0.6-2 not signing modules

[Holger Schröder]

The patch does not work for me. The modules are signed again with the
patch but at boot time they are not accepted and I end up at the
initramfs prompt. zfs module not loaded in my case.


Cheers

Bug#1019816: raft: FTBFS on hppa - testsuite fails

[John David Anglin]

Source: raft
Version: 0.15.0-1
Severity: normal
Tags: patch

Dear Maintainer,

The follow two tests fail on hppa:
FAIL: test/integration/uv
FAIL: test/unit/core

See: 
https://buildd.debian.org/status/fetch.php?pkg=raft=hppa=0.15.0-1=1661714018=0

The test/unit/core test fails because test_compress.c fails to allocate
357198848 bytes.

This is fixed by adding hppa to the list of 32-bit architectures in the
Lower-mipsel_malloc.patch patch.

The test/integration/uv fails because of bad addresses in the io_submit
system call:
 src/uv_append.c:197 - write: io_submit: bad address in system call argument
Error: test/integration/test_uv_append.c:630: assertion failed: status == 
result->status (18 == 0)
Error: child killed by signal 6 (Aborted)
append/nonBlockingBarrierLongBlockingTask   [ ERROR ]

The Debian hppa architecture is 32-bit big endian. One can see the problem
with strace:
[pid 27905] io_submit(0xf5854000, 1, [{aio_data=0x2913c0, 
aio_lio_opcode=IOCB_CMD_PWRITEV, aio_fildes=13, aio_buf=0x291590, 
aio_nbytes=1, aio_offset=0}]) = -1 EFAULT (Bad address)

The aio_data and aio_buf arguments are passed incorrectly for a 32-bit
big-endian architecture. The attached hppa-uv_writer.patch patch fixes
the and the testsuite now runs without fails.

See: 
https://buildd.debian.org/status/fetch.php?pkg=raft=hppa=0.15.0-1=1663183915=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
merged-usr: no
Architecture: hppa (parisc64)

Kernel: Linux 5.19.8+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Description: Lower malloc() size for mipsel
 For unknown reason this is nearly the max mipsel can malloc()
Author: Laszlo Boszormenyi (GCS) 
Forwarded: no
Last-Update: 2022-04-24

---

Index: raft-0.15.0/test/unit/test_compress.c
===
--- raft-0.15.0.orig/test/unit/test_compress.c
+++ raft-0.15.0/test/unit/test_compress.c
@@ -128,7 +128,10 @@ TEST(Compress, compressDecompressRandomO
 }
 
 static char* len_nonrandom_one_params[] = {
-#if !defined(__LP64__) && (defined(__arm__) || defined(__i386__) || 
defined(__mips__))
+#if defined(__MIPSEL__)
+/* mipsel has lower malloc limits */
+  "4096", "65536", "4194304", "1073741824", "1427483000",
+#elif !defined(__LP64__) && (defined(__arm__) || defined(__hppa__) || 
defined(__i386__) || defined(__mips__))
 /*4KB 64KB 4MB1GB   INT_MAX (larger allocations 
fail on 32-bit archs */
   "4096", "65536", "4194304", "1073741824", "2147483647",
 #else
Index: raft-0.15.0/src/uv_writer.c
===
--- raft-0.15.0.orig/src/uv_writer.c
+++ raft-0.15.0/src/uv_writer.c
@@ -463,10 +463,18 @@ int UvWriterSubmit(struct UvWriter *w,
 req->iocb.aio_fildes = (uint32_t)w->fd;
 req->iocb.aio_lio_opcode = IOCB_CMD_PWRITEV;
 req->iocb.aio_reqprio = 0;
+#if defined(__hppa__)
+req->iocb.aio_buf = (uintptr_t)bufs;
+#else
 *((void **)(>iocb.aio_buf)) = (void *)bufs;
+#endif
 req->iocb.aio_nbytes = n;
 req->iocb.aio_offset = (int64_t)offset;
+#if defined(__hppa__)
+req->iocb.aio_data = (uintptr_t)req;
+#else
 *((void **)(>iocb.aio_data)) = (void *)req;
+#endif
 
 #if defined(RWF_HIPRI)
 /* High priority request, if possible */

Bug#1019761: expat: CVE-2022-40674

[Salvatore Bonaccorso]

Source: expat
Version: 2.4.8-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libexpat/libexpat/pull/629
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for expat.

CVE-2022-40674[0]:
| libexpat before 2.4.9 has a use-after-free in the doContent function
| in xmlparse.c.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-40674
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40674
[1] https://github.com/libexpat/libexpat/pull/629
[2] https://github.com/libexpat/libexpat/pull/640

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#795495: new upstream non-microsoft github version available

[Jeffrey Cliff]

https://git.freecumextremist.com/themusicgod1/ex_doc is a non-NSA/Microsoft
github repo/fork for this project

Jeff Cliff
-- 

End the campaign to Cancel Richard Stallman - go to stallmansupport.org !

Bug#1019760: TypeError: Descriptors cannot not be created directly

[Graham Cobb]

Package: mitmproxy
Version: 6.0.2-1
Severity: normal

I had just started using mitmproxy: it was installed and working.

Independently, I upgraded my Debian Testing system to the latest version
and now, when I try to run mitmproxy, I get the following errors:

Traceback (most recent call last):
  File "/usr/bin/mitmproxy", line 33, in 
sys.exit(load_entry_point('mitmproxy==6.0.2', 'console_scripts', 
'mitmproxy')())
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/main.py", line 142, in 
mitmproxy
from mitmproxy.tools import console
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/console/__init__.py", 
line 1, in 
from mitmproxy.tools.console import master
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/console/master.py", line 
18, in 
from mitmproxy import addons
  File "/usr/lib/python3/dist-packages/mitmproxy/addons/__init__.py", line 6, 
in 
from mitmproxy.addons import clientplayback
  File "/usr/lib/python3/dist-packages/mitmproxy/addons/clientplayback.py", 
line 14, in 
from mitmproxy import io
  File "/usr/lib/python3/dist-packages/mitmproxy/io/__init__.py", line 2, in 

from .db import DBHandler
  File "/usr/lib/python3/dist-packages/mitmproxy/io/db.py", line 4, in 
from mitmproxy.io import protobuf
  File "/usr/lib/python3/dist-packages/mitmproxy/io/protobuf.py", line 12, in 

from mitmproxy.io.proto import http_pb2
  File "/usr/lib/python3/dist-packages/mitmproxy/io/proto/http_pb2.py", line 
35, in 
_descriptor.FieldDescriptor(
  File 
"/home/cobb/.local/lib/python3.10/site-packages/google/protobuf/descriptor.py", 
line 560, in __new__
_message.Message._CheckCalledFromGeneratedFile()
TypeError: Descriptors cannot not be created directly.
If this call came from a _pb2.py file, your generated code is out of date and 
must be regenerated with protoc >= 3.19.0.
If you cannot immediately regenerate your protos, some other possible 
workarounds are:
 1. Downgrade the protobuf package to 3.20.x or lower.
 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use 
pure-Python parsing and will be much slower).


Using PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python allows mitmproxy to run.

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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.21.9
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-4.1
ii  python3   3.10.6-1
ii  python3-asgiref   3.5.0-1
ii  python3-blinker   1.4+dfsg1-0.5
ii  python3-brotli1.0.9-2+b4
ii  python3-certifi   2022.6.15-2
ii  python3-click 8.0.3-1
ii  python3-cryptography  3.4.8-2
ii  python3-flask 2.0.3-1
ii  python3-h24.1.0-3
ii  python3-hyperframe6.0.0-1
ii  python3-kaitaistruct  0.9-1
ii  python3-ldap3 2.9.1-1
ii  python3-msgpack   1.0.3-1+b1
ii  python3-openssl   21.0.0-1
ii  python3-passlib   1.7.4-1
ii  python3-pkg-resources 59.6.0-1.2
ii  python3-protobuf  3.12.4-1+b4
ii  python3-publicsuffix2 2.20191221-3
ii  python3-pyasn10.4.8-2
ii  python3-pyparsing 3.0.7-2
ii  python3-pyperclip 1.8.2-2
ii  python3-ruamel.yaml   0.17.16-1
ii  python3-sortedcontainers  2.4.0-2
ii  python3-tornado   6.2.0-1
ii  python3-urwid 2.1.2-2+b2
ii  python3-wsproto   1.1.0-1

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- debconf-show failed

Bug#1019758: python-xarray: new autopkgtest regression on s390x

[Graham Inggs]

Control: tags -1 + patch

Please consider applying the attached patch.
Description: Allow test_indexes to pass on big-endian systems
Forwarded: https://github.com/pydata/xarray/pull/7026
Bug-Debian: https://bugs.debian.org/1019758
Author: Graham Inggs 
Last-Update: 2022-09-11

--- a/xarray/tests/test_indexes.py
+++ b/xarray/tests/test_indexes.py
@@ -264,13 +264,13 @@
 actual = index1.join(index2)
 print(actual.index)
 assert actual.equals(expected)
-assert actual.coord_dtype == " None:
 index1 = PandasIndex([0, 1, 2], "x")
@@ -380,7 +380,7 @@
 pd_midx = pd.MultiIndex.from_product(
 [[0, 1, 2], ["a", "b"]], names=("foo", "bar")
 )
-level_coords_dtype = {"foo": np.int32, "bar": "

Bug#1019758: python-xarray: new autopkgtest regression on s390x

[Graham Inggs]

Source: python-xarray
Version:  2022.06.0-1
Severity: serious
Forwarded: https://github.com/pydata/xarray/pull/7026
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of python-xarray 2022.06.0-1, some new failing tests
appeared on the big-endian s390x architecture [1].  I've copied what I
hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-xarray/testing/s390x/


=== FAILURES ===
__ TestPandasIndex.test_join ___

self = 

def test_join(self) -> None:
index1 = PandasIndex(["a", "aa", "aaa"], "x", coord_dtype="   assert actual.coord_dtype == "U4') == 'U4') = .coord_dtype

/usr/lib/python3/dist-packages/xarray/tests/test_indexes.py:267: AssertionError
- Captured stdout call -
Index(['aa', 'aaa'], dtype='object', name='x')
___ TestPandasMultiIndex.test_concat ___

self = 

def test_concat(self) -> None:
pd_midx = pd.MultiIndex.from_product(
[[0, 1, 2], ["a", "b"]], names=("foo", "bar")
)
level_coords_dtype = {"foo": np.int32, "bar": "   assert actual.level_coords_dtype == expected.level_coords_dtype
E   AssertionError: assert {'bar': dtype...type('int32')} ==
{'bar': '}
E Omitting 1 identical items, use -vv to show
E Differing items:
E {'bar': dtype('>U1')} != {'bar': '}
E + {'bar': dtype('>U1'), 'foo': dtype('int32')}

/usr/lib/python3/dist-packages/xarray/tests/test_indexes.py:395: AssertionError
 TestPandasMultiIndex.test_join 

self = 

def test_join(self):
midx = pd.MultiIndex.from_product([["a", "aa"], [1, 2]],
names=("one", "two"))
level_coords_dtype = {"one": "   assert actual.level_coords_dtype == level_coords_dtype
E   AssertionError: assert {'one': dtype...type('int32')} ==
{'one': 'U2')} != {'one': 'U2'), 'two': dtype('int32')}

/usr/lib/python3/dist-packages/xarray/tests/test_indexes.py:493: AssertionError

Bug#1019593: hp-plugin: Failure to download plugin

[martin f krafft]

Thanks Brian for your quick response. Yeah, it's cool that I can use 
the printer for driverless printing, but unfortunately, the scanning 
functionality still requires the plugin.

It is also true that the issue seems to be in code downloaded 
on-the-fly from upstream, so you're right in closing the bug.

It's a real shame that HP still require proprietary code, and have 
such shit Linux support.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1019757: perl: Subroutine JSON::PP::Boolean::(-- redefined with 5.36

[Niko Tyni]

Package: perl
Version: 5.36.0-2
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition
Forwarded: https://github.com/Perl/perl5/issues/20246
X-Debbugs-Cc: libmetacpan-client-p...@packages.debian.org
Control: affects -1 libmetacpan-client-perl
Control: block 1019353 with -1

This warns with Perl >= 5.36:

  % perl -we 'use Cpanel::JSON::XS (); use JSON::PP'
  Subroutine JSON::PP::Boolean::(0+ redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  Subroutine JSON::PP::Boolean::(++ redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  Subroutine JSON::PP::Boolean::(-- redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.

I have filed https://github.com/makamaka/JSON-PP/issues/76 against
JSON::PP about this, but it's currently unclear if it should rather be
"fixed" on the Perl side ( https://github.com/Perl/perl5/issues/20246 ).

The immediate impact is that (at least) libmetacpan-client-perl now
fails its autopkgtest checks because of the warning, as seen at

  
https://ci.debian.net/data/autopkgtest/unstable/amd64/libm/libmetacpan-client-perl/26050668/log.gz

  #   Failed test ' /usr/bin/perl -w -M"MetaCPAN::Client" -e 1 2>&1 produced no 
(non-whitelisted) output'
  #   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110.
  # Structures begin differing at:
  #  $got->[0] = 'Subroutine JSON::PP::Boolean::(-- redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  # '
  # $expected->[0] = Does not exist

and verified manually:

  % perl -we 'use MetaCPAN::Client'
  Subroutine JSON::PP::Boolean::(0+ redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  Subroutine JSON::PP::Boolean::(-- redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  Subroutine JSON::PP::Boolean::(++ redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.


This didn't happen in my earlier tests with 5.36 so the failure is
probably rather sensitive to changes in the dependency chain.

Not sure yet what to do about this but it doesn't feel like it should
be a hard blocker for the Perl 5.36 transition. Adding the metadata for
now anyway so we don't forget about it.
-- 
Niko Tyni   nt...@debian.org

Bug#1019756: RFP: elixir-gettext -- Internationalization and localization support for Elixir

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: elixir-gettext
  Version : 0.15.0.1
  Upstream Author : Plataformatec
* URL : https://git.freecumextremist.com/themusicgod1/gettext/
* License : Apache
  Programming Lang: Elixir
  Description : Internationalization and localization support for Elixir

Gettext is a internationalization (i18n) and localization (l10n) system
commonly used for writing multilingual programs, originally from the GNU
Translation Project. Gettext is a standard for i18n in different
communities, meaning there is a great set of tooling for developers and
translators.

This project is an implementation of the Gettext system in Elixir.
This project has also been evacuated from NSA/Microsoft Github.

It is currently a prerequisite for pleroma / rebased ( #895050 )

Bug#895050: 'rebased' fork

[Jeffrey Cliff]

there are now two main forks of this project, one of which is the 'pleroma'
gitlab link above the other which is 'rebased'
https://gitlab.com/soapbox-pub/rebased

Jeff Cliff
-- 

End the campaign to Cancel Richard Stallman - go to stallmansupport.org !

Bug#1019755: dunst: Please package new upstream release 1.9.0

[Boyuan Yang]

Source: dunst
Version: 1.8.1-1
Severity: normal
Tags: sid
X-Debbugs-CC: ni...@tsipinakis.com

Dear Debian dunst package maintainer,

According to https://github.com/dunst-project/dunst/releases , a new release
1.9.0 is now available. Please consider packaging latest upstream version.
If you need any help in packaging such as technical issues or sponsorship
needs, please feel free to let me know. Thanks!

Best,
Boyuan Yang


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

Bug#1019754: icon and title incorrect in GNOME Shell list of running applications

[Sébastien Villemot]

Package: free42-nologo
Version: 3.0.14+ds-1
Severity: normal
Tags: patch

Dear Maintainer,

When I run free42-nologo inside GNOME Shell, the icon and title of the
application are not properly set in the list of running applications (displayed
when pressing “Alt-Tab”). A generic icon is displayed instead and the title is
set to the name of the executable (either “free42dec” or “free42bin”).

The reason for this bug is that the application ID used when initializing GTK+
does not match the name of .desktop file.

I attach a patch that fixes this issue.

Note that I’m unsure about whether this patch should be forwarded upstream,
since .desktop files are Debian-specific, and upstream may not care about
freedesktop.org compliance.

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org
--- a/gtk/shell_main.cc
+++ b/gtk/shell_main.cc
@@ -189,8 +189,10 @@ static void gif_writer(const char *text,
 
 #ifdef BCD_MATH
 #define TITLE "Free42 Decimal"
+#define APPID "com.thomasokken.Free42dec"
 #else
 #define TITLE "Free42 Binary"
+#define APPID "com.thomasokken.Free42bin"
 #endif
 
 static const char *mainWindowXml =
@@ -373,7 +375,7 @@ int main(int argc, char *argv[]) {
 
 GtkApplication *app;
 int status;
-app = gtk_application_new("com.thomasokken.free42", 
G_APPLICATION_FLAGS_NONE);
+app = gtk_application_new(APPID, G_APPLICATION_FLAGS_NONE);
 g_signal_connect(app, "activate", G_CALLBACK(activate), NULL);
 status = g_application_run(G_APPLICATION(app), 0, NULL);
 g_object_unref(app);

Bug#1019753: py-libzfs: Pushing from Experimental into Sid?

[Boyuan Yang]

Source: py-libzfs
Version: 0.0+git20220621.a99d1db-1
Severity: normal
X-Debbugs-CC: will...@grzy.org pkg-zfsonlinux-de...@alioth-lists.debian.net

Dear Debian py-libzfs package maintainer,

I noticed that py-libzfs [1][2] entered Debian experimental in section
contrib back in 2019. There hasn't been much activity since then. I am
wondering if there is any reason of not releasing this software into Sid, or
if we should do so before Debian 12 freeze and release.

Thanks,
Boyuan Yang


[1] https://tracker.debian.org/pkg/py-libzfs
[2] https://github.com/truenas/py-libzfs


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

Bug#1019752: libpcre3-udeb: Can this be dropped?

[Bastian Germann]

Package: libpcre3-udeb
Severity: wishlist
Version: 2:8.39-14
Tags: d-i
Control: block -1 by 1019724

grep 3.8-1 has switched to pcre2. If I am not mistaken, grep is the last 
reverse dependency of libpcre3-udeb.
When the new grep version has migrated to bookworm, please ask the installer 
team if it is okay to drop libpcre3-udeb.

Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck

[Vagrant Cascadian]

On 2022-09-14, Philip Hands wrote:
> Vagrant Cascadian  writes:
>
>>> but also
>>> (given that the tests will have passed during the normal build) the tests
>>> failing during the varied build seems unlikely to be identifying faults 
>>> that are
>>> worth fixing, and so is just a waste of cycles.
>>
>> How do you know weather the bugs it is identifying are worth fixing? It
>> could also identify non-deterministic failures, or failures triggered by
>> specific build environment configurations...
>
> The point is that if the package is reproducible, then the fact that its
> tests fail when run in a weird environment (that may never be found in
> the wild) seems rather likely to be finding errors in the tests rather
> than errors in the program that gets shipped.

Fair point! 

> Of course, if the package is not reproducible, the tests may well fail
> because the package ends up containing new bugs that are only present in
> the variant-built package, but then its also going to show up as
> non-reproducible, so does that really make a difference?

True, though it may make things harder to verify reproducibility in
practice, especially if it is a fairly "normal" variation that triggers
the issue...


It is a balancing act...

I guess I'd be fine with the defaults to go either way, but it would be
important to be able to enable or disable however this gets implemented.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1018915: v4l-utils: FTBFS with libbpf 1.0.0

[Sean Young]

Hi Gregor,

On Wed, Sep 07, 2022 at 02:53:49PM +0200, Gregor Jasny wrote:
> Hello Sudip,
> 
> thanks for the report.
> 
> On 02.09.22 01:19, Sudip Mukherjee wrote:
> > Package: v4l-utils
> > Version: 1.22.1-4
> > Severity: important
> > Tags: ftbfs
> > X-Debbugs-Cc: sudipm.mukher...@gmail.com
> > Usertags: libbpf1
> > 
> > Dear Maintainer,
> > 
> > v4l-utils FTBFS with libbpf 1.0.0 (available in experimental).
> > This is the first error from the build log:
> > 
> > bpf_load.c: In function 'load_and_attach':
> > bpf_load.c:66:38: error: storage size of 'load_attr' isn't known
> > 66 | struct bpf_load_program_attr load_attr;
> >|  ^
> > bpf_load.c:69:38: error: invalid application of 'sizeof' to incomplete type 
> > 'struct bpf_load_program_attr'
> > 69 | memset(_attr, 0, sizeof(struct 
> > bpf_load_program_attr));
> >|  ^~
> > bpf_load.c:78:14: warning: implicit declaration of function 
> > 'bpf_load_program_xattr' [-Wimplicit-function-declaration]
> > 78 | fd = bpf_load_program_xattr(_attr, bpf_log_buf, 
> > LOG_BUF_SIZE);
> >|  ^~
> > bpf_load.c:66:38: warning: unused variable 'load_attr' [-Wunused-variable]
> > 66 | struct bpf_load_program_attr load_attr;
> >|  ^
> > bpf_load.c: In function 'build_raw_map':
> > bpf_load.c:113:14: warning: implicit declaration of function 
> > 'bpf_create_map_node' [-Wimplicit-function-declaration]
> >113 | fd = bpf_create_map_node(map->def.type,
> >|  ^~~
> > bpf_load.c: In function 'load_maps':
> > bpf_load.c:179:47: warning: implicit declaration of function 
> > 'bpf_create_map_in_map_node' [-Wimplicit-function-declaration]
> >179 | bpf_file->map_fd[i] = 
> > bpf_create_map_in_map_node(
> >|   
> > ^~
> > 
> 
> Sean, would you be able to port the existing code to libbpf 1.0? I noticed
> that the current code already triggers deprecation warnings with libbpf
> 0.8.0.

This needs porting, I'll add it to my todo list.

Having said that, I am working on an entirely new tooling in rust but this
is not near completion yet: https://github.com/seanyoung/cir


Sean

Bug#1019750: btrbk: Remote backup with earlier versions broken by change in readlink command syntax

[Graham Cobb]

Package: btrbk
Version: 0.32.4-1
Severity: minor

I have been using btrbk for centralised backups of many remote
machines for a long time.

The latest release of btrbk changes the 'readlink' command sent
to remote machines. Previously it seems the command was:

readlink -v -e /mnt/a/b

Now it is:

readlink -v -e '/mnt/a/b'

The addition of the single quotes breaks the checks in
some, but not all, older versions of
/usr/share/btrbk/scripts/ssh_filter_btrbk.sh.

I assume the quotes are for a good reason, so I think a NEWS
message should be added to warn installers that this security
change will not interoperate with some (but not all) older releases.

It appears that a workround is to copy the new version of
/usr/share/btrbk/scripts/ssh_filter_btrbk.sh to the same place in
any affected remote systems, if they cannot be upgraded to
the new release.

NOTE: I have not attempted to exhaustively test that the latest
ssh_filter_btrbk.sh works completely on the old systems. But it
does fix the problem at least for interoperation between btrbk 0.32.4-1
and btrbk 0.31.3-1.


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

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

Versions of packages btrbk depends on:
ii  btrfs-progs  5.18.1-1
ii  perl 5.34.0-5

Versions of packages btrbk recommends:
ii  mbuffer 20220418+ds1-1
ii  openssh-client  1:9.0p1-1+b1

Versions of packages btrbk suggests:
ii  openssl  3.0.4-2
ii  python3  3.10.4-1+b1

-- no debconf information

Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck

[Philip Hands]

Vagrant Cascadian  writes:

>> but also
>> (given that the tests will have passed during the normal build) the tests
>> failing during the varied build seems unlikely to be identifying faults that 
>> are
>> worth fixing, and so is just a waste of cycles.
>
> How do you know weather the bugs it is identifying are worth fixing? It
> could also identify non-deterministic failures, or failures triggered by
> specific build environment configurations...

The point is that if the package is reproducible, then the fact that its
tests fail when run in a weird environment (that may never be found in
the wild) seems rather likely to be finding errors in the tests rather
than errors in the program that gets shipped.

Even if busybox's du really does have a bug where it miscounts the sizes
of files when run under the fileordering variation, I'm not sure that
breaking the ability to confirm that the package is reproducible is
justified in order to find that bug.

I'm afraid I've not yet managed to work out what's behind the
mis-counting, but my first guess is that it's more likely to be
something in the fuse system presenting the data than in du's counting
of it.

Of course, if the package is not reproducible, the tests may well fail
because the package ends up containing new bugs that are only present in
the variant-built package, but then its also going to show up as
non-reproducible, so does that really make a difference?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Christoph Martin]

Am 14.09.22 um 17:53 schrieb Bastian Germann:


I would like to help here at least to get the package up to speed.
I started with some bug triaging.

Antonio, would you please add me (salsa user bage) as owner of the group?
Or add me and make Christoph an owner. When that is done I will hand in 
some changes.


I just uploaded another version with some mainly cosmetic bug fixes.

My plan was to next package 3.15.6 which is the latest version in the 
3.15 LTS line. This update should work without many changes.


Next step would than be upgrade to 3.18 LTS.

Some of the bugs might have been fixed by upstream in one of the recent 
versions.


A good step would be to use the systemd units instead of the selfmade 
init.d script (#950432) and use the FHS options instead of patching the 
paths (#873699)


Christoph


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019740: libreoffice: Please package the qt6 VCL plugin

[Rene Engelhard]

Hi,

just discussed this on IRC. For reference:

17:38 < _rene_> michaelweghorn: ping?
17:38 < michaelweghorn> _rene_: pong
17:38 -!- mw_web [~mw_web@2001:a61:2596:c001:f128:ccdb:acb1:1a03] has 
joined #libreoffice-dev
17:38 < _rene_> michaelweghorn: I of course know about that plugin and 
actually even fixed the build once ;-)
17:38 < _rene_> michaelweghorn: the question was whether it has a 
stability compared to qt5 ;)
17:39 < _rene_> michaelweghorn: and: is there something 
desktop-detecor'ish actually using it?
17:39 < _rene_> michaelweghorn: users usually don't know about 
SAL_USE_VCLPLUGIN...

17:39 < _rene_> (also sent per mail  now for recording in the bug log)
17:40 < _rene_> michaelweghorn: ideally reply there :)
17:42 -!- hellsworth [~hellswort@209.136.66.6] has joined #libreoffice-dev
17:42 < michaelweghorn> _rene_: from my developer experience, I'm 
currently not aware of anything that's broken in qt6, but not qt5 VCL 
plugin,
17:42 < michaelweghorn>  except video playback on Wayland (tdf#145735), 
which is due to there no longer being a qt6 gstreamer plugin

17:43 < _rene_> so people will complain about that...
17:43 < michaelweghorn> _rene_: and platform integration (theme) isn't 
as nice, since I think there's no qt6 platform theme as of now, same 
with qtcreator
17:43 < _rene_> but I consider videos and audios in presentations a bug 
in the presentation anyway
17:44 < michaelweghorn> _rene_: nothing uses qt6 by default 
(desktop-detection) and I wouldn't replace qt5/kf5 as of now, but only 
package qt6 as optional alternative
17:44 < _rene_> sure, that will we a given anyway due to the qt6 
dependencies and we need qt5 for kf5
17:44 < _rene_> so why would we want it then if users won't actually get 
the effects?
17:45 < michaelweghorn> _rene_: but if you think that should wait until 
qt5/qt6 can be replaced, I'd probably rather wait for a qt6/kf6-based 
plasma desktop after all
17:45 < _rene_> as said, most people will just install it and notice no 
effect at all

17:45 < _rene_> or some other qt6 thingy
17:45 < _rene_> doesn't need to be plasma :)
17:46 < _rene_> trying to decide whether the adding make sense AND 
warrants a unknown waiting time in NEW
17:46 < michaelweghorn> _rene_: I don't have a strong opinion on whether 
it makes sense to package qt6 in debian right now, fine with any 
decision on that

17:47 < _rene_> ok
17:47 < _rene_> ok with me sending this conversation into the bug for 
reference?
17:47 < michaelweghorn> _rene_: my main motivation to file 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019740 was timur's 
question in


https://bugs.documentfoundation.org/show_bug.cgi?id=145734#c2
17:47 < IZBot> bug 145734: LibreOffice-LibreOffice normal/medium NEW 
[META] Qt6 VCL plugin bugs and enhancements
17:48 -!- htietze 
[~h...@p200300d60f0129003587351e4b9d6368.dip0.t-ipconnect.de] has quit 
[Quit: Konversation terminated!]

17:48 < _rene_> yeah, read that
17:48 < _rene_> but he's a user knowing that that and SAL_USE_VCLPLUGIN 
exists
17:49 < michaelweghorn> _rene_: sure, I'm fine with that conversation 
ending up in the bug report, thanks for taking care of that :)
17:50 < michaelweghorn> _rene_: as mentioned, my idea for now was just 
to have it optionally for people who know what they're doing and it 
wouldn't affect others at all
17:50 < michaelweghorn> _rene_: but I don't have any hard feelings 
either way
17:51 < _rene_> will think about it. maybe only for 7.5.x where waiting 
in NEW is not a big deal

17:52 < michaelweghorn> _rene_: sounds fine for me :)
17:52 < _rene_> (aka not in the next Debian release)
17:52 < _rene_> that one will definitely has 7.4.x (7.4.4 most probably)

Regards,

Rene

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Bastian Germann]

Control: owner -1 b...@debian.org
Control: retitle -1 ITA: cfengine3 -- configures network machines

Am 14.09.22 um 12:09 schrieb Christoph Martin:

I joined the team some years ago to help fix some bugs.
But I don't want to do it alone.
So help preferably as patches or pull requests are welcome.


I would like to help here at least to get the package up to speed.
I started with some bug triaging.

Antonio, would you please add me (salsa user bage) as owner of the group?
Or add me and make Christoph an owner. When that is done I will hand in some 
changes.

Bug#1019740: libreoffice: Please package the qt6 VCL plugin

[Rene Engelhard]

Hi,

Am 14.09.22 um 15:49 schrieb Michael Weghorn:

a Qt 6 based UI variant (VCL plugin) was added to LibreOffice in this commit:
https://git.libreoffice.org/core/commit/88d57cf241209ffec9eaed3e523942ab51af6db6


I know :)

The qt6 VCL plugin was never mentioned in the official LO release notes, 
since

it was initially mostly meant to be used for own experimenting before making it
official, but at least from my (developer's) experience, I haven't run into any
issues that are specific to the qt6 VCL plugin (as compared to the qt5/kf5 one)
for a while when used together with recent versions of Qt 6.


Yes, that was the question.


Now the question stil ls: is this useful? Will anytning 
desktop-dection'ish use it? Or do people actually need to set 
SAL_USE_VCLPLUGIN=qt6? (which users don't know about)



Regards,


Rene

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Santiago Ruano Rincón]

Hi Jochen,

El 14/09/22 a las 15:16, Jochen Sprickerhof escribió:
> Hi Santiago,
> 
> * Santiago Ruano Rincón  [2022-09-14 10:36]:
> > > this causes build failures:
> > > 
> > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/libtool.html
> > > 
> > > and also autopkgtest failures:
> > > 
> > > https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dpkg/26032114/log.gz
> > > https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cjet/26041201/log.gz
> > > 
> > > The first autopkgtest failure is in libtool which is vendored by a lot
> > > of packages so will probably take a long time to fix.
> > > 
> > 
> > Fixing this would require fixing libtool only, isn't that right?
> 
> I don't think so, as it is in a lot of packages:
> 
> https://codesearch.debian.net/search?q=Configured+with%3A%22+%7C+%24GREP+%22+%5C-L
> 
> (Note that the buggy libtool.m4 is included into configure.)

Yeah, sorry. I lately realised not all the packages would autoreconf
during building time.

So silencing these warnings would make sense.

> 
> > > P.S.: I will send a bug with a patch to the libtool maintainer.
> > 
> > Please do.
> 
> Done as #1019725.
> 
> > P.S. I am letting Severity: serious for now to prevent migration to
> > testing. But *I* am considering this rather Severity: important, at
> > most.
> 
> Note that the release team issued a block for now:
> 
> https://release.debian.org/britney/hints/jcristau
> 
> and proposed to test with a archive rebuild before introducing it again.

ACK.

Dear Release Team, just to be sure of being on the same page: if you are
proposing to rebuild the whole archive, should I wait before silencing
the warnings, for being able to (mass-)bug filing?

Thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1019749: linux autopkg tests fail with stderr output, blocking gcc-11

[Matthias Klose]

Package: src:linux
Version: 5.19.6-1
Severity: serious
Tags: sid bookworm

linux autopkg tests fail with stderr output, blocking gcc-11

[...]
E: Unexpected warning/error messages
autopkgtest [14:13:45]:  summary
selftestsSKIP Test restriction "isolation-machine" requires testbed 
capability "isolation-machine"
selftestsSKIP Test restriction "isolation-machine" requires testbed 
capability "isolation-machine"

python   PASS (superficial)
kbuild   FAIL stderr: E: Unexpected warning/error messages

Bug#1019579: raku-json-unmarshal: trying to overwrite '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package rak

[Dominique Dumont]

On Monday, 12 September 2022 16:21:45 CEST Adrian Bunk wrote:
> ...
> Unpacking raku-json-unmarshal (0.10-1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-Kxnez1/92-raku-json-unmarshal_0.10-1_arm64.deb
> (--unpack): trying to overwrite
> '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/
> C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package
> raku-json-marshal 0.0.23-1 ...
> 

ok. I don't' really understand what's going on with these precompiled files.

I've asked for help upstream.

Thanks for the heads-up

All the best.

Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck

[Vagrant Cascadian]

On 2022-09-14, Philip Hands wrote:
> I suggest adding a 'nocheck' variation, that sets DEB_BUILD_OPTIONS=nocheck
> during the build,

Sounds reasonable!

> and enabling it by default.

Less sure...

> The reason for doing so is that one could imagine that a package produces
> differing results depending upon whether the tests were run or not

Indeed!

> but also
> (given that the tests will have passed during the normal build) the tests
> failing during the varied build seems unlikely to be identifying faults that 
> are
> worth fixing, and so is just a waste of cycles.

How do you know weather the bugs it is identifying are worth fixing? It
could also identify non-deterministic failures, or failures triggered by
specific build environment configurations...

> This idea is prompted by `busybox` where the tests fail in the varied 
> scenario,
> despite the fact that the package is reproducible.

> Here they are failing:
>
>   https://salsa.debian.org/installer-team/busybox/-/jobs/3227197
>
>   (among other things, du produces weird results when the `fileordering`
>variation is active, claiming the 1MB directoy is 2MB so the tests fail, so
>the varied package is not produced, so we don't get to see that it was
>reproducible:
>
> https://salsa.debian.org/installer-team/busybox/-/blob/master/testsuite/du/du-m-works
>)

Consistantly? Then, maybe the test needs to be improved?


> I found a couple of ways of making the issue go away:
>
>   1) disabling the 'fileordering' variation, thus:
>
> 
> https://salsa.debian.org/installer-team/busybox/-/commit/17387890c73388e1f56a6ae9fbc79783095b4e86
>
> https://salsa.debian.org/installer-team/busybox/-/jobs/3233259
>
>   2) telling the package to skip the tests when doing the variations:
>
> 
> https://salsa.debian.org/installer-team/busybox/-/commit/5260442e8ceea220fa36bdda169978d15108f781
>
> which is setting this in the salsa-ci.yml:
>   SALSA_CI_REPROTEST_ARGS: 
> --variations=environment.variables+=DEB_BUILD_OPTIONS=nocheck
>
> https://salsa.debian.org/installer-team/busybox/-/jobs/3235476
>
>
> Option 2) is what I'm suggesting making into a default variation.
>
> If nothing else it will speed up testing of packages with extensive test 
> suits.

I think it's a valuable feature, but I'm not entirely sure weather it
should be default or not...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1019717: Display of an SVG file broken due to gsfonts transition

[Bob Friesenhahn]

On Tue, 13 Sep 2022, Russ Allbery wrote:

X-Debbugs-Cc: r...@debian.org

Attempting to display an SVG file breaks due to a missing font file:

% gm display _static/spawning.svg
gm display: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb) 
[No such file or directory].

(The image in question was created via the Python seqdiag package, which
is packaged in Debian as python3-seqdiag, although I am using it directly
from PyPI via a virtualenv.)

This is presumably due to the transition from gsfonts to fonts-urw-base35
recently discussed on debian-devel:

https://lists.debian.org/debian-devel/2022/08/msg00263.html

I'm not sure precisely what has to change in GraphicsMagick to use the
new package, though.


The path to the fonts may be configured via the --with-gs-font-dir 
configure option.


The configure script does check /usr/share/fonts/type1/gsfonts but 
perhaps the path has been overridden, or the fonts-urw-base35 package 
was not installed when the configure script was executed, or there is 
a bug.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Bug#1019423: libreoffice-impress: starting by double click from dolphin results in 1 pixel wide window

[MAG4 Piemonte]

Dear Rene, we can confirm the bug upgrading to version 7.4.1~rc1-3 in testing. 
May be is related to https://bugs.documentfoundation.org/show_bug.cgi?
id=150856
Regards!

Guido

Bug#1019748: error: package "encoding/binary" without types was imported

[Vignesh Raman]

Source: golang-github-klauspost-compress
Version: 1.15.4+ds1-1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: vignesh.ra...@collabora.com

Dear Maintainer,

When building golang-github-klauspost-compress with golang-1.18 the below error 
is seen,

src/github.com/klauspost/compress/zstd/blockdec.go
stringer: internal error: package "encoding/binary" without types was imported 
from "github.com/klauspost/compress/zstd"

Please could you look into this. Thanks.

Regards,
Vignesh

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

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

Bug#1019747: flask-limiter: build with sphinx enum_tools

[Emanuele Rocca]

Source: flask-limiter
Version: 2.6.2-1
Severity: wishlist

Flask-limiter 2.6.2 uses the enum_tools sphinx extension. As the
extension is not in Debian yet, I've added a patch to flask-limiter to
build without it, debian/patches/no_enum_tools.patch.

Once sphinx-enum-tools will be in the archive, the patch should be
dropped and the extension added as a build dependency.

The sphinx-enum-tools WNPP bug is https://bugs.debian.org/1019745

Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck

[Holger Levsen]

Hi Phil,

On Wed, Sep 14, 2022 at 04:00:04PM +0200, Philip Hands wrote:
> I suggest adding a 'nocheck' variation, that sets DEB_BUILD_OPTIONS=nocheck
> during the build, and enabling it by default.
[...]
> Option 2) is what I'm suggesting making into a default variation.
[...]
> If nothing else it will speed up testing of packages with extensive test 
> suits.

as discussed in RL, /me likes. :) Please provide a MR including documenation
updates as needed. And thank you very much for using and improving reprotest!


-- 
cheers,
Holger

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

Nach wieviel Einzelfällen wird ein Einzelfall zum Normalfall?
(Jan Böhmermann)


signature.asc
Description: PGP signature

Bug#1019697: debootstrap: aid reproducible boostrapping by providing a --cleanup-logs option

[Cyril Brulebois]

Chris Lamb  (2022-09-14):
> Would it be sensible to suggest that, instead of an explicit
> command-line flag, that debootstrap would do this cleanup if
> SOURCE_DATE_EPOCH is present?

LGTM, and much better than the command line flag I was definitely not a
huge fan of (as mentioned initially).

It would probably make sense to have a tiny note in the manpage so that
people can check the difference in behaviour if they notice and wonder.

> If it helps, the idea of using the presence (or non-presence) of
> SOURCE_DATE_EPOCH to slightly adjust the behaviour of a program is
> already being used as a flag in other places.

Good to know, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1019745: RFP: sphinx-enum-tools -- expand Python's enum module in Sphinx documentation

[Emanuele Rocca]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: sphinx-enum-tools
  Version : 0.9.0
  Upstream Author : Dominic Davis-Foster 
* URL : https://github.com/domdfcoding/enum_tools
* License : LGPL-3
  Programming Lang: Python
  Description : expand Python's enum module in Sphinx documentation

The enum_tools Sphinx extension can be used to document Enums better
than autoclass can currently. Additionally, this library includes a
decorator to add docstrings to Enum members from a comment at the end of
the line.

---

The package is being requested since the latest flask-limiter version
uses the enum_tools extension for its documentation.

Bug#1019744: khal: Can't create an event without specifying the timezone

[eingousef]

Package: khal
Version: 1:0.10.4~ds-3
Severity: normal
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

Here's what happens when I try to create an event without specifying the TZ :

```
$ khal new -a private_calendar_local '2022-09-15 12:00' "test" :: "test"
  
/usr/lib/python3/dist-packages/khal/icalendar.py:104: PytzUsageWarning: The 
localize method is no longer necessary, as this time zone supports the fold 
attribute (PEP 495). For more details on migrating to a PEP 495-compliant 
implementation, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  dtstart = timezone.localize(dtstart)
/usr/lib/python3/dist-packages/khal/icalendar.py:105: PytzUsageWarning: The 
localize method is no longer necessary, as this time zone supports the fold 
attribute (PEP 495). For more details on migrating to a PEP 495-compliant 
implementation, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  dtend = timezone.localize(dtend)
/usr/lib/python3/dist-packages/icalendar/parser.py:54: PytzUsageWarning: The 
zone attribute is specific to pytz's interface; please migrate to a new time 
zone provider. For more details on how to do so, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  if hasattr(dt.tzinfo, 'zone'):
/usr/lib/python3/dist-packages/icalendar/parser.py:55: PytzUsageWarning: The 
zone attribute is specific to pytz's interface; please migrate to a new time 
zone provider. For more details on how to do so, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  tzid = dt.tzinfo.zone  # pytz implementation
Traceback (most recent call last):
  File "/usr/bin/khal", line 5, in 
main_khal()
  File "/usr/lib/python3/dist-packages/click/core.py", line 1128, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1053, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1659, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 1395, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 754, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 26, in 
new_func
return f(get_current_context(), *args, **kwargs)
  File "/usr/lib/python3/dist-packages/khal/cli.py", line 388, in new
new_func(
  File "/usr/lib/python3/dist-packages/khal/controllers.py", line 355, in 
new_from_string
new_from_args(
  File "/usr/lib/python3/dist-packages/khal/controllers.py", line 381, in 
new_from_args
collection.new(event)
  File "/usr/lib/python3/dist-packages/khal/khalendar/khalendar.py", line 208, 
in new
event.href, event.etag = self._storages[calendar].upload(event)
  File "/usr/lib/python3/dist-packages/khal/khalendar/vdir.py", line 212, in 
upload
if not isinstance(item.raw, str):
  File "/usr/lib/python3/dist-packages/khal/khalendar/event.py", line 382, in 
raw
timezone = create_timezone(tzinfo, self.start)
  File "/usr/lib/python3/dist-packages/khal/khalendar/event.py", line 858, in 
create_timezone
for one, two in iter(tz._tzinfos.items())
AttributeError: '_PytzShimTimezone' object has no attribute '_tzinfos'
```

Instead I have to do :

```
$ khal new -a private_calendar_local '2022-09-15 12:00 Europe/Paris' "test" :: 
"test"
```

Please bring the old behavior back, where khal used the system TZ when
no TZ was given.

Regards,

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

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

Versions of packages khal depends on:
ii  python33.10.6-1
ii  python3-atomicwrites   1.4.0-2
ii  python3-click  8.0.3-1
ii  python3-click-log  0.3.2-1
ii  python3-configobj  5.0.6-5
ii  python3-dateutil   2.8.1-6
ii  python3-icalendar  4.0.3-5
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-tz 2022.2.1-1
ii  python3-tzlocal4.2-1
ii  python3-urwid  2.1.2-2+b2
ii  python3-xdg0.27-2

Versions of packages khal recommends:
ii  python3-setproctitle  1.3.1-1

Versions of packages khal suggests:
ii  khal-doc  1:0.10.4~ds-3

-- no debconf information

Bug#1013228: python-werkzeug: Please keep version < 2.1

[Thomas Goirand]

Hi Bastian,

I'm about to upload Werkzeug to Experimental, and soon after (in 2 weeks 
if everything goes as planned) to Unstable.


Do you have any update regarding crossbar?

Cheers,

Thomas Goirand (zigo)

Bug#1019743: u-boot-menu: u-boot-update should read kernel parameters from /etc/kernel/cmdline

[Christopher Obbard]

Source: u-boot-menu
Version: 4.1.0
Severity: wishlist

Dear Maintainer,

u-boot-update should read the kernel cmline parameters from
/etc/kernel/cmdline when updating the extlinux configuration.


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck

[Philip Hands]

Package: reprotest
Version: 0.7.22
Severity: wishlist

I suggest adding a 'nocheck' variation, that sets DEB_BUILD_OPTIONS=nocheck
during the build, and enabling it by default.

The reason for doing so is that one could imagine that a package produces
differing results depending upon whether the tests were run or not, but also
(given that the tests will have passed during the normal build) the tests
failing during the varied build seems unlikely to be identifying faults that are
worth fixing, and so is just a waste of cycles.

This idea is prompted by `busybox` where the tests fail in the varied scenario,
despite the fact that the package is reproducible.

Here they are failing:

  https://salsa.debian.org/installer-team/busybox/-/jobs/3227197

  (among other things, du produces weird results when the `fileordering`
   variation is active, claiming the 1MB directoy is 2MB so the tests fail, so
   the varied package is not produced, so we don't get to see that it was
   reproducible:
   
https://salsa.debian.org/installer-team/busybox/-/blob/master/testsuite/du/du-m-works
   )


I found a couple of ways of making the issue go away:

  1) disabling the 'fileordering' variation, thus:


https://salsa.debian.org/installer-team/busybox/-/commit/17387890c73388e1f56a6ae9fbc79783095b4e86

https://salsa.debian.org/installer-team/busybox/-/jobs/3233259

  2) telling the package to skip the tests when doing the variations:


https://salsa.debian.org/installer-team/busybox/-/commit/5260442e8ceea220fa36bdda169978d15108f781

which is setting this in the salsa-ci.yml:
  SALSA_CI_REPROTEST_ARGS: 
--variations=environment.variables+=DEB_BUILD_OPTIONS=nocheck

https://salsa.debian.org/installer-team/busybox/-/jobs/3235476


Option 2) is what I'm suggesting making into a default variation.

If nothing else it will speed up testing of packages with extensive test suits.

Cheers, Phil.

Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged

[Michael Prokop]

Hi!

* Gabriel Filion [Tue Sep 13, 2022 at 10:46:27AM -0400]:
> On 2022-09-13 01 h 50, Michael Prokop wrote:
> > * Gabriel Filion [Mon Jan 24, 2022 at 10:53:27AM -0500]:
> > 
> > > Upstream has released a new version of smokeping, 2.8.2 and it would be 
> > > helpful
> > > to upgrade the debian package to this version since it contains a number 
> > > of
> > > fixes, some of which would remove patches in the package.
> > > 
> > > I've received two emails directly requesting the new version so I'm 
> > > creating
> > > this bug report to reflect their wish to have this version.
> > 
> > Friendly ping, that v2.8.2 was released on 2021-08-13 and the freeze
> > for Debian/bookworm is coming closer. :) Would be great to have the
> > new smokeping version in the upcoming Debian stable release.
> > 
> > Thanks for maintaining smokeping!
> 
> thanks for the ping!  I've been concentrated on another project recently but
> you're totally right, I should make the last efforts required to get that
> version into testing soon!

Ok! :)

> The current state of things is that the new lib dependency to version 2.8.2,
> libobject-result-perl, is created and I've received some feedback from the
> perl team:
> 
> https://lists.debian.org/debian-perl/2022/09/msg5.html
> 
> I should fix the license text and maybe open a bug report upstream for the
> typo.

Ah I see, usually the perl team is very responsive, but if you don't
find a sponsor/uploader for the package within reasonable time, let
me know.

> In the mean time, I'm wondering if you're willing to help out a bit with
> reviewing my work on smokeping, that way we could move faster once the perl
> lib is in unstable. Upstream version 2.8.2 was merged onto the "master"
> branch. IIRC it's currently awaiting the dependency and then should be ready
> for review/sponsorship (but there might still be lintian issues that I
> haven't looked at because of the new library)
> 
> https://salsa.debian.org/debian/smokeping

Ah great, I can't promise anything yet, but happy to take a look at
it, once the package is ready for building (AKA
libobject-result-perl is available), feel free to poke me then! :)

Thanks!

regards
-mika-


signature.asc
Description: PGP signature

Bug#1019741: flask-limiter: build with sphinx inline_tabs

[Emanuele Rocca]

Source: flask-limiter
Version: 2.6.2-1
Severity: wishlist

Flask-limiter 2.6.2 uses the inline_tabs sphinx extension. As the
extension is not in Debian yet, I've added a patch to flask-limiter to
build without it, debian/patches/no_inline_tabs.patch.

Once sphinx-inline-tabs will be in the archive, the patch should be
dropped and the extension added as a build dependency.

The sphinx-inline-tabs WNPP bug is https://bugs.debian.org/992745

Bug#1019740: libreoffice: Please package the qt6 VCL plugin

[Michael Weghorn]

Package: libreoffice
Version: 1:7.4.1~rc1-3+b1
Severity: wishlist
X-Debbugs-Cc: m.wegh...@posteo.de

Dear Maintainer,

a Qt 6 based UI variant (VCL plugin) was added to LibreOffice in this commit:
https://git.libreoffice.org/core/commit/88d57cf241209ffec9eaed3e523942ab51af6db6

It is the Qt 6 variant of the "qt5" VCL plugin (autogen option '--enable-qt5')
and shares almost all code with it.

The qt6 VCL plugin can be enabled by the '--enable-qt6' autogen option.

It would be nice if the qt6 VCL plugin were packaged in Debian as well.

Best regards,
Michael

PS: The trigger for this request is a question in LO Bugzilla:
https://bugs.documentfoundation.org/show_bug.cgi?id=145734#c2

The qt6 VCL plugin was never mentioned in the official LO release notes, since
it was initially mostly meant to be used for own experimenting before making it
official, but at least from my (developer's) experience, I haven't run into any
issues that are specific to the qt6 VCL plugin (as compared to the qt5/kf5 one)
for a while when used together with recent versions of Qt 6.


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

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

Versions of packages libreoffice depends on:
ii  libreoffice-base1:7.4.1~rc1-3+b1
ii  libreoffice-calc1:7.4.1~rc1-3+b1
ii  libreoffice-core1:7.4.1~rc1-3+b1
ii  libreoffice-draw1:7.4.1~rc1-3+b1
ii  libreoffice-impress 1:7.4.1~rc1-3+b1
ii  libreoffice-math1:7.4.1~rc1-3+b1
ii  libreoffice-report-builder-bin  1:7.4.1~rc1-3+b1
ii  libreoffice-writer  1:7.4.1~rc1-3+b1
ii  python3-uno 1:7.4.1~rc1-3+b1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.5-1
ii  fonts-linuxlibertine5.3.0-6
ii  fonts-noto-core 20201225-1
ii  fonts-noto-extra20201225-1
ii  fonts-noto-mono 20201225-1
ii  fonts-noto-ui-core  20201225-1
ii  fonts-sil-gentium-basic 1.102-1.1
ii  libreoffice-java-common 1:7.4.1~rc1-3
ii  libreoffice-nlpsolver   0.9+LibO7.4.1~rc1-3
ii  libreoffice-report-builder  1:7.4.1~rc1-3
ii  libreoffice-script-provider-bsh 1:7.4.1~rc1-3
ii  libreoffice-script-provider-js  1:7.4.1~rc1-3
ii  libreoffice-script-provider-python  1:7.4.1~rc1-3
ii  libreoffice-sdbc-mysql  1:7.4.1~rc1-3+b1
ii  libreoffice-sdbc-postgresql 1:7.4.1~rc1-3+b1
ii  libreoffice-wiki-publisher  1.2.0+LibO7.4.1~rc1-3

Versions of packages libreoffice suggests:
ii  cups-bsd 2.4.2-1+b1
ii  default-jre [java8-runtime]  2:1.11-72
ii  firefox-esr  102.2.0esr-1
ii  ghostscript  9.56.1~dfsg-1
ii  gnupg2.2.39-1
pn  gpa  
ii  gstreamer1.0-libav   1.20.3-1+b1
ii  gstreamer1.0-plugins-bad 1.20.3-2
ii  gstreamer1.0-plugins-base1.20.3-2
ii  gstreamer1.0-plugins-good1.20.3-1
ii  gstreamer1.0-plugins-ugly1.20.3-1
ii  hunspell-de-de-frami [hunspell-dictionary]   1:7.4.0~rc2-4
ii  hunspell-en-gb [hunspell-dictionary] 1:7.4.0~rc2-4
ii  hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2
ii  hunspell-es [hunspell-dictionary]1:7.4.0~rc2-4
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1
ii  hunspell-it [hunspell-dictionary]1:7.4.0~rc2-4
ii  hunspell-pt-br [hunspell-dictionary] 1:7.4.0~rc2-4
ii  hunspell-pt-pt [hunspell-dictionary] 1:7.4.0~rc2-4
ii  hyphen-de [hyphen-hyphenation-patterns]  1:7.4.0~rc2-4
ii  hyphen-en-gb [hyphen-hyphenation-patterns]   1:7.4.0~rc2-4
ii  hyphen-en-us [hyphen-hyphenation-patterns]   2.8.8-7
ii  hyphen-es [hyphen-hyphenation-patterns]  1:7.4.0~rc2-4
ii  hyphen-fr [hyphen-hyphenation-patterns]  1:7.4.0~rc2-4
ii  hyphen-it [hyphen-hyphenation-patterns]  1:7.4.0~rc2-4
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b3
ii  libgl1   1.5.0-1
pn  libofficebean-java   
pn  libreoffice-grammarcheck 
ii  libreoffice-help-de 

Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Santiago R.R.]

El 14/09/22 a las 13:58, Emilio Pozuelo Monfort escribió:
> On 13/09/2022 16:46, Sylvain Beucler wrote:
> > Hi,
> > 
> > IIUC this is about fixing 2 non-security bugs, that were introduced
> > prior to buster's initial release.
> > 
> > I personally don't think this fits the LTS project scope.
> > Maybe other LTS members will have a different opinion.
> 
> We've had bugfix updates from time to time. They are rare, but not
> forbidden. This should go in a buster suite rather than buster-security, but
> since there's no such suite for LTS, having it in buster-security is the
> lesser evil. Of course we shouldn't flood -security with bug fixes, if that
> was necessary we should consider keeping $stable open and handled by the LTS
> team (but that doesn't seem necessary at this point).
> 
> In this case, since the update has been prepared and looks sensible, I'll go
> ahead with the upload if nobody objects.
> 

Thanks, Emilio. Also consider
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961654#15

Haven't tested yet myself. But I suppose I should apply it in unstable.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1019739: ITP: passes -- GTK-based digital pass manager

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-de...@lists.debian.org, aferra...@debian.org

* Package name: passes
  Version : 0.6
  Upstream Author : Pablo Sánchez Rodríguez 
* URL : https://github.com/pablo-s/passes
* License : GPL
  Programming Lang: Python
  Description : GTK-based digital pass manager

Passes is a graphical application for managing digital passes, as its name
implies. It has a mobile-friendly user interface and can import and display
PKPASS files, and display Aztec, PDF417 and QR codes.

Bug#1019710: python-oauthlib: CVE-2022-36087: DoS when attacker provide malicious IPV6 URI

[Salvatore Bonaccorso]

Hi Daniele,

On Wed, Sep 14, 2022 at 10:37:08AM +0200, Daniele Tricoli wrote:
> Hello Salvatore,
> many thanks for the report!
> 
> On 13/09/2022 22:14, Salvatore Bonaccorso wrote:
> > Source: python-oauthlib
> > Version: 3.2.0-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for python-oauthlib.
> > 
> > CVE-2022-36087[0]:
> > | OAuthLib is an implementation of the OAuth request-signing logic for
> > | Python 3.6+. In OAuthLib versions 3.1.1 until 3.2.1, an attacker
> > | providing malicious redirect uri can cause denial of service. An
> > | attacker can also leverage usage of `uri_validate` functions depending
> > | where it is used. OAuthLib applications using OAuth2.0 provider
> > | support or use directly `uri_validate` are affected by this issue.
> > | Version 3.2.1 contains a patch. There are no known workarounds.
> > 
> > Note, that while it is claimed to be fixed in 3.2.1, the two commits
> > in [1] and [2] are not included in 3.2.1. There is a simple test case
> > to show the issue as well in the commit expanding the unittests.
> 
> I'm preparing a new upload for python-oauthlib and I will include also the
> two commits you mentioned. Thanks!

Thanks to you  for the quick action!

Regards,
Salvatore

Bug#1019738: searchandrescue: FTBFS on riscv64: add library search path

[Sakura286]

Source: searchandrescue
Version: 1.5.0-2.1
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

Searchandrescue failed on riscv64 [1].

Simply add library search path to sar/platform.ini and it works. The 
patch has been attached below.


Regards,

Sakura286.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=searchandrescue=riscv64=1.5.0-2.1=1660399987


Index: searchandrescue-1.5.0/sar/platforms.ini
===
--- searchandrescue-1.5.0.orig/sar/platforms.ini
+++ searchandrescue-1.5.0/sar/platforms.ini
@@ -174,6 +174,7 @@ Platform = Linux
 PlatformSearchPathLib = /usr/lib/powerpc-linux-gnu/
PlatformSearchPathLib = /usr/lib/powerpc64le-linux-gnu/
 PlatformSearchPathLib = /usr/lib/powerpc-linux-gnuspe/
+PlatformSearchPathLib = /usr/lib/riscv64-linux-gnu/
 PlatformSearchPathLib = /usr/lib/s390-linux-gnu/
 PlatformSearchPathLib = /usr/lib/s390x-linux-gnu/
 PlatformSearchPathLib = /usr/lib/sh4-linux-gnu/

Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Chris Frey]

On Wed, Sep 14, 2022 at 01:54:40PM +0200, Emilio Pozuelo Monfort wrote:
> Your top-commit looks very similar to the one from Santiago on [1]. I'd
> rather use that to give him credit as he proposed the fix first (plus using
> CPPFLAGS seems more correct for this flag). In addition to that, the commit
> misses his follow-up fix in [2]. I'm going to consider that last debdiff
> from him for an upload to buster. Thanks in any case for looking at it (and
> coming up with a similar fix) and for testing the update.

No problem, thank you!

- Chris

Bug#1019737: qtads: please package new version 3.3 release 19 May 2022

[Alexandre Detiste]

Package: qtads
Version: 2.1.7-0.1+b1
Severity: normal
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org

Hi,

With a bit of luck the new upstream release would solve
"#984310 ftbfs with GCC-11".

There are also a lot of different things to refresh,
like removing the old .menu file.

If you're not (much) interrested anymore in maintaining this
package I'd like to team-maintain it under the Game Teams,
and you could be kept as uploader, your choice.

This would also make it easier to do coordinate uploads
with gargoyle-free to maintain alternatives.

Greetings,

Alexandre Detiste

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qtads depends on:
ii  libc62.34-7
ii  libgcc-s1 [libgcc1]  12.2.0-1
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5gui5   5.15.4+dfsg-5
ii  libqt5network5   5.15.4+dfsg-5
ii  libqt5widgets5   5.15.4+dfsg-5
ii  libsdl-mixer1.2  1.2.12-17+b1
ii  libsdl-sound1.2  1.0.3-9+b1
ii  libsdl1.2-compat-shim [libsdl1.2debian]  1.2.52-4
ii  libstdc++6   12.2.0-1

qtads recommends no packages.

qtads suggests no packages.

-- no debconf information

Bug#988908: plantuml: Can plantuml work with default-jre-headless?

[Maximilian Stein]

> Would it be possible to change this to also accept the headless version,
> ie 'default-jre | default-jre-headless'? It would reduse the apt
> download by 21.4 MiB and the disk footprint by 214 MiB.


I'd like to second this. According to the PlantUML FAQ 
(https://plantuml.com/en/faq) headless operation is possible with a java 
flag.


An alternative approach would be a separate package "plantuml-headless" 
that might even run as server.


Best,
Maximilian

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Jochen Sprickerhof]

Hi Santiago,

* Santiago Ruano Rincón  [2022-09-14 10:36]:

this causes build failures:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/libtool.html

and also autopkgtest failures:

https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dpkg/26032114/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cjet/26041201/log.gz

The first autopkgtest failure is in libtool which is vendored by a lot
of packages so will probably take a long time to fix.



Fixing this would require fixing libtool only, isn't that right?


I don't think so, as it is in a lot of packages:

https://codesearch.debian.net/search?q=Configured+with%3A%22+%7C+%24GREP+%22+%5C-L

(Note that the buggy libtool.m4 is included into configure.)


P.S.: I will send a bug with a patch to the libtool maintainer.


Please do.


Done as #1019725.


P.S. I am letting Severity: serious for now to prevent migration to
testing. But *I* am considering this rather Severity: important, at
most.


Note that the release team issued a block for now:

https://release.debian.org/britney/hints/jcristau

and proposed to test with a archive rebuild before introducing it again.


signature.asc
Description: PGP signature

Bug#1019168: sysvinit: [INTL:pt] Portuguese translation of MANPAGE

[Mark Hindley]

Control: tags -1 upstream

Américo,

On Sun, Sep 04, 2022 at 10:33:07PM +0100, Américo Monteiro wrote:
> Package: sysvinit
> Version: 3.04-1
> Tags: l10n, patch-
> Severity: wishlist

Thanks very much for this.

Forwarded upstream for inclusion.

Mark

Bug#1006788: autopkgtest fails on hosts with lots of RAM/cores

[Graham Inggs]

It's probably worth trying to set
BAGEL_NUM_THREADS=4
or similar in the autopkgtest.

From: https://nubakery.org/quickstart/how_to_run_bagel.html

Bug#1019736: cfengine3: d/watch: Scan GitHub tags

[Bastian Germann]

Source: cfengine3
Version: 3.15.2-3.2

There are not GitHub releases (the pages used to show the tags as well).
Please switch the debian/watch file to the GitHub tags pages.

Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64

[Diederik de Haas]

Control: fixed -1 5.19.6-1

On woensdag 14 september 2022 06:45:18 CEST Computer Enthusiastic wrote:
> An upstream patch has been released [1]
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?
> h=v6.0-rc5=6b04ce966a738ecdd9294c9593e48513c0dc90aa

That commit is part of v6.0-rc3

Fixed in 5.19 with commit 8e3ba23a67de984f4156f0663f1f603ff6c15815 which is 
part of 5.19.6.

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

Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Emilio Pozuelo Monfort]

On 13/09/2022 16:46, Sylvain Beucler wrote:

Hi,

IIUC this is about fixing 2 non-security bugs, that were introduced prior to 
buster's initial release.


I personally don't think this fits the LTS project scope.
Maybe other LTS members will have a different opinion.


We've had bugfix updates from time to time. They are rare, but not forbidden. 
This should go in a buster suite rather than buster-security, but since there's 
no such suite for LTS, having it in buster-security is the lesser evil. Of 
course we shouldn't flood -security with bug fixes, if that was necessary we 
should consider keeping $stable open and handled by the LTS team (but that 
doesn't seem necessary at this point).


In this case, since the update has been prepared and looks sensible, I'll go 
ahead with the upload if nobody objects.


Cheers,
Emilio

Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Emilio Pozuelo Monfort]

Hi Chris,

On 14/09/2022 05:48, Chris Frey wrote:

On the other hand, the fix has been known since 2019 and looks like a
prime problem for an LTS newbie volunteer like me.

I have created the fix based on the Debian/bzip2 repo, the fix is in
the debian/buster branch.

git clone http://digon.foursquare.net/debian-buster-bzip2/.git


Your top-commit looks very similar to the one from Santiago on [1]. I'd rather 
use that to give him credit as he proposed the fix first (plus using CPPFLAGS 
seems more correct for this flag). In addition to that, the commit misses his 
follow-up fix in [2]. I'm going to consider that last debdiff from him for an 
upload to buster. Thanks in any case for looking at it (and coming up with a 
similar fix) and for testing the update.


Cheers,
Emilio

[1] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=961654;filename=bzip2_1.0.6-9.2~deb10u2.debdiff;msg=5
[2] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=961654;filename=bzip2_1.0.6-9.2~deb10u2.debdiff;msg=10




I have tested it on a 32bit buster, and it works on +2g files.

I do not have privileges to push this to any server yet, so feel free to
tweak the changelog and claim it as your own, whoever wishes to upload it.

- Chris


On Tue, Sep 13, 2022 at 04:46:14PM +0200, Sylvain Beucler wrote:

Hi,

IIUC this is about fixing 2 non-security bugs, that were introduced prior to
buster's initial release.

I personally don't think this fits the LTS project scope.
Maybe other LTS members will have a different opinion.

Cheers!
Sylvain Beucler
Debian LTS Team

On 13/09/2022 15:27, Santiago R.R. wrote:

El 10/09/22 a las 19:11, Adam D. Barratt escribió:

On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote:

Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64
CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557

I've uploaded a fixed version to unstable yesterday. It would be
great
to fix it also in buster. Please, consider the attached debdiff.
Would it be OK for you to upload it?



Apologies for apparently letting this sit unanswered. (FTR there was a
reply from a non-SRM member 18 months ago.)


And I am sorry I missed that answer.



The final point release for buster has now happened, so any further
updates to packages in buster will need to be handled via LTS. I'm
therefore going to close this request now.

[snip]

I am forwarding this to the LTS folks, so they can decide about this
change.

Bug#1019734: bat: Bat its manpage are not anymore renamed from ‘bat’ to 'batcat' after resolution of #932634

[Tomasz Kapias]

Package: bat
Version: 0.21.0-2
Severity: important

Dear Maintainer,


Apparently because of an executable conflict in another package 'bat' was
renamed 'batcat' ater discussions in #932634.

Apt-file, lintian conflict file and package description still mention this
change.

But the situation changed:

  - at least for version 0.21.0-2, I don't have any 'batcat' executable
installed, and 'bat' is in /usr/bin.
  - The executable creation date to 10th july and the issue was closed in july
too.

The issue is with the description of the package and with interactions with
other projects.
There is no mention in the changelog.

Some project were looking for 'batcat' as a requirement for debian.



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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bat depends on:
ii  libc62.34-7
ii  libgcc-s112.2.0-1
ii  libgit2-1.3  1.3.0+dfsg.1-3

bat recommends no packages.

bat suggests no packages.

-- no debconf information