Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free

[Axel Beckert]

Hi,

there are two variants in which this tag is emitted, with different
parameters:

One is

  archive-liberty-mismatch (in section for $installable) $area1 vs $area2 
[$path]

The other one is:

  archive-liberty-mismatch (in source paragraph) $area1 -> $area2 [$path]

Kibi's patch patches the second variant and Andreas' patch patches the
first variant — which was also the one emitted by running Lintian
against his package.

So it makes sense that Kibi's patch didn't fix Andreas' false
positive. Nevertheless Kibi found a likely problematic part of the
code.

Axel Beckert wrote:
> > changing this:
> > for my $inferior_liberty ('non-free', 'contrib') {
> > into this:
> > for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
> […]
> > # must remain inferior
> > last
> >   if $inferior_liberty eq $source_liberty;
> 
> Thanks for that analysis. I suspect this type of change is probably
> necessary. Will have a closer look at it.

I must admit, I'm not sure what the check emitting the second variant
(and patched with Kibi's patch) actually does check for. (I have a vague
idea, but that's it.)

And unfortunately I don't find any example for it I could test it
against. Both, lintian's test suite as well as (the in this case
luckily outdated
https://lintian.debian.org/tags/archive-liberty-mismatch only know
examples of the first type. And
https://udd.debian.org/lintian-tag.cgi?tag=archive-liberty-mismatch
doesn't report any anymore. (Probably doesn't check non-free packages.
Or lags a bit behind.)

So I tried to figure out when this got added and to see if there's an
accompaning bug report:

Figured out that tag got renamed twice and wasn't mentioned in
debian/changelog by its name upon its introduction. Which didn't make
searching for that bug report easier.

So I tried git log and git blame. That ended quickly at a commit with
the commit message "Split the check debian/control into 26 smaller
checks.". And then "Move all checks into the module name space under
./lib". And then "Capitalize module names for checks in camel case;
drop underscores." And then "Move check control-file to
'debian/control'." And then "checks: Rename all checks to include a
".pm" extension". *sigh*

At that point I at least reached the commit which renamed the tag for
the first time: d431e568dc33b6f862466218908d337fff43626b from 2009.
>From there on searching through "git -log -p -- checks/control-file"
helped.

There seemed to be no bug report associated, the tag has been
introduced by Russ in commit
204fbd7b78a95e4d940ee1eea647fe365ccaaa4f in 2006. But back then the
code looks very different and only seems to check binary packages.

So I ended up following every change in that tag with

  git log -p -- lib/Lintian/Check/Archive/Liberty/Mismatch.pm 
lib/Lintian/Check/Debian/Control.pm checks/Debian/Control.pm 
checks/debian/control.pm checks/control-file.pm checks/control-file

The first commit which added a second variant checking source against
binary packages is 2e83812c19e1466bc05e65bb3fa52b33e33305e8 by Ivo De
Decker from 2019, i.e. rather recently:

Check for sources in the "main" section with only binaries in the contrib 
section. (Closes: #928126)

But that code is still very clear and readable. And its obvious what
it does.

So actually the commit that changed the code to become way more
convoluted and unreadable was this one:

  commit 1edef669729b04bc67d480b81568dfa8e5e3ae0f
  Author: Felix Lechner 
  Date:   Mon Nov 1 05:03:13 2021 -0700

Split the check debian/control into 26 smaller checks.

Gbp-Dch: ignore

Yes, this one. Took me a few attempts to realize, too. And no, it
didn't just split up code. It basically rewrote the check so much
(maybe even from scratch?) that I can't really recognize which part of
the new code resembles what part in the old file. Especially that "in
ascending order of liberty" got introduced there.

It also renamed the emitted tag from section-area-mismatch to
archive-liberty-mismatch without even mentioning it the commit
message. 

Not to mention that really inappropriate "Gbp-Dch: ignore" for such a
profound rewrite. 奈

And since there's no test for that variant, I can't even tell if it
still works properly. Not even thinking about changing it without
knowing how to test it.

So I'll keep my fingers of that code shortly before the soft freeze
unless someone gives me an example that either triggers the second
variant of this tag or one that doesn't trigger it, but should.

> > The attached patch does make the error go away by adding an exception for
> > 'non-free-firmware build from non-free' similar to 'contrib built from main'
> 
> > --- /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm.orig   
> > 2023-02-03 00:30:29.782861611 +0100
> > +++ /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm
> > 2023-02-03 01:02:12.441805855 +0100
> > @@ -87,6 +87,9 @@
> >  # special exception for 

Bug#1028728: deap: FTBFS: AssertionError: CMA algorithm did not converged properly.

[s3v]

Control: forwarded -1 
https://github.com/DEAP/deap/commit/0453060f6d9fce4e712f0f3479733118b2655bb4
thanks

Dear Maintainer,

> ==
> ERROR: deap.tests.test_algorithms.test_nsga3
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File 
>"/<>/.pybuild/cpython3_3.10_deap/build/deap/tests/test_algorithms.py",
> line 213, in test_nsga3
> pop = toolbox.select(pop, len(pop))
>   File 
>"/<>/.pybuild/cpython3_3.10_deap/build/deap/tools/emo.py", line 
>554, in selNSGA3
> selected = niching(pareto_fronts[-1], n, niches[sel_count:], 
>dist[sel_count:], niche_counts)
>   File 
>"/<>/.pybuild/cpython3_3.10_deap/build/deap/tools/emo.py", line 
>624, in niching
> available = numpy.ones(len(individuals), dtype=numpy.bool)
>   File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 284, in 
>__getattr__
> raise AttributeError("module {!r} has no attribute "
> AttributeError: module 'numpy' has no attribute 'bool'
>
> --
> Ran 27 tests in 0.754s
>
> FAILED (errors=1)

This issue was fixed upstream and I can confirm the build is fine and all
test pass after applying aforementioned commit.

Kind Regards

Bug#1030568: src:cross-toolchain-base-mipsen: fails to migrate to testing for too long: unsatisfiable Build-Depends

[Paul Gevers]

Source: cross-toolchain-base-mipsen
Version: 21
Severity: serious
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s) and mips* porter(s),

Please consider this an official warning for the mipsel and mips64el 
ports. Several key packages that are specific for mips* are behind in 
testing for way too long (bug #1023706, #1026129, #1026128) and so far 
I've only seen action after reminders.


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:cross-toolchain-base-mipsen has been 
trying to migrate for 61 days [2]. Hence, I am filing this bug. Your 
package has a Build-Depends on linux-source-6.0 but that's no longer the 
linux version in testing.


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.


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030567: ITP: libbiblio-lcc-perl -- parse and normalize LC-style call numbers

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbiblio-lcc-perl
  Version : 0.09
  Upstream Author : 2007 Paul M. Hoffman 
* URL : https://metacpan.org/release/Biblio-LCC
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : parse and normalize LC-style call numbers

Biblio::LCC parses Library of Congress classification ranges and call numbers
and normalizes them into a form suitable for a straight ASCII sort.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030009: www.debian.org: addition of non-free-firmware for bookworm and higher

[Laura Arjona Reina]

Hello again

I have made a list of website files under /english, mentioning nonfree 
or non-free. Not all of them may need updates but I think we should 
review them all to be sure.


I have created a pad to ease the collaborative work of reviewing files:

https://storm.debian.net/shared/Daxsx1pQoBV0v1aPODgReIShC_qnpevLdvXNwQewADa

Shortened URL: https://deb.li/1030009

I'm pasting the list of files below for reference.

I still didn't start to review any file, and some of them I think other 
teams can help (CDVendors, internationalization scripts...) I'll CC them 
when I get to those files and post here (in the bug report) my 
proposals, with commits to the GR-non-free-firmware branch.



List of files that need review/update
Relevant files mentioning nonfree or non-free

blends/index.wml
Bugs/server-request.wml

CD/faq/index.wml
CD/http-ftp/index.wml
CD/live/index.wml
CD/netinst/index.wml
CD/torrent-cd/index.wml

devel/debian-installer/images.data
devel/debian-installer/index.wml

devel/join/nm-step3.wml

distrib/archive.wml
distrib/index.wml
distrib/netinst.wml
distrib/search_packages-form.inc

download.wml
intro/about.wml
intro/philosophy.wml
legal/cryptoinmain.wml
legal/licenses/index.wml

releases/bookworm/debian-installer/index.wml
releases/bookworm/errata.wml

releases/trixie/debian-installer/index.wml
releases/trixie/errata.wml

releases/bullseye/debian-installer/index.wml
releases/bullseye/errata.wml
releases/buster/debian-installer/index.wml
releases/buster/errata.wml
(etc, similar for former releases)

releases/proposed-updates.wml

security/faq.wml
security/index.wml

template/debian/legal_tags.wml
template/debian/release_images.wml
template/debian/release_info.wml

CD/vendors/debiancd.db
CD/vendors/getvendors.pl

international/l10n/data/synonyms
international/l10n/ddtp.wml
international/l10n/po4a/pot.wml
international/l10n/po-debconf/errors-by-pkg.inc
international/l10n/po-debconf/ok.inc
international/l10n/po-debconf/pot.wml
international/l10n/po-debconf/todo.inc
international/l10n/po-debconf/untranslated.inc
international/l10n/po/ok.inc
international/l10n/po/pot.wml
international/l10n/po/todo.inc
international/l10n/po/todo.wml
international/l10n/po/untranslated.inc
international/l10n/README
international/l10n/scripts/fix-files.sh
international/l10n/scripts/gen-files.pl
international/l10n/scripts/transmonitor-check

mirror/mirror_list.pl


Kind regards
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#974470: Upload needed - python-scripttest - autopkgtest must be marked superficial

[Malik Mlitat]

Hello DPT,

I closed #974470 [1] and marked tests in python-scripttest as superficial.

The package with version 1.3-6 could be now uploaded [2] .

Thank you in advance

Malik

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974470

[1] https://salsa.debian.org/python-team/packages/python-scripttest/-/tags

Bug#1030566: ITP: libtemplate-plugin-gettext-perl -- Gettext Support For the Template Toolkit Version 2

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtemplate-plugin-gettext-perl
  Version : 0.7
  Upstream Author : Guido Flohr 
* URL : https://metacpan.org/release/Template-Plugin-Gettext
* License : LGPL-3+
  Programming Lang: Perl
  Description : Gettext Support For the Template Toolkit Version 2

Template::Plugin::Gettext provides an end-to-end localization and
internationalization solution for the Template Toolkit 2.

It consists of a plugin that offers translation functions inside
templates and a string extractor xgettext-tt2 that extracts translatable
strings from templates and writes them to PO files (or rather a .pot file
in PO format).

The string extractor xgettext-tt2 is fully customizable and also usable for
other i18n plugins or frameworks for the Template Toolkit.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1028554: [Debian-on-mobile-maintainers] Bug#1028554: osk-sdl: Missing initial configuration

[Undef]

On 1/13/23 03:48, /dev/fra via Debian-on-mobile-maintainers wrote:


After installing osk-sdl I was expecting it to show up automatically at
the next boot, but that was not the case. I had to edit /etc/crypttab,
add the option

"keyscript=/usr/share/initramfs-tools/scripts/osk-sdl-keyscript"

and then update initramfs.

Shouldn't this configuration step be performed automatically during the
installation instead?



Thanks for the bug report.

I'm not sure I'd agree that this is the packages job to configure. In 
#1014393 we decided to remove config automatically, but that was a 
single very specific instance that always leaves the system unbootable.


In this case the package would have to add the config, potentially 
breaking what the user was doing before.


The basic version of this might be `sed -i 
"s:$:keyscript=/usr/share/initramfs-tools/scripts/osk-sdl-keyscript:" 
/etc/crypttab`, but this will break if the user is already using 
keyfiles for example.



If you can think of a robust way of fixing this I'm happy to 
review/include a patch, I just worry that most solutions will break 
existing (and unknown) installs that were already bootable. Any solution 
should also ensure that if it changes the config the debconf flag to 
revert the change is also set.

Bug#1030325: lintian: archive-liberty-mismatch (in section for firmware-nvidia-gsp) non-free-firmware vs non-free

[Axel Beckert]

Hi Andreas and Kibi,

Andreas Beckmann wrote:
> while preparing the move of firmware-nvidia-gsp from non-free to
> non-free-firmware I noticed this error from lintian:
> 
> E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for 
> firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106]

Thanks for that bug report! non-free packages alone are seldom enough
so that these checks don't get a chance to be checked for the in the
wild already, and non-free-firmware is even more seldom.

Cyril Brulebois wrote:
> Andreas Beckmann  (2023-02-02):
> > while preparing the move of firmware-nvidia-gsp from non-free to
> > non-free-firmware I noticed this error from lintian:
> > 
> > E: nvidia-graphics-drivers source: archive-liberty-mismatch (in section for 
> > firmware-nvidia-gsp) non-free-firmware vs non-free [debian/control:106]
> 
> Without a deep understanding of concepts or implementation, maybe a
> quick fix would be to consider non-free-firmware of lower liberty than
> non-free

For this implementation it looks like that on a first glance, yes.
Need to dig into this deeper, too, though.

> (even if they really should be considered the same),

I'd even say higher liberty due that infamous GR: There are obviously
people who would accept non-free-firmware on their systems, but not
other non-free packages. So non-free-firmware must be a bit more
"free" than "non-free". ;-P (And yes, in most cases, it's less "free"
than most software in "non-free". That's why I still don't get the
outcome of that GR. But I'm digressing...)

> changing this:
> for my $inferior_liberty ('non-free', 'contrib') {
> into this:
> for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
[…]
> # must remain inferior
> last
>   if $inferior_liberty eq $source_liberty;

Thanks for that analysis. I suspect this type of change is probably
necessary. Will have a closer look at it.

Andreas Beckmann wrote:
> >  for my $inferior_liberty ('non-free', 'contrib') {
> > into this:
> >  for my $inferior_liberty ('non-free-firmware', 'non-free', 'contrib') {
> 
> That doesn't work for me (but may be needed for other cases).

I suspect the latter, too.

> The attached patch does make the error go away by adding an exception for
> 'non-free-firmware build from non-free' similar to 'contrib built from main'

> --- /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm.orig 
> 2023-02-03 00:30:29.782861611 +0100
> +++ /usr/share/lintian/lib/Lintian/Check/Archive/Liberty/Mismatch.pm  
> 2023-02-03 01:02:12.441805855 +0100
> @@ -87,6 +87,9 @@
>  # special exception for contrib built from main
>  next
>if $source_liberty eq 'main' && $installable_liberty eq 'contrib';
> +# and non-free-firmware built from non-free
> +next
> +  if $source_liberty eq 'non-free' && $installable_liberty eq 
> 'non-free-firmware';
>  
>  my $control_item= $self->processable->debian_control->item;
>  my $position = $installable_fields->position('Section');

Thanks for that patch, too. Maybe both are necessary. Will check.

Unfortunately firmware-nvidia-gsp/nvidia-graphics-drivers is rather
large and I ran out of disk space when first unpacking it in my home
directory. Will need to run my checks elsewhere for now. Or buy new
SSDs. %-)

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

Bug#1030565: ITP: libtext-undiacritic-perl -- remove diacritics from a string

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtext-undiacritic-perl
  Version : 0.07
  Upstream Author : Helmut Wollmersdorfer 
* URL : https://metacpan.org/release/Text-Undiacritic
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : remove diacritics from a string

Text::Undiacritic provides a module that changes characters with diacritics
into their base characters.

Also changes into base character in cases where UNICODE does not provide a
decomposition.

E.g. all characters '... WITH STROKE' like 'LATIN SMALL LETTER L WITH STROKE'
do not have a decomposition. In the latter case the result will be 'LATIN
SMALL LETTER L'.

Removing diacritics is useful for matching text independent of spelling
variants.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#968467: ENC: Bug#968467: RE: Bug#968467: (librosa)

[Nilson Silva]

Hello Bastian!

I think we're done.
https://salsa.debian.org/debian/librosa

I had to disable a documents/examples directory as well as the tests.
Both make use of the external repository 
https://github.com/librosa/librosa-test-data,

which is unlicensed. I already related this to upstream:
https://github.com/librosa/librosa/issues/1654


Thank you for everything!
Nilson F. Silva



De: Nilson Silva 
Enviado: sexta-feira, 27 de janeiro de 2023 14:32
Para: Bastian Germann ; 968...@bugs.debian.org 
<968...@bugs.debian.org>
Assunto: RE: Bug#968467: RE: Bug#968467:

Hello Bastian!
OK. I'm going to work on it this weekend.


Nilson F. Silva


De: Bastian Germann 
Enviado: sexta-feira, 27 de janeiro de 2023 14:13
Para: 968...@bugs.debian.org <968...@bugs.debian.org>
Assunto: Bug#968467: RE: Bug#968467:

On Wed, 29 Jun 2022 22:41:56 + Nilson Silva  
wrote:
> By the way, could you sponsor Bastian?

When I change the llvm-toolchain-11 to llvm the package starts building. I see 
the following, which needs to be fixed:

Downloading file 'Karissa_Hobbs_-_Let's_Go_Fishin'.ogg' from
'https://librosa.org/data/audio/Karissa_Hobbs_-_Let's_Go_Fishin'.ogg' to 
'/home/bage/librosa/.cache/librosa'.
generating gallery for auto_examples... [ 36%] plot_superflux.py
Downloading file 'sorohanro_-_solo-trumpet-06.hq.ogg' from
'https://librosa.org/data/audio/sorohanro_-_solo-trumpet-06.hq.ogg' to 
'/home/bage/librosa/.cache/librosa'.
generating gallery for auto_examples... [ 45%] plot_pcen_stream.py
Downloading file 'glacier-bay-humpback.ogg' from 
'https://librosa.org/data/audio/glacier-bay-humpback.ogg' to
'/home/bage/librosa/.cache/librosa'.
generating gallery for auto_examples... [ 54%] plot_music_sync.py

Bug#431800: retitle 431800 to [rmadison]: please add debian-ports.org support

[Paul Wise]

Source: devscripts
Source-Version: 2.23.0
Done: Benjamin Drung 

On Thu, 02 Feb 2023 16:30:24 +0800 Paul Wise wrote:

> This will be fixed in the devscripts 2.22.3 release.

This upload happened but the bug didn't get closed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1030564: ITP: ocaml-uuseg -- unicode text segmentation for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-uuseg
  Version : 15.0.0
  Upstream Contact: The uuseg programmers
* URL : https://erratique.ch/software/uuseg
* License : ISC
  Programming Lang: OCaml
  Description : unicode text segmentation for OCaml

 Uuseg is an OCaml library for segmenting Unicode text. It implements
 the locale independent Unicode text segmentation algorithms to detect
 grapheme cluster, word and sentence boundaries and the Unicode line
 breaking algorithm to detect line break opportunities.
 .
 The library is independent from any IO mechanism or Unicode text data
 structure and it can process text without a complete in-memory
 representation.

This package is a new dependency of zed. It will be maintained in the
OCaml Team.

Bug#1008763: torbrowser-launcher: Multiarch support

[Roger Shimizu]

On Fri, Apr 1, 2022 at 2:03 PM Richard Z  wrote:
>
> I think this lint warning is relevant:
> https://lintian.debian.org/tags/package-contains-no-arch-dependent-files?version=2.114.162
>
> Might be best to mark it as
> Architecture: all

Upstream only support amd64 and i386
- https://aus1.torproject.org/torbrowser/update_3/release/
It's useless for other arch to install this package.

Cheers,
Roger

Bug#1030248: [PATCH] kexec: make -a the default

[наб]

I'm subscribed, passed greylist, got queued:
  Feb 03 00:17:58 tarta postfix/qmgr[17154]: 270C9B76: 
from=, size=6121, nrcpt=2 (queue active)
  Feb 03 00:18:01 tarta postfix/smtpd[899494]: connect from 
bombadil.infradead.org[198.137.202.133]
  Feb 03 00:18:02 tarta postfix/smtpd[899494]: 8D84B100A: 
client=bombadil.infradead.org[198.137.202.133]
  Feb 03 00:18:02 tarta postfix/smtpd[899494]: disconnect from 
bombadil.infradead.org[198.137.202.133] ehlo=2 starttls=1 mail=1 rcpt=1 quit=1 
commands=6
  Feb 03 00:18:04 tarta postfix/smtp[899865]: 270C9B76: 
to=, 
relay=bombadil.infradead.org[198.137.202.133]:25, delay=466, 
delays=460/0.02/1.8/4.2, dsn=2.0.0, status=sent (250 OK id=1pNiqA-00HOjV-Qp)
  Feb 03 00:18:04 tarta postfix/qmgr[17154]: 270C9B76: removed
and had no further infradead.org I/O ‒ didn't get a bounce,
or (like I historically did when posting to kexec@)
an "awaiting admin approval" notification,
and I don't see it in the archive:
  http://lists.infradead.org/pipermail/kexec/2023-February/thread.html
so hell knows if I actually got queued.

Thoughts?

наб


signature.asc
Description: PGP signature

Bug#1030563: ITP: libbiblio-sici-perl -- Provides methods for assembling, parsing, manipulating and serialising SICIs

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbiblio-sici-perl
  Version : 0.04
  Upstream Author : Heiko Jansen 
* URL : https://metacpan.org/release/Biblio-SICI
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Provides methods for assembling, parsing, manipulating and 
serialising SICIs

A "Serial Item and Contribution Identifier" (SICI) is a code (ANSI/NISO
standard Z39.56) used to uniquely identify specific volumes, articles or
other identifiable parts of a periodical.

Biblio::SICI provides methods for assembling, parsing, manipulating and
serialising SICIs.

Both internal implementation and public API are currently considered BETA and
may change without warning in a future release. For more information on this
have a look at the TODO section|/TODO below.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1013082: wine: CombineZP doesn't display a picture

[Michael Gilbert]

Günter Frenz wrote:
> version 6.18~repack-1 is the last working version. When comparing this
> to the current version 7.0, I noticed an error message in CombineZP
> saying "CreateCompatibleBitmap failed", maybe this helps too.

Bitmap handling was moved from dlls/gdi32 to dlls/win32u between 6.18
and 6.19 (commit 08f677ca).  There was also refactoring related to
bitmap memory allocation, which may be relevant (commit 6ea18f66).

That should be a start to begin working out which commit caused the problem.

Best wishes,
Mike

Bug#1014064: libqpid-proton-cpp12-dev: Missing CMake config files

[Nicholas Omann]

I noticed this same issue. I also noticed that with the latest version of the 
tests package that some of the pkg-config files are now missing with the update 
to 0.37. I attached a patch here that should fix both issues. Don't know what 
exactly the best way to go through getting this applied.

-- 
  Nicholas Omann
  alphaclus...@linux.comdiff --git a/debian/libqpid-proton-cpp12-dev.install b/debian/libqpid-proton-cpp12-dev.install
index 8fdd8434..b4a06c77 100644
--- a/debian/libqpid-proton-cpp12-dev.install
+++ b/debian/libqpid-proton-cpp12-dev.install
@@ -2,3 +2,4 @@ usr/include/proton/*.hpp
 usr/include/proton/*/*.hpp
 usr/lib/*/libqpid-proton-cpp.so
 usr/lib/*/pkgconfig/libqpid-proton-cpp.pc
+usr/lib/*/cmake/ProtonCpp/*.cmake
\ No newline at end of file
diff --git a/debian/libqpid-proton11-dev.install b/debian/libqpid-proton11-dev.install
index ec1e4a08..b5f157f9 100644
--- a/debian/libqpid-proton11-dev.install
+++ b/debian/libqpid-proton11-dev.install
@@ -1,4 +1,9 @@
 usr/include/proton/*.h
 usr/include/proton/*.i
 usr/lib/*/libqpid-proton.so
+usr/lib/*/libqpid-proton-core.so
+usr/lib/*/libqpid-proton-proactor.so
 usr/lib/*/pkgconfig/libqpid-proton.pc
+usr/lib/*/pkgconfig/libqpid-proton-core.pc
+usr/lib/*/pkgconfig/libqpid-proton-proactor.pc
+usr/lib/*/cmake/Proton/*.cmake
\ No newline at end of file

Bug#1030394: Couldn't be some interrupted install

[Dan Jacobson]

reopen 1030394
retitle 1030394 1.20 not cleaned up
thanks

Wait, on my other computer there is the exact same problem:

$ ls -log /usr/share/emacs/site-lisp/elpa/
drwxr-xr-x 2 4096 2018-08-07  circe-2.6
drwxr-xr-x 2 4096 2022-05-26  csv-mode-1.20
drwxr-xr-x 2 4096 01-25 12:31 csv-mode-1.21
drwxr-xr-x 2 4096 01-25 12:31 debian-el-37

Bug#995155: (no subject)

[Nathaniel Roach]

I can confirm that building 15.7 from the debian git, using it to boot 
(with secure boot off) with the right EFI entry results in the update 
going through:


sudo apt-get build-dep shim

sudo apt-get install libefivar-dev # New dependency that apt won't be 
aware of yet


git clone https://salsa.debian.org/efi-team/shim.git

dpkg-buildpackage -uc -b

sudo dpkg -i ../shim-unsigned_15.7-1~deb11u1_amd64.deb

sudo mv /boot/efi/EFI/debian/shimx64.efi 
/boot/efi/EFI/debian/shimx64-154.efi


sudo cp /usr/lib/shim/shimx64.efi /boot/efi/EFI/debian/shimx64.efi

-- reboot into firmware, disable secure boot --

-- boot the Linux-Firmware-Updater entry, let the system update --

-- boot back into debian --

sudo apt-get install shim-unsigned=15.4-7

sudo mv /boot/efi/EFI/debian/shimx64-154.efi 
/boot/efi/EFI/debian/shimx64.efi



Signing the shim with MOK doesn't work, FYI, I did try that.

--

*Nathaniel Roach*

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Osamu Aoki]

Control: clone 1030189 -1
Control: reassign -1 debian-faq

Thanks Sven,

How about Debian FAQ?  Shouldn't it mention non-free-firmware

 * debian-faq package
 * https://www.debian.org/doc/manuals/debian-faq/ftparchives.en.html

FYI: I already updated debian-reference

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_archive_basics

(minimal changes to avoid translation breakages)


> Le mer. 1 févr. 2023 à 21:36, Sven Joachim  a écrit :
> 
> > Control: reassign -1 release-notes
> >
...
> > Somehow, but how exactly?  Good question that was brought up on
> > debian-devel[2], alas without replies yet.
> >
> > Cheers,
> >    Sven
> >
> >
> > 1. https://lists.debian.org/debian-user/2023/01/msg00706.html
> > 2. https://lists.debian.org/debian-devel/2023/01/msg00312.html

Bug#1030561: ITP: libmath-random-mt-auto-perl -- Auto-seeded Mersenne Twister PRNGs

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmath-random-mt-auto-perl
  Version : 6.23
  Upstream Author : Jerry D. Hedden 
* URL : https://metacpan.org/release/Math-Random-MT-Auto
* License : BSD-3-clause
  Programming Lang: Perl
  Description : Auto-seeded Mersenne Twister PRNGs

The Mersenne Twister is a fast pseudorandom number generator (PRNG) that is
capable of providing large volumes (> 10^6004) of "high quality" pseudorandom
data to applications that may exhaust available "truly" random data sources
or system-provided PRNGs such as rand|perlfunc/"rand".

Math::Random::MT::Auto provides PRNGs that are based on the Mersenne Twister.
There is a functional interface to a single, standalone PRNG, and an OO
interface (based on the inside-out object model as implemented by the
Object::InsideOut module) for generating multiple PRNG objects. The PRNGs are
normally self-seeding, automatically acquiring a (19968-bit) random seed from
user-selectable sources. (Manual seeding is optionally available.)

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1017977: Fails to load intel/ibt-20-1-3.sfi

[Olaf Meeuwissen]

Olaf Meeuwissen  writes:

> I am currently on
>
>   firmware-iwlwifi/testing,now 20221214-3 all [installed]
>   linux-image-6.0.0-4-amd64/now 6.0.8-1 amd64 [installed,local]
>   linux-image-6.0.0-6-amd64/now 6.0.12-1 amd64 [installed,local]
>   linux-image-6.1.0-1-amd64/testing,now 6.1.4-1 amd64 [installed,automatic]
>   linux-image-amd64/testing,now 6.1.4-1 amd64 [installed,automatic]
>
> and still experience this issue when "cold" booting (i.e. after
> `poweroff`) linux-image-6.1.0.1.

Just checked again with 6.1.7-1 and still no joy :-(
--
Olaf Meeuwissen

Bug#1030560: Ugly // in symlinks

[Dan Jacobson]

Package: elpa-csv-mode
Version: 1.21-1
Severity: minor

We note the ugly double slashes. Yes, cosmetic problem only.
ls -og ...
/usr/share/emacs/site-lisp/elpa/csv-mode-1.21:
-rw-r--r-- 132 01-18 18:15 Install.log.gz
lrwxrwxrwx 172 01-18 18:15 csv-mode-autoloads.el -> 
/usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode-autoloads.el
lrwxrwxrwx 166 01-18 18:15 csv-mode-pkg.el -> 
/usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode-pkg.el
lrwxrwxrwx 168 01-18 18:15 csv-mode-tests.el -> 
/usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode-tests.el
-rw-r--r-- 1 15956 01-18 18:15 csv-mode-tests.elc
lrwxrwxrwx 162 01-18 18:15 csv-mode.el -> 
/usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode.el
-rw-r--r-- 1 57160 01-18 18:15 csv-mode.elc

Bug#1030559: speechpy-fast: autopkgtest failure

[Adrian Bunk]

Source: speechpy-fast
Version: 2.4-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/s/speechpy-fast/31022842/log.gz

...
autopkgtest [03:53:37]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import speechpy_fast; print(speechpy_fast)" ; done
autopkgtest [03:53:37]: test autodep8-python3: [---
Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'speechpy_fast'
autopkgtest [03:53:37]: test autodep8-python3: ---]
autopkgtest [03:53:37]: test autodep8-python3:  - - - - - - - - - - results - - 
- - - - - - - -
autodep8-python3 FAIL non-zero exit status 1

Bug#1029320: bullseye-pu: package w3m/0.5.3+git20210102-6+deb11u1

[Tatsuya Kinoshita]

On 2023-02-04 at 19:01 +, Adam D. Barratt wrote:
> On Sat, 2023-01-21 at 19:51 +0900, Tatsuya Kinoshita wrote:
> > I'd like to update package w3m in bullseye to fix a security issue,
> > managed as minor issue, no-dsa.
> > cf. https://security-tracker.debian.org/tracker/CVE-2022-38223
> >
>
> Please go ahead.

Uploaded.

Thanks,
--
Tatsuya Kinoshita


pgpUhdorUiFNO.pgp
Description: PGP signature

Bug#1030558: toil build-depends on missing python3-xdist

[Adrian Bunk]

Source: toil
Version: 5.9.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=toil=sid

toil build-depends on missing:
- python3-xdist:amd64


Should this be python3-pytest-xdist?

Bug#1030196: RFP: libzbd Zoned Block device Manipulation library and tools

[Sudip Mukherjee]

Control: close -1
--

Hi Tommy,

On Wed, Feb 01, 2023 at 12:59:09PM +0900, Tommy McGee wrote:
> 
> Package: wnnp
> Severity: wishlist
> 
> * Package name: libzbd
> * Version : 2.0.4
> * URL :https://github.com/westerndigitalcorporation/libzbd
> * License : GPL
>   Programming Language: C
>   Description :libzbd is a library providing functions
>   simplifying access to zoned block device information and the
>   execution of zone management operations.

libzbd is already in Debian - https://tracker.debian.org/pkg/libzbd

-- 
Regards
Sudip

Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration

[Joshua Peisach]

Hi Nicholas, I'm sorry for bunting. I really should be working with the emacsen 
team and using other examples. For this, I have created a branch called 
'1011594-fixes' which aims to solve these problems.

Before reading, just want to say that you aren't being harsh. You're giving the 
'deeply concerned and worried' attitude, not the 'how dare you' mood. You went 
into a lot of depth with the problems, and you are looking out for me. For what 
I am doing, it is sensible for me to do the work, so this is a good "pause and 
think" moment. I greatly appreciate it, no matter how deep of a hole I may be 
digging for myself. :)


  1.
Changelog for 'upstream release' - Using ggtags as an example, I'm setting that 
to "Update to new upstream commit" - 
https://salsa.debian.org/emacsen-team/ggtags/-/blob/master/debian/changelog
  2.  The patch. I had to fresh the patch. Honestly, I took the lazy route 
since I did not do this in a while and just.. created a new one and put your 
name down as the 'first' author to show you did it first.
 *   First: In terms of a FOSS project, what I did was tremendously dumb. I 
should've thought about what I was doing but I didn't. I was focused on getting 
the thing done by just doing what was needed to get dpkg-source and quilt apply 
the patch happily. and next time I need to think logistically about how to 
handle this.
 *   The wording I did was taken from you, for the 'Declare correct MELPA 
version'. The text in the patch is taken directly from the file. If it helps 
you understand what I did, I created an entirely new patch. I did the quilt 
new, quilt add, (edit-file-command), quilt refresh, quilt header -e --dep3, 
quilt pop.
 *   My current step process: I have reverted the commit (git revert. I 
rarely revert commits, and I try to avoid force pushing unless I'm tremendously 
lost). I am running back to Chapter 8 of the maintenance guide, setup dquilt 
and am following the updating patch part of section 8.3, under the conflict 
part with the new upstream source. I edit kotlin-mode.el file, ran dquilt push 
and refresh, going back to 8.1 for changelog. Using projectile's changelog as 
an example, and I'm saying "Refresh patch 0001 (update source version)"
  3.  Standards Version - I always use the updating checklist! It's the most 
helpful tool. Ran through both 4.6.1 and 4.6.2. I took your suggestion for 
"Declare compliance with.." though I've always used "Update Std-Ver". For a 
second changelog point, I should've put that in but I did not. For reasoning, I 
will say that the file says required emacs 24.3 and buster has 
1:26.1+1-3.2+deb10u3. Plus, for bookworm the current emacs version is 
1:28.2+1-10. Users keeping their system up-to-date meet the constraint.
  4.  Copyright years - I am a bit embarrased to say I had no idea Threshold of 
Originality is a thing. Looking at other examples, best thing to do is leave 
it. Unfortunately I cannot quite meet the 'one-time history change' as I have 
already used it on the patch, but I can offer you a commit that just takes off 
the -2023 with an explanation. Not every file has changed, and it seems there 
are different rules of threshold of originality per country. I am in the US 
personally, and I think I meet the "small value" but I don't feel like risking 
it.

I have just updated the changelog, made commits, the tests passed, ran lintian 
and fixed the changelog line being too long, updated changelog time again, 
committed and pushed.

If possible, can you review the branch?

Thanks again for checking everything out, and I am so sorry for all the 
problems created.

-Josh



From: Nicholas D Steeves
Sent: Monday, January 30, 2023 10:48 PM
To: Joshua Peisach; 1011...@bugs.debian.org
Subject: Re: Bug#1011594: Re: kotlin-mode needs a source-only upload for 
testing migration

Hi Josh,

Thank you for the quick reply, and for updating the maintainer :) I've
tried to write an email that will help you understand the issues with as
quickly as possible, since the final deadline is days away. 'hope it's
not too long or harsh 

As you know, Debian has high standards, and you may remember some of this
from our first review.  When you didn't follow up, I fixed the remaining
issues myself (see 30eb8be to faef886); This time around, please resolve
the issues noted below yourself, before the 5th of February.

If you're short on time and want to take the fastest path, skip to the
paragraph that starts with "If you want".

Upstream has not made a release, so the first changelog point is wrong.
What is really being packaged?

d51515f * Refresh and update patches
  - I would write the following no matter who the original author of the
  patch was: This looks like an attempt to take credit for someone
  else's work by making some some changes that aren't significant for
  the purposes of copyright; this sort of thing will eventually make you
  look bad and/or get you into trouble, so I'm 

Bug#1029254: wireshark: FTBFS: AttributeError: '_Outcome' object has no attribute 'errors'

[Bálint Réczey]

Control: fixed -1 4.0.3-1

Lucas Nussbaum  ezt írta (időpont: 2023. jan. 20., P, 12:02):
>
> Source: wireshark
> Version: 4.0.2-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230120 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
...
> > ERROR: test_text2pcap_sip_pcapng 
> > (suite_text2pcap.case_text2pcap_pcapng.test_text2pcap_sip_pcapng)
> > Test text2pcap with sip.pcapng.
> > --
> > Traceback (most recent call last):
> >   File "/<>/test/fixtures.py", line 321, in tearDown
> > self._orig_tearDown()
> >   File "/<>/test/subprocesstest.py", line 181, in tearDown
> > if self._last_test_failed():
> >
> >   File "/<>/test/subprocesstest.py", line 168, in 
> > _last_test_failed
> > for test_case, exc_info in self._outcome.errors:
> >
> > AttributeError: '_Outcome' object has no attribute 'errors'

Bug#1030557: ITP: golang-github-theupdateframework-go-tuf -- A framework for securing software in golang (library)

[Reinhard Tartler]

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

* Package name: golang-github-theupdateframework-go-tuf
  Version : 0.5.2
  Upstream Contact: https://github.com/theupdateframework/go-tuf
* URL : https://github.com/theupdateframework/go-tuf
* License : BSD-3-clause
  Programming Lang: golang
  Description : A framework for securing software in golang  (library)

The Update Framework (TUF) helps developers maintain the security of software
update systems, providing protection even against attackers that compromise
the repository or signing keys. TUF provides a flexible framework and
specification that developers can adopt into any software update system.

Bug#1030556: ITP: mkosi-initrd -- builds an initramfs using distribution packages

[Marco d'Itri]

Package: wnpp
Severity: wishlist
Owner: Marco d'Itri 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkosi-initrd
  Version : 0
  Upstream Contact: Zbigniew Jędrzejewski-Szmek
* URL : https://github.com/systemd/mkosi-initrd
* License : LGPL
  Programming Lang: Perl (?)
  Description : builds an initramfs using distribution packages

Uses the normal distribution packages and mkosi to create an initramfs.

A major goal of this project is being able to create standard and
static initramfs images which can be signed and shipped as packages by 
distributions.

It will be maintained by the systemd maintainers.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1030555: ITP: golang-github-secure-systems-lab-go-securesystemslib -- Cryptographic and general-purpose routines for Golang Secure Systems Lab projects at NYU

[Reinhard Tartler]

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

* Package name: golang-github-secure-systems-lab-go-securesystemslib
  Version : 0.4.0
  Upstream Contact: https://github.com/secure-systems-lab/go-securesystemslib
* URL : https://github.com/secure-systems-lab/go-securesystemslib
* License : Expat
  Programming Lang: Golang
  Description : Cryptographic and general-purpose routines for Golang 
Secure Systems Lab projects at NYU


Description: Cryptographic and general-purpose routines for Golang Secure 
Systems Lab projects at NYU (library)
 A library that provides cryptographic and general-purpose functions for
 Go Secure Systems Lab projects at NYU.

I plan to maintain this library under the pkg-golang umbrella.

It is one of the missing dependencies for sigstore

Bug#1030554: lomiri-camera-app build-depends on non-existing libgles2-dev

[Adrian Bunk]

Source: lomiri-camera-app
Version: 4.0.1+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=lomiri-camera-app

lomiri-camera-app build-depends on missing:
- libgles2-dev:amd64


libgles2-dev was a virtual package a long time ago,
libgles2-mesa-dev is the correct build dependency
(same for libgl1-mesa-dev, where libgl1-dev is the
alternative that could be dropped).

Bug#1026259: SW RAID to JFS intermittent boot fail with NULL pointer dereference

[Andy]

On 4 February 2023 22:28:05 CET, Salvatore Bonaccorso  wrote:
>Hi,
>
>On Fri, Feb 03, 2023 at 09:31:01AM +, RattusRattus wrote:
>> Dear team,
>> 
>> - Did I submit to the correct location?
>> - Is there anything additional information that you require?
>
>It is okay, but even better if the issue can be brough upstream. But
>that said, I would not expect really any progress, in fact upstream it
>is discussed if it might be removed in future, cf.
>https://lwn.net/Articles/920259/ .
>
>It seems to be a hard to tackle problem if it's not really
>reproducible and machine dependent. But if reproduces for you quite
>consistently, a bisect between the last known working version and
>kernel in recent bullseye point release which started failing might
>pin point us to the relevant change causing this.
>
>Dave, adding you to CC, this is about report
>https://bugs.debian.org/1026259 in Debian. This was noted with at
>least 5.10.158 based stable kernel in Debian. My understanding is that
>at least 5.10.127 was still fine.
>
>Regards,
>Salvatore
>

I can certainly reproduce the problem repeatedly, perhaps 50% of the time, 
maybe more.

Will happily bisect versions to see if I can identify if this is a regression 
or has always been present.

I may have some time available in a weeks time to investigate (half term)

I may be able to automate the process too

Best wishes
/Andy

Bug#1030140: rsyslog: Property-basesd filters are prevented from working by systemd config

[Reuben Thomas]

On Wed, 1 Feb 2023 at 17:04, Michael Biebl  wrote:

> Am 31.01.23 um 16:05 schrieb Reuben Thomas:
> > Package: rsyslog
> > Version: 8.2112.0-2ubuntu2.2
>
> This appears to be an Ubuntu version not known in the Debian archive
>

Apologies.


> > Severity: normal
> >
> > In order to work around a bug in scanbd (#901695), I tried to add a
> > property-based filter as /etc/rsyslog.d/99-scanbd.conf:
> >
> > :msg, regex, "/usr/sbin/scanbd: abandon polling of"
> ^/usr/local/sbin/restart-scanbd
>
> What exactly does restart-scanbd do? Does it call systemctl?
>

Yes it does. I see what you're saying: it's running systemctl "recursively"
that causes the error? If so, sorry, I got confused.

-- 
https://rrt.sc3d.org

Bug#1029385: bullseye-pu: package postfix/3.5.17-0+deb11u1

[Scott Kitterman]

On Saturday, February 4, 2023 1:57:15 PM EST Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2023-01-21 at 21:02 -0500, Scott Kitterman wrote:
> > Routine postfix bugfix update
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Thanks.  Uploaded.

Scott K

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

Bug#1030096: #1030096 dask.distributed autopkgtest fail

[Rebecca N. Palmer]

That removed most of the test failures, but there seem to be a few 
apparently random ones left (2 runs both failed, but with different errors).


On 04/02/2023 21:35, Andreas Tille wrote:

Any reason to not push to master directly?


I don't do that with packages that aren't mine.  Also see above.

Bug#1030553: tup FTBFS on hppa

[Helge Deller]

Package: tup
Tags: patch, ftbfs, hppa
Version: 0.7.11-3

The attached patch fixes the tup build on hppa.
In addition it would make sense that tup is compiled with the "future+lfs" flags
to support large files on large discs on 32-bit builds.
It currently builds with   -D_FILE_OFFSET_BITS=64 but large files is still 
missing.

Please apply to next upload.

Thanks!
Helgediff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org	2023-02-04 22:15:19.619396046 +
+++ ./debian/rules	2023-02-04 22:15:59.371776381 +
@@ -1,5 +1,5 @@
 #!/usr/bin/make -f
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all qa=+canary
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all qa=+canary future=+lfs
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
 
diff -up ./src/tup/platform.c.org ./src/tup/platform.c
--- ./src/tup/platform.c.org	2023-02-04 22:10:17.296503537 +
+++ ./src/tup/platform.c	2023-02-04 22:11:02.672937681 +
@@ -60,6 +60,8 @@ const char *tup_arch = "arm";
 const char *tup_arch = "arm64";
 #elif __s390x__
 const char *tup_arch = "s390x";
+#elif __hppa__
+const char *tup_arch = "hppa";
 #elif (__riscv || __riscv__) && __riscv_xlen == 64
 const char *tup_arch = "riscv64";
 #elif (__riscv || __riscv__) && __riscv_xlen == 32

Bug#1030552: systemsettings: Display Configuration disregards list of "Screen Priorities" at every login on KDE Plasma

[Jonas Arndt]

Package: systemsettings
Version: 4:5.26.90-1
Severity: important
Tags: upstream
X-Debbugs-Cc: jar...@duck.com

Dear Maintainer,

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

   * What led up to the situation?
 I have three screens. The left and the right are portrait oriented and the
middle one is
 landscape oriented and the default screen. After an apt upgrade the system
forgets
 that the middle screen is the default one. The list of screen priorities
is correct, but
 the system still decides to make my very left screen default (the one with
panels on)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I have to change the screen priorities list, save, change back, save.
   * What was the outcome of this action?
 Then the middle screen becomes the default again. However, if I log out
and back in again
 the problem reappears
   * What outcome did you expect instead?
 I expect that the system will look at the screen priorities and make the
screen with the
 highest priority the default screen

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


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

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

Versions of packages systemsettings depends on:
ii  kio 5.102.0-1
ii  kpackagetool5   5.102.0-1
ii  libc6   2.36-8
ii  libkf5activities5   5.102.0-1
ii  libkf5auth5 5.102.0-1
ii  libkf5authcore5 5.102.0-1
ii  libkf5completion5   5.102.0-1
ii  libkf5configcore5   5.102.0-1
ii  libkf5configgui55.102.0-1
ii  libkf5configwidgets55.102.0-1
ii  libkf5coreaddons5   5.102.0-1
ii  libkf5crash55.102.0-1
ii  libkf5dbusaddons5   5.102.0-1
ii  libkf5i18n5 5.102.0-1
ii  libkf5iconthemes5   5.102.0-1
ii  libkf5itemmodels5   5.102.0-1
ii  libkf5itemviews55.102.0-1
ii  libkf5kcmutils5 5.102.0-1
ii  libkf5kiocore5  5.102.0-1
ii  libkf5kiogui5   5.102.0-1
ii  libkf5kiowidgets5   5.102.0-1
ii  libkf5kirigami2-5   5.102.0-1
ii  libkf5notifications55.102.0-1
ii  libkf5package5  5.102.0-1
ii  libkf5runner5   5.102.0-1
ii  libkf5service-bin   5.102.0-1
ii  libkf5service5  5.102.0-1
ii  libkf5widgetsaddons55.102.0-1
ii  libkf5windowsystem5 5.102.0-1
ii  libkf5xmlgui5   5.102.0-1
ii  libkworkspace5-54:5.26.90-1
ii  libqt5core5a5.15.8+dfsg-2
ii  libqt5gui5  5.15.8+dfsg-2
ii  libqt5qml5  5.15.8+dfsg-2
ii  libqt5quick55.15.8+dfsg-2
ii  libqt5quickwidgets5 5.15.8+dfsg-2
ii  libqt5widgets5  5.15.8+dfsg-2
ii  libstdc++6  12.2.0-14
ii  qml-module-org-kde-kcm  5.102.0-1
ii  qml-module-org-kde-kcmutils 5.102.0-1
ii  qml-module-org-kde-kirigami25.102.0-1
ii  qml-module-org-kde-kitemmodels  5.102.0-1
ii  qml-module-org-kde-newstuff 5.102.0-1
ii  qml-module-qtquick-controls 5.15.8-2
ii  qml-module-qtquick-layouts  5.15.8+dfsg-2
ii  qml-module-qtquick-shapes   5.15.8+dfsg-2
ii  qml-module-qtquick2 5.15.8+dfsg-2

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#1029594: Fails to authenticate mit o365

[Chandler Sobel-Sorenson]

On Wed, 1 Feb 2023 19:50:15 -0300 Carsten Schoenert  
wrote:
> Am Wed, Feb 01, 2023 at 03:24:14PM + schrieb Nicola Chiapolini:
> > Control: severity -1 serious
> > Hi Carsten
> > I am increasing the severity again. This bit me today.
> > I rely on apt-listbugs to protect me from such problems and with the default settings 
"normal" is not sufficient to trigger listbugs.
> > Yesterday, #1030112 triggered listbugs, so today I was happy to see that 
the problem is fixed and upgraded. So I try to help others...
> > (Since the only reason I use Thunderbird in the first place is to access 
o365, this bug might even be considered grave ;-)
>
> I'm considering this issue is normaly just of severity important.

Frankly, I'm glad it was increased to serious because otherwise listbugs 
wouldn't have let me stop it, then I have to spend more time figuring out why I 
suddenly can't retrieve my e-mail and tracking down a solution, downgrading 
packages, etc.  There is only so much time in the day and so much coffee I can 
drink. ;-)  We use O365 at the University and I have enough issues maintaining 
our Linux systems there. ;-)  Last thing I need is problems with workstation to 
get in the way of my work.

> Quoting https://www.debian.org/Bugs/Developer.en.html
> important
> a bug which has a major effect on the usability of a package, without 
rendering it completely unusable to everyone
> And that's what this issue is about, most of the users can use
> Thunderbird without problems.

Do you have statistics for that?  What is "most"?

I'm pretty sure many Universities and other large organizations across the world are using Office 
however, if it's anything like our University, "most" of those users are using Windows 
version of Outlook or Outlook Online.  Still, I could not be sure what "most" Thunderbird 
users are using.

Further, the actual bug in mozilla is #1814536 (OAuth2 authentication | 
102.7.1. | Linux - fails) - still Open.  This is an even broader than just o365 
as Google uses OAuth2 as well, etc. That bug was reported here in Debian as 
grave under #1030112 but you closed it as a duplicate of this bug.  That was 
perhaps mistaken.

> serious
>     is a severe violation of Debian policy (roughly, it violates a "must" or 
"required" directive),
> or, in the package maintainer's or release manager's opinion, makes the 
package unsuitable for release.

I don't have the time to currently review the 609 instances of "must" or 
"required" in the policy, but I believe this makes the package unsuitable for release.

> grave
>     makes the package in question unusable or mostly so, or causes data loss,
> or introduces a security hole allowing access to the accounts of users who 
use the package.

I think #1030112 should be reopened and/or merged with this bug, with the title 
being updated to reflect broader issue with OAuth2. As the bug is much broader 
than is implied here, severity should be maintained at a minimum of serious.  
Since many these days are using Gmail as their only e-mail then could even be 
argued that thunderbird is now unusable or mostly so, therefore severity of 
grave is not out of the question either.

Best Regards,
Chandler

Bug#1030551: RM: gitit [mipsel] -- RoQA; no longer builds on mipsel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

gitit no longer builds on mipsel, see #1023021.

Bug#1030550: flashrom FTBFS on !amd64/i386

[Adrian Bunk]

Source: flashrom
Version: 1.3.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=flashrom=1.3.0-1

...
../meson.build:1:0: ERROR: Unknown options: "config_atahpt, config_atapromise, 
config_atavia, config_drkaiser, config_gfxnvidia, config_internal, 
config_it8212, config_nic3com, config_nicintel, config_nicintel_eeprom, 
config_nicintel_spi, config_nicnatsemi, config_nicrealtek, config_ogp_spi, 
config_rayer_spi, config_satamv, config_satasii"
...

Bug#1028493: geeqie: Does not print

[Bernhard Übelacker]

Am 04.02.23 um 16:26 schrieb Andreas Rönnquist:


Thanks - it does indeed sound reasonable to recommend on evince - If
you have evince installed, does printing work as you expect it then?

-- Andreas Rönnquist
gus...@debian.org



Sorry, I am not using geeqie regularly, I was just looking through some
reports and tested inside a non-persistent VM, and I did not test if a
print to the cups-pdf printer would have really worked.
Just have forwarded my findings.

Bug#1030549: filelight: Missing dependency on qml-module-org-kde-quickcharts and more

[Manuel Bilderbeek]

Package: filelight
Version: 4:22.12.1-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

I haven't used the program in a long while (and kept upgrading my testing 
system daily). Then I tried it today and I got a blank window with this on the 
terminal:
$ filelight
kf.kirigami: Failed to find a Kirigami platform plugin
QQmlComponent: Component is not ready
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/PageRow.qml:916: 
Error: Error while loading page: qrc:/ui/OverviewPage.qml:8 module 
"org.kde.quickcharts" is not installed

qrc:/ui/main.qml:171:5: QML Connections: Implicitly defined onFoo properties in 
Connections are deprecated. Use this syntax instead: function 
onFoo() { ... }

And indeed, I do not have qml-module-org-kde-quickcharts installed, because it 
doesn't seem to be listed in the dependency list:
$ aptitude show filelight
Package: filelight   
Version: 4:22.12.1-1
State: installed
Automatically installed: no
Priority: optional
Section: kde
Maintainer: Debian Qt/KDE Maintainers 
Architecture: amd64
Uncompressed Size: 1.840 k
Depends: kio, libc6 (>= 2.35), libkf5configcore5 (>= 5.69.0),
 libkf5configwidgets5 (>= 4.96.0), libkf5coreaddons5 (>= 5.91.0~),
 libkf5i18n5 (>= 5.98.0~), libkf5jobwidgets5 (>= 5.70.0), libkf5kiocore5
 (>= 5.100.0), libkf5kiogui5 (>= 5.98.0~), libkf5kiowidgets5 (>=
 5.98.0~), libkf5widgetsaddons5 (>= 4.96.0), libkf5xmlgui5 (>= 5.98.0~),
 libqt5core5a (>= 5.15.2~), libqt5gui5 (>= 5.15.2~) | libqt5gui5-gles
 (>= 5.15.2~), libqt5qml5 (>= 5.15.2~), libqt5quick5 (>= 5.15.2~) |
 libqt5quick5-gles (>= 5.15.2~), libqt5quickcontrols2-5 (>= 5.15.2~),
 libqt5svg5 (>= 5.15.2~), libqt5widgets5 (>= 5.15.2~), libstdc++6 (>= 5)

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

I installed qml-module-org-kde-quickcharts manually. That made it start-up.

But when I then tried to scan a folder... another error:
QQmlComponent: Component is not ready
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/PageRow.qml:916: 
Error: Error while loading page: qrc:/ui/MapPage.qml:8 module 
"org.kde.kcoreaddons" is not installed

So, I installed qml-module-org-kde-kcoreaddons manually.

Then the program worked as expected.

So, please add these 2 missing dependencies. Thanks!

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

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

Versions of packages filelight depends on:
ii  kio 5.102.0-1
ii  libc6   2.36-8
ii  libkf5configcore5   5.102.0-1
ii  libkf5configwidgets55.102.0-1
ii  libkf5coreaddons5   5.102.0-1
ii  libkf5i18n5 5.102.0-1
ii  libkf5jobwidgets5   5.102.0-1
ii  libkf5kiocore5  5.102.0-1
ii  libkf5kiogui5   5.102.0-1
ii  libkf5kiowidgets5   5.102.0-1
ii  libkf5widgetsaddons55.102.0-1
ii  libkf5xmlgui5   5.102.0-1
ii  libqt5core5a5.15.8+dfsg-2
ii  libqt5gui5  5.15.8+dfsg-2
ii  libqt5qml5  5.15.8+dfsg-2
ii  libqt5quick55.15.8+dfsg-2
ii  libqt5quickcontrols2-5  5.15.8+dfsg-2
ii  libqt5svg5  5.15.8-2
ii  libqt5widgets5  5.15.8+dfsg-2
ii  libstdc++6  12.2.0-14

filelight recommends no packages.

filelight suggests no packages.

-- no debconf information

Bug#1029994: bullseye-pu: package phyx/1.01+ds-2+b1

[Olek Wojnar]

Hi Adam,

On 2/4/23 13:11, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Sun, 2023-01-29 at 20:28 -0500, Olek Wojnar wrote:

The phyx package incorrectly declares a Build Dependency on the
libatlas-cpp-0.6-dev package. The src:atlas-cpp package is obsolete
since the
only packages that actually depended on it (ember and cyphesis) were
not in
bullseye and have subsequently been removed even from unstable since
the
code base is too unstable for inclusion in Debian [1]. The incorrect
BD of
phyx on atlas-cpp is the only thing stopping atlas-cpp from also
being removed
from bullseye.



dak disagrees with the latter statement:

Checking reverse dependencies...
# Broken Depends:
eris: liberis-1.3-21
   liberis-1.3-dev

# Broken Build-Depends:
eris: libatlas-cpp-0.6-dev (0.6.3 >=)
phyx: libatlas-cpp-0.6-dev


Sorry about that, I wasn't being quite detailed enough in my statement. 
What I *meant* to say was that phyx was the only thing preventing the 
*WorldForge libraries* from being removed from bullseye. Those libraries 
are:

atlas-cpp
eris
libwfut
mercator
skstream
varconf
wfmath

Once phyx builds correctly I will submit bugs for those removals.


In any case, please go ahead.


Thank you!

-Olek


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Diederik de Haas]

On Saturday, 4 February 2023 22:12:24 CET Salvatore Bonaccorso wrote:
> > Right, I agree this should be a package of its own. I didn't know
> > raspi-nonfree came from a "coherent" set of firmware sources provided
> > by a single upstream. It is a distorsion that peopleinterested in
> > brcmfmac firmware have to install raspi-firmware if they have
> > different hardware.
> 
> So I guess we can close this bug here, and the files can be shipped
> with a new dedicated source package containing the firmware files,
> since the last option of having them merged upstream in
> linux-firmware.git seems unrealistic for now?

We could do that, but wouldn't it make more sense to reassign it to wnpp (?) 
and turn it into a RFP type bug?

That way we would preserve the history (and thus useful info) of this issue.

My 0.02

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

Bug#1030548: RM: xorg-gtest -- ROM; RC buggy, no consumers anymore

[Mike Gabriel]

Package: ftp.debian.org
Severity: normal

Please remove xorg-gtest from Debian testing/unstable. It does not seem
to have any consumers anymore in Debian, it is badly maintained upstream
(if at all) and it currently is RC buggy.

Bye bye xorg-gtest.

Thanks,
Mike

Bug#1030506: backintime-common: Version string ("1.3.3-dev") reported by backintime does not reflect the release

[Jonathan Wiltshire]

Control: severity 1030506 minor

Policy 3.2 does not apply to this.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 SaaS == Saunas as a Service
 broonie, more like Sauna as additional Storage

Bug#1030096: #1030096 dask.distributed autopkgtest fail

[Andreas Tille]

Am Sat, Feb 04, 2023 at 06:20:32PM + schrieb Rebecca N. Palmer:
> I have an attempt to fix this in Salsa now (in my fork), but it hasn't had
> time to run the tests yet, so I don't know whether it works.

Any reason to not push to master directly?
 
> Note the above mention that if we lose dask.distributed then we lose Spyder,
> which makes this a bigger issue than I initially thought.

We should definitely keep dask.distributed.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#981496: svtools: ship with bullseye?

[Joost van Baal-Ilić]

Priority 981496 normal
Thanks

Hi Adrian,

Thanks for this notification, and sorry for not responding ealier.  Chris filed
the original bug, but didn't indicate any actual breakage of the package.  Age
alone would, afaik, not be a reason to stop shipping a package; nor would lack
of a formal maintainer be.  These indeed _could_ indicate trouble with the
package (so thanks Chris for creating awareness), but are not sufficient for
blocking it from entering testing.  No record of actual breakage is filed
upstream.  Therefore I feel the priority of this bug should get lowered, and
svtools should get shipped with bullseye as-is.

Adjusting; and hoping I'm not too late here.

Bye,

Joost

On Sat, Feb 04, 2023 at 10:36:12PM +0200, Adrian Bunk wrote:
> Hi Joost,
> 
> if you as maintainer of daemontools think this package would be useful 
> in bookworm, please close the bug (and consider adopting the package).
> 
> Thanks
> Adrian
> 
> 
> On Wed, Sep 08, 2021 at 02:25:01PM +0300, Adrian Bunk wrote:
> > On Sun, Jan 31, 2021 at 10:35:45PM +0100, Chris Hofstaedtler wrote:
> > > Package: svtools
> > > Version: 0.6-4
> > > Severity: important
> > > 
> > > Hi,
> > > 
> > > the package "svtools" has been orphaned by its original maintainer
> > > over 7 years ago. The Debian maintainer was also the upstream
> > > maintainer. Upstream has archived the project, and the last change
> > > was over 9 years ago.
> > > 
> > > Is this still useful software? Should we continue to ship it?
> > > 
> > > If you are interested, please speak up now.
> > >...
> > 
> > Jan, you intend to addopt daemontools.
> > 
> > Can you check whether svtools is still useful for Debian
> > (and if yes, ideally also adopt it)?

Bug#1026259: SW RAID to JFS intermittent boot fail with NULL pointer dereference

[Salvatore Bonaccorso]

Hi,

On Fri, Feb 03, 2023 at 09:31:01AM +, RattusRattus wrote:
> Dear team,
> 
> - Did I submit to the correct location?
> - Is there anything additional information that you require?

It is okay, but even better if the issue can be brough upstream. But
that said, I would not expect really any progress, in fact upstream it
is discussed if it might be removed in future, cf.
https://lwn.net/Articles/920259/ .

It seems to be a hard to tackle problem if it's not really
reproducible and machine dependent. But if reproduces for you quite
consistently, a bisect between the last known working version and
kernel in recent bullseye point release which started failing might
pin point us to the relevant change causing this.

Dave, adding you to CC, this is about report
https://bugs.debian.org/1026259 in Debian. This was noted with at
least 5.10.158 based stable kernel in Debian. My understanding is that
at least 5.10.127 was still fine.

Regards,
Salvatore

Bug#1030547: RFS: ghostscript/9.53.3~dfsg-7+deb11u3 [NMU] -- interpreter for the PostScript language and for PDF

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ghostscript":

 * Package name : ghostscript
   Version  : 9.53.3~dfsg-7+deb11u3
   Upstream contact : Ghostscript development and discussion 

 * URL  : https://www.ghostscript.com/
 * License  : GPL-2+, public-domain, BSD-3-Clause, NTP~Open, GPL-3+ 
with Autoconf exception, Apache-2.0, none, LGPL-2.1, ZLIB, NTP~WSU, 
BSD-3-Clause~Adobe, AGPL-3+ and custom, AGPL-3+ with font exception, 
GAP~configure, ISC, NTP~Lucent, AGPL-3+, Adobe-2006, GPL, Expat~Ghostgum, 
Expat, AGPL-3+ and FTL, Expat~SunSoft with SunSoft exception
 * Vcs  : https://salsa.debian.org/printing-team/ghostscript
   Section  : text

The source builds the following binary packages:

  ghostscript - interpreter for the PostScript language and for PDF
  ghostscript-x - interpreter for the PostScript language and for PDF - X11 
support
  ghostscript-doc - interpreter for the PostScript language and for PDF - 
Documentation
  libgs9 - interpreter for the PostScript language and for PDF - Library
  libgs9-common - interpreter for the PostScript language and for PDF - common 
files
  libgs-dev - interpreter for the PostScript language and for PDF - Development 
Files

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/ghostscript/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/ghostscript/ghostscript_9.53.3~dfsg-7+deb11u3.dsc

Changes since the last upload:

 ghostscript (9.53.3~dfsg-7+deb11u3) bullseye; urgency=medium
 .
   * Non-maintainer upload.
   * Cherry-pick upstream patch to fix path for PostScript helper file in
 ps2epsi. Closes: #1003926, #1029541


Upload is confirmed for stable [1].

Regards,
Håvard


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029619

Bug#1030546: qt6-base FTBFS on hppa

[Helge Deller]

Package: qt6-base
Tags: patch, ftbfs, hppa
Version: 6.4.2+dfsg

The attached patch fixes this qt6-base "build-from-source" (FTBFS) failure on 
hppa:
/usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o): relocation 
R_PARISC_DPREL21L can not be used when making a shared object; recompile with 
-fPIC

The problem is, that qt6-base suddenly tries to link against the static
library of libzstd.a, while in the past it did linked against the shared 
library:

In current failing build (6.4.2+dfsg-1):
-- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required is 
"1.3")
Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.2%2Bdfsg-1=1675198832=0

while it worked in the past for qt6-base 6.4.2+dfsg~rc1-1
-- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable version "1.5.2", 
minimum required is "1.3")
Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.2%2Bdfsg%7Erc1-1=1672201686=0

The attached patch changes  WrapZSTD to prefer the dynamic library.

Thanks,
Helge[PATCH] FindWrapZSTD: Prefer libzstd shared library over static library

On some architectures a static library can not be linked into shared library
because shared libraries may need specific symbol relocations.
This fixes the build on hppa architecture which gives those errors: 
/usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(zstd_v05.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(zstd_v06.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(zstd_v07.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(huf_decompress.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC

Signed-off-by: Helge Deller 

---
diff -up ./cmake/FindWrapZSTD.cmake.org ./cmake/FindWrapZSTD.cmake
--- ./cmake/FindWrapZSTD.cmake.org	2023-02-04 17:50:29.119361823 +
+++ ./cmake/FindWrapZSTD.cmake	2023-02-04 17:51:51.876153609 +
@@ -25,10 +25,10 @@ include(FindPackageHandleStandardArgs)
 if(TARGET zstd::libzstd_static OR TARGET zstd::libzstd_shared)
 find_package_handle_standard_args(WrapZSTD
   REQUIRED_VARS zstd_VERSION VERSION_VAR zstd_VERSION)
-if(TARGET zstd::libzstd_static)
-set(zstdtargetsuffix "_static")
-else()
+if(TARGET zstd::libzstd_shared)
 set(zstdtargetsuffix "_shared")
+else()
+set(zstdtargetsuffix "_static")
 endif()
 if(NOT TARGET WrapZSTD::WrapZSTD)
 add_library(WrapZSTD::WrapZSTD INTERFACE IMPORTED)

Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x

[Hilko Bengen]

* Michael Tokarev:

> 04.02.2023 23:19, Hilko Bengen wrote:
>> Package: src:qemu
>> Version: 1:7.2+dfsg-2
> ..
>>  qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 
>> 512
>> would hang in what appears a tight loop (100% CPU).
>
> Does 7.2+dfsg-1 work?
>
> I don't have s390x environment so have no way to deal with this one.

No, it doesn't. On the porterbox (zelenka.debian.org) I was only able to
install 1:7.2+dfsg-1+b1 without rebuilding.

The last non-failing build before[1] also used 1:7.2+dfsg-1+b1, though.
This made me think that the hang might be related to a shared library
that had been updated since.

Breaking into the running process tells us that it hangs within ppoll
and continuing "heals" the situation as before:
,
| (bookworm_s390x-dchroot)bengen@zelenka:~$ gdb -p 2497762 
| GNU gdb (Debian 12.1-4+b1) 12.1
| Copyright (C) 2022 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later 
| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
| Type "show copying" and "show warranty" for details.
| This GDB was configured as "s390x-linux-gnu".
| Type "show configuration" for configuration details.
| For bug reporting instructions, please see:
| .
| Find the GDB manual and other documentation resources online at:
| .
| 
| For help, type "help".
| Type "apropos word" to search for commands related to "word".
| Attaching to process 2497762
| [New LWP 2497763]
| [Thread debugging using libthread_db enabled]
| Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
| 0x03ff988081ee in ppoll () from /lib/s390x-linux-gnu/libc.so.6
| (gdb) bt
| #0  0x03ff988081ee in ppoll () from /lib/s390x-linux-gnu/libc.so.6
| #1  0x02aa27deb648 in ?? ()
| #2  0x02aa27deac92 in aio_poll ()
| #3  0x02aa27cffccc in bdrv_create ()
| #4  0x02aa27d0a9e6 in bdrv_img_create ()
| #5  0x02aa27cea004 in _start ()
| (gdb) c
| Continuing.
| [New Thread 0x3ff977fd8c0 (LWP 2497916)]
| [Thread 0x3ff980ff8c0 (LWP 2497763) exited]
| [Thread 0x3ff9936bb80 (LWP 2497762) exited]
| [Thread 0x3ff977fd8c0 (LWP 2497916) exited]
| [New process 2497762]
| [Inferior 1 (process 2497762) exited normally]
`

Looks like the only candidatee may be libc which was at 2.36-7 for the
last working build and got upgraded to 2.36-8 before things started to
go wrong.

Cheers,
-Hilko

[1] https://buildd.debian.org/status/logs.php?pkg=libguestfs=s390x

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Salvatore Bonaccorso]

Hi,

On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote:
> Hi!
> 
> Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > > Would they fit into a separate source package not associated with
> > > raspi-config?
> > 
> > I do strongly think they do not belong in the raspi-firmware package for 
> > the 
> > reason I retitled this bug and retitled my response Subject. Another reason 
> > is 
> > that the raspi-firmware package makes (several) assumptions, namely that 
> > they 
> > are only used/usable on RPi devices and have a /boot/firmware directory 
> > (where 
> > a FAT partition is mounted, although that part is not checked for).
> > I have previously expressed my concerns/doubts about that, but that's 
> > outside 
> > the scope of this bug.
> > It also looks 'weird' to install the raspi-firmware package while you only 
> > care 
> > about the wifi firmware and not care about RPi's at all.
> 
> Right, I agree this should be a package of its own. I didn't know
> raspi-nonfree came from a "coherent" set of firmware sources provided
> by a single upstream. It is a distorsion that peopleinterested in
> brcmfmac firmware have to install raspi-firmware if they have
> different hardware.

So I guess we can close this bug here, and the files can be shipped
with a new dedicated source package containing the firmware files,
since the last option of having them merged upstream in
linux-firmware.git seems unrealistic for now?

Regards,
Salvatore

p.s.: sorry misstyped initially the origin source package, was obviously
  not meaning raspi-config, so raspi-firmware.

Bug#1029594: New TB 1:102.7.1-1 from Mozilla

[Pete Elliott]

Hello,

I'm ignorant as to how packages get updated. It appears that there is a 
newer version of TB 1:102.7.1-1 available from Mozilla than the one 
offered via the Debian package management system. Will this update at 
some point?


(It does seem odd that Mozilla's fix of the Oauth didn't generate a new 
version number as opposed to fixing a previously broken version.)


Thanks,

--
~ Pete

Bug#991450: ubertooth: diff for NMU version 2018.12.R1-5.1

[Adrian Bunk]

Control: tags 991450 + patch
Control: tags 991450 + pending

Dear maintainer,

I've prepared an NMU for ubertooth (versioned as 2018.12.R1-5.1) and 
uploaded it to DELAYED/1. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru ubertooth-2018.12.R1/debian/changelog ubertooth-2018.12.R1/debian/changelog
--- ubertooth-2018.12.R1/debian/changelog	2020-10-13 11:30:08.0 +0300
+++ ubertooth-2018.12.R1/debian/changelog	2023-02-04 22:43:30.0 +0200
@@ -1,3 +1,10 @@
+ubertooth (2018.12.R1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for FTBFS with gcc >= 10. (Closes: #991450)
+
+ -- Adrian Bunk   Sat, 04 Feb 2023 22:43:30 +0200
+
 ubertooth (2018.12.R1-5) unstable; urgency=medium
 
   * Fix build with GCC-10 by removing unused extra definition of variable
diff -Nru ubertooth-2018.12.R1/debian/patches/0001-firmware-fix-update-for-newer-gcc-versions.patch ubertooth-2018.12.R1/debian/patches/0001-firmware-fix-update-for-newer-gcc-versions.patch
--- ubertooth-2018.12.R1/debian/patches/0001-firmware-fix-update-for-newer-gcc-versions.patch	1970-01-01 02:00:00.0 +0200
+++ ubertooth-2018.12.R1/debian/patches/0001-firmware-fix-update-for-newer-gcc-versions.patch	2023-02-04 22:42:54.0 +0200
@@ -0,0 +1,264 @@
+From 66b8ddea875dffbd3ef8d1a106a45d5763606e92 Mon Sep 17 00:00:00 2001
+From: mar-kub 
+Date: Thu, 25 Mar 2021 00:33:37 +0100
+Subject: firmware fix: update for newer gcc versions
+
+---
+ firmware/bluetooth_rxtx/bluetooth.c|  6 ++
+ firmware/bluetooth_rxtx/bluetooth.h| 10 +-
+ firmware/bluetooth_rxtx/cc2400_rangetest.c |  2 ++
+ firmware/bluetooth_rxtx/cc2400_rangetest.h |  2 +-
+ firmware/bluetooth_rxtx/ubertooth_clock.c  | 13 +
+ firmware/bluetooth_rxtx/ubertooth_clock.h  | 16 
+ firmware/bluetooth_rxtx/ubertooth_cs.c |  5 +
+ firmware/bluetooth_rxtx/ubertooth_cs.h |  8 
+ firmware/bluetooth_rxtx/ubertooth_dma.c| 14 ++
+ firmware/bluetooth_rxtx/ubertooth_dma.h| 12 ++--
+ firmware/bluetooth_rxtx/ubertooth_rssi.c   |  4 
+ firmware/bluetooth_rxtx/ubertooth_rssi.h   |  6 +++---
+ 12 files changed, 71 insertions(+), 27 deletions(-)
+
+diff --git a/firmware/bluetooth_rxtx/bluetooth.c b/firmware/bluetooth_rxtx/bluetooth.c
+index 4a10bc7..accb98b 100644
+--- a/firmware/bluetooth_rxtx/bluetooth.c
 b/firmware/bluetooth_rxtx/bluetooth.c
+@@ -21,6 +21,12 @@
+ 
+ #include "bluetooth.h"
+ 
++bdaddr target;
++u64 syncword;
++u8 afh_enabled;
++u8 afh_map[10];
++u8 used_channels;
++
+ /* these values for hop() can be precalculated (at leastin part) */
+ u8 a1, b, c1, e;
+ u16 d1;
+diff --git a/firmware/bluetooth_rxtx/bluetooth.h b/firmware/bluetooth_rxtx/bluetooth.h
+index 4f4c2ca..c31 100644
+--- a/firmware/bluetooth_rxtx/bluetooth.h
 b/firmware/bluetooth_rxtx/bluetooth.h
+@@ -27,11 +27,11 @@
+ 
+ #define MAX_SYNCWORD_ERRS 5
+ 
+-bdaddr target;
+-u64 syncword;
+-u8 afh_enabled;
+-u8 afh_map[10];
+-u8 used_channels;
++extern bdaddr target;
++extern u64 syncword;
++extern u8 afh_enabled;
++extern u8 afh_map[10];
++extern u8 used_channels;
+ 
+ /* Barker distance/correct gains us very little when sniffing a known AC
+ static const u8 ao_barker_distance[] = {
+diff --git a/firmware/bluetooth_rxtx/cc2400_rangetest.c b/firmware/bluetooth_rxtx/cc2400_rangetest.c
+index 28534f8..30a36cb 100644
+--- a/firmware/bluetooth_rxtx/cc2400_rangetest.c
 b/firmware/bluetooth_rxtx/cc2400_rangetest.c
+@@ -46,6 +46,8 @@
+  *   crc: 2 bytes
+  */
+ 
++rangetest_result rr;
++
+ void cc2400_rangetest(volatile u16 *chan_ptr)
+ {
+ #ifdef TX_ENABLE
+diff --git a/firmware/bluetooth_rxtx/cc2400_rangetest.h b/firmware/bluetooth_rxtx/cc2400_rangetest.h
+index 70f9d35..a306f84 100644
+--- a/firmware/bluetooth_rxtx/cc2400_rangetest.h
 b/firmware/bluetooth_rxtx/cc2400_rangetest.h
+@@ -24,7 +24,7 @@
+ 
+ #include "ubertooth.h"
+ 
+-rangetest_result rr;
++extern rangetest_result rr;
+ 
+ void cc2400_rangetest(volatile u16 *chan_ptr);
+ 
+diff --git a/firmware/bluetooth_rxtx/ubertooth_clock.c b/firmware/bluetooth_rxtx/ubertooth_clock.c
+index e7b0c01..ed96775 100644
+--- a/firmware/bluetooth_rxtx/ubertooth_clock.c
 b/firmware/bluetooth_rxtx/ubertooth_clock.c
+@@ -22,6 +22,19 @@
+ #include "ubertooth_clock.h"
+ #include "ubertooth.h"
+ 
++volatile uint32_t clkn;
++volatile uint32_t last_hop;
++
++volatile uint32_t clkn_offset;
++volatile uint16_t clk100ns_offset;
++
++// linear clock drift
++volatile int16_t clk_drift_ppm;
++volatile uint16_t clk_drift_correction;
++
++volatile uint32_t clkn_last_drift_fix;
++volatile uint32_t clkn_next_drift_fix;
++
+ void clkn_stop()
+ {
+ 	/* stop and reset the timer to zero */
+diff --git a/firmware/bluetooth_rxtx/ubertooth_clock.h b/firmware/bluetooth_rxtx/ubertooth_clock.h
+index 833899b..7674b11 100644
+--- a/firmware/bluetooth_rxtx/ubertooth_clock.h
 b/firmware/bluetooth_rxtx/ubertooth_clock.h
+@@ 

Bug#695188: 2017 patch review

[Brian Thompson]

Does anyone have time to review the patch that was submitted back in 2017?

2017 patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=695188;filename=0001-Fix-695188-intelligent-add-of-Bug-XX.patch;msg=60

-- 
Brian Thompson 


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

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

[Adrian Bunk]

On Sat, Dec 24, 2022 at 09:13:35AM +, Tobias Hansen wrote:
>...
> Upstream has a (maybe unrelated?) problem with higher setuptools versions 
> described here:
> https://trac.sagemath.org/ticket/34442
> 
> Unfortunately I don't have much time to work on this. If someone can come up 
> with a patch, that would be highly appreciated.

The setuptools issue might have been fixed by #1025216.

I tried to reproduce this, but ran into several unrelated issues.

Patches I applied locally on top of what is already in git:
https://github.com/sagemath/sage/commit/de38bac21e276c6dba95b8b33f7457a0ac56bdeb
https://github.com/sagemath/sagetrac-mirror/commit/6f3b4556db746e6354d55d42eba5925be19a6cad

/usr/include/giac/plot.h needs a "typedef unsigned char uchar;" somewhere.

build/cythonized/sage/rings/polynomial/multi_polynomial_libsingular.cpp:36042:120:
 error: ‘pTakeOutComp1’ was not declared in this scope; did you mean 
‘pTakeOutComp’?

> Best wishes,
> 
> Tobias

cu
Adrian

Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x

[Michael Tokarev]

04.02.2023 23:19, Hilko Bengen wrote:

Package: src:qemu
Version: 1:7.2+dfsg-2

..

 qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512

would hang in what appears a tight loop (100% CPU).


Does 7.2+dfsg-1 work?

I don't have s390x environment so have no way to deal with this one.

Thanks,

/mjt

Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x

[Hilko Bengen]

Package: src:qemu
Version: 1:7.2+dfsg-2
Severity: grave
X-Debbugs-Cc: none, Hilko Bengen 

Dear Maintainer,

While investigating recent s390x build failures of libguestfs, I noticed
that variants of 

qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512

would hang in what appears a tight loop (100% CPU).

Calling strace on those hanging processes or sending them TSTP and CONT
signals causes them to continue.

Later in the build process, libguestfs-test-tool runs qemu-system-s390x
a few times. Those processes also hang and they can also be "cured" by
sending them TSTP and CONT signals.

Cheers,
-Hilko

Bug#1030544: rust-document-features: autopkgtest failure

[Adrian Bunk]

Source: rust-document-features
Version: 0.2.7-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-document-features/30989599/log.gz

...
error: The feature `default` must be enabled to ensure forward compatibility 
with future version of this crate
   --> lib.rs:153:1
|
153 | / compile_error!(
154 | | "The feature `default` must be enabled to ensure \
155 | | forward compatibility with future version of this crate"
156 | | );
| |_^

error: could not compile `document-features` due to previous error

Caused by:
  process didn't exit successfully: `CARGO=/usr/bin/cargo 
CARGO_CRATE_NAME=document_features 
CARGO_MANIFEST_DIR=/usr/share/cargo/registry/document-features-0.2.7 
CARGO_PKG_AUTHORS='Slint Developers ' 
CARGO_PKG_DESCRIPTION='Extract documentation for the feature flags from 
comments in Cargo.toml' CARGO_PKG_HOMEPAGE='https://slint-ui.com' 
CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=document-features 
CARGO_PKG_REPOSITORY='https://github.com/slint-ui/document-features' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.2.7 CARGO_PKG_VERSION_MAJOR=0 
CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=7 CARGO_PKG_VERSION_PRE='' 
CARGO_PRIMARY_PACKAGE=1 
LD_LIBRARY_PATH='/tmp/tmp.9SugApoBQC/target/debug/deps:/usr/lib' rustc 
--crate-name document_features --edition=2018 lib.rs --error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type 
proc-macro --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no -C 
debuginfo=2 -C metadata=9050631d527b1f34 -C extra-filename=-9050631d527b1f34 
--out-dir /tmp/tmp.9SugApoBQC/target/debug/deps -C 
incremental=/tmp/tmp.9SugApoBQC/target/debug/incremental -L 
dependency=/tmp/tmp.9SugApoBQC/target/debug/deps --extern 
litrs=/tmp/tmp.9SugApoBQC/target/debug/deps/liblitrs-a03c4a135dff2839.rlib 
--extern proc_macro` (exit status: 1)
warning: build failed, waiting for other jobs to finish...
error: could not compile `document-features` due to previous error

Caused by:
  process didn't exit successfully: `CARGO=/usr/bin/cargo 
CARGO_CRATE_NAME=document_features 
CARGO_MANIFEST_DIR=/usr/share/cargo/registry/document-features-0.2.7 
CARGO_PKG_AUTHORS='Slint Developers ' 
CARGO_PKG_DESCRIPTION='Extract documentation for the feature flags from 
comments in Cargo.toml' CARGO_PKG_HOMEPAGE='https://slint-ui.com' 
CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=document-features 
CARGO_PKG_REPOSITORY='https://github.com/slint-ui/document-features' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.2.7 CARGO_PKG_VERSION_MAJOR=0 
CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=7 CARGO_PKG_VERSION_PRE='' 
CARGO_PRIMARY_PACKAGE=1 
LD_LIBRARY_PATH='/tmp/tmp.9SugApoBQC/target/debug/deps:/usr/lib' rustc 
--crate-name document_features --edition=2018 lib.rs --error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link 
-C prefer-dynamic -C embed-bitcode=no -C debuginfo=2 --test -C 
metadata=6b6f5d3fcfc82b5d -C extra-filename=-6b6f5d3fcfc82b5d --out-dir 
/tmp/tmp.9SugApoBQC/target/debug/deps -C 
incremental=/tmp/tmp.9SugApoBQC/target/debug/incremental -L 
dependency=/tmp/tmp.9SugApoBQC/target/debug/deps --extern 
litrs=/tmp/tmp.9SugApoBQC/target/debug/deps/liblitrs-a03c4a135dff2839.rlib 
--extern proc_macro` (exit status: 1)
autopkgtest [09:14:57]: test librust-document-features-dev:: 
---]
autopkgtest [09:14:58]: test librust-document-features-dev::  - - - - - - - - - 
- results - - - - - - - - - -
librust-document-features-dev: FAIL non-zero exit status 101
autopkgtest [09:14:58]:  summary
rust-document-features:@ PASS
librust-document-features-dev:default PASS
librust-document-features-dev:self-test FAIL non-zero exit status 101
librust-document-features-dev: FAIL non-zero exit status 101

Bug#1030543: rust-dockerfile: autopkgtest failure

[Adrian Bunk]

Source: rust-dockerfile
Version: 0.2.1-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-dockerfile/30979620/log.gz

...
autopkgtest [03:52:12]: test rust-dockerfile:@: 
/usr/share/cargo/bin/cargo-auto-test dockerfile 0.2.1 --all-targets 
--all-features
autopkgtest [03:52:12]: test rust-dockerfile:@: [---
debian cargo wrapper: options, profiles, parallel: ['parallel=64'] [] ['-j64']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: linking /usr/share/cargo/registry/* into 
/tmp/tmp.CZI90S5IlT/registry/
debian cargo wrapper: options, profiles, parallel: ['parallel=64'] [] ['-j64']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j64', 
'--target', 'x86_64-unknown-linux-gnu', '--all-targets', '--all-features'],) {}
   Compiling dockerfile v0.2.1 (/usr/share/cargo/registry/dockerfile-0.2.1)
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=dockerfile 
CARGO_MANIFEST_DIR=/usr/share/cargo/registry/dockerfile-0.2.1 
CARGO_PKG_AUTHORS='Anthony Dodd ' 
CARGO_PKG_DESCRIPTION='A Rust library for dynamically generating Dockerfiles.' 
CARGO_PKG_HOMEPAGE='https://github.com/thedodd/dockerfile' 
CARGO_PKG_LICENSE=Apache-2.0 CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=dockerfile 
CARGO_PKG_REPOSITORY='https://github.com/thedodd/dockerfile' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.2.1 CARGO_PKG_VERSION_MAJOR=0 
CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' 
CARGO_PRIMARY_PACKAGE=1 
LD_LIBRARY_PATH='/tmp/tmp.CZI90S5IlT/target/debug/deps:/usr/lib' rustc 
--crate-name dockerfile --edition=2018 src/lib.rs --error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link 
-C embed-bitcode=no -C debuginfo=2 --test --cfg 'feature="docinclude"' -C 
metadata=3260d957e4ef2b10 -C extra-filename=-3260d957e4ef2b10 --out-dir 
/tmp/tmp.CZI90S5IlT/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -C 
incremental=/tmp/tmp.CZI90S5IlT/target/x86_64-unknown-linux-gnu/debug/incremental
 -L dependency=/tmp/tmp.CZI90S5IlT/target/x86_64-unknown-linux-gnu/debug/deps 
-L dependency=/tmp/tmp.CZI90S5IlT/target/debug/deps -C debuginfo=2 --cap-lints 
warn -C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro 
--remap-path-prefix 
/usr/share/cargo/registry/dockerfile-0.2.1=/usr/share/cargo/registry/dockerfile-0.2.1
 --remap-path-prefix /tmp/tmp.CZI90S5IlT/registry=/usr/share/cargo/registry`
error[E0557]: feature has been removed
 --> src/lib.rs:1:43
  |
1 | #![cfg_attr(feature="docinclude", feature(external_doc))]
  |    feature has been 
removed
  |
  = note: use #[doc = include_str!("filename")] instead, which handles macro 
invocations

warning: unknown `doc` attribute `include`
 --> src/lib.rs:2:39
  |
2 | #![cfg_attr(feature="docinclude", doc(include="../README.md"))]
  |   ^^- help: use 
`doc = include_str!` instead: `#![doc = include_str!("../README.md")]`
  |
  = note: `#[warn(invalid_doc_attributes)]` on by default
  = warning: this was previously accepted by the compiler but is being phased 
out; it will become a hard error in a future release!
  = note: for more information, see issue #82730 


For more information about this error, try `rustc --explain E0557`.
warning: `dockerfile` (lib test) generated 1 warning
error: could not compile `dockerfile` due to previous error; 1 warning emitted

Caused by:
  process didn't exit successfully: `CARGO=/usr/bin/cargo 
CARGO_CRATE_NAME=dockerfile 
CARGO_MANIFEST_DIR=/usr/share/cargo/registry/dockerfile-0.2.1 
CARGO_PKG_AUTHORS='Anthony Dodd ' 
CARGO_PKG_DESCRIPTION='A Rust library for dynamically generating Dockerfiles.' 
CARGO_PKG_HOMEPAGE='https://github.com/thedodd/dockerfile' 
CARGO_PKG_LICENSE=Apache-2.0 CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=dockerfile 
CARGO_PKG_REPOSITORY='https://github.com/thedodd/dockerfile' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.2.1 CARGO_PKG_VERSION_MAJOR=0 
CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' 
CARGO_PRIMARY_PACKAGE=1 
LD_LIBRARY_PATH='/tmp/tmp.CZI90S5IlT/target/debug/deps:/usr/lib' rustc 
--crate-name dockerfile --edition=2018 src/lib.rs --error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link 
-C embed-bitcode=no -C debuginfo=2 --test --cfg 'feature="docinclude"' -C 
metadata=3260d957e4ef2b10 -C extra-filename=-3260d957e4ef2b10 --out-dir 
/tmp/tmp.CZI90S5IlT/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -C 
incremental=/tmp/tmp.CZI90S5IlT/target/x86_64-unknown-linux-gnu/debug/incremental
 -L 

Bug#1029651: bullseye-pu: package libxpm/1:3.5.12-1.1~deb11u1

[Salvatore Bonaccorso]

Hi Adam,

On Sat, Feb 04, 2023 at 06:28:28PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2023-01-25 at 21:32 +0100, Salvatore Bonaccorso wrote:
> > I would like to propose to update libxpm in bullseye as well fixing
> > some no-dsa tagged CVEs by simply rebuilding the package which got
> > uploaded to unstable (without other changes apart addressing issues):
> > 
> > +libxpm (1:3.5.12-1.1~deb11u1) bullseye; urgency=medium
> > +
> > +  * Non-maintainer upload.
> > +  * Rebuild for bullseye
> > +
> > + -- Salvatore Bonaccorso   Wed, 25 Jan 2023
> > 21:19:41 +0100
> > +
> > +libxpm (1:3.5.12-1.1) unstable; urgency=medium
> > +
> > +  * Non-maintainer upload.
> > +  * Fix CVE-2022-46285: Infinite loop on unclosed comments
> > +  * Fix CVE-2022-44617: Runaway loop with width of 0 and enormous
> > height
> > +  * configure: add --disable-open-zfile instead of requiring
> > -DNO_ZPIPE
> > +  * Fix CVE-2022-4883: compression commands depend on  $PATH
> > +  * Prevent a double free in the error code path
> > +  * Use gzip -d instead of gunzip
> > +  * debian/rules: configure: Set explicitly runtime paths for
> > {,un}compress
> > +and gzip.
> > 
> 
> Please go ahead.

Thank you, have done the upload.

Regards,
Salvatore

Bug#1030542: ITP: erlang-hex -- Package manager for the Erlang ecosystem

[John Lines]

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

* Package name: erlang-hex
  Version : 2.0.0
  Upstream Author : Eric Meadows-Jonsson
i URL : https://hex.pm/
* License : Apache Software License 2.0
  Programming Lang: Elixir,Erlang
  Description : Package manager for the Erlang ecosystem

The Hex packaging manager manages dependencies within the Erlang
and Elixir ecosystem. It can download software from repositories
such as hex.pm, and can be used with elixir's mix program or rebar3.

It is a build-depedency for the pleroma federated social network.
Original packaging by Gantua.

Bug#1030429: libervia-backend: FTBFS: InvalidVersion: Invalid version: '0.9.0-hg3993'

[Martin]

Control: retitle -1 libervia-backend: FTBFS: InvalidVersion: Invalid version: 
'0.9.0-hg3993'
Control: user debian-pyt...@lists.debian.org
Control: usertags -1 python3.11

The cause of the error is not the failing unit test (which is ignored as
"known broken"), but that Python 3.11 is more strict about version
numbers than Python 3.10. The tilde '~' is not valid in PEP 440, but
somehow replaced with a dash '-', which is invalid, too:


Traceback (most recent call last):
  File "/<>/setup.py", line 97, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 108, in 
setup
return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
185, in setup
return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
201, in run_commands
dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
969, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1213, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
988, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/install.py", line 68, 
in run
return orig.install.run(self)
   ^^
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py", line 
709, in run
self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 318, 
in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1213, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
987, in run_command
cmd_obj.ensure_finalized()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 111, 
in ensure_finalized
self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/command/install_egg_info.py", 
line 31, in finalize_options
ei_cmd = self.get_finalized_command("egg_info")
 ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 305, 
in get_finalized_command
cmd_obj.ensure_finalized()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 111, 
in ensure_finalized
self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 
219, in finalize_options
parsed_version = parse_version(self.egg_version)
 ^^^
  File 
"/usr/lib/python3/dist-packages/pkg_resources/_vendor/packaging/version.py", 
line 266, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'0.9.0-hg3993'
E: pybuild pybuild:388: install: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py install --root '/<>/debian/tmp' 
--install-lib=/usr/share/libervia/ --install-scripts=/launchers/ --verbose
dh_auto_install: error: pybuild --install -i python{version} -p 3.11 --dest-dir 
/<>/libervia-backend-0.9.0\~hg3993/debian/tmp returned exit code 13
make: *** [debian/rules:18: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[Andreas Beckmann]

Did you try nvidia-legacy-340xx-kernel-dkms -16 (get it from 
snapshot.d.o) with only the use-nv-kernel-ARCH.o_binary.patch patch 
replaced by the version from -17 to get support for Linux 6.1?

That gives you again the older set of acpi patches.
If that works I'll look again into the acpi patches and the difference 
between the two sets.
There is no need to replace any other package besides the -dkms one for 
these tests.


Andreas

Bug#1030541: gap-browse: autopkgtest failure

[Adrian Bunk]

Source: gap-browse
Version: 1.8.18-1
Severity: serious
X-Debbugs-Cc: Bill Allombert 

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gap-browse/31044433/log.gz

...
autopkgtest [15:59:11]: test test: [---

true
Architecture: x86_64-pc-linux-gnu-default64-kv8

testing: ./tst/test.tst
> Diff in ./tst/test.tst:78
# Input is:
NCurses.Alert( "Hello world!", 1000 );
# Expected output:
fail
# But found:
#I  NCurses.Alert: cannot switch to visual mode because of TERM = "d\
umb"
fail
...
autopkgtest [15:59:51]:  summary
test FAIL non-zero exit status 1

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Rene Engelhard]

Hi,

Am 04.02.23 um 19:14 schrieb Soren Stoutner:

Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is probably
not the most accurate name, but bdic-convert-dict would make sense.  Another
option would be to name it convert-bdic.  The Chromium upstream names the tool
convert_dict, but we aren’t beholden to follow their lead.

I have updated the merge request to name the tool /usr/bin/convert-bdic,  and
the virtual package to be convert-bdic, but can change it again if there is a
consensus in a different direction.



convert-bdic is fine with me,  thanks :)


Regards,


Rene

Bug#1030401: Many bugs about unsatisfiable build-dependencies

[Lucas Nussbaum]

Hi,

On 04/02/23 at 12:17 +0100, Stéphane Glondu wrote:
> Hello,
> 
> These unsatisfiable build-dependencies are temporary and will be solved by
> properly sequenced binNMUs or sourceful uploads that I am currently dealing
> with.
> 
> I do not see the value of such bug reports. Packages with unsatisfiable
> build-dependencies do not migrate to testing nor are picked up by buildd
> daemons (so no actual FTBFS). They add burden and look like noise to me.

I agree in general (and usually exclude such classes of failures when
filing bugs).

However, given our state in the release preparation, I see some value in
stating "there's something fishy about those packages".

I'm of course fine if you prefer to mass-close those bugs.

Lucas

Bug#1029147: bullseye-pu: package needrestart/3.5-4+deb11u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-01-18 at 16:27 +0100, Patrick Matthäi wrote:
> needrestart on stable reports a uninitialized perl warning on some
> amd64
> systems when using option "-b"
> 

Please go ahead.

Regards,

Adam

Bug#1029217: bullseye-pu: package libapreq2/2.13-7~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-01-19 at 20:47 +0100, Tobias Frost wrote:
> I've uploaded prepared an security update of libapreq2 for LTS and
> ELTS.
> The proposed upload fixes the CVE also for bullseye.
> 
> CVE-2022-22728:
> 
> A flaw in Apache libapreq2 versions 2.16 and earlier could cause a
> buffer
> overflow while processing multipart form uploads. A remote attacker
> could send
> a request causing a process crash which could lead to a denial of
> service
> attack.
> 

Please go ahead, with the changes suggested by Salvatore.

Regards,

Adam

Bug#1029320: bullseye-pu: package w3m/0.5.3+git20210102-6+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-01-21 at 19:51 +0900, Tatsuya Kinoshita wrote:
> I'd like to update package w3m in bullseye to fix a security issue,
> managed as minor issue, no-dsa.
> cf. https://security-tracker.debian.org/tracker/CVE-2022-38223
> 

Please go ahead.

Regards,

Adam

Bug#1029385: bullseye-pu: package postfix/3.5.17-0+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-01-21 at 21:02 -0500, Scott Kitterman wrote:
> Routine postfix bugfix update

Please go ahead.

Regards,

Adam

Bug#1030540: abi-compliance-checker uses inconsitent flags to GCC for C code

[Steve Langasek]

Package: abi-compliance-checker
Version: 2.3-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Mathieu,

I'm currently using abi-compliance-checker to do some archive-wide analysis
of armhf library ABIs, and how those would change if we turned on 64-bit
time_t.  In the process, I discovered a bug in a-c-c's -cxx-incompatible
option: when checking whether any symbol names need to be mangled to not
break when compiled with the C++ frontend, it fails to pass the preprocessor
defines (-U__cplusplus -D_Bool=\"bool\") to the preprocessor that it's set
up to pass when doing a full compilation!  The result is that a good number
of libraries which use C++-incompatible symbol names are handled wrong at
the preprocessor stage, so even if the headers are successfully mangled by
a-c-c, the preprocessed code passed to the compiler is the wrong code and
can't be successfully compiled.

The attached patch addresses this and ensures we're always passing the same
-D and -U options to the preprocessor when compiling C code.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru abi-compliance-checker-2.3/debian/patches/consistent-C-flags.patch 
abi-compliance-checker-2.3/debian/patches/consistent-C-flags.patch
--- abi-compliance-checker-2.3/debian/patches/consistent-C-flags.patch  
1969-12-31 16:00:00.0 -0800
+++ abi-compliance-checker-2.3/debian/patches/consistent-C-flags.patch  
2023-02-03 07:53:52.0 -0800
@@ -0,0 +1,24 @@
+Description: use consistent flags to GCC when doing two passes
+ When using the -cxx-incompatible option, a-c-c runs gcc in two passes,
+ a preprocessor pass and a compilation pass, with a step in between to try
+ to fix up C code to be C++-compatible.  However, a-c-c passes -U__cplusplus
+ during the compilation pass but *not* to the preprocessor pass, which can
+ result in the detection of C code to fail.  Pass the preprocessor instruction
+ to the preprocessor pass where it belongs!
+Author: Steve Langasek 
+Last-Update: 2023-02-03
+Forwarded: no
+
+Index: abi-compliance-checker-2.3/modules/Internals/TUDump.pm
+===
+--- abi-compliance-checker-2.3.orig/modules/Internals/TUDump.pm
 abi-compliance-checker-2.3/modules/Internals/TUDump.pm
+@@ -640,7 +640,7 @@
+ my ($HeaderPath, $IncStr, $LVer) = @_;
+ 
+ my $TmpDir = $In::Opt{"Tmp"};
+-my $PreprocessCmd = getCompileCmd($HeaderPath, "-E", $IncStr, $LVer);
++my $PreprocessCmd = getCompileCmd($HeaderPath, "-U__cplusplus 
-D_Bool=\"bool\" -E", $IncStr, $LVer);
+ my $Content = undef;
+ 
+ if(not defined $In::Opt{"MinGWCompat"}
diff -Nru abi-compliance-checker-2.3/debian/patches/series 
abi-compliance-checker-2.3/debian/patches/series
--- abi-compliance-checker-2.3/debian/patches/series2021-12-09 
02:01:04.0 -0800
+++ abi-compliance-checker-2.3/debian/patches/series2023-02-03 
07:48:24.0 -0800
@@ -3,3 +3,4 @@
 oom-exec-helper.patch
 fpic-for-arm64.patch
 0659b3b0a23e3535f41c6fd8dee5255ad8e29f7e.patch
+consistent-C-flags.patch

Bug#1029619: bullseye-pu: package ghostscript/9.53.3~dfsg-7+deb11u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-01-25 at 16:56 +0100, Håvard Flaget Aasen wrote:
> The file '/usr/bin/ps2epsi' is a wrapper for 'ps2epsi.ps', and
> 'ps2epsi.ps' is being called with wrong path, which prevents it from
> being executed.
> 
> I haven't checked when the bug was introduced, but the version in
> Bullseye is the last version that as it. The patch from upstream was
> included in version 9.54.
> 

Please go ahead.

Regards,

Adam

Bug#1030539: d/copyright is wrong

[Paul R. Tagliamonte]

Package: php-dompdf-svg-lib
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

As noted in :

This package is LGPLv3+ (LGPL-3.0+) not LGPLv3 (LGPL-3.0). Please
update your copyright file in another upload before it migrates to
testing/stable.

-- 
:wq

Bug#1030304: Licensing & copyright issues

[Adam Ant]

> Public Domain is an accepted as DFSG compatible. As the DFSG-FAQ §15
> says: "Software placed in the public domain has all the freedoms
> required by the DFSG, and is free software."

Yes, Public Domain is indeed "free software" and you can incorporate it in a 
larger project (either proprietary or FOSS). But what you can not do is to 
claim copyright over that code or re-license it. 

By slapping a copyright notice on a file, you are basically claiming "I wrote 
this". Give the original authors due credit and mark the files as Public Domain 
source.

Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12

[Roger Shimizu]

control: tags -1 +help

+ Hans-Christoph

Dear Hans-Christoph,

It'd be appreciated if you can help this ticket.
I tried a few ways, but it still doesn't work.

On Sat, Feb 4, 2023 at 12:09 AM Roger Shimizu  wrote:
>
> control: reopen -1
>
> Yes, it ftbfs on sid now.
> And I tried latest upstream 13.0.0_r24, result is the same.
> Have to fix this issue before we can migrate to sid.

Error log is not originally reported, for latest error log please refer to:
- https://bugs.debian.org/1012890#17

I guess the issue is caused due to upstream using clang stdc++ lib,
but we're using gcc/g++ one.
Those two have slight differences.

Cheers,
Roger

Bug#997389: xrdesktop: diff for NMU version 0.15.1-5.1

[Adrian Bunk]

Control: tags 997389 + patch

Dear maintainer,

I've prepared an NMU for xrdesktop (versioned as 0.15.1-5.1) and 
uploaded it to DELAYED/1. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru xrdesktop-0.15.1/debian/changelog xrdesktop-0.15.1/debian/changelog
--- xrdesktop-0.15.1/debian/changelog	2020-12-03 13:57:21.0 +0200
+++ xrdesktop-0.15.1/debian/changelog	2023-02-04 20:37:39.0 +0200
@@ -1,3 +1,10 @@
+xrdesktop (0.15.1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix Python FTBFS. (Closes: #997389)
+
+ -- Adrian Bunk   Sat, 04 Feb 2023 20:37:39 +0200
+
 xrdesktop (0.15.1-5) unstable; urgency=medium
 
   * Add Breaks+Replaces for libxrdesktop-0.13-0. (Closes: #971997)
diff -Nru xrdesktop-0.15.1/debian/xrdesktop.install xrdesktop-0.15.1/debian/xrdesktop.install
--- xrdesktop-0.15.1/debian/xrdesktop.install	2020-07-22 13:41:47.0 +0300
+++ xrdesktop-0.15.1/debian/xrdesktop.install	2023-02-04 20:37:35.0 +0200
@@ -1,4 +1,4 @@
-usr/lib/python*/site-packages/xrdesktop/config.py
+usr/lib/python*/dist-packages/xrdesktop/config.py
 usr/bin/xrd-settings
 usr/share/applications/org.xrdesktop.settings.desktop
 usr/share/xrdesktop/org.xrdesktop.settings.gresource

Bug#1029823: bullseye-pu: package ruby-cfpropertylist/2.2.8-1.1+deb11u1

[Jakob Haufe]

On Sat, 04 Feb 2023 18:14:38 +
"Adam D. Barratt"  wrote:

> Does that imply that the package has been broken for a very long time?
> ruby 1.8 was removed from the archive nearly a decade ago.

Most probably, yes.

> In any case, please go ahead.

Thanks, will do.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpAlr0NUE38U.pgp
Description: OpenPGP digital signature

Bug#1016744: Test failure has become significantly rarer

[Nicholas Guriev]

severity 1016744 minor
retitle 1016744 vim-ultisnips: flaky autopkgtest with-neovim
stop

I applied a patch [1] increasing attempts of tests with regular expressions.
And now probability of failure is far less.

Although, the initial issue with a race of I/O in tmux(1) was not completely
fixed. I daresay it does not block our release of the package.

If you still encounter failure of the with-neovim autopkgtest as of package
version 3.2-2, please retry the test and it should pass. Sorry for 
inconvenience.

 [1]: 
https://salsa.debian.org/mymedia/vim-ultisnips/-/commit/50df4908a8452042d358cce94527c22b4d253872


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

Bug#1030096: #1030096 dask.distributed autopkgtest fail

[Rebecca N. Palmer]

I have an attempt to fix this in Salsa now (in my fork), but it hasn't 
had time to run the tests yet, so I don't know whether it works.


Note the above mention that if we lose dask.distributed then we lose 
Spyder, which makes this a bigger issue than I initially thought.

Bug#1024373: rust-reqwest: feature "socks" is missing

[Peter Michael Green]

Please consider enabling feature socks now: Package rust-socks is now in Debian.


The socks feature of rust-reqwest depends on the tokio-socks crate, not the 
socks
crate.

Bug#1030538: pulseaudio-module-gsettings and zeroconf unmet dependencies

[Witold Baryluk]

Package: pulseaudio
Version: 16.1+dfsg1-2+b1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

I have no idea how is this possible, but during build of live Debian iso
of testing/bookworm, using live-build, I got this:

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:
 pulseaudio-module-gsettings : Depends: pulseaudio (= 16.1+dfsg1-2+b1)
 pulseaudio-module-zeroconf : Depends: pulseaudio (= 16.1+dfsg1-2+b1)
E: Unable to correct problems, you have held broken packages.
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Reading state information...

real2m38.843s
user0m0.002s
sys 0m0.013s


Tried with 3 different mirrors.

The list provided to the apt-get does not contain pulseaudio or any
pulseaudio modules. It does contain libpulse-dev specified manually. And
some other packages. So the pulseaudio itself is installed via transitive
dependency (i.e. something like gnome or mate). (the actuall command line
to apt is too long too list here, it has over 8000 packages specified).

I had no issues few weeks ago, and I changed nothing. So something must
have changed in packaging, apt or archive.
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; remixing-produce-lfe = no
; remixing-consume-lfe = no
; lfe-crossover-freq = 0

; flat-volumes = no

; rescue-streams = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4

Bug#1029651: bullseye-pu: package libxpm/1:3.5.12-1.1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-01-25 at 21:32 +0100, Salvatore Bonaccorso wrote:
> I would like to propose to update libxpm in bullseye as well fixing
> some no-dsa tagged CVEs by simply rebuilding the package which got
> uploaded to unstable (without other changes apart addressing issues):
> 
> +libxpm (1:3.5.12-1.1~deb11u1) bullseye; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rebuild for bullseye
> +
> + -- Salvatore Bonaccorso   Wed, 25 Jan 2023
> 21:19:41 +0100
> +
> +libxpm (1:3.5.12-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix CVE-2022-46285: Infinite loop on unclosed comments
> +  * Fix CVE-2022-44617: Runaway loop with width of 0 and enormous
> height
> +  * configure: add --disable-open-zfile instead of requiring
> -DNO_ZPIPE
> +  * Fix CVE-2022-4883: compression commands depend on  $PATH
> +  * Prevent a double free in the error code path
> +  * Use gzip -d instead of gunzip
> +  * debian/rules: configure: Set explicitly runtime paths for
> {,un}compress
> +and gzip.
> 

Please go ahead.

Regards,

Adam

Bug#1030537: rust-reqwest: fails tests requiring network access

[Jonas Smedegaard]

Source: rust-reqwest
Version: 0.11.11-3
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

autopkgtests fails some tests requiring network:

test_rustls_badssl_modern
test_allowed_methods

This was noticed in a migration test of rust-rustls:
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-reqwest/31010872/log.gz

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPeo2oACgkQLHwxRsGg
ASG9RA//X/0VzVbCTz+gn/BuvY+Nh1wJBX/3UJdhuQpuFS0CUlDAVyEe/Pz9mEvM
Fr7JbOHn6ouBlyGQXBM6s9RxJ63l0RxIi9u5cR8P92N2PiETxiGft6Jybkro42Zf
m1Q2Y442AIV+oqyt59Hks50BVBHLO2sj0xdwGB+hr5ZWJFie/FgwPrVf4981CWSI
PhC2zCVZMksSq/o7NGcRZ7P6ExV7aZMkmIGTp3csFyGbPnIYl3WxjIGArEsx2dql
vD9HeAyhR/6Jf4XlXeWUtPcxxeuhgTAwctNJ1NNFGQen9B8YG19hxsq6b+QpDk5U
Qt988Plov1ur7rRj5GqfjA/7IzaIFewBUClJqant09Ef0EwFal8LaxDdAF7kG3BS
UkkvThH8icJFbw+1F3OzrMlMY3lk/NVue9OwEMhKbbqSMdputlF1KDd/WKtgDwXa
lZDAnZEa9xASuY7xcmkjcr48JEKZPKj5y2pI9uMNTnn/gkKRGVrzft4mrpfvz214
W/lOoE+m+7tBmtRcLmEJ+x1L/CW2zYwqZZkSUePT1djkjmOmB2mczXVs3AOzGyll
w43nsPmB1pCwe123NFdMpGLlzICj4tBerbDhHx/KhQRA/u2HvN8GZqpAVL9VUDGG
H9yv9qLhppCO7QlMyGSmN1HXcXb01GXWXTmHCAz6US0/zciDJvo=
=7mfR
-END PGP SIGNATURE-

Bug#1029680: bullseye-pu: package grep/3.6-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-01-26 at 11:39 +0100, Santiago Ruano Rincón wrote:
> 3.6-1 is affected by https://bugs.debian.org/1029235#19
> 
> [ Impact ]
> Not fixing this means continue to have a POSIX-non-compliant
> behaviour.
> 

Please go ahead.

Regards,

Adam

Bug#1029728: bullseye-pu: package passenger/5.0.30-1.2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-01-26 at 16:40 -0300, Antonio Terceiro wrote:
> This updates makes it possible for users to use NodeJS binaries newer
> than the ones provided in bullseye.
> 
> [ Impact ]
> Users using a NodeJS version can't get passenger to work because it
> fails to start due to use of an invalid global variable.
> 

For some reason this bug never made it to debian-release.

Please go ahead.

Regards,

Adam

Bug#1029823: bullseye-pu: package ruby-cfpropertylist/2.2.8-1.1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-01-28 at 10:28 +0100, Jakob Haufe wrote:
> This update fixes #1029726 in bullseye.
> 
> This bug was introduced silently by updating ruby above 1.8.
> 

Does that imply that the package has been broken for a very long time?
ruby 1.8 was removed from the archive nearly a decade ago.

In any case, please go ahead.

Regards,

Adam

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is probably 
not the most accurate name, but bdic-convert-dict would make sense.  Another 
option would be to name it convert-bdic.  The Chromium upstream names the tool 
convert_dict, but we aren’t beholden to follow their lead.

I have updated the merge request to name the tool /usr/bin/convert-bdic,  and 
the virtual package to be convert-bdic, but can change it again if there is a 
consensus in a different direction.

On Saturday, February 4, 2023 10:51:38 AM MST Rene Engelhard wrote:
> Hi,
> 
> Sorry for my absence, and sorry if it's already discussed:
> 
> Why convert-dict? Sounds to generic to me, can't we at least do
> qt-convert-dict or bdic-convert-dict or so?
> 
> 
> Regards,
> 
> 
> Rene


-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1029994: bullseye-pu: package phyx/1.01+ds-2+b1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-01-29 at 20:28 -0500, Olek Wojnar wrote:
> The phyx package incorrectly declares a Build Dependency on the
> libatlas-cpp-0.6-dev package. The src:atlas-cpp package is obsolete
> since the
> only packages that actually depended on it (ember and cyphesis) were
> not in
> bullseye and have subsequently been removed even from unstable since
> the
> code base is too unstable for inclusion in Debian [1]. The incorrect
> BD of
> phyx on atlas-cpp is the only thing stopping atlas-cpp from also
> being removed
> from bullseye.
> 

dak disagrees with the latter statement:

Checking reverse dependencies...
# Broken Depends:
eris: liberis-1.3-21
  liberis-1.3-dev

# Broken Build-Depends:
eris: libatlas-cpp-0.6-dev (0.6.3 >=)
phyx: libatlas-cpp-0.6-dev

In any case, please go ahead.

Regards,

Adam

Bug#1030113: bullseye-pu: package openvswitch/2.15.0+ds1-2+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2023-01-31 at 09:26 +0100, Thomas Goirand wrote:
> We would like to fix https://bugs.debian.org/1008684.
> Michael Prokop found the matching patch, and we would like to
> apply it to Bullseye.
> 
> [ Reason ]
> As per #1008684, restarting OVS in Bullseye makes the computer
> loose network.
> 
> [ Impact ]
> Any further update to OVS may be very annoying for OVS users,
> as a reboot may be necessary to restore network connectivity.

Please go ahead.

Regards,

Adam

Bug#1030536: wine: FTBFS because of a Makefile bug (hlsl.tab.h: No such file or directory)

[Santiago Vila]

Package: src:wine
Version: 8.0~repack-1
Severity: important
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
 debian/rules binary-arch
dh binary-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o 
-type l -printf "symlink  %p
" > debian/autoreconf.before
grep -q ^XDT_ configure.ac
autoreconf -f -i
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o 
-type l -printf "symlink  %p
" > debian/autoreconf.after
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'

[...]

x86_64-w64-mingw32-gcc -c -o libs/vkd3d/x86_64-windows/libs/vkd3d/state.o 
libs/vkd3d/libs/vkd3d/state.c -Ilibs/vkd3d -Iinclude -Iinclude/msvcrt -Ilibs/vkd3d/include 
-Ilibs/vkd3d/include/private -Ilibs/vkd3d/libs/vkd3d -Ilibs/vkd3d/libs/vkd3d-shader -D_UCRT 
-DWINE_NO_NAMELESS_EXTENSION -DCONST_VTABLE -DLIBVKD3D_SOURCE -DLIBVKD3D_SHADER_SOURCE 
-DLIBVKD3D_UTILS_SOURCE -D__WINE_PE_BUILD -fno-strict-aliasing -Wno-packed-not-aligned 
-mcx16 -gdwarf-4 -Wdate-time -g -O2 -ffile-prefix-map=/<>=. 
-Wno-array-bounds -Wno-unused-function -Wno-format
x86_64-w64-mingw32-gcc -c -o libs/vkd3d/x86_64-windows/libs/vkd3d/utils.o 
libs/vkd3d/libs/vkd3d/utils.c -Ilibs/vkd3d -Iinclude -Iinclude/msvcrt -Ilibs/vkd3d/include 
-Ilibs/vkd3d/include/private -Ilibs/vkd3d/libs/vkd3d -Ilibs/vkd3d/libs/vkd3d-shader -D_UCRT 
-DWINE_NO_NAMELESS_EXTENSION -DCONST_VTABLE -DLIBVKD3D_SOURCE -DLIBVKD3D_SHADER_SOURCE 
-DLIBVKD3D_UTILS_SOURCE -D__WINE_PE_BUILD -fno-strict-aliasing -Wno-packed-not-aligned 
-mcx16 -gdwarf-4 -Wdate-time -g -O2 -ffile-prefix-map=/<>=. 
-Wno-array-bounds -Wno-unused-function -Wno-format
x86_64-w64-mingw32-gcc -c -o libs/vkd3d/x86_64-windows/libs/vkd3d/vkd3d_main.o 
libs/vkd3d/libs/vkd3d/vkd3d_main.c -Ilibs/vkd3d -Iinclude -Iinclude/msvcrt 
-Ilibs/vkd3d/include -Ilibs/vkd3d/include/private -Ilibs/vkd3d/libs/vkd3d 
-Ilibs/vkd3d/libs/vkd3d-shader -D_UCRT -DWINE_NO_NAMELESS_EXTENSION -DCONST_VTABLE 
-DLIBVKD3D_SOURCE -DLIBVKD3D_SHADER_SOURCE -DLIBVKD3D_UTILS_SOURCE -D__WINE_PE_BUILD 
-fno-strict-aliasing -Wno-packed-not-aligned -mcx16 -gdwarf-4 -Wdate-time -g -O2 
-ffile-prefix-map=/<>=. -Wno-array-bounds -Wno-unused-function 
-Wno-format
flex -olibs/vkd3d/libs/vkd3d-shader/hlsl.yy.c 
libs/vkd3d/libs/vkd3d-shader/hlsl.l
x86_64-w64-mingw32-gcc -c -o libs/vkd3d/x86_64-windows/libs/vkd3d-shader/hlsl.yy.o 
libs/vkd3d/libs/vkd3d-shader/hlsl.yy.c -Ilibs/vkd3d -Iinclude -Iinclude/msvcrt 
-Ilibs/vkd3d/include -Ilibs/vkd3d/include/private -Ilibs/vkd3d/libs/vkd3d 
-Ilibs/vkd3d/libs/vkd3d-shader -D_UCRT -DWINE_NO_NAMELESS_EXTENSION -DCONST_VTABLE 
-DLIBVKD3D_SOURCE -DLIBVKD3D_SHADER_SOURCE -DLIBVKD3D_UTILS_SOURCE -D__WINE_PE_BUILD 
-fno-strict-aliasing -Wno-packed-not-aligned -mcx16 -gdwarf-4 -Wdate-time -g -O2 
-ffile-prefix-map=/<>=. -Wno-array-bounds -Wno-unused-function 
-Wno-format
libs/vkd3d/libs/vkd3d-shader/hlsl.l:25:10: fatal error: hlsl.tab.h: No such 
file or directory
   25 | #include "hlsl.tab.h"
  |  ^~~~
compilation terminated.
make[2]: *** [Makefile:31895: 
libs/vkd3d/x86_64-windows/libs/vkd3d-shader/hlsl.yy.o] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: error: make -j1 returned exit code 2
make[1]: *** [debian/rules:159: override_dh_auto_build-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:107: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


The above is just how the build ends and I believe it's also the most relevant 
part.

Simple question:

Why is make trying to use hlsl.tab.h before generating it?


Note: I discovered this by building on a system with a single CPU.

To reproduce, please try setting GRUB_CMDLINE_LINUX="nr_cpus=1"
in /etc/default/grub first. If that does not work, my general offer
for ssh access below still applies in either case.

-

About the archive rebuild: The build was made using virtual machines
from Hetzner, with enough memory, enough disk, and either one or two
CPUs, using a reduced chroot with only build-essential packages (plus
debhelper).

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.

Bug#1029968: bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3e0/0x4d0

[Diederik de Haas]

On Saturday, 4 February 2023 02:06:02 CET Dr. David Alan Gilbert wrote:
> a) The patch I bisected to is not the root cause of the bug; it just
> triggers a ~9 year old bug in the v4l code - so this patch isn't going
> to get changed.
> 
> b) The ~9 year old bug is in a particularly hairy piece of memory management
> code  in v4l that I doubt anyone is going to fix.
> 
> c) The plan is all the drivers using that API are to either be retired
> or rewritten using a new API; that's already been done for some of the
> drivers and the bttv one is a few months out.  I'm not sure that's
> any use to this version of Debian though.
> 
> d) The work arounds are:
>   1) Disable iommu
>   2) some v4l tools can use an mmap interface rather than the read(2)
> interface; that seems to be OK.

Also reading the upstream conversation, that seems like a good summary :)

I could be wrong (ofc), but I doubt this issue will be fixed in kernel 6.1 
which is planned to be Bookworm's kernel.

What you could do is test any patch(es) they put out and provide feedback on 
those and if you find that the patch(es) fixes the/your issue, you could 
consider providing a "Tested-By: yourname " which can have a 
positive effect on the maintainer accepting the patch from which it then can 
procede further up the chain to Linus.
When it does end up in Linus' tree and it would need to have a new Kconfig 
option enabled in Debian's kernel, feel free to request that.

I think IOMMU is a really good thing, so disabling that does not sound ideal, 
but it could be an acceptable workaround (for now).
If you want to run Bookworm on your system, you'd probably have to wait till a 
suitable Backports kernel becomes available. If you go for Trixie, you should 
get (in time) the proper fix by just upgrading.

Thanks for all the investigative work and bringing it to upstream :-)

Cheers,
  Diederik

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

Bug#1024805: bullseye-pu: package libvirt/7.0.0-3+deb11u1

[Adam D. Barratt]

Hi Guido,

On Wed, 2022-12-14 at 20:00 +0100, Guido Günther wrote:
> Hi,
> On Mon, Dec 12, 2022 at 06:39:42PM +, Adam D. Barratt wrote:
> > On Sun, 2022-12-11 at 16:24 +0100, Guido Günther wrote:
> > > Hi Adam,
> > > On Wed, Dec 07, 2022 at 08:22:41PM +, Adam D. Barratt wrote:
> > > > Control: tags -1 + confirmed
> > > > 
> > > > On Fri, 2022-11-25 at 15:19 +0100, Guido Günther wrote:
> > > > > Fix lxc container reboots and shutdown (#983871, #991773).
> > > > > 
> > > > 
> > > > Please go ahead.
> > > 
> > > Uploaded now, thanks!
> > 
> > Unfortunately the build fails on both arm64 and armhf while running
> > the
> > test suite. Each has been tried a couple of times, for a total of
> > four
> > different buildds across three hosters between them.
> 
> Thanks for letting me know! I'll have a look (I assume that the
> current
> version in stable will fail the same way).
> 

Did you have any luck with this?

Regards,

Adam

Bug#1030535: python-pycdlib: FTBFS (AttributeError: module 'inspect' has no attribute 'getargspec')

[Santiago Vila]

Package: src:python-pycdlib
Version: 1.12.0+ds1-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
=== short test summary info 
===
FAILED tests/integration/test_parse.py::test_parse_write_with_progress - 
AttributeError: module 'inspect' has no attribute 'getargspec'
FAILED 
tests/integration/test_parse.py::test_parse_write_with_progress_three_arg - 
AttributeError: module 'inspect' has no attribute 'getargspec'
= 2 failed, 1702 passed, 17 skipped in 
13.87s =
make[1]: *** [debian/rules:19: override_dh_auto_install] Error 1
make[1]: Leaving directory '/home/sanvila/python-pycdlib-1.12.0+ds1'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and I believe it's also the most relevant 
part.

The failure also happens here with similar error message:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-pycdlib.html


About the archive rebuild: The build was made using virtual machines
from Hetzner, with enough memory, enough disk, and either one or two
CPUs, using a reduced chroot with only build-essential packages (plus
debhelper).

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.

Bug#1030526: live-build: Fails to build bookworm, due to firmware-linux

[Witold Baryluk]

Package: live-build
Version: 1:20230131
Followup-For: Bug #1030526
X-Debbugs-Cc: witold.bary...@gmail.com

Oo. A new archive area / suite. That must be new indeed, and explains why
it broke.

Using non-free-firmware archive area did help! (my build fails at the
moment, due to some pulseaudio-module-zeroconf dependency issue, but that
is probably just transient issue in the archive, not live-build issue).

I also modified some live-build files to install also firmware-misc-non
free from that area.

Thank you Roland.

PS. I will try 'lb config' without root next time. (looks to be working)

Bug#1030093: dgit: can't import python-coverage.

[Ian Jackson]

Ian Jackson writes ("Re: Bug#1030093: dgit: can't import python-coverage."):
> (Also probably gbp pq ought to cope natively, so I will file a bug
> about that.).

This is now
  #1030534: gbp pq import fails with series file containing form feed

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.