Bug#966573: progress packaging awscli v2

[Noah Meyerhans]

Hi Ross,

On Tue, Oct 05, 2021 at 11:10:43PM -0600, Ross Vandegrift wrote:
> > awscli v2 remains quite difficult to package, but it seems that upstream
> > is looking to address this.  See
> > https://github.com/aws/aws-cli/issues/6186 for details and tracking.
> 
> Using the source dist poc from https://github.com/aws/aws-cli/pull/6352 I've
> made enough progress to get a packaged aws-cli v2 working.  There's a lot more
> that needs to be done, but idea of the above linked PR could work for us.  I'm
> going to document my findings here.

So, only a year later, I've picked this up and made some additional
progress:

I have no name!@b02f1db79f9e:/src$ aws --version
aws-cli/2.8.7 Python/3.10.8 Linux/6.0.0-2-amd64 source/x86_64.debian prompt/off
I have no name!@b02f1db79f9e:/src$ dpkg -s awscli | grep Version
Version: 2.8.7-1

> aws-crt-python is the hard part.  It depends on a bunch of C libraries which
> follow a more modern development style.  They:
> - provide no abi/api stability guarantees.
> - have versioned releases, but no one cares about the versions.  The intention
>   is that everyone should be following the main branch.
> - only nominally support dynamic linking (it can be enabled, but is not used 
> or
>   tested by upstream).
> - seem to be mostly used via source inclusion.

Indeed, none of this has improved in the past year.  In fact, we've
actually gained a few more such dependencies that didn't exist last year
(aws-c-sdkutils, at least).

We might actually be able to make a case that all the aws-c-* libraries
end up being easier to maintain if we ship them as private internal
components of the aws-crt-python package rather than as first class
packages that could end up becoming dependencies of other downstream
packages.

> - some repos have tests disabled due to failing during builds.  So far, I 
> don't
>   know if these are real failures, or if upstream's build method.

I think I've got most of these fixed.

> - copyright attribution for aws-lc is very hard.  It's a fork of Google's
>   BoringSSL, which is a fork of pre-3.0 OpenSSL.
> 
> - That also means that aws-lc inherits the openssl gpl incompatibility.

Here's the good news: We don't actually need aws-lc at all.  awscli v2
and its various dependencies (including s2n-tls) can build against
OpenSSL 3.

> - the aws-cli2-temp repo is based on upstream, not our awscli repo.  I was
>   intentionally being sloppy to quickly get through a test.

Same.  I essentially Debianized the upstream v2 repo from scratch,
pulling in some of your packaging metadata as it made sense.  Given that
v2 is developed on a different branch and by now differs quite
significantly from v1, a case could be made for introducing a new
awscli2 package as a new source package and retiring the original awscli
package.  However, the debian package metadata isn't really all that
complex, so it may not actually be necessary.

> - aws-lc and s2n-tls may be hard to maintain.  Both are complicated, security
>   critical crypto libraries.

Fortunately, aws-lc isn't an issue. But s2n-tls remains one.  Not sure
we're going to be able to do anything about that.  The difficult thing
is that it's typically expected to be used as a statically linked
library, which means updates end up being tedious.

I haven't pushed my changes anywhere, yet.  Once I do, the remaining
tasks will be to any lintian issues or other obvious problems and get
these packages into NEW.  I think they're in reasonably good shape, but
we don't have a lot of time before bookworm starts freezing, so I'd love
any help with these steps.

We have to get at least the following packages into the archive:

aws-c-auth_0.6.18-1_amd64.changes
aws-c-cal_0.5.20-1_amd64.changes
aws-c-common_0.8.4-1_amd64.changes
aws-c-compression_0.2.15-1_amd64.changes
aws-c-event-stream_0.2.15-1_amd64.changes
aws-c-http_0.6.23-1_amd64.changes
aws-c-io_0.13.6-1_amd64.changes
aws-c-mqtt_0.7.12-1_amd64.changes
aws-c-s3_0.1.51-1_amd64.changes
aws-c-sdkutils_0.1.4-1_amd64.changes
aws-checksums_0.1.13-1_amd64.changes
aws-crt-python_0.15.1-1_amd64.changes
s2n-tls_1.3.26-1_amd64.changes

Bug#1023248: systemd fails to install: Failed to resolve group 'systemd-journal'.

[Jochen Sprickerhof]

Hi Helmut,

* Helmut Grohne  [2022-11-01 06:08]:

Package: systemd
Version: 252-1
Severity: serious

systemd fails to install in unstable:

mmdebstrap --verbose --variant apt --include systemd unstable /dev/null

| Setting up systemd (252-1) ...
| Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → 
/lib/systemd/system/getty@.service.
| Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target 
→ /lib/systemd/system/remote-fs.target.
| Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-pstore.service → 
/lib/systemd/system/systemd-pstore.service.
| Initializing machine ID from random generator.
| /usr/lib/tmpfiles.d/systemd.conf:28: Failed to resolve group 
'systemd-journal'.
| /usr/lib/tmpfiles.d/systemd.conf:29: Failed to resolve group 
'systemd-journal'.
| /usr/lib/tmpfiles.d/systemd.conf:30: Failed to resolve group 
'systemd-journal'.
| dpkg: error processing package systemd (--configure):
|  installed systemd package post-installation script subprocess returned error 
exit status 65
| Processing triggers for libc-bin (2.35-4) ...
| Errors were encountered while processing:
|  systemd
| E: Sub-process env returned an error code (1)

Hope you can figure this out quickly. It happens to break rebootstrap
CI. If you happen to know a workaround that'd be appreciated as well.


I've opened a MR to fix this:

https://salsa.debian.org/systemd-team/systemd/-/merge_requests/182

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1023248: systemd fails to install: Failed to resolve group 'systemd-journal'.

[Helmut Grohne]

Package: systemd
Version: 252-1
Severity: serious

systemd fails to install in unstable:

mmdebstrap --verbose --variant apt --include systemd unstable /dev/null

| Setting up systemd (252-1) ...
| Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → 
/lib/systemd/system/getty@.service.
| Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target 
→ /lib/systemd/system/remote-fs.target.
| Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-pstore.service → 
/lib/systemd/system/systemd-pstore.service.
| Initializing machine ID from random generator.
| /usr/lib/tmpfiles.d/systemd.conf:28: Failed to resolve group 
'systemd-journal'.
| /usr/lib/tmpfiles.d/systemd.conf:29: Failed to resolve group 
'systemd-journal'.
| /usr/lib/tmpfiles.d/systemd.conf:30: Failed to resolve group 
'systemd-journal'.
| dpkg: error processing package systemd (--configure):
|  installed systemd package post-installation script subprocess returned error 
exit status 65
| Processing triggers for libc-bin (2.35-4) ...
| Errors were encountered while processing:
|  systemd
| E: Sub-process env returned an error code (1)

Hope you can figure this out quickly. It happens to break rebootstrap
CI. If you happen to know a workaround that'd be appreciated as well.

Helmut

Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel

[Wookey]

On 2022-11-01 08:57 +0500, Akbarkhon Variskhanov wrote:
> On Mon, Oct 31, 2022 at 7:02 PM Wookey  wrote:
> > The description could be more useful.
> > "The plugin supports common mathematical operators (+, -, *, /, ^) with 
> > usual
> >  precedence rules, and some common functions such as abs(x), sqrt(x), sin(x)
> >  and cos(x)."
> 
> If it were possible, I wouldn't even write a long description for this
> package. I feel like repeating what's already there in the short
> description is counter-productive,

You may feel that, but I disagree. Good descriptions, both long and
short, are important.  Imagine somone reading through a list of our
thousands of packages (who maybe never have even _heard_ of XFCE) when
writing descriptions. The description needs to tell them enough to
decide whether or not they might want to install this thing.

> and Xfce panel plugins are Xfce
> panel plugins. They depend on having xfce4-panel and anyone who's ever
> used Xfce knows where their panel is, what their panel has. Besides,
> I'm completely lost as to what else I can say here (aka lacking
> creativity). It is an Xfce panel plugin (determined by its name
> already), provides a calculator functionality on the Xfce panel
> (again, it's in the name). Hence,

I've been using XFCE daily for 20 years and I'm still asking for a
more useful description because I _don't_ know what this package
is/does. What you've said above is pretty good, and I've now actually
tried it, so I came up with this:

"An XFCE desktop panel plugin, which provides a 'paper mode' style calculator 
as a box in the panel."

The important distinction here is between something that launches a
desktop calculator or something that provides a box in the panel that
will do calculations. It sounds from what you have said that it is the
latter (and I have just installed it to check that that is indeed the case). 

I was actually a lot more excited about it when I thought it was a
quick way to keep something like galculator to hand.

> > It needs to say what this _is_. Perhaps something like
> >  "Provides on-screen calculator from toolbar", then details as above.
> 
> would be wrong, and even with corrections, pointless and/or duplicated info.

That fact that I got it wrong after reading your ITP and examining the
packaging illustrates the need for the description to clarify what the
package actually is/does.

> Let me contact upstream for their explanation and rationale for
> including LGPL in the source tree.

That'll be the best way to work out what was intended. 

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel

[Akbarkhon Variskhanov]

Hi. Thanks a lot for your review and hints.

On Mon, Oct 31, 2022 at 7:02 PM Wookey  wrote:
> The description could be more useful.
> "The plugin supports common mathematical operators (+, -, *, /, ^) with usual
>  precedence rules, and some common functions such as abs(x), sqrt(x), sin(x)
>  and cos(x)."

If it were possible, I wouldn't even write a long description for this
package. I feel like repeating what's already there in the short
description is counter-productive, and Xfce panel plugins are Xfce
panel plugins. They depend on having xfce4-panel and anyone who's ever
used Xfce knows where their panel is, what their panel has. Besides,
I'm completely lost as to what else I can say here (aka lacking
creativity). It is an Xfce panel plugin (determined by its name
already), provides a calculator functionality on the Xfce panel
(again, it's in the name). Hence,

> It needs to say what this _is_. Perhaps something like
>  "Provides on-screen calculator from toolbar", then details as above.

would be wrong, and even with corrections, pointless and/or duplicated info.

> I'd add Adrian Dimitrov  to the copyright list

Nice catch! Surprisingly, neither `debmake` nor `licensecheck` listed
Adrian Dimitrov. I'm not sure why, though. It looks like he's only
involved in panel-plugins/calculator.c. Manual grepping doesn't reveal
any more copyright holders, and unfortunately the test suite is also
authorless. I also did a big whoopsie and forgot to include debian/*
and myself in the copyright file. I'll fix these.

> and the package includes the LGPL COPYING.LIB at top level, although it's not 
> obvious if that actually applies to any of the code.
> If it does then the LGPL should be listed (maybe you already checked this?).

To be honest, I struggle with such things a bit. Let me contact
upstream for their explanation and rationale for including LGPL in the
source tree.

Cheers,
Akbar.

Bug#1023206: ITP: ruby-ipaddr -- class to manipulate an IP address in ruby

[Vinay Keshava]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-ipaddr
 Version   : 1.2.4
 Upstream Author   : ipaddr
*URL   :https://github.com/ruby/ipaddr
*License   : Expat
 Programming Lang  : Ruby
*Description   : class to manipulate an IP address in ruby

 IPAddr provides a set of methods to manipulate an IP address.
 Both IPv4 and IPv6 are supported.

.

This gem is required for the gitlab 15.5.1 update.

- Vinay Keshava

Bug#1023197: ITP: ruby-cvss-suite -- gem that helps you to process the vector of the Common Vulnerability Scoring System

[Vinay Keshava]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-cvss-suite
 Version   : 3.1.0
 Upstream Author   : 0llirocks
*URL   :https://github.com/0llirocks/cvss-suite
*License   : Expat
 Programming Lang  : Ruby
*Description   :Ruby gem for processing cvss vectors.

 This Ruby gem helps you to process the vector of the Common Vulnerability
 Scoring System (https://www.first.org/cvss/specification-document).
 Besides calculating the Base, Temporal and Environmental Score, you are able
 to extract the selected option.

.

This gem is required for the gitlab 15.5.1 update.

- Vinay Keshava

Bug#1023230: [Debian-med-packaging] Bug#1023230: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: test times out after 2:47 hours

[gregor herrmann]

Control: reassign -1 t-coffee 13.45.0.4846264+dfsg-1

On Tue, 01 Nov 2022 09:12:43 +0900, Charles Plessy wrote:

> Le Mon, Oct 31, 2022 at 09:27:47PM +0100, Paul Gevers a écrit :
> > 
> > https://ci.debian.net/data/autopkgtest/testing/arm64/libb/libbio-tools-run-alignment-tcoffee-perl/27686780/log.gz
> > 
> > autopkgtest [11:59:24]: ERROR: timed out on command "su -s /bin/bash debci
> 
> I think that t-coffee never worked on ARM.  It built, but never worked.
> The simplest would be to distribute it only on amd64.
> See https://bugs.debian.org/631249

Also https://bugs.debian.org/1022570 might be relevant.

Reassigning to (only) t-coffee.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones: Letitrock


signature.asc
Description: Digital Signature

Bug#1023247: Filter by package name is broken

[Алекса -скрыто-]

Package: synaptic
Version: 0.91.2
X-Debbugs-No-Ack: yes

1. Create a new filter
2. Add a condition "Package Name" "Includes" "foo"; select the logic "OR"
3. Press OK
4. Reopen the filter dialog

The predicate has changed to "Excludes".

Bug#1023246: Filter by package name is broken

[Алекса -скрыто-]

Package: synaptic
Version: 0.91.2
X-Debbugs-No-Ack: yes

1. Create a new filter
2. Add a condition "Package Name" "Includes" "foo"; select the logic "OR"
3. Press OK
4. Reopen the filter dialog

The predicate has changed to "Excludes".

Bug#1018225: src:rust-rustls: fails to migrate to testing for too long: blocked by build dependency

[Peter Green]

On 31/10/2022 16:17, Jonas Smedegaard wrote:

Quoting Peter Green (2022-10-31 03:39:28)

src:rust-rustls: fails to migrate to testing for too long: blocked by build 
dependency

Specifically rust-async-std has taken some time to package, because of the 
large number
of dependencies. There has been effort on this front both by the rust team and 
by Jonas
who currently packages rust stuff outside the rust team because he doesn't like 
our
packaging workflow.

Thanks, Peter.  For issues like this one by Release team and explicitly
described in subject as "blocked by build dependency" I believe however
than there is no need for explaining the cause (in _these_ bugreports -
it may make sense and be helpful to elaborate on the cause at a _root_
blocking bugreport).


This bug report is the one that is in testing, and has rc severity and
hence can cause stuff to be removed from testing.

The autoremovals system operates on the basis of when a bug report
was last posted to as an indication of wheter progress is being made
on the bug. Progress is being made on this bug, but the autoremovals
system doesn't know that in case a status update is posted to the
bug, hence why I posted one.

Bug#1023230: [Debian-med-packaging] Bug#1023230: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: test times out after 2:47 hours

[Charles Plessy]

Le Mon, Oct 31, 2022 at 09:27:47PM +0100, Paul Gevers a écrit :
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/libb/libbio-tools-run-alignment-tcoffee-perl/27686780/log.gz
> 
> autopkgtest [11:59:24]: ERROR: timed out on command "su -s /bin/bash debci

Hi all,

I think that t-coffee never worked on ARM.  It built, but never worked.
The simplest would be to distribute it only on amd64.

See https://bugs.debian.org/631249

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1023245: firmware-iwlwifi: missing ibt-0040-0041.sfi causes Bluetooth device 8087:0033 to not work

[Christoph Anton Mitterer]

Package: firmware-iwlwifi
Version: 20221012-1
Severity: normal


Hey there.

My new Fujitsu Lifebook U7512 has some Intel USB Bluetooh device:
# lsusb -v -d 8087:0033

Bus 001 Device 009: ID 8087:0033 Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.01
  bDeviceClass  224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize064
  idVendor   0x8087 Intel Corp.
  idProduct  0x0033 
  bcdDevice0.00
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x00c8
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x  1x 0 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x  1x 0 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   1
  bNumEndpoints   2
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0009  1x 9 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0009  1x 9 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   2
  bNumEndpoints   2
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
   

Bug#1023221: (no subject)

[Jorge]

See https://github.com/the3dfxdude/7kaa/issues/258

Bug#1023229: f3d: autopkgtest regression on s390x: Compare with ref failed

[François Mazen]

Hello Paul,

thanks for reporting the issue, I've investigated and this is an Assimp
problem that I've reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023212

The big endian architecture may be the root of the issue, thanks for
pointing that out.

Best Regards,
François






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

Bug#1009966: Fixed upstream in 1.7.0 release

[Paweł Krawczyk]

https://github.com/kravietz/pam_tacplus/releases/tag/v1.7.0


libpam-tacplus (1.7.0-1) unstable; urgency=medium

  * libtac: Refactored the complex and overengineered TACACS+ session 
id generation,

replacing it with getrandom(2).
  * libtac: gnulib now provides implementation of missing functions.
  * libtac: Removed legacy MD5 code and replaced it with gnulib.
  * libtac: Legacy data structures such as attribute lists were 
replaced with gnulib structures.
  * libtac: CHAP implementation used a fixed challenge in contradiction 
with the RFC 1994
requirement. This was replaced with a pseudo-random challenge 
generated using getrandom(2).
  * libtac: ABI version set to 5:0:0. From now on, this is the only way 
to version the library.

The legacy static variables tac_ver_ were removed as confusing.
  * pam_tacplus: Calling process PID is now used as the task_id 
attribute in TACACS+
accounting session. This replaces an overengineered 
cryptographically random tasks identifiers.

  * libtac: Fix CVE-2016-20014. Closes: #1009966

 -- Pawel Krawczyk   Sat, 31 Oct 2022 22:44:00 
+0100

Bug#1023244: gajim does not start : libsoup-ERROR

[Jean-Marc]

Package: gajim
Version: 1.5.2-1
Severity: important

Dear Maintainer,

gajim does not start anymore.

It just crashes producing this error message:

$ gajim

(org.gajim.Gajim:104000): libsoup-ERROR **: 00:06:55.825: libsoup2 symbols 
detected. Using libsoup2 and libsoup3 in the same process is not supported.

I got the same with other programs (i.e. dino-im).

Regards,

Jean-Marc

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

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gajim depends on:
ii  desktop-file-utils   0.26-1
ii  gir1.2-gst-plugins-base-1.0  1.20.3-2
ii  gir1.2-gtk-3.0   3.24.34-3
ii  gir1.2-gtksource-4   4.8.3-1
ii  python3  3.10.6-1
ii  python3-cairo1.20.1-4
ii  python3-css-parser   1.0.8-1
ii  python3-gi   3.42.2-2
ii  python3-gi-cairo 3.42.2-2
ii  python3-idna 3.3-1
ii  python3-keyring  23.9.3-1
ii  python3-nbxmpp   3.2.4-1
ii  python3-openssl  21.0.0-1
ii  python3-packaging21.3-1.1
ii  python3-pil  9.2.0-1.1
ii  python3-precis-i18n  1.0.4-2

Versions of packages gajim recommends:
ii  alsa-utils   1.2.7-1
ii  aspell-en [aspell-dictionary]2018.04.16-0-1
ii  aspell-fr [aspell-dictionary]0.50-3-8.1
ii  aspell-nl [aspell-dictionary]1:2.20.19-2
ii  ca-certificates  20211016
ii  dbus 1.14.4-1
ii  fonts-noto-color-emoji   2.038-1
ii  gajim-omemo  2.8.15-1
ii  gajim-openpgp1.4.9-1
ii  gir1.2-farstream-0.2 0.2.9-1
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-gsound-1.01.0.3-2
ii  gir1.2-gspell-1  1.12.0-1
ii  gir1.2-gstreamer-1.0 1.20.3-1
ii  gir1.2-gupnpigd-1.0  1.2.0-3
ii  gir1.2-secret-1  0.20.5-3
ii  gnome-shell [notification-daemon]43.0-2
ii  gstreamer1.0-plugins-ugly1.20.3-1
ii  notification-daemon  3.20.0-4+b1
ii  pulseaudio-utils 16.1+dfsg1-2+b1
ii  python3-dbus 1.3.2-1
ii  python3-sentry-sdk   1.9.10-1
ii  xfce4-notifyd [notification-daemon]  0.6.4-1

Versions of packages gajim suggests:
ii  libxss1  1:1.2.3-1
ii  nautilus-sendto  3.8.6-4

-- no debconf information

Bug#1023243: projectile: Dead Homepage link

[Adrian Bunk]

Source: projectile
Version: 2.5.0-1
Severity: minor

The Homepage: link seems to be dead, please replace it with
https://github.com/bbatsov/projectile

Bug#1023242: software-properties-gtk: using http://security.debian.org/

[Arimil]

Package: software-properties-gtk
Version: 0.96.20.2-2.1
Followup-For: Bug #950232

Dear Maintainer,


   * What led up to the situation?
  
Updating to debian bullseye following 
https://wiki.debian.org/DebianUpgrade

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

I updated the security lines to "deb 
http://deb.debian.org/debian-security bullseye-security main" manually, this 
caused them to be listed under other software however. Removing the entries and 
re-enabling security updates adds "deb http://security.debian.org/ 
bullseye-security non-free contrib main" which functions but is not ideal.

   * What was the outcome of this action?

Security updates appear to be working with both domains, but I've been 
told security.debian.org is being phased out.


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

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

Versions of packages software-properties-gtk depends on:
ii  gir1.2-gtk-3.0   3.24.24-4+deb11u2
ii  python3  3.9.2-3
ii  python3-gi   3.38.0-2
ii  python3-software-properties  0.96.20.2-2.1
ii  software-properties-common   0.96.20.2-2.1

software-properties-gtk recommends no packages.

Versions of packages software-properties-gtk suggests:
ii  gnome-software  3.38.1-1

-- no debconf information

Bug#1023202: [l10n] Updated Czech translation of apt-listbugs

[Francesco Poli]

On Mon, 31 Oct 2022 15:25:53 +0100 Miroslav Kure wrote:

> Hi,

Hello Miroslav!   :-)

> 
> in attachement there is updated Czech (cs.po) translation of 
> apt-listbugs. Please include it with the package.

Thanks a lot for your very prompt answer to the call for translation
updates!
The updated file will be included in the next upload of the package.

Your contribution is really appreciated!
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpACixzh9Sd0.pgp
Description: PGP signature

Bug#1022806: linux-image-5.10.0-19-amd64: amggpu unbootable problem persists

[Andreas Wirooks]

On Fri, 28 Oct 2022 20:26:55 +0200 Gert  wrote:
> 5.19.0-0.deb11.2-amd64 works fine at first glance.

I am also affected and i also tried this kernel and it works as you can
read here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022042#160

I also filed a new drm bug here:

https://gitlab.freedesktop.org/drm/amd/-/issues/2237

Kind regards,

Andreas

Bug#1022042: Bug#1022025: fixed in linux 5.10.149-2

[Andreas Wirooks]

On Thu, 27 Oct 2022 19:12:43 + inasprecali 
wrote:
> I think bug 1022806 is a recent one referring to 5.10.149-2
> specifically, which is about this same issue. I don't think there
> is a need to report yet another bug about it.

Ok, then i switch to 1022806 too. I already created a new drm bug:

https://gitlab.freedesktop.org/drm/amd/-/issues/2237

Bug#1023241: openjdk-17-jre-headless: openjdk binfmts not correctly removed/set

[Christoph Anton Mitterer]

Package: openjdk-17-jre-headless
Version: 17.0.5+8-2
Severity: normal


Hey.

IIRC, this has happened with (all)? previous openjdk versions, when
transitioning from one major version to another, and presumably
also when simply purging openjdk.

The entries for update-binfmts are not correctly removed respectively
upgraded.

I've just switched from 11 to 17, but still:
~# update-binfmts --display
jar (enabled):
 package = openjdk-11
type = magic
  offset = 0
   magic = PK\x03\x04
mask = 
 interpreter = /usr/bin/jexec
detector = 

the registration is made for 11.

It probably doesn't matter so much (though it's a bit ugly), but I've
seen the maintainer scripts do contain some code which should properly
unregister/register, but that doesn't seem to work.


Any ideas? :-)

Thanks,
Chris.


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-17-jre-headless depends on:
ii  ca-certificates-java  20220719
ii  java-common   0.73
ii  libasound21.2.7.2-1
ii  libc6 2.35-4
ii  libcups2  2.4.2-1+b2
ii  libfontconfig12.13.1-4.5
ii  libfreetype6  2.12.1+dfsg-3
ii  libgcc-s1 12.2.0-7
ii  libharfbuzz0b 5.2.0-2
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  liblcms2-22.13.1-1+b1
ii  libnss3   2:3.83-1
ii  libpcsclite1  1.9.9-1
ii  libstdc++612.2.0-7
ii  util-linux2.38.1-1.1+b1
ii  zlib1g1:1.2.11.dfsg-4.1

openjdk-17-jre-headless recommends no packages.

Versions of packages openjdk-17-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

-- no debconf information

Bug#1008649: ITS: dokuwiki

[Axel Beckert]

Control: tag -1 + pending

Hi Daniel,

Axel Beckert wrote:
> But as its a thing which definitely needs a few hours of leisure in a
> row and to be on the safe side: If you don't see any obvious activity
> until the end of the month, feel free to take over without asking
> again.

Working on it right now. I took a few days off and now can invest
several hours in a row into such bigger makeovers.

Have already imported and pushed the relevant branches. But there's
still a lot of work ahead. Upload might no more happen this night.

> > or should/can I take over?
> 
> Shall I add you to Uploaders? I'd be happy to have another one on
> board because Anton looks a bit time-starved as well.

Friendly ping on this. :-)

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


signature.asc
Description: PGP signature

Bug#1023240: firmware-iwlwifi: iwlwifi-so-a0-gf-a0-72.ucode possibly missing

[Christoph Anton Mitterer]

Package: firmware-iwlwifi
Version: 20221012-1
Severity: normal


Hey there.

There possibly is a firmware file missing. In the kernel log I see:
# dmesg | grep -i wifi
[  158.112234] Intel(R) Wireless WiFi driver for Linux
[  158.114662] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-gf-a0-72.ucode (-2)
[  158.114669] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-gf-a0-72.ucode (-2)
[  158.114670] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-gf-a0-72.ucode failed with error -2
[  158.116799] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-so-a0-gf-a0-71.ucode
[  158.116804] iwlwifi :00:14.3: api flags index 2 larger than supported by 
driver
[  158.116822] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
[  158.117057] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[  158.117061] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[  158.117063] iwlwifi :00:14.3: loaded firmware version 71.058653f6.0 
so-a0-gf-a0-71.ucode op_mode iwlmvm
[  158.278035] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, 
REV=0x370
[  158.451222] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-so-a0-gf-a0.pnvm
[  158.451242] iwlwifi :00:14.3: loaded PNVM version 881c99e1
[  158.466456] iwlwifi :00:14.3: Detected RF GF, rfid=0x2010d000
[  158.536276] iwlwifi :00:14.3: base HW address: 7c:b5:66:f7:a8:a5
[  165.944059] iwlwifi :00:14.3: Unhandled alg: 0x707

So it first tries to load iwlwifi-so-a0-gf-a0-72.ucode, which fails and only
then tries iwlwifi-so-a0-gf-a0-71.ucode, which does in fact succeed...
and as far as I can see the device *is* working.

So maybe this is a non-issue, but maybe the missing file should be added.

Cheers,
Chris.


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1023225: esup-el: autopkgtest regression: No such file or directory, comp

[Adrian Bunk]

Control: block 1020178 by -1

On Mon, Oct 31, 2022 at 09:04:04PM +0100, Paul Gevers wrote:
>...
> With a recent upload of esup-el the autopkgtest of esup-el fails in testing
> when that autopkgtest is run with the binary packages of esup-el from
> unstable. It passes when run with only packages from testing. In tabular
> form:
> 
>passfail
> esup-elfrom testing0.7.1-4
> all others from testingfrom testing

But:
 pass
esup-el  from unstable
all others   from unstable

>...
> Paul
>...
> Cannot open load file: No such file or directory, comp
>...

I suspect the test-only fix for #1020178 that fixed the tests with Emacs 28
broke them with Emacs 27, so testing esup-el/unstable with emacs/unstable
should pass.

cu
Adrian

Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)

[Salvatore Bonaccorso]

Control: severity -1 important
Control: tags -1 + moreinfo

Hi Vincent,

On Mon, Oct 31, 2022 at 01:09:31PM +0100, Vincent Lefevre wrote:
> Package: src:linux
> Version: 6.0.5-1
> Severity: grave
> Justification: renders package unusable
> 
> (Setting to grave because Bluetooth is a major component.)
> 
> Bluetooth no longer works at all.
> 
> zira:~> journalctl -b -g bluetooth
> Oct 31 12:55:16 zira kernel: Bluetooth: Core ver 2.22
> Oct 31 12:55:16 zira kernel: NET: Registered PF_BLUETOOTH protocol family
> Oct 31 12:55:16 zira kernel: Bluetooth: HCI device and connection manager 
> initialized
> Oct 31 12:55:16 zira kernel: Bluetooth: HCI socket layer initialized
> Oct 31 12:55:16 zira kernel: Bluetooth: L2CAP socket layer initialized
> Oct 31 12:55:16 zira kernel: Bluetooth: SCO socket layer initialized
> Oct 31 12:55:17 zira systemd[1]: Starting Bluetooth service...
> Oct 31 12:55:17 zira systemd[795]: ConfigurationDirectory 'bluetooth' already 
> exists but the mode is different. (File system: 755 
> ConfigurationDirectoryMode: 555)
> Oct 31 12:55:17 zira bluetoothd[795]: Bluetooth daemon 5.65
> Oct 31 12:55:17 zira systemd[1]: Started Bluetooth service.
> Oct 31 12:55:17 zira systemd[1]: Reached target Bluetooth Support.
> Oct 31 12:55:17 zira bluetoothd[795]: Bluetooth management interface 1.22 
> initialized
> Oct 31 12:55:17 zira dbus-daemon[801]: [system] Activating via systemd: 
> service name='org.freedesktop.hostname1' 
> unit='dbus-org.freedesktop.hostname1.service' requested by ':1.2' (uid=0 
> pid=795 comm="/usr/libexec/bluetooth/bluetoothd")
> Oct 31 12:55:17 zira kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> Oct 31 12:55:17 zira kernel: Bluetooth: BNEP filters: protocol multicast
> Oct 31 12:55:17 zira kernel: Bluetooth: BNEP socket layer initialized
> Oct 31 12:55:17 zira NetworkManager[950]:   [1667217317.6273] Loaded 
> device plugin: NMBluezManager 
> (/usr/lib/x86_64-linux-gnu/NetworkManager/1.40.2/libnm-device-plugin-bluetooth.so)
> Oct 31 12:55:19 zira kernel: Bluetooth: hci0: Reading Intel version command 
> failed (-110)
> Oct 31 12:55:19 zira kernel: Bluetooth: hci0: command 0xfc05 tx timeout
> 
> With the 6.0.3-1 kernel version, I got:
> 
> Oct 31 11:17:59 zira kernel: Bluetooth: Core ver 2.22
> Oct 31 11:17:59 zira kernel: NET: Registered PF_BLUETOOTH protocol family
> Oct 31 11:17:59 zira kernel: Bluetooth: HCI device and connection manager 
> initialized
> Oct 31 11:17:59 zira kernel: Bluetooth: HCI socket layer initialized
> Oct 31 11:17:59 zira kernel: Bluetooth: L2CAP socket layer initialized
> Oct 31 11:17:59 zira kernel: Bluetooth: SCO socket layer initialized
> Oct 31 11:17:59 zira kernel: Bluetooth: hci0: Legacy ROM 2.5 revision 8.0 
> build 2 week 3 2013
> Oct 31 11:17:59 zira kernel: bluetooth hci0: firmware: direct-loading 
> firmware intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
> Oct 31 11:17:59 zira kernel: Bluetooth: hci0: Intel Bluetooth firmware file: 
> intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
> Oct 31 11:17:59 zira systemd[1]: Starting Bluetooth service...
> [...]
> 
> So it appears that the 6.0.5-1 kernel version can't load the firmware.

There were no Bluetooth related changes in the relatively small 6.0.3
to 6.0.5 update and I cannot reproduce the issue. Can you provide the
full boot and kernel logs? (ideally from both runs).

Regards,
Salvatore

Bug#1023239: dracut: [regression] missing grep

[Bastien Roucariès]

Package: dracut
Version: 056-3
Severity: critical
Tags: patch upstream
Justification: breaks the whole system
Forwarded: 
https://github.com/dracutdevs/dracut/commit/79f9d9e1c29a9c8fc046ab20765e5bde2aaa3428

Dear Maintainer,

grep is missing failling with lvm main partition.

Could you apply patch from upstream ?

Bastien


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

Kernel: Linux 5.19.0-2-rt-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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dracut depends on:
ii  dracut-core  056-3

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1023238: libdecaf please migrate to python3

[Paul Gevers]

Source: libdecaf
Version: 1.0.1-2
Severity: serious
Justification: rt
Control: fixed -1 1.0.2-1

Dear maintainers,

If I didn't make a mistake, wand is keeping python2.7 in the key package 
set because it (Build-)Depends on it. We're trying hard to remove 
python2.7 before the bookworm release. libdecaf seems to be one of two 
last packages blocking removal.


I note that a recent upload in experimental already build depends on 
python3. The Release Team would appreciate it if you don't wait to long 
with uploading to unstable if no further concerns block that decision.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017723: bullseye-pu: package nftables/0.9.8-3.2

[Jeremy Sowden]

On 2022-09-04, at 15:09:10 +0100, Jeremy Sowden wrote:
> On 2022-09-03, at 14:53:45 +0100, Adam D. Barratt wrote:
> > On Fri, 2022-08-19 at 16:05 +0100, Jeremy Sowden wrote:
> > > The related nftables bug is:
> > > 
> > >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017359
> > > 
> > > [ Reason ]
> > > nftables uses a fixed-size array containing the locations of the
> > > expressions within each rule that it sends to the kernel to provide
> > > more informative error-reporting.  If the rule is rejected by the
> > > kernel, the kernel will provide an ID for the expression which was
> > > responsible, and nftables will use this to highlight it when
> > > outputting the rule in the error message:
> > > 
> > >  # nft add rule t c iif lo reject with icmp 255
> > >  Error: Could not process rule: Invalid argument
> > >  add rule t c iif lo reject with icmp 255
> > >  ^^
> > > 
> > > There is an off-by-one error in the bounds-checking used before
> > > adding the details of an expression to this array.  The result of
> > > this is that if a rule contains enough expressions, nftables will
> > > write past the end of the array leading to memory-corruption and
> > > possibly crashes.
> > 
> > The debdiff is somewhat confusing.
> > 
> > +nftables (0.9.8-3.2) unstable; urgency=medium
> > 
> > This is an upload to bullseye, not unstable. Additionally, the version
> > should be 0.9.8-3.1+deb11u1.
> > 
> > + -- Sven Auhagen   Sat, 16 Jul 2022 11:29:27 
> > +0200
> > 
> > Who is this? It's obviously not you, but also doesn't appear to be
> > related to the nftables bug report you mentioned.
> 
> Whoops.  Silly mistakes.  Still learning the ropes.  I've amended the
> change-log entry.
> 
> I've also added myself to `Uploaders` (I am already listed as one in
> testing and unstable).
> 
> New debdiff attached.

Is there anything more I can to do to get a decision on this bug?  Or do
I just need to be more patient? :)

J.

> diff -Nru nftables-0.9.8/debian/changelog nftables-0.9.8/debian/changelog
> --- nftables-0.9.8/debian/changelog   2021-07-20 09:01:47.0 +0100
> +++ nftables-0.9.8/debian/changelog   2022-09-04 09:34:11.0 +0100
> @@ -1,3 +1,14 @@
> +nftables (0.9.8-3.1+deb11u1) bullseye; urgency=medium
> +
> +  * d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
> +It fixes a one off for the check for NFT_NLATTR_LOC_MAX
> +which leads to double free or corruption (out) error.
> +Thanks to Sven Auhagen  for
> +suggesting the fix (closes: #1017359).
> +  * d/control: add myself to uploaders.
> +
> + -- Jeremy Sowden   Sun, 04 Sep 2022 09:34:11 +0100
> +
>  nftables (0.9.8-3.1) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -Nru nftables-0.9.8/debian/control nftables-0.9.8/debian/control
> --- nftables-0.9.8/debian/control 2021-07-20 09:01:47.0 +0100
> +++ nftables-0.9.8/debian/control 2022-09-04 09:34:11.0 +0100
> @@ -2,7 +2,8 @@
>  Section: net
>  Priority: important
>  Maintainer: Debian Netfilter Packaging Team 
> 
> -Uploaders: Arturo Borrero Gonzalez 
> +Uploaders: Arturo Borrero Gonzalez ,
> +   Jeremy Sowden 
>  Build-Depends: asciidoc-base,
> automake,
> bison,
> diff -Nru 
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
>  
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
> --- 
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
>   1970-01-01 01:00:00.0 +0100
> +++ 
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
>   2022-09-04 09:26:53.0 +0100
> @@ -0,0 +1,32 @@
> +From 2d0a7a9adeb30708d6fbbee57476c0d4b9214dbd Mon Sep 17 00:00:00 2001
> +From: Phil Sutter 
> +Date: Fri, 11 Jun 2021 17:08:34 +0200
> +Subject: rule: Fix for potential off-by-one in cmd_add_loc()
> +
> +Using num_attrs as index means it must be at max one less than the
> +array's size at function start.
> +
> +Fixes: 27362a5bfa433 ("rule: larger number of error locations")
> +Signed-off-by: Phil Sutter 
> +---
> + src/rule.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +(limited to 'src/rule.c')
> +
> +diff --git a/src/rule.c b/src/rule.c
> +index dbbe744e..92daf2f3 100644
> +--- a/src/rule.c
>  b/src/rule.c
> +@@ -1275,7 +1275,7 @@ struct cmd *cmd_alloc(enum cmd_ops op, enum cmd_obj 
> obj,
> + 
> + void cmd_add_loc(struct cmd *cmd, uint16_t offset, const struct location 
> *loc)
> + {
> +-if (cmd->num_attrs > NFT_NLATTR_LOC_MAX)
> ++if (cmd->num_attrs >= NFT_NLATTR_LOC_MAX)
> + return;
> + 
> + cmd->attr[cmd->num_attrs].offset = offset;
> +-- 
> +cgit v1.2.3
> +
> diff -Nru nftables-0.9.8/debian/patches/series 
> nftables-0.9.8/debian/patches/series
> --- nftables-0.9.8/debian/patches/series  2021-07-20 09:01:47.0 
> +0100
> +++ nftables-0.9.8/debian/patches/series  

Bug#1023237: openjdk-11: Keep out of testing and stable

[Emmanuel Bourg]

Source: openjdk-11
Version: 11.0.4+11-1
Severity: serious
Justification: should not migrate to testing or stable any more


openjdk-17 is now the default JDK, but openjdk-11 is still required for
bootstrapping JVM-based languages like Kotlin or Scala in unstable.
Therefore the package should no longer migrate to testing or stable anymore.

Bug#1023236: ITP: plasma-mobile -- Open-source user interface for phones, based on Plasma technologies

[Marco Mattiolo]

Package: wnpp
Severity: wishlist
Owner: Marco Mattiolo 
X-Debbugs-Cc: debian-de...@lists.debian.org, marco.matti...@hotmail.it

* Package name    : plasma-mobile
  Version : 5.26.z
  Upstream Author : 
* URL : https://invent.kde.org/plasma/plasma-mobile
* License : GPL
  Programming Lang: QML, C++
  Description : Open-source user interface for phones, based on 
Plasma technologies


 Plasma Mobile is an open-source user interface and ecosystem targeted at
 mobile devices, built on the KDE Plasma stack.
 A pragmatic approach is taken that is inclusive to software regardless of
 toolkit, giving users the power to choose whichever software they want to
 use on their device.
 Plasma Mobile aims to contribute to and implement open standards, and is
 developed in a transparent process that is open for anyone to 
participate in.


Plasma Mobile provides a graphical interfaces for touch devices like
smartphones or tablets, including (but not limited to) PinePhone(Pro),
Librem5, OnePlus6, ...
Plasma Mobile is actually provided by mobile distributions like postmaketOS
or Manjaro. A Debian packaging suite is available at an external repository
maintained by one Plasma developer, who is not willing to include the
packages into Debian. Having Plasma mobile packaged inside Debian main
repository enables the creation of Plasma-based Mobian images.
As of October 2022, a few desktop environments for touch-devices are 
available

at Debian, like Phosh and SXMO, but none of them is IMHO at Plasma's level.
I have been using Plasma mobile packaged by JBB for months on my Pinephone,
but its stability was not very good as the maintainer was admittedly 
uploading

packages to his repo without testing them.
I already have a working 5.26.0 package and I am having it reviewed 
inside the

DebianOnMobile team.

Bug#1013276: Alsa clients using the wrong plugin if pulseaudio is installed

[Sebastien Bacher]

Thanks Dylan. I think the bug references are inverted but the fix pushed 
to the vcs to actually provide the alsa configuration should resolved 
the issue!


Cheers,
Sebastien

Le 28/10/2022 à 17:49, Dylan Aïssi a écrit :

Hi Sebastien,

Le lun. 10 oct. 2022 à 14:00, Sebastien Bacher  a écrit :

Reopening, I think the decision to revert is unfortunate. Nothing is
going to remove pulseaudio on upgrade as pipewire-pulse gets pulled in
as the new default; and the pulseaudio package provides an alsa
configuration which creates issues for pipewire.

You are basically making the new default sound service be misconfigured
for most users for the benefit of a few who want to be able to switch by
masking the service instead of removing pulseaudio...

Could we reconsider?

The initial bug report on Launchpad [1] is confusing and is mixing several
issues as I just explained. I do not see a conflict between pulseaudio and
pipewire in [1]. The only part we can improve is to install pipewire-alsa conf
files in the right location to enable it by default (it was already
in my todo list [2]).

I propose to close #1013276 and to continue the discussion of an eventual
conflict between pulseaudio and pipewire in #1020903 to avoid noise with
unrelated issues.

Best,
Dylan

[1] https://bugs.launchpad.net/bugs/1975823
[2] 
https://salsa.debian.org/utopia-team/pipewire/-/blob/debian/master/debian/pipewire-alsa.TODO

Bug#1023233: optee-client FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: optee-client
Version: 3.19.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

optee-client fails to cross build from source, because the upstream
Makefiles hard code the build architecture pkg-config. Please consider
applying the attached patch to fix the cross build.

Helmut
--- optee-client-3.19.0.orig/Makefile
+++ optee-client-3.19.0/Makefile
@@ -52,7 +52,7 @@
 
 check-libuuid:
 	@echo "Finding uuid.pc"
-	pkg-config --atleast-version=2.34 uuid
+	$(PKG_CONFIG) --atleast-version=2.34 uuid
 
 install: copy_export
 
--- optee-client-3.19.0.orig/flags.mk
+++ optee-client-3.19.0/flags.mk
@@ -5,6 +5,7 @@
 CROSS_COMPILE   ?= 
 CC  ?= $(CROSS_COMPILE)gcc
 AR		?= $(CROSS_COMPILE)ar
+PKG_CONFIG	?= $(CROSS_COMPILE)pkg-config
 
 override CFLAGS += -Wall -Wbad-function-cast -Wcast-align \
 		   -Werror-implicit-function-declaration -Wextra \
--- optee-client-3.19.0.orig/libteeacl/Makefile
+++ optee-client-3.19.0/libteeacl/Makefile
@@ -27,10 +27,10 @@
 LIBTEEACL_INCLUDES	= ${CURDIR}/include
 
 LIBTEEACL_CFLAGS	:= $(addprefix -I, $(LIBTEEACL_INCLUDES)) \
-			$(shell pkg-config --cflags uuid) \
+			$(shell $(PKG_CONFIG) --cflags uuid) \
 			$(CFLAGS) -D_GNU_SOURCE -fPIC
 
-LIBTEEACL_LFLAGS	:= $(LDFLAGS) $(shell pkg-config --libs uuid)
+LIBTEEACL_LFLAGS	:= $(LDFLAGS) $(shell $(PKG_CONFIG) --libs uuid)
 
 LIBTEEACL_OBJ_DIR	:= $(OUT_DIR)
 LIBTEEACL_OBJS	:= $(patsubst %.c,$(LIBTEEACL_OBJ_DIR)/%.o, $(LIBTEEACL_SRCS))

Bug#1023235: synthv1 FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: synthv1
Version: 0.9.24-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

synthv1 fails to cross build from source, because the upstream
CMakeLists.txt hard code the build architecture strip. Beyond breaking
cross compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. Please consider applying the attached
patch to fix all of the above.

Helmut
diff --minimal -Nru synthv1-0.9.27/debian/changelog 
synthv1-0.9.27/debian/changelog
--- synthv1-0.9.27/debian/changelog 2022-10-06 23:27:01.0 +0200
+++ synthv1-0.9.27/debian/changelog 2022-10-31 15:02:25.0 +0100
@@ -1,3 +1,10 @@
+synthv1 (0.9.27-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 31 Oct 2022 15:02:25 +0100
+
 synthv1 (0.9.27-1) unstable; urgency=medium
 
   * New upstream version 0.9.27
diff --minimal -Nru synthv1-0.9.27/debian/patches/cross.patch 
synthv1-0.9.27/debian/patches/cross.patch
--- synthv1-0.9.27/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ synthv1-0.9.27/debian/patches/cross.patch   2022-10-31 15:02:11.0 
+0100
@@ -0,0 +1,39 @@
+--- synthv1-0.9.27.orig/CMakeLists.txt
 synthv1-0.9.27/CMakeLists.txt
+@@ -53,6 +53,7 @@
+ endif ()
+ 
+ set (CONFIG_PREFIX "${CMAKE_INSTALL_PREFIX}")
++set (CONFIG_STRIP "strip" CACHE STRING "Utility used for stripping objects")
+ 
+ include (GNUInstallDirs)
+ set (CONFIG_BINDIR  "${CONFIG_PREFIX}/${CMAKE_INSTALL_BINDIR}")
+--- synthv1-0.9.27.orig/src/CMakeLists.txt
 synthv1-0.9.27/src/CMakeLists.txt
+@@ -174,7 +174,7 @@
+   if (UNIX AND NOT APPLE)
+ if (NOT CONFIG_DEBUG)
+   add_custom_command(TARGET ${PROJECT_NAME}_lv2  POST_BUILD
+-COMMAND strip lib${PROJECT_NAME}_lv2.so)
++COMMAND ${CONFIG_STRIP} lib${PROJECT_NAME}_lv2.so)
+ endif ()
+ if (CONFIG_PREFIX MATCHES $ENV{HOME})
+   set (CONFIG_LV2DIR ${CONFIG_PREFIX}/.lv2)
+@@ -193,7 +193,7 @@
+ target_link_options (${PROJECT_NAME}_lv2 PRIVATE -static-libgcc 
-static-libstdc++)
+ if (NOT CONFIG_DEBUG)
+   add_custom_command(TARGET ${PROJECT_NAME}_lv2  POST_BUILD
+-COMMAND strip lib${PROJECT_NAME}_lv2.dll)
++COMMAND ${CONFIG_STRIP} lib${PROJECT_NAME}_lv2.dll)
+ endif ()
+ set (CONFIG_LV2DIR ${CONFIG_WINDOWS_LV2_PATH})
+ install (FILES ${CMAKE_CURRENT_BINARY_DIR}/lib${PROJECT_NAME}_lv2.dll
+@@ -223,7 +223,7 @@
+   if (UNIX AND NOT APPLE)
+ if (NOT CONFIG_DEBUG)
+   add_custom_command(TARGET ${PROJECT_NAME}_jack POST_BUILD
+-COMMAND strip ${PROJECT_NAME}_jack)
++COMMAND ${CONFIG_STRIP} ${PROJECT_NAME}_jack)
+ endif ()
+ install (TARGETS ${PROJECT_NAME}_jack RUNTIME
+   DESTINATION ${CMAKE_INSTALL_BINDIR})
diff --minimal -Nru synthv1-0.9.27/debian/patches/series 
synthv1-0.9.27/debian/patches/series
--- synthv1-0.9.27/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ synthv1-0.9.27/debian/patches/series2022-10-31 15:01:34.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru synthv1-0.9.27/debian/rules synthv1-0.9.27/debian/rules
--- synthv1-0.9.27/debian/rules 2022-10-06 11:05:29.0 +0200
+++ synthv1-0.9.27/debian/rules 2022-10-31 15:02:23.0 +0100
@@ -9,6 +9,7 @@
 else
  CMAKE_OPTS = -DCONFIG_ALSA_MIDI=OFF
 endif
+CMAKE_OPTS += -DCONFIG_STRIP=/bin/true
 
 %:
dh $@

Bug#1023234: gnuradio FTCBFS: unsatisfiable sphinx dependency

[Helmut Grohne]

Source: gnuradio
Version: 3.10.4.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

gnuradio cannot be cross built from source, because its dependency on
sphinx is not cross satisfiable. As it happens, the Debian build of
gnuradio does not actually run sphinx even though there are some sphinx
sources. As such it can be deleted. Almost that is. python3-sphinx
happens to pull python3-packaging, which is not otherwise declared in
Build-Depends but is essential to building gnuradio. It's a missing
Build-Dependency that is hidden by python3-sphinx. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru gnuradio-3.10.4.0/debian/changelog 
gnuradio-3.10.4.0/debian/changelog
--- gnuradio-3.10.4.0/debian/changelog  2022-10-26 02:03:42.0 +0200
+++ gnuradio-3.10.4.0/debian/changelog  2022-10-31 12:16:09.0 +0100
@@ -1,3 +1,10 @@
+gnuradio (3.10.4.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused B-D: python3-sphinx. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 31 Oct 2022 12:16:09 +0100
+
 gnuradio (3.10.4.0-3) unstable; urgency=medium
 
   * update to v3.10.4.0-17-gcfcd070f9
diff --minimal -Nru gnuradio-3.10.4.0/debian/control 
gnuradio-3.10.4.0/debian/control
--- gnuradio-3.10.4.0/debian/control2022-10-26 02:03:42.0 +0200
+++ gnuradio-3.10.4.0/debian/control2022-10-31 12:16:09.0 +0100
@@ -58,10 +58,10 @@
python3-mako,
python3-numpy,
python3-opengl,
+   python3-packaging,
   python3-pyqt5 [!hurd-i386],
   python3-schema,
python3-scipy,
-   python3-sphinx,
   python3-thrift [amd64 arm64 armel armhf i386 mips64el mipsel 
ppc64el riscv64 s390x],
   python3-yaml,
python3-zmq [!hurd-i386],

Bug#1023232: samplv1 FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: samplv1
Version: 0.9.27-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

samplv1 fails to cross build from source, because the upstream
CMakeLists.txt hard code the build architecture strip. Beyond breaking
cross compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. Please consider applying the attached
patch to fix all of the above.

Helmut
diff --minimal -Nru samplv1-0.9.27/debian/changelog 
samplv1-0.9.27/debian/changelog
--- samplv1-0.9.27/debian/changelog 2022-10-06 23:29:26.0 +0200
+++ samplv1-0.9.27/debian/changelog 2022-10-31 21:34:20.0 +0100
@@ -1,3 +1,10 @@
+samplv1 (0.9.27-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 31 Oct 2022 21:34:20 +0100
+
 samplv1 (0.9.27-1) unstable; urgency=medium
 
   * New upstream version 0.9.27
diff --minimal -Nru samplv1-0.9.27/debian/patches/cross.patch 
samplv1-0.9.27/debian/patches/cross.patch
--- samplv1-0.9.27/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ samplv1-0.9.27/debian/patches/cross.patch   2022-10-31 21:34:18.0 
+0100
@@ -0,0 +1,39 @@
+--- samplv1-0.9.27.orig/CMakeLists.txt
 samplv1-0.9.27/CMakeLists.txt
+@@ -53,6 +53,7 @@
+ endif ()
+ 
+ set (CONFIG_PREFIX "${CMAKE_INSTALL_PREFIX}")
++set (CONFIG_STRIP "strip" CACHE STRING "Utility used for stripping objects")
+ 
+ include (GNUInstallDirs)
+ set (CONFIG_BINDIR  "${CONFIG_PREFIX}/${CMAKE_INSTALL_BINDIR}")
+--- samplv1-0.9.27.orig/src/CMakeLists.txt
 samplv1-0.9.27/src/CMakeLists.txt
+@@ -197,7 +197,7 @@
+   if (UNIX AND NOT APPLE)
+ if (NOT CONFIG_DEBUG)
+   add_custom_command(TARGET ${PROJECT_NAME}_lv2  POST_BUILD
+-COMMAND strip lib${PROJECT_NAME}_lv2.so)
++COMMAND ${CONFIG_STRIP} lib${PROJECT_NAME}_lv2.so)
+ endif ()
+ if (CONFIG_PREFIX MATCHES $ENV{HOME})
+   set (CONFIG_LV2DIR ${CONFIG_PREFIX}/.lv2)
+@@ -216,7 +216,7 @@
+ target_link_options (${PROJECT_NAME}_lv2 PRIVATE -static-libgcc 
-static-libstdc++)
+ if (NOT CONFIG_DEBUG)
+   add_custom_command(TARGET ${PROJECT_NAME}_lv2  POST_BUILD
+-COMMAND strip lib${PROJECT_NAME}_lv2.dll)
++COMMAND ${CONFIG_STRIP} lib${PROJECT_NAME}_lv2.dll)
+ endif ()
+ set (CONFIG_LV2DIR ${CONFIG_WINDOWS_LV2_PATH})
+ install (FILES ${CMAKE_CURRENT_BINARY_DIR}/lib${PROJECT_NAME}_lv2.dll
+@@ -246,7 +246,7 @@
+   if (UNIX AND NOT APPLE)
+ if (NOT CONFIG_DEBUG)
+   add_custom_command(TARGET ${PROJECT_NAME}_jack POST_BUILD
+-COMMAND strip ${PROJECT_NAME}_jack)
++COMMAND ${CONFIG_STRIP} ${PROJECT_NAME}_jack)
+ endif ()
+ install (TARGETS ${PROJECT_NAME}_jack RUNTIME
+   DESTINATION ${CMAKE_INSTALL_BINDIR})
diff --minimal -Nru samplv1-0.9.27/debian/patches/series 
samplv1-0.9.27/debian/patches/series
--- samplv1-0.9.27/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ samplv1-0.9.27/debian/patches/series2022-10-31 21:33:29.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru samplv1-0.9.27/debian/rules samplv1-0.9.27/debian/rules
--- samplv1-0.9.27/debian/rules 2022-10-06 11:05:05.0 +0200
+++ samplv1-0.9.27/debian/rules 2022-10-31 21:34:20.0 +0100
@@ -9,6 +9,7 @@
 else
  CMAKE_OPTS = -DCONFIG_ALSA_MIDI=OFF
 endif
+CMAKE_OPTS += -DCONFIG_STRIP=/bin/true
 
 %:
dh $@

Bug#1023231: cimg: autopkgtest failure everywhere but on amd64: './libHalf.so': File exists

[Paul Gevers]

Source: cimg
Version: 3.1.6+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package cimg, great. However, 
it fails everywhere but on amd64. Currently this failure is blocking the 
migration to testing [1]. Can you please investigate the situation and 
fix it?


I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=cimg

https://ci.debian.net/data/autopkgtest/testing/arm64/c/cimg/27599388/log.gz

make[1]: Entering directory 
'/tmp/autopkgtest-lxc.1l29kob2/downtmp/autopkgtest_tmp'

grep: ../CImg.h: No such file or directory
grep: ../CImg.h: No such file or directory
grep: ../CImg.h: No such file or directory

** Compiling 'CImg_demo (..)' with 'gcc version 12.2.0 (Debian 12.2.0-3) '

Hack to provide -lIlmImf and -lHalf
if [ ! -e ./libHalf.so ] ; then   ln -s `find /usr/lib -type l -name 
"libHalf-2_5.so.*"`   ./libHalf.so ; fi

ln: failed to create symbolic link './libHalf.so': File exists
make[1]: *** [Makefile:322: CImg_demo] Error 1
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.1l29kob2/downtmp/autopkgtest_tmp'

make: *** [Makefile:459: Mlinux] Error 2
autopkgtest [17:13:51]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023230: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: test times out after 2:47 hours

[Paul Gevers]

Source: t-coffee, libbio-tools-run-alignment-tcoffee-perl
Control: found -1 t-coffee/13.45.0.4846264+dfsg-1
Control: found -1 libbio-tools-run-alignment-tcoffee-perl/1.7.4-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of t-coffee the autopkgtest of 
libbio-tools-run-alignment-tcoffee-perl fails in testing on all 
architectures but amd64 and i386 when that autopkgtest is run with the 
binary packages of t-coffee from unstable. It passes when run with only 
packages from testing. In tabular form:


  passfail
t-coffee  from testing13.45.0.4846264+dfsg-1
libbio-tools-run-alignment-tcoffee-perl from testing1.7.4-3
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report. There's 
nothing there, it just waits for the timeout after 2:47h.


Currently this regression is blocking the migration of t-coffee to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=t-coffee

https://ci.debian.net/data/autopkgtest/testing/arm64/libb/libbio-tools-run-alignment-tcoffee-perl/27686780/log.gz

autopkgtest [11:59:24]: ERROR: timed out on command "su -s /bin/bash 
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || 
true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.l1eqkc21/downtmp/build.05l/src"; mkdir 
-p -m 1777 -- 
"/tmp/autopkgtest-lxc.l1eqkc21/downtmp/autodep8-perl-build-deps-artifacts"; 
export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.l1eqkc21/downtmp/autodep8-perl-build-deps-artifacts"; 
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.l1eqkc21/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.l1eqkc21/downtmp/autopkgtest_tmp"; 
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; 
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE 
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES 
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL;cd "$buildtree"; exec 
/tmp/autopkgtest-lxc.l1eqkc21/downtmp/wrapper.sh 
--script-pid-file=/tmp/autopkgtest_script_pid 
--stderr=/tmp/autopkgtest-lxc.l1eqkc21/downtmp/autodep8-perl-build-deps-stderr 
--stdout=/tmp/autopkgtest-lxc.l1eqkc21/downtmp/autodep8-perl-build-deps-stdout 
-- bash -ec '/usr/share/pkg-perl-autopkgtest/runner build-deps' ;" 
(kind: test)

autopkgtest [11:59:24]: test autodep8-perl-build-deps



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022926: transition: glibc 2.36

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2022-10-30 19:06:09 +0100, Aurelien Jarno wrote:
> On 2022-10-30 17:10, Sebastian Ramacher wrote:
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/glibc-2.36.html
> > Control: tags -1 moreinfo
> > 
> > On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote:
> > > 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.36. It has been
> > > available in experimental for a bit more than 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.]* \(< > >   is_good = .depends ~ /libc[0-9.]* \(<< 2.37\)/;
> > >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> > > 
> > > In addition a few new symbols have been added that might prevent a few
> > > other packages to migrate to testing until glibc migrates if they pick
> > > up the new symbols, however those are really limited in this version and
> > > mostly linked to new filesystem, processes or random functions, so
> > > unlikely to be massively used by default.
> > > 
> > > Note that this version builds with GCC 12 instead of GCC 11, so it is a
> > > prerequisite for not shipping bookworm with GCC 11.
> > 
> > Speaking of GCC 12 … #1022991 seems to have a first patch available
> > upstream. Is there any chance that we could start this transition
> > together with a fix for that bug?
> 
> I would not say we have patch yet. I posted a first patch on the mailing
> list yesterday [1], and we have two epidermic answers from both sides
> ("Why this patch is approved?" or "So MIPS ABI idiocrasies strike
> again"). One come with a proposal and another one with a partial patch.
> So that's 3 different options in total. I am also worried that the
> problem could be more widespread as there is a claim that clock_adjtime
> is broken on all 64bit system.
> 
> So IMHO, we should just wait that things calm done, and that people
> really try to understand the problem, its consequences and how to fix
> it, instead of just proposing random patches.
> 
> But once we have something acceptable, I am find including it either in
> a 2.35 upload or a 2.36 one, both are fine to me.

Okay, then let's not wait for #1022991. None of the reverse dependencies
should get stuck behind gcc-12. Please go ahead with this transition.

Cheers
-- 
Sebastian Ramacher

Bug#1023229: f3d: autopkgtest regression on s390x: Compare with ref failed

[Paul Gevers]

Source: f3d
Version: 1.3.1+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of f3d the autopkgtest of f3d fails in testing when 
that autopkgtest is run with the binary packages of f3d from unstable. 
It passes when run with only packages from testing. In tabular form:


   passfail
f3dfrom testing1.3.1+dfsg-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. I note that 
s390x is our only big endian release architecture (just in case that 
matters to the problem at hand).


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=f3d

https://ci.debian.net/data/autopkgtest/testing/s390x/f/f3d/27693775/log.gz

==
Smoke Test
==
No config file found
Loading: /tmp/autopkgtest-lxc.dd0h8lat/downtmp/autopkgtest_tmp/cube.dae

Warning: In 
./library/VTKExtensions/Readers/vtkF3DAssimpImporter.cxx, line 583
vtkF3DAssimpImporter (0x2aa2fdf42f0): Assimp failed to load: 
/tmp/autopkgtest-lxc.dd0h8lat/downtmp/autopkgtest_tmp/cube.dae



No camera available in this file



Camera position: 0,0,1
Camera focal point: 0,0,0
Camera view up: 0,1,0
Camera view angle: 30


===
Generate the new screenshot
===

Compare with ref

Comparing "debian/tests/cube_dae_ref.png" and 
"/tmp/autopkgtest-lxc.dd0h8lat/downtmp/check-cube-dae-artifacts/cube_dae.png"

  Mean error = 0.0898372
  RMS error = 0.250222
  Peak SNR = 12.0335
  Max error  = 0.72549 @ (393, 106, R)  values are 0.92549, 0.92549, 
0.92549 vs 0.2, 0.2, 0.2

  47288 pixels (15.4%) over 1e-06
  47288 pixels (15.4%) over 1e-06
FAILURE
autopkgtest [06:20:10]: test check-cube-dae



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023111: apt-listbugs: Ignores release-related tags (sid, bookwork, etc.) in bug reports causing false positives, e.g. lists bugs in stable which are only tagged sid and bookworm

[Axel Beckert]

Hi Francesco,

Francesco Poli wrote:
> > apt-listbugs doesn't seem to care about release-related tags in the BTS,
> > e.g. shows RC bugs on stable which are tagged sid and (currently)
> > bookworm in the BTS and hence don't apply to the same (or similar)
> > version in stable.
> 
> That's true, it does not take those tags into account.
> 
> It has a "-T" option to filter by tags, but I don't think it's too
> useful in your use case, since you want to see bugs without
> release-related tags plus bugs with the release-related tag which refers
> to your own release...

Ack.

> > This causes false positives and unnecessarily blocks
> > backported security updates of rolling-release packages like
> > firefox-esr, chromium, etc. as well as updates of packages in
> > -backports.
> 
> Frankly speaking, I have really rarely encountered such a situation
> myself. Hence, I have never felt an actual need for a special treatment
> of release-related tags...
> 
> However, when you encounter a situation like the one you described, you
> may take a look at the bug report (which is often a good thing to do,
> before deciding whether to pin the package or go ahead with the
> upgrade/installation) and immediately find out that the bug does not
> affect your system.

I think I forgot some context: I'm using apt-listbugs together with
automatically applying updates. I only see the result later in cron
job mails or in the monitoring.

> I acknowledge that this requires manual intervention and human
> judgment, but they are also needed for other kinds of bugs, unless you
> want to pin *any* buggy package, no matter what...

Actually another thing which annoyed me in the past, but I haven't
checked if it's still the case, but IIRC apt-listbugs in unattended
upgrade mode (at least in the past) has put packages completely on
hold instead of just forbidding to upgrade to an affected version.

> > So from my point of view, apt-listbugs should do the following:
> 
> Thank you for this feature request.
> I am setting the severity to "wishlist", since you are requesting the
> implementation of a new feature.

That's fair. Actually I was torn between important (as not having such
a feature causes false positives on holding back security updates) and
wishlist (because it _is_ a new feature which is necessary to fix this
issue).

> > * Check on which release it is running.
> 
> Which can be done, but is not always trivial.

True.

> For instance: how do I tell testing (currently "bookworm") and unstable
> ("sid") apart?

The admin can set a preferred release via APT::Default-Release. That's
one source for a decision. If this is not set, the output of
"apt-cache policy" without a parameter should give an idea. If
multiple repos with different releases are at the highest rank, that
logic probably should be skipped.

> With some pin-priorities set, it is easy to run a mix of the two.
> So: how should I consider testing with some packages from unstable (or
> even experimental)? as "bookworm"? or as "sid"?

Maybe skip that logic all together. At least my use case for that is
mostly security updates in stable vs tagged bugs in unstable.

> What about stable (currently "bullseye") with many packages backported
> from testing or unstable?

That's clearly bullseye then IMHO. (Given that these backports are
official ones. Otherwise they probably wouldn't come via (offiial) apt
repos.

> > * Only take RC bugs into account, which are either not tagged for any
> >   release at all (and where hence only the affected versions are
> >   relevant) or which are (also) tagged for the current release.
> > 
> > To do that it seems only marginally necessary how other releases a named
> > as it only needs to know the release name of the release its running
> > on. For that it should suffice to know a list of all tags which are
> > _not_ release names.
> 
> This would require heavy maintenance on my side, since I would need to
> be very prompt to update this list, as soon as a new
> non-release-related tag is added to the Debian BTS.

Yep. But then again this seems to happen rather seldom to me.

> Moreover, other Debian-based distributions could decide to use a BTS
> based on debbugs (I don't know whether there are any _today_, but there
> could be some _in the future_), and they could use a slightly different
> version of debbugs or a fork with different non-release-related
> tags.

Good point. At least the GNU project also uses debbugs. Not sure if
it's only used for upstream work or if also some Debian derivates
(Trisquel comes to my mind) use it.

> This would mean even more maintenance on the side of anyone who would
> port apt-listbugs to that distribution...

Ack.

> All this looks a bit fragile: for instance, suppose a new
> non-release-related tag is implemented in the Debian BTS (I think the
> last addition was 'newcomer') and apt-listbugs is not promptly updated
> to recognize that new non-release-related tag. An unaware apt-listbugs
> would consider 

Bug#1023228: gatb-core: autopkgtest failure: fails on architectures where arch:any doesn't build

[Paul Gevers]

Source: gatb-core
Version: 1.4.2+dfsg-10
Severity: important
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package gatb-core, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report. I note that 
your package fails on the architectures where the built fails. I think 
this can be fixed by *not* specifying "@" in your test Dependencies, but 
the actual (arch:any) binaries you need to run your tests. If this 
doesn't help, please reach out to me and I can help solve the migration 
issue as a Release Team member.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gatb-core

https://ci.debian.net/data/autopkgtest/testing/armel/g/gatb-core/26961561/log.gz

autopkgtest [10:12:43]: starting date: 2022-10-11
autopkgtest [10:12:43]: version 5.26
autopkgtest [10:12:43]: host ci-worker-armel-03; command line: 
/usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo 
'"'"'gatb-core testing/armel'"'"' > /var/tmp/debci.pkg 2>&1 || true' 
'--setup-commands=echo '"'"'Acquire::Retries "10";'"'"' > 
/etc/apt/apt.conf.d/75retry 2>&1 || true' --user debci --apt-upgrade 
--add-apt-release=unstable --pin-packages=unstable=src:gatb-core 
--output-dir 
/tmp/debci-worker-26961561-vDyO8u1Wzp/autopkgtest-incoming/testing/armel/g/gatb-core/26961561 
gatb-core -- lxc --sudo --name ci-284-0808bf0b autopkgtest-testing-armel

autopkgtest [10:12:56]:  test bed setup
Get:1 http://deb.debian.org/debian unstable InRelease [161 kB]
Get:2 http://deb.debian.org/debian unstable/contrib Sources [58.5 kB]
Get:3 http://deb.debian.org/debian unstable/main Sources [9,977 kB]
Get:4 http://deb.debian.org/debian unstable/non-free Sources [90.6 kB]
Get:5 http://deb.debian.org/debian unstable/contrib armel Packages [47.1 kB]
Get:6 http://deb.debian.org/debian unstable/main armel Packages [8,933 kB]
Get:7 http://deb.debian.org/debian unstable/non-free armel Packages 
[62.6 kB]

Fetched 19.3 MB in 5s (3,840 kB/s)
Reading package lists...
Get:1 http://deb.debian.org/debian testing InRelease [164 kB]
Get:2 http://deb.debian.org/debian-debug testing-debug InRelease [53.1 kB]
Hit:3 http://deb.debian.org/debian unstable InRelease
Get:4 http://deb.debian.org/debian testing/main Sources.diff/Index [63.6 kB]
Get:5 http://deb.debian.org/debian testing/main armel 
Packages.diff/Index [63.6 kB]
Get:6 http://deb.debian.org/debian testing/main Sources 
T-2022-10-11-1403.13-F-2022-10-11-1403.13.pdiff [644 B]
Get:6 http://deb.debian.org/debian testing/main Sources 
T-2022-10-11-1403.13-F-2022-10-11-1403.13.pdiff [644 B]
Get:7 http://deb.debian.org/debian testing/main armel Packages 
T-2022-10-11-1403.13-F-2022-10-11-1403.13.pdiff [2,497 B]
Get:7 http://deb.debian.org/debian testing/main armel Packages 
T-2022-10-11-1403.13-F-2022-10-11-1403.13.pdiff [2,497 B]

Fetched 347 kB in 5s (74.5 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
autopkgtest [10:13:13]: testbed dpkg architecture: armel
autopkgtest [10:13:14]: testbed running kernel: Linux 5.10.0-18-arm64 #1 
SMP Debian 5.10.140-1 (2022-09-02)

autopkgtest [10:13:14]:  apt-source gatb-core
Get:1 http://deb.debian.org/debian unstable/main gatb-core 1.4.2+dfsg-10 
(dsc) [2,417 B]
Get:2 http://deb.debian.org/debian unstable/main gatb-core 1.4.2+dfsg-10 
(tar) [2,945 kB]
Get:3 http://deb.debian.org/debian unstable/main gatb-core 1.4.2+dfsg-10 
(diff) [98.1 kB]

gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.X962_0PM/trustedkeys.kbx': 
General error

gpgv: Signature made Tue 11 Oct 2022 08:21:07 AM CDT
gpgv:using RSA key F1F007320A035541F0A663CA578A0494D1C646D1
gpgv:issuer "ti...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: cannot verify signature ./gatb-core_1.4.2+dfsg-10.dsc
autopkgtest [10:13:18]: testing package gatb-core version 1.4.2+dfsg-10
autopkgtest [10:13:18]: build not needed
autopkgtest [10:13:18]: test run-unit-test: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) autopkgtest-satdep:armel < 0 @iU K Nb Ib >
Broken autopkgtest-satdep:armel Depends on gatb-core:armel < none @un H >
  Removing 

Bug#1023227: breezy: autopkgtest regression: Non-UTF-8 code starting with '\xf2' in file /usr/bin/brz

[Paul Gevers]

Source: breezy
Version: 3.3.0+bzr7661-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of breezy the autopkgtest of breezy fails in 
testing when that autopkgtest is run with the binary packages of breezy 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
breezy from testing3.3.0+bzr7661-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
breezy/3.3.0+bzr7661-2. I.e. due to versioned dependencies or 
breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=breezy

https://ci.debian.net/data/autopkgtest/testing/amd64/b/breezy/27685392/log.gz

SyntaxError: Non-UTF-8 code starting with '\xf2' in file /usr/bin/brz on 
line 2, but no encoding declared; see 
https://python.org/dev/peps/pep-0263/ for details

autopkgtest [23:12:42]: test testsuite3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023226: pg-fact-loader: autopkgtest regression

[Paul Gevers]

Source: pg-fact-loader
Version: 1.7.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pg-fact-loader the autopkgtest of pg-fact-loader 
fails in testing when that autopkgtest is run with the binary packages 
of pg-fact-loader from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
pg-fact-loader from testing1.7.0-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
pg-fact-loader/1.7.0-2. I.e. due to versioned dependencies or 
breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=pg-fact-loader

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pg-fact-loader/27687022/log.gz

### PostgreSQL 15 installcheck ###
Creating new PostgreSQL cluster 15/regress ...
echo "+++ regress install-check in  +++" && 
/usr/lib/postgresql/15/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress 
--inputdir=./ --bindir='/usr/lib/postgresql/15/bin' 
--dbname=contrib_regression 01_create_ext 02_schema 03_audit 04_seeds 
05_pgl_setup 06_basic_workers 07_launch_worker 08_fact_table_deps 
09_purge 10_delete 11_more_data 12_no_proid 13_cutoff_no_dep_on_filter 
14_null_key 15_source_change_date 16_1_2_features 17_1_3_features

+++ regress install-check in  +++
(using postmaster on localhost, port 5433)
== dropping database "contrib_regression" ==
SET
DROP DATABASE
== creating database "contrib_regression" ==
CREATE DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
ALTER DATABASE
== running regression test queries==
test 01_create_ext... ok  146 ms
test 02_schema... ok   92 ms
test 03_audit ... ok   41 ms
test 04_seeds ... ok   64 ms
test 05_pgl_setup ... ok   27 ms
test 06_basic_workers ... ok 8854 ms
test 07_launch_worker ... ok 4031 ms
test 08_fact_table_deps   ... ok 2663 ms
test 09_purge ... ok  176 ms
test 10_delete... ok13701 ms
test 11_more_data ... ok 6198 ms
test 12_no_proid  ... ok10785 ms
test 13_cutoff_no_dep_on_filter   ... ok36008 ms
test 14_null_key  ... ok  238 ms
test 15_source_change_date... ok  101 ms
test 16_1_2_features  ... ok 3220 ms
test 17_1_3_features  ... FAILED 8219 ms

===
 1 of 17 tests failed. ===

The differences that caused some tests to fail can be viewed in the
file 
"/tmp/autopkgtest-lxc.68jcp06n/downtmp/build.L0a/src/regression.diffs". 
A copy of the test summary that you see
above is saved in the file 
"/tmp/autopkgtest-lxc.68jcp06n/downtmp/build.L0a/src/regression.out".


make: *** [/usr/lib/postgresql/15/lib/pgxs/src/makefiles/pgxs.mk:433: 
installcheck] Error 1
*** /tmp/pg_virtualenv.Azz268/log/postgresql-15-regress.log (last 100 
lines) ***


, update_key AS (
SELECT qdwr.queue_table_dep_id,
  --Cutoff the id to that newly found, otherwise default to last value
  COALESCE(mu.last_cutoff_id, qdwr.last_cutoff_id) AS last_cutoff_id,
	  --This cutoff time must always be the same for all queue tables for 
given fact table.
	  --Even if there are no new records, we move this forward to wherever 
the stream is at

  qdwr.maximum_cutoff_time AS last_cutoff_source_time
FROM fact_loader.queue_deps_all qdwr
	LEFT JOIN new_metadata mu ON mu.queue_table_dep_id = 
qdwr.queue_table_dep_id

WHERE qdwr.fact_table_id = 2
--Exclude dependent fact tables from updates directly to 
queue_table_deps
  AND qdwr.fact_table_dep_id IS NULL
)

/
	This SQL also nearly matches that for the queue_table_deps but would be 
a little ugly to try to DRY up

/
, update_key_fact_dep AS (
SELECT qdwr.fact_table_dep_queue_table_dep_id,
  qdwr.fact_table_id,
  COALESCE(mu.last_cutoff_id, qdwr.last_cutoff_id) AS last_cutoff_id,
  qdwr.maximum_cutoff_time AS last_cutoff_source_time

Bug#1023225: esup-el: autopkgtest regression: No such file or directory, comp

[Paul Gevers]

Source: esup-el
Version: 0.7.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of esup-el the autopkgtest of esup-el fails in 
testing when that autopkgtest is run with the binary packages of esup-el 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
esup-elfrom testing0.7.1-4
all others from testingfrom testing

I copied some of the output at the bottom of this report. I'm seeing 
command lines about native complilation. Are you sure you don't need a 
new enough emacs that supports that for your test or package?


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=esup-el

https://ci.debian.net/data/autopkgtest/testing/amd64/e/esup-el/27685397/log.gz

	emacs -batch -Q -l package --eval "(setq native-comp-eln-load-path 
'(\"/tmp/3oIzPMCFGJ\"))" --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f 
package-initialize -L . -L test -l test/esup-test.el --eval 
\(ert-run-tests-batch-and-exit\)

Cannot open load file: No such file or directory, comp
dh_elpa_test: error: emacs -batch -Q -l package --eval "(setq 
native-comp-eln-load-path '(\"/tmp/3oIzPMCFGJ\"))" --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval 
"(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -L 
test -l test/esup-test.el --eval \(ert-run-tests-batch-and-exit\) 
returned exit code 255

autopkgtest [23:12:43]: test dh-elpa-test-autopkgtest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023224: strongswan: autopkgtest regression: depends on no longer built strongswan-scepclient

[Paul Gevers]

Source: strongswan
Version: 5.9.8-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of strongswan the autopkgtest of strongswan fails 
in testing when that autopkgtest is run with the binary packages of 
strongswan from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
strongswan from testing5.9.8-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The 
autopkgtest d/t/control files says the first test depends on 
strongswan-scepclient, but src:strongswan no long build it.


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=strongswan

https://ci.debian.net/data/autopkgtest/testing/amd64/s/strongswan/27694623/log.gz

Removing autopkgtest-satdep (0) ...
autopkgtest: WARNING: package strongswan is not installed though it 
should be
autopkgtest: WARNING: package strongswan-pki is not installed though it 
should be
autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt 
pinning. Retrying with using all packages from unstable

Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) autopkgtest-satdep:amd64 < 0 @iU K Nb Ib >
Broken autopkgtest-satdep:amd64 Depends on strongswan-scepclient:amd64 < 
none @un H >
  Considering strongswan-scepclient:amd64 1 as a solution to 
autopkgtest-satdep:amd64 -2
  Removing autopkgtest-satdep:amd64 rather than change 
strongswan-scepclient:amd64

Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following packages will be REMOVED:
  autopkgtest-satdep
0 upgraded, 0 newly installed, 1 to remove and 15 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
(Reading database ... (Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 13114 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest: WARNING: package strongswan is not installed though it 
should be
autopkgtest: WARNING: package strongswan-pki is not installed though it 
should be
autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing 
dependencies in test logs

Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) strongswan-scepclient:amd64 < none -> 5.9.6-1+b1 @un 
puN Ib >
Broken strongswan-scepclient:amd64 Depends on libstrongswan:amd64 < none 
-> 5.9.8-1+b1 @un puN > (= 5.9.6-1+b1)
  Considering libstrongswan:amd64 6 as a solution to 
strongswan-scepclient:amd64 

  Re-Instated libstrongswan:amd64
Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 strongswan-scepclient : Depends: libstrongswan (= 5.9.6-1+b1) but 
5.9.8-1+b1 is to be installed

E: Unable to correct problems, you have held broken packages.
admin-strongswan-charon FAIL badpkg
blame: strongswan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023223: ITP: mfem -- Lightweight, general, scalable C++ library for finite element methods

[Gürkan Myczko]

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

* Package name: mfem
  Version : 4.5
  Upstream Authors: 2010-2022 Lawrence Livermore National Security, LLC.
  URL : https://github.com/mfem/mfem
* License : BSD-3-clause
  Description : Lightweight, general, scalable C++ library for 
finite element methods
 This is a modular parallel C++ library for finite element methods. Its 
goal is
 to enable high-performance scalable finite element discretization 
research and
 application development on a wide variety of platforms, ranging from 
laptops

 to supercomputers.

Bug#1023222: python-xarray: autopkgtest regression on s390x: segmentation fault

[Paul Gevers]

Source: python-xarray
Version: 2022.10.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-xarray the autopkgtest of python-xarray 
fails in testing on s390x when that autopkgtest is run with the binary 
packages of python-xarray from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python-xarray  from testing2022.10.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-xarray

https://ci.debian.net/data/autopkgtest/testing/s390x/p/python-xarray/27672266/log.gz

[ 90%]
tests/test_sparse.py::test_variable_property[nbytes] PASSED 
[ 90%]
tests/test_sparse.py::test_variable_property[ndim] PASSED 
[ 90%]
tests/test_sparse.py::test_variable_property[values] XFAIL (Coercion...) 
[ 90%]
tests/test_sparse.py::test_variable_method[obj.all(*(), **{})-False] 
Fatal Python error: Segmentation fault


Current thread 0x03ff91575040 (most recent call first):
  File "/usr/lib/python3/dist-packages/sparse/_coo/core.py", line 1562 
in _grouped_reduce
  File "/usr/lib/python3/dist-packages/sparse/_coo/core.py", line 687 
in _reduce_calc
  File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line 
360 in reduce
  File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line 
278 in _reduce
  File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line 
307 in __array_ufunc__
  File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line 
490 in all
  File "/usr/lib/python3/dist-packages/sparse/_sparse_array.py", line 
268 in __array_function__

  File "<__array_function__ internals>", line 5 in all
  File "/usr/lib/python3/dist-packages/xarray/core/variable.py", line 
1901 in reduce
  File "/usr/lib/python3/dist-packages/xarray/core/common.py", line 73 
in wrapped_func
  File "/usr/lib/python3/dist-packages/xarray/tests/test_sparse.py", 
line 69 in __call__
  File "/usr/lib/python3/dist-packages/xarray/tests/test_sparse.py", 
line 231 in test_variable_method
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 192 in 
pytest_pyfunc_call
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1761 in 
runtest
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 166 in 
pytest_runtest_call
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in 

  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in 
from_call
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in 
call_runtest_hook
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in 
call_and_report
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 130 in 
runtestprotocol
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in 
pytest_runtest_protocol
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 347 in 
pytest_runtestloop
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__

  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 322 in _main
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 268 in 
wrap_session
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 315 in 
pytest_cmdline_main
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", 
line 164 in main
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", 
line 187 in console_main
  File 

Bug#1023221: 7kaa: If I use Esperanto locale, the program fails

[Jorge Maldonado Ventura]

Package: 7kaa
Version: 2.15.5+dfsg-1
Severity: important
X-Debbugs-Cc: jorgesu...@freakspot.net



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

Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 7kaa depends on:
ii  7kaa-data2.15.5+dfsg-1
ii  libc62.35-4
ii  libcurl3-gnutls  7.85.0-1
ii  libenet7 1.3.13+ds-1
ii  libgcc-s112.2.0-3
ii  libopenal1   1:1.19.1-2
ii  libsdl2-2.0-02.24.1+dfsg-1
ii  libstdc++6   12.2.0-3
ii  libuuid1 2.38.1-1.1+b1

7kaa recommends no packages.

Versions of packages 7kaa suggests:
pn  7kaa-music  

-- no debconf information

Bug#1023220: src:pd-flext: fails to migrate to testing for too long: autopkgtest failure on armel and armhf

[Paul Gevers]

Source: pd-flext
Version: 0.6.1-3
Severity: serious
Control: close -1 0.6.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:pd-flext has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package recently gained an 
autopkgtest (great), however it fails on armel and armhf:

fatal error: gnu/stubs-hard.h: No such file or directory

If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pd-flext



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023100: ITP: cancelreader -- A cancelable reader for Go

[Holger Levsen]

On Sun, Oct 30, 2022 at 09:23:52AM +0100, Martin Dosch wrote:
>   Description : A cancelable reader for Go
> 
>  CancelReader
>  .
>  Latest Release (https://github.com/muesli/cancelreader/releases) Go Doc
>  (https://pkg.go.dev/github.com/muesli/cancelreader) Software License
>  (/LICENSE) Build Status (https://github.com/muesli/cancelreader/actions)
>  Go ReportCard (https://goreportcard.com/report/muesli/cancelreader)
>  .
>  A cancelable reader for Go
>  .
>  This package is based on the fantastic work of Erik Geiser
>  (https://github.com/erikgeiser) in Charm's Bubble Tea
>  (https://github.com/charmbracelet/bubbletea) framework.
> 
>  This is a build-depend for newer versions of
> golang-github-charmbracelet-bubbletea.

what's a cancelable reader?


-- 
cheers,
Holger

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

The vision of self driving cars is nothing compared to the vision of no cars at 
all.


signature.asc
Description: PGP signature

Bug#1023219: src:psychtoolbox-3: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: psychtoolbox-3
Version: 3.0.18.9.dfsg1-1
Severity: serious
Control: close -1 3.0.18.12.dfsg1-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:psychtoolbox-3 has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=psychtoolbox-3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021857: fixed

[Sylvestre Ledru]

fixed 1021857 1:14.0.6-7
thanks

I think the issue is fixed but if someone knows cmake well. please let 
me know :)


Cheers
S

Bug#1023217: manpages: Wrongly sorted man pages

[Helge Kreutzmann]

Package: manpages
Version: 6.01-1
Severity: normal

manpages ships pages for section 2 and 3 in manpages-dev, however now
some man pages for section 3 are in manpages itself:

helge@twentytwo:~$ dpkg -L manpages | grep man3
/usr/share/man/man3/queue.3.gz
/usr/share/man/man3/sigevent.3type.gz
/usr/share/man/man3/siginfo_t.3type.gz
/usr/share/man/man3/sigset_t.3type.gz
/usr/share/man/man3/sigval.3type.gz

Please move these not manpages-dev.

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

Kernel: Linux 6.0.3 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  konqueror [man-browser]  4:21.12.3-1
ii  man-db [man-browser] 2.11.0-1+b1

-- no debconf information

-- 
  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#1023218: manpages: Description about included sections wrong

[Helge Kreutzmann]

Package: manpages
Version: 6.01-1
Severity: minor

helge@twentytwo:~$ LC_ALL=C apt-cache show manpages
Package: manpages
…
Description-en: Manual pages about using a GNU/Linux system
 This package contains GNU/Linux manual pages for these sections:
  4 = Devices (e.g. hd, sd).
  5 = File formats and protocols, syntaxes of several system
  files (e.g. wtmp, /etc/passwd, nfs).
  7 = Conventions and standards, macro packages, etc.
  (e.g. nroff, ascii).
 .
 Sections 1, 6 and 8 are provided by the respective applications. This
 package only includes the intro man page describing the section.

However, there are pages in section 1, 6 and 8 (and even 4!) included. 

I'm fine with manpages shipping these files, but please update the
description accordingly.


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

Kernel: Linux 6.0.3 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  konqueror [man-browser]  4:21.12.3-1
ii  man-db [man-browser] 2.11.0-1+b1

-- no debconf information

-- 
  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#1023216: parted: Avoid check dependency in nocheck profile

[Samuel Thibault]

Package: parted
Version: 3.5-2
Severity: normal

Hello,

To make bootstrapping ports easier, it would be useful to avoid the
"check" build-dep when using the nocheck build profile, as the attached
patch does, could you apply it?

Thanks,
Samuel

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

Kernel: Linux 6.0.0 (SMP w/8 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages parted depends on:
ii  libc6 2.35-4
ii  libparted23.5-2
ii  libreadline8  8.2-1
ii  libtinfo6 6.3+20220423-2

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2022-10-31 19:29:37.441927361 +0100
+++ debian/control  2022-10-31 19:29:39.911940259 +0100
@@ -17,7 +17,7 @@
  texinfo,
  libblkid-dev,
  pkg-config,
- check,
+ check ,
  autoconf,
  automake,
  autopoint,

Bug#1023215: gstreamer1.0-plugins-good: Typo in libsoup3 depends

[Peter Karbaliotis]

Package: gstreamer1.0-plugins-good
Version: 1.20.3-1+b1
Severity: normal

Dear Maintainer,

There is a missing '-' in the libsoup3 depends: it should be libsoup-3.0-0 inste
ad of libsoup3.0-0. This prevents replacement of libsoup2 libraries.

Thanks

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

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

Versions of packages gstreamer1.0-plugins-good depends on:
ii  gstreamer1.0-plugins-base 1.20.3-2
ii  libaa11.4p5-50
ii  libavc1394-0  0.5.4-5
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.35-4
ii  libcaca0  0.99.beta20-3
ii  libcairo-gobject2 1.16.0-6
ii  libcairo2 1.16.0-6
ii  libdv41.0.0-15
ii  libflac12 1.4.2+ds-1
ii  libgcc-s1 12.2.0-7
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libglib2.0-0  2.74.1-1
ii  libgstreamer-plugins-base1.0-01.20.3-2
ii  libgstreamer1.0-0 1.20.3-1
ii  libgudev-1.0-0237-2
ii  libiec61883-0 1.2.0-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libmp3lame0   3.100-6
ii  libmpg123-0   1.31.0-1
ii  liborc-0.4-0  1:0.4.32-2
ii  libpng16-16   1.6.38-2
ii  libpulse0 16.1+dfsg1-2+b1
ii  libraw1394-11 2.1.2-2
ii  libshout3 2.4.6-1+b1
ii  libsoup2.4-1  2.74.3-1
ii  libspeex1 1.2.1-1
ii  libstdc++612.2.0-7
ii  libtag1v5 1.12-1+b1
ii  libtwolame0   0.4.0-2
ii  libv4l-0  1.22.1-4
ii  libvpx7   1.12.0-1
ii  libwavpack1   5.5.0-1
ii  libx11-6  2:1.8.1-2
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  zlib1g1:1.2.11.dfsg-4.1

Versions of packages gstreamer1.0-plugins-good recommends:
ii  gstreamer1.0-x  1.20.3-2

gstreamer1.0-plugins-good suggests no packages.

-- no debconf information

Bug#1023214: schroot: CMakeLists.txt: missing "gettext" library should be a fatal error

[Dima Kogan]

Package: schroot
Version: 1.6.13-1
Severity: normal
Hi. This is a bug in building schroot on non-Debian systems. It is NOT
an issues on Debian since we have Build-Depends: gettext

If the gettext dependency is missing, the "cmake" step succeeds with a
warning. You can still try to build, but the build fails because
gettext() is used by the code unconditionally. Thus the CMakeLists.txt
should treat a missing gettext as a fatal error, or the code should be
changed to work even without.

Thanks.

Bug#983470: cdbs: waf-unpack needs Python 2.7

[Bastian Germann]

I have uploaded NMU to fix this. debdiff is attached.diff -Nru cdbs-0.4.163+nmu1/debian/changelog cdbs-0.4.163+nmu2/debian/changelog
--- cdbs-0.4.163+nmu1/debian/changelog  2022-09-17 22:20:04.0 +0200
+++ cdbs-0.4.163+nmu2/debian/changelog  2022-10-31 18:54:32.0 +0100
@@ -1,3 +1,10 @@
+cdbs (0.4.163+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * scripts/waf-unpack: Convert to Python3 syntax (Closes: #983470).
+
+ -- Bastian Germann   Mon, 31 Oct 2022 18:54:32 +0100
+
 cdbs (0.4.163+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cdbs-0.4.163+nmu1/scripts/waf-unpack 
cdbs-0.4.163+nmu2/scripts/waf-unpack
--- cdbs-0.4.163+nmu1/scripts/waf-unpack2022-09-17 22:20:04.0 
+0200
+++ cdbs-0.4.163+nmu2/scripts/waf-unpack2022-10-31 18:54:14.0 
+0100
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 # -*- mode: python; coding: utf-8 -*-
 #
 # Most of this code was stolen from Waf which is:
@@ -115,11 +115,11 @@
(options, args) = parser.parse_args()
 
if not options.waf and not options.dest:
-   print '--waf and --dest options are mandatory'
+   print('--waf and --dest options are mandatory')
parser.print_help()
sys.exit(1) 
 
-   print 'Unpacking ' + options.waf + ' to ' + options.dest + ' ...'
+   print('Unpacking ' + options.waf + ' to ' + options.dest + ' ...')
unpack_waf(options.waf, options.dest)
-   print 'Done'
+   print('Done')
 

Bug#1023213: ITP: rust-nanorand -- tiny and fast random number generation

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-nanorand
  Version : 0.7.0
  Upstream Author : Lucy 
* URL : https://github.com/Absolucy/nanorand-rs
* License : Zlib
  Programming Lang: Rust
  Description : tiny and fast random number generation

 Nanorand is a Rust library meant for fast, random number generation
 with quick compile time, and minimal dependencies.

This package will be maintained in the collaborative Debian section of
Salsa, at .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNgEBgACgkQLHwxRsGg
ASH4BA//YoZMKGCEG5oPLjxfeV54weUsCWEf+zBRcJbVWOhNJUDlbF5QfTYH2p9a
fvskTR2mtdFbo7vWHfpVdBT0Q+SiahDuKxfWD9fFeee6YptGUsijy17OmGdELUOP
NNSzkq6SD3v7+Q3QjJBSEZUehn7BNFWTGheRPTfoz3dSYKvm4YdPXj2FSLx1cXBD
EofRLJr/GUGonXSK4YMEnpq0OUfPTzRDK43eZPV5jRze84M/5BwIAnC4O5dtGr4z
+h1kTfxMMydaUB33+0d/ZGG/EqzjuLor8n4xWEYziNSCXnNVcfzFCRsYZc8GvNZP
KeFrNGeiJSIAPW4hCqxfsDYlXJGZt9RhmabETxJvPflaPsek3sYT+8Eji1nxfOcL
ciDUpyUKm2YCNg5MwDA9Q7C0F6YkG4wL4q+UCGULjoVRNxMxPl9GkuxJUNAVpXYm
aYTfPfkB9/Tu0V9S7/dgp5lESRpCuSAshISNwhnMWsqyQ7jfzM1Cmy2zOuzqIPrN
lR92cNTaXJfSOt8DVqFkc4TrZoyqLNjhS1pH2nHK2hxUYvvEsav+L623hne3hlb7
rGrQ5ktNJXebRTxph8NlM3SxB4rGQJmKYk18rvVbg6wKa49gjwkJr+ivMsWWkoVy
0qiPo5Lb21P6zxPADAbRX90mDbsu3qOKbeVdCK+hjGPyx8j8eQk=
=7F/f
-END PGP SIGNATURE-

Bug#1023212: assimp: Failing to open simple COLLADA file on s390x architecture

[Francois Mazen]

Source: assimp
Severity: normal
X-Debbugs-Cc: franc...@mzf.fr

Dear Maintainer,

F3D [1] uses Assimp to open COLLADA files. The associated autopkgtest fails on
s390x architecture only.

The test tries to open the COLLADA Example from the 1.5 documentation with is a
simple white cube [2] (see Appendix A).

The Assimp error description is: "Expected different index count in 
element."

I've created a minimal example to reproduce the issue [3].
The "correct" output using amd64 platform is:
Info,  T0: Load cube.dae
Debug, T0: Assimp 5.2.0 amd64 gcc debug shared singlethreadedsingle :
Info,  T0: Found a matching importer for this file format: Collada Importer.
Info,  T0: Import root directory is './'
Debug, T0: Collada schema version is 1.5.n
Debug, T0: UpdateImporterScale scale set: 1
Info,  T0: Entering post processing pipeline
Debug, T0: LimitBoneWeightsProcess begin
Debug, T0: LimitBoneWeightsProcess end
Info,  T0: Leaving post processing pipeline
Assimp import OK

The "wrong" output using s390x platform (zelenka porter box) is:
Info,  T0: Load cube.dae
Debug, T0: Assimp 5.2.0 s390x gcc debug shared singlethreadedsingle :
Info,  T0: Found a matching importer for this file format: Collada Importer.
Info,  T0: Import root directory is './'
Debug, T0: Collada schema version is 1.5.n
Error, T0: Expected different index count in  element.
Assimp error: Expected different index count in  element.

Thanks!

François

[1] https://tracker.debian.org/pkg/f3d
[2] https://www.khronos.org/files/collada_spec_1_5.pdf
[3] https://salsa.debian.org/mzf/assimp-collada-test

Bug#1023211: RM: dirtbike -- ROM; Obsolete, no longer used for any Debian Python packages

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

We used to use this back when we debundled pip's embedded dependencies.
We don't do that anymore (no longer supported upstream), so dirtbike is
not needed.  It is unmaintained upstream and likely to be a problem over
time since its design is inherently fragile.

Scott K

Bug#1023205: bullseye-pu: package memtest86+/6.00-1

[Fabio Fantoni]

Il 31/10/2022 17:38, Felix Zielcke ha scritto:

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: fziel...@z-51.de, fantonifa...@tiscali.it

[ Reason ]

memtest86+ 5.01-3.1 in stable is very old and doestn't run correctly
on recent hardware.

[ Impact ]

Fail to run memtest86+ on their hardware.

[ Tests ]

manually tested.

[ Risks ]

Completely rewritten from scratch. So could have bugs not yet known.


[ Checklist ]
   [X] *all* changes are documented in the d/changelog
   [X] I reviewed all changes and I approve them
   [X] attach debdiff against the package in (old)stable
   [X] the issue is verified as fixed in unstable

[ Changes ]

Comeplete new upstream version.
Rewritten GRUB integration scripts.
New ISO/USB bootable Images.

[ Other info ]

I requested a backport [1] but Thomas Goirand (zigo) recommend me to ask you 
for a
complete update in stable [2].
If this will be rejected, I recommend to remove memtest86+ from stable
and hopefully somebody uploads the new version to backports.
As a DM I can't do this myself.

[1] https://lists.debian.org/debian-backports/2022/10/msg00056.html
[2] https://lists.debian.org/debian-backports/2022/10/msg00061.html
About stable-update if 6.00 will be rejected as was "full rewrite" I 
suggest 5.31b+dfsg-4 as alternative, except for efi support missed also 
in it was working in all computers where I used it


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023210: ITP: golang-sourcehut-emersion-gqlclient -- GraphQL client and code generator for Go

[Taavi Väänänen]

Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block -1 by 1023203

* Package name: golang-sourcehut-emersion-gqlclient
  Version : 0.0~git20220713.e4b2ae1-1
  Upstream Author : Simon Ser 
* URL : https://sr.ht/~emersion/gqlclient/
* License : Expat
  Programming Lang: Go
  Description : GraphQL client and code generator for Go

gqlclient can be used as a thin GraphQL client, and can be augmented
with code generation.

I am packaging this since it is a dependency of the sr.ht CLI tool hut
(https://git.sr.ht/~emersion/hut).


OpenPGP_0xEF242F709F912FBE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023209: rust-getrandom: please update to v0.2.5

[Jonas Smedegaard]

Source: rust-getrandom
Version: 0.2.4-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v0.2.5 (or newer), needed by
projects I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNgBAgACgkQLHwxRsGg
ASHvfBAAgBJLxfjjPurVhnHZWXmKhCQiw9QmQK+e5vOnwSU0ORaVYzyWnivzDjut
mQcNXiT35k9nz9g96cL1NItiU3XCW7rmaHJ5tmOxw5eUtffoaWpe7xLveQr4j0KX
otAySOxaPL96+5CA/OH/FzvEPUEabHJsDGUc+3hw811jSp3oB5hv5gzNlZARCZwR
UBNPyxoFjj1QiZOQayN3RHoO7LHGw//vWAHbt033NdFCTvdD+ZeGAEDezio9zymn
j9PogYpEl08SCagr+M/oOnvOLM8dYF0k+pO4XJmdfR58X5KTawzLbIdEbdvqGZYB
/ecTrlgZFnCFYOcq+sj8Siz+5Xwkmi5BwgTI5oEi1XbEtEhNuZ13iAdJ5EFQz0Ko
0tc9gDnymGBxi8bc5pFCPxaB3/3wzvpM7/solhq+qOvr+CfyfjVeAVXwE5GUHYQe
6XZbKPrVoz1JgKE3asSXcGPDanOC+GzPHi7Vs5kloqpENmOZFH+T2a1CCmSlc/sm
TklN2bVoTpzcjDeg0o4qdTQbPsWIRq5vN3siahx0B+DV+9oAw1eJNb0ycHIZLA7C
INhqLU4J/chyvPkmkrJ+bVg/gZ8UdEuRax6CcJBX0GC203JcLgb7LATy3mb5N3Yx
kB3asY6Pl5vNbjUr9ummGhkDHOfIN+OapQSMB0cMezEfmVVCvw4=
=L+V4
-END PGP SIGNATURE-

Bug#1003472: owfs: fails to build with php8.1

[Bastian Germann]

Control: retitle -1 libow-php7: misnomer
Control: tags -1 - ftbfs
Control: severity -1 minor

The package should build with swig 4.1.0.
But with a build based on PHP 8, the libow-php7 package is a misnomer.

Bug#950213: openjdk-17-jre-headless: AccessControlException in java.util.Properties when running with a security manager

[Emmanuel Bourg]

Control: reassign -1 openjdk-17-jre-headless
Control: retitle -1 openjdk-17-jre-headless: AccessControlException in 
java.util.Properties when running with a security manager

The report is empty and I was tempted to close it as invalid. But the
underlying issue is worth considering: java.util.Properties is patched
in Debian to remove the timestamp in the header of the properties files
to make them reproducible. The timestamp is removed when the SOURCE_DATE_EPOCH
environment variable is defined.

This look trivial but this creates a subtle incompatibility compared to
the upstream JDK. Reading SOURCE_DATE_EPOCH when running with a security
manager triggers an AccessControlException unless a rule is added in the
policy file:

java.security.AccessControlException: access denied ("java.lang.RuntimePermission" 
"getenv.SOURCE_DATE_EPOCH")
at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at 
java.base/java.security.AccessController.checkPermission(AccessController.java:897)
at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at java.base/java.lang.System.getenv(System.java:996)
at 
java.base/java.util.Properties.getFormattedTimestamp(Properties.java:1587)
at java.base/java.util.Properties.store0(Properties.java:929)
at java.base/java.util.Properties.store(Properties.java:918)

So basically, any external Java application launched with the Debian JRE
and using a security manager will break when attempting to write a
properties files.

This is bad and should be reverted or done differently. We could try
adding a SOURCE_DATE_EPOCH property in jdk.internal.util.StaticProperty
since these properties are initialized before the security manager is
set. Or we could drop the patch and rely on strip-nondeterminism to
remove the timestamp.

Emmanuel Bourg

Bug#1023208: evolution: Evolution calendar is highlighting tomorrow, not today.

[Diane Trout]

Package: evolution
Version: 3.46.1-1
Severity: normal
X-Debbugs-Cc: none, Diane Trout 

Dear Maintainer,

For some reason my instance of evolution has started highlighting the
next day in the work week calendar.

So as I write this on Monday, October 31st, looking at the work week
calendar, Tuesday 01 November is highlighted with the red "current time"
line moving toward an appointment tomorrow.

I did check that the correct date is highlighted in the flatpak
version. Though that's using 3.46.0 (Commit
0414db49604c08e720a5c6256c60dfcfd4dc8a500949789ec736a609018de1ca)
and the change was recent enough that if it's not a configuration issue
on my system the bug could've been introduced in the .1 release.

Thanks,
Diane Trout

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 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 evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.4-1
ii  evolution-common3.46.1-1
ii  evolution-data-server   3.46.1-1
ii  libc6   2.35-3
ii  libcamel-1.2-64 3.46.1-1
ii  libecal-2.0-2   3.46.1-1
ii  libedataserver-1.2-27   3.46.1-1
ii  libevolution3.46.1-1
ii  libglib2.0-02.74.0-3
ii  libgtk-3-0  3.24.34-3
ii  libical33.0.16-1
ii  libnotify4  0.8.1-1
ii  libwebkit2gtk-4.1-0 2.38.0-3
ii  libxml2 2.9.14+dfsg-1+b1
ii  psmisc  23.5-3

Versions of packages evolution recommends:
pn  evolution-plugin-bogofilter | evolution-plugin-spamassassin  
ii  evolution-plugin-pstimport   3.46.1-1
ii  evolution-plugins3.46.1-1
ii  yelp 42.2-1

Versions of packages evolution suggests:
ii  evolution-ews   3.46.1-1
pn  evolution-plugins-experimental  
ii  gnupg   2.2.40-1
ii  network-manager 1.40.2-1

-- no debconf information

Bug#1023207: ITP: rust-flume -- blazingly fast multi-producer channel

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-flume
  Version : 0.10.14
  Upstream Author : Joshua Barretto 
* URL : https://github.com/zesterer/flume
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : blazingly fast multi-producer channel

 Flume is a Rust library
 for a blazingly fast multi-producer, multi-consumer channel.
 .
 "Do not communicate by sharing memory;
 instead, share memory by communicating."

This package will be maintained in the collaborative Debian section of
Salsa, at .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNf/74ACgkQLHwxRsGg
ASGDHQ//YfhyDWsScX9Vq+Xw6VBI+jY11oN+MpkRy374BGrcSfJI6evgr6NzTSIx
e0e3PUZLN3W062Aq2GgOykGN+LAHn6XFqjd/VSGzX9z/BqmiHHi+Jt+KwcvUOPXL
J4ZiwV6rAMm10N1gsirCMRDqllqH+O/wl5KiMZIvNRyD+Z+N+e0buBu4Rwrt1eGD
4GR/9oLOnjgWXwIEv+tEfwIJ2v3qeneajrswimjLIJbcbimz1UzlYxXaMWgLzQNm
YSZR4f2Uo9AUcN/HVp0bvPLqZQkYoOOmdOi91kC4bNZD9lWitcqSHmNsfkhOdD/X
4kmBhcYWwhqkXqtPxLuNoY1SXvHdEJP64SK65wW/raqFJgbi1OcJE1Z/k3I5tDL8
a/fLSbEeBlELb398ceWZnXCRDynwnUUaANlkLol7z75BRkvw00pqHybYhrVJuHmE
GUAErD/j39rOEvXASS5lh4Iv7ipywol11psta2GcaIhEtsXDhCh0uym9XyfbUCe0
G7jlooakATFQgtXUm/lQIDzbR9oOnd9ZeS3GohRSRn7MAOmfjRyOO9OcVw+HZpP+
MlOcjcxQIQnd9BodZLMtbdWY1K/iUaadmbwu/Yelw+JaMSIfuRL8EKu5XxyxwLRK
2tNNBxXHsfk92PRoyV1FdKTzBUzzCagtunwLcRsxb7Pmqt6S/wc=
=fit0
-END PGP SIGNATURE-

Bug#1023206: ITP : ruby-ipaddr -- class to manipulate an IP address in ruby

[Vinay Keshava]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-ipaddr
 Version   : 1.2.4
 Upstream Author   : ipaddr
*URL   :https://github.com/ruby/ipaddr
*License   : Expat
 Programming Lang  : Ruby
*Description   : class to manipulate an IP address in ruby

 IPAddr provides a set of methods to manipulate an IP address.
 Both IPv4 and IPv6 are supported.

.

This gem is required for the gitlab 15.5.1 update.

- Vinay Keshava

Bug#1023205: bullseye-pu: package memtest86+/6.00-1

[Felix Zielcke]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: fziel...@z-51.de, fantonifa...@tiscali.it

[ Reason ]

memtest86+ 5.01-3.1 in stable is very old and doestn't run correctly
on recent hardware.

[ Impact ]

Fail to run memtest86+ on their hardware.

[ Tests ]

manually tested.

[ Risks ]

Completely rewritten from scratch. So could have bugs not yet known.


[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]

Comeplete new upstream version.
Rewritten GRUB integration scripts.
New ISO/USB bootable Images.

[ Other info ]

I requested a backport [1] but Thomas Goirand (zigo) recommend me to ask you 
for a
complete update in stable [2].
If this will be rejected, I recommend to remove memtest86+ from stable
and hopefully somebody uploads the new version to backports.
As a DM I can't do this myself.

[1] https://lists.debian.org/debian-backports/2022/10/msg00056.html
[2] https://lists.debian.org/debian-backports/2022/10/msg00061.html

Bug#1011760: default-jdk: install fails: depends on openjdk-11-jdk-headless but 404 not found

[Emmanuel Bourg]

Control: tags -1 unreproducible

This looks like an apt issue, "apt update" should fix this.

Emmanuel Bourg

Bug#1018225: src:rust-rustls: fails to migrate to testing for too long: blocked by build dependency

[Jonas Smedegaard]

Quoting Peter Green (2022-10-31 03:39:28)
> > src:rust-rustls: fails to migrate to testing for too long: blocked by build 
> > dependency
> 
> Specifically rust-async-std has taken some time to package, because of the 
> large number
> of dependencies. There has been effort on this front both by the rust team 
> and by Jonas
> who currently packages rust stuff outside the rust team because he doesn't 
> like our
> packaging workflow.

Thanks, Peter.  For issues like this one by Release team and explicitly
described in subject as "blocked by build dependency" I believe however
than there is no need for explaining the cause (in _these_ bugreports -
it may make sense and be helpful to elaborate on the cause at a _root_
blocking bugreport).

> rust-async-std is now in unstable, however the autopkgtests for 
> rust-criterion and
> rust-async-std are failing. Jonas can you deal with these or do you want help?

Thanks, you offer is appreciated but (hopefully - should be confirmed
within few hours) there was no need for help this time.

Also, in future it is better if you post offers for help with the root
issue at the root bugreport rather than one of these leaf ones.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1013259: samba-libs: Possible policy violation

[Michael Stone]

If you can come up with a better solution than a strict dependency, great. But 
the current situation, in which samba upgrades randomly render systems unusable 
is, in my opinion, much much much worse than an overly strict dependency. 
Fundamentally the problem is that you're promising future compatibility but not 
providing that. One way or another samba-libs either needs to not suggest that 
linked binaries will work with future versions, or make sure that they do.
-- 
Michael Stone
(From phone, please excuse typos)

Bug#1017922: java-common: update-java-alternatives --list propagates the exit code of a random grep, causing inconsistencies

[Emmanuel Bourg]

Thank you for the very detailed report, this will be fixed in the next 
update.


Emmanuel Bourg

Bug#1023180: pdfcrack doesn't respect the -n or -m flags

[Henning Norén]

On Mon, 2022-10-31 at 12:49 -0300, Eriberto wrote:
> This is for versions =< 0.19, right?

Correct!

Kind Regards,
Henning Norén


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

Bug#992304: Dell PowerEdge T140

[Diederik de Haas]

On Thursday, 27 October 2022 15:56:33 CET Gabriel Rolland [Res Novae] wrote:
> Same problem with the Dell PowerEdge T140 with LSI MegaRAID SAS-3 3008
> [Fury] (rev 02) and linux-image-5.10.0-19-amd64 (NO UEFI)
> 
> No problem booting with the old 4.19.0-22-amd64 kernel

The best way to make progress with this is doing a `git bisect` where
good = v4.19.194 (= 4.19.0-17)* and
bad = v5.10.46
https://wiki.debian.org/DebianKernel/GitBisect

*) I think that's better/faster then v4.19.260 (=4.19.0-22), but I'm not sure.
Hopefully someone can confirm/deny that and offer a better/faster strategy.

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

Bug#1023180: pdfcrack doesn't respect the -n or -m flags

[Eriberto]

Em seg., 31 de out. de 2022 às 11:42, Henning Norén
 escreveu:
>
> This issue is now resolved in pdfcrack 0.20 (just released).


Thanks a lot Henning. I will package this new version now.


> The problem with parsing the integer of -n or -m arguments can be
> worked around by either:
>
> pdfcrack -f document.pdf -n 9
>
> or:

This is for versions =< 0.19, right?

Cheers,

Eriberto

Bug#1023193: RFS: libtrio/1.16+dfsg1-6 [ITA] -- portable and extendable printf and string functions

[Matthias]

On 31.10.22 14:09, Bastian Germann wrote:
> This qualifies more as a QA upload.
> The only changes are version bumps and adding the s in https...
>
> Please only adopt a package if you can show actual changes.
>

Oh, sorry.  I thought it was a goal in itself to have as few orphaned 
packages as possible in Debian and that therefore one should always 
adopt a package if one has the time and interest to properly care for 
it.  I didn't knew that adoption should only be done when there is also 
some immediate need for change.  Since I don't have that right now, I 
guess I retract my ITA.


Best regards, Matthias.

Bug#1021937: more detail

[Jeffrey Cliff]

looks like meliae used to be in debian
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000548
is the bug report that removed it, claiming some 3.9 FTBFS bug
is it https://bugs.launchpad.net/meliae/+bug/1899379 ?

it also does seem to be still falling to others to maintain also
https://bugs.launchpad.net/meliae/+bug/1498436

copying the debian directory from oldstable into the new trunk from
launchpad ( most recently updated earlier this year )
https://salsa.debian.org/themusicgod1-guest/meliae
doesn't quite build, runs into some kind of problem with pip/cython
where it looks for python 2.7 (perhaps it's in the cython code hard
coded somewhere? )

hopefully this helps
tmg1
-- 

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

Bug#1013259: samba-libs: Possible policy violation

[Michael Tokarev]

31.10.2022 18:15, Michael Stone wrote:
The issue here is that packages built against samba-libs get a dependency on samba-libs >= version, and they really either need a dependency on 
samba-libs == version or the samba-libs package needs to be versioned (e.g., samba-libs2, samba-libs3, etc.) and conflict with other versions, or 
samba-libs needs to Breaks: every dependent package on every update, or somesuch. The current state of affairs results in every change to the 
samba-libs libraries breaks other packages compiled against them (namely sssd) until those packages are recompiled, but there is nothing in the 
dependencies to enforce that.


Michael, are you sure about that?

It is not that simple.

Yes, there were an incompatible change in libndr.so which resulted in changing
its soname, and this is bullseye->bookworm issue indeed.  I know about this
issue. But this does not mean sssd needs to be recompiled on every samba
upload (or even 4.16=>4.17 update), sssd should work just fine being compiled
with older samba libs while more recent samba-libs are installed.

Or so it looks like, to me, anyway.

There was another issue here, when modifying samba to build libldb out of
samba sources, there was a bug resulted with older sssd to become non-functional
(this was together with the soname of libndr change too, but unrelated): the
plugin directory has changed. But later on I found a way how to search both
old and new plugins directories, so that issue has been resolved, tho I still
have (iirc) Breaks for older sssd.

But over than this soname change and a bug in directory rename, there should
be no reason why sssd needs to be recompiled every time samba changes, and
why samba-libs dependency should be =version, not >=version.

Samba does have more or less stable public libraries (in /usr/lib/, or actually
/usr/lib/$triple/ but let's use the former for brevity). If another package
uses one of these (like libndr, lisamba-util, libsmbldap, etc), it will have
>= $version dependency.  And there are quite some internal libraries,
in /usr/lib/samba/, which, once used, gets =$version dependency, because for
these, there's just no ABI whatsoever, and stuff can change significantly.

I yet to figure out how to solve the soname change issues like we have.
I can add Breaks against existing previous sssd releases for that, I guess,
but it wont be fair, since a recompile of old sssd would fix it but the
Breaks will prevent it from being used.

/mjt

Bug#1023111: apt-listbugs: Ignores release-related tags (sid, bookwork, etc.) in bug reports causing false positives, e.g. lists bugs in stable which are only tagged sid and bookworm

[Francesco Poli]

On Sun, 30 Oct 2022 12:47:33 +0200 Adrian Bunk wrote:

> On Sun, Oct 30, 2022 at 11:30:58AM +0100, Axel Beckert wrote:
> >...
> > To do that it seems only marginally necessary how other releases a named
> > as it only needs to know the release name of the release its running
> > on. For that it should suffice to know a list of all tags which are
> > _not_ release names.
> 
> I don't know much about interfaces to the BTS, but there might be
> some usable existing interface/implementation for such information.

I am not aware of any existing SOAP interface for this in debbugs.
At least, I cannot find it among the [documented] interfaces.

[documented]: 

Maybe it would be worth requesting this feature to debbugs upstream?
Are you willing to do so?

Actually, this is related to another pending feature request: [#694979].
A possible enhanced version of 'get_bugs' could also allow the client
to specify the release it is interested in, and the BTS would only
return bugs that affect the specified binary versions of the specified
binary packages on the specified release (taking release-related tags
into account).

[#694979]: 

> 
> If available, this would be preferrable to an own implementation
> interpreting the sometimes weird and archaic ways how the BTS works.

I agree that a server-side implementation would be better than a
client-side one, since it would not need to closely chase any
server-side change.

> 
> > Then again, if new not-release-name tags are added to the BTS in the
> > future, having a positive list of all known release names (which are
> > usually known two releases in advance) might be helpful nevertheless.
> >...
> 
> The distro-info-data package can be used if such information is required.

Yes, I agree, but with the limitations I expressed in my reply to Axel
("which release am I running?" does not always have a clear-cut answer
and relying on distro-info-data would be Debian-specific anyway, or
would require porting that package to any other distribution we want
apt-listbugs to run on).


Anyway, thanks for your comments, Adrian!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgphv5iVyO0Pg.pgp
Description: PGP signature

Bug#1010024: (no subject)

[Matthew Vernon]

Hi,

Looking at this further.

The offending file is

cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_測試_Русский_ě_áñ.._testdir_path2_測試_Русский_ě_áñ.copy1to2.que


In generating the manifest, pristine-tar calls:

LANG='C' tar --quoting-style=escape -tf rclone-1.60.0.tar.gz

which renders it thus:

rclone-1.60.0/cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.._testdir_path2_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.copy1to2.que

That appears in manifest as:

rclone-1.60.0/cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.._testdir_path2_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.copy1to2.que

pristine-tar then prints that out in its warning message:

pristine-tar: 
rclone-1.60.0/cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.._testdir_path2_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.copy1to2.que 
is listed in the manifest but may not be present in the source directory


...but if I strace it, it's looking at something different - like it's 
interpreting the \s in the manifest as literal \s rather than escape 
characters...


stat("/tmp/pristine-tar.lndiNRBXMu/workdir/rclone-1.60.0/cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_\\346\\270\\254\\350\\251\\246_\\320\\240\\321\\203\\321\\201\\321\\201\\320\\272\\320\\270\\320\\271_\\304\\233_\\303\\241\\303\\261.._testdir_path2_\\346\\270\\254\\350\\251\\246_\\320\\240\\321\\203\\321\\201\\321\\201\\320\\272\\320\\270\\320\\271_\\304\\233_\\303\\241\\303\\261.copy1to2.que", 
0x55a1149ee4b8) = -1 ENAMETOOLONG (File name too long)


and indeed it tries to create something similar:

mkdir("/tmp/pristine-tar.lndiNRBXMu/workdir/rclone-1.60.0/cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_\\346\\270\\254\\350\\251\\246_\\320\\240\\321\\203\\321\\201\\321\\201\\320\\272\\320\\270\\320\\271_\\304\\233_\\303\\241\\303\\261.._testdir_path2_\\346\\270\\254\\350\\251\\246_\\320\\240\\321\\203\\321\\201\\321\\201\\320\\272\\320\\270\\320\\271_\\304\\233_\\303\\241\\303\\261.copy1to2.que", 
0777) = -1 ENAMETOOLONG (File name too long)


HTH,

Matthew

Bug#1023111: apt-listbugs: Ignores release-related tags (sid, bookwork, etc.) in bug reports causing false positives, e.g. lists bugs in stable which are only tagged sid and bookworm

[Francesco Poli]

Control: severity -1 wishlist


On Sun, 30 Oct 2022 11:30:58 +0100 Axel Beckert wrote:

> Package: apt-listbugs
> Version: 0.1.35
> Severity: important
> 
> Hi,

Hello Axel,
nice to read you.

> 
> apt-listbugs doesn't seem to care about release-related tags in the BTS,
> e.g. shows RC bugs on stable which are tagged sid and (currently)
> bookworm in the BTS and hence don't apply to the same (or similar)
> version in stable.

That's true, it does not take those tags into account.

It has a "-T" option to filter by tags, but I don't think it's too
useful in your use case, since you want to see bugs without
release-related tags plus bugs with the release-related tag which refers
to your own release...

> This causes false positives and unnecessarily blocks
> backported security updates of rolling-release packages like
> firefox-esr, chromium, etc. as well as updates of packages in
> -backports.

Frankly speaking, I have really rarely encountered such a situation
myself. Hence, I have never felt an actual need for a special treatment
of release-related tags...

However, when you encounter a situation like the one you described, you
may take a look at the bug report (which is often a good thing to do,
before deciding whether to pin the package or go ahead with the
upgrade/installation) and immediately find out that the bug does not
affect your system.
At that point, you may dodge (command 'd') any other bugs that worry
you, and proceed with the upgrade/installation of the package affected
by the other-release-specific bug. Or mark the other-release-specific
bug as ignored (command 'i'), if you prefer.

I acknowledge that this requires manual intervention and human
judgment, but they are also needed for other kinds of bugs, unless you
want to pin *any* buggy package, no matter what... 

> 
> One such recent example is #1021810 in firefox-esr which is about
> dropping 32-bit architectures in the future. (Granted, the result of
> that specific discussion-style bug-report will probably also apply to
> stable at some point, but that's not the point here. :-)
> 
> So from my point of view, apt-listbugs should do the following:

Thank you for this feature request.
I am setting the severity to "wishlist", since you are requesting the
implementation of a new feature.

Please let me comment on what you propose.

> 
> * Check on which release it is running.

Which can be done, but is not always trivial.

For instance: how do I tell testing (currently "bookworm") and unstable
("sid") apart?

With some pin-priorities set, it is easy to run a mix of the two.
So: how should I consider testing with some packages from unstable (or
even experimental)? as "bookworm"? or as "sid"?

What about stable (currently "bullseye") with many packages backported
from testing or unstable?

> 
> * Only take RC bugs into account, which are either not tagged for any
>   release at all (and where hence only the affected versions are
>   relevant) or which are (also) tagged for the current release.
> 
> To do that it seems only marginally necessary how other releases a named
> as it only needs to know the release name of the release its running
> on. For that it should suffice to know a list of all tags which are
> _not_ release names.

This would require heavy maintenance on my side, since I would need to
be very prompt to update this list, as soon as a new
non-release-related tag is added to the Debian BTS.

Moreover, other Debian-based distributions could decide to use a BTS
based on debbugs (I don't know whether there are any _today_, but there
could be some _in the future_), and they could use a slightly different
version of debbugs or a fork with different non-release-related tags.
This would mean even more maintenance on the side of anyone who would
port apt-listbugs to that distribution...

All this looks a bit fragile: for instance, suppose a new
non-release-related tag is implemented in the Debian BTS (I think the
last addition was 'newcomer') and apt-listbugs is not promptly updated
to recognize that new non-release-related tag. An unaware apt-listbugs
would consider any bug tagged with this new tag ('newcomer') as
specific to this non-existent release ('newcomer') and users running,
say, unstable would fail to be warned about those bugs...

I am somehow reluctant to implement such a fragile feature.

> 
> Then again, if new not-release-name tags are added to the BTS in the
> future, having a positive list of all known release names (which are
> usually known two releases in advance) might be helpful nevertheless.
[...]

This could be slightly better, but would require maintenance on my side
anyway, as new release names are continuously added (roughly every
second year).
However, this approach would be even more Debian-specific and would
require a fork of apt-listbugs for any other Debian-based distribution
which uses a debbugs-based BTS...


All in all, I see the usefulness of the feature you are requesting
(although it seems to be 

Bug#1014537: unnamed packaging files in a multibinary package should be an error

[Mattia Rizzolo]

Hi Niels,

Thank you for this work.

Personally I have only one point I'd like to raise:

On Sat, Oct 29, 2022 at 08:55:38PM +0200, Niels Thykier wrote:
>  * debian/README.Debian
>  * debian/TODO
> 
> These have historically been installed into the main package and a note in
> debhelper (dh_installdocs) suggests these (or at least README.Debian) is a
> name standardized by Policy.  I am open to not installing them by default if
> one of you are willing to drive the discussion on debian-devel to assert
> there is consensus for that.

In all my QA work around the archive (admittedly, not much in the last
few years), I don't think I ever saw *one* d/TODO file that was
up-to-date; they always felt remnants from the last century or so.

Also, IIRC most of the time those files contained TODO items for the
maintainer, something that is hardly interesting for the final user.

Do you have any number about this file?


As such, I'd like to propose to instead not ship this file by default if
present in the source package.


BTW, is d/TODO documented anywhere?  I know it's an historic file, but I
don't think I saw it mentioned in any formal document.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1013259: samba-libs: Possible policy violation

[Michael Stone]

The issue here is that packages built against samba-libs get a 
dependency on samba-libs >= version, and they really either need a 
dependency on samba-libs == version or the samba-libs package needs to 
be versioned (e.g., samba-libs2, samba-libs3, etc.) and conflict with 
other versions, or samba-libs needs to Breaks: every dependent package 
on every update, or somesuch. The current state of affairs results in 
every change to the samba-libs libraries breaks other packages compiled 
against them (namely sssd) until those packages are recompiled, but 
there is nothing in the dependencies to enforce that.

Bug#992304: Dell PowerEdge T140

[Gabriel Rolland [Res Novae]]

Update

On Thu, 27 Oct 2022 15:56:33 +0200 "Gabriel Rolland [Res Novae]" 
 wrote:

> Same problem with the Dell PowerEdge T140 with LSI MegaRAID SAS-3 3008
> [Fury] (rev 02) and linux-image-5.10.0-19-amd64 (NO UEFI)
>
> No problem booting with the old 4.19.0-22-amd64 kernel
>
>

The problem is still present with 
linux-image-5.19.0-0.deb11.2-amd64_5.19.11-1~bpo11+1_amd64

Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump

[Vincent Lefevre]

Hi,

On 2022-10-30 06:31:27 -0700, Sean Whitton wrote:
> I've backported a couple of patches from upstream related to native
> compilation, now, so would you be able to test again with the latest
> upload?  Thanks.

If you mean 1:28.2+1-3, I still got the same issue. But it seems
that after a reboot, the problem no longer occurs (after removing
the .emacs.d directory). Was a reboot needed?

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

Bug#1023204: sssd-ipa: sssd fails to start due to broken dependency

[Michael Stone]

Package: sssd-ipa
Version: 2.7.4-1+b1
Severity: critical
Justification: breaks the whole system

After upgrade of samba-libs syslog has messages like

... sssd[448823]: /usr/libexec/sssd/sssd_pac: error while loading shared 
libraries: libndr.so.2: cannot open shared object file: No such file or 
directory

/usr/lib/x86_64-linux-gnu/sssd/libsss_ipa.so seems to have a dependency on
libndr.so.2 while current samba-libs only provides libndr.so.3.

As a result, there is no uid/gid resolution, etc, for all centrally managed
users, making the system unusable for non-local accounts.

This may be an issue with the way the dependency in the way samba is generating
library dependencies deserving of a separate bug, but for now sssd is broken
until recompiled against latest samba library. The dependency on samba-libs
should probably be a strict version rather than a >= version.

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

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

Versions of packages sssd-ipa depends on:
ii  libc6 2.35-4
ii  libdhash1 0.6.2-1
ii  libipa-hbac0  2.7.4-1+b1
ii  libldap-2.5-0 2.5.13+dfsg-2+b1
ii  libldb2   2:2.6.1+samba4.17.2-3
ii  libpopt0  1.19+dfsg-1
ii  libselinux1   3.4-1+b2
ii  libsemanage2  3.4-1+b2
ii  libsss-idmap0 2.7.4-1+b1
ii  libtalloc22.3.4-2
ii  libtevent00.13.0-2
ii  samba-libs2:4.17.2+dfsg-3
ii  sssd-ad-common2.7.4-1+b1
ii  sssd-common   2.7.4-1+b1
ii  sssd-krb5-common  2.7.4-1+b1

sssd-ipa recommends no packages.

sssd-ipa suggests no packages.

-- no debconf information

Bug#856587: fake-tty shared object or command line tool

[Jakub Wilk]

* Patrick Schleizer , 2017-03-02 18:07:
- unbuffer(1) does not correctly return the exit code if the process is 
killed.


I've reported that as #1023201.

--
Jakub Wilk

Bug#1023180: pdfcrack doesn't respect the -n or -m flags

[Henning Norén]

This issue is now resolved in pdfcrack 0.20 (just released).
The problem with parsing the integer of -n or -m arguments can be
worked around by either:

pdfcrack -f document.pdf -n 9

or:

pdfcrack -f document.pdf -minpw=9

but now even this should work:

pdfcrack -f document.pdf -n=9

Kind Regards,
Henning Norén


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

Bug#1023203: ITP: golang-github-vektah-gqlparser -- A port of the parser from graphql-js into golang

[Taavi Väänänen]

Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 
Control: block -1 by 1023097
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-vektah-gqlparser
  Version : 2.5.1-1
  Upstream Author : Adam Scarr
* URL : https://github.com/vektah/gqlparser
* License : Expat
  Programming Lang: Go
  Description : A port of the parser from graphql-js into golang

gqlparser is a parser for GraphQL, written to mirror the graphql-js
reference implementation as closely while remaining idiomatic and easy
to use.

It currently targets the June 2018 version of the spec.

I am packaging this since it is a dependency of the sr.ht CLI tool hut
(https://git.sr.ht/~emersion/hut).


OpenPGP_0xEF242F709F912FBE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023202: [l10n] Updated Czech translation of apt-listbugs

[Miroslav Kure]

Package: apt-listbugs
Severity: wishlist
Tags: l10n, patch

Hi,

in attachement there is updated Czech (cs.po) translation of 
apt-listbugs. Please include it with the package.

Thank you
-- 
Miroslav Kure
# Czech translation of apt-listbugs.
# Copyright (C) 2002-2020 apt-listbugs authors
# This file is distributed under the same license as the apt-listbugs package.
# Miroslav Kure , 2005, 2009, 2012, 2014, 2016, 2019, 2020, 
2022.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listbugs 0.1.34\n"
"Report-Msgid-Bugs-To: invernom...@paranoici.org\n"
"POT-Creation-Date: 2022-10-22 17:16+0200\n"
"PO-Revision-Date: 2022-10-31 15:14+0100\n"
"Last-Translator: Miroslav Kure \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"

#. TRANSLATORS: "E: " is a label for error messages; you may translate it with 
a suitable abbreviation of the word "error"
#: ../bin/apt-listbugs:429 ../bin/apt-listbugs:462 ../bin/apt-listbugs:467
#: ../bin/apt-listbugs:473 ../bin/apt-listbugs:487 ../bin/apt-listbugs:517
#: ../bin/apt-listbugs:548 ../bin/apt-listbugs:597 ../bin/apt-listbugs:610
#: ../lib/aptlistbugs/logic.rb:310 ../lib/aptlistbugs/logic.rb:320
#: ../lib/aptlistbugs/logic.rb:1072 ../lib/aptlistbugs/logic.rb:1084
#: ../lib/aptlistbugs/logic.rb:1097 ../libexec/aptcleanup:52
#: ../libexec/aptcleanup:55
msgid "E: "
msgstr "E: "

#: ../bin/apt-listbugs:430
msgid ""
"This may be caused by a package lacking support for the ruby interpreter in "
"use. Try to fix the situation with the following commands:"
msgstr ""
"To může být způsobeno balíkem bez podpory použitého interpretru ruby. Zkuste "
"vzniklou situaci vyřešit těmito příkazy:"

#: ../bin/apt-listbugs:462
msgid ""
"APT_HOOK_INFO_FD is undefined.\n"
msgstr ""
"APT_HOOK_INFO_FD není definovaná.\n"

#: ../bin/apt-listbugs:467
msgid ""
"APT_HOOK_INFO_FD is not correctly defined.\n"
msgstr ""
"APT_HOOK_INFO_FD není definovaná správně.\n"

#: ../bin/apt-listbugs:473
msgid "Cannot read from file descriptor %d"
msgstr "Nelze číst z deskriptoru souboru %d"

#: ../bin/apt-listbugs:487
msgid ""
"APT Pre-Install-Pkgs failed to provide the expected 'VERSION 3' string.\n"
msgstr ""
"APT Pre-Install-Pkgs nevrátil očekávaný řetězec „VERSION 3“.\n"

#: ../bin/apt-listbugs:517
msgid ""
"APT Pre-Install-Pkgs provided fewer fields than expected.\n"
msgstr ""
"APT Pre-Install-Pkgs vrátil méně polí, než je očekáváno.\n"

#: ../bin/apt-listbugs:548
msgid ""
"APT Pre-Install-Pkgs provided an invalid direction of version change.\n"
msgstr ""
"APT Pre-Install-Pkgs vrátil neplatný směr změny verze.\n"

#: ../bin/apt-listbugs:627
msgid "** Exiting with an error in order to stop the installation. **"
msgstr "** Ukončeno s chybou s cílem ukončit instalaci. **"

#: ../lib/aptlistbugs/logic.rb:49
msgid "Usage: "
msgstr "Použití: "

#: ../lib/aptlistbugs/logic.rb:50
msgid " [options]  [arguments]"
msgstr " [volby]  [argumenty]"

#: ../lib/aptlistbugs/logic.rb:52
msgid ""
"Options:\n"
msgstr ""
"Volby:\n"

#. TRANSLATORS: the colons (:) in the following strings are vertically aligned, 
please keep their alignment consistent
#. TRANSLATORS: the \"all\" between quotes should not be translated
#: ../lib/aptlistbugs/logic.rb:55
msgid ""
" -s   : Filter bugs by severities you want to see\n"
"(or \"all\" for all)\n"
"[%s].\n"
msgstr ""
" -s   : Zobrazí jen chyby daných závažností\n"
"(nebo „all“ pro všechny)\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:56
msgid ""
" -T : Filter bugs by tags you want to see.\n"
msgstr ""
" -T <štítky>  : Zobrazí jen chyby s danými štítky.\n"

#: ../lib/aptlistbugs/logic.rb:57
msgid ""
" -S   : Filter bugs by pending-state categories you want to see\n"
"[%s].\n"
msgstr ""
" -S: Zobrazí jen chyby daných stavů\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:58
msgid ""
" -B : Filter bugs by number, showing only the specified bugs.\n"
msgstr ""
" -B   : Zobrazí pouze chyby daných čísel.\n"

#: ../lib/aptlistbugs/logic.rb:59
msgid ""
" -D   : Show downgraded packages, too.\n"
msgstr ""
" -D   : Vypíše také chyby v degradovaných balících.\n"

#: ../lib/aptlistbugs/logic.rb:60
msgid ""
" -H : Hostname of Debian Bug Tracking System [%s].\n"
msgstr ""
" -H  : Jméno počítače na němž běží debianí BTS [%s].\n"

#: ../lib/aptlistbugs/logic.rb:61
msgid ""
" -p : Port number of the server [%s].\n"
msgstr ""
" -p : Číslo portu na serveru [%s].\n"

#: ../lib/aptlistbugs/logic.rb:62
msgid ""
" -P : Pin-Priority value [%s].\n"
msgstr ""
" -P : Hodnota Pin-Priority [%s].\n"

#: ../lib/aptlistbugs/logic.rb:63
msgid ""
" -E: Title of RSS output.\n"
msgstr ""
" -E  : Titulek RSS výstupu.\n"

#: 

Bug#1023201: unbuffer: ignores errors from signal-killed programs

[Jakub Wilk]

Package: expect
Version: 5.45.4-2+b1

unbuffer(1) ignores errors from programs that were killed by a signal:

   $ perl -e 'use POSIX; raise(SIGABRT)'
   Aborted

   $ echo $?
   134

   $ unbuffer perl -e 'use POSIX; raise(SIGABRT)'

   $ echo $?
   0


-- System Information:
Architecture: i386

Versions of packages expect depends on:
ii  tcl8.6  8.6.12+dfsg-1+b1
ii  libc6   2.35-4
ii  libtcl8.6   8.6.12+dfsg-1+b1
ii  tcl-expect  5.45.4-2+b1

--
Jakub Wilk

Bug#1005092: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13

[Daichi Fukui]

Hi Leo,

Thanks for your reply.

On Tue, 18 Oct 2022 13:37:12 + "Singer, Leo P. (GSFC-6610)" <
leo.p.sin...@nasa.gov> wrote:
> Hi Daichi,
>
> Yes, I can do that next week. (I am traveling and do not have my Debian
key on me.)
>
> Leo
>
> From: Daichi Fukui 
> Date: Tuesday, October 18, 2022 at 09:36
> To: "1005...@bugs.debian.org" <1005...@bugs.debian.org>
> Cc: "leo.sin...@ligo.org" 
> Subject: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13
>
> Dear maintainer
> CC: Leo Singer
>
> > Dear maintainer,
> >
> > I am currently packaging cmyt [1], which is a new dependency of the "yt"
> > package. For testing, cmyt requires at least version 0.13 of pytest-mpl.
> > Could I ask to update the version in Debian to this latest version?
> >
> > Thank you very much!
> >
> > Ole
> If you don't mind, can I work on updating this package to version 0.13?
> I'd be happy if I could contribute to this one and the Astro team.
>
> FYI, I've CC'd this email to Leo because it seems Leo is the top
contributor according to d/changelog.
>
> Best,
> Fukui

It's been a while since we had a conversation some ten days ago.
I just want to let you know that I'm still working on this and need some
time to complete the package draft.
This is because pytest returns a bunch of errors with the updated source
code.
I'm now trying to address them.

Best,
Fukui

Bug#1023200: va-driver-all: buggy or unstable behavior on older i965 GPU

[Eduard Bloch]

Package: va-driver-all
Version: 2.16.0-1
Severity: important

Dear Maintainer,

Please dispatch this ticket as you see fit. I report this against va-driver-all
since it seems to have indirectly lead to the trouble, and there is no README
in va-driver-all which would explain the rules of the game.

My system has been working fine with Sid until a couple of months ago. IIRC,
last year I checked the vainfo config and eventually enabled it even in Firefox
(Chrome was fine out of the box).

However, now the CPU consumption in Chrome is back to high in Video playback,
feels like the GPU acceleration started failing silently. Investigation on the
issue has caused trobule, see below. And setting popular env. vars like
MESA_LOADER_DRIVER_OVERRIDE=i965 did not help.

Hardware:

Lenovo X250 (older revision)

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller 
(rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI 
Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM 
(rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio 
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #6 
(rev e3)
00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 
(rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller 
(rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller 
[AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP 
Thermal Management Controller (rev 03)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI 
Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 99)

Situation 1:

va-driver-all is installed (that installs intel-media-va-driver; see below for 
intel-media-va-driver-nonfree effects).

Result:

on some H264 videos, VLC is not accelerated, framerate is terrible, like 2-5 
fps.
On bigger ones, VLC simply crashes. Where? Here:

Module libudev.so.1 from deb systemd-252~rc3-2.amd64
Module libsystemd.so.0 from deb systemd-252~rc3-2.amd64
Stack trace of thread 3269:
#0  0x7f4eca507730 _Z21mos_bo_wait_renderingP12mos_linux_bo 
(iHD_drv_video.so + 0x107730)
#1  0x7f4eca718db9 
_ZN14DdiMediaDecode12CreateBufferE12VABufferTypejjPvPj (iHD_drv_video.so + 
0x318db9)
#2  0x7f4eca6fe0ac 
_Z21DdiMedia_CreateBufferP15VADriverContextj12VABufferTypejjPvPj 
(iHD_drv_video.so + 0x2fe0ac)
#3  0x7f4f38c9e870 vaCreateBuffer (libva.so.2 + 0x6870)
#4  0x7f4f0060ab85 n/a (libvdpau_va_gl.so.1 + 0xab85)
#5  0x7f4f0060b2ac n/a (libvdpau_va_gl.so.1 + 0xb2ac)
#6  0x7f4f0060b879 n/a (libvdpau_va_gl.so.1 + 0xb879)
#7  0x7f4f1f200f78 n/a (libavcodec.so.59 + 0x800f78)
#8  0x7f4f1f2028b4 n/a (libavcodec.so.59 + 0x8028b4)
#9  0x7f4f1ed8a28c n/a (libavcodec.so.59 + 0x38a28c)
#10 0x7f4f1ed9ff3e n/a (libavcodec.so.59 + 0x39ff3e)
#11 0x7f4f1f06756b n/a (libavcodec.so.59 + 0x66756b)
#12 0x7f4f7628784a start_thread (libc.so.6 + 0x8784a)
#13 0x7f4f7630b2cc __clone3 (libc.so.6 + 0x10b2cc)

Before it brings:

VLC media player 3.0.18-rc2 Vetinari (revision 3.0.13-8-g41878ff4f2)
[55f30ff19610] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: Kann 
die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden 
(search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, 
suffix _dri)
libGL error: failed to load driver: i965
[55f30fff2db0] main audio output error: too low audio sample frequency (0)
[7ff9e4c96810] main decoder error: failed to create audio output
[55f30fff2db0] vlcpulse audio output error: digital pass-through stream 
connection failure: Eingabe/Ausgabe-Fehler
[55f30fff2db0] main audio output error: module not functional
[7ff9e4c96810] main decoder error: failed to create audio output
libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: 
Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht 
gefunden (search paths 

Bug#1023193: RFS: libtrio/1.16+dfsg1-6 [ITA] -- portable and extendable printf and string functions

[Bastian Germann]

This qualifies more as a QA upload.
The only changes are version bumps and adding the s in https...

Please only adopt a package if you can show actual changes.

Bug#1023199: RFP: node-evacuated-tslint-config-prettier -- Use TSLint with Prettier without any conflict

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name:  node-evacuated-tslint-config-prettier
  Upstream Author :   Alex Jover Morales 
* URL :
https://git.freecumextremist.com/themusicgod1/evacuated-tslint-config-prettier
* License : MIT
  Programming Lang: javascript
  Description :  Use TSLint with Prettier without any conflict

tslint-config-prettier disables all conflicting rules that may cause
such problems. Prettier takes care of the formatting whereas tslint
takes care of all the other things.
This package has been evacuated from NSA/Microsoft github.

 is a dev-dependency of node-threads (not yet RFPd)

Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel

[Wookey]

On 2022-10-30 21:54 +0500, Akbarkhon Variskhanov wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "xfce4-calculator-plugin":
> 
>  * Package name : xfce4-calculator-plugin
>Version  : 0.7.1-1
>Upstream contact :
> https://gitlab.xfce.org/panel-plugins/xfce4-calculator-plugin/-/project_members
>  * URL  :
> https://docs.xfce.org/panel-plugins/xfce4-calculator-plugin/start
>  * License  : GPL-2.0+
>  * Vcs  : [fill in URL of packaging vcs]
>Section  : xfce

Thanks for packaging this.

> The source builds the following binary packages:
> 
>   xfce4-calculator-plugin - calculator plugin for Xfce panel

The description could be more useful.
"The plugin supports common mathematical operators (+, -, *, /, ^) with usual
 precedence rules, and some common functions such as abs(x), sqrt(x), sin(x)
 and cos(x)."

It needs to say what this _is_. Perhaps something like
 "Provides on-screen calculator from toolbar", then details as above.

I'd add Adrian Dimitrov  to the copyright list
and the package includes the LGPL COPYING.LIB at top level, although it's not 
obvious if that actually applies to any of the code.
If it does then the LGPL should be listed (maybe you already checked this?).

Otherwise it looks fine.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature