Bug#1016096: FTBFS on arm*

[Daniel Baumann]

Package: libdrm
Version: 2.4.110-1
Severity: serious

Hi,

unfortunately the last upload of libdrm failed to build on all arm
architectures:

https://buildd.debian.org/status/package.php?p=libdrm=unstable

Regards,
Daniel

Bug#1015920: RFS: picklecast/1.0.2 [ITP] -- Screenshare receiver

[Evan Widloski]

I've corrected the copyright and changelog files.

> What is that adapter-latest.js file in debian/copyright?

It's a shim which hides variation in the WebRTC api between browsers.

Evan

Bug#1016095: RFS: archlinux-keyring/0~20220713-1 [ITP] -- Arch Linux PGP keyring

[Michel Alexandre Salim]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "archlinux-keyring":

 * Package name: archlinux-keyring
   Version : 0~20220713-1
   Upstream Author : arch-proje...@lists.archlinux.org
 * URL : https://gitlab.archlinux.org/archlinux/archlinux-keyring
 * License : GPL-3+
 * Vcs : https://gitlab.archlinux.org/archlinux/archlinux-keyring
   Section : misc

The source builds the following binary packages:

  archlinux-keyring - Arch Linux PGP keyring

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

  https://mentors.debian.net/package/archlinux-keyring/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/archlinux-keyring/archlinux-keyring_0~20220713-1.dsc

Changes for the initial release:

 archlinux-keyring (0~20220713-1) unstable; urgency=low
 .
   * Initial release. (Closes: #1016094)

Regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Stephen Dennis]

I've submitted a second upload to mentors that:

1. I believe will address libmux.so being used before it is built. I've
tried to reproduce a race condition with make -j12, but I am unsuccessful.
For me, the build always succeeds.
2. I hope the above fix prevents any random reference to an external libmux
or random and unintended reference to libxbase64 or .la files.

On Tue, Jul 26, 2022 at 9:18 PM Stephen Dennis 
wrote:

> Could it be a naming collision between the private libmux and an
> official libmux package?
>
> On Tue, Jul 26, 2022 at 9:13 PM Stephen Dennis 
> wrote:
>
>> How can I reproduce what you are seeing? The package doesn't use libtool,
>> and no .la files are produced or included. There should be no reference to
>> libxbase64. I'm not even sure what that is.
>>
>>
>> On Tue, Jul 26, 2022 at 8:30 PM Adam Borowski 
>> wrote:
>>
>>> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
>>> >Package name: xbase64
>>> >Version : 3.1.2-14
>>>
>>> >  xbase64 (3.1.2-14) unstable; urgency=medium
>>> >  .
>>> >* Migrate to debhelper-compat 13:
>>> >  - debian/control: Add debhelper-compat (= 13).
>>> >  - Remove debian/compat.
>>> >  - Add usr/bin/xbase64-config into new debian/not-installed.
>>> >  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
>>> >  debian/libxbase64-bin.install.
>>> >* Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
>>> >* debian/copyright:
>>> >  - Add year 2022 to myself.
>>> >* Disable Link time optimization (Closes: #1015707):
>>> >  - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
>>> >* debian/control: Add Rules-Requires-Root: no.
>>>
>>> Is there a reason you include the .la file?  From my experience it being
>>> needed for anything suggests severe borkage, and the Policy concurs:
>>>
>>> # [...] these files normally should not be included in the Debian
>>> package,
>>> # since the information they include is not necessary to link with the
>>> # shared library on Debian and can add unnecessary additional
>>> dependencies
>>> # to other programs or libraries.
>>>
>>> It then says:
>>>
>>> # If the ".la" must be included, it should be included in the
>>> # development ("-dev") package, unless the library will be loaded by
>>> # "libtool"’s "libltdl" library. If it is intended for use with
>>> # "libltdl", the ".la" files must go in the run-time library package.
>>>
>>> libxbase64-bin is neither.
>>>
>>>
>>> Meow!
>>> --
>>> ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
>>> ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
>>> ⢿⡄⠘⠷⠚⠋⠀
>>> ⠈⠳⣄ You should also never anthropomorphize spammers and
>>> telemarketers.
>>>
>>>

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Stephen Dennis]

Could it be a naming collision between the private libmux and an
official libmux package?

On Tue, Jul 26, 2022 at 9:13 PM Stephen Dennis 
wrote:

> How can I reproduce what you are seeing? The package doesn't use libtool,
> and no .la files are produced or included. There should be no reference to
> libxbase64. I'm not even sure what that is.
>
>
> On Tue, Jul 26, 2022 at 8:30 PM Adam Borowski  wrote:
>
>> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
>> >Package name: xbase64
>> >Version : 3.1.2-14
>>
>> >  xbase64 (3.1.2-14) unstable; urgency=medium
>> >  .
>> >* Migrate to debhelper-compat 13:
>> >  - debian/control: Add debhelper-compat (= 13).
>> >  - Remove debian/compat.
>> >  - Add usr/bin/xbase64-config into new debian/not-installed.
>> >  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
>> >  debian/libxbase64-bin.install.
>> >* Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
>> >* debian/copyright:
>> >  - Add year 2022 to myself.
>> >* Disable Link time optimization (Closes: #1015707):
>> >  - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
>> >* debian/control: Add Rules-Requires-Root: no.
>>
>> Is there a reason you include the .la file?  From my experience it being
>> needed for anything suggests severe borkage, and the Policy concurs:
>>
>> # [...] these files normally should not be included in the Debian package,
>> # since the information they include is not necessary to link with the
>> # shared library on Debian and can add unnecessary additional dependencies
>> # to other programs or libraries.
>>
>> It then says:
>>
>> # If the ".la" must be included, it should be included in the
>> # development ("-dev") package, unless the library will be loaded by
>> # "libtool"’s "libltdl" library. If it is intended for use with
>> # "libltdl", the ".la" files must go in the run-time library package.
>>
>> libxbase64-bin is neither.
>>
>>
>> Meow!
>> --
>> ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
>> ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
>> ⢿⡄⠘⠷⠚⠋⠀
>> ⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.
>>
>>

Bug#1015898: ITP: FoxDot -- Live Coding with Python

[Paul Wise]

On Sat, 23 Jul 2022 15:22:11 +0200 Josue Ortega wrote:

> * Package name: foxdot
> * URL : https://foxdot.org/

I note that the GitHub repo suggests that FoxDot is unmaintained:

   https://github.com/Qirky/FoxDot

   I am no longer actively developing FoxDot and will only be making minor
   changes to the code in response to issues / pull requests in this time.

So you might want to talk to upstream about the situation. Maybe they
should create a LiveCoding GitHub organisation, invite other people and
projects and move maintenance of FoxDot to the new organisation.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Stephen Dennis]

How can I reproduce what you are seeing? The package doesn't use libtool,
and no .la files are produced or included. There should be no reference to
libxbase64. I'm not even sure what that is.


On Tue, Jul 26, 2022 at 8:30 PM Adam Borowski  wrote:

> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
> >Package name: xbase64
> >Version : 3.1.2-14
>
> >  xbase64 (3.1.2-14) unstable; urgency=medium
> >  .
> >* Migrate to debhelper-compat 13:
> >  - debian/control: Add debhelper-compat (= 13).
> >  - Remove debian/compat.
> >  - Add usr/bin/xbase64-config into new debian/not-installed.
> >  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
> >  debian/libxbase64-bin.install.
> >* Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
> >* debian/copyright:
> >  - Add year 2022 to myself.
> >* Disable Link time optimization (Closes: #1015707):
> >  - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
> >* debian/control: Add Rules-Requires-Root: no.
>
> Is there a reason you include the .la file?  From my experience it being
> needed for anything suggests severe borkage, and the Policy concurs:
>
> # [...] these files normally should not be included in the Debian package,
> # since the information they include is not necessary to link with the
> # shared library on Debian and can add unnecessary additional dependencies
> # to other programs or libraries.
>
> It then says:
>
> # If the ".la" must be included, it should be included in the
> # development ("-dev") package, unless the library will be loaded by
> # "libtool"’s "libltdl" library. If it is intended for use with
> # "libltdl", the ".la" files must go in the run-time library package.
>
> libxbase64-bin is neither.
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
> ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
> ⢿⡄⠘⠷⠚⠋⠀
> ⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.
>
>

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Adam Borowski]

On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
>Package name: xbase64
>Version : 3.1.2-14

>  xbase64 (3.1.2-14) unstable; urgency=medium
>  .
>* Migrate to debhelper-compat 13:
>  - debian/control: Add debhelper-compat (= 13).
>  - Remove debian/compat.
>  - Add usr/bin/xbase64-config into new debian/not-installed.
>  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
>  debian/libxbase64-bin.install.
>* Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
>* debian/copyright:
>  - Add year 2022 to myself.
>* Disable Link time optimization (Closes: #1015707):
>  - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
>* debian/control: Add Rules-Requires-Root: no.

Is there a reason you include the .la file?  From my experience it being
needed for anything suggests severe borkage, and the Policy concurs:

# [...] these files normally should not be included in the Debian package,
# since the information they include is not necessary to link with the
# shared library on Debian and can add unnecessary additional dependencies
# to other programs or libraries.

It then says:

# If the ".la" must be included, it should be included in the
# development ("-dev") package, unless the library will be loaded by
# "libtool"’s "libltdl" library. If it is intended for use with
# "libltdl", the ".la" files must go in the run-time library package.

libxbase64-bin is neither.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.

Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Stephen Dennis]

I wonder if it is a race condition in the Makefile. libmux.so is built from
code in the package. It isn't an external dependency. From the Makefile:

MUX_LIBS = -lmux
...
all: libmux.so netmux slave stubslave links subdirs
...
stubslave: stubslave.o
$(CXX) $(ALLCXXFLAGS) -o stubslave stubslave.o -L. $(LIBS)
$(MUX_LIBS) $(STUBLIBS)

I bet that should be

  stubslave: stubslave.o libmux.so
$(CXX) $(ALLCXXFLAGS) -o stubslave stubslave.o -L. $(LIBS)
$(MUX_LIBS) $(STUBLIBS)

This has probably been an issue forever, but no one has tried to build it
on enough cores, yet. And, likewise, I won't know for certain that it is
fixed without someone without enough cores.

Stephen

On Tue, Jul 26, 2022 at 8:03 PM Adam Borowski  wrote:

> On Tue, Jul 26, 2022 at 03:29:03PM -0600, Stephen Dennis wrote:
> >  * Package name: tinymux
> >Version : 2.12.0.10-1
>
> >  tinymux (2.12.0.10-1) unstable; urgency=medium
> >  .
> >* New upstream release
> >  + fixes ftbfs with GCC-12. (Closes: #1013053)
> >* Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
> >  + Removed build date and number for reproducible build.
> >(Closes: #866945)
>
> Alas, it fails to build:
> g++ -std=c++14 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -g -O
>  -DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux: No such file or directory
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
> ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
> ⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...
>

Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Adam Borowski]

On Tue, Jul 26, 2022 at 03:29:03PM -0600, Stephen Dennis wrote:
>  * Package name: tinymux
>Version : 2.12.0.10-1

>  tinymux (2.12.0.10-1) unstable; urgency=medium
>  .
>* New upstream release
>  + fixes ftbfs with GCC-12. (Closes: #1013053)
>* Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
>  + Removed build date and number for reproducible build.
>(Closes: #866945)

Alas, it fails to build:
g++ -std=c++14 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -O 
-DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux 
/usr/bin/ld: cannot find -lmux: No such file or directory


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Bug#994151: youtube-dl seems to be alive again

[Christoph Anton Mitterer]

On Tue, 2022-07-26 at 00:29 -0400, Andres Salomon wrote:
> Yeah, I was just noticing that. I'll wait a few more months to see if
> youtube-dl does an actual release, but long-term it might make sense
> to 
> turn youtube-dl into an empty package that depends on yt-dlp.

This could make sense even if the former would make a new release.

I mean in Debian we have current Python versions, and as long as yt-dlp
is feature-wise far more active than youtube-dl, that should be enough
for Debian users.


> Since they have different command-line arguments and people might be 
> using youtube-dl in scripts, I do wonder if youtube-dl should remain
> in 
> bookworm with a NEWS.Debian warning users to switch to yt-dlp, and
> have 
> it become a dummy package in bookworm+1?

Or just add a release notes entry that youtube-dl has been replaced by
the other, with noting the similar CLI and refering to the yt-dlp
manpage for the exact differences.



On Tue, 2022-07-26 at 07:08 +0200, Andreas Tille wrote:
> I would be really happyif you would consider team
> maintaining youtube-dl and yt-dl since I'm really not the best person
> to
> maintain this package.  I'm fine with sponsoring any of your work if
> you do
> not have upload permissions.

At least for yt-dlp, Unit 193 already does quite some awesome job of
Debian maintenance... so I guess there's not much needed for that right
now?


Thanks,
Chris.

Bug#1012987: libpodofo: ftbfs with GCC-12

[yokota]

Hello,

> I rewrite my patch to enable all string test.

New patch was already uploaded to salsa.
  https://salsa.debian.org/debian/libpodofo/-/merge_requests/2

--
YOKOTA

Bug#1016094: ITP: archlinux-keyring -- Arch Linux PGP keyring

[Michel Alexandre Salim]

Package: wnpp
Severity: wishlist
Owner: Michel Alexandre Salim 
X-Debbugs-Cc: debian-de...@lists.debian.org, mic...@michel-slm.name

* Package name: archlinux-keyring
  Version : 20220713
  Upstream Author : Christian Hesse 
* URL : https://gitlab.archlinux.org/archlinux/archlinux-keyring
* License : GPL-3+
  Programming Lang: Python
  Description : Arch Linux PGP keyring
The archlinux-keyring project holds PGP packet material and tooling
(keyringctl) to create the distribution keyring for Arch Linux. The keyring is
used by pacman to establish the web of trust for the packagers of the
distribution.

The PGP packets describing the main signing keys can be found below the
keyring/main directory, while those of the packagers are located below the
keyring/packager directory.

Having this packaged in Debian (and other distributions) will allow
mkosi, which is already in Debian, to generate Arch Linux images without
hardcoding the keyring.

I need a sponsor.

Bug#1015883: /usr/bin/update-alternatives: update-alternatives: manualy selected choice is overriden by apt-get dist-upgrade

[Guillem Jover]

Control: reassign -1 src:openjdk-11
Control: retitle -1 openjdk: Removes alternatives on deconfigure losing manual 
state

[ Leaving enough context for the reassign. ]

Hi!

On Sat, 2022-07-23 at 02:00:15 +0200, Richard Z wrote:
> Package: dpkg
> Version: 1.20.11
> Severity: normal
> File: /usr/bin/update-alternatives
> X-Debbugs-Cc: r...@linux-m68k.org

> on my system I have both i386 and amd64 versions of Java. I used
> update-alternatives to select am64 version while the proimary architecture
> is i386. My configuration looked like
> 
> # update-alternatives --config java
> There are 2 choices for the alternative java (providing /usr/bin/java).
> 
>   SelectionPath Priority   Status
> 
>   0/usr/lib/jvm/java-11-openjdk-i386/bin/java  auto
> mode
> * 1/usr/lib/jvm/java-11-openjdk-amd64/bin/java   1110  manual
> mode
>   2/usr/lib/jvm/java-11-openjdk-i386/bin/java  manual
> mode
> 
> While doing "apt-get dist-upgrade" I saw following messages in the console:
> update-alternatives: removing manually selected alternative - switching java 
> to
> auto mode
> update-alternatives: using /usr/lib/jvm/java-11-openjdk-i386/bin/java to
> provide /usr/bin/java (java) in auto mode
> 
> and the resulting configuration looked like this:
> 
> 
> # update-alternatives --config java
> There are 2 choices for the alternative java (providing /usr/bin/java).
> 
>   SelectionPath Priority   Status
> 
> * 0/usr/lib/jvm/java-11-openjdk-i386/bin/java  auto
> mode
>   1/usr/lib/jvm/java-11-openjdk-amd64/bin/java   1110  manual
> mode
>   2/usr/lib/jvm/java-11-openjdk-i386/bin/java  manual
> mode
> 
> My understanding of the manpage of update-alternatives is that once manual 
> mode
> is selected it should not be changed back to auto mode by an action like
> updating
> the package?
> Or how else should I achieve the desired effect?

This is due to the openjdk-NN-jre and openjdk-NN-jre-headless
prerm maintscripts removing the alternatives during «deconfigure»,
which can cause the lose of manual state during upgrades. This is
documented in the update-alternatives man page.

This should be fixed in all current openjdk versions, just reassigning
to the one affected by this report, and leaving the rest to the
maintainer.

> -- Package-specific info:
> System tainted due to merged-usr-via-aliased-dirs.
> 
> -- System Information:
> Debian Release: 11.4
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable'), (100, 'testing')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
> 
> Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Thanks,
Guillem

Bug#991778: dlint: Dlint fails to find version number of dig

[Paul Wise]

Control: forcemerge 991778 619936

On Wed, 2022-07-27 at 00:20 +0200, Patrik Schindler wrote:

> I'll think about it. Seems I won't inherit a huge list of
> unresolvable bugs. My decision might be based upon the availability
> of a concise "what it takes to be a package maintainer"
> documentation.

The basic process is that you upload package changes to mentors.d.n and
then search for a sponsor, who inspects the package and uploads it to
Debian. The maintainer should respond to bug reports and other queries.
Since this package also has no upstream project, the maintainer should
also try to fix bugs that are reported rather than forwarding them
upstream. Since dlint is also in several different distros, it might be
worth creating a new upstream project and using that as the basis of
the Debian package, then getting other distros to use it too, this
would be optional of course though. You'll need a mentors.d.n account
and since the dlint package is stored in git, you will also need an
account on the Debian Salsa service. Since the git repo is in Florian's
namespace, that would also need to be moved to the debian namespace.
Perhaps if Florian returns he could become your sponsor for this :)

https://mentors.debian.net/intro-maintainers/
https://tracker.debian.org/pkg/dlint
https://repology.org/project/dlint/packages
https://wiki.debian.org/Salsa

> Btw., I apparently created a second bug report, this one (991778) for
> the same issue. Browsing the still open bugs list  it appears, I've
> created a bug report for the same issue a decade before, 619936.

In future, please do check for existing bugs before filing new ones,
if you use reportbug then it will show you the list of open bugs.

> And already provided a similar solution.
> Which didn't make it into the releases in between.

I guess Florian didn't have time to look at all the bugs when he made
the last dlint update in 2019.

> Maybe close one of them, marked as dupe?

We can simply merge the bugs, which keeps it open but hides it when the
bug list is set to hide merged bugs. Done using the command above.

https://www.debian.org/Bugs/Reporting#control
https://www.debian.org/Bugs/server-control#forcemerge

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1016093: Grub UEFI installation fails when EFI partition has already been mounted

[Daniel Leidert]

Package: vmdb2
Version: 0.26-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When the EFI system partition is already mounted, the grub UEFI install fails
with

2022-07-27 00:47:13 DEBUG STDERR: mount: /tmp/tmpXXX/boot/efi: 
/dev/mapper/loopYp1 already mounted on /tmp/tmpXXX/boot/efi.

One can easily reproduce it with the uefi.vmdb example by simply mounting the
EFI partition to /boot/efi after mounting the root filesystem:

  - mount: efi
mount-on: /
dirname: '/boot/efi'

The workaround at the moment is to not have the EFI system partition mounted.
But it seems rather weird to have this as a requirement.

Regards, Daniel


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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-4
ii  debootstrap 1.0.126+nmu1
ii  e2fsprogs   1.46.5-2
ii  kpartx  0.8.8-1
ii  parted  3.5-1
ii  python3 3.10.5-2
ii  python3-jinja2  3.0.3-1
ii  python3-yaml5.4.1-1+b1
ii  qemu-utils  1:7.0+dfsg-7

Versions of packages vmdb2 recommends:
ii  ansible   5.5.0-1
ii  dosfstools4.2-1
ii  qemu-user-static  1:7.0+dfsg-7

vmdb2 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIB9kcJqmmF4VguFXclr8JZgo7DMFAmLgcYIACgkQclr8JZgo
7DMohRAAu9Bzz2r2dVaI9yIo+906kfqoSdMr7w+8oWEj0buZPI0qZ2pIbnY4Que8
LxmdHctRGAqA32/AFM4mpcEbApQB9UXEW9IXToqxdrJvRyMznYYWFJWJExWy64wb
EqHWWcZKNFVEKWXLnZfbQc7cYEvyIAntBgdwt88SVViYlumw2vJsElSZls4SWiL6
F4TloYlaUuJaOCfpXCM/lSpePFhAj3XUPpQ6odvwBWVLQNO41IBBMfDNbfJogtsx
yhD5CnBQAWYC7pkpIezGuG+HNBMiYWm1Z0c2DxQIT5a+rV4qLRktzpekgtTQ0KYC
4pbIKaGmW9EA1CUHNwDJx/BTt64T2eZ/bFPrPC02AXOvD/c/YA0QryUyZ27kFv4x
hf+I1EB8JRtwmwPSrY1Tqsz+1tGKhGQQSrIKI2fzH3+3e56Ne6gvt+NltvBOgEe9
P4jqF9uGoImIAkwoRyyyxk4b2+TnTyDRM4C3WQCr2x0B6Nb3ibDUVI2yG+vlHUlu
ZZks3/IJLYTne/UDveubizOUDoeFMjDl03Cwr0Fs+YIq/gpjxqBiuGpE99g8b49M
0S39LDW+Kvn3EM86nYz0JY0sob8GTE9sNsVDOW5eBTevu/BWwkAXlW490SrPfFS+
SrMTa3SPEvWa5O8hXk57fIwax8GN7hCxgEAIEzjvuiEJuNdnFBE=
=1MDK
-END PGP SIGNATURE-

Bug#619936: dlint fails when output of dig is changed via .digrc

[Patrik Schindler]

Hello,

this is a dupe for bug #991778.

:wq! PoC

Bug#991778: dlint: Dlint fails to find version number of dig

[Patrik Schindler]

Hello Paul,

Am 23.07.2022 um 02:06 schrieb Paul Wise :

>> Yes, unless you make dig less talkative with +nocmd.
> That looks like the cause of this problem indeed.

Thanks for confirmation!

> So the bug isn't likely to get fixed any time soon. If you have time to 
> maintain the package, salvaging it might be the best way forward.

I'll think about it. Seems I won't inherit a huge list of unresolvable bugs. My 
decision might be based upon the availability of a concise "what it takes to be 
a package maintainer" documentation.

> Otherwise please apply the fix locally for now.

I already did. :-)

Btw., I apparently created a second bug report, this one (991778) for the same 
issue. Browsing the still open bugs list  it appears, I've created a bug report 
for the same issue a decade before, 619936. And already provided a similar 
solution. Which didn't make it into the releases in between.

Maybe close one of them, marked as dupe?

:wq! PoC

Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'

[Diederik de Haas]

On Sunday, 11 July 2021 17:42:27 CEST Steve McIntyre wrote:
> >If an error is detected, a message like "Look at this wiki page  for
> >possible solutions", with the solution you just provided me (among others),
> >would be really helpful.
> >I've made/attached screenshots which could be used for that.
> 
> I'm adding an extra section to https://wiki.debian.org/UEFI right now,
> at least.

I just ran into this issue again and your solution worked again :-)
But I ran a search in my mail folder(s) to find it again, so a pointer to
that wiki page would still be useful I'd guess.

I didn't get the error message I initially got (not a post-install script 
failure), but I can understand if people get scared when seeing:
"system may not be bootable"

I've learned to ignore that warning, which may not be the response
we'd want to teach our users ;-)
I _think_ that even without the "dpkg-reconfigure" call the system would
still boot, but I didn't verify it (at least this time).

Here's the output I got this time, again on a Rock64 device, but another
one with a recent fresh system install:

root@cs21:~# aptitude safe-upgrade
Resolving dependencies...
The following NEW packages will be installed:
  linux-image-5.18.0-3-arm64{a} 
The following packages will be upgraded:
  ... shim-helpers-arm64-signed ...
Preparing to unpack .../22-shim-helpers-arm64-signed_1+15.6+1_arm64.deb ...
Unpacking shim-helpers-arm64-signed (1+15.6+1) over (1+15.4+7) ...
Setting up libdouble-conversion3:arm64 (3.2.0-1) ...
Setting up libapparmor1:arm64 (3.0.5-1) ...
Setting up libnewt0.52:arm64 (0.52.21-5+b2) ...
Setting up apt-utils (2.5.2) ...
Setting up shim-helpers-arm64-signed (1+15.6+1) ...
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot.
grub-install: warning: efivarfs_set_variable: failed to create 
/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c for 
writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: 
Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file 
system.
Failed: grub-install --target=arm64-efi
WARNING: Bootloader is not properly installed, system may not be bootable
...
Setting up linux-image-5.18.0-3-arm64 (5.18.14-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.18.0-2-arm64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.18.0-2-arm64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.18.0-3-arm64
I: /initrd.img is now a symlink to boot/initrd.img-5.18.0-3-arm64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.18.0-3-arm64
W: Possible missing firmware /lib/firmware/rockchip/dptx.bin for module 
rockchipdrm
I: The initramfs will attempt to resume from /dev/sda2
I: (UUID=f9b86b70-965a-4079-948c-02dd4d016680)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.0-3-arm64
Found initrd image: /boot/initrd.img-5.18.0-3-arm64
Found linux image: /boot/vmlinuz-5.18.0-2-arm64
Found initrd image: /boot/initrd.img-5.18.0-2-arm64
Found linux image: /boot/vmlinuz-5.18.0-1-arm64
Found initrd image: /boot/initrd.img-5.18.0-1-arm64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

root@cs21:~# dpkg-reconfigure grub-efi-arm64
Installing for arm64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.0-3-arm64
Found initrd image: /boot/initrd.img-5.18.0-3-arm64
Found linux image: /boot/vmlinuz-5.18.0-2-arm64
Found initrd image: /boot/initrd.img-5.18.0-2-arm64
Found linux image: /boot/vmlinuz-5.18.0-1-arm64
Found initrd image: /boot/initrd.img-5.18.0-1-arm64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done



On Monday, 12 July 2021 04:32:41 CEST Andres Salomon wrote:
> Should this just do a quick test in the postinst to test that efivarfs
> is mounted r/w?  Something quick like:
> 
> db_get grub2/update_nvram || RET=true
> if [ "$RET" = false ]; then
> OPTIONS="$OPTIONS --no-nvram"
> elif [ ! -w /sys/firmware/efi/efivars/ ]; then

root@cs21:~# ls -lh /sys/firmware/efi/
total 0
drwxr-xr-x 2 root root0 Jun 27 22:16 efivars
-r--r--r-- 1 root root 4.0K Jul 26 23:32 fw_platform_size
drwxr-xr-x 2 root root0 Jul 26 23:32 mok-variables
-r 1 root root 4.0K Jul 26 23:32 systab
root@cs21:~# ls -lh /sys/firmware/efi/efivars/
total 0
-rw-r--r-- 1 root root  5 Jun 27 22:16 

Bug#1016092: please enable CONFIG_SENSORS_SHT3x

[Marco d'Itri]

Source: linux
Version: 5.10.127-1
Severity: wishlist

Please enable CONFIG_SENSORS_SHT3x and CONFIG_SENSORS_SHT4x, because 
they are commonly available high quality I2C thermometers used in many 
DIY projects.
At least for armhf/arm64, which is the most common Linux architecture 
used for electronic experimentation.

The SHT15, SHT21 (which is actually enabled) and SHTC1 are much less 
common and probably would not be missed much.

For the same reason I would love to also have available:
CONFIG_SCD30_CORE
CONFIG_SCD4X
CONFIG_SENSIRION_SGP30
CONFIG_SENSIRION_SGP40
CONFIG_SPS30_I2C
CONFIG_SPS30_SERIAL

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1016083: Please package the first few releases of a new major version of Thunderbird in experimental rather than in unstable

[Carsten Schoenert]

Hello Amr,

Am 26.07.22 um 19:28 schrieb Amr Ibrahim:

I'm on Debian testing, and that means that security support is not
guaranteed nor prompt if the package is stuck in unstable for any
reason.


you can quite always install the package from unstable also in testing.

And as you wrote, it's testing, I think it is the nature of testing to 
have versions in testing which might not be fully working at all the 
time. And we need people which are using testing so any serious issue is 
getting detected!



So, in order to mitigate this situation, I kindly request that a new
major version of Thunderbird be packaged in experimental rather than in
unstable. The reason is that: the first few releases of a new major
version are almost always buggy, and that prevents it from migrating to
testing in due time. Later releases can then be packaged in unstable
when it becomes stable enough. In the meantime, new releases of the
current major version can be packaged in unstable and migrate to
testing.

That is the same approach of upstream Thunderbird: they postpone the
upgrade to the new major version for the first few releases until it
become stable.


We do some similar strategy by using the previous ESR version for stable 
and old-stable and providing (if possible and maintainer time permits) 
the most recent ESR version in unstable and testing.


It makes no real sense to me putting recent ESR versions into 
experimental, there is no user base for a broader testing of such versions.


I'm not able to do a packaging of the current versions due some 
traveling, so it might look a bit unfortunate right now. Version 102.1.0 
is ready for preparing and also 19.11.0 within the next days.



Thunderbird version 102.0.3 is only offered as direct download from
thunderbird.net and not as an upgrade from Thunderbird version 91 or
earlier. A future release will provide updates from earlier versions.

https://www.thunderbird.net/en-US/thunderbird/102.0.3/releasenotes/


As written above, users of testing should be aware of the things happen 
in this release part. If you need a stable and always working 
environment than you need to use stable.


--
Regards
Carsten

Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Stephen Dennis]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: tinymux
   Version : 2.12.0.10-1
   Upstream Author : Stephen Dennis 
 * URL : http://www.tinymux.org/
 * License : BSD-3-clause, Artistic-1.0 and TinyMUD-revised
 * Vcs : https://github.com/brazilofmux/tinymux
   Section : games

The source builds the following binary packages:

  tinymux - text-based multi-user virtual world server

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/t/tinymux/tinymux_2.12.0.10-1.dsc

Changes since the last upload:

 tinymux (2.12.0.10-1) unstable; urgency=medium
 .
   * New upstream release
 + fixes ftbfs with GCC-12. (Closes: #1013053)
   * Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
 + Removed build date and number for reproducible build.
   (Closes: #866945)

Regards,

Stephen Dennis

Bug#677836: Fwd: Dzs56

[Raymond N SENA]

-  Warum ignorierst du meine Mails?

Bug#1015730: move more

[Geert Stappers]

Control: tag -1 patch
stop

The "fix me"s needs more TLC

On Tue, Jul 26, 2022 at 10:08:22AM +0200, Zozó Teki wrote:
> Now it says;
>   "NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator 
>All development happens there.
>Also, download new releases & submit issues there."
> 
> 

--- a/debian/control
+++ b/debian/control
@@ -9,9 +9,9 @@ Build-Depends: debhelper-compat (=13), g++ (>=10), automake, 
bison, flex,
  fonts-droid-fallback, fonts-urw-base35,
  fonts-dejavu-core
 Standards-Version: 4.6.1
-Homepage: https://sourceforge.net/projects/msc-generator
-Vcs-Browser: 
https://sourceforge.net/p/msc-generator/gcode/ci/debian/unstable/~/tree/
-Vcs-Git: git://git.code.sf.net/p/msc-generator/gcode -b debian/unstable
+Homepage: https://moved.to.gitlab/fix/me
+Vcs-Browser: https://moved.to.gitlab/fix/me
+Vcs-Git: git://git.code.moved.to.gitlab/fix/me
 Rules-Requires-Root: no
 
 Package: msc-generator

Bug#341952: Fwd: 33xcp

[Raymond N SENA]

-  Warum ignorierst du meine Mails?

Bug#1016090: python-django breaks lots of autopkgtests

[Paul Gevers]

Source: python-django
Control: found -1 python-django/2:4.0.6-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 django-mailman3 django-invitations
Control: affects -1 django-oauth-toolkit django-tables
Control: affects -1 djangorestframework-filters factory-boy
Control: affects -1 python-django-braces python-django-celery-results
Control: affects -1 python-django-dbconn-retry python-django-extensions
Control: affects -1 python-django-extra-views
Control: affects -1 python-django-rest-framework-guardian

Dear maintainer(s),

With a recent upload of python-django the autopkgtest of 
django-mailman3, django-invitations, django-oauth-toolkit, 
django-tables, djangorestframework-filters, factory-boy, 
python-django-braces, python-django-celery-results, 
python-django-dbconn-retry, python-django-extensions, 
python-django-extra-views and python-django-rest-framework-guardian fail 
in testing when that autopkgtest is run with the binary packages of 
python-django from unstable. It passes when run with only packages from 
testing.


I note that the changelog has this:
"This security release mitigates the issue, but we have identified 
improvements to the Database API methods related to date extract and 
truncate that would be beneficial to add to Django 4.1 before it's final 
release. This will impact 3rd party database backends using Django 4.1 
release candidate 1 or newer, until they are able to update to the API 
changes. We apologize for the inconvenience."


I guess that means that these breakages might be intentional, but even 
if all this is to be expected, it would be good to add a *versioned* 
Breaks to python-django3 for all the packages that it really breaks (not 
just the autopkgtest).


Currently this regression is blocking the migration of python-django to 
testing [1].


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016089: mistune: CVE-2022-34749

[Moritz Mühlenhoff]

Source: mistune
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for mistune.

CVE-2022-34749[0]:
| In mistune through 2.0.2, support of inline markup is implemented by
| using regular expressions that can involve a high amount of
| backtracking on certain edge cases. This behavior is commonly named
| catastrophic backtracking.

https://github.com/lepture/mistune/commit/a6d43215132fe4f3d93f8d7e90ba83b16a0838b2

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-34749
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34749

Please adjust the affected versions in the BTS as needed.

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Johannes Schauer Marin Rodrigues]

Quoting Paul Gevers (2022-07-26 22:24:55)
> That worker (ci-worker13) has 7 TB of disk available, so space shouldn't be
> the problem. I'm also not seeing [1] the disk usage anytime higher than 7%
> (and it's actually that /mnt/lxc-containers that's being used and that
> doesn't peak above 1.2% since we changed hosts).

Yes, disk space is not a problem. The failing test is unshare-qemuwrapper which
tests the unshare backend of sbuild. Since neither the salsaci nor the debci
autopkgtest runners allow unsharing the user namespace, the autopkgtest creates
a qemu virtual machine and the test is then run inside of qemu.

Increasing the disk size of that qemu virtual machine is easy but I first want
to confirm that the buildd chroot growing by half a GB is intended and not a
bug that this test found.

signature.asc
Description: signature

Bug#1004629: motion: FTBFS with ffmpeg 5.0

[Dan Bungert]

Dear Maintainer,

I backported the work merged upstream around ffmpeg 5.  Please see attached.
This was sufficient to address the FTBFS both for Sid and Ubuntu Kinetic.

-Dan
Description: Backport ffmpeg 5 fixes.
Author:  Dan Bungert 
Origin:  https://github.com/Motion-Project/motion/pull/1351/commits/fc9ed24c467006a463684f7db2f760a61f1eebe0
Bug-Ubuntu:  https://bugs.launchpad.net/bugs/1982886
Bug-Debian:  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004629
Forwarded:   not-needed
Last-Update: 2022-07-26
--- a/src/ffmpeg.c
+++ b/src/ffmpeg.c
@@ -340,7 +340,7 @@
 
 if (ffmpeg->tlapse == TIMELAPSE_APPEND){
 ffmpeg->oc->oformat = av_guess_format ("mpeg2video", NULL, NULL);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_MPEG2VIDEO;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_MPEG2VIDEO;
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mpg",basename);
 if ((!ffmpeg->oc->oformat) ||
 (retcd < 0) || (retcd >= PATH_MAX)){
@@ -362,7 +362,7 @@
 if (strcmp(codec_name, "msmpeg4") == 0) {
 ffmpeg->oc->oformat = av_guess_format("avi", NULL, NULL);
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.avi",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_MSMPEG4V2;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_MSMPEG4V2;
 }
 
 if (strcmp(codec_name, "swf") == 0) {
@@ -373,13 +373,13 @@
 if (strcmp(codec_name, "flv") == 0) {
 ffmpeg->oc->oformat = av_guess_format("flv", NULL, NULL);
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.flv",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_FLV1;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_FLV1;
 }
 
 if (strcmp(codec_name, "ffv1") == 0) {
 ffmpeg->oc->oformat = av_guess_format("avi", NULL, NULL);
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.avi",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_FFV1;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_FFV1;
 }
 
 if (strcmp(codec_name, "mov") == 0) {
@@ -390,19 +390,19 @@
 if (strcmp(codec_name, "mp4") == 0) {
 ffmpeg->oc->oformat = av_guess_format("mp4", NULL, NULL);
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mp4",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_H264;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_H264;
 }
 
 if (strcmp(codec_name, "mkv") == 0) {
 ffmpeg->oc->oformat = av_guess_format("matroska", NULL, NULL);
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mkv",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_H264;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_H264;
 }
 
 if (strcmp(codec_name, "hevc") == 0) {
 ffmpeg->oc->oformat = av_guess_format("mp4", NULL, NULL);
 retcd = snprintf(ffmpeg->filename,PATH_MAX,"%s.mp4",basename);
-if (ffmpeg->oc->oformat) ffmpeg->oc->oformat->video_codec = MY_CODEC_ID_HEVC;
+if (ffmpeg->oc->oformat) ffmpeg->oc->video_codec_id = MY_CODEC_ID_HEVC;
 }
 
 //Check for valid results
@@ -422,7 +422,7 @@
 return -1;
 }
 
-if (ffmpeg->oc->oformat->video_codec == MY_CODEC_ID_NONE) {
+if (ffmpeg->oc->video_codec_id == MY_CODEC_ID_NONE) {
 MOTION_LOG(ERR, TYPE_ENCODER, NO_ERRNO, _("Could not get the codec"));
 ffmpeg_free_context(ffmpeg);
 free(codec_name);
@@ -721,7 +721,7 @@
 } else {
 ffmpeg->codec = avcodec_find_encoder_by_name(>codec_name[codec_name_len+1]);
 if ((ffmpeg->oc->oformat) && (ffmpeg->codec != NULL)) {
-ffmpeg->oc->oformat->video_codec = ffmpeg->codec->id;
+ffmpeg->oc->video_codec_id = ffmpeg->codec->id;
 } else if (ffmpeg->codec == NULL) {
 MOTION_LOG(WRN, TYPE_ENCODER, NO_ERRNO
 ,_("Preferred codec %s not found")
@@ -730,7 +730,7 @@
 }
 }
 if (!ffmpeg->codec)
-ffmpeg->codec = avcodec_find_encoder(ffmpeg->oc->oformat->video_codec);
+ffmpeg->codec = avcodec_find_encoder(ffmpeg->oc->video_codec_id);
 if (!ffmpeg->codec) {
 MOTION_LOG(ERR, TYPE_ENCODER, NO_ERRNO
 ,_("Codec %s not found"), ffmpeg->codec_name);
@@ -818,7 +818,7 @@
 }
 }
 
-ffmpeg->ctx_codec->codec_id  = ffmpeg->oc->oformat->video_codec;
+ffmpeg->ctx_codec->codec_id  = ffmpeg->oc->video_codec_id;
 ffmpeg->ctx_codec->codec_type= AVMEDIA_TYPE_VIDEO;
 ffmpeg->ctx_codec->bit_rate  = ffmpeg->bps;
 ffmpeg->ctx_codec->width = ffmpeg->width;
@@ -1320,7 +1320,7 @@
 
 #if (LIBAVFORMAT_VERSION_MAJOR >= 58) || 

Bug#1016074: UDD/lintian: please add search option to filter by lintian tags

[Lucas Nussbaum]

Hi,

On 26/07/22 at 11:11 -0400, Louis-Philippe Véronneau wrote:
> Package: qa.debian.org
> User: qa.debian@packages.debian.org
> Usertags: udd
> Severity: wishlist
> 
> Hi,
> 
> It would be really nice if the lintian web page for UDD let you filter
> by lintian tags.
> 
> This way, it would be easier to do QA work on some things that are
> flagged by lintian :)

So I thought about that, and there are several possible workarounds:

1/ add some client-side filtering of the results table using javascript
(I would welcome a patch for that, my js is rusty)

2/ use the JSON output, then post-process locally

3/ do SQL directly. the page has a secret =1 parameter that shows
the SQL it's doing, which can be helpful.

All those workarounds are sufficiently good that I don't plan to provide
server-side support for filtering by tag (and/or 'information').

Lucas

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Paul Gevers]

Hi,

On 26-07-2022 13:28, Luca Boccassi wrote:

The autopkgtest run for sbuild keeps failing in debci, blocking other
packages migrations. The failure manifests in two different error
types, but both related to "No space left on device" when running
mmdebstrap.

This seems to have started on July the 22nd. List of recent failures:

https://ci.debian.net/packages/s/sbuild/testing/amd64/

Eg:

https://ci.debian.net/data/autopkgtest/unstable/amd64/s/sbuild/23951901/log.gz

+ mmdebstrap --mode=unshare --variant=apt unstable /tmp/chroot.tar
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.1Pi2WSLk6H as tempdir
I: running apt-get update...
I: downloading packages with apt...
I: extracting archives...
I: installing essential packages...
Selecting previously unselected package gcc-12-base:amd64.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../gcc-12-base_12.1.0-7_amd64.deb ...
Unpacking gcc-12-base:amd64 (12.1.0-7) ...
Selecting previously unselected package libc6:amd64.
Preparing to unpack .../libc6_2.33-8_amd64.deb ...
Use of uninitialized value in concatenation (.) or string at 
/usr/share/perl5/Debconf/Config.pm line 22.
Unpacking libc6:amd64 (2.33-8) ...
dpkg: error processing archive /var/cache/apt/archives/libc6_2.33-8_amd64.deb 
(--install):
  cannot copy extracted data for './usr/lib/x86_64-linux-gnu/gconv/IBM904.so' 
to '/usr/lib/x86_64-linux-gnu/gconv/IBM904.so.dpkg-new': failed to write (No 
space left on device)


That worker (ci-worker13) has 7 TB of disk available, so space shouldn't 
be the problem. I'm also not seeing [1] the disk usage anytime higher 
than 7% (and it's actually that /mnt/lxc-containers that's being used 
and that doesn't peak above 1.2% since we changed hosts).


Paul

[1] https://ci.debian.net/munin/ci-worker13/ci-worker13/df.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016059: DDPO,Package Tracking System: move to UDD as a data source for lintian?

[Mattia Rizzolo]

On Tue, Jul 26, 2022 at 09:50:50PM +0200, Lucas Nussbaum wrote:
> On 26/07/22 at 17:24 +0200, Mattia Rizzolo wrote:
> > > https://udd.debian.org/lintian/?dpkg , which DDPO and PTS could use as a
> > > link target.
> > 
> > Probably, I'll keep it for the future for now.
> > However, may I suggest you make it use a proper querystring instead?
> > Like, ?pkg=dpkg, so that it'll be extensible in the future if one wants.
> 
> https://udd.debian.org/lintian/?packages=dpkg also works

Great, so I'll go with that!

> Regarding your comment on IRC:
> > btw, I consider udd.d.o/lintian/ slow, IMHO.  if you could see if some 
> > tuning could be done, that would likely be appreciated.
> 
> The postgresql optimizer was doing something strange with a temporary
> table. Fixed.

Much better, thank you!

> Also, this looks wrong:
> https://salsa.debian.org/qa/qa/-/commit/6eb803b9965a1d97b2dd5eed4da22fc69124d3f0#cbc3b83fa697117813ee1ea10081d209b6d42d4f_1080_1079
> (missing '?' before the source package name)

And thank you for spotting this as well… :|

I manually deployed the change, and it looks good to me now ;)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1016088: binutils-multiarch-dev: libbfd and friends not available for multiarch development

[Mark Brown]

Package: binutils-multiarch-dev
Version: 2.35.2-2
Severity: normal

Attempting to build a program linking against libbfd (such as perf) for
a non-native architecture is not supported in a multiarch environment,
binutils-multarch-dev does not provide the libraries and attempting to
install the multiarch version will remove the native version:

| The following additional packages will be installed:
|   binutils:arm64 binutils-aarch64-linux-gnu:arm64 binutils-common:arm64
|   libbinutils:arm64 libctf-nobfd0:arm64 libctf0:arm64
| Suggested packages:
|   binutils-doc:arm64
| The following packages will be REMOVED:
|   binutils binutils-aarch64-linux-gnu binutils-dev binutils-multiarch
|   binutils-multiarch-dev clang-15 gcc-10 gcc-10-aarch64-linux-gnu
|   gcc-aarch64-linux-gnu
| The following NEW packages will be installed:
|   binutils:arm64 binutils-aarch64-linux-gnu:arm64 binutils-common:arm64
|   binutils-dev:arm64 libbinutils:arm64 libctf-nobfd0:arm64 libctf0:arm64

This causes issues with for example perf.

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

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

Versions of packages binutils-multiarch-dev depends on:
pn  binutils-dev
ii  binutils-multiarch  2.35.2-2

binutils-multiarch-dev recommends no packages.

binutils-multiarch-dev suggests no packages.

-- no debconf information

Bug#1016059: DDPO,Package Tracking System: move to UDD as a data source for lintian?

[Lucas Nussbaum]

On 26/07/22 at 17:24 +0200, Mattia Rizzolo wrote:
> > https://udd.debian.org/lintian/?dpkg , which DDPO and PTS could use as a
> > link target.
> 
> Probably, I'll keep it for the future for now.
> However, may I suggest you make it use a proper querystring instead?
> Like, ?pkg=dpkg, so that it'll be extensible in the future if one wants.

https://udd.debian.org/lintian/?packages=dpkg also works

Regarding your comment on IRC:
> btw, I consider udd.d.o/lintian/ slow, IMHO.  if you could see if some tuning 
> could be done, that would likely be appreciated.

The postgresql optimizer was doing something strange with a temporary
table. Fixed.

Also, this looks wrong:
https://salsa.debian.org/qa/qa/-/commit/6eb803b9965a1d97b2dd5eed4da22fc69124d3f0#cbc3b83fa697117813ee1ea10081d209b6d42d4f_1080_1079
(missing '?' before the source package name)

Lucas

Bug#31477: #31477 lynx: bookmark file is relative to home dir

[Thomas Dickey]

The documentation was updated in 2.8.2dev.4, to state

.h2 DEFAULT_BOOKMARK_FILE
# DEFAULT_BOOKMARK_FILE is the filename used for storing personal 
bookmarks.
# It will be prepended by the user's home directory.
# NOTE that a file ending in .html or other suffix mapped to text/html
# should be used to ensure its treatment as HTML.  The built-in default
# is lynx_bookmarks.html.  On both Unix and VMS, if a subdirectory off 
of
# the HOME directory is desired, the path should begin with "./" (e.g.,
# ./BM/lynx_bookmarks.html), but the subdirectory must already exist.
# Lynx will create the bookmark file, if it does not already exist, on
# the first ADD_BOOKMARK attempt if the HOME directory is indicated
# (i.e., if the definition is just filename.html without any slashes),
# but requires a pre-existing subdirectory to create the file there.
# The user can re-define the default bookmark file, as well as a set
# of sub-bookmark files if multiple bookmark file support is enabled
# (see below), via the 'o'ptions menu, and can save those definitions
# in the .lynxrc file.
#
#DEFAULT_BOOKMARK_FILE:lynx_bookmarks.html

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1016087: dpkg: errors about cannot verify signature fpr assorted packages

[Tim McConnell]

Package: dpkg
Version: 1.21.9
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

What led up to the situation? Normal upgrading of system

What exactly did you do (or not do) that was effective (or ineffective)? Unsure
these messages started appearing.

What was the outcome of this action? I now receive multiple lines of: gpgv:
Signature made Fri 24 Oct 2014 06:23:17 PM CDT
gpgv:using RSA key F664D256B4691A7D
gpgv: Can't check signature: No public key
dpkg-source: warning: cannot verify signature
/var/cache/apt/sources/libtrio_1.16+dfsg1-3.dsc
gpgv: Signature made Tue 03 May 2022 09:04:38 PM CDT
gpgv:using RSA key A1489FE2AB99A21A
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
quantreg_5.93-1.dsc
gpgv: Signature made Wed 20 Jul 2022 05:25:03 AM CDT
gpgv:using RSA key A1489FE2AB99A21A
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
quantreg_5.94-1.dsc
apt-listdifferences: removing old src:r-cran-quantreg 5.93-1
gpgv: Signature made Fri 27 May 2022 04:42:52 AM CDT
gpgv:using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature
/var/cache/apt/sources/kconfig_5.94.0-3.dsc
gpgv: Signature made Sat 23 Jul 2022 05:20:34 AM CDT
gpgv:using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature
/var/cache/apt/sources/kconfig_5.94.0-4.dsc

When running this command `apt-get dist-upgrade -y -m`

What outcome did you expect instead? To be sure I'm getting packages from an
uncompromised repo.


-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/1 CPU thread; 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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-8
ii  liblzma5 5.2.5-2.1
ii  libselinux1  3.4-1+b1
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-4

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.5.1
ii  debsig-verify  0.25+b1

-- no debconf information

Bug#1012096: RFS: tractor/3.14-1 [ITP] -- Setup an onion routing proxy

[Bastian Germann]

Am 26.07.22 um 20:56 schrieb دانیال بهزادی:
I targeted it to experimental and reuploaded the package. What are the instructions for publishing it to unstable and 
testing?


No specific instruction for unstable; just replace experimental with unstable. You do not publish to testing. The 
package will automatically migrate to testing once it is in unstable and checks all migration boxes.

Bug#1012096: RFS: tractor/3.14-1 [ITP] -- Setup an onion routing proxy

[دانیال بهزادی]

Control: tags -1 - moreinfo

I targeted it to experimental and reuploaded the package. What are the 
instructions for publishing it to unstable and testing?

در 26 ژوئیهٔ 2022 16:32:41 (UTC)، Bastian Germann  نوشت:
>Control: tags -1 moreinfo
>
>On Mon, 25 Jul 2022 13:58:36 +0430  wrote:
>> OK, I removed the 3.13-1 and closed the ITP in 3.14-1 instead.
>> Danial Behzadi
>
>But now you target UNRELEASED. You have to target unstable or experimental 
>with an ITP.
>

Bug#1016085: libqt5network5: depends on libssl3 but loads (wrong) file provided by libssl-dev instead

[Lionel Elie Mamane]

Package: libqt5network5
Version: 5.15.4+dfsg-4
Severity: serious
Justification: Policy 3.5

I have libssl 3.0.4-2 (satisfying the dependency of libqt5network5),
but libssl-dev 1.1.1n-0+deb11u3.

Starting QT applications gets on stdout/stderr stuff like

07-26 20:08:33:071 [ warning qt.network.ssl ]:  QSslSocket: cannot resolve 
SSL_get1_peer_certificate
07-26 20:08:33:071 [ warning qt.network.ssl ]:  QSslSocket: cannot resolve 
EVP_PKEY_get_base_id
07-26 20:08:33:071 [ warning qt.network.ssl ]:  QSslSocket: cannot resolve 
SSL_CTX_load_verify_dir
07-26 20:08:46:405 [ warning qt.network.ssl ]:  QSslSocket: cannot call 
unresolved function SSL_CTX_load_verify_dir
07-26 20:08:46:405 [ warning qt.network.ssl ]:  An error encountered while to 
set root certificates location: ""
07-26 20:08:46:409 [ warning qt.network.ssl ]:  QSslSocket: cannot call 
unresolved function SSL_get1_peer_certificate
07-26 20:08:46:409 [ warning qt.network.ssl ]:  QSslSocket: cannot call 
unresolved function SSL_get1_peer_certificate

and then the application fails to recognise any certificate as valid,
since it doesn't recognise any root CA.

An strace shows that it loads (my guess if with dlopen())
/usr/lib/x86_64-linux-gnu/libssl.so

That file is _not_ provided by _any_ direct or indirect dependency of
libqt5network5 but by libssl-dev.

So from a policy standpoint:

 * libqt5network5 _must_ _not_ require that file to function since it
   does not depend on libssl-dev; formally that is fulfilled since it
   will fallback to libssl.so.3 when libssl.so is not found.

 * libqt5network5 _must_ _not_ be broken by the presence of any
   particular version of that file since it does not conflict with any
   particular version of libssl-dev; that is the policy requirement
   that is not fulfilled.


In my opinion the best solution is to _never_ dlopen("libssl.so"), but
only every dlopen("libssl.so.3") since that is the ABI that you
expect, and what the package depends on.

>From a policy standpoint, it would also be acceptable (as in non-RC
buggy) to instead conflict on any version of libssl-dev that one is
not compatible with, but IMO that would be a pity.


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libqt5network5 depends on:
ii  libc6 2.33-8
ii  libgssapi-krb5-2  1.18.3-6+deb11u1
ii  libqt5core5a [qtbase-abi-5-15-4]  5.15.4+dfsg-4
ii  libqt5dbus5   5.15.4+dfsg-4
ii  libssl3   3.0.4-2
ii  libstdc++612.1.0-7
ii  zlib1g1:1.2.11.dfsg-2+deb11u1

libqt5network5 recommends no packages.

libqt5network5 suggests no packages.

-- no debconf information

-- 
Lionel Mamane
Tél: +352 46 67 74
Fax: +352 46 67 76

This message and any attachments may be intended to be confidential,
intended solely for the addressee and/or contain legally privileged
information. Any unauthorised use or dissemination is prohibited.
Unless cryptographically protected, emails are susceptible to
interception, alteration and spoofing, so in case of doubt, please
check by independent means.

We do not make any commitment by email, ever; if this emails appears
to contain a commitment, we will not recognise the latter as valid,
nor as engaging our liability. We make commitments only by a written
paper document signed by at least one person entitled to engage our
liability.

Bug#1016084: transition: petsc

[Drew Parsons]

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

I'd like to proceed with the next upgrade of the numerical library
stack*.

superlu-dist   7.2.0 -> 8.1.0
hypre  2.23.0 -> 2.25.0
mumps  5.4.1 -> 5.5.0
petsc  3.16 -> 3.17
slepc  3.16 -> 3.17
with petsc4py, slepc4py


I've checked reverse dependencies build.
They had a couple of problems evidently not related to this transition
  - siconos had some problem with source
  - freefem++ required parmetis (not declared in Build-Depends)

Other dependent packages built fine.


auto-transitions are already created

https://release.debian.org/transitions/html/auto-superlu-dist.html
https://release.debian.org/transitions/html/auto-hypre.html
https://release.debian.org/transitions/html/auto-mumps.html
https://release.debian.org/transitions/html/auto-petsc.html
https://release.debian.org/transitions/html/auto-slepc.html
https://release.debian.org/transitions/html/auto-petsc4py.html


* not upgrading trilinos. Others are managing trilinos.

Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Raphael Hertzog]

Control: tags -1 + patch
Control: user de...@kali.org
Control: usertags -1 + kali-patch

On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois  wrote:
> I suppose the journal bits could be patched out for the udeb build (right
> now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
> I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
> could have for arrays built at installation time (the function call itself
> is already guarded within an #ifdef/#endif block, so it seems somewhat
> optional already).

I confirm that a build with this patch gets rid of the libsystemd0
dependency in the udeb:

diff --git a/debian/rules b/debian/rules
index f1a9df9bd..bef9b2df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -71,6 +71,8 @@ define CONFARGS.udeb
--with-pool=none
--disable-readline
--disable-selinux
+   --disable-app-machineid
+   --disable-systemd-journal
 endef
 
 BUILDS :=

I looked up the impact of --disable-app-machineid and I concluded that it
should be safe to use it even if the non-udeb build has it enabled.

The option only adds a supplementary source (named "appmachineid") for lvm
to get a "system_id". The DEFAULT_SYSTEM_ID_SOURCE is "none" and it's not
overriden by what we ship as Debian configuration files. Given that it was
non-existent up-to-now, we can be pretty sure that d-i is not overriding
the lvm configuration to set global/system_id_source to "appmachineid".

man lvmsystemid has some explanation about the feature related to
"systemid" and from a quick check on my system, it looks like that
VG created by d-i do not set any system id.

Bastian, do you agree with the above assessment? If yes, can you upload
a fixed package please?

Cheers,
-- 
Raphaël Hertzog

Bug#1016083: Please package the first few releases of a new major version of Thunderbird in experimental rather than in unstable

[Amr Ibrahim]

Package: thunderbird

Hallo Carsten,

This is more of a request than a bug report.

I'm on Debian testing, and that means that security support is not
guaranteed nor prompt if the package is stuck in unstable for any
reason.

So, in order to mitigate this situation, I kindly request that a new
major version of Thunderbird be packaged in experimental rather than in
unstable. The reason is that: the first few releases of a new major
version are almost always buggy, and that prevents it from migrating to
testing in due time. Later releases can then be packaged in unstable
when it becomes stable enough. In the meantime, new releases of the
current major version can be packaged in unstable and migrate to
testing.

That is the same approach of upstream Thunderbird: they postpone the
upgrade to the new major version for the first few releases until it
become stable.

> Thunderbird version 102.0.3 is only offered as direct download from
> thunderbird.net and not as an upgrade from Thunderbird version 91 or
> earlier. A future release will provide updates from earlier versions.
https://www.thunderbird.net/en-US/thunderbird/102.0.3/releasenotes/

Best,
Amr

Bug#1016082: RFP: authenticator -- Generate Two-Factor Codes

[Guido Günther]

Package: wnpp
Severity: wishlist

* Package name: authenticator
  Version : 4.1.6
  Upstream Author : Bilal Elmoussaoui
* URL : https://gitlab.gnome.org/World/Authenticator
* License : GPL
  Programming Lang: Rust
  Description : Generate Two-Factor Codes

This is the successor of gnome-authenticator (packaged in Debian) by the
same author but rewritten in Rust. Hence i filed wnpp instead of "new
upstream version".

Looking at

   https://gitlab.gnome.org/World/Authenticator/-/blob/master/Cargo.toml

we're currently lacking zbar and a few other crates which would need to
go in first.

As authenticator is pretty generic maybe gw-authenticator (as it's part
of /GNOME/World) would be an appropriate executable name? Otherwise
replacing gnome-authenticator would likely work too.

I don't have immediate plans to work on it but would join a packaging
effort as there's more rust based GNOME related projects which would be
great to have.

Cheers,
 -- Guido

Bug#1016080: buster-pu: package libreoffice/:6.1.5-3+deb10u8

[Rene Engelhard]

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

Hi,

actually this is quite a small update for a big package. Should we
really do it (and the default change)? Or should we assume people don't
use LO from oldstable anymore and either use bullseye or the bullseye
version backported to buster?

Filing for completeness' sake, though.

[ Reason ]
Croatia will join the Eurozone on 2023-01-01. I think we should
prepare.
TODO: After (or shortly before) 2023-01-01 we then can do a point
release update to switch the default...

[ Impact ]
EUR isn't supported in .hr locale

[ Tests ]
None, ttbomk.

[ Risks ]
None. trivial, and doesn't yet affect the default

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

This is not yet fixed in unstable, that will happen with the upload of
7.4.0 rc2 (or someting later) to it

[ Changes ]
See above. I just added the verbatim upstream commits.

Debdiff:
$ export TMPDIR=~/tmp; debdiff libreoffice_6.1.5-3+deb10u7.dsc 
libreoffice_6.1.5-3+deb10u8.dsc 
dpkg-source: Warnung: unsigniertes Quellpaket wird extrahiert 
(/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice_6.1.5-3+deb10u8.dsc)
diff -Nru libreoffice-6.1.5/debian/changelog libreoffice-6.1.5/debian/changelog
--- libreoffice-6.1.5/debian/changelog  2021-03-08 13:13:24.0 +0100
+++ libreoffice-6.1.5/debian/changelog  2022-07-26 18:54:43.0 +0200
@@ -1,3 +1,10 @@
+libreoffice (1:6.1.5-3+deb10u8) buster; urgency=medium
+
+  * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+
+ -- Rene Engelhard   Tue, 26 Jul 2022 18:54:43 +0200
+
 libreoffice (1:6.1.5-3+deb10u7) buster; urgency=medium
 
   * debian/patches/fix-PYTHONPATH.diff: backport upstream fix to
diff -Nru libreoffice-6.1.5/debian/patches/hrk-euro.diff 
libreoffice-6.1.5/debian/patches/hrk-euro.diff
--- libreoffice-6.1.5/debian/patches/hrk-euro.diff  1970-01-01 
01:00:00.0 +0100
+++ libreoffice-6.1.5/debian/patches/hrk-euro.diff  2022-07-26 
18:54:22.0 +0200
@@ -0,0 +1,156 @@
+From 7c4b2db21ef77b37daf234ac1ab9989234606a22 Mon Sep 17 00:00:00 2001
+From: Eike Rathke 
+Date: Fri, 22 Jul 2022 22:12:02 +0200
+Subject: Resolves: tdf#150011 Add HRK Croatian Kuna conversion to EUR Euro
+
+TODO: switch defaults before 2023-01-01 in
+i18npool/source/localedata/data/hr_HR.xml
+
+Change-Id: Ifc62aefbc8c9fe8bbf044f61ae4fd6eeff692185
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137371
+Reviewed-by: Eike Rathke 
+Tested-by: Jenkins
+---
+ i18npool/source/localedata/data/hr_HR.xml  |  8 
+ officecfg/registry/data/org/openoffice/Office/Calc.xcu | 11 +++
+ sc/source/core/tool/interpr2.cxx   |  3 ++-
+ 3 files changed, 21 insertions(+), 1 deletion(-)
+
+diff --git a/i18npool/source/localedata/data/hr_HR.xml 
b/i18npool/source/localedata/data/hr_HR.xml
+index 0c493131e16b..4de83e5535cd 100644
+--- a/i18npool/source/localedata/data/hr_HR.xml
 b/i18npool/source/localedata/data/hr_HR.xml
+@@ -421,6 +421,14 @@
+   Hrvatska Kuna
+   2
+ 
++
++
++  EUR
++  €
++  EUR
++  Euro
++  2
++
+   
+   
+ 
+diff --git a/officecfg/registry/data/org/openoffice/Office/Calc.xcu 
b/officecfg/registry/data/org/openoffice/Office/Calc.xcu
+index a62d06512704..eda60fe6c434 100644
+--- a/officecfg/registry/data/org/openoffice/Office/Calc.xcu
 b/officecfg/registry/data/org/openoffice/Office/Calc.xcu
+@@ -228,6 +228,17 @@
+ 3.45280
+   
+ 
++
++  
++EUR
++  
++  
++HRK
++  
++  
++7.53450
++  
++
+   
+   
+ 
+diff --git a/sc/source/core/tool/interpr2.cxx 
b/sc/source/core/tool/interpr2.cxx
+index 31c42a4b728a..67fcd9f787f8 100644
+--- a/sc/source/core/tool/interpr2.cxx
 b/sc/source/core/tool/interpr2.cxx
+@@ -3235,7 +3235,8 @@ static bool lclConvertMoney( const OUString& 
aSearchUnit, double& rfRate, int& r
+ { "SKK", 30.1260,  2 },
+ { "EEK", 15.6466,  2 },
+ { "LVL", 0.702804, 2 },
+-{ "LTL", 3.45280,  2 }
++{ "LTL", 3.45280,  2 },
++{ "HRK", 7.53450,  2 }
+ };
+ 
+ for (const auto & i : aConvertTable)
+-- 
+cgit v1.2.1
+
+From b1a2f727ca99ecd3402d4b051b99cbfd24266e59 Mon Sep 17 00:00:00 2001
+From: Eike Rathke 
+Date: Fri, 22 Jul 2022 22:17:11 +0200
+Subject: Related: tdf#150011 Add HRK Croatian Kuna to Euro conversion wizard
+
+Maybe just for completeness, it's removed from menu but might be
+callable as macro.
+
+Change-Id: Iade0be845186d3deb2f00f4aaa230c0b344cea72
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137372
+Reviewed-by: Eike Rathke 
+Tested-by: Jenkins
+---
+ wizards/source/euro/Init.xba 

Bug#1016081: elpa-magit: Magit saves wrong buffers for remote repository

[Toby Speight]

Package: elpa-magit
Version: 3.3.0-1
Severity: normal
Tags: patch
X-Debbugs-Cc: Toby Speight 
File: /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-mode.el

When working remotely over SSH, I find that Magit offers to save only
local files, rather than the ones on the host where Git is running.

The problem stems from `magit-save-repository-buffers', which begins
around line 1208:

/
|   (when-let ((topdir (magit-rev-parse-safe "--show-toplevel")))
| (let ((remote (file-remote-p topdir))
\

`topdir' is the output from "git rev-parse --show-toplevel", which is a
pathname _on the remote machine_, without any adornment.  So `remote' is
always nil, even for such a repository.

I get the desired behavour if I make the following changes, which could
be a candidate for upstream:

--- /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-mode.el	2022-07-26 08:58:43.534569844 +0100
+++ /usr/share/emacs/site-lisp/elpa-src/magit-3.3.0/magit-mode.el	2022-07-26 08:58:43.534569844 +0100
@@ -1206,7 +1206,7 @@
 argument (the prefix) non-nil means save all with no questions."
   (interactive "P")
   (when-let ((topdir (magit-rev-parse-safe "--show-toplevel")))
-(let ((remote (file-remote-p topdir))
+(let ((remote (file-remote-p default-directory))
   (save-some-buffers-action-alist
`((?Y (lambda (buffer)
(with-current-buffer buffer
@@ -1229,7 +1229,7 @@
   ;; therefore has to come after the above to avoid
   ;; unnecessarily waiting for unrelated hosts.
   (file-exists-p (file-name-directory buffer-file-name))
-  (string-prefix-p topdir (file-truename buffer-file-name))
+  (string-prefix-p topdir (file-local-name (file-truename buffer-file-name)))
   (equal (magit-rev-parse-safe "--show-toplevel")
  topdir)))
 

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

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

Versions of packages elpa-magit depends on:
ii  dh-elpa-helper  2.0.10
ii  elpa-dash   2.19.1+dfsg-1
ii  elpa-git-commit 3.3.0-1
ii  elpa-magit-section  3.3.0-1
ii  elpa-transient  0.3.7-1
ii  elpa-with-editor3.0.5-1
ii  emacsen-common  3.0.4
ii  git 1:2.35.1-1

elpa-magit recommends no packages.

elpa-magit suggests no packages.

-- no debconf information

Bug#1012096: RFS: tractor/3.14-1 [ITP] -- Setup an onion routing proxy

[Bastian Germann]

Control: tags -1 moreinfo

On Mon, 25 Jul 2022 13:58:36 +0430  wrote:

OK, I removed the 3.13-1 and closed the ITP in 3.14-1 instead.
Danial Behzadi


But now you target UNRELEASED. You have to target unstable or experimental with 
an ITP.

Bug#1016079: 10 minutes after boot ibus-daemonspikes to 100% CPU usage and stays there forever

[David Michael Smith]

Package: ibus
Version: 1.5.26-4
Severity: normal
File: /usr/bin/ibus-daemon
X-Debbugs-Cc: sidic...@gmail.com

About 10 minutes after boot, ibus-daemon takes 100% cpu usage and stays there
forever. Burning up my battery life and slowing down the system.
If I manually kill it then the problem immediately goes away. Even if I close
down Anthy / IME after login the problem still happens.

For the input methods configured in ibus-setup, I have "English - English (US)"
and "Japanese - Anthy"

Was not having this issue on Debian oldstable / buster.

Currently using LXDE / Openbox.

Not really sure how to troubleshoot a 100% CPU usage ibus-daemon problem.



-- Package-specific info:
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l =>  ibus fcitx xim kinput2
im-config -m => 'default' 'ibus' 'ibus' '' 'ibus'

XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
WAYLAND_DISPLAY=
XDG_CURRENT_DESKTOP=LXDE
XDG_MENU_PREFIX=lxde-
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=LXDE
XDG_SESSION_ID=298
XDG_SESSION_TYPE=x11

== ls -l /usr/lib/ibus/ibus-* /usr/libexec/ibus-* ==
/bin/ls: cannot access '/usr/lib/ibus/ibus-*': No such file or directory
-rwxr-xr-x 1 root root  22832 Apr 10 07:16 /usr/libexec/ibus-dconf
-rwxr-xr-x 1 root root   1119 Jan  1  2022 /usr/libexec/ibus-engine-anthy
-rwxr-xr-x 1 root root  14640 Apr 10 07:16 /usr/libexec/ibus-engine-simple
-rwxr-xr-x 1 root root 166192 Apr 10 07:16 /usr/libexec/ibus-extension-gtk3
-rwxr-xr-x 1 root root  18736 Apr 10 07:16 /usr/libexec/ibus-memconf
-rwxr-xr-x 1 root root  92464 Apr 10 07:16 /usr/libexec/ibus-portal
-rwxr-xr-x 1 root root   1053 Jan  1  2022 /usr/libexec/ibus-setup-anthy
-rwxr-xr-x 1 root root 121144 Apr 10 07:16 /usr/libexec/ibus-ui-emojier
-rwxr-xr-x 1 root root 321904 Apr 10 07:16 /usr/libexec/ibus-ui-gtk3
-rwxr-xr-x 1 root root 100280 Apr 10 07:16 /usr/libexec/ibus-x11

== dpkg-query -l 'ibus*' ==
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--===
ii  ibus   1.5.26-4   amd64Intelligent 
Input Bus - core
ii  ibus-anthy 1.5.14-1   amd64anthy engine for 
IBus
un  ibus-array (no description 
available)
ii  ibus-clutter:amd64 0.0+git20090728.a936bacf-7 amd64ibus input 
method framework for clutter
ii  ibus-data  1.5.26-4   all  Intelligent 
Input Bus - data files
un  ibus-doc   (no description 
available)
un  ibus-el(no description 
available)
un  ibus-googlepinyin  (no description 
available)
ii  ibus-gtk:amd64 1.5.26-4   amd64Intelligent 
Input Bus - GTK2 support
ii  ibus-gtk3:amd641.5.26-4   amd64Intelligent 
Input Bus - GTK3 support
ii  ibus-gtk4:amd641.5.26-4   amd64Intelligent 
Input Bus - GTK4 support
un  ibus-pinyin(no description 
available)

=== gsettings ===
org.freedesktop.ibus.general dconf-preserve-name-prefixes 
['/desktop/ibus/engine/pinyin', '/desktop/ibus/engine/bopomofo', 
'/desktop/ibus/engine/hangul']
org.freedesktop.ibus.general embed-preedit-text true
org.freedesktop.ibus.general enable-by-default false
org.freedesktop.ibus.general engines-order ['anthy', 'xkb:us::eng']
org.freedesktop.ibus.general preload-engines ['xkb:us::eng', 'anthy']
org.freedesktop.ibus.general switcher-delay-time 400
org.freedesktop.ibus.general use-global-engine true
org.freedesktop.ibus.general use-system-keyboard-layout false
org.freedesktop.ibus.general use-xmodmap true
org.freedesktop.ibus.general version '1.5.26'
org.freedesktop.ibus.general xkb-latin-layouts ['ara', 'bg', 'cz', 'dev', 'gr', 
'gur', 'in', 'jp(kana)', 'mal', 'mkd', 'ru', 'ua']
org.freedesktop.ibus.general.hotkey disable-unconditional @as []
org.freedesktop.ibus.general.hotkey enable-unconditional @as []
org.freedesktop.ibus.general.hotkey next-engine ['Alt+Shift_L']
org.freedesktop.ibus.general.hotkey next-engine-in-menu ['Alt+Shift_L']
org.freedesktop.ibus.general.hotkey prev-engine @as []
org.freedesktop.ibus.general.hotkey previous-engine @as []
org.freedesktop.ibus.general.hotkey trigger ['Control+space', 
'Zenkaku_Hankaku', 'Alt+Kanji', 'Alt+grave', 'Hangul', 'Alt+Release+Alt_R']
org.freedesktop.ibus.general.hotkey triggers ['space']
org.freedesktop.ibus.panel auto-hide-timeout 1
org.freedesktop.ibus.panel custom-font 'Sans 10'
org.freedesktop.ibus.panel follow-input-cursor-when-always-shown false
org.freedesktop.ibus.panel lookup-table-orientation 1

Bug#1016078: RFP: fff -- micro-framework for creating fake C functions for tests

[Bastian Germann]

Package: wnpp
Severity: wishlist

* Package name: fff
  Upstream Author : Michael Long
* URL : https://github.com/meekrosoft/fff
* License : Expat
  Programming Lang: C++, Ruby
  Description : micro-framework for creating fake C functions for tests

Fake Function Framework (fff) is a micro-framework for creating fake C 
functions for tests.
Because life is too short to spend time hand-writing fake functions for testing.

It would be nice to have this for running efibootguard's tests.

Bug#1016077: network-manager-openvpn cannot connect due to IPv6 bug

[tuxmind]

Package: network-manager-openvpn
Version: 1.8.12-2

Good evening,
I'm experiencing this bug from upstream:
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/64

I've upgraded my system and got OpenVPN 2.5.1, which yields the
abovementioned bug when used with network-manager-openvpn < 1.8.14 .

I am using Debian GNU/Linux 11, kernel 5.10.127-1 and libc6 2.31-13.

Thank you for your time and precious work.
All the best, tuxmind.

Bug#1001214: Getting EFI Boot Guard into Debian

[Bastian Germann]

Am 26.07.22 um 00:04 schrieb Bastian Germann:

I would prefer not to be responsible for it and can hand over maintainership to
somebody who actually uses the software. I can grant git access for that person 
with
a salsa (Gitlab) username provided.

Whoever wants to be the package maintainer please make #1001214 an ITP (retitle 
and own the bug).


Quirin, do you want to step up as maintainer? I would still be sponsoring your package uploads but do not want to take 
responsibility for the package because I have never used it.


To make this your ITP send an answer including the bug address with the first 
two lines:

Control: retitle -1 ITP: efibootguard -- UEFI-based bootloader
Control: owner -1 Quirin Gylstorff 

Thanks,
Bastian

Bug#1016076: haskell-genvalidity-property FTBFS: unknown RTS option: -N

[Adrian Bunk]

Source: haskell-genvalidity-property
Version: 1.0.0.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-genvalidity-property=1.0.0.0-1

...
Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct
Non-zero exit code 1.
Running 1 test suites...
Test suite genvalidity-property-test: RUNNING...
Test suite genvalidity-property-test: FAIL
Test suite logged to:
dist-ghc/test/genvalidity-property-1.0.0.0-genvalidity-property-test.log
0 of 1 test suites (0 of 1 test cases) passed.
genvalidity-property-test: unknown RTS option: -N
genvalidity-property-test: 
genvalidity-property-test: Usage:   [+RTS  | -RTS ] 
... --RTS 
genvalidity-property-test: 
genvalidity-property-test:+RTSIndicates run time system options follow
genvalidity-property-test:-RTSIndicates program arguments follow
genvalidity-property-test:   --RTSIndicates that ALL subsequent arguments 
will be given to the
genvalidity-property-test:program (including any of these RTS flags)
genvalidity-property-test: 
genvalidity-property-test: The following run time system options are available:
genvalidity-property-test: 
genvalidity-property-test:   -?   Prints this message and exits; the 
program is not executed
genvalidity-property-test:   --info   Print information about the RTS used by 
this program
genvalidity-property-test: 
genvalidity-property-test:   --nonmoving-gc
genvalidity-property-test: Selects the non-moving mark-and-sweep 
garbage collector to
genvalidity-property-test: manage the oldest generation.
genvalidity-property-test:   --copying-gc
genvalidity-property-test: Selects the copying garbage collector to 
manage all generations.
genvalidity-property-test: 
genvalidity-property-test:   -K  Sets the maximum stack size (default: 
80% of the heap)
genvalidity-property-test: Egs: -K32k -K512k -K8M
genvalidity-property-test:   -ki Sets the initial thread stack size 
(default 1k)  Egs: -ki4k -ki2m
genvalidity-property-test:   -kc Sets the stack chunk size (default 32k)
genvalidity-property-test:   -kb Sets the stack chunk buffer size 
(default 1k)
genvalidity-property-test: 
genvalidity-property-test:   -A  Sets the minimum allocation area size 
(default 1m) Egs: -A20m -A10k
genvalidity-property-test:   -AL Sets the amount of large-object memory 
that can be allocated
genvalidity-property-test: before a GC is triggered (default: the 
value of -A)
genvalidity-property-test:   -F Sets the collecting threshold for old 
generations as a factor of
genvalidity-property-test: the live data in that generation the 
last time it was collected
genvalidity-property-test: (default: 2.0)
genvalidity-property-test:   -n  Allocation area chunk size (0 = 
disabled, default: 0)
genvalidity-property-test:   -O  Sets the minimum size of the old 
generation (default 1M)
genvalidity-property-test:   -M  Sets the maximum heap size (default 
unlimited)  Egs: -M256k -M1G
genvalidity-property-test:   -H  Sets the minimum heap size (default 0M)  
 Egs: -H24m  -H1G
genvalidity-property-test:   -xb Sets the address from which a suitable 
start for the heap memory
genvalidity-property-test: will be searched from. This is useful if 
the default address
genvalidity-property-test: clashes with some third-party library.
genvalidity-property-test:   -xn   Use the non-moving collector for the old 
generation.
genvalidity-property-test:   -m Minimum % of heap which must be 
available (default 3%)
genvalidity-property-test:   -G Number of generations (default: 2)
genvalidity-property-test:   -c Use in-place compaction instead of 
copying in the oldest generation
genvalidity-property-test:when live data is at least % of the 
maximum heap size set with
genvalidity-property-test:-M (default: 30%)
genvalidity-property-test:   -c   Use in-place compaction for all oldest 
generation collections
genvalidity-property-test:(the default is to use copying)
genvalidity-property-test:   -w   Use mark-region for the oldest generation 
(experimental)
genvalidity-property-test:   -I  Perform full GC after  idle time 
(default: 0.3, 0 == off)
genvalidity-property-test: 
genvalidity-property-test:   -T Collect GC statistics (useful for 
in-program statistics access)
genvalidity-property-test:   -t[] One-line GC statistics (if  
omitted, uses stderr)
genvalidity-property-test:   -s[] Summary  GC statistics (if  
omitted, uses stderr)
genvalidity-property-test:   -S[] Detailed GC statistics (if  
omitted, uses stderr)
genvalidity-property-test: 
genvalidity-property-test: 
genvalidity-property-test:   -Z Don't squeeze out update frames on 
context switch
genvalidity-property-test:   -B Sound the bell at the start of each 
garbage collection
genvalidity-property-test:   -h   Heap residency profile (output file 
.hp)

Bug#1016059: DDPO,Package Tracking System: move to UDD as a data source for lintian?

[Mattia Rizzolo]

Control: clone -1 -2
Control: reassign -2 tracker.debian.org

On Tue, Jul 26, 2022 at 11:39:45AM +0200, Lucas Nussbaum wrote:
> Package: qa.debian.org

cloning a copy for tracker.  I'll do ddpo rsn!

> UDD now has its own importer for lintian data. It also provides a

Thank you for working on it!


> https://udd.debian.org/lintian/?dpkg , which DDPO and PTS could use as a
> link target.

Probably, I'll keep it for the future for now.
However, may I suggest you make it use a proper querystring instead?
Like, ?pkg=dpkg, so that it'll be extensible in the future if one wants.

> I suggest that DDPO and PTS move to using UDD as a data source for
> lintian.
> 
> https://udd.debian.org/lintian-qa-list.txt is refreshed on a regular
> basis while the importer is running. So DDPO/PTS can sync for example
> hourly.

Great.

> Minor caveat: the semantic for qa-list.txt was a bit poor:
> 1) for packages both in unstable and experimental, lintian-qa-list.txt
> show stats for packages in unstable.

That's fair.

> 3) it does not provide a column for tags of type 'information'.
> I suppose it is OK to keep it like that.

DDPO only uses errors and warning, so no interest in that.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1001214: Getting EFI Boot Guard into Debian

[Bastian Germann]

Am 24.07.22 um 16:09 schrieb Jan Kiszka:

it would be really great to have EBG as an official package in bookworm.
There is the initial work done by Bastian with contributions by Quirin
already [1], but EBG moved on since then and needs some more work to
support 0.12. Likely, we will need patches from current next as bookworm
is broken with that release. Some bits to account for structural changes
in the latest releases is in [2], possibly not in Debian shape yet.


"broken" is a bit of a stretch. Instead of taking the patches from next I came 
up with
https://salsa.debian.org/debian/efibootguard/-/commit/6f62ed00158dbdeb2e4559a6c052ac8db41b53e6

It would help downstream packages to apply CFLAGS and LDFLAGS as you can also 
see with Debian's blhc checks at
https://salsa.debian.org/debian/efibootguard/-/jobs/3039310

Bug#1016074: UDD/lintian: please add search option to filter by lintian tags

[Louis-Philippe Véronneau]

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd
Severity: wishlist

Hi,

It would be really nice if the lintian web page for UDD let you filter
by lintian tags.

This way, it would be easier to do QA work on some things that are
flagged by lintian :)

Cheers, and thanks for running lintian!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#964752: Packaging gosop

[Daniel Kahn Gillmor]

On Wed 2022-07-20 19:54:00 +0200, Martin Dosch wrote:
> Ok, I just pushed my current progress to salsa: 
> https://salsa.debian.org/go-team/packages/gosop

Thanks for this work, Martin!

I've taken a look at it, and it looks reasonable to me.  (i confess here
that i am basically entirely a novice when it comes to go or go
packaging, so i welcome other reviewers).

I've also built the package and it works as i expect it to.  If someone
with more go experience or more mentoring experience than me wants to go
ahead with the upload, i encourage it!

  --dkg


signature.asc
Description: PGP signature

Bug#1011376: tpm2-pkcs11: Please import new upstream version

[Legner, Markus]

Not having the latest [version 
1.8.0](https://github.com/tpm2-software/tpm2-pkcs11/releases/tag/1.8.0) of 
tpm2-pkcs11 makes several workflows impossible that worked in the past (with 
OpenSSL 1), see also [this upstream 
issue](https://github.com/tpm2-software/tpm2-pkcs11/issues/766) and [this 
Ubuntu bug](https://bugs.launchpad.net/ubuntu/+source/tpm2-pkcs11/+bug/1964975).


Is there an estimated timeline for having a Debian package for 1.8.0?

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Luca Boccassi]

On Tue, 2022-07-26 at 15:43 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Hi,
> 
> Quoting Luca Boccassi (2022-07-26 15:27:35)
> > If it's not appropriate, please do update it accordingly, but IIRC it's what
> > gets used in these cases.
> 
> a bunch of sbuild issues piled up during the last weeks so I'll be doing an
> upload soon and will include a fix for this as well.
> 
> > > I put the gcc maintainer in CC. Is the buildd tarball to be more than 
> > > twice
> > > the size compared to before now?
> > 
> > Good find - regardless of whether it's intended that the tarball is so
> > large, perhaps it is an indication that the sbuild testsuite is a bit
> > fragile w.r.t. the running environment? Would it be possible to adjust
> > it to be more resilient? Is there a different disk-based scratch area
> > available for test artifacts?
> 
> the autopkgtest checks whether the sbuild unshare backend works. The
> environment on salsaci and the one on ci.debian.net does not support Linux 
> user
> namespaces. To still be able to test it, the autopkgtest creates a virtual 
> qemu
> environment and runs the test inside a qemu virtual machine. The size of the
> machine image is the limiting factor here.
> 
> The virtual machine image size was not a problem since the introduction of 
> this
> test in January 2021, so I wouldn't call it "fragile". Increasing the disk 
> size
> is simple but while you call such an adjustment to make it more "resilient" I
> first want to confirm that the more than twice increase in size is intentional
> or not. Otherwise, changing the disk size might have the opposite effect of
> "resilient" and hide problems resulting from an accidental upload which
> unnecessarily increased the installation size by half a Gigabyte.
> 
> Thanks!
> 
> cheers, josch

Right, I've misunderstood the issue, from a cursory and uninformed look
at the logs it looked like it was setting up a chroot in /tmp and it
was running out of space on the host.

Thanks for looking into this!

-- 
Kind regards,
Luca Boccassi


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

Bug#1001214: Getting EFI Boot Guard into Debian

[Gylstorff Quirin]

On 7/26/22 00:04, Bastian Germann wrote:

Am 24.07.22 um 16:09 schrieb Jan Kiszka:

Hi all,

it would be really great to have EBG as an official package in bookworm.
There is the initial work done by Bastian with contributions by Quirin
already [1], but EBG moved on since then and needs some more work to
support 0.12. Likely, we will need patches from current next as bookworm
is broken with that release. Some bits to account for structural changes
in the latest releases is in [2], possibly not in Debian shape yet.

Bastian, do you have the time to support this? What is needed from your
perspective, what should we contribute?


I have updated the package to build v0.12 but run into:
./configure: line 14997: syntax error near unexpected token 
`-mgeneral-regs-only,'

./configure: line 14997: `AX_CHECK_COMPILE_FLAG(-mgeneral-regs-only,'

Full log at https://salsa.debian.org/debian/efibootguard/-/jobs/3036697

The suggested "next" changes do not fix this.



I create an MR on salsa with the necessary fixes.

Quirin


So if you could provide a patch for this I can hand in the package.
I would prefer not to be responsible for it and can hand over 
maintainership to
somebody who actually uses the software. I can grant git access for that 
person with

a salsa (Gitlab) username provided.

Whoever wants to be the package maintainer please make #1001214 an ITP 
(retitle and own the bug).









Thanks,
Jan

[1] https://salsa.debian.org/debian/efibootguard/
[2]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-bsp/efibootguard 

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Luca Boccassi (2022-07-26 15:27:35)
> If it's not appropriate, please do update it accordingly, but IIRC it's what
> gets used in these cases.

a bunch of sbuild issues piled up during the last weeks so I'll be doing an
upload soon and will include a fix for this as well.

> > I put the gcc maintainer in CC. Is the buildd tarball to be more than twice
> > the size compared to before now?
> 
> Good find - regardless of whether it's intended that the tarball is so
> large, perhaps it is an indication that the sbuild testsuite is a bit
> fragile w.r.t. the running environment? Would it be possible to adjust
> it to be more resilient? Is there a different disk-based scratch area
> available for test artifacts?

the autopkgtest checks whether the sbuild unshare backend works. The
environment on salsaci and the one on ci.debian.net does not support Linux user
namespaces. To still be able to test it, the autopkgtest creates a virtual qemu
environment and runs the test inside a qemu virtual machine. The size of the
machine image is the limiting factor here.

The virtual machine image size was not a problem since the introduction of this
test in January 2021, so I wouldn't call it "fragile". Increasing the disk size
is simple but while you call such an adjustment to make it more "resilient" I
first want to confirm that the more than twice increase in size is intentional
or not. Otherwise, changing the disk size might have the opposite effect of
"resilient" and hide problems resulting from an accidental upload which
unnecessarily increased the installation size by half a Gigabyte.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Luca Boccassi]

On Tue, 2022-07-26 at 15:15 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Hi,
> 
> thank you for your bug report!
> 
> Quoting Luca Boccassi (2022-07-26 13:28:50)
> > Severity: serious
> 
> why is an autopkgtest failure "serious"?

Because it blocks other packages from migrating to testing, e.g.:

https://tracker.debian.org/pkg/apt

If it's not appropriate, please do update it accordingly, but IIRC it's
what gets used in these cases.

> > The autopkgtest run for sbuild keeps failing in debci, blocking other
> > packages migrations. The failure manifests in two different error
> > types, but both related to "No space left on device" when running
> > mmdebstrap.
> 
> The reason for this is the upload of gcc-defaults 1.198 to unstable. I 
> bisected
> Debian unstable. On 2022-07-22T08:51:38Z a buildd chroot tarball was 396 MB
> small. Starting with snapshot timestamp 2022-07-22T15:09:35Z (the first
> timestamp with the new gcc-defaults version) a buildd chroot tarball is now 
> 906
> MB large.
> 
> I put the gcc maintainer in CC. Is the buildd tarball to be more than twice 
> the
> size compared to before now?
> 
> Thanks!

Good find - regardless of whether it's intended that the tarball is so
large, perhaps it is an indication that the sbuild testsuite is a bit
fragile w.r.t. the running environment? Would it be possible to adjust
it to be more resilient? Is there a different disk-based scratch area
available for test artifacts?

-- 
Kind regards,
Luca Boccassi


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

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Johannes Schauer Marin Rodrigues]

Hi,

thank you for your bug report!

Quoting Luca Boccassi (2022-07-26 13:28:50)
> Severity: serious

why is an autopkgtest failure "serious"?

> The autopkgtest run for sbuild keeps failing in debci, blocking other
> packages migrations. The failure manifests in two different error
> types, but both related to "No space left on device" when running
> mmdebstrap.

The reason for this is the upload of gcc-defaults 1.198 to unstable. I bisected
Debian unstable. On 2022-07-22T08:51:38Z a buildd chroot tarball was 396 MB
small. Starting with snapshot timestamp 2022-07-22T15:09:35Z (the first
timestamp with the new gcc-defaults version) a buildd chroot tarball is now 906
MB large.

I put the gcc maintainer in CC. Is the buildd tarball to be more than twice the
size compared to before now?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1014926: pipewire: module-echo-cancel causes distortion in microphone input

[jk jk]

Hello,

I tried the new version (0.3.56) and the problem is indeed fixed.

Thank you,
Jan

Bug#1015039: gtk4 memorytexture test-case regresses with Mesa 22.1

[Simon McVittie]

Control: tags -1 + patch

On Tue, 19 Jul 2022 at 11:56:43 +0100, Simon McVittie wrote:
> A straightforward revert of 6bbbe15a applies cleanly to 22.1.x and
> appears to solve this.

Alternatively, upstream merge request
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17702 is waiting
for review, and a backport of it to 22.1.3 also appears to solve this
(see attached).

Because this is a RC bug (it caused FTBFS in gtk4, and apparently also
cases rendering errors in real-world use of gtk4 on llvmpipe), Mesa 22.1
will not migrate to testing until this is solved somehow or downgraded.

Please consider either reverting 6bbbe15a (the conservative approach)
or applying !17702.

Thanks,
smcv
>From 235c8f728eef3fc2bbc97cfe0be007dda0b0d96d Mon Sep 17 00:00:00 2001
From: Dave Airlie 
Date: Fri, 22 Jul 2022 11:12:58 +1000
Subject: [PATCH 1/3] llvmpipe: make last_fence a screen/rast object not a
 context one.

When a flush happens the per-context setup is used to hold the fence
for the last scene sent to the rasterizer. However when multiple
contexts are in use, this fence won't get returned to be blocked on.

Instead move the last fence to the rasterizer object, and return
that instead as it should be valid across contexts.

Fixes gtk4 bugs on llvmpipe since overlapping vertex/fragment.

Fixes: 6bbbe15a783a ("Reinstate: llvmpipe: allow vertex processing and fragment processing in parallel")
Origin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17702
---
 src/gallium/drivers/llvmpipe/lp_flush.c   | 12 ++---
 src/gallium/drivers/llvmpipe/lp_rast.c| 14 +-
 src/gallium/drivers/llvmpipe/lp_rast.h|  3 ++-
 src/gallium/drivers/llvmpipe/lp_rast_priv.h   |  2 ++
 src/gallium/drivers/llvmpipe/lp_setup.c   | 26 +--
 src/gallium/drivers/llvmpipe/lp_setup.h   |  1 -
 .../drivers/llvmpipe/lp_setup_context.h   |  1 -
 7 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_flush.c b/src/gallium/drivers/llvmpipe/lp_flush.c
index c231f334eaf..c72944232e7 100644
--- a/src/gallium/drivers/llvmpipe/lp_flush.c
+++ b/src/gallium/drivers/llvmpipe/lp_flush.c
@@ -38,7 +38,9 @@
 #include "lp_flush.h"
 #include "lp_context.h"
 #include "lp_setup.h"
-
+#include "lp_fence.h"
+#include "lp_screen.h"
+#include "lp_rast.h"
 
 /**
  * \param fence  if non-null, returns pointer to a fence which can be waited on
@@ -49,11 +51,15 @@ llvmpipe_flush( struct pipe_context *pipe,
 const char *reason)
 {
struct llvmpipe_context *llvmpipe = llvmpipe_context(pipe);
-
+   struct llvmpipe_screen *screen = llvmpipe_screen(pipe->screen);
draw_flush(llvmpipe->draw);
 
/* ask the setup module to flush */
-   lp_setup_flush(llvmpipe->setup, fence, reason);
+   lp_setup_flush(llvmpipe->setup, reason);
+
+   lp_rast_fence(screen->rast, (struct lp_fence **)fence);
+   if (fence && (!*fence))
+  *fence = (struct pipe_fence_handle *)lp_fence_create(0);
 
/* Enable to dump BMPs of the color/depth buffers each frame */
if (0) {
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c b/src/gallium/drivers/llvmpipe/lp_rast.c
index e27d78a3432..6cdaa51b62d 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -47,6 +47,7 @@
 #include "gallivm/lp_bld_format.h"
 #include "gallivm/lp_bld_debug.h"
 #include "lp_scene.h"
+#include "lp_screen.h"
 #include "lp_tex_sample.h"
 
 
@@ -1128,6 +1129,10 @@ lp_rast_queue_scene( struct lp_rasterizer *rast,
 {
LP_DBG(DEBUG_SETUP, "%s\n", __FUNCTION__);
 
+   lp_fence_reference(>last_fence, scene->fence);
+   if (rast->last_fence)
+  rast->last_fence->issued = TRUE;
+
if (rast->num_threads == 0) {
   /* no threading */
   unsigned fpstate = util_fpstate_get();
@@ -1384,6 +1389,8 @@ void lp_rast_destroy( struct lp_rasterizer *rast )
   align_free(rast->tasks[i].thread_data.cache);
}
 
+   lp_fence_reference(>last_fence, NULL);
+
/* for synchronizing rasterization threads */
if (rast->num_threads > 0) {
   util_barrier_destroy( >barrier );
@@ -1394,4 +1401,9 @@ void lp_rast_destroy( struct lp_rasterizer *rast )
FREE(rast);
 }
 
-
+void lp_rast_fence(struct lp_rasterizer *rast,
+   struct lp_fence **fence)
+{
+   if (fence)
+  lp_fence_reference((struct lp_fence **)fence, rast->last_fence);
+}
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h b/src/gallium/drivers/llvmpipe/lp_rast.h
index 14a2710f7f5..1756345737f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -388,5 +388,6 @@ lp_debug_draw_bins_by_cmd_length( struct lp_scene *scene );
 void
 lp_debug_draw_bins_by_coverage( struct lp_scene *scene );
 
-
+void lp_rast_fence(struct lp_rasterizer *rast,
+   struct lp_fence **fence);
 #endif
diff --git a/src/gallium/drivers/llvmpipe/lp_rast_priv.h b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
index 

Bug#1016073: python3-defaults: new --{min,max}-supported options for py3versions

[Julian Gilbey]

Source: python3-defaults
Version: 3.10.5-3
Severity: wishlist
Tags: patch

Hi!

I've found a need for a --min-supported option for py3versions, as I
need to grab something from /usr/lib/python3.X during package build
time, where python3.X is the minimum supported version.

I've just written a patch for this and submitted it as a MR on salsa:
https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/11

Best wishes,

   Julian

Bug#1016049: coreutils: env --{default,ignore,block}-signal with empty argument is valid and does nothing?

[наб]

On Tue, Jul 26, 2022 at 12:56:06PM +0100, Pádraig Brady wrote:
> On 26/07/2022 05:46, наб wrote:
> > Package: coreutils
> > Version: 8.32-4+b1
> > Severity: minor
> > 
> > Quoth env(1):
> > -- >8 --
> > --block-signal[=SIG]
> >block delivery of SIG signal(s) to COMMAND
> > 
> > --default-signal[=SIG]
> >reset handling of SIG signal(s) to the default
> > 
> > --ignore-signal[=SIG]
> >set handling of SIG signals(s) to do nothing
> > 
> > SIG may be a signal name like 'PIPE', or a signal number like '13'. 
> >  Without SIG, all known signals are included.  Multiple signals can be 
> > comma-separated.
> > -- >8 --
> > 
> > Precedent dictates that an empty argument should be refused (right?),
> > practicality suggests that it's likely a mistake
> > (since, again, it does nothing).
> > and the manual says it's forbidden
> > (clumsily using SIG and prose to describe signal[,signal]...).
> Not a bug I think.
> 
> "Empty" and "No" arguments are separate cases.
> I.e. `env --block-signal=` is equivalent to `env --block-signal ""`.
> This distinction is useful if passing a dynamic arg like:
>   env --block "$SIGS_TO_BLOCK"
Sure, I don't disagree that's useful,
but the manual specifies that at least one signal is required.

Consider instead the following:
-- >8 --
--block-signal[=SIGS]
--default-signal[=SIGS]
--ignore-signal[=SIGS]
   block delivery of SIGS signals to COMMAND

SIGS is a comma-separated list of signal names like 'PIPE' or
signal numbers like '13'.
-- >8 --

Which describes this accurately,
and could be resugared as --block-signal[=[signal[,signal]...]].

> thanks,
> Pádraig
Best,
наб


signature.asc
Description: PGP signature

Bug#1016049: coreutils: env --{default,ignore,block}-signal with empty argument is valid and does nothing?

[Pádraig Brady]

On 26/07/2022 05:46, наб wrote:

Package: coreutils
Version: 8.32-4+b1
Severity: minor

Dear Maintainer,

Quoth upstream NEWS:
-- >8 --
* Noteworthy changes in release 8.31 (2019-03-10) [stable]

** New features

   env now supports '--default-signal[=SIG]', '--ignore-signal[=SIG]', and
   '--block-signal[=SIG], to setup signal handling before executing a program.

   env now supports '--list-signal-handling' to indicate non-default
   signal handling before executing a program.
-- >8 --

Quoth env(1):
-- >8 --
--block-signal[=SIG]
   block delivery of SIG signal(s) to COMMAND

--default-signal[=SIG]
   reset handling of SIG signal(s) to the default

--ignore-signal[=SIG]
   set handling of SIG signals(s) to do nothing

SIG may be a signal name like 'PIPE', or a signal number like '13'.  
Without SIG, all known signals are included.  Multiple signals can be 
comma-separated.
-- >8 --

However:
-- >8 --
$ env -v --block-signal=1 ls /dev/null
signal HUP (1) mask set to BLOCK
executing: ls
arg[0]= ‘ls’
arg[1]= ‘/dev/null’
/dev/null
$ env -v --block-signal ls /dev/null 2>&1 | paste - - - -
signal HUP (1) mask set to BLOCKsignal INT (2) mask set to BLOCK
signal QUIT (3) mask set to BLOCK   signal ILL (4) mask set to BLOCK
signal TRAP (5) mask set to BLOCK   signal ABRT (6) mask set to BLOCK   
signal BUS (7) mask set to BLOCKsignal FPE (8) mask set to BLOCK
signal KILL (9) mask set to BLOCK   signal USR1 (10) mask set to BLOCK  
signal SEGV (11) mask set to BLOCK  signal USR2 (12) mask set to BLOCK
signal PIPE (13) mask set to BLOCK  signal ALRM (14) mask set to BLOCK  
signal TERM (15) mask set to BLOCK  signal STKFLT (16) mask set to BLOCK
signal CHLD (17) mask set to BLOCK  signal CONT (18) mask set to BLOCK  
signal STOP (19) mask set to BLOCK  signal TSTP (20) mask set to BLOCK
signal TTIN (21) mask set to BLOCK  signal TTOU (22) mask set to BLOCK  
signal URG (23) mask set to BLOCK   signal XCPU (24) mask set to BLOCK
signal XFSZ (25) mask set to BLOCK  signal VTALRM (26) mask set to BLOCK
signal PROF (27) mask set to BLOCK  signal WINCH (28) mask set to BLOCK
signal POLL (29) mask set to BLOCK  signal PWR (30) mask set to BLOCK   
signal SYS (31) mask set to BLOCK   signal RTMIN (34) mask set to BLOCK
signal RTMIN+1 (35) mask set to BLOCK   signal RTMIN+2 (36) mask set to BLOCK   
signal RTMIN+3 (37) mask set to BLOCK   signal RTMIN+4 (38) mask set to BLOCK
signal RTMIN+5 (39) mask set to BLOCK   signal RTMIN+6 (40) mask set to BLOCK   
signal RTMIN+7 (41) mask set to BLOCK   signal RTMIN+8 (42) mask set to BLOCK
signal RTMIN+9 (43) mask set to BLOCK   signal RTMIN+10 (44) mask set to BLOCK  
signal RTMIN+11 (45) mask set to BLOCK  signal RTMIN+12 (46) mask set to BLOCK
signal RTMIN+13 (47) mask set to BLOCK  signal RTMIN+14 (48) mask set to BLOCK  
signal RTMIN+15 (49) mask set to BLOCK  signal RTMAX-14 (50) mask set to BLOCK
signal RTMAX-13 (51) mask set to BLOCK  signal RTMAX-12 (52) mask set to BLOCK  
signal RTMAX-11 (53) mask set to BLOCK  signal RTMAX-10 (54) mask set to BLOCK
signal RTMAX-9 (55) mask set to BLOCK   signal RTMAX-8 (56) mask set to BLOCK   
signal RTMAX-7 (57) mask set to BLOCK   signal RTMAX-6 (58) mask set to BLOCK
signal RTMAX-5 (59) mask set to BLOCK   signal RTMAX-4 (60) mask set to BLOCK   
signal RTMAX-3 (61) mask set to BLOCK   signal RTMAX-2 (62) mask set to BLOCK
signal RTMAX-1 (63) mask set to BLOCK   signal RTMAX (64) mask set to BLOCK 
executing: ls  arg[0]= ‘ls’
arg[1]= ‘/dev/null’  /dev/null
$ env -v --block-signal= ls /dev/null
executing: ls
arg[0]= ‘ls’
arg[1]= ‘/dev/null’
/dev/null
-- >8 --

Precedent dictates that an empty argument should be refused (right?),
practicality suggests that it's likely a mistake
(since, again, it does nothing).
and the manual says it's forbidden
(clumsily using SIG and prose to describe signal[,signal]...).

Best,
наб

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information



Not a bug I think.

"Empty" and "No" arguments 

Bug#1016056: src:linux: Please enable CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y

[Diederik de Haas]

On dinsdag 26 juli 2022 10:27:24 CEST intrigeri wrote:
> Original pull request:
> https://lkml.iu.edu/hypermail/linux/kernel/2104.3/01302.html

https://lore.kernel.org/all/20210401232347.2791257-1-keesc...@chromium.org/ 
seems to be the corresponding link on 'lore'.


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

Bug#1016071: ftp.debian.org: Please reject 'pd-mapper' (ROM; confusing name)

[Arnaud Ferraris]

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

Dear FTP Masters,

I recently uploaded the 'pd-mapper' package to NEW. However, based on the
discussion
in the corresponding ITP (#1016011), it appears the name 'pd-mapper' can be
confusing
to some users.

Therefore, please reject the 'pd-mapper' package currently in NEW. I plan on
uploading
a new (renamed) package afterwards.

My apologies for this mishap and thanks for all your hard work.

Cheers,
Arnaud

Bug#1016070: sbuild: autopkgtest fails with "No space left on device"

[Luca Boccassi]

Source: sbuild
Version: 0.83.1
Severity: serious
X-Debbugs-Cc: jo...@debian.org, debian...@lists.debian.org

Dear Maintainer(s),

The autopkgtest run for sbuild keeps failing in debci, blocking other
packages migrations. The failure manifests in two different error
types, but both related to "No space left on device" when running
mmdebstrap.

This seems to have started on July the 22nd. List of recent failures:

https://ci.debian.net/packages/s/sbuild/testing/amd64/

Eg:

https://ci.debian.net/data/autopkgtest/unstable/amd64/s/sbuild/23951901/log.gz

+ mmdebstrap --mode=unshare --variant=apt unstable /tmp/chroot.tar
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.1Pi2WSLk6H as tempdir
I: running apt-get update...
I: downloading packages with apt...
I: extracting archives...
I: installing essential packages...
Selecting previously unselected package gcc-12-base:amd64.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../gcc-12-base_12.1.0-7_amd64.deb ...
Unpacking gcc-12-base:amd64 (12.1.0-7) ...
Selecting previously unselected package libc6:amd64.
Preparing to unpack .../libc6_2.33-8_amd64.deb ...
Use of uninitialized value in concatenation (.) or string at 
/usr/share/perl5/Debconf/Config.pm line 22.
Unpacking libc6:amd64 (2.33-8) ...
dpkg: error processing archive /var/cache/apt/archives/libc6_2.33-8_amd64.deb 
(--install):
 cannot copy extracted data for './usr/lib/x86_64-linux-gnu/gconv/IBM904.so' to 
'/usr/lib/x86_64-linux-gnu/gconv/IBM904.so.dpkg-new': failed to write (No space 
left on device)

Or:

https://ci.debian.net/data/autopkgtest/unstable/amd64/s/sbuild/24064827/log.gz

+ mmdebstrap --mode=unshare --variant=apt unstable /tmp/chroot.tar
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.CcPte840kk as tempdir
I: running apt-get update...
I: downloading packages with apt...
I: extracting archives...
tar: ./sbin/ldconfig: Wrote only 6144 of 10240 bytes
tar: ./usr/bin/catchsegv: Cannot write: No space left on device

-- 
Kind regards,
Luca Boccassi


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

Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u2 (was: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1)

[Rene Engelhard]

Hi,

[ redoing all the information for better clarity in the bugreport ]

[ Reason ]
1) It seems the evolution adress book is broken since 2015 due to a 
evolution change. Apparently noone noticed until 2021, where I 
backported the patch but then actually forgot to request a stable update


2) Croatia will join the Eurozone on 2023-01-01. I think we should
prepare.
TODO: After (or shortly before) 2023-01-01 we then can do a point 
release update to switch the default...


3) CVE-2021-25636 was no-DSA for bullseye but given we do an update 
anyway we can just include it

4) I just talked with Moritz and CVE-2022-2630{5,6,7} are also no-DSA.
While we are at it we can fix it too here

[ Impact ]
for 1) it stays broken.
for 2) EUR isn't supported in .hr locale
for 3) and 4) stays vulnerable (though it's minor)

[ Tests ]
None, ttbomk.

[ Risks ]
for 2) trivial, and doesn't yet affect the default
for 1) it is a bigger patch but upstream since 2021. No regression known
and if it should regress, it can't get more broken than "broken".

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

(2) is not yet fixed in unstable, that will happen with the upload of
7.4.0 rc2 (or someting later) to it

[ Changes ]
See above. I just added the verbatim upstream commits. (Made to apply 
and build for the CVE-2022-2630{5,6,7} fixes)


Debdiff attached.

[ Other info ]
As said, for 2) we need a new update to switch the default later.

Regards,

Renediff --git a/changelog b/changelog
index bdd1d149..ea05cdd3 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,19 @@
+libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
+
+  * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says; from libreoffice-7-2 branch
+  * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+  * debian/patches/b0404f80577de9ff69e58390c6f6ef949fdb0139.patch: fix
+CVE-2021-25636
+  * debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch,
+debian/patches/0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
+debian/patches/0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
+debian/patches/0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch:
+fix CVE-2022-2630{5,6,7}
+
+ -- Rene Engelhard   Tue, 26 Jul 2022 13:19:49 +0200
+
 libreoffice (1:7.0.4-4+deb11u1) bullseye-security; urgency=high
 
   * backport fixes from libreoffice-7-0 branch:
diff --git a/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch b/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
new file mode 100644
index ..e02b110f
--- /dev/null
+++ b/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
@@ -0,0 +1,63 @@
+From 77f30ada1156ca1e1357776fea8e9dc113f6898d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= 
+Date: Thu, 3 Mar 2022 14:22:37 +
+Subject: [PATCH 1/4] CVE-2022-26305 compare authors using Thumbprint
+
+Change-Id: I338f58eb07cbf0a3d13a7dafdaddac09252a8546
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130929
+Tested-by: Jenkins
+Reviewed-by: Miklos Vajna 
+(cherry picked from commit 65442205b5b274ad309308162f150f8d41648f72)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130866
+Reviewed-by: Michael Stahl 
+(cherry picked from commit a7aaa78acea4c1d51283c2fce54ff9f5339026f8)
+---
+ .../component/documentdigitalsignatures.cxx   | 23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+diff --git a/xmlsecurity/source/component/documentdigitalsignatures.cxx b/xmlsecurity/source/component/documentdigitalsignatures.cxx
+index b9066ea92cac..5a21c8421bec 100644
+--- a/xmlsecurity/source/component/documentdigitalsignatures.cxx
 b/xmlsecurity/source/component/documentdigitalsignatures.cxx
+@@ -19,9 +19,10 @@
+ 
+ #include 
+ 
+-#include 
++#include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -666,9 +667,23 @@ sal_Bool DocumentDigitalSignatures::isAuthorTrusted(
+ Sequence< SvtSecurityOptions::Certificate > aTrustedAuthors = SvtSecurityOptions().GetTrustedAuthors();
+ 
+ return std::any_of(aTrustedAuthors.begin(), aTrustedAuthors.end(),
+-[, ](const SvtSecurityOptions::Certificate& rAuthor) {
+-return xmlsecurity::EqualDistinguishedNames(rAuthor[0], xAuthor->getIssuerName())
+-&& ( rAuthor[1] == sSerialNum );
++[this, , ](const SvtSecurityOptions::Certificate& rAuthor) {
++if (!xmlsecurity::EqualDistinguishedNames(rAuthor[0], xAuthor->getIssuerName()))
++return false;
++if (rAuthor[1] != sSerialNum)
++return false;
++
++DocumentSignatureManager aSignatureManager(mxCtx, {});
++if 

Bug#1016069: ceph: CVE-2022-0670

[Moritz Mühlenhoff]

Source: ceph
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ceph.

CVE-2022-0670[0]:
| A flaw was found in Openstack manilla owning a Ceph File system
| "share", which enables the owner to read/write any manilla share or
| entire file system. The vulnerability is due to a bug in the "volumes"
| plugin in Ceph Manager. This allows an attacker to compromise
| Confidentiality and Integrity of a file system. Fixed in RHCS 5.2 and
| Ceph 17.2.2.

https://ceph.io/en/news/blog/2022/v17-2-2-quincy-released/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0670
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0670

Please adjust the affected versions in the BTS as needed.

Bug#1016068: vim: CVE-2022-2522

[Moritz Mühlenhoff]

Source: vim
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for vim.

CVE-2022-2522[0]:
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to
| 9.0.0060.

https://huntr.dev/bounties/3a2d83af-9542-4d93-8784-98b115135a22
https://github.com/vim/vim/commit/5fa9f23a63651a8abdb074b4fc2ec9b1adc6b089

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2522
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2522

Please adjust the affected versions in the BTS as needed.

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Luca Boccassi]

On Tue, 2022-07-26 at 10:49 +0100, Mark Hindley wrote:
> Luca,
> 
> [Sorry for the slow reply, your response was not sent to me.]
> 
> On Mon, Jul 25, 2022 at 04:52:32PM +0100, Luca Boccassi wrote:
> > Indeed it would be wrong. Also the justification doesn't seem correct:
> > simply installing the 'systemd' binary does NOT switch the init system,
> > so it's difficult to see how it could 'significant problems' in and by
> > itself.
> 
> I know that the original intention was to allow installation of the systemd
> binary independently of switching the init system. Whilst, in theory, that is
> still the case, in many, perhaps most real-world situations, installation of
> systemd does force a change of init. This is because the two available logind
> implementations (and therefore their dependency chains: 
> libpam-systemd->systemd
> or libpam-elogind->elogind) conflict and libpam-systemd depends on
> systemd-sysv. So, when installing just the systemd binary on a system which 
> uses
> a non-systemd init and the libpam-elogind logind implementation, APT has to
> change to libpam-systemd which pulls in systemd-sysv and forces the init 
> switch.
> 
> Logind dependencies are now very widespread. With packages such as
> openssh-server having a Recommends for it, even relatively minimal server
> installations will often require a logind implementation.
> 
> I hope that explanation is clear and helps.

The systemd binary package does not depend on libpam-systemd, that is
not the issue. Installing it does not pull in libpam nor switches the
init system
What you are referring to happens because elogind conflicts with
systemd, so obviously the systemd package and the elogind package
cannot be installed at the same time. That sounds like something that
should be fixed in elogind, and not a reason to make the default use
case more risky.

-- 
Kind regards,
Luca Boccassi


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

Bug#1016067: rpcbind installation fails due to missing user _rpc

[Daniel Reichelt]

Package: rpcbind
Version: 1.2.6-4
Severity: grave
Justification: renders package unusable

Hi,

since the d/postinst file has been removed, on a fresh VM rpcbind can no longer 
be installed:


--8<--
root@kvmsid:~# apt install rpcbind
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  rpcbind
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.9 kB of archives.
After this operation, 164 kB of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian sid/main amd64 rpcbind amd64 1.2.6-5 
[51.9 kB]
Fetched 51.9 kB in 0s (242 kB/s)
Selecting previously unselected package rpcbind.
(Reading database ... 26717 files and directories currently installed.)
Preparing to unpack .../rpcbind_1.2.6-5_amd64.deb ...
Unpacking rpcbind (1.2.6-5) ...
Setting up rpcbind (1.2.6-5) ...

/usr/lib/tmpfiles.d/rpcbind.conf:2: Failed to resolve user '_rpc': No such 
process
^


Created symlink /etc/systemd/system/multi-user.target.wants/rpcbind.service → 
/lib/systemd/system/rpcbind.service.
Created symlink /etc/systemd/system/sockets.target.wants/rpcbind.socket → 
/lib/systemd/system/rpcbind.socket.
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 145.
-->8--


Executing the adduser command from the former postinst script manually and
running `dpkg --configure -a` fixed the problem. Even though the migration path
from postinst might be obsolete, creating the _rpc user isn't.


Thanks,
Daniel

Bug#1016064: rpcbind: rpcbind.service fails with "cannot get uid of '_rpc': Success"

[Martin Pitt]

Martin Pitt [2022-07-26 11:58 +0200]:
> A fresh installation of rpcbind fails to start the service:

This can also be seen on package installation [1]:

   Setting up rpcbind (1.2.6-5) ...
   /usr/lib/tmpfiles.d/rpcbind.conf:2: Failed to resolve user '_rpc': No such 
process

Martin

[1] https://logs.cockpit-project.org/logs/image-refresh-3664-20220726-100606/log


signature.asc
Description: PGP signature

Bug#1016066: ITP: eg25-manager -- Manager daemon for the Quectel EG25 modem

[Arnaud Ferraris]

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

* Package name: eg25-manager
  Version : 0.4.4
  Upstream Author : Arnaud Ferraris 
* URL : https://gitlab.com/mobian1/eg25-manager
* License : GPL
  Programming Lang: C
  Description : Manager daemon for the Quectel EG25 modem

eg25-manager is a daemon aimed at configuring and monitoring the Quectel EG25
modem on a running system. It is used on the PinePhone (Pro) and performs the
following functions:
- power on/off
- startup configuration using AT commands
- AGPS data upload
- status monitoring (and restart if it becomes unavailable)

This package will be maintained within the DebianOnMobile team.

Bug#1015889: [Pkg-utopia-maintainers] Bug#1015889: high CPU load for avahi-daemon on Bullseye

[Harald Dunkel]

On 2022-07-24 14:23:45, Michael Biebl wrote:

Am 24.07.22 um 06:15 schrieb Harald Dunkel:

0.8-6 builds fine on Bullse


More importantly: Does it fix the high CPU load in your case?


I haven't seen the high CPU load anymore using the backported
avahi-daemon.

Regards

Harri

Bug#1016063: [Pkg-javascript-devel] Bug#1016063: node-node-rest-client: many issues, abandonned upstream, leaf package: should this package be RM'd ?

[Jérémy Lal]

Le mar. 26 juil. 2022 à 12:03, Jérémy Lal  a écrit :

> Source: node-node-rest-client
> Version: 3.1.1-1
> Severity: important
>
> Hi,
>
> for some reason debci fails on this package, so I checked it,
> only to discover many issues:
> - it doesn't run upstream test suite, but another test suite
> - it does useless things in debian/rules regarding debug.sh, test.sh,
>   and uselessly depends on dos2unix
> - when properly setup, upstream test suite fails on debian (two failures)
>

I've pushed to salsa repo the current changes - the tests failures should
be fixable
but I don't see the point in spending more time on this.

Bug#1016065: ITP: golang-github-shenwei356-unik -- A k-mer serialization package for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-shenwei356-unik
  Version : 5.0.1-1
  Upstream Author : Wei Shen
* URL : https://github.com/shenwei356/unik
* License : Expat
  Programming Lang: Go
  Description : A k-mer serialization package for Golang (library)
 This package provides k-mer serialization methods for the package kmers
 TaxIds of k-mers are optionally saved, while there's no frequency information.
 .
 K-mers (represented in uint64 in RAM ) are serialized in 8-Byte (or less
 Bytes for shorter k-mers in compact format, or much less Bytes for sorted
 k-mers) arrays and optionally compressed in gzip format with extension of
 .unik.

Bug#1015898: I would love to see FoxDot in Debian

[Joenio Marques da Costa]

I would be very happy to see it on Debian.

I don't know if I have experience enough (I've never packaged python 
things) but I can help on it.


Thanks for opening this bug Josue ;)

--
Joenio Marques da Costa
Invited Researcher at Université Gustave Eifell
Research Software Engineer at LISIS
Developer at CorTexT platform & RISIS Core Facility
http://umr-lisis.fr/membre/joenio

Bug#776852: .cache/apvlv/ has files now, .apvlvinfo should put in ~/.cache/apvlv/

[肖盛文]

In apvlv  0.4.0+repack-1, it has files in ~/.cache/apvlv/ now.


find .cache/apvlv/

.cache/apvlv/
.cache/apvlv/WebKitCache
.cache/apvlv/WebKitCache/Version 16
.cache/apvlv/WebKitCache/Version 16/salt
.cache/apvlv/WebKitCache/Version 16/Blobs

Perhaps .apvlvinfo should put in ~/.cache/apvlv/ directory.

-- 
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016064: rpcbind: rpcbind.service fails with "cannot get uid of '_rpc': Success"

[Martin Pitt]

Package: rpcbind
Version: 1.2.6-4
Severity: serious

A fresh installation of rpcbind fails to start the service:

systemd[1]: Starting RPC bind portmap service...
rpcbind[314]: cannot get uid of '_rpc': Success
systemd[1]: rpcbind.service: Main process exited, code=exited, 
status=1/FAILURE
systemd[1]: rpcbind.service: Failed with result 'exit-code'.
systemd[1]: Failed to start RPC bind portmap service.

That's because the `_rpc` user does not exist. Upgrading from an earlier image
(with 1.2.6-3) works because earlier versions created it:

# id _rpc
uid=108(_rpc) gid=65534(nogroup) groups=65534(nogroup)

Release -4 said "Remove obsolete debian/postinst file", and most of it may be
obsolete, but not this bit:

if [ "$1" = configure ] ; then
# run daemon as non-root (see #852066)
adduser --force-badname --system --quiet --home /run/rpcbind 
--no-create-home _rpc

Please put this back. Or better yet, use systemd's User=, DynamicUser=, and
RuntimeDirectory= options to contain all of the setup in the unit.

Thanks!

Martin


signature.asc
Description: PGP signature

Bug#1016063: node-node-rest-client: many issues, abandonned upstream, leaf package: should this package be RM'd ?

[Jérémy Lal]

Source: node-node-rest-client
Version: 3.1.1-1
Severity: important

Hi,

for some reason debci fails on this package, so I checked it,
only to discover many issues:
- it doesn't run upstream test suite, but another test suite
- it does useless things in debian/rules regarding debug.sh, test.sh,
  and uselessly depends on dos2unix
- when properly setup, upstream test suite fails on debian (two failures)
- it is practically abandonned upstream, also it is old pre-es5 javascript 
style,
  and source code is of mediocre quality.
- contrary to what the ITP #877646 announced, it is now a leaf package,
  and not needed (as a dep or build-dep) by any other package

For all those reasons, instead of artificially keeping it alive,
I strongly suggest this package be removed from debian.

I'll open a RM bug if you are okay with that.

Jérémy

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

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

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Mark Hindley]

Luca,

[Sorry for the slow reply, your response was not sent to me.]

On Mon, Jul 25, 2022 at 04:52:32PM +0100, Luca Boccassi wrote:
> Indeed it would be wrong. Also the justification doesn't seem correct:
> simply installing the 'systemd' binary does NOT switch the init system,
> so it's difficult to see how it could 'significant problems' in and by
> itself.

I know that the original intention was to allow installation of the systemd
binary independently of switching the init system. Whilst, in theory, that is
still the case, in many, perhaps most real-world situations, installation of
systemd does force a change of init. This is because the two available logind
implementations (and therefore their dependency chains: libpam-systemd->systemd
or libpam-elogind->elogind) conflict and libpam-systemd depends on
systemd-sysv. So, when installing just the systemd binary on a system which uses
a non-systemd init and the libpam-elogind logind implementation, APT has to
change to libpam-systemd which pulls in systemd-sysv and forces the init switch.

Logind dependencies are now very widespread. With packages such as
openssh-server having a Recommends for it, even relatively minimal server
installations will often require a logind implementation.

I hope that explanation is clear and helps.

Best wishes

Mark

Bug#1016062: haskell-cborg FTBFS on 32bit: error: Couldn't match expected type ‘Int64#’ with actual type ‘Int#’

[Adrian Bunk]

Source: haskell-cborg
Version: 0.2.7.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-cborg=0.2.7.0-1

...
src/Codec/CBOR/Decoding.hs:341:19: error:
• Couldn't match expected type ‘Int64#’ with actual type ‘Int#’
• In the first argument of ‘I64#’, namely ‘n’
  In the expression: I64# n
  In an equation for ‘toInt64’: toInt64 n = I64# n
|
341 | toInt64  n = I64# n
|   ^

src/Codec/CBOR/Decoding.hs:345:19: error:
• Couldn't match expected type ‘Word64#’ with actual type ‘Word#’
• In the first argument of ‘W64#’, namely ‘n’
  In the expression: W64# n
  In an equation for ‘toWord64’: toWord64 n = W64# n
|
345 | toWord64 n = W64# n
|   ^

src/Codec/CBOR/Decoding.hs:421:62: error:
• Couldn't match expected type ‘Word#’ with actual type ‘Word64#’
• In the first argument of ‘toWord64’, namely ‘w64#’
  In the first argument of ‘k’, namely ‘(toWord64 w64#)’
  In the expression: k (toWord64 w64#)
|
421 |   Decoder (\k -> return (ConsumeWord64 (\w64# -> k (toWord64 w64#
|  

src/Codec/CBOR/Decoding.hs:440:65: error:
• Couldn't match expected type ‘Word#’ with actual type ‘Word64#’
• In the first argument of ‘toWord64’, namely ‘w64#’
  In the first argument of ‘k’, namely ‘(toWord64 w64#)’
  In the expression: k (toWord64 w64#)
|
440 |   Decoder (\k -> return (ConsumeNegWord64 (\w64# -> k (toWord64 w64#
| 

src/Codec/CBOR/Decoding.hs:480:60: error:
• Couldn't match expected type ‘Int#’ with actual type ‘Int64#’
• In the first argument of ‘toInt64’, namely ‘n64#’
  In the first argument of ‘k’, namely ‘(toInt64 n64#)’
  In the expression: k (toInt64 n64#)
|
480 |   Decoder (\k -> return (ConsumeInt64 (\n64# -> k (toInt64 n64#
|

src/Codec/CBOR/Decoding.hs:520:71: error:
• Couldn't match expected type ‘Word#’ with actual type ‘Word64#’
• In the first argument of ‘toWord64’, namely ‘w64#’
  In the first argument of ‘k’, namely ‘(toWord64 w64#)’
  In the expression: k (toWord64 w64#)
|
520 |   Decoder (\k -> return (ConsumeWord64Canonical (\w64# -> k (toWord64 
w64#
|   

src/Codec/CBOR/Decoding.hs:539:74: error:
• Couldn't match expected type ‘Word#’ with actual type ‘Word64#’
• In the first argument of ‘toWord64’, namely ‘w64#’
  In the first argument of ‘k’, namely ‘(toWord64 w64#)’
  In the expression: k (toWord64 w64#)
|
539 |   Decoder (\k -> return (ConsumeNegWord64Canonical (\w64# -> k (toWord64 
w64#
|  


src/Codec/CBOR/Decoding.hs:579:69: error:
• Couldn't match expected type ‘Int#’ with actual type ‘Int64#’
• In the first argument of ‘toInt64’, namely ‘n64#’
  In the first argument of ‘k’, namely ‘(toInt64 n64#)’
  In the expression: k (toInt64 n64#)
|
579 |   Decoder (\k -> return (ConsumeInt64Canonical (\n64# -> k (toInt64 
n64#
| 
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 642
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:160: build-ghc-stamp] Error 25

Bug#1014926: pipewire: module-echo-cancel causes distortion in microphone input

[Dylan Aïssi]

Hi,

Le jeu. 14 juil. 2022 à 17:09, Jan K  a écrit :
>
> When module-echo-cancel is loaded with pipewire version 0.3.54-2 there is 
> heavy crackling in the captured microphone input, the sound is very 
> distorted.  When the module is unloaded the mic sounds fine again (but there 
> is no echo cancellation obviously).
>
> With version 0.3.53-1 the module doesn't have this problem, echo cancellation 
> works and there is no distortion.
>

Based on a similar issue on the upstream bug tracker, this issue
should be fixed in 0.3.56 already available in unstable/testing.
Can you check if the new version solves your issue?

Best,
Dylan

Bug#1016061: ITP: golang-github-shenwei356-kmers -- bit-packed k-mers methods for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-shenwei356-kmers
  Version : 0.1.0-1
  Upstream Author : Wei Shen
* URL : https://github.com/shenwei356/kmers
* License : Expat
  Programming Lang: Go
  Description : bit-packed k-mers methods for Golang (library)
 This package provides manipulations for bit-packed k-mers (k<=32, encoded
 in uint64).

Bug#1016059: DDPO,Package Tracking System: move to UDD as a data source for lintian?

[Lucas Nussbaum]

Package: qa.debian.org
Severity: normal

Hi,

lintian.debian.org has been out of date since end of 2021. The question
of its future has been raised with DSA:
https://lists.debian.org/debian-qa/2022/07/msg6.html

UDD now has its own importer for lintian data. It also provides a
drop-in replacement for https://lintian.debian.org/static/qa-list.txt as
https://udd.debian.org/lintian-qa-list.txt, and a web interface to view
detailed results per package at (e.g.)
https://udd.debian.org/lintian/?dpkg , which DDPO and PTS could use as a
link target.

I suggest that DDPO and PTS move to using UDD as a data source for
lintian.

https://udd.debian.org/lintian-qa-list.txt is refreshed on a regular
basis while the importer is running. So DDPO/PTS can sync for example
hourly.

Minor caveat: the semantic for qa-list.txt was a bit poor:
1) for packages both in unstable and experimental, lintian-qa-list.txt
show stats for packages in unstable.
2) packages not in unstable are not listed.
3) it does not provide a column for tags of type 'information'.
I suppose it is OK to keep it like that.

For reference, the UDD code the generate the data is
https://salsa.debian.org/qa/udd/-/blob/master/rimporters/lintian.rb#L380

Lucas

Bug#1015897: gobby: Gobby is crashing right after calling it

[Andreas Tille]

Hi,

Am Tue, Jul 26, 2022 at 09:58:49AM +0200 schrieb Philipp Kern:
> Hi,
> 
> On 23.07.22 15:09, Andreas Tille wrote:
> > ** (gobby:197027): WARNING **: 15:06:06.692: Failed to create root 
> > directory: Permission denied
> > Subsequent storage operations will most likely fail
> 
> How do your permissions on ~/.config

drwxr-xr-x  90 andreas andreas  4096 26. Jul 11:24 .config

> and ~/.config/gobby look like?

drwxr-xr-x  2 andreas andreas  4096 20. Jul 10:11 gobby

$ ls -lR .config/gobby
.config/gobby:
insgesamt 8
-rw-r--r-- 1 andreas andreas  52 23. Aug 2020  documents.xml
-rw-r--r-- 1 andreas andreas 298 23. Aug 2020  hosts.xml
-rw-r--r-- 1 andreas andreas   0 12. Aug 2013  known_hosts
-rw-r--r-- 1 andreas andreas   0 23. Aug 2020  recent_hosts

> Does the
> latter exist now?

It existed - but if I remove it no such dir is create newly.
 
Kind regards

   Andreas. 

-- 
http://fam-tille.de

Bug#1013551: fixed by this commit

[Christian Ehrhardt]

This FTFBS which - as reported - is good if build from git is fixed by

commit 69c911989e4752c3b56851877cfcf7cc6a23bde2
Author: Athos Ribeiro 
Date:   Tue Jun 7 19:44:38 2022 -0300

d/control: depend on librust-uuid+rand-dev for v4

I'll mark that as fixing this bug

-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1005099: new upstream version 4.0.12

[Harald Dunkel]

In the meantime LXC version 5.0 has been released.

Looking at #768073 and #1010843 I have the impression that the the new
lxc 5.0 version is needed to resolve a file name conflict with lxd, waiting
to be released as a "real" Debian package.

Would you mind to check? If you need help please mail.


Regards

Harri

Bug#1003777: bug acknowledged

[Christian Ehrhardt]

fixed 1003777 1.1.0-2
tags 1003777 +pending

Bug#1003777: Thanks for the report

[Christian Ehrhardt]

Hi Martin,
yes that dir got lost in the switch to 1.x - thanks for the report.
This formerly was created by the upstream build and thereby available
automatically.
Old users upgrading from e.g. 0.59 would still have it.

But indeed the new version lacks that, I'll add the dir to the build
so that it is properly created.

-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1013551: bug acknowledged

[Christian Ehrhardt]

fixed 1013551 1.1.0-2
tags 1013551 +pending

Bug#1013551: probably a transient issue of the rand version upgrade

[Christian Ehrhardt]

Hi,
sorry that I didn't see that bug earlier :-/
Well better late than never ... I at least saw the removal :-(

I had a look and I'm confused by how your re-build broke here.

> searched package name: `rand`

That should be provided by librust-rand-dev and all its variations.

The build dependency is there:
 - we build depend on librust-uuid+rand-dev
 - That has
   Depends: ... librust-rand-0.8+default-dev

So therefore it should be around at build time.

I checked the last good build [1] and there it did behave as expected
installing librust-rand* packages and building fine.

The packages are there - rmadison output:
librust-uuid+rand-dev | 0.8.1-5   | testing| amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
librust-uuid+rand-dev | 0.8.1-5   | unstable   | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
librust-rand-dev | 0.8.4-2   | testing| amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x
librust-rand-dev | 0.8.4-2   | unstable   | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x

The latter has:
Provides: ... librust-rand-0.8+default-dev (= 0.8.4-2)

I did a run of sbuild in unstable and testing - both worked just fine.

Without digging much further I can only assume that this was a transitional
issue while librust-rand went from 0.6.3-2 to the current 0.8.4-2.

A simple rebuild should fix this and along the way I can fix another bug
that was opened recently.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=mdevctl=amd64=1.1.0-1%2Bb1=1651440805=1


-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1016057: should use --disable-unit-tests for ./configure

[Frank Lichtenheld]

Package: openvpn
Version: 2.6.0~git20220518+dco-3

Currently openvpn implicitely disables the unit tests by not build-depending on
libcmocka-dev. If it is installed, the unit tests will be built. If not running
the unit tests is intentional you should specify the --disable-unit-tests 
configure
flags to get consistent behavior. Or add libcmocka-dev to the build 
dependencies.

However, on Ubuntu the package even fails to build when libcmocka-dev is 
installed
since Ubuntu enables -flto by default which breaks linking of some of the UTs.

Regards,
-- 
  Frank Lichtenheld

Bug#1015730: Please elaborate the move

[Geert Stappers]

On Tue, Jul 26, 2022 at 10:08:22AM +0200, Zozó Teki wrote:
> Now it says;
>   "NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator 
>All development happens there.
>Also, download new releases & submit issues there."
> 
> Is this better?


Yes, much better.  Thanks


Regards
Geert Stappes
Live from https://mch2022.org

Bug#1016053: ITP: lua-resty-core -- New FFI-based Lua API for NGINX lua module

[Jérémy Lal]

Le mar. 26 juil. 2022 à 08:51, Jan Mojzis  a écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Jan Mojzis 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: lua-resty-core
>   Version : 0.10.13
>   Upstream Author : Yichun Zhang (agentzh) 
> * URL : https://github.com/openresty/lua-resty-core
> * License : BSD
>   Programming Lang: Lua
>   Description : New FFI-based Lua API for NGINX lua module
>
> This library implements a New FFI-based Lua API for NGINX lua module.
>
> I'm currenlty maintaining NGINX package, and new ngx_lua module needs the
> lua-resty-core package.
>
> I would like to maintain the package using https://salsa.debian.org/
> I would need to create a
> https://salsa.debian.org/debian/lua-team/lua-resty-core repository before
> uploading.
> Currently is the Debian package maintained here
> https://salsa.debian.org/janmojzis/lua-resty-core
>
> I need sponsor only for the first upload (I'm DM).
>

Hi !
I'm consuming lua-resty-core, lua-resty-lrucache, lua-resty-lock,
lua-resty-redis, and some others like srcache,
lua-upstream, lua-set-misc...
So I'll be glad to review/sponsor.

I created https://salsa.debian.org/lua-team/lua-resty-core
 however, only
project maintainer/owner can grant you access.
Ask on pkg-lua-de...@alioth-lists.debian.net or on #debian-lua. Maybe you
can request access directly on salsa (and maybe not).

Jérémy

Bug#1015897: gobby: Gobby is crashing right after calling it

[Philipp Kern]

Hi,

On 23.07.22 15:09, Andreas Tille wrote:

** (gobby:197027): WARNING **: 15:06:06.692: Failed to create root directory: 
Permission denied
Subsequent storage operations will most likely fail


How do your permissions on ~/.config and ~/.config/gobby look like? Does 
the latter exist now?


Kind regards
Philipp Kern

Bug#1016056: src:linux: Please enable CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y

[intrigeri]

Source: linux
Version: 5.18.14-1
Severity: wishlist
User: tails-...@boum.org
Usertags: hardening

Hi!

Please consider setting CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
(5.13 or newer).

This enables a security feature with low performance overhead.

Original pull request:
https://lkml.iu.edu/hypermail/linux/kernel/2104.3/01302.html

Ubuntu 22.04 LTS has this setting enabled by default.

KSPP recommends enabling it:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings

Thanks for your attention,
cheers!
-- 
intrigeri