Bug#1004081: file: Add support for JPEG-XL

[Mathieu Malaterre]

Control: fixed -1 1:5.39-3

See:

https://bugs.astron.com/view.php?id=309#c3703

Bug#1000336: numba: FTBFS with Python 3.10

[Graham Inggs]

Hi Diane

On Mon, 21 Feb 2022 at 05:39, Diane Trout  wrote:
> It would... except numpy 1.22 just hit experimental on the 18th. and
> numba isn't compatible with numpy 1.22. I tried adding this to
> d/control,
>
> python3-numpy (<< 1.22),
>
> but my sbuild resolver still picked up numpy from experimental and
> refused to build.

That doesn't sound right.  You should be targeting experimental, but
still building against packages in unstable.  Something like this:

sbuild -d experimental -c unstable-amd64-sbuild ...

Regards
Graham

Bug#1005230: Does chromium REALLY need fuse now?

[Trent W. Buck]

Trent W. Buck wrote:
> The error report for #1005230 only specifically mentioned GTK3.
> Are these other "portal" dependencies *really* needed now?

As at chromium 98.0.4758.102-1~deb11u1,
chromium works with xdg-desktop-portal, fuse, flatpak removed.

A minimal test script is attached.
it builds & boots a Debian 11 Live VM without chromium.
You can then launch chromium,
browse to https://example.com, Ctrl+S save and Ctrl+O open.

I'm not sure what other tests are needed.
Can I do anything else to help with this ticket?
#!/usr/bin/python3
import subprocess
import tempfile

__doc__ = """ test chrome w/o fuse

log in as "x", run chromium, browse to https://example.museum/, Ctrl+S Enter to save.
See that saving works even with xdg-desktop-portal/flatpak/fuse removed.

NOTE: kvm's default geometry is 800x600 or something.
  GTK3's default save dialog does not fit.
  Try resizing the KVM window before lightdm starts.
"""

with tempfile.TemporaryDirectory() as td:
subprocess.check_call(
['mmdebstrap',
 '--include=linux-image-generic,live-boot,chromium,task-xfce-desktop,sudo',
 # f'--aptopt=Acquire::http::Proxy "http://localhost:3142";',
 '--customize-hook=chroot $1 adduser x --gecos x --disabled-password --quiet',
 '--customize-hook=chroot $1 adduser x sudo',
 '--customize-hook=echo x: | chroot $1 chpasswd --crypt-method=NONE',
 '--customize-hook=download vmlinuz vmlinuz',
 '--customize-hook=download initrd.img initrd.img',

 # Remove things that chromium claims it needs but does not actually need.
 '--customize-hook=chroot $1 dpkg --force-depends --purge xdg-desktop-portal xdg-desktop-portal-backend xdg-desktop-portal-gtk fuse libfuse2 fuse3 libfuse3-3 bubblewrap flatpak libgnome-desktop-3-19',

 # Report which version of chromium we are running.
 '--customize-hook=chroot $1 dpkg-query -W chromium',
 'bullseye',
 'filesystem.squashfs'],
cwd=td)
subprocess.check_call(
['kvm',
 '-m', '2G',
 '--device', 'virtio-vga',
 '--kernel', 'vmlinuz',
 '--initrd', 'initrd.img',
 '--append', 'boot=live plainroot root=/dev/vda quiet',
 '--drive', f'file=filesystem.squashfs,format=raw,media=disk,if=virtio,readonly=on'],
cwd=td)
bash5$ python3 POC-chromium-without-fuse.py
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: squashfs
I: using /tmp/mmdebstrap.YvkchFlb0y as tempdir
W: tar2sqfs does not support extended attributes from the 'system' namespace
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
done
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 adduser x --gecos x 
--disabled-password --quiet' exec /tmp/mmdebstrap.YvkchFlb0y
I: running --customize-hook in shell: sh -c 'chroot $1 adduser x sudo' exec 
/tmp/mmdebstrap.YvkchFlb0y
Adding user `x' to group `sudo' ...
Adding user x to group sudo
Done.
I: running --customize-hook in shell: sh -c 'echo x: | chroot $1 chpasswd 
--crypt-method=NONE' exec /tmp/mmdebstrap.YvkchFlb0y
I: running special hook: download vmlinuz vmlinuz
I: running special hook: download initrd.img initrd.img
I: running --customize-hook in shell: sh -c 'chroot $1 dpkg --force-depends 
--purge xdg-desktop-portal xdg-desktop-portal-backend xdg-desktop-portal-gtk 
fuse libfuse2 fuse3 libfuse3-3 bubblewrap flatpak libgnome-desktop-3-19' exec 
/tmp/mmdebstrap.YvkchFlb0y
dpkg: warning: ignoring request to remove xdg-desktop-portal-backend which 
isn't installed
dpkg: warning: ignoring request to remove fuse3 which isn't installed
dpkg: warning: ignoring request to remove libfuse3-3 which isn't installed
dpkg: warning: ignoring request to remove flatpak which isn't installed
dpkg: libgnome-desktop-3-19:amd64: dependency problems, but removing anyway as 
you requested:
 xdg-desktop-portal-gtk depends on libgnome-desktop-3-19 (>= 3.17.92).

(Reading database ... 31385 files and directories currently installed.)
Removing libgnome-desktop-3-19:amd64 (3.38.5-3) ...
dpkg: xdg-desktop-portal: dependency problems, but removing anyway as you 
requested:
 xdg-desktop-portal-gtk depends on xdg-desktop-portal (>= 1.7.1).

Removing xdg-desktop-portal (1.8.1-1) ...
dpkg: xdg-desktop-portal-gtk: dependency problems, but removing anyway as you 
requested:
 chromium depends on xdg-desktop-portal-gtk | xdg-desktop-portal-backend; 
however:
  Package xdg-desktop-portal-gtk is to be removed.
  Package xdg-desktop-portal-backend is not installed.
  Package xdg-desktop-portal-gtk which provides xdg-desktop-portal-backend is 
to be removed.
 chromium depends on xdg-desktop-portal-gtk | xdg-desktop-portal-backend; 
however:
  Pac

Bug#1005808: chromium: ERR_SSL_VERSION_OR_CIPHER_MISMATCH after upgrade to 98.0.4758.80

[Benoît Panizzon]

Hi Andres

> Thanks for the explanation. What happens if you run chromium with
> --tls1 ? That sets the min SSL version to TLSv1.0, although I'm not
> sure what changed within chromium to actually drop TLSv1 support; if
> it's a third party library, then the code to support it might just be
> gone.

Unfortunately --tls1 does not solve the issue.

I also found: https://chromestatus.com/feature/5759116003770368 which
explains they removed tls1.0 all together with no way to bypass.

So I guess I have to switch to a different browser to access devices
with built-in ssl webserver which do not support anything else than
tls1 and sslv3

-Benoit-

Bug#1005230: Does chromium REALLY need fuse now?

[Trent W. Buck]

Package: chromium
Followup-For: Bug #1005230

Hi, I ship chromium in prisons, where we extremely do not want
unprivileged users to be able to add new drivers (fuse) and
applications (flatpak/bubblewrap/xdg-desktop-portal). [*]

The fix for #1005230 added indirect dependencies on fuse and bubblewrap.

The error report for #1005230 only specifically mentioned GTK3.
Are these other "portal" dependencies *really* needed now?

If they are needed, I can deal with it.
If they aren't needed, is it feasible to define the hard dependencies more 
precisely?
Or downgrade xdg-desktop-portal to a Recommends?

(I repackage a few things in-house like linux and vlc, but
I'm frankly too scared to try that with chromium.)


As a sanity-check, I see that libwebkit2gtk-4.0-37 needs bubblewrap (but not 
fuse), and
firefox-esr needs neither.



[*] I have a bunch of other layers to block these, but
"libfuse* isn't even installed" is really nice layer to have.
e.g. detainee kernels have CONFIG_FUSE_FS disabled
(though CONFIG_USER_NS is enabled due to systemd).


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 chromium-common depends on:
ii  libc6   2.31-13+deb11u2
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.2-1
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
pn  chromium-sandbox   
ii  fonts-liberation   1:1.07.4-11
ii  gnome-shell [notification-daemon]  3.38.6-1~deb11u1
ii  libgl1-mesa-dri20.3.5-1
ii  libu2f-udev1.1.10-3
ii  notification-daemon3.20.0-4
ii  system-config-printer  1.5.14-1
ii  upower 0.99.11-2

Bug#1006198: docbook: Packaging license incompatible with the upstream

[Helmut Grohne]

Hi Eriberto,

On Mon, Feb 21, 2022 at 12:55:05AM -0300, Joao Eriberto Mota Filho wrote:
> The current packaging license (GPL-2+) is incompatible with upstream
> licensing (DocBook License). It is a hampering condition to submit patches
> from Debian to the upstream.
> 
> I would like to change the packaging licensing to 'DocBook' and I will
> wait 15 days to know if anyone has any objection.

I hereby dual-license my past contributions to the docbook Debian
package under the DocBook license in addition to the existing GPL-2+
license.

Thank you for taking care.

Helmut

Bug#991788: From Mrs Amaib Chi

[Amaib Gold]

Greetings to you in the name of the Lord. My name is Mrs Amaib Chi. There
is something very important I want to discuss with you. I'm a very
influential and wealthy woman but I'm sick and dying.


I'm suffering from severe malignancy and have a few months to live. I send
you this message because I want to make a charity donation to the Charity
in your country.

Please, endeavour to get back to me for more details, thanks and May God
bless.


Warm regards

Mrs Amaib Chi

Bug#1006141: supertuxkart: FTBFS on armhf: Error: selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'

[Peter Michael Green]

Tags 1006141 +patch
thanks

This was fixed in ubuntu a few months ago by adding ".fpu vfp" to the 
assembler file in question.
(within the block of code that is only used on systems with the hard 
float ABI).


https://patches.ubuntu.com/s/supertuxkart/supertuxkart_1.3+dfsg1-2ubuntu1.patch

I have just built the same fix successfully in raspbian bookworm-staging 
and uploaded it
to raspbian. I haven't tested it in Debian myself but I'd be extremely 
surprised if it doesn't work.

Bug#1006172: [Pkg-electronics-devel] Bug#1006172: src:lepton-eda: fails to migrate to testing for too long: FTBFS on s390x

[Bdale Garbee]

Paul Gevers  writes:

> Your package fails to build on s390x where it build successfully in
> the past. I've X-Debbugs-CC-ed the s390x porters to help you
> understand why only this architecture is affected.

It's hard to imagine anyone actually trying to use lepton-eda on s390x.
If the porting team for that architecture wants to figure this out,
that's great, but I'd personally be completely comfortable having the
s390x binaries removed from the archive to allow fresher lepton-eda to
migrate to testing.

Bdale


signature.asc
Description: PGP signature

Bug#1006198: docbook: Packaging license incompatible with the upstream

[Joao Eriberto Mota Filho]

Package: docbook
Version: 4.5-9
Severity: normal
X-Debbugs-Cc: Mark W. Eichin , Adam Di Carlo 
, J.H.M. Dassen (Ray) , Yann Dirson 
, Steve Langasek , Daniel Leidert (dale) 
, Jakub Wilk , Mathieu Malaterre 
, Helmut Grohne 

The current packaging license (GPL-2+) is incompatible with upstream
licensing (DocBook License). It is a hampering condition to submit patches
from Debian to the upstream.

I would like to change the packaging licensing to 'DocBook' and I will
wait 15 days to know if anyone has any objection.

Thanks!

Regards,

Eriberto

Bug#1000336: numba: FTBFS with Python 3.10

[Diane Trout]

On Sat, 2022-02-19 at 11:02 +0100, Drew Parsons wrote:
> Source: numba
> Followup-For: Bug #1000336
> 
> onetbb is now building (in experimental) for all arches except
> armel and armhf.
> 
> Is it worth at this point to make an upload of numba 0.55 to
> experimental to check that it's building and passing tests for the
> other arches?

It would... except numpy 1.22 just hit experimental on the 18th. and
numba isn't compatible with numpy 1.22. I tried adding this to
d/control, 

python3-numpy (<< 1.22),

but my sbuild resolver still picked up numpy from experimental and
refused to build.

Upstream has a meta bug with the numpy 1.22 issues.
https://github.com/numba/numba/issues/7754

Bug#1002402: python-sparse: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Diane Trout]

On Mon, 2022-02-21 at 02:24 +, Peter Michael Green wrote:
> > During a rebuild of all packages in sid, your package failed to
> > build
> > on amd64.
>  
>  I'm no expert on this particular package, but this looks to me like
> it is not actually caused by a problem in python-sparse, but is
> instead a symptom of python3-numba not being built against python
> 3.10 due to 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000336
>  

Yep that was my interpretation as well.

Numba 0.55.1 needs libtbb-dev > 2021.04, and 2021.05 is in experimental
getting some weird architectures tested. However libtbb is going to
need a transition.

Unfortunately numpy 0.55.1 breaks with numpy 1.22 which is also in
experimental

Diane

Bug#975911: Seems to have been resolved

[Gerardo Malazdrewicz]

>From https://thrysoee.dk/editline/:

2021-05-22 Jess Thrysoee
* version-info: 0:66:0
* all: sync with upstream source
* src/el.c: editrc not read on systems without issetugid
Patch by Trevor Cordes

bookworm (and later) defaults to old behavior, so does buster with the
libedit2 from bookworm backported.

Also, seems to be a libedit2 issue rather than mariadb-client.

Regards,
 Gerardo

Bug#1003470: openimageio FTBFS: invalid preprocessing directive #errorDCMTK

[Jeremy Bicha]

In Ubuntu, we fixed this issue by building with C++17.

You can find a diff of the rules file at
https://launchpad.net/ubuntu/+source/openimageio/2.2.18.0+dfsg-1ubuntu1

This is needed to complete the libwebp transition:
https://release.debian.org/transitions/html/auto-libwebp.html

Thank you,
Jeremy Bicha

Bug#1006149: cancel message #20

[Felix Miata]

message #20 landed here by mistake in understanding questions in reportbug form.
It was properly sent subsequently as a new report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006166
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Bug#1006197: gpg hangs when importing keys with "gpg: waiting for lock (held by xxxxxxx) (deadlock?)"

[Ron Murray]

Package: gpg
Version: 2.2.27-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   When importing public keys, gpg hangs for several minutes with
something like

gpg: waiting for lock (held by 1308345) (deadlock?) ...

   Process 1308345, in this case, was

1308345 ?RL gpg --disable-dirmngr --batch --no-sk-comments 
--status-fd 21 --no-tty --charset utf8 --enable-progress-filter 
--exit-on-status-write-error --display :0.0 --logger-fd 25 --with-colons 
--with-secret --with-keygrip --list-keys --

   ... and the only other gpg process was

1307658 pts/2SL+0:00 gpg --edit-key 
5B80C5754298F0CB55D8ED6ABCEF7E294B092E28

   I first noticed this problem almost a year ago, but didn't report
it at the time. I looks to me as if process 1308345 is waiting for an
input, but I don't see any prompts or dialog boxes.

   Problem seems to time out eventually, so importing keys is still
(vaguely) possible, so I'm leaving this report marked as "normal".

Thanks,

 .Ron

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

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

Versions of packages gpg depends on:
ii  gpgconf2.2.27-3
ii  libassuan0 2.5.5-1
ii  libbz2-1.0 1.0.8-5
ii  libc6  2.33-6
ii  libgcrypt201.9.4-5
ii  libgpg-error0  1.43-3
ii  libreadline8   8.1.2-1
ii  libsqlite3-0   3.37.2-2
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gpg recommends:
ii  gnupg  2.2.27-3

gpg suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmIS9oYOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52HiAg//eEasBs7zU9MefiCFcmgtg6Oi6hxPkYPlAgrH
b4BA3owGigPA/tEcAoDkY7IfKdslMrPGwV3JWCMh38dE10/yiQ5aAaaw892R+iYL
mIPYoirWFiiaAW5oIFCiYf4JKLi6a1QTdTeuznaz1cJzNo98y00VNa7kuyTuB803
i0pwm4TNJf6e9mezhTKvfg+U6S7BMIsw5RLDTK1uGjDfk8wQ8fD/6ReCSVPqb0W7
fhDfb6epmj7FPv9MfH9RxzScdHtza/js0OCsyp43iMl334nwgt5OACynLcC4FE2g
L2hx8cuTt/Wz2ZqB2j3JhfMqZ6nAdORKDQOO0vJy9kfxjzAclwPjKhzUOpfy10TB
6bxn8UUBTurHeewlBXgrsQxtO7f7VwynD1Ws2PCfPzu7+QfcA3ChMOU5t7DfcqMP
6UuMjQ67ZWSXTSUKLrkLeFiYsvzclQNqDKGCh2I99HuXHJJG2ytMmhCDp8GOiLqt
d4qWQ4D7AjcNhBkMGEtMIfjYeTzjUZmYhc1iP6WSZpebw7my+9v34BDk39lKmNvj
IKDTrvkBICQEU2ufgsF4ef76kzeCKo7xiVyfw4p7hdJJapn3aK7p3IPnAVVkf600
fPadXSjFSPZy9KvwYUc3ijGU7viGqeMQ2tXtesCSOHJqYbOMYUDjWyyDWcf0RfS8
YokE8/E=
=rIFO
-END PGP SIGNATURE-

Bug#1002402: python-sparse: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Peter Michael Green]

During a rebuild of all packages in sid, your package failed to build
on amd64.


I'm no expert on this particular package, but this looks to me like it 
is not actually caused by a problem in python-sparse, but is instead a 
symptom of python3-numba not being built against python 3.10 due to

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

Bug#897069: shutter: SIGSEGV in strlen ()

[Paul Wise]

On Fri, 27 Apr 2018 17:39:09 -0500 Nathaniel Morck Beaver wrote:

> Segfaults upon exit sometimes. Backtrace is attached.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#872855: shutter: Shutter hangs gnome desktop environment when capture

[Paul Wise]

On Mon, 21 Aug 2017 17:17:31 -0300 Manuel A. Chávez M. wrote:

> I'm able to open the application but when trying to capture the
> screen is distorted and the whole desktop environment crashes. I can
> go to a TTY and kill shutter process, in that way I can get back to
> the desktop again.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#820341: shutter: fails to properly minimize to system tray

[Paul Wise]

On Thu, 07 Apr 2016 17:11:02 +0200 Karsten Hilbert wrote:

> Does not appear in system tray when closed via title bar (but stays in
> process list)

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#854380: window no longer disappears after taking a screenshot and clicking the systray icon

[Paul Wise]

On Mon, 06 Feb 2017 15:04:04 +0100 Toni Mueller wrote:

> I have been using shutter for a while, and it used to be the case that
> after taking a screenshot, I could click on the icon in the systray to
> make the window with the screenshots, which appears after taking a
> screenshot, disappear again.
> 
> Since a few weeks, this is no longer the case, and the only way to close
> the window is to use the window manager's functionality to close a
> client window. This is a nuisance from my POV, and I would like to have
> the old behaviour back.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#782181: shutter: The Shutter windows lack distinguishing X roles and instance names

[Paul Wise]

On Thu, 09 Apr 2015 04:46:18 +0200 Tomas Sandven wrote:

> I am trying to configure the way Shutter acts in my i3 window manager. I
> want to specify the main Shutter window, the one with "Session" in the
> title, but all the windows in Shutter have the same X instance name and
> class name, and none of them have a role (WM_WINDOW_ROLE) specified.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#764011: fails to capture with Unexpected short read from authority file

[Paul Wise]

On Sat, 04 Oct 2014 15:21:10 -0400 Antoine Beaupré wrote:

> Shutter now fails to perform simple screenshots in Jessie.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#761058: shutter: GLib-CRITICAL **: Source ID 29 was not found when attempting to remove it at /usr/bin/shutter line 7247

[Paul Wise]

On Wed, 10 Sep 2014 13:28:02 +0200 0 1  wrote:

> I start shutter.
> I try to use any capture mode (selecting a window, fullscreen...)
> A message pops up:
> "Erreur lors de la capture.
> Le clavier ne peut pas être capturer"

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#755278: shutter: Ram usage

[Paul Wise]

On Sat, 19 Jul 2014 16:34:34 +0200 MrToc wrote:

> I have a pb using Shutter, I frequently encounter the same pb, after few
> minutes my RAM is full (8Go / 2Go  used in general).
> This time I had 2 screenshots
> I don't know why it happened. I must close shuteer each time. I often use
> plugin to export screenshots but I don't think it's the pb.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#717220: shutter: Text is readable under Pixelizer (has less than 100% opacity)

[Paul Wise]

On Thu, 18 Jul 2013 03:45:29 +0200 Alois Mahdal wrote:

> Recently I discovered that Pixelizer from the Shutter editor does not
> reliably render the data unreadable.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#717219: shutter: Make it harder to move the base picture

[Paul Wise]

On Thu, 18 Jul 2013 03:36:49 +0200 Alois Mahdal wrote:

> I use shutter almost daily, and while it's really a great tool, there's
> one thing that has kept bugging me for a while:
> 
> In the editor, it's really easy to "shoot yourself in the foot" by
> moving the base picture a few bits, which, apart from misalignments with
> other items, can cause ugly border on sides.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#551891: shutter: Cannot capture from multi-monitor

[Paul Wise]

On Wed, 21 Oct 2009 16:32:38 +0200 Christoph Haas wrote:

> Shutter is the nicest screenshot program I have ever seen. But there is
> one little issue. I'm using two monitors and when I want to make a
> screenshot then shutter takes the contents of my left monitor, puts it
> onto the right monitor and allows me to select the region I'd like to
> capture there. The left monitor remains dark during that operation.

A new version of shutter was reintroduced into Debian unstable. Please
install it and check if the issue still occurs. If it still occurs,
please file a new bug with the upstream project on GitHub and let us
know the bug URL or mark the bug as forwarded yourself. If the issue no
longer occurs please let us know or close the bug yourself.

https://shutter-project.org/contribute/
https://www.debian.org/Bugs/server-control
https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1006196: mozjs91: FTBFS on mipsel (eller): non262/regress/regress-303213.js: out of memory

[Simon McVittie]

On Sun, 20 Feb 2022 at 23:59:14 +, Simon McVittie wrote:
> I tried building mozjs on the mips(64)el porterbox 'eller' to test my
> earlier commit that resolved a build failure, and it now fails on eller
> with a test failure instead:
...
>  FAILED!  integer overflow in js : Expected value 'InternalError: allocation 
> size overflow', Actual value 'out of memory'

I'm testing a possible patch.

smcv

Bug#1006152: mozjs91: FTBFS on i386: test262/built-ins/Date/UTC/fp-evaluation-order.js

[Simon McVittie]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1755531

On Sat, 19 Feb 2022 at 22:38:34 +, Simon McVittie wrote:
> After applying patches to fix compilation on i386 and mipsel (see commits
> 3f0f229d, 585dadd4) there is a test failure unresolved on i386:
> 
> ## test262/built-ins/Date/UTC/fp-evaluation-order.js: rc = 3, run time = 
> 0.022397
> /home/smcv/mozjs/js/src/tests/test262/shell.js:415:9 uncaught exception: 
> Test262Error: order of operations / precision in MakeTime Expected 
> SameValue(«29256», «29312») to be true
> Stack:
>   Test262Error.thrower@/home/smcv/mozjs/js/src/tests/test262/shell.js:415:9
>   assert.sameValue@/home/smcv/mozjs/js/src/tests/test262/shell.js:51:9
>   
> @/home/smcv/mozjs/js/src/tests/test262/built-ins/Date/UTC/fp-evaluation-order.js:19:8
> TEST-UNEXPECTED-FAIL | test262/built-ins/Date/UTC/fp-evaluation-order.js | 
> (args: "") [0.0 s]

I think this is the same thing Marco reported in
.

I'm testing a patch (basically just extending Marco's workaround to
apply to i386 too). If successful, I'll downgrade the severity of this bug
but leave it open.

smcv

Bug#1004811: survex: FTBFS with ffmpeg 5.0

[Olly Betts]

Control: tags -1 + fixed-upstream

On Tue, Feb 01, 2022 at 11:19:04PM +0100, Sebastian Ramacher wrote:
> survex FTBFS with ffmpeg 5.0 in experimental:

I've pushed a fix for this upstream (commit
44c4b7054885c2a5f25692547bf45fa33bcba1e8).

It looks like there are a huge number of packages still blocking the
transition so my plan is to just pick up this fix with the next upstream
release in the interests of avoiding creating more things to do for
myself.

Cheers,
Olly

Bug#1006196: mozjs91: FTBFS on mipsel (eller): non262/regress/regress-303213.js: out of memory

[Simon McVittie]

Source: mozjs91
Version: 91.6.0-1
Severity: serious
Tags: ftbfs

I tried building mozjs on the mips(64)el porterbox 'eller' to test my
earlier commit that resolved a build failure, and it now fails on eller
with a test failure instead:

## non262/regress/regress-303213.js: rc = 0, run time = 0.147349
BUGNUMBER: 303213
STATUS: integer overflow in js
STATUS: This bug passes if no crash occurs
--- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 0 ---
--- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 5 ---
STATUS: done generating
 FAILED!  integer overflow in js : Expected value 'InternalError: allocation 
size overflow', Actual value 'out of memory'
TEST-UNEXPECTED-FAIL | non262/regress/regress-303213.js | (args: "") [0.1 s]

I think some other tests have already been adjusted to accept either of
these messages as being OK?

smcv

Bug#1006195: zchunk: Import new version

[Bastian Germann]

Source: zchunk

Please import the latest version, which is 1.2.0 currently.

Bug#1006194: foot - arch all build failure

[Peter Michael Green]

Package: foot
Version: 1.11.0-1
Tags: ftbfs

The arch all build of foot failed, this is preventing the new version 
from migrating to

testing, which is needed to complete the fcft transition.


dh_missing -i
dh_missing: warning: usr/share/zsh/site-functions/_foot exists in debian/tmp 
but is not installed to anywhere
dh_missing: warning: usr/share/zsh/site-functions/_footclient exists in 
debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: foot (8), foot-terminfo (1), foot-themes (1)
 * dh_installdocs: foot (0), foot-terminfo (0), foot-themes (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
make: *** [debian/rules:6: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit 
status 2
Note that Debian build infrastructure performs arch all only builds 
(dpkg-buildpackage -A).

Bug#1006193: Remove luit, now packaged separately

[Brendan O'Dea]

Package: x11-utils
Version: 7.7+5
Severity: normal
Tags: patch
X-Debbugs-Cc: b...@debian.org

Merge request to remove luit from x11-utils:

  https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1

now packaged separately, this commit removes luit and adds a recommends for
the new package.

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

Kernel: Linux 5.16.0-1-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-utils depends on:
ii  libc6   2.33-6
ii  libfontconfig1  2.13.1-4.4
ii  libfontenc1 1:1.1.4-1
ii  libgl1  1.4.0-1
ii  libx11-62:1.7.2-2+b1
ii  libx11-xcb1 2:1.7.2-2+b1
ii  libxaw7 2:1.0.13-1.1
ii  libxcb-shape0   1.14-3
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxext62:1.3.4-1
ii  libxft2 2.3.2-2
ii  libxi6  2:1.8-1
ii  libxinerama12:1.1.4-3
ii  libxkbfile1 1:1.1.0-1
ii  libxmu6 2:1.1.3-3
ii  libxmuu12:1.1.3-3
ii  libxrandr2  2:1.5.2-1
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.2.1-1
ii  libxtst62:1.2.3-1
ii  libxv1  2:1.0.11-1
ii  libxxf86dga12:1.1.4-1+b3
ii  libxxf86vm1 1:1.1.4-1+b2

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information

Bug#1006192: bullseye-pu: package espeak-ng/1.50+dfsg-7+deb11u1

[Samuel Thibault]

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

Hello,

I'd like to upload the attached changes to bullseye (already queued)

[ Reason ]
People have reported that when they work on the linux console with the
espeakup screen reader, if they e.g. cat a long file, and the reader
starts speaking it, and the user presses some key to interrupt the read,
the screen reader remains silent for several seconds before it speaks
anything again. That is because the speaking events for all the file
reading have still been queued and the speak cancellation just makes
them processed very quickly to flush the queue. Unfortunately there is a
little usleep(50ms) that is performed on each event processing. This is
a very old trick that was probably browntape-fixing some erroneous
condition. We tried to remove that sleep and it didn't seem to have any
nasty side effect. Upstream did commit the change and users are really
happy with the change that completely fixes the delay.

[ Impact ]
Any action that creates long outputs (catting a long file, running
dmesg, listing a long directory, etc.) introduce long latency even when
the user wants to stop the speaking.

[ Tests ]
This was tested manually by the reporters.

[ Risks ]
The code by itself is trivial. The sleep was probably meant to "fix"
something but it seems that that something doesn't exist any more.

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

[ Changes ]
This just removes a spurious sleep.
diff -Nru espeak-ng-1.50+dfsg/debian/changelog 
espeak-ng-1.50+dfsg/debian/changelog
--- espeak-ng-1.50+dfsg/debian/changelog2020-08-02 01:26:35.0 
+0200
+++ espeak-ng-1.50+dfsg/debian/changelog2022-02-13 02:41:25.0 
+0100
@@ -1,3 +1,10 @@
+espeak-ng (1.50+dfsg-7+deb11u1) bullseye; urgency=medium
+
+  * patches/even-delay: Drop spurious 50ms delay while processing events, this
+adds potentially very long latency to canceling speech.
+
+ -- Samuel Thibault   Sun, 13 Feb 2022 02:41:25 +0100
+
 espeak-ng (1.50+dfsg-7) unstable; urgency=medium
 
   * patches/no-common: Fix build with gcc-10 (Closes: Bug#957181).
diff -Nru espeak-ng-1.50+dfsg/debian/patches/event-delay 
espeak-ng-1.50+dfsg/debian/patches/event-delay
--- espeak-ng-1.50+dfsg/debian/patches/event-delay  1970-01-01 
01:00:00.0 +0100
+++ espeak-ng-1.50+dfsg/debian/patches/event-delay  2022-02-13 
02:41:25.0 +0100
@@ -0,0 +1,29 @@
+https://github.com/espeak-ng/espeak-ng/pull/1077
+
+commit 977bff9a061fbd6b44835a6ce45ad887634ae068
+Author: Samuel Thibault 
+Date:   Sun Feb 13 02:54:00 2022 +0100
+
+event_notify: Remove spurious 50ms delay
+
+event_notify currently introduces an arbitrary 50ms delay between speech
+requests. This is usually unnoticed since it's small. But when
+cancelling a long series of events, they add up to potentially seconds
+of delays, while the user was precisely requesting to just cancel
+everything as fast as possible.
+
+This 50ms delay was probably meant to work around some issues elsewhere.
+If they are still there, they should be fixed, not worked around.
+
+diff --git a/src/libespeak-ng/event.c b/src/libespeak-ng/event.c
+index acf3a39e..5561fdbc 100644
+--- a/src/libespeak-ng/event.c
 b/src/libespeak-ng/event.c
+@@ -161,7 +161,6 @@ static void event_notify(espeak_EVENT *event)
+   events[0].type = espeakEVENT_SENTENCE;
+   my_callback(NULL, 0, events);
+   events[0].type = a_new_type;
+-  usleep(5);
+   }
+   my_callback(NULL, 0, events);
+   a_old_uid = event->unique_identifier;
diff -Nru espeak-ng-1.50+dfsg/debian/patches/series 
espeak-ng-1.50+dfsg/debian/patches/series
--- espeak-ng-1.50+dfsg/debian/patches/series   2020-04-18 22:16:12.0 
+0200
+++ espeak-ng-1.50+dfsg/debian/patches/series   2022-02-13 02:41:25.0 
+0100
@@ -6,3 +6,4 @@
 greek-rules
 fix-tests-bash
 no-common
+event-delay
diff -Nru espeak-ng-1.50+dfsg/debian/salsa-ci.yml 
espeak-ng-1.50+dfsg/debian/salsa-ci.yml
--- espeak-ng-1.50+dfsg/debian/salsa-ci.yml 1970-01-01 01:00:00.0 
+0100
+++ espeak-ng-1.50+dfsg/debian/salsa-ci.yml 2022-02-13 02:41:25.0 
+0100
@@ -0,0 +1,10 @@
+---
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  SALSA_CI_DISABLE_VERSION_BUMP: 1
+  RELEASE: bullseye
+
+# vim: ts=2 sw=2 et sts=2 ft=yaml

Bug#1005838: jameica: Unsupported connection setting "MVCC" [90113-210]

[Jochen Sprickerhof]

Control: reassign -1 libh2-java
Control: forcemerge 1006140 -1

Hi Thomas,

thanks for opening the bug and sorry for not answering earlier. I have 
uploaded a reverted version (2.1.210+really1.4.197-1) of the h2database 
to unstable as part of #1006140 so jameica should work again for you. It 
could be that you need to load a backup of the database, jameica should 
instruct you in that case.


I'm planing to implement a migration strategy before uploading the new 
h2 version again.


Cheers Jochen


* Thomas Renard  [2022-02-15 21:14]:

Package: jameica
Version: 2.10.1+dfsg-1
Severity: important

Dear Maintainer,

Jameica/Hibiscus starts up but has a break with error:

Unsupported connection setting "MVCC" [90113-210]

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

  * What led up to the situation?
  according to  https://github.com/h2database/h2database/issues/2198
  probably todays update of libh2-java to 2.1.210-1
  * What exactly did you do (or not do) that was effective (or
ineffective)?
* apt upgrade
* startup jameica from desktop
* log in to you hibiscus session
* jameica window opens
  * What was the outcome of this action?
  No hibiscus environment but the error message above
  * What outcome did you expect instead?
  Hibiscus starts up as normal.

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


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 jameica depends on:
ii  libactivation-java1.2.0-2
ii  libbcpkix-java1.68-5
ii  libbcprov-java1.68-5
ii  libcommons-cli-java   1.4-2
ii  libcommons-collections3-java  3.2.2-2
ii  libcommons-lang-java  2.6-9
ii  libcommons-logging-java   1.2-2
ii  libeclipse-core-commands-java 3.10.100+eclipse4.21-1
ii  libeclipse-core-runtime-java  3.20.100+eclipse4.19-1
ii  libeclipse-jface-databinding-java 1.13.0+eclipse4.21-1
ii  libeclipse-osgi-java  3.17.0+eclipse4.21-1
ii  libeclipse-ui-forms-java  3.11.200+eclipse4.21-1
ii  libequinox-common-java3.14.100+eclipse4.19-1
ii  libgeronimo-annotation-1.3-spec-java  1.3-1
ii  libh2-java2.1.210-1
ii  libicu4j-java 68.2-2
ii  libistack-commons-java3.0.6-5
ii  libjameica-datasource-java2.8.1+dfsg-4
ii  libjameica-util-java  2.8-3
ii  libjaxb-api-java  2.3.1-1
ii  libjaxb-java  2.3.0.1-10
ii  libmariadb-java   2.7.4-1
ii  libmckoisqldb-java1.0.6-4
ii  libnanoxml2-java  2.2.3.dfsg-9
ii  liboro-java   2.0.8a-14
ii  libpaperclips-java1.0.4-3
ii  libswt-cairo-gtk-4-jni4.20.0-2
ii  libswtcalendar-java   0.5-3
ii  libtxw2-java  2.3.0.1-10
ii  velocity  1.7-6

jameica recommends no packages.

jameica suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1004459: bullseye-pu: package lxc/1:4.0.6-2+deb11u1

[Antonio Terceiro]

On Sat, Feb 19, 2022 at 06:53:52PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2022-01-27 at 21:32 -0300, Antonio Terceiro wrote:
> > This update fixes the download of container images using the
> > "download"
> > template. pool.sks-keyservers.net is not active anymore, so the patch
> > (already included in the upstream release present in sid/bookworm)
> > changes that to keyserver.ubuntu.com.
> > 
> 
> +  * lxc-download: Switch GPG server.
> +The default server used to download gpg keys from has ben deprecated,
> 
> s/ben/been/
> 
> Please go ahead.

Uploaded with that typo fixed. Thanks.


signature.asc
Description: PGP signature

Bug#1005920: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1005920: fixed in coq-doc 8.15.0-2)

[Andreas Beckmann]

Control: found -1 8.15.0-2

This looks like more missing Build-Depends(-Indep):

[...]
Running[3870]: (cd _build/default/doc && /usr/bin/env sphinx-build -q -W -b 
html sphinx refman-html)
Running[3871]: (cd _build/default/doc && /usr/bin/env sphinx-build -q -W -b 
latex sphinx refman-pdf)
Command [3870] exited with code 2:
$ (cd _build/default/doc && /usr/bin/env sphinx-build -q -W -b html sphinx 
refman-html)

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 329, in 
eval_config_file
exec(code, namespace)
  File "/build/coq-doc-8.15.0/_build/default/doc/sphinx/conf.py", line 245, in 

import sphinx_rtd_theme
ModuleNotFoundError: No module named 'sphinx_rtd_theme'

Command [3871] exited with code 2:
$ (cd _build/default/doc && /usr/bin/env sphinx-build -q -W -b latex sphinx 
refman-pdf)

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 329, in 
eval_config_file
exec(code, namespace)
  File "/build/coq-doc-8.15.0/_build/default/doc/sphinx/conf.py", line 245, in 

import sphinx_rtd_theme
ModuleNotFoundError: No module named 'sphinx_rtd_theme'

make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1


Andreas

Bug#1006028: php-crypt-gpg: FTBFS: PHPUnit\Framework\Exception: PHP Fatal error: Uncaught Crypt_GPG_BadPassphraseException: Cannot export private key. Incorrect passphrase provided for keys: "First Ke

[Lucas Nussbaum]

On 19/02/22 at 11:04 +0100, Guilhem Moulin wrote:
> Control: tag -1 moreinfo
> 
> On Sat, 19 Feb 2022 at 07:38:04 +0100, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> 
> Seems like a false-positive to me.  It does build here, and also did
> build on the buildds [0] (and Salsa CI too).  Perhaps that test is
> unreliable though, in which case we should mark it as such or skip it.

Ah, I see that you fixed it in the meantime.
I confirm that 1.6.7-2 builds fine (in the same environment).

Lucas

Bug#1005288: bullseye-pu: package sphinx-bootstrap-theme/0.7.1-1+deb11u1

[Antonio Terceiro]

On Sat, Feb 19, 2022 at 05:41:40PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2022-02-15 at 21:33 -0300, Antonio Terceiro wrote:
> > Control: reopen -1
> > 
> > > On Thu, Feb 10, 2022 at 11:44:24AM -0300, Antonio Terceiro wrote:
> > > > [ Reason ]
> > > > Version 0.8.0-1 contains a bug caused by extra whitespace in
> > > > src=""
> > > > attributes of 

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:35:23 +, Simon McVittie wrote:
> GTK with merge request 6 (full backport from 3.24.29)
...
> With cups-browsed only: Two printers appear, labelled
> HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.

This seems to be a mismatch between the transformation from DNS-SD
name in recent versions of cups-browsed (for which modern GTK's code is
correct) and older versions of cups-browsed such as the one in Debian 11
(for which an additional patch is needed). I'm now preparing variants
of merge requests 6 and 9 that have this additional patch.

smcv

Bug#1006190: New upstream release

[MichaIng]

Package: clonezilla
Version: 3.35.2-3

Dear maintainer,

the last Clonezilla upstream release has been applied to Debian a long 
time ago. In the meantime there have been many releases, latest at time 
of writing bring v5.0.3:

https://gitlab.com/stevenshiau/clonezilla/-/blob/master/clonezilla.spec

It provides many new features, including one I personally require: 
support for loop devices.


Would it be possible to provide a new Debian build via unstable suite?

Best regards,

Micha

Bug#1006189: /usr/bin/xdg-mime: `xdg-mime query default` blindly greps through .desktop files

[Frédéric Brière]

Package: xdg-utils
Version: 1.1.3-4.1
Severity: normal
File: /usr/bin/xdg-mime

Demonstrating under XFCE (though I think it affects all but KDE):

  $ cat /usr/local/share/applications/foobar.desktop 
[Desktop Entry]
# blah blah blah text/unreadable; blah x-scheme-handler/foo; blah blah blah
Name=FooBar
Type=Application
Exec=/bin/true

  $ xdg-mime query default text/unreadable
foobar.desktop
  $ xdg-mime query default x-scheme-handler/foo
foobar.desktop


Basically, search_desktop_file() just blindly greps through every
.desktop file, returning any that matches, regardless of context.  That
is, erm, unexepected, to say the least.  (It at least explains why
commenting out MimeType wasn't showing any effect.)



-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=

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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.31-1
pn  libnet-dbus-perl   
pn  libx11-protocol-perl   
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+9

xdg-utils suggests no packages.

-- no debconf information

Bug#1005448: ruby-certificate-authority: FTBFS: ERROR: Test "ruby3.0" failed: NoMethodError:

[Antonio Terceiro]

Control: forwarded -1 
https://github.com/cchandler/certificate_authority/issues/61

I tried updating to the latest upstream release, and this issue is still
there. It's caused by the fact that ruby3.0 now carries version 3.0.0 of
the openssl ruby extension, and this packages is not compatible with it
yet.


signature.asc
Description: PGP signature

Bug#964785: Package accepted

[Sebastian Geiger (Lanoxx)]

Hi all,

the shutter 0.99.2-3 package was accepted into unstable [1]. Thanks to
everyone who helped to make this possible. If I am not mistaken, then
packages automatically migrate to testing after 7 days in unstable. We
might just barely miss the Debian Import Freeze for Ubuntu 22.04 which
starts on 24.02 [2]. I think once the package has migrated to testing we
could ask for a freeze exception on the Ubuntu side [3] and then shutter
would finally be back to both Debian and Ubuntu.

[1]:
https://packages.debian.org/search?suite=all&searchon=names&keywords=shutter

[2]: https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906

[3]: https://wiki.ubuntu.com/FreezeExceptionProcess

Bug#1006188: nmu: pqiv_2.12-1

[Jeremy Bicha]

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

pqiv has a Recommends on the old libwebp6 library. The Recommends
doesn't show up on the transition tracker but it should still be
rebuilt.

nmu pqiv_2.12-1 . ANY . unstable . -m "Rebuild against
libwebp7"

Thanks,
Jeremy Bicha

Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Andreas Tille]

Cool!  This finally works.  Thanks a lot for your patience, Andreas.

Am Sun, Feb 20, 2022 at 09:43:10AM -0800 schrieb Chris Chang:
> Hmm.  Ordinarily, that download link would be fine.  I had not updated it
> this time because the issue only affects gcc 11+, so it did not affect any
> of the precompiled binaries and I wanted to keep the posted source
> identical to that used to compile those binaries.
> 
> On the other hand, the only difference (in the non-gcc-11+ case) between
> the binaries and the updated source is the version date.  I guess this is
> insignificant enough that a temporary discordance is less disruptive than
> making you change your packing process, so I've updated the website source
> link to point to the newer code; let me know if you still run into any
> problems.
> 
> On Sat, Feb 19, 2022 at 11:53 PM Andreas Tille  wrote:
> 
> > Hi Chris,
> >
> > Am Sat, Feb 19, 2022 at 11:37:34PM -0800 schrieb Chris Chang:
> > > To elaborate: when I look at
> > > https://salsa.debian.org/med-team/plink2/-/tree/master , I can see that
> > > plink2.cc, include/plink2_base.h, and include/plink2_base.cc don't have
> > the
> > > same contents as the v2.00a3-20220218 GitHub tag/release.  So I don't
> > know
> > > where you grabbed the code from this time, but it does not appear to be
> > > from GitHub.
> >
> > That's true since on Github the source code of plink1.9 and plink2 is not
> > separated.  Thus I download the tarball from
> >
> >https://www.cog-genomics.org/plink/2.0/
> >
> > which points to
> >
> >https://www.cog-genomics.org/static/bin/plink2_src_220217.zip
> >
> > I confirm that the tag on Github says v2.00a3-20220218 which seems to be
> > later than 220217.  In principle I could point the packaging metadata to
> > Github and exclude everything that I do not need for plink2 packaging (so
> > remove 1.9 directory and code copies of libdeflate, simde and zstd in 2.0)
> >
> > In case you consider this the safer way to download plink2 code I'll do so.
> >
> > Kind regards and thanks a lot for comparing the code base
> >
> >  Andreas.
> >
> > > On Sat, Feb 19, 2022 at 7:54 AM Chris Chang 
> > wrote:
> > >
> > > > If you build off the current head, the version string should say "18
> > Feb
> > > > 2022", not "17 Feb 2022".
> > > >
> > > > On Sat, Feb 19, 2022 at 7:02 AM Andreas Tille 
> > wrote:
> > > >
> > > >> Hi again,
> > > >>
> > > >> Am Sat, Feb 19, 2022 at 12:28:21AM -0800 schrieb Chris Chang:
> > > >> > Ok, new release/tag created.
> > > >>
> > > >> I've built the new version now.  The bad news is that it keeps on
> > > >> SEGFAULTing for me:
> > > >>
> > > >> ...
> > > >> (gdb) run
> > > >> Starting program: /usr/lib/plink2/plink2-sse3 --debug --pfile tmp_data
> > > >> --export vcf vcf-dosage=DS --out tmp_data2
> > > >> [Thread debugging using libthread_db enabled]
> > > >> Using host libthread_db library
> > "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > > >> [New Thread 0x74cc7640 (LWP 985019)]
> > > >> [New Thread 0x744c6640 (LWP 985020)]
> > > >> [New Thread 0x7fffebcc5640 (LWP 985021)]
> > > >> PLINK v2.00a3 64-bit (17 Feb 2022)
> > > >> www.cog-genomics.org/plink/2.0/
> > > >> (C) 2005-2022 Shaun Purcell, Christopher Chang   GNU General Public
> > > >> License v3
> > > >> Logging to tmp_data2.log.
> > > >> Options in effect:
> > > >>   --debug
> > > >>   --export vcf vcf-dosage=DS
> > > >>   --out tmp_data2
> > > >>   --pfile tmp_data
> > > >>
> > > >> Start time: Sat Feb 19 16:00:00 2022
> > > >> 31998 MiB RAM detected; reserving 15999 MiB for main workspace.
> > > >> Using up to 4 compute threads.
> > > >> [New Thread 0x77fc5640 (LWP 985022)]
> > > >>
> > > >> Thread 1 "plink2-sse3" received signal SIGSEGV, Segmentation fault.
> > > >> plink2::LoadPsam (psamname=psamname@entry=0x7fffbe60
> > > >> "tmp_data.psam", pheno_range_list_ptr=, fam_cols=...,
> > > >> pheno_ct_max=,
> > > >> missing_pheno=, affection_01=0, max_thread_ct=4,
> > > >> piip=0x7fff8870, sample_include_ptr=0x7fff8790,
> > > >> founder_info_ptr=0x7fff87a8, sex_nm_ptr=0x7fff8798,
> > > >> sex_male_ptr=0x7fff87a0, pheno_cols_ptr=0x7fff8770,
> > > >> pheno_names_ptr=0x7fff8780, raw_sample_ct_ptr=0x7fff8728,
> > > >> pheno_ct_ptr=0x7fff8720,
> > > >> max_pheno_name_blen_ptr=0x7fff87b0) at ../plink2_psam.cc:611
> > > >> 611 pheno_cols[pheno_idx].nonmiss = nullptr;
> > > >>
> > > >>
> > > >> Please let me know if I can do further checks.
> > > >>
> > > >> Kind regards
> > > >>
> > > >>   Andreas.
> > > >>
> > > >> --
> > > >> http://fam-tille.de
> > > >>
> > > >
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Bug#1006187: bullseye-pu: package espeakup/0.80-20+deb11u1

[Samuel Thibault]

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

Hello,

I would like to upload the attached change to bullseye (already uploaded
to the queue).

[ Reason ]
Users have reported that when they are building large packages in
parallel, or generally loading the system a bit, the espeakup screen
reader becomes very laggy. This is because espeakup gets scheduled only
along other the parallel processes. Worse, if the system goes OOM,
espeakup might get killed by the OOM killer.

This is not a regression with respect to previous releases.

In the case of the brltty screen reader, we fixed this by making brltty
niced to -10 and its OOM score set to -900.

[ Impact ]
Users will keep seeing their screen reader potentially harmed by system
overload.

[ Tests ]
This was tested manually, and users reported that they can now load
their system without seeing the screen reader getting laggy.

[ Risks ]
The code is very trivial: two obvious lines of systemd service.

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

[ Changes ]
This just sets the nice level to -10 and the OOM score to -900 for the
espeakup service.
diff -Nru espeakup-0.80/debian/changelog espeakup-0.80/debian/changelog
--- espeakup-0.80/debian/changelog  2021-04-04 14:33:26.0 +0200
+++ espeakup-0.80/debian/changelog  2022-01-08 16:59:23.0 +0100
@@ -1,3 +1,9 @@
+espeakup (1:0.80-20+deb11u1) stable; urgency=medium
+
+  * debian/espeakup.service: Protect espeakup from system overloads.
+
+ -- Samuel Thibault   Sat, 08 Jan 2022 16:59:23 +0100
+
 espeakup (1:0.80-20) unstable; urgency=medium
 
   * espeakup-udeb.finish-install: Carry over the alsa mixer levels into the
diff -Nru espeakup-0.80/debian/espeakup.service 
espeakup-0.80/debian/espeakup.service
--- espeakup-0.80/debian/espeakup.service   2020-04-29 02:48:49.0 
+0200
+++ espeakup-0.80/debian/espeakup.service   2022-01-08 16:59:23.0 
+0100
@@ -12,6 +12,8 @@
 ExecStart=/bin/sh -c 'modprobe speakup_soft && /usr/bin/espeakup -V "${VOICE}"'
 ExecReload=/bin/kill -HUP $MAINPID
 Restart=always
+Nice=-10
+OOMScoreAdjust=-900
 
 [Install]
 WantedBy=sound.target

Bug#1003611: Acknowledgement (systemd: Upgrade from 249.7 to 250.2 seems to have crashed the systemd root process, leaving system unstable)

[Michael Biebl]

On Wed, 12 Jan 2022 19:54:15 +0100 Michael Biebl  wrote:

Am 12.01.22 um 19:34 schrieb Christian Weeks:
> I have attached the journal from the 10 minutes prior. I was trying to mount a
> CD in an external CD rom drive at the time. It seems that something went wrong
> and killed systemd. I apparently didn't notice for another 10 days. /facepalm
> 
> I have the core file, if you want me to analyze it somehow, just tell me what to

> do.

To get a useful backtrace, you'll probably need a chroot, where you 
install systemd 249.7-1 + dbgsym packages.

Then run gdb /lib/systemd/systemd 

Then run "bt full" to get a backtrace.


Did you have a chance to produce such a backtrace?

Without it, there is practically no chance that this can be further 
investigated.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006186: RM: gnome-desktop3 -- RoM; duplicate source package; dak rm -S

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: gnome-deskt...@packages.debian.org

The gnome-desktop3 source package has been renamed to gnome-desktop.
(This was done because the latest release includes both a gtk3 and
gtk4 library but eventually new releases will drop the gtk3 library.
Since that will probably happen before all Debian packages have been
moved to the gtk4 library, we will probably need to keep the latest
gtk3 version around and we can use the gnome-desktop3 source package
for it then.)

Please remove the source package only. The binary packages are now
built by gnome-desktop instead.

dak rm -S gnome-desktop3

Thank you,
Jeremy Bicha

Bug#1006171: Make internal-sftp the default

[Colin Watson]

On Sun, Feb 20, 2022 at 02:46:50PM +0100, MichaIng wrote:
> Currently the standalone OpenSSH sftp-server is used as default SFTP
> subsystem, set via /etc/ssh/sshd_config. This implies a dependency on the
> openssh-sftp-server package and means that every SFTP connection spawns a
> new external process, while sshd ships with the internal-sftp in-process
> SFTP server, which perform better when dealing with many short duration
> connections and simplifies the ChrootDirectory usage to not require any
> manual /dev node setup.
> 
> Legacy SSH1 clients pass an exact SFTP command, hence will still depend on
> openssh-sftp-server or any alternative standalone SFTP server, also
> internal-sftp means that the login shell is skipped in the first place. But
> the need for both are edge cases, the use of SSH1 IMO worth to be actively
> discouraged, and the vast majority of OpenSSH SFTP server admins will
> benefit from this change, at least to not require a config change that is
> part of very most SFTP guides around the internet, reasonably.

I haven't done this mainly because if the default is to be changed it
should be changed upstream; they're better placed to be aware of corner
cases that might cause regressions if changing the default.  I'd
encourage you to file this on https://bugzilla.mindrot.org/ instead.

(SSH 1 is not an issue, since the code to support it has been removed
from the server anyway, so you should probably omit that part from your
upstream report.)

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1006185: shunit2: newer upstream version 2.1.8

[tony mancill]

Package: shunit2
Version: 2.1.6-1.2
Severity: minor

Dear Maintainer,

shunit2 upstream is active again and newer upstream release includes
some new assertions - for example, "assertContains" - that make it
easier to write unit-tests.  It would be nice to get the latest version
into Debian during the bookworm release cycle.

  https://github.com/kward/shunit2/releases

Thank you for maintaining shunit2.  I am using it in autopkgtests.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#995230: [Pkg-rust-maintainers] Bug#995230: Bug#995230: ripgrep: add autocompletion for bash

[Sylvestre Ledru]

Le 20/02/2022 à 20:24, Florian Ernst a écrit :
> On Sun, Feb 20, 2022 at 06:42:54PM +0100, Sylvestre Ledru wrote:
>> Le 20/02/2022 à 14:25, Florian Ernst a écrit :
>>> In commit 7f0d6ae of rust-team/debcargo-conf the corresponding "--with
>>> bash-completion" was dropped, most presumably by accident. As such bash
>>> autocompletion was missing ever since 13.0.0-1. Readding that part
>>> brings back the missing file:
>>> [...]
>> It seems. Would you like to provide a MR ?
> Truth be told, I actively avoided the formal overhead of a MR for such a
> tiny change. Feel free to just fix it in git.
>
> However, if some policy of sorts requires a MR I will file one. If it's
> just for attribution, though, I personally see no need.

i didn't realize that you are a DD :)

sorry

S

Bug#990201: CVE-2021-33622 (was: Re: Accepted singularity-container 3.9.5+ds1-1 (source) into experimental)

[Nilesh Patra]

Hi Salvatore,

On Sun, Feb 20, 2022 at 08:01:34PM +0100, Salvatore Bonaccorso wrote:
> >[ Andreas Tille ]
> >* Team upload.
> >* Version > 3.6.x are closing CVE-2021-33622
> >  Closes: #990201
> 
> Can you help isolate on that?
> https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622-
> refers the 3.6.x as beeing affected and so there is the statement that
> the issue is not going to be patched in those version:
> 
> > This issue affects open-source Singularity 3.5.x and 3.6.x. These
> > versions are no longer supported and will not be patched.

Yes, but in the same bug link, this is written as well:

| Affected Versions
| Singularity 3.5.x - 3.6.x, SingularityPRO <3.5-8.

And so I thought it has been fixed in later versions.

> https://bugs.debian.org/990201#10 is as well relevant in the context.

Since Andreas added this entry, I suppose he somehow forgot
about his own findings about the problem; and I did not scrutinize much
before upload (as this was not building and that was my primary focus)

> So where has this issue bin fixed?

But yes, you are right, even at Mitre metadata, I do not find any information
about any patch for the bug; i.e. I do not see the "code" that fixes it, and 
hence
I too am skeptical whether or not it is really gone.

For the sake of completeness, I have opened a issue upstream[1]

[1]: https://github.com/sylabs/singularity/issues/586
 
Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1006184: avogadro: atom editing is broken

[Aritz Erkiaga]

Package: avogadro
Version: 1.95.1-2
Severity: important
Tags:|patch, fixed-upstream|

This bug is described in detail 
at:https://github.com/OpenChemistry/avogadrolibs/issues/820


Bonding atoms manually creates a corrupted molecule.



1. Open Avogadro
2. Place two carbon atoms (should create two methane molecules).
3. Click on one of the carbons and drag cursor to the other.
4. Release cursor to create bond.



Missing hydrogens around the first atom is not the only issue; trying to
add another carbon atom instead moves one of the remaining hydrogens to
the clicked location. Doing so many times crashes Avogadro 2.


It's confirmed to be a 1.95.1 regression.

The bug is fixed in this commit:
https://github.com/OpenChemistry/avogadrolibs/commit/c47d00c821ba77ea2b13aaa933cfc922f1980469

The commit is a one-line change fixing a typo that was causing the 
aforementioned problems.
It's entirely self-contained and unlikely to cause additional trouble.

It was merged in the following pull 
request:https://github.com/OpenChemistry/avogadrolibs/pull/819
No new versions of the package have been published yet by the upstream 
developers.

Bug#995230: [Pkg-rust-maintainers] Bug#995230: ripgrep: add autocompletion for bash

[Florian Ernst]

On Sun, Feb 20, 2022 at 06:42:54PM +0100, Sylvestre Ledru wrote:
> Le 20/02/2022 à 14:25, Florian Ernst a écrit :
> > In commit 7f0d6ae of rust-team/debcargo-conf the corresponding "--with
> > bash-completion" was dropped, most presumably by accident. As such bash
> > autocompletion was missing ever since 13.0.0-1. Readding that part
> > brings back the missing file:
> > [...]
> It seems. Would you like to provide a MR ?

Truth be told, I actively avoided the formal overhead of a MR for such a
tiny change. Feel free to just fix it in git.

However, if some policy of sorts requires a MR I will file one. If it's
just for attribution, though, I personally see no need.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#987997: Wrong (too low) version of libcharls2 referenced

[Steven Robbins]

On Mon, 03 May 2021 14:54:07 +0200 Philipp Marek  
wrote:
> Package: digikam
> Version: 4:7.1.0-2
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Just "apt-get install digikam -t testing" doesn't work - libcharls2 is 
> left at 2.0.0+dfsg-1, but this digikam needs at least 2.2.0+dfsg-2 to 
> run.

Hi,

I am sorry that you ran into trouble but happy that you were able to diagnose 
and fix.

It turns out that digikam itself doesn't directly depend on any version of 
libcharls2.  The dependency appears to be picked up via libgdal30 and 
libgdcm3.0 -- which are themselves not directly used by digikam during build.



> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-
debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> 
&references=<162004644786.145723.13839356111643438268.report...@rs232.brz.gv.at>

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

Bug#1004611: Resignation & call for votes to elect the Chair

[Elana Hashman]

On Sun, Jan 30, 2022 at 02:10:08PM -0700, Sean Whitton wrote:
> Package: tech-ctte
> 
> [resubmitting as a bug; please vote here rather than on the ML -- sorry]
> 
> Dear committee members,
> 
> As the membership of the committee has changed, according to convention
> I hereby resign as Chair, effective one week from now, and call for
> votes to elect the Chair of the Technicall Committee.  In accordance
> with the Debian Constitution, the vote runs until all members have
> voted, or until my resignation takes effect.
> 
> FAOD, I would like to continue in the role if the committee agrees.
> 
> The ballot:
> 
> ===BEGIN
> 
> A: Christoph Berg 
> B: Helmut Grohne 
> C: Elana Hashman 
> D: Simon McVittie 
> E: Niko Tyni 
> F: Matthew Vernon 
> G: Sean Whitton 
> H: Gunnar Wolf 
> 
> ===END

My apologies for failing to vote here; I didn't mean to ignore this.
It's been an interesting month for me.

For transparency, I would have voted:

G > A = D = E = H > C > B = F

Congrats Sean on your reelection :)

- e


signature.asc
Description: PGP signature

Bug#990201: CVE-2021-33622 (was: Re: Accepted singularity-container 3.9.5+ds1-1 (source) into experimental)

[Salvatore Bonaccorso]

Hi Nilesh, hi Andreas,

On Sun, Feb 20, 2022 at 02:37:12PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 20 Feb 2022 19:27:46 +0530
> Source: singularity-container
> Architecture: source
> Version: 3.9.5+ds1-1
> Distribution: experimental
> Urgency: medium
> Maintainer: Debian HPC Team 
> Changed-By: Nilesh Patra 
> Closes: 990201
> Changes:
>  singularity-container (3.9.5+ds1-1) experimental; urgency=medium
>  .
>[ Andreas Tille ]
>* Team upload.
>* Version > 3.6.x are closing CVE-2021-33622
>  Closes: #990201

Can you help isolate on that?
https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622-
refers the 3.6.x as beeing affected and so there is the statement that
the issue is not going to be patched in those version:

> This issue affects open-source Singularity 3.5.x and 3.6.x. These
> versions are no longer supported and will not be patched.

https://bugs.debian.org/990201#10 is as well relevant in the context.

So where has this issue bin fixed?

Regards,
Salvatore

Bug#1005959: mig-for-host:amd64 should not exist

[Samuel Thibault]

Helmut Grohne, le dim. 20 févr. 2022 07:50:59 +0100, a ecrit:
> Once doing that, we effectively get the very same packages just
> without -linux or -kfreebsd.

Yep, that's what I understood

> I'm wondering whether that should be expanded to just cover the full
> matrix withing x86 architectures (32bit and 64bit) to ease hurd-amd64
> development on hurd-i386. Do you have a preference here?

For now we'll probably build such hurd-amd64 packages on amd64 anyway.

> > checking for i686-gnu-mig... i686-linux-gnu-mig
> > 
> > but that's still relatively bogus.
> 
> After the change above, there would not be any i686-linux-gnu-mig, but
> i686-gnu-mig instead.

Yep.

> If you agree with this change in principle, I can look into writing a
> patch for it.

If you're interesting in having a look you're welcome, otherwise I
believe I see how to change things.

Samuel

Bug#1006183: cups-browsed: Provide apparmor rule for cups-browsed-debian-edu.conf as shipped on Debian Edu systems

[Mike Gabriel]

Package: cups-browsed
Severity: wishlist
Version: 1.28.11-2
Control: found -1 2.3.3op2-3+deb11u1
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: debian-edu
Tags: patch

Dear CUPS maintainers,

on Debian Edu we face a problem with  
/etc/apparmor.d/usr.sbin.cups-browsed as shipped in cups-browsed  
bin:pkg (see [1] for details). The problem is specific to Debian Edu,  
but it would be really cool to get the most appropriate fix for this  
into bin:pkg cups-browsed itself.


The problem: in Debian Edu, we move /etc/cups/cups-browsed.conf out of  
the way and replace it by a symlink that points to  
/etc/cups/cups-browsed-debian-edu.conf. In Debian Edu, we do this for  
several files in /etc/ when provisioning an adjusted Debian Edu server  
or workstation. Unfortunately, since Debian Edu 11, the file  
/etc/cups/cups-browsed-debian-edu.conf does not get read anymore due  
to apparmor denying this file from being read.


The request that we ask form the printing team is this: Can you please  
allow cups-browsed to read from  
/etc/cups/cups-browsed-debian-edu.conf? A patch for this is attached  
to this bug report.


Of course, the conffile manipulation approach in Debian Edu is  
debatable, but shall not be our concern in this bug. (See #311188 if  
you want to chime in on that topic).


Thanks+Greets,
Mike


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

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net

diff -Nru cups-filters-1.28.11/debian/apparmor/usr.sbin.cups-browsed 
cups-filters-1.28.11/debian/apparmor/usr.sbin.cups-browsed
--- cups-filters-1.28.11/debian/apparmor/usr.sbin.cups-browsed  2022-01-22 
12:19:51.0 +0100
+++ cups-filters-1.28.11/debian/apparmor/usr.sbin.cups-browsed  2022-02-20 
19:51:07.0 +0100
@@ -17,6 +17,9 @@
   /var/log/cups/* rw,
   /tmp/** rw,
 
+  # Courtesy to the Debian Edu team...
+  /etc/cups/cups-browsed-debian-edu.conf r,
+
   # Site-specific additions and overrides. See local/README for details.
   #include 
 }
diff -Nru cups-filters-1.28.11/debian/changelog 
cups-filters-1.28.11/debian/changelog
--- cups-filters-1.28.11/debian/changelog   2022-01-22 12:19:51.0 
+0100
+++ cups-filters-1.28.11/debian/changelog   2022-02-20 19:51:15.0 
+0100
@@ -1,3 +1,12 @@
+cups-filters (1.28.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/apparmor/usr.sbin.cups-browsed: Allow reading from Debian Edu's
+cups-browsed config file (/etc/cups/cups-browsed-debian-edu.conf).
+(Closes: -1).
+
+ -- Mike Gabriel   Sun, 20 Feb 2022 19:51:15 +0100
+
 cups-filters (1.28.11-2) unstable; urgency=medium
 
   * debian/control: lynx has to be handled different in Debian and Ubuntu


pgp2kBuaPl3BF.pgp
Description: Digitale PGP-Signatur

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:35:23 +, Simon McVittie wrote:
> With cups-browsed only: Two printers appear, labelled
> HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.

I think this is because the mDNS name of my printer happens to end with
a parenthesis (it's "HP Color LaserJet MFP M277dw (xx)"), and with
this specific printer, the algorithms used by GTK and cups-browsed to
flatten mDNS names into syntactically-valid printer names are subtly
different: GTK removes trailing invalid characters, but cups-browsed
does not (this appears to be deliberate, it has special code to do this
for other strings but not for DNS-SD-based printer names).

smcv

Bug#1006119: uwsgi: FTBFS with ruby3.0 as default

[Antonio Terceiro]

Control: tag -1 + patch

On Sat, 19 Feb 2022 14:19:46 +0100 Paul Gevers  wrote:
> Source: uwsgi
> Version: 2.0.20-2
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> Control: block -1 by 1004915
> 
> Dear maintainer,
> 
> I tried to binNMU your package for the ongoing ruby3.0 as default ruby
> transition. It failed:
> https://buildd.debian.org/status/package.php?p=uwsgi
> 
> Paul

The attached patch converts the rack plugin to ruby3.0. Please let me
know if I should just upload it (requires going through NEW due to the
new bianry package).
uwsgi_2.0.20-2.1.dsc
uwsgi_2.0.20-2.dsc


signature.asc
Description: PGP signature

Bug#982925: Request for testing: GTK for bullseye with improved CUPS printing support

[Simon McVittie]

I have been looking into two GTK merge requests [!6] and [!9], trying to
figure out which one is the better candidate for a bullseye stable update.

[!6]: https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/6
[!9]: https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/9

This is an attempt to resolve https://bugs.debian.org/982925, and maybe
other printing-related issues. Not all GTK programs necessarily use the
unmodified GTK printing dialog, but the gedit package seems to be a good
test-case.

At the moment, I am leaning towards the more complete !6 being a better
candidate for a stable update, even though it is technically a feature
enhancement, which we don't usually do in stable. Please could people who
have printers try the release candidate from here, and confirm whether it
works as expected?
https://people.debian.org/~smcv/bullseye-gtk-printing/mr6/
https://salsa.debian.org/gnome-team/gtk3/-/commits/wip/bullseye-mr6

The _binary.changes and .dsc files are signed with my key in the Debian
keyring, and can be verified with the dscverify tool from the devscripts
package (this requires devscripts and debian-archive-keyring installed).

If the release team will not accept !6, then the fallback option is !9:
https://people.debian.org/~smcv/bullseye-gtk-printing/mr9/
https://salsa.debian.org/gnome-team/gtk3/-/commits/wip/bullseye-mr9

Please send test results to #982925. There are a lot of moving parts here,
so when reporting test results, please answer these questions:

* Which versions of cups-daemon and cups-filters-core-drivers are installed?
* What printers are physically present on your network?
* Have you configured a printer queue in CUPS manually, or are you relying
  on auto-detection?
* Is cups-browsed installed? If yes, which version?
* What printer names appear in the GTK print dialog?
  (If they contain MAC addresses or serial numbers, you can censor them
  as XX)
* For each printer name that appears:
  * Does it appear in /etc/cups/printers.conf?
  * Does printing to it work?
  * If not, what failure mode do you see?
(Nothing happens / printer prints wrong results / other)

Please note that I do not claim to be any sort of expert on printing.
Anyone who thinks they can do a better job is welcome to take over
any time.

Thanks,
smcv

Bug#1001082: qtbase-opensource-src: segfault when closing one windows in a multi window QT application

[Dmitry Shachnev]

Hi,

On Thu, Feb 17, 2022 at 11:16:39AM -0500, theofficialgman wrote:
> Thanks for pushing the fix to the buster git branch. Is this good to be
> released or do we have to wait for some release timing before it is built
> and published?

I have just filed https://bugs.debian.org/1006182 which needs to be approved
by the Release team.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1006182: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u5

[Dmitry Shachnev]

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

Dear Release team,

[ Reason ]
One of our users requested a new upload to fix this bug:
https://bugs.debian.org/1001082.

[ Impact ]
This bug causes various applications to segfault on exit.

[ Tests ]
Upstream commits add auto-tests for this change (tabOrderNoChange and
tabOrderNoChange2).

We do not run tests during build because there are too many issues with
them, and my patch does not include the test additions for that reason.
However, I patched the test manually and ran it against the new build, and
these tests passed:

PASS   : tst_QWidget::defaultTabOrder()
PASS   : tst_QWidget::reverseTabOrder()
PASS   : tst_QWidget::tabOrderWithProxy()
PASS   : tst_QWidget::tabOrderWithCompoundWidgets()
PASS   : tst_QWidget::tabOrderNoChange()
PASS   : tst_QWidget::tabOrderNoChange2()

Some other tests in tst_qwidget.cpp failed, but I believe it's because of
Xvfb (tests are designed to run in real X11). Full test log is attached.

[ Risks ]
On one hand, this change is in QWidget class, which the base class for all
Qt's widgets. On the other hand, this change is covered by upstream tests,
and upstream has backported it to 5.12 LTS branch (we ship 5.11 but it's
quite similar to 5.12).

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

[ Changes ]
It is a backport of two upstream commits from upstream 5.12 LTS branch:

https://code.qt.io/cgit/qt/qtbase.git/commit/?id=81e298a51d08c510
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a7cbb8c639487edb

--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.11.3+dfsg1-1+deb10u5) buster; urgency=medium
+
+  * Backport two upstream commits to fix setTabOrder for compound widgets
+(closes: #1001082).
+
+ -- Dmitry Shachnev   Sun, 20 Feb 2022 20:35:51 +0300
+
 qtbase-opensource-src (5.11.3+dfsg1-1+deb10u4) buster; urgency=medium
 
   [ Dmitry Shachnev ]
--- /dev/null
+++ b/debian/patches/fix_settaborder.diff
@@ -0,0 +1,76 @@
+Description: QWidget: fix setTabOrder for compound widgets
+Origin: upstream, commits:
+ https://code.qt.io/cgit/qt/qtbase.git/commit/?id=81e298a51d08c510
+ https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a7cbb8c639487edb
+Last-Update: 2022-02-13
+
+--- a/src/widgets/kernel/qwidget.cpp
 b/src/widgets/kernel/qwidget.cpp
+@@ -6975,35 +6975,41 @@ void QWidget::setTabOrder(QWidget* first
+ lastFocusChild = focusNext;
+ }
+ };
++auto setPrev = [](QWidget *w, QWidget *prev)
++{
++w->d_func()->focus_prev = prev;
++};
++auto setNext = [](QWidget *w, QWidget *next)
++{
++w->d_func()->focus_next = next;
++};
+ 
+-QWidget *lastFocusChildOfFirst, *lastFocusChildOfSecond;
+-determineLastFocusChild(first, lastFocusChildOfFirst);
++// remove the second widget from the chain
++QWidget *lastFocusChildOfSecond;
+ determineLastFocusChild(second, lastFocusChildOfSecond);
++{
++QWidget *oldPrev = second->d_func()->focus_prev;
++QWidget *prevWithFocus = oldPrev;
++while (prevWithFocus->focusPolicy() == Qt::NoFocus)
++prevWithFocus = prevWithFocus->d_func()->focus_prev;
++// only widgets between first and second -> all is fine
++if (prevWithFocus == first)
++return;
++QWidget *oldNext = lastFocusChildOfSecond->d_func()->focus_next;
++setPrev(oldNext, oldPrev);
++setNext(oldPrev, oldNext);
++}
+ 
+-// If the tab order is already correct, exit early
+-if (lastFocusChildOfFirst->d_func()->focus_next == second)
+-return;
+-
+-// Note that we need to handle two different sections in the tab chain; The section
+-// that 'first' belongs to (firstSection), where we are about to insert 'second', and
+-// the section that 'second' used be a part of (secondSection). When we pull 'second'
+-// out of the second section and insert it into the first, we also need to ensure
+-// that we leave the second section in a connected state.
+-QWidget *firstChainOldSecond = lastFocusChildOfFirst->d_func()->focus_next;
+-QWidget *secondChainNewFirst = second->d_func()->focus_prev;
+-QWidget *secondChainNewSecond = lastFocusChildOfSecond->d_func()->focus_next;
+-
+-// Insert 'second' after 'first'
+-lastFocusChildOfFirst->d_func()->focus_next = second;
+-second->d_func()->focus_prev = lastFocusChildOfFirst;
+-
+-// The widget that used to be 'second' in the first section, should now become 'third'
+-lastFocusChildOfSecond->d_func()->focus_next = firstChainOldSecond;
+-firstChainOldSecond->d_func()->focus_prev = lastFocusChildOfSecond;
+-
+-// Repair the second section after we pulled 'second' out of 

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Eric Valette]

On 20/02/2022 16:48, Dominique Dumont wrote:

On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:

Does the system actually suspend?


Not really. The screens looks like it's going to suspend, but it does come
back after 10s or so. The light mounted in the middle of the power button does
not switch off.



As I have a very similar problem and also commented on the original 
debian bug report 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005005), I will add 
some information here on another amd only laptop (renoir AMD Ryzen 7 
4800H with Radeon Graphics + Radeon RX 5500/5500M / Pro 5500M).


For me the suspend works once, but after the first resume (I do know 
know if it is in the suspend path or the resume path I see a RIP in the 
dmesg (see aditional info in debian bug))  and later suspend do not 
work: It only go to the kde login screen.


I was unable due to network connectivity to do a full bisect but tested 
with the patch I had on my laptop:


5.10.101 works, 5.10 from debian works
5.11 works
5.12 works
5.13 suspend works but when resuming the PC is dead I have to reboot
5.14 seems to work but looking at dmesg it is full of RIP messages at 
various places.

5.15.24 is a described 5.15 from debian is behaving identically
5.16 from debian is behaving identically.


Is this system S0i3 or regular S3?


For me it is real S3.

The proposed patch is intended for INTEl + intel gpu + amdgpu but I have 
dual amd GPU.


--eric

Bug#1006181: fslint is no longer available. Seems to be superseeded by Czkawka

[waxhead]

Package: fslint
Severity: wishlist
X-Debbugs-Cc: waxh...@dirtcellar.net

Dear Maintainer,


   * What led up to the situation?
fslint was removed from the Debian repos

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Cried, that was ineffective - so I visited fslint's homepage and foudn this.
https://qarmin.github.io/czkawka/

   * What was the outcome of this action?
Seems to be a continuation of the project...

   * What outcome did you expect instead?
I hope this program can be added to the Debian repos.



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

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

Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Chris Chang]

Hmm.  Ordinarily, that download link would be fine.  I had not updated it
this time because the issue only affects gcc 11+, so it did not affect any
of the precompiled binaries and I wanted to keep the posted source
identical to that used to compile those binaries.

On the other hand, the only difference (in the non-gcc-11+ case) between
the binaries and the updated source is the version date.  I guess this is
insignificant enough that a temporary discordance is less disruptive than
making you change your packing process, so I've updated the website source
link to point to the newer code; let me know if you still run into any
problems.

On Sat, Feb 19, 2022 at 11:53 PM Andreas Tille  wrote:

> Hi Chris,
>
> Am Sat, Feb 19, 2022 at 11:37:34PM -0800 schrieb Chris Chang:
> > To elaborate: when I look at
> > https://salsa.debian.org/med-team/plink2/-/tree/master , I can see that
> > plink2.cc, include/plink2_base.h, and include/plink2_base.cc don't have
> the
> > same contents as the v2.00a3-20220218 GitHub tag/release.  So I don't
> know
> > where you grabbed the code from this time, but it does not appear to be
> > from GitHub.
>
> That's true since on Github the source code of plink1.9 and plink2 is not
> separated.  Thus I download the tarball from
>
>https://www.cog-genomics.org/plink/2.0/
>
> which points to
>
>https://www.cog-genomics.org/static/bin/plink2_src_220217.zip
>
> I confirm that the tag on Github says v2.00a3-20220218 which seems to be
> later than 220217.  In principle I could point the packaging metadata to
> Github and exclude everything that I do not need for plink2 packaging (so
> remove 1.9 directory and code copies of libdeflate, simde and zstd in 2.0)
>
> In case you consider this the safer way to download plink2 code I'll do so.
>
> Kind regards and thanks a lot for comparing the code base
>
>  Andreas.
>
> > On Sat, Feb 19, 2022 at 7:54 AM Chris Chang 
> wrote:
> >
> > > If you build off the current head, the version string should say "18
> Feb
> > > 2022", not "17 Feb 2022".
> > >
> > > On Sat, Feb 19, 2022 at 7:02 AM Andreas Tille 
> wrote:
> > >
> > >> Hi again,
> > >>
> > >> Am Sat, Feb 19, 2022 at 12:28:21AM -0800 schrieb Chris Chang:
> > >> > Ok, new release/tag created.
> > >>
> > >> I've built the new version now.  The bad news is that it keeps on
> > >> SEGFAULTing for me:
> > >>
> > >> ...
> > >> (gdb) run
> > >> Starting program: /usr/lib/plink2/plink2-sse3 --debug --pfile tmp_data
> > >> --export vcf vcf-dosage=DS --out tmp_data2
> > >> [Thread debugging using libthread_db enabled]
> > >> Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > >> [New Thread 0x74cc7640 (LWP 985019)]
> > >> [New Thread 0x744c6640 (LWP 985020)]
> > >> [New Thread 0x7fffebcc5640 (LWP 985021)]
> > >> PLINK v2.00a3 64-bit (17 Feb 2022)
> > >> www.cog-genomics.org/plink/2.0/
> > >> (C) 2005-2022 Shaun Purcell, Christopher Chang   GNU General Public
> > >> License v3
> > >> Logging to tmp_data2.log.
> > >> Options in effect:
> > >>   --debug
> > >>   --export vcf vcf-dosage=DS
> > >>   --out tmp_data2
> > >>   --pfile tmp_data
> > >>
> > >> Start time: Sat Feb 19 16:00:00 2022
> > >> 31998 MiB RAM detected; reserving 15999 MiB for main workspace.
> > >> Using up to 4 compute threads.
> > >> [New Thread 0x77fc5640 (LWP 985022)]
> > >>
> > >> Thread 1 "plink2-sse3" received signal SIGSEGV, Segmentation fault.
> > >> plink2::LoadPsam (psamname=psamname@entry=0x7fffbe60
> > >> "tmp_data.psam", pheno_range_list_ptr=, fam_cols=...,
> > >> pheno_ct_max=,
> > >> missing_pheno=, affection_01=0, max_thread_ct=4,
> > >> piip=0x7fff8870, sample_include_ptr=0x7fff8790,
> > >> founder_info_ptr=0x7fff87a8, sex_nm_ptr=0x7fff8798,
> > >> sex_male_ptr=0x7fff87a0, pheno_cols_ptr=0x7fff8770,
> > >> pheno_names_ptr=0x7fff8780, raw_sample_ct_ptr=0x7fff8728,
> > >> pheno_ct_ptr=0x7fff8720,
> > >> max_pheno_name_blen_ptr=0x7fff87b0) at ../plink2_psam.cc:611
> > >> 611 pheno_cols[pheno_idx].nonmiss = nullptr;
> > >>
> > >>
> > >> Please let me know if I can do further checks.
> > >>
> > >> Kind regards
> > >>
> > >>   Andreas.
> > >>
> > >> --
> > >> http://fam-tille.de
> > >>
> > >
>
> --
> http://fam-tille.de
>

Bug#995230: [Pkg-rust-maintainers] Bug#995230: ripgrep: add autocompletion for bash

[Sylvestre Ledru]

Le 20/02/2022 à 14:25, Florian Ernst a écrit :
> On Tue, Sep 28, 2021 at 10:43:53AM +0200, Laurent Cheylus wrote:
>> during build of ripgrep, a script (rg.bash) is generated via clap tool
>> for autocompletion (see [...]
>> This script is not included in Debian package v13.0.0-2. Please add it
>> to be installed as /usr/share/bash-completion/completions/rg.
> In commit 7f0d6ae of rust-team/debcargo-conf the corresponding "--with
> bash-completion" was dropped, most presumably by accident. As such bash
> autocompletion was missing ever since 13.0.0-1. Readding that part
> brings back the missing file:
>
> | diff -Nru rust-ripgrep-13.0.0/debian/rules rust-ripgrep-13.0.0/debian/rules
> | --- rust-ripgrep-13.0.0/debian/rules2021-08-31 22:06:04.0 +0200
> | +++ rust-ripgrep-13.0.0/debian/rules2022-02-20 13:48:27.0 +0100
> | @@ -1,6 +1,6 @@
> |  #!/usr/bin/make -f
> |  %:
> | -   dh $@ --buildsystem cargo
> | +   dh $@ --buildsystem cargo --with bash-completion
> | 
> |  execute_after_dh_testdir:
> | find . ! -newermt "jan 01, 2000" -exec touch {} +
>
> and then after rebuilding the binary package
>
> | $ debdiff ripgrep_13.0.0-2_amd64.deb ripgrep_13.0.0-2.1_amd64.deb
> | [The following lists of changes regard files as different if they have
> | different names, permissions or owners.]
> | 
> | Files in second .deb but not in first
> | -
> | -rw-r--r--  root/root   /usr/share/bash-completion/completions/rg
> | drwxr-xr-x  root/root   /usr/share/bash-completion/
> | drwxr-xr-x  root/root   /usr/share/bash-completion/completions/
> | 
> | Control files: lines which differ (wdiff format)
> | [...]

It seems. Would you like to provide a MR ?

thanks
S

Bug#1006180: ITP: twopaco -- build the compacted de Bruijn graph from many complete genomes

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: twopaco -- build the compacted de Bruijn graph from many complete 
genomes
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: twopaco
  Version : 0.9.4
  Upstream Author : I. Minkin and P. Medvedev.
* URL : https://github.com/medvedevgroup/TwoPaCo
* License : BSD-4-clause
  Programming Lang: C
  Description : build the compacted de Bruijn graph from many complete 
genomes
 TwoPaCo is an implementation of the algorithm described in the paper
 "TwoPaCo: An efficient algorithm to build the compacted de Bruijn graph
 from many complete genomes".
 .
 This package contains two programs:
 .
  twopaco: tool for direct construction of the compressed graph from
   multiple complete genomes
  graphdump: utility that turns output of twopaco into a text format

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/twopaco

Bug#1005067: closed by Debian FTP Masters (reply to Dylan Aïssi ) (Bug#1005067: fixed in pipewire 0.3.46-1)

[Eric Valette]

On 17/02/2022 22:27, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the pipewire-pulse package:



I confirm it WFM. Thanks.

-- eric

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:19:32 +, Simon McVittie wrote:
> When reporting test results, please answer these questions:
> 
> * Which versions of cups-daemon and cups-filters-core-drivers are installed?
> * How many printers are physically present on your network?
> * Have you configured a printer queue in CUPS manually, or are you only
>   using auto-detection?
> * Is cups-browsed installed? If yes, which version?
> * What printer names appear in the GTK print dialog?
>   (If they contain MAC addresses or serial numbers, you can censor them
>   as XX)
> * For each printer name that appears:
>   * Does printing to it work?
>   * If not, what failure mode do you see?
> (Nothing happens / printer prints wrong results / other)

Sorry, I should have mentioned another question:

* What printer names are listed in /etc/cups/printers.conf?

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:19:36 +, Simon McVittie wrote:
> I will reply to the bug with my own test results.

> * Which versions of cups-daemon and cups-filters-core-drivers are installed?

cups-daemon 2.3.3op2-3+deb11u1
cups-filters-core-drivers   1.28.7-1

> * How many printers are physically present on your network?

One HP Color LaserJet MFP M277dw.

> * Is cups-browsed installed? If yes, which version?

I tested both with and without cups-browsed 1.28.7-1.

Test methodology for each of the 12 attempts listed here (I'm using an
expendable test machine, do not do these steps unless you are willing
to lose manual CUPS configuration):

sudo apt purge cups-browsed cups-daemon
sudo rm -fr /etc/cups
sudo apt install cups cups-core-drivers cups-daemon cups-browsed-
(optionally) Configure printer: gnome-control-center, Printers, Unlock,
 Add..., wait, click on the single printer that appears, Add
(optionally) sudo apt install cups-browsed
G_MESSAGES_DEBUG=all gedit
Try to print

GTK 3.24.24-4 (status quo in bullseye)
==

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no|unavailable | works |
 yes| works  |duplicated |
||---|

With no configuration and no cups-browsed: No printers are listed

With cups-browsed only: One printer, HP_Color_LaserJet_MFP_M277dw_xx_,
where xx is a unique ID taken from its MAC address. It appears in
/etc/cups/printers.conf, flagged as having come from cups-browsed.
Printing is successful.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: both of the printers mentioned above appear in the GTK dialog
and in /etc/cups/printers.conf. Both print successfully.

GTK with merge request 9 (Daniel's minimal backport)


| cups-browsed installed  |
|no  | yes|
|||
printer manually configured   no| unavailable|duplicated  |
 yes| works  |dup., only one works|
|||

With no configuration and no cups-browsed: No printers are listed

With cups-browsed only: One printer, HP_Color_LaserJet_MFP_M277dw_xx_,
where xx is a unique ID taken from its MAC address. Printing is successful.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: both of the printers mentioned above appear in the GTK dialog
and in /etc/cups/printers.conf. Only the first one printed successfully:
the second logged "NO_DEST_FOUND".

GTK with merge request 6 (full backport from 3.24.29)
=

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no| works  |duplicated |
 yes| works  |duplicated |
||---|

With no configuration and no cups-browsed: One printer appears in the
GTK dialog, HP_Color_LaserJet_MFP_M277dw_xx. Printing is successful.

With cups-browsed only: Two printers appear, labelled
HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.
Only the second one appears in /etc/cups/printers.conf, labelled as having
come from cups-browsed. Both print successfully.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: Two printers appear, labelled HP-Color-LaserJet-MFP-M277dw
and HP_Color_LaserJet_MFP_M277dw_xx_. Both are in /etc/cups/printers.conf,
with the second one labelled as having come from cups-browsed. Both print
successfully.

Bug#1002496: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

[Dominique Dumont]

On Wednesday, 9 February 2022 19:36:16 CET Chris Lamb wrote:
> > Unfortunately, the build of perl6-zef with cowbuilder is already broken
> > with cowbuilder. The nonexistant home dir leads to build failures.
> 
> Ah, shame. Although I wasn't experiencing a build failure, I was
> getting the same or similar warnings when building "perl6-readline".

Sorry, I got confused.

The pre-compilation phase works fine with HOME set to a non-existent directory.

On the other hand, zef tests require a writable HOME directory. I've changed 
dh_raku_test to set HOME to debian/tmp/home (and cleanup afterwards).

With these changes, perl6-zef builds without problems.

This does not change the reproducible build issue.

All the best

Dod

Bug#1006179: clamav: please package 0.104.2

[Martin-Éric Racine]

Package: clamav
Version: 0.103.5+dfsg-0+deb11u1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

According to  upstream is now at version 
0.104.2. Can you please package it and also push it to stable-updates?

Thanks!

Martin-Éric

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

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

Versions of packages clamav depends on:
ii  clamav-freshclam [clamav-data]  0.103.5+dfsg-0+deb11u1
ii  libc6   2.31-13+deb11u2
ii  libclamav9  0.103.5+dfsg-0+deb11u1
ii  libcurl47.74.0-1.3+deb11u1
ii  libjson-c5  0.15-2
ii  libssl1.1   1.1.1k-1+deb11u1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages clamav recommends:
ii  clamav-base  0.103.5+dfsg-0+deb11u1

Versions of packages clamav suggests:
pn  clamav-docs   
pn  libclamunrar  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmISeccACgkQrh+Cd8S0
17ac3w/9EXTt0e4FbAobEglqDhiB3NJK2OhapAvukbR0voPTI1xhCV6tv/08b9Oe
JO8CsDfxnMUFRqLzGSqd7seVhM4QU2+sG2eOHoQ9S/Q+AF5zeIclaUHY9BkfBK7F
n7GjdC7db2CbT07VFsK357NDzdnn9SH6po6U+Iu3656x7wqJGoooZBo7kIsb8vHj
+9MDcpbKkM+BEag/rzIs+CWaWNCip0DDyR8DCD4EsEsY4EVjTOLlk9NLeGFaDGtx
6bwSDJtKlFCYtlyzQMHp+9db/bKOLLYyQ+442IUkdP5P0xa3ZHa3Ova0vuuU1Rew
MmVUrGlv/jPi5pk60RC2Kh9wMSKnIXza6wRgw+cmZkeMK3sh5VBZ6cuRKIyZRrWE
VrIgcyb8uneMFf8rMOwOEr+B3R980n1RKli7z8rUgddgr60GUuYuH4Uzcewnw0GT
lEGI/twxk2uWMMYZ6ULYod3qVhN4Rgn+UdZOYeUE88q2fQ3ImgOBnXQbYzQAQ9/b
tIKgEO6tkIRYI/0jN0U0kBCu89R9NXStGOQ0XUegEuI59uTIecO9ywgfyBwObdVt
ytx1ReGQ3HX8FoNjYXMCajAxDQMS2mxY3pN/DpACP9O/vOTEtxEqSjQu7/Eg2Rmk
lw+iMje+icARLvsj4ZDmYyLY7+qMHWRkttSVerbRUpqtoQcgYdI=
=oSFL
-END PGP SIGNATURE-

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Tue, 16 Feb 2021 at 11:55:28 -0500, Zack Weinberg wrote:
> I have only one printer, a network-attached Brother HL model.  CUPS
> autodetects it somehow and creates a queue for it:
> 
> $ lpstat -e
> Brother_HL_L2350DW_series
> 
> This queue shows up twice in the GTK print dialog box, with two
> slightly different names (see attached screenshot).
> 
> This is not merely a cosmetic problem: only one of the two queues
> actually works.  If I select the wrong one, the print job disappears
> into the aether.

On Mon, 26 Jul 2021 at 02:24:06 +0200, Daniel Gröber wrote:
> I was seeing the exact same problem
(and on a merge request)
> Printers discovered directly via avahi instead of going through cups
> don't always work properly, in my case printing to such a printer will
> just keep spewing pages filled with binary garbage until the print job
> is cancelled manually.

That doesn't appear to be the exact same problem: Zack said that printing
just doesn't happen, but Daniel said that printing produces a wrong
print job.

I have been looking into Daniel's merge request [!9], and a related
merge request that backports the entire CUPS printing module from GTK
3.24.29 [!6], trying to figure out which one is the better candidate
for a stable update.

[!6]: https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/6
[!9]: https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/9

At the moment, I am leaning towards the more complete !6 being a better
candidate for a stable update, even though it is technically a feature
enhancement, which we don't usually do in stable. Please could you try the
release candidate from here, and confirm whether it solves the issues you
are seeing?
https://people.debian.org/~smcv/bullseye-gtk-printing/mr6/

The _binary.changes and .dsc files are signed with my key in the Debian
keyring, and can be verified with the dscverify tool from the devscripts
package (this requires devscripts and debian-archive-keyring installed).

If the release team will not accept !6, then the fallback option is !9,
which is the change that Daniel proposed:
https://people.debian.org/~smcv/bullseye-gtk-printing/mr9/

I would appreciate test results from both of these if possible.

When reporting test results, please answer these questions:

* Which versions of cups-daemon and cups-filters-core-drivers are installed?
* How many printers are physically present on your network?
* Have you configured a printer queue in CUPS manually, or are you only
  using auto-detection?
* Is cups-browsed installed? If yes, which version?
* What printer names appear in the GTK print dialog?
  (If they contain MAC addresses or serial numbers, you can censor them
  as XX)
* For each printer name that appears:
  * Does printing to it work?
  * If not, what failure mode do you see?
(Nothing happens / printer prints wrong results / other)

I will reply to the bug with my own test results.

smcv

Bug#1004678: git-lfs: allow offline operation

[Stephen Gelman]

On Feb 20, 2022 at 3:29:31 AM, Barak A. Pearlmutter 
wrote:

> I will file an issue upstream. But I don't expect them to care,
> because github (the company) probably views this issue as a feature,
> not a bug. This issue ties people to a single central repository and
> makes migration nearly impossible, at least for non-wizards. Which is
> basically their business model: come for the issue tracker and repo
> sharing, stay because you have no choice, you can't leave, you can't
> even commit without connecting.
>

Sorry, I realize I misspoke. I meant to say due to the _centralized_ nature
of git-lfs...

Bug#1002652: bullseye-pu: package schleuder/3.6.0-3+deb10u1

[Georg Faerber]

On 22-02-19 17:54:40, Adam D. Barratt wrote:
> Please go ahead; sorry for the delay.

Uploaded, thanks.

Cheers,
Georg

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Salvatore Bonaccorso]

Hi Dominique

[dropping almost all recipients for this reply]

On Sun, Feb 20, 2022 at 04:48:43PM +0100, Dominique Dumont wrote:
> On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
> > Does the system actually suspend?  
> 
> Not really. The screens looks like it's going to suspend, but it does come 
> back after 10s or so. The light mounted in the middle of the power button 
> does 
> not switch off.
> 
> > Is this system S0i3 or regular S3?
> 
> I'm not sure how to check that. After a bit of reading on the Internet [1], I 
> hope that the following information answers that question. Please get back to 
> me if that's not the case.
> 
> Looks like my system supports both Soi3 and S3
> 
> $ cat /sys/power/state 
> freeze mem disk
> 
> I get the same result running these 2 commands as root:
> # echo freeze > /sys/power/state
> # echo mem > /sys/power/state
> 
> >  Does this patch help by any chance?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=e55a3aea418269266d84f426b3bd70794d3389c8
> 
> yes, with this patch:
> - the suspend issue is solved
> - kernel logs no longer show messages like "failed to send message" or 
> "*ERROR* suspend of IP block  failed" while suspending

Okay great :). This commit landed in 5.16.8 for the 5.16.y series. I
did upload 5.16.10-1 (but the signed packages are yet missing). Can
you test this one to confirm the issue is fixed?

Regards,
Salvatore

Bug#1005814: ITP: debfetch -- Prints short info about Debian.

[Andrey Rahmatullin]

On Tue, Feb 15, 2022 at 12:38:17PM -0300, Ramon Mulin Lopes wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ramon Mulin Lopes 
> X-Debbugs-Cc: debian-de...@lists.debian.org, mu...@disroot.org
> 
> * Package name: debfetch
>   Version : 1.0
>   Upstream Author : Blau Araujo 
> * URL : https://git.blauaraujo.com/blau_araujo/debfetch
> * License : GPL 3.0+
>   Programming Lang: Bash
>   Description : Prints short info about Debian.
> 
> Prints short info about Debian on terminal. Lists branch of Debian, kernel 
> version, uptime, local host, packages free and non-free installed and date of 
> last update with a red Debian logo.
> 
> The software can be an excellent minimalist alternative built in bash for 
> others with the same goal. I need a sponsor to do the software packaging as 
> it will be my first package.
I don't think we need a package for a low-effort 50-line bash script that
duplicates at least two already packaged tools.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Salvatore Bonaccorso]

Hi,

On Sun, Feb 20, 2022 at 01:10:30AM +0100, Richard B. Kreckel wrote:
> Hi Salvatore,
> 
> On 19.02.22 20:31, Salvatore Bonaccorso wrote:
> > Alright thank you for confirming that. Would it be possible that you
> > as well build the kernel with
> > https://git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94
> > applied on top to see if this resolved the issue?
> 
> Yes that patch fixes it.

Thanks for confirming, I will cherry-pick the commit for the next
upload.

Regards,
Salvatore

Bug#1006178: ITP: tox-delay -- run some Tox tests after others have completed

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 
X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org

* Package name: tox-delay
  Version : 0.1.0
  Upstream Author : Peter Pentchev 
* URL : https://devel.ringlet.net/devel/tox-delay/
* License : BSD-2-clause
  Programming Lang: POSIX shell
  Description : run some Tox tests after others have completed

 The tox-delay tool postpones the run of the specified Tox environments
 after the run of all the others has completed successfully. This may be
 useful if e.g. there are unit or functional test environments, which
 it would make no sense to run if the static checkers (pylint, mypy, etc)
 find problems.


signature.asc
Description: PGP signature

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Dominique Dumont]

On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
> Does the system actually suspend?  

Not really. The screens looks like it's going to suspend, but it does come 
back after 10s or so. The light mounted in the middle of the power button does 
not switch off.

> Is this system S0i3 or regular S3?

I'm not sure how to check that. After a bit of reading on the Internet [1], I 
hope that the following information answers that question. Please get back to 
me if that's not the case.

Looks like my system supports both Soi3 and S3

$ cat /sys/power/state 
freeze mem disk

I get the same result running these 2 commands as root:
# echo freeze > /sys/power/state
# echo mem > /sys/power/state

>  Does this patch help by any chance?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> d=e55a3aea418269266d84f426b3bd70794d3389c8

yes, with this patch:
- the suspend issue is solved
- kernel logs no longer show messages like "failed to send message" or 
"*ERROR* suspend of IP block  failed" while suspending

All the best

[1] https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/
hibernate-issues

Bug#1006157: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko: [sparc64+ext4] reads see zeros w/ simultaneous write

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Noah,

On Sat, Feb 19, 2022 at 05:53:52PM -0800, Noah Misch wrote:
> Package: src:linux
> Version: 5.16.7-2
> Severity: normal
> File: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> The context is an ext4 filesystem on a sparc64 host.  I've observed
> this with each of the three sparc64 kernels that I've tested.  Those
> kernels were 5.16.0-1-sparc64-smp (this report), 5.15.0-2-sparc64-smp,
> and 4.9.0-13-sparc64-smp.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> See the included file for a minimal test program.  It creates two
> processes, each of which loops indefinitely.  One opens a file, writes
> 0x1 to a 256-byte region, and closes the file.  The other process
> opens the same file, reads the same region, and prints a message if
> any byte is not 0x1.
> 
> This thread has more discussion and a more-configurable test program:
> https://postgr.es/m/flat/20220116071210.ga735...@rfd.leadboat.com
> 
>* What was the outcome of this action?
> 
> The program prints messages, at least ten per second.  The mismatch
> always appears at an offset divisible by eight.  Some offsets are more
> common than others.  Here's output from 300s of runtime, filtered
> through "sort -nk3 | uniq -c":
> 
>1729 mismatch at 8: got 0, want 1
>1878 mismatch at 16: got 0, want 1
>1030 mismatch at 24: got 0, want 1
>  41 mismatch at 40: got 0, want 1
> 373 mismatch at 48: got 0, want 1
>  24 mismatch at 56: got 0, want 1
> 349 mismatch at 64: got 0, want 1
>   13525 mismatch at 72: got 0, want 1
> 401 mismatch at 80: got 0, want 1
> 365 mismatch at 88: got 0, want 1
>   1 mismatch at 96: got 0, want 1
>  32 mismatch at 104: got 0, want 1
>  34 mismatch at 112: got 0, want 1
>  19 mismatch at 120: got 0, want 1
>  34 mismatch at 128: got 0, want 1
> 253 mismatch at 136: got 0, want 1
> 149 mismatch at 144: got 0, want 1
> 138 mismatch at 152: got 0, want 1
>   1 mismatch at 160: got 0, want 1
>   4 mismatch at 168: got 0, want 1
>   7 mismatch at 176: got 0, want 1
>   4 mismatch at 184: got 0, want 1
>   1 mismatch at 192: got 0, want 1
>  83 mismatch at 200: got 0, want 1
>  58 mismatch at 208: got 0, want 1
>3301 mismatch at 216: got 0, want 1
>   2 mismatch at 232: got 0, want 1
>   1 mismatch at 248: got 0, want 1
> 
> If I run the program atop an xfs filesystem (still with sparc64), it
> prints nothing.  If I run it with x86_64 or powerpc64 (atop ext4), it
> prints nothing.
> 
>* What outcome did you expect instead?
> 
> I expected the program to print nothing, indicating that the reader
> process observes only 0x1 bytes.  That is how x86_64+ext4 behaves.
> 
> POSIX is stricter, requiring read() and write() implementations such
> that "each call shall either see all of the specified effects of the
> other call, or none of them"
> (https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07).
> ext4 does not conform, which may be pragmatic.  However, with x86_64
> and powerpc64, readers see each byte as either its before-write value
> or its after-write value.  They don't see a zero in an offset that
> will have been nonzero both before and after the ongoing write().

Unless mistaken this looks like to be an upstream issue, think would
be better suited to directly report it upstream. Can you do so and
keep us in the loop?

Regards,
Salvatore

Bug#1006009: qtimageformats-opensource-src: FTBFS on mipsel: test failure

[Dmitry Shachnev]

Control: reassign -1 libwebp7 1.2.1-7
Control: affects -1 src:qtimageformats-opensource-src

Hi Sebastian and libwebp maintainers!

On Fri, Feb 18, 2022 at 10:39:23PM +0100, Sebastian Ramacher wrote:
> Source: qtimageformats-opensource-src
> Version: 5.15.2-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
>
> qtimageformats-opensource-src FTBFS on mipsel:
>
> TIFFReadDirectory: Warning, Sum of Photometric type-related color channels 
> and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels 
> as ExtraSamples..
> TIFFReadDirectory: Warning, Sum of Photometric type-related color channels 
> and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels 
> as ExtraSamples..
> PASS   : tst_qtiff::tiffGrayscale()
> FAIL!  : tst_qwebp::writeImage(kollada_noalpha-100) '!reread.isNull()' 
> returned FALSE. ()
>Loc: [tst_qwebp.cpp(174)]
> PASS   : tst_qwebp::cleanupTestCase()
> Totals: 10 passed, 1 failed, 0 skipped, 0 blacklisted, 632ms
> * Finished testing of tst_qwebp *
>
> See
> https://buildd.debian.org/status/fetch.php?pkg=qtimageformats-opensource-src&arch=mipsel&ver=5.15.2-2%2Bb1&stamp=1645209225&raw=0

It looks to me like a bug in new libwebp version: encoder generates broken
webp files on mipsel.

I can reproduce it without any Qt code by encoding the attached PNG file and
then trying to decode it back:

(sid_mipsel-dchroot)mitya57@eller:~$ cwebp kollada_noalpha.png -lossless -o 
kollada_noalpha.webp
Saving file 'kollada_noalpha.webp'
File:  kollada_noalpha.png
Dimension: 436 x 160
Output:37004 bytes (4.24 bpp)
Lossless-ARGB compressed size: 37004 bytes
  * Header size: 636 bytes, image data size: 36342
  * Precision Bits: histogram=3 transform=3 cache=1
(sid_mipsel-dchroot)mitya57@eller:~$ dwebp kollada_noalpha.webp
Decoding of kollada_noalpha.webp failed.
Status: 3(BITSTREAM_ERROR)

I am also attaching the generated broken WEBP file.

--
Dmitry Shachnev


kollada_noalpha.webp
Description: Binary data


signature.asc
Description: PGP signature

Bug#1001172: Post processing script execution bug

[Volker C. Behr]

On 19.02.22 08:40, Martin-Éric Racine wrote:

On Sun, Dec 5, 2021 at 7:27 PM Alex Liddiard  wrote:

Package: printer-driver-cups-pdf
Version: 3.0.1-9
Severity: normal
X-Debbugs-Cc: alex.liddi...@warwickgrad.net

Dear Maintainer,

I added a script to the PostProcessing option and created a network shared 
cups-pdf printer.
The script executed correctly when printing from a number of different devices 
on my network.
I tried printing from a device which used an unusual username (contained 
brackets and spaces).
The post processing script failed to execute.

Modifying the script and using very simple scripts had no effect.
I enabled full debug logging in cups-pdf and experimented with ipptool.
Could not resolve the issue or find any workarounds.

I discovered the bash command used to execute the script contained errors: 
special characters contained in the username were not escaped.
This was causing the script execution to fail due to a bash syntax error.


I'm not sure I get what or where the bus is. Was your script not
capable of escaping special charachers? Something else?

Martin-Éric


CUPS-PDF itself is not escaping special characters in usernames when 
calling external scripts. This needs to be fixed upstream and is on my list.


Cheers,
Volker

Bug#1006177: src:opentsne: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: opentsne
Version: 0.5.0-2
Severity: serious
Control: close -1 0.6.1-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004706

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006176: src:lua-system: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: lua-system
Version: 0.2.1-2
Severity: serious
Control: close -1 0.2.1-5
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004099

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006175: src:lua-say: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: lua-say
Version: 1.3-1-5
Severity: serious
Control: close -1 1.3-1-7
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004098

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006173: src:lua-cliargs: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: lua-cliargs
Version: 3.0-2-1
Severity: serious
Control: close -1 3.0-2-4
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004096

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006174: src:lua-mediator: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: lua-mediator
Version: 1.1.2-0-3
Severity: serious
Control: close -1 1.1.2-0-6
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004097

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006172: src:lepton-eda: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: lepton-eda
Version: 1.9.16-3
Severity: serious
Control: close -1 1.9.17-2
X-Debbugs-CC: debian-s3...@lists.debian.org
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:lepton-eda has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package fails to build on 
s390x where it build successfully in the past. I've X-Debbugs-CC-ed the 
s390x porters to help you understand why only this architecture is affected.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006171: Make internal-sftp the default

[MichaIng]

Package: openssh-server
Version: 1:8.8p1-1

Currently the standalone OpenSSH sftp-server is used as default SFTP 
subsystem, set via /etc/ssh/sshd_config. This implies a dependency on 
the openssh-sftp-server package and means that every SFTP connection 
spawns a new external process, while sshd ships with the internal-sftp 
in-process SFTP server, which perform better when dealing with many 
short duration connections and simplifies the ChrootDirectory usage to 
not require any manual /dev node setup.


Legacy SSH1 clients pass an exact SFTP command, hence will still depend 
on openssh-sftp-server or any alternative standalone SFTP server, also 
internal-sftp means that the login shell is skipped in the first place. 
But the need for both are edge cases, the use of SSH1 IMO worth to be 
actively discouraged, and the vast majority of OpenSSH SFTP server 
admins will benefit from this change, at least to not require a config 
change that is part of very most SFTP guides around the internet, 
reasonably.


Forgive me if this discussion was already done, but I couldn't find it 
within the Debian bug tracker at least.


Best regards,

Micha

Bug#1004915: transition: ruby2.7-rm

[Paul Gevers]

Hi,

On 18-02-2022 21:23, Paul Gevers wrote:
Also the autopkgtest regressions don't look pretty yet, did you 
already have a look:

https://qa.debian.org/excuses.php?package=ruby-defaults

I'll try to take a look at this list and see what's going on.


coderay seems to have a patch to fix this in Ubuntu:
 https://patches.ubuntu.com/c/coderay/coderay_1.1.3-5ubuntu1.patch

diaspora-installer can just be removed, it's already on the autoremoval 
list.


jekyll apparently is fixed in unstable, but is on the autoremoval list. 
Shall I remove it or are you going to fix ruby-pathutil shortly?


ruby-certificate-authority is a key package, bug #1005448 looks related.

ruby-eventmachine is a key package, you'll need to investigate: 
NameError: uninitialized constant TestIOStreamer::StreamServer::StringIO


ruby-jwt, is a key package, you'll need to fix bug #1005426.

ruby-rack will migrate soon, I removed ruby-rack-mount.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995230: ripgrep: add autocompletion for bash

[Florian Ernst]

On Tue, Sep 28, 2021 at 10:43:53AM +0200, Laurent Cheylus wrote:
> during build of ripgrep, a script (rg.bash) is generated via clap tool
> for autocompletion (see [...]
> This script is not included in Debian package v13.0.0-2. Please add it
> to be installed as /usr/share/bash-completion/completions/rg.

In commit 7f0d6ae of rust-team/debcargo-conf the corresponding "--with
bash-completion" was dropped, most presumably by accident. As such bash
autocompletion was missing ever since 13.0.0-1. Readding that part
brings back the missing file:

| diff -Nru rust-ripgrep-13.0.0/debian/rules rust-ripgrep-13.0.0/debian/rules
| --- rust-ripgrep-13.0.0/debian/rules2021-08-31 22:06:04.0 +0200
| +++ rust-ripgrep-13.0.0/debian/rules2022-02-20 13:48:27.0 +0100
| @@ -1,6 +1,6 @@
|  #!/usr/bin/make -f
|  %:
| -   dh $@ --buildsystem cargo
| +   dh $@ --buildsystem cargo --with bash-completion
| 
|  execute_after_dh_testdir:
| find . ! -newermt "jan 01, 2000" -exec touch {} +

and then after rebuilding the binary package

| $ debdiff ripgrep_13.0.0-2_amd64.deb ripgrep_13.0.0-2.1_amd64.deb
| [The following lists of changes regard files as different if they have
| different names, permissions or owners.]
| 
| Files in second .deb but not in first
| -
| -rw-r--r--  root/root   /usr/share/bash-completion/completions/rg
| drwxr-xr-x  root/root   /usr/share/bash-completion/
| drwxr-xr-x  root/root   /usr/share/bash-completion/completions/
| 
| Control files: lines which differ (wdiff format)
| [...]

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Sun, 2022-02-20 at 10:03 +0100, Ricardo Fraile wrote:
> Only to point that adduser is the recommended way to handle accounts in 
> maintainer scripts [1] and Debian Code Search reports 267 packages using 
> it [2], but dh_sysusers [3] seems to handle the same task on the 
> packages and works with useradd under the hood too.

There is certainly some work to be done to reconcile the three different
ways of managing users.

There needs to be:

- a "right way" to add a system user from a package
- a "right way" to add a system user from the command line
- a "right way" to do low-level user management tasks

I had envisioned "adduser" as a Debian policy enforcer on top of the
more distribution-agnostic tools from shadow. But, it is true now that
some features are confusingly duplicated across these methods. Notably,
there are settings for system user UID ranges in both /etc/login.defs
and /etc/adduser.conf.

There may be value in keeping "adduser" as a higher level tool that can
do helpful things by default (e.g., avoid forbidden UIDs, avoid UID
reuse, do additional clean up of at jobs w/o need for configs, etc.).

I am unsure how to proceed, but I know it will require working well with
the shadow maintainers.

I think I'll start a discussion through the proper channel.

Thanks!

-- 
Jason Franklin

Bug#1005891: runc: failing autopkgtest on one of ci.d.n amd64 workers

[Paul Gevers]

Hi,

On 20-02-2022 11:04, Shengjing Zhu wrote:

That's great to know. Could you retry runc's autopkgtest on
ci-worker13. If it succeeds, can we close this bug?


I hit the retry button three times, two of those were executed on 
ci-worker13 and all three passed.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001001: closed by Salvatore Bonaccorso (Re: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!)

[Paul Gevers]

Control: reopen -1
Control: found -1 5.10.84-1

Hi,

Sad to say, but this week we had two hangs again.

The one on ci-worker-arm64-06 had this:

Feb 15 08:51:12 ci-worker-arm64-06 kernel: kernel BUG at 
include/linux/swapops.h:204!
Feb 15 08:51:12 ci-worker-arm64-06 kernel: Internal error: Oops - BUG: 0 
[#1] SMP


root@ci-worker-arm64-06:~# uname -a
Linux ci-worker-arm64-06 5.10.0-10-arm64 #1 SMP Debian 5.10.84-1 
(2021-12-08) aarch64 GNU/Linux


I'm upgrading the workers to the latest kernel now.

Paul


OpenPGP_signature
Description: OpenPGP digital signature