Bug#1013428:

[Nilson Silva]

Hi!

Complementing: this package is a dependency of this other package 
flask-bootstrap
which had ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817958



Nilson F. Silva

Bug#1009917: gtk4 applications randomly crash

[Evangelos Ribeiro Tzaras]

Control: tags -1 fixed-upstream

On Wed, 20 Apr 2022 18:03:34 +0200 ZenWalker  wrote:
> 
> Unable to run these applications 10 times without crash with mobian pinephone:
> 
> megapixels, gnome-calculator, and gnome-clocks and probably more gtk4 apps
> 
> the crash, running in terminal:
> 
>
Gsk:ERROR:../../../gsk/gl/gskglcommandqueue.c:1266:gsk_gl_command_queue_create_r
ender_target: assertion failed (glCheckFramebufferStatus (GL_FRAMEBUFFER) ==
GL_FRAMEBUFFER_COMPLETE): (0x8cd6 == 0x8cd5)
> Bail out!
Gsk:ERROR:../../../gsk/gl/gskglcommandqueue.c:1266:gsk_gl_command_queue_create_r
ender_target: assertion failed (glCheckFramebufferStatus (GL_FRAMEBUFFER) ==
GL_FRAMEBUFFER_COMPLETE): (0x8cd6 == 0x8cd5)
> Aborted (core dumped)
> 
> The issue in gtk repo:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4763
> 
> This patch fixes the bug:
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4570.patch
> 

A couple of patches that fix the issue have been merged upstream:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4687


Cheers
-- 
Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19





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

Bug#1013866: curry-base FTBFS: error: Suffix occurrence of @. For an as-pattern, remove the leading whitespace.

[Adrian Bunk]

Source: curry-base
Version: 1.1.1-3
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=curry-base=sid

...
src/Curry/Syntax/Type.hs:985:17: error:
Suffix occurrence of @. For an as-pattern, remove the leading whitespace.
|
985 |   updateEndPos f@ (Field _ _ _) = f
| ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1005832: more info

[Mark A. Hershberger]

Found this bug because this is the only hit I found on search engines for the 
error I was seeing. I have a Debian system. 

The problem is apparently because /usr/lib/libreoffice/share/extensions is (in 
my case) a 0-byte file and installing an extension resolves the issue. 

I was also able to resolve it by erasing the file and creating the directory. 

Example: 

mah@gabriel:~$ libreoffice 
Warning: failed to launch javaldx - java may not function correctly 
terminate called after throwing an instance of 
'com::sun::star::deployment::DeploymentException' 
Unspecified Application Error 
mah@gabriel:~$ libreoffice --version 
LibreOffice 7.3.4.2 30(Build:2) 

mah@gabriel:~$ sudo rm /usr/lib/libreoffice/share/extensions 
mah@gabriel:~$ sudo mkdir /usr/lib/libreoffice/share/extensions 
mah@gabriel:~$ libreoffice 
Warning: failed to launch javaldx - java may not function correctly 
mah@gabriel:~$ dpkg -S /usr/lib/libreoffice/share/extensions 
dpkg-query: no path found matching pattern 
/usr/lib/libreoffice/share/extensions 
mah@gabriel:~$ apt-file search /usr/lib/libreoffice/share/extensions | cut -d : 
-f 1 | sort -u | xargs dpkg -l 
Desired=Unknown/Install/Remove/Purge/Hold 
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend 
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) 
||/ Name Version Architecture Description 
+++-==-=--===
 
ii libreoffice-common 1:7.3.4~rc2-1~bpo11+1 all office productivity suite -- 
arch-independent files 
un libreoffice-wiki-publisher   (no description available) 
un libreoffice-writer2latex   (no description available) 
un libreoffice-writer2xhtml   (no description available) 
dpkg-query: no packages found matching eyes17 
dpkg-query: no packages found matching libreoffice-canzeley-client 
dpkg-query: no packages found matching libreoffice-dmaths 
dpkg-query: no packages found matching libreoffice-grammalecte 
dpkg-query: no packages found matching libreoffice-lightproof-en 
dpkg-query: no packages found matching libreoffice-lightproof-hu 
dpkg-query: no packages found matching libreoffice-lightproof-pt-br 
dpkg-query: no packages found matching libreoffice-lightproof-ru-ru 
dpkg-query: no packages found matching libreoffice-nlpsolver 
dpkg-query: no packages found matching libreoffice-numbertext 
dpkg-query: no packages found matching libreoffice-parlatype 
dpkg-query: no packages found matching libreoffice-texmaths 
dpkg-query: no packages found matching libreoffice-voikko 

Bug#1013671: vlc: Video display in a separate window

[Christopher Bailey]

Confirming bug with vlc/unstable,now 3.0.17.4-4 amd64 under a Gnome desktop on 
a Sid installation. Downgrading to previous release fixes.

Bug#1013752: Transition KDE PIM 22.04

[Sebastian Ramacher]

On 2022-06-25 20:45:37 +0200, Patrick Franz wrote:
> Hi Sebastian,
> 
> Am Samstag, 25. Juni 2022, 20:30:32 CEST schrieb Sebastian Ramacher:
> [...]
> > > A fixed version of kgpg is in experimental and just needs to be
> > > uploaded to unstable once KDE PIM 22.04 is uploaded there. There
> > > are patches available for both digikam and kjots. I can patch kjots
> > > myself and point the digikam maintainers to the existing patch.
> > 
> > Just to be clear: is the patch for digikam for kdepim compat or does
> > it also fix the build failure with ffmpeg 5.0?
> 
> It would be purely for KDE PIM (https://invent.kde.org/graphics/
> digikam/-/commit/51efe295a222070743187af0367b0bf957879337).

I see. If you (and the KDE team) are okay with temporarly removing
digikam from testing, then please feel free to go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1013818: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: slinkwatch
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages slinkwatch depends on:
ii  libc6  2.31-13+deb11u3

slinkwatch recommends no packages.

slinkwatch suggests no packages.

Bug#1013819: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: syncthing
Version: 1.18.6~ds1-1~bpo11+1
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages syncthing depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u3

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#1013817: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: packer
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages packer depends on:
ii  libc6  2.31-13+deb11u3

packer recommends no packages.

Versions of packages packer suggests:
pn  ansible  
pn  docker.io
ii  qemu-system  1:5.2+dfsg-11+deb11u2

Bug#1013816: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: nomad-driver-podman
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Bug#1013743: python3-pyqt5: Crash with openshot-qt

[Dmitry Shachnev]

Hi Christian!

On Sat, Jun 25, 2022 at 10:26:24AM +0200, Christian Marillat wrote:
> Package: python3-pyqt5
> Version: 5.15.7+dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> Since qt 15.5 openshot-qt crash with :
>
> INFO main_window: updateStatusChanged
> Unhandled Python exception
> Caught signal 6 (SIGABRT)
>  Unhandled Exception: Stack Trace 
>   /lib/x86_64-linux-gnu/libc.so.6 ( abort 
> + 0x112 )  [0x7f076efbb546]
>   /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ( 
>   + 0x90b51)  [0x7f076dc90b51]
>   /usr/lib/python3/dist-packages/PyQt5/QtCore.abi3.so (   
> + 0xb6247)  [0x7f076e2b6247]
>   /usr/lib/python3/dist-packages/PyQt5/sip.cpython-310-x86_64-linux-gnu.so (  
>  + 0x11993)  [0x7f076e7ea993]
>   /usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so (
>+ 0x155c5d)  [0x7f076ad55c5d]
>   /usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so (
>+ 0x3ab0fc)  [0x7f076afab0fc]
>   /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QWidget::event(QEvent*)  
>  + 0x20e )  [0x7f076a5a567e]
[...]

Is there a way to reproduce it? I opened openshot-qt, added a video, clicked
some buttons but it did not crash.

Is it related to upgrade of Qt itself (5.15.2 to 5.15.4) or upgrade of PyQt5
or python3-pyqt5.sip?

Can you install these debug packages and see if stacktrace becomes better?

- python3-pyqt5-dbgsym
- python3-pyqt5.sip-dbgsym
- libqt5core5a-dbgsym
- libqt5gui5-dbgsym
- libqt5widgets5-dbgsym

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1013815: liblognorm-doc: missing Breaks+Replaces: liblognorm-dev (<< 2.0.6-2)

[Andreas Beckmann]

Package: liblognorm-doc
Version: 2.0.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../liblognorm-doc_2.0.6-3_all.deb ...
  Unpacking liblognorm-doc (2.0.6-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/liblognorm-doc_2.0.6-3_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/liblognorm-dev/html/_images/graph.png', 
which is also in package liblognorm-dev 2.0.6-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/liblognorm-doc_2.0.6-3_all.deb


cheers,

Andreas


liblognorm-dev=2.0.6-1_liblognorm-doc=2.0.6-3.log.gz
Description: application/gzip

Bug#648436: Fwd: yaku-ns_0.2-1_amd64.changes REJECTED

[Gürkan Myczko]

 Original Message 
Subject: yaku-ns_0.2-1_amd64.changes REJECTED
Date: 24.06.2022 17:10
From: Thorsten Alteholz 
To: Gürkan Myczko 

Hi,

according to the file header the license of this software is only GPL-2 
instead of GPL-2+.
Please also mention the files licensed under a BSD license in your 
debian/coypright.

Last but not least please mention all copyright holder.

Thanks!
 Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Bug#1001622: Fwd: groops_0+git20220120+ds-1_amd64.changes REJECTED

[Gürkan Myczko]

 Original Message 
Subject: groops_0+git20220120+ds-1_amd64.changes REJECTED
Date: 25.06.2022 13:00
From: Thorsten Alteholz 
To: Gürkan Myczko 

Hi,

our hardworking trainees added a note to that package:

  File source\external\nrlmsis2\alt2gph.F90

  has a non-free wording here:

! The MSIS Software (hereinafter Software) is property of the United 
States   
   . 
  │
! Government, as represented by the Secretary of the Navy. Methods 
performed
! by this software are covered by U.S. Patent Number 10,641,925. The 
Government   
 
 │
! of the United States of America, as represented by the Secretary 
of the Navy,
! herein grants a non-exclusive, non-transferable license to the 
Software for
! academic, non-commercial, purposes only. A user of the Software 
shall not:
! (i) use the Software for any non-academic, commercial purposes, 
(ii) make
! any modification or improvement to the Software, (iii) disseminate 
the
! Software or any supporting data to any other person or entity who 
will use
! the Software for any non-academic, commercial purposes, or (iv) 
copy the
! Software or any documentation related thereto except for (a) 
distribution
! among the users personal computer systems, archival, or emergency 
repair   
e
   │
! purposes, or (b) distribution for non-commercial, academic 
purposes, without
! first obtaining the written consent of IP Counsel for the Naval 
Research 
 
│

! Laboratory.

 There is a huge lumping together of copyright owners in d/copyright for 
stanza


  Files: *

  This is too broad. A significant part of the files are ony (C) one or 
two

  authors.

  License for source\external\iers\CNMTX.F has a controversial clause 
(see long

  thread on d.devel):

  *  4. In any published work produced by the user and which includes
  * results achieved by using the Software, you shall acknowledge
  * that the Software was used in obtaining those results.


In the README.md there is also a CC-ND license mentioned.

  Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Bug#1006601: Fwd: qvge_0.6.3-1_amd64.changes REJECTED

[Gürkan Myczko]

 Original Message 
Subject: qvge_0.6.3-1_amd64.changes REJECTED
Date: 25.06.2022 14:00
From: Thorsten Alteholz 
To: Gürkan Myczko 

Hi,

our hardworking trainees left a note at your package:

  File src\appbase\CPlatformWin32.cpp is Copyright  2011, Gerolf 
Reinwardt. All

  rights reserved. No mention in d/copyright.

  File qtpropertybrowser\lineedit.cpp is Copyright (c) 2007 Trolltech 
ASA

  , but I do not see it listed in d/copyright.

  Similar remark for qtpropertybrowser\qtbuttonpropertybrowser.cpp that 
is

  Copyright (C) 2015 The Qt Company Ltd.


Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Bug#1012647: Bug has been fixed in version 6.30.223.271-20

[Drew Stephens]

package: broadcom-sta-dkms
severity: minor

Dear Mr. Bloch,
At this point, 6.30.223.271-20 is in testing, which already had fixed 
the bug in question. Thus, this bug report should should be closed, as 
it is already fixed.

Thank you for your time. Have a great day.

Bug#1012195: dpkg: lintian autopkgtest *may* have spotted a regression in security update of dpkg

[Salvatore Bonaccorso]

Hi,

On Wed, Jun 01, 2022 at 03:53:32AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2022-05-31 at 22:10:29 +0200, Paul Gevers wrote:
> > Source: dpkg
> > Version: 1.20.10
> > Severity: important
> 
> > Our proposed-updates queue [1] show regressions in the autopkgtest of
> > lintian with the security version of dpkg. Looking at the logs [2], it
> > appears to me that the file permissions of files in the test
> > change. If I understand the security issue correctly, I don't think
> > that was intended. Again, I may be reading the signs wrong, but I
> > suspect you want to have a look.
> 
> Hmm, right. We noticed this on the new security queue autopkgtest
> infra, and I checked locally and it was reproducible, but for some
> reason I disregarded it as not relevant. :/
> 
> Perhaps because it was not showing up on lintian's sid test suite (but
> just checked now and the test seems to have been removed from there),
> and I'm assuming I didn't test against the previous dpkg version. So,
> it seems I botched the testing procedure somewhere.
> 
> In any case, I think the attached patch fixes this, which during the
> days I was preparing the fix this came to mind to take into account,
> but I guess I forgot along the way. :/ I'll test this tomorrow against
> the older lintian test suite. I guess I'll need to talk with the
> security team avoid issuing a security fixup?

In fact I think this regression can be included as fix in the upcoming
point releases if SRM agree, and so avoid an out of order dpkg update
again to fix this rather edge-case regression (and instread batch it
with other updates for the point releases).

Did you found time already for fixes? The bullseye 11.4 point release
has now been settled for the July 9th, with freezing the upload window
the preceeding weekend.

Thank you Guillem for your work!

Regards,
Salvatore

Bug#1013807: luajit doesn't work on ppc64el; use lua or remove binaries on ppc64el

[Paul Gevers]

Package: nginx
Version: 1.20.2-2
Severity: serious
X-Debbugs-CC: 1004...@bugs.debian.org, lu...@debian.org
Control: reopen 1004511
Control: block 1004511 by -1
Control: block 1012362 by 1004511
Control: clone -1 -2 -3 -4 -5 -6 -7 -8
Control: reassign -2 src:aegisub 3.2.2+dfsg-6
Control: reassign -3 src:ettercap 1:0.8.3.1-9
Control: reassign -4 src:knot-resolver 5.5.1-1
Control: reassign -5 src:snort 2.9.15.1-6
Control: reassign -6 src:trafficserver  9.1.2+ds-10
Control: reassign -7 src:uwsgi-plugin-luajit 0.0.7
Control: reassign -8 src:luakit 1:2.3-1

Dear maintainers,

We have been working for a while to get a working libluajit on ppc64el 
(for reference, see history in bug #1012362). In the end we concluded 
that it's not going to work as commitment upstream is lacking to support 
ppc64el.


Your source package build depends on libluajit-5.1-dev when building on 
ppc64el and at least one of its binaries depends on libluajit-5.1-2 on 
that architecture. Please use liblua on ppc64el if that works for your 
package, otherwise please request removal of the binaries on ppc64el 
(e.g. by reassigning the bug to ftp.debian.org, lowering severity and 
re-titling appropriately).


Sorry we couldn't solve the problem in a better way.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013806: ruby-rails-html-sanitizer: CVE-2022-32209

[Salvatore Bonaccorso]

Source: ruby-rails-html-sanitizer
Version: 1.4.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-rails-html-sanitizer.

CVE-2022-32209[0]:
| # Possible XSS Vulnerability in Rails::Html::SanitizerThere is a
| possible XSS vulnerability with certain configurations of
| Rails::Html::Sanitizer.This vulnerability has been assigned the CVE
| identifier CVE-2022-32209.Versions Affected: ALLNot affected:
| NONEFixed Versions: v1.4.3## ImpactA possible XSS vulnerability with
| certain configurations of Rails::Html::Sanitizer may allow an attacker
| to inject content if the application developer has overridden the
| sanitizer's allowed tags to allow both `select` and `style`
| elements.Code is only impacted if allowed tags are being overridden.
| This may be done via application configuration:```ruby# In
| config/application.rbconfig.action_view.sanitized_allowed_tags =
| ["select", "style"]```see
| https://guides.rubyonrails.org/configuring.html#configuring-action-
| viewOr it may be done with a `:tags` option to the Action View helper
| `sanitize`:```%= sanitize @comment.body, tags: ["select", "style"]
| %```see https://api.rubyonrails.org/classes/ActionView/Helpers/San
| itizeHelper.html#method-i-sanitizeOr it may be done with
| Rails::Html::SafeListSanitizer directly:```ruby# class-level
| optionRails::Html::SafeListSanitizer.allowed_tags = ["select",
| "style"]```or```ruby# instance-level
| optionRails::Html::SafeListSanitizer.new.sanitize(@article.body, tags:
| ["select", "style"])```All users overriding the allowed tags by any of
| the above mechanisms to include both "select" and "style" should
| either upgrade or use one of the workarounds immediately.##
| ReleasesThe FIXED releases are available at the normal locations.##
| WorkaroundsRemove either `select` or `style` from the overridden
| allowed tags.## CreditsThis vulnerability was responsibly reported by
| [windshock](https://hackerone.com/windshock?type=user).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-32209
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32209
[1] https://hackerone.com/reports/1530898
[2] 
https://discuss.rubyonrails.org/t/cve-2022-32209-possible-xss-vulnerability-in-rails-sanitizer/80800
[3] 
https://github.com/rails/rails-html-sanitizer/commit/45a5c10fed3d9aa141594c80afa06d748fa0967d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1013805: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: nomad-driver-lxc
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages nomad-driver-lxc depends on:
ii  libc6  2.31-13+deb11u3
ii  liblxc11:4.0.6-2
ii  lxc-templates  3.0.4-5
pn  nomad  

nomad-driver-lxc recommends no packages.

nomad-driver-lxc suggests no packages.

Bug#1013804: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: nomad
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages nomad depends on:
ii  libc62.31-13+deb11u3
pn  pipexec  
ii  procps   2:3.3.17-5

Versions of packages nomad recommends:
pn  containernetworking-plugins  
ii  ethtool  1:5.9-1

Versions of packages nomad suggests:
pn  consul  
ii  default-jre 2:1.11-72
pn  nomad-driver-lxc
pn  nomad-driver-podman 
pn  nomad-driver-singularity
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11+deb11u2

Bug#1013803: autopkgtest: limiting restrictions by architecture

[Andreas Beckmann]

Package: autopkgtest
Version: 5.22
Severity: wishlist

Hi,

I'd like to limit certain restrictions to particular architectures.
Most prominent example would be flaky, where I'd prefer something like
  Restrictions: flaky [!amd64]
or
  Restrictions: flaky [ppc64el i386]
(i.e. annotating restrictions with a dpkg like arch dependency syntax)
over
1) marking the test as flaky on all architectures (if the test fails
on "well supported" architectures, it should really fail, but if it
fails (sporadically) on "exotic" ones (upstream may consider everything
beyond amd64 as exotic), this could be marked as flaky until someone
manages to investigate (and fix)) or
2) completely disabling the test for this architecture (having an
up-to-date flaky failure test log available may serve as a start for
investigation).

Some examples:
src:nvidia-graphics-drivers-tesla-470 fails to build the kernel module
for ppc64el kernels due to transitive gpl symbol usage, an issue that
needs to be fixed upstream.
That has really surprised me since ppc64el is one of the three
architectures supported upstream by nvidia-cuda-toolkit. I only noticed
that after fixing dkms and autodep8 to make autopkgtest-pkg-dkms
actually build kernel modules. (Manually testing to build non-amd64
nvidia kernel modules in a chroot I last tried a few years ago after
someone reported a bug.)

src:cub/src:libthrust have their upstream testsuite failing to compile
on some architectures where the signedness of char differs from the
signedness of char on amd64 ... something I need to verify on the latest
upstream release before reporting it upstream.


Andreas

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Thomas Schmitt]

Hi,

Zhang Boyang wrote:
> These experiments all succeeded. Thank you very much! Good Job! :)

Thank you for testing and challenging.


I wrote:
> > For now i decided to take the 50 seconds with dash.

> if you really want to reduce runtime I would suggest using
> `sort -s -u -k 2 merged_md5sum.txt' instead of processing each line
> by hand.

The task is to identify those which need newly computed MD5 because they
might have changed. Mostly i know which directories are suspects, because
they are on hard disk and get mapped back into the emerging ISO. Their
MD5s get recomputed from the files on hard disk.
Some other paths in the md5sum.txt may appear multiple times. In this case
it is clear that the data of the file in the emerging ISO stem from iso1.
But it is not clear which of the multiple lines in md5sum.txt stems from
iso1. So the MD5 has to be recomputed from the file in mounted iso1.


> I saw there are some other logic to process md5 records from
> different group of files, so we can use `grep' and `grep -v' to split them,
> process them separately, then merge them finally.

That's a great idea.
The majority of files is in ./pool and surely needs no recomputing, even
if listed multiple times (due to overlapping ISO pools).

This here

  ( fgrep ' ./pool/' temp_file

needs 1.9 seconds instead of 7.2 seconds with the old

  polish_md5sum_txt >temp_file

Times were measured by date '+%s.%N' around the polishing commands.
polish_md5sum_txt and its subordinate were slightly modified for the new
method to read from stdin and to not expect any ./pool file.
The latter brought 0.9 seconds.

The number of lines in md5sum.txt is then the same as with the old method.
My test loop with md5sum -c on the mounted result ISO reports no
mismatches. (It is annoying that gzip inserts a time stamp, so that the
Packages.gz files differ although they bear the same uncompressed
content. So the md5sum.txt file shows differences, too, from run to run.)


> Unfortunately the option `-s' of `sort' is not standard

I understand that it is needed to keep sort -k 2 from distinguishing
lines with differences outside of -k 2 so that sort -u could throw out
surplus lines with duplicate paths.

But with above code sort -u is not needed.
The pool lines have to be identical even if duplicate paths appear at
all. (I only know of one old debian package which existed with different
content but same name, long ago.) So uniq can do its job.
The other lines are made unique by the shell function polish_md5sum_txt.

Complexity-wise this replaces a slow O(n) algorithm by a faster O(n) and
an additional O(n * log(n)) run. At some size of Debian the slow speed
of the linear loop will be compensated by the sorting complexity.
But there is still room: A sort of 11,000 lines lasts about 0.03 seconds.

I will probably commit this change tomorrow. Now it needs cleaning and
handling of the new dependency uniq.


Have a nice day :)

Thomas

Bug#1013801: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Source: golang-github-satta-ifplugo
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Bug#1013802: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: ncbi-entrez-direct
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages ncbi-entrez-direct depends on:
ii  curl7.74.0-1.3+deb11u1
ii  libc6   2.31-13+deb11u3
ii  libwww-perl 6.52-1
ii  libxml-simple-perl  2.25-1
ii  perl5.32.1-4+deb11u2
ii  wget1.21-1+deb11u1

ncbi-entrez-direct recommends no packages.

Versions of packages ncbi-entrez-direct suggests:
ii  curl   7.74.0-1.3+deb11u1
ii  libxml2-utils  2.9.10+dfsg-6.7+deb11u2
ii  python33.9.2-3

Bug#1013800: timeline for enforcing dependencies for gopsutil v3 breaking changes

[Nicholas D Steeves]

Package: golang-github-hashicorp-consul-dev
Severity: normal

Control: affects -1 golang-github-shirou-gopsutil

Dear Maintainer,

The upload of golang-github-shirou-gopsutil/3.21.10-1 introduced the
following breaking changes:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
  https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md

Upstream writes "from v3.20.10, gopsutil becomes v3 which breaks
backwards compatibility".  Our gopsutil package dependencies do yet
enforce the compatibility break.

Affected packages are as follows:

  consul
  golang-github-satta-ifplugo
  ncbi-entrez-direct
  nomad
  nomad-driver-lxc
  nomad-driver-podman
  packer
  slinkwatch
  syncthing

Please verify that your package is ready for gopsutil v3.  If the
version in sid/unstable is v3-ready, then please set "fixed -1
sourcepkgname/version" for this bug.  If not, the latest upstream
release may already support it, in which case, please import it!  If
the latest release is not ready, please contact that upstream without
delay, because some may be reticent to keep pace with changing
libraries.  It may be worth mentioning to them that the v2 series
is EOL:

  https://github.com/shirou/gopsutil/blob/master/README.md#v3-migration
* Contains the upstream statement v2 is gone.
  https://pkg.go.dev/github.com/shirou/gopsutil/v3#readme-v3-migration
* Also available here.
  https://github.com/shirou/gopsutil/blob/v2
* (404 error)

Three weeks from now (18 July) I will increase severity to important
as a gentle reminder.

Around 17 September I will upload to experimental.

The 15 October I will increase severity to RC.  To justify downgrading
severity at that time, please add the forwarded tag the bug, with a
URL that shows that upstream is working towards solving this issue
before 2023.

Either the first week of December, or the first week of January 2023
(at the latest), the compatibility break will be enforced with an
upload of gopsutil to unstable.

I hope that everyone affected feels that these deadline are fair, and
prefers to have a roadmap rather than vague "at some point" guesturing
followed by stresssful surprises at the worst times.


Best wishes,
Nicholas


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

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

Versions of packages golang-github-hashicorp-consul-dev depends on:
pn  golang-github-armon-go-metrics-dev 
pn  golang-github-armon-go-radix-dev   
pn  golang-github-hashicorp-go-bexpr-dev   
pn  golang-github-hashicorp-go-cleanhttp-dev   
pn  golang-github-hashicorp-go-hclog-dev   
pn  golang-github-hashicorp-go-memdb-dev   
pn  golang-github-hashicorp-go-msgpack-dev 
pn  golang-github-hashicorp-go-rootcerts-dev   
pn  golang-github-hashicorp-go-uuid-dev
ii  golang-github-hashicorp-golang-lru-dev 0.5.4-2
pn  golang-github-hashicorp-hcl-dev
pn  golang-github-hashicorp-hil-dev
pn  golang-github-hashicorp-memberlist-dev 
pn  golang-github-hashicorp-raft-boltdb-dev
pn  golang-github-hashicorp-raft-dev   
pn  golang-github-hashicorp-serf-dev   
pn  golang-github-hashicorp-yamux-dev  
pn  golang-github-inconshreveable-muxado-dev   
pn  golang-github-miekg-dns-dev
pn  golang-github-mitchellh-cli-dev
pn  golang-github-mitchellh-copystructure-dev  
pn  golang-github-pascaldekloe-goe-dev 
ii  golang-golang-x-sys-dev0.0~git20210124.22da62e-1

golang-github-hashicorp-consul-dev recommends no packages.

golang-github-hashicorp-consul-dev suggests no packages.

Bug#1013752: Transition KDE PIM 22.04

[Patrick Franz]

Hi Sebastian,

Am Samstag, 25. Juni 2022, 20:30:32 CEST schrieb Sebastian Ramacher:
[...]
> > A fixed version of kgpg is in experimental and just needs to be
> > uploaded to unstable once KDE PIM 22.04 is uploaded there. There
> > are patches available for both digikam and kjots. I can patch kjots
> > myself and point the digikam maintainers to the existing patch.
> 
> Just to be clear: is the patch for digikam for kdepim compat or does
> it also fix the build failure with ffmpeg 5.0?

It would be purely for KDE PIM (https://invent.kde.org/graphics/
digikam/-/commit/51efe295a222070743187af0367b0bf957879337).


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1013799: ITP: phosh-mobile-settings -- Application to configure mobile settings for Phosh

[Guido Günther]

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

* Package name: phosh-mobile-settings
  Version : 0.0.1
  Upstream Author : Guido Günther 
* URL : https://gitlab.gnome.org/guidog/phosh-mobile-settings
* License : GPL
  Programming Lang: C
  Description : Application to configure mobile settings for Phosh

Mobile Settings allows to configure some advanced settings of Phosh and
related components via a GUI that would otherwise involve using the
command line like scaling down applications or haptic / led feedback
settings.

It will be maintained under the DebianOnMobile umbrella.

Bug#1013752: Transition KDE PIM 22.04

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/kdepim-22.04.html

On 2022-06-25 13:37:32 +0200, Patrick Franz wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org
> 
> Hi Release team,
> 
> we would like to request a transition for KDE PIM 22.04.
> 
> We have uploaded KDE PIM 22.04 to experimental, but since KDE PIM
> does not provide ABI stability and some packages outside
> KDE PIM depend on it, we need a transition.
> 
> The packages depending on KDE PIM are:
> 
> * digikam
> * kgpg
> * kio-gdrive
> * kjots
> * kmymoney
> * kraft
> * zanshin
> 
> kio-gdrive, kmymoney, kraft and zanshin simply need a rebuild against
> KDE PIM 22.04.
> 
> A fixed version of kgpg is in experimental and just needs to be uploaded
> to unstable once KDE PIM 22.04 is uploaded there. There are patches
> available for both digikam and kjots. I can patch kjots myself and point
> the digikam maintainers to the existing patch.

Just to be clear: is the patch for digikam for kdepim compat or does it
also fix the build failure with ffmpeg 5.0?

Cheers

> 
> Here is the Ben file:
> 
> ---
> title = "KDEPIM 22.04";
> 
> is_affected = .depends ~ /libkf5.*-21.12/ | .depends ~ /libkf5.*-22.04/;
> is_good = .depends ~ /libkf5.*-22.04/;
> is_bad = .depends ~ /libkf5.*-21.12/;
> ---
> 
> Thank you.
> 
> 
> -- 
> Med vänliga hälsningar
> 
> Patrick Franz

-- 
Sebastian Ramacher

Bug#1013798: cargo-binutils: ships /usr/bin/rust-lld, already provided by rustc

[Andreas Beckmann]

Package: cargo-binutils
Version: 0.3.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../cargo-binutils_0.3.5-1_amd64.deb ...
  Unpacking cargo-binutils (0.3.5-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/cargo-binutils_0.3.5-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/rust-lld', which is also in package rustc 
1.59.0+dfsg1-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/cargo-binutils_0.3.5-1_amd64.deb


cheers,

Andreas


rustc=1.59.0+dfsg1-2_cargo-binutils=0.3.5-1.log.gz
Description: application/gzip

Bug#1013797: grub-efi: grub no longer offers to boot Windows

[Ralf Jung]

Package: grub-efi
Version: 2.06-3
Severity: important

Dear Maintainer,

After doing a system update, the option to boot Windows has disappeared from 
Grub.
I have not changed anything else.
This will be a big problem the next time I actually need to boot Windows.

Kind regards,
Ralf

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda2 /boot ext4 rw,relatime 0 0
/dev/mapper/vg-home /home ext4 rw,relatime 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/mapper/store /mnt/store ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="2"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2  
2af046c2-1c1f-43ca-9692-7ea1d357493b
else
  search --no-floppy --fs-uuid --set=root 2af046c2-1c1f-43ca-9692-7ea1d357493b
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=1920x1080,1024x768,auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=3
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=3
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2  
2af046c2-1c1f-43ca-9692-7ea1d357493b
else
  search --no-floppy --fs-uuid --set=root 2af046c2-1c1f-43ca-9692-7ea1d357493b
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=keep
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-8f0db0a1-2c26-4b6c-a132-e8292709197e' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2  
2af046c2-1c1f-43ca-9692-7ea1d357493b
else
  search --no-floppy --fs-uuid --set=root 
2af046c2-1c1f-43ca-9692-7ea1d357493b
fi
echo'Loading Linux 5.18.0-2-amd64 ...'
linux   /vmlinuz-5.18.0-2-amd64 root=/dev/mapper/vg-root ro  quiet 
splash
echo'Loading initial ramdisk ...'
initrd  /initrd.img-5.18.0-2-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-8f0db0a1-2c26-4b6c-a132-e8292709197e' {
menuentry 'Debian GNU/Linux, with Linux 5.18.0-2-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.18.0-2-amd64-advanced-8f0db0a1-2c26-4b6c-a132-e8292709197e' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 

Bug#1013796: haskell-hxt-regex-xmlschema FTBFS: Parse error in pattern: !n

[Adrian Bunk]

Source: haskell-hxt-regex-xmlschema
Version: 9.2.0.3-7
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-hxt-regex-xmlschema=sid

...
src/Text/Regex/XMLSchema/Generic/Regex.hs:72:1: warning: [-Wunused-imports]
The import of ‘Data.Monoid’ is redundant
  except perhaps to import instances from ‘Data.Monoid’
To import instances alone, use: import Data.Monoid()
   |
72 | import Data.Monoid  ((<>))
   | ^^

src/Text/Regex/XMLSchema/Generic/Matching.hs:247:27: error:
Parse error in pattern: !n
|
247 | token' re' fcs' (uns, ! n) inp
|   ^^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013795: haskell-maths FTBFS: error: Bang pattern in expression context: !j

[Adrian Bunk]

Source: haskell-maths
Version: 0.4.9-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-maths=sid

...
Math/Algebra/LinearAlgebra.hs:222:60: error:
Bang pattern in expression context: !j
Did you mean to add a space after the '!'?
|
222 |in zip is $ L.transpose [map (negate . (!j)) m' | j <- 
js]

|^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013794: haskell-psqueue FTBFS: Encountered missing or private dependencies: base >=4.3 && <4.15

[Adrian Bunk]

Source: haskell-psqueue
Version: 1.1.0.1-3
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-psqueue=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.3 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013793: haskell-store-core FTBFS: error: Module ‘GHC.Prim’ does not export ‘unsafeCoerce#’

[Adrian Bunk]

Source: haskell-store-core
Version: 0.4.4.3-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-store-core=sid

...
src/Data/Store/Core.hs:52:28: error:
Module ‘GHC.Prim’ does not export ‘unsafeCoerce#’
   |
52 | import   GHC.Prim (unsafeCoerce#, RealWorld, ByteArray#, 
copyByteArrayToAddr#, copyAddrToByteArray#)
   |^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013792: haskell-syb-with-class FTBFS: Encountered missing or private dependencies: template-haskell >=2.4 && <2.17

[Adrian Bunk]

Source: haskell-syb-with-class
Version: 0.6.1.13-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-syb-with-class=sid

...
hlibrary.setup: Encountered missing or private dependencies:
template-haskell >=2.4 && <2.17

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013791: haskell-inspection-testing FTBFS: Encountered missing or private dependencies: base >=4.9 && <4.15, ghc >=8.0.2 && <8.11

[Adrian Bunk]

Source: haskell-inspection-testing
Version: 0.4.2.4-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-inspection-testing=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.9 && <4.15, ghc >=8.0.2 && <8.11

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013790: haskell-tree-monad FTBFS: Encountered missing or private dependencies: base >=4.13 && <4.15

[Adrian Bunk]

Source: haskell-tree-monad
Version: 0.3.1-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-tree-monad=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.13 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1012227: webkitgtk: CPU usage

[tmcconnell168]

On Thu, 2022-06-09 at 15:59 -0500, Tim McConnell wrote:
> Source: webkit2gtk
> Version: 2.36.3-1
> Followup-For: Bug #1012227
> X-Debbugs-Cc: tmcconnell...@gmail.com
> 
> Dear Maintainer,
> 
> running sudo ps -aux |grep WebKitWebProcess
> tmick    4071296 53.0  9.5 88411428 683212 ? RLl  15:38   8:13
> /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 13 35
> tmick    4073180  0.0  0.0   6432  2284 pts/1    T    15:52   0:00
> grep
> WebKitWebProcess
> tmick    4073195  0.0  0.0   6432  2284 pts/1    S+   15:54   0:00
> grep
> WebKitWebProcess
> 
> And stays there until I shutdown everything that uses it. Evolution,
> TOR,
> Firefox and reboot. It's like I'm running Windows 3.11 again.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
Update: Evolution mailing list gave me this command to run: gdb --batch
--ex "t a a bt" --pid=27250 &>>~/bt.txt. I've attached it to this
email. Hope it helps. 
[New LWP 27261]
[New LWP 27265]
[New LWP 27267]
[New LWP 27278]
[New LWP 27281]
[New LWP 27282]
[New LWP 27283]
[New LWP 27317]
[New LWP 27320]
[New LWP 27321]
[New LWP 27322]

warning: .dynamic section for "/lib/x86_64-linux-gnu/libgnutls.so.30" is not at 
the expected address (wrong library or version mismatch?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f013000a87f in __GI___poll (fds=0x55648400ae00, nfds=2, timeout=29685) 
at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.

Thread 12 (Thread 0x7f0078eaa640 (LWP 27322) "WebKitWe:shlo0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64 
(futex_word=futex_word@entry=0x556484224898, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x556484224898, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at 
../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x556484224848, cond=0x556484224870) at pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556484224870, mutex=0x556484224848) at 
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f0078eaa640) at 
pthread_create.c:481
#7  0x7f013001676f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 11 (Thread 0x7f00796ab640 (LWP 27321) "WebKitWebP:sh0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64 
(futex_word=futex_word@entry=0x556484224328, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x556484224328, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at 
../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x5564842242d8, cond=0x556484224300) at pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556484224300, mutex=0x5564842242d8) at 
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f00796ab640) at 
pthread_create.c:481
#7  0x7f013001676f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 10 (Thread 0x7f00cc87b640 (LWP 27320) "WebKitW:disk$0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64 
(futex_word=futex_word@entry=0x556483f44708, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x556483f44708, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at 
../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x556483f446b8, cond=0x556483f446e0) at 

Bug#1012817: evolution-common: Checking local mail causes High CPU Usage

[tmcconnell168]

On Tue, 2022-06-14 at 13:44 -0500, Tim McConnell wrote:
> Package: evolution-common
> Version: 3.44.2-1
> Severity: important
> X-Debbugs-Cc: tmcconnell...@gmail.com
> 
> Dear Maintainer,
> 
> What led up to the situation? Not sure, it took a while to narrow
> down the CPU
> usage.
> 
> What exactly did you do (or not do) that was effective (or
> ineffective)?
> Ineffective attempts to fix have been updating kernel, reducing log
> reports
> being sent and killing evolution by evolution --force shutdown.
> 
> What was the outcome of this action? No Change WebkitWebProcess still
> consumes
> 50% or higher of my CPU and will go to 100% occasionally, I have
> opened bug
> Bug#1012227: webkitgtk: CPU usage and haven't really found anything.
> 
> What outcome did you expect instead? For my CPU use to be the usualy
> 3 - 20%
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages evolution-common depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
> 
> Versions of packages evolution-common recommends:
> ii  evolution  3.44.2-1
> 
> evolution-common suggests no packages.
> 
> -- no debconf information
See attached file for output from 'gdb --batch --ex "t a a bt" --
pid=27250 &>>~/bt.txt' the mailing list provided the command. 
[New LWP 27261]
[New LWP 27265]
[New LWP 27267]
[New LWP 27278]
[New LWP 27281]
[New LWP 27282]
[New LWP 27283]
[New LWP 27317]
[New LWP 27320]
[New LWP 27321]
[New LWP 27322]

warning: .dynamic section for "/lib/x86_64-linux-gnu/libgnutls.so.30" is not at 
the expected address (wrong library or version mismatch?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f013000a87f in __GI___poll (fds=0x55648400ae00, nfds=2, timeout=29685) 
at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.

Thread 12 (Thread 0x7f0078eaa640 (LWP 27322) "WebKitWe:shlo0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64 
(futex_word=futex_word@entry=0x556484224898, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x556484224898, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at 
../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x556484224848, cond=0x556484224870) at pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556484224870, mutex=0x556484224848) at 
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f0078eaa640) at 
pthread_create.c:481
#7  0x7f013001676f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 11 (Thread 0x7f00796ab640 (LWP 27321) "WebKitWebP:sh0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64 
(futex_word=futex_word@entry=0x556484224328, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x556484224328, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at 
../sysdeps/nptl/futex-internal.c:123
#2  0x7f012be21c30 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x5564842242d8, cond=0x556484224300) at pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x556484224300, mutex=0x5564842242d8) at 
pthread_cond_wait.c:619
#4  0x7f00cdf4048b in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x7f00cdf400d7 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#6  0x7f012be1bd80 in start_thread (arg=0x7f00796ab640) at 
pthread_create.c:481
#7  0x7f013001676f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 10 (Thread 0x7f00cc87b640 (LWP 27320) "WebKitW:disk$0"):
#0  0x7f012be280fa in __futex_abstimed_wait_common64 
(futex_word=futex_word@entry=0x556483f44708, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
#1  0x7f012be2815b 

Bug#1013789: haskell-memoize FTBFS: error: Expecting one more argument to ‘TyVarBndr’

[Adrian Bunk]

Source: haskell-memoize
Version: 0.8.1-6
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-memoize=sid

...
src/Data/Function/Memoize/TH.hs:119:30: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the first argument of ‘Q’, namely
‘(Name, [TyVarBndr], [(Name, Int)])’
  In the type signature:
checkName :: Name -> Q (Name, [TyVarBndr], [(Name, Int)])
|
119 | checkName ∷ Name → Q (Name, [TyVarBndr], [(Name, Int)])
|  ^

src/Data/Function/Memoize/TH.hs:170:31: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature:
buildContext :: Maybe [Int] -> [TyVarBndr] -> [Name] -> CxtQ
|
170 | buildContext ∷ Maybe [Int] → [TyVarBndr] → [Name] → CxtQ
|   ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013788: haskell-harp FTBFS: Encountered missing or private dependencies: base <4.15

[Adrian Bunk]

Source: haskell-harp
Version: 0.4.3.4-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-harp=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013787: haskell-operational FTBFS: error: Ambiguous occurrence ‘singleton’

[Adrian Bunk]

Source: haskell-operational
Version: 0.2.3.5-5
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-operational=sid

...
[1 of 1] Compiling Main ( doc/examples/TicTacToe.hs, 
dist-ghc/build/operational-TicTacToe/operational-TicTacToe-tmp/Main.o )

src/Control/Monad/Operational.hs:26:1: warning: [-Wunused-imports]
The import of ‘Control.Applicative’ is redundant
  except perhaps to import instances from ‘Control.Applicative’
To import instances alone, use: import Control.Applicative()
   |
26 | import Control.Applicative
   | ^^

src/Control/Monad/Operational.hs:26:1: warning: [-Wunused-imports]
The import of ‘Control.Applicative’ is redundant
  except perhaps to import instances from ‘Control.Applicative’
To import instances alone, use: import Control.Applicative()
   |
26 | import Control.Applicative
   | ^^

doc/examples/TicTacToe.hs:46:13: error:
Ambiguous occurrence ‘singleton’
It could refer to
   either ‘Control.Monad.Operational.singleton’,
  imported from ‘Control.Monad.Operational’ at 
doc/examples/TicTacToe.hs:19:1-32
   or ‘Data.List.singleton’,
  imported from ‘Data.List’ at doc/examples/TicTacToe.hs:23:1-16
  (and originally defined in ‘base-4.15.1.0:Data.OldList’)
   |
46 | readBoard = singleton ReadBoard
   | ^

doc/examples/TicTacToe.hs:47:13: error:
Ambiguous occurrence ‘singleton’
It could refer to
   either ‘Control.Monad.Operational.singleton’,
  imported from ‘Control.Monad.Operational’ at 
doc/examples/TicTacToe.hs:19:1-32
   or ‘Data.List.singleton’,
  imported from ‘Data.List’ at doc/examples/TicTacToe.hs:23:1-16
  (and originally defined in ‘base-4.15.1.0:Data.OldList’)
   |
47 | playMove  = singleton . PlayMove
   | ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

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

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

Bug#1013786: haskell-knob FTBFS: Couldn't match type ‘()’ with ‘Integer’

[Adrian Bunk]

Source: haskell-knob
Version: 0.1.1-13
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-knob=sid

...
lib/Data/Knob.hs:71:17: error:
• Couldn't match type ‘()’ with ‘Integer’
  Expected: IO Integer
Actual: IO ()
• In a stmt of a 'do' block:
MVar.modifyMVar_ var (\ _ -> return (fromInteger off))
  In the expression:
do checkOffset off
   MVar.modifyMVar_ var (\ _ -> return (fromInteger off))
  In an equation for ‘IO.seek’:
  IO.seek (Device _ _ var) IO.AbsoluteSeek off
= do checkOffset off
 MVar.modifyMVar_ var (\ _ -> return (fromInteger off))
   |
71 | MVar.modifyMVar_ var (\_ -> return (fromInteger off))
   | ^

lib/Data/Knob.hs:74:17: error:
• Couldn't match type ‘()’ with ‘Integer’
  Expected: IO Integer
Actual: IO ()
• In a stmt of a 'do' block:
MVar.modifyMVar_
  var
  (\ old_off
 -> do let new_off = ...
   checkOffset new_off
   return (fromInteger new_off))
  In the expression:
do MVar.modifyMVar_
 var
 (\ old_off
-> do let ...
  )
  In an equation for ‘IO.seek’:
  IO.seek (Device _ _ var) IO.RelativeSeek off
= do MVar.modifyMVar_ var (\ old_off -> do ...)
   |
74 | MVar.modifyMVar_ var (\old_off -> do
   | ...

lib/Data/Knob.hs:80:17: error:
• Couldn't match type ‘()’ with ‘Integer’
  Expected: IO Integer
Actual: IO ()
• In a stmt of a 'do' block:
MVar.modifyMVar_
  off_var
  (\ _
 -> do size <- IO.getSize dev
   let new_off = ...
   checkOffset new_off
   )
  In the expression:
do MVar.modifyMVar_
 off_var
 (\ _
-> do size <- IO.getSize dev
  )
  In an equation for ‘IO.seek’:
  IO.seek dev@(Device _ _ off_var) IO.SeekFromEnd off
= do MVar.modifyMVar_ off_var (\ _ -> do ...)
   |
80 | MVar.modifyMVar_ off_var (\_ -> do
   | ^^...
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013462: libnvidia-allocator1 has worthless description

[Craig Sanders]

On Fri, Jun 24, 2022 at 08:06:52AM +0200, Andreas Beckmann wrote:
> TBH, I have no clue what that library is good for.  Nvidia was not very
> informative when adding library, these are the two places where it is
> mentioned in the documentation:
>
>o Various libraries that are used internally by other driver components.
>  These include '/usr/lib/libnvidia-cfg.so.510.73.08',
> [...]
>  '/usr/lib/libnvidia-allocator.so.510.73.08'.
>
> * Added support for the GBM API. This adds the new symlink
>   nvidia-drm_gbm.so pointing to the file libnvidia-allocator.so.VERSION to
>   implement a GBM backend driver usable with the GBM loader from the Mesa
> [...]
>
> Do you have some suggestions what to put into the description instead?

Sorry, no.  I tried googling before I posted the bug report, hoping to find
a useful summary but didn't find anything.

> ("Nvidia probably knows a reason for the existence of this library."
> wouldn't be helpful either.)

Maybe something like "Nvidia hasn't bothered documenting what this library is
for" might encourage them to volunteer some details :)

craig

--
craig sanders 

Bug#1013785: haskell-regex-compat-tdfa FTBFS: Bang pattern in expression context: !0

[Adrian Bunk]

Source: haskell-regex-compat-tdfa
Version: 0.95.1.4-8
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-regex-compat-tdfa=sid

...
Text/Regex.hs:142:22: error:
Bang pattern in expression context: !0
Did you mean to add a space after the '!'?
|
142 |   let matches = map (!0) (matchAll delim strIn)
|  ^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013784: haskell-polyparse FTBFS: Encountered missing or private dependencies: base >=4.3.1.0 && <4.14

[Adrian Bunk]

Source: haskell-polyparse
Version: 1.13-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-polyparse=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.3.1.0 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013783: haskell-postgresql-libpq FTBFS: Encountered missing or private dependencies: base >=4.3 && <4.15

[Adrian Bunk]

Source: haskell-postgresql-libpq
Version: 0.9.4.2-3
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-postgresql-libpq=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.3 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1006277:

[Roman Lebedev]

Thank you! Now that easyeffects is packaged,
i have just successfully performed migration to pipewire.

Roman.

Bug#1013782: haskell-sop-core FTBFS: Encountered missing or private dependencies: base >=4.9 && <4.15

[Adrian Bunk]

Source: haskell-sop-core
Version: 0.5.0.1-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-sop-core=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.9 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013748: [Debian-on-mobile-maintainers] Bug#1013748: src:phosh: fails to migrate to testing for too long: uploader built arch:all binaries

[Guido Günther]

Hi Paul,
On Sat, Jun 25, 2022 at 01:19:51PM +0200, Paul Gevers wrote:
> Your package is only blocked because the arch:all binary package(s) aren't
> built on a buildd. Unfortunately the Debian infrastructure doesn't allow
> arch:all packages to be properly binNMU'ed. Hence, I will shortly do a
> no-changes source-only upload to DELAYED/15, closing this bug. Please let me
> know if I should delay or cancel that upload.

Thanks for handling this, I totally didn't notice that migration was
pending for so long due to me picking the wrong change file on upload it
seems.

Cheers,
 -- Guido

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




> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1013781: haskell-hashable-time FTBFS: Encountered missing or private dependencies: base >=4.7 && <4.15

[Adrian Bunk]

Source: haskell-hashable-time
Version: 0.2.0.2-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-hashable-time=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.7 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013779: haskell-token-bucket FTBFS: Encountered missing or private dependencies: base >=4.6 && <4.14

[Adrian Bunk]

Source: haskell-token-bucket
Version: 0.1.0.1-11
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-token-bucket=sid

...
Configuring token-bucket-0.1.0.1...

hlibrary.setup: Encountered missing or private dependencies:
base >=4.6 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013780: librust-snafu-dev: impossible to install

[Jonas Smedegaard]

Package: librust-snafu-dev
Version: 0.6.10-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package has impossible to satisfy dependencies on
librust-futures-0.1-dev and librust-pin-project-0.4-dev.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK3LLYACgkQLHwxRsGg
ASFCWA//VwPsXt1RZqcaObdTqkj+YsvDupZiAJFJqcO05cpijQN75B4r2n9fRkdo
TW4vL9DXw6F6uYUaqBuheE2696nl/xXuqGBHjFBfCngDcyM1sfRyfvwdsabokOlD
HP0XX+EdI8V+CetPZPqGTpmTD6uJvNHs0MQg0Rno8Di2bF6P/R3iVAXuBsRQw+wz
oZxa6ntMI+dBe8PioN4/vycqF9dJXImQtuZ5TsRERgUIH9Kfkw6o40SSfRQUgo7P
Wuw4DsByBeRurrr77G72GZFASG0rIX6YwcT78K8/2Orz+kT0XiZIKgYN23qYW+XF
JJKTegH+FILAnOktEgt8zUL9sZORJlaixIRxs3zWzd8rWrPqHOjJ+NyM+zxXDfdE
Hb7r3S9OZWzADuvbl5bg/g93k+dgFe6NqBPdEjw7xGopYCobpMj61BDtb9HFDt/q
8JzUAURHGPRSaTUfGY4J01kTQ3Mz9B/+5mWYROwnOAxCqGJp0aCF9rQ1BB8Upyv5
yglpKjnOnnRm98eC73M5KFrsvNydI1TXLxG+J5fcuOQBxuW64uK0xbdxbT+XOGkA
iuhqZX51jWIh4d6aLCDpRxwY9J6x3mpM2XIsn/LPY4x7qZPNIfsOLtP3vOaUZrW3
Lw3sKVFEDLMjaJCSmmn+ghz1k8e160vljeK2wrLL+dz+BMrK2pw=
=2Dxz
-END PGP SIGNATURE-

Bug#1006989: nim: incompatible with OpenSSL 3.0

[Nilesh Patra]

Hi Federico,

On Wed, 9 Mar 2022 18:04:36 -0800 Steve Langasek  
wrote:
> Source: nim
> $ ./bin/nimble 
> could not import: SSL_get_peer_certificate
> $
> 
> libssl3 is currently in experimental and expected to be the version of
> OpenSSL shipped with the next version of Debian.  Please work with upstream
> to ensure this package can be updated for compatibility with OpenSSL 3.

Unfortunately now nim has been removed from testing :(

https://tracker.debian.org/news/1334488/nim-removed-from-testing/

Would you know if the support is there yet or is under-way?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1013778: haskell-newtype FTBFS: Encountered missing or private dependencies: base >=4.5 && <4.14

[Adrian Bunk]

Source: haskell-newtype
Version: 0.2.2.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-newtype=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.5 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013777: O: tuxguitar -- Multitrack guitar tablature editor and player (gp3 to gp5)

[tony mancill]

Package: wnpp
Severity: normal
Control: affects -1 src:tuxguitar

I intend to orphan the tuxguitar package.

The package description is:
 TuxGuitar is a multitrack Guitar tablature editor and player.
 It can open GP3, GP4, and GP5 files and exports in MIDI and PDF.


signature.asc
Description: PGP signature

Bug#1013776: rust-thread-scoped: unmaintained obstream

[Jonas Smedegaard]

Source: rust-thread-scoped
Version: 1.0.2-2
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This crate last saw an upstream release 5 years ago, and is flagged as
"deprecated" at .

Perhaps it should be dropped from Debian?

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK3J0cACgkQLHwxRsGg
ASH7LA/+PtE9eeCnWpuWEyU36HEb1lmwjet7XOrlFXOTvJfsxTlLQaVUF2x4m+un
cnvsusn0nyB8y6y/5YwYyGpEsdxAIThYWhzCPr2xdI1vnTKP+gKZwc9KeS+sgeF3
R7yk0dq5Sm1s50vq+IKIb50fr3xl9Z/3VVsqzIdVuVeR393yygW+JlW8uTzE2CZo
gig5yGuHIMb5BLNB/7ADxiirhkNmeiQgjCQr1+peaw9fcj4y/EZdpO5XeoZT5Qjb
exUkqHBGRRzqMQ2l2nU5YIqDvijNlop8loNDrN7B4gyBzoMSrcYy4V7Ui6QFa/87
kqQmKW/pUSwxAi1fenng54ftDpD5asUyigrCo93dE5JG96uaoA8OYissBGK7oMaz
bjCVMuzYxxxmgmwwh7v+NhJvrZrJ1lXjBwW7lPIh9qNFXwuahXxELzqcJDGSGsqG
Ct8VYb4twqC6gyBPPMqKW7kYVHbTWagrCMBHXkndV+QIUd1gh51MiCSw8uu0WVuY
unLKNGM7BcPLEPLWmRkUl30mRdmuwrIZrMWiWdBwPjJvDoGcEONziviRs/MLVWUx
s4AunLHyUGkqS5WKKpyyENVI2X1wqaVu6JQs/s8gNUyEN9KtKkAEw96Ha4P1Lggn
gHCysK/+0ilDbct+1wMZVDJHqFiKu0dKVE0E6sUT5ocRSlrq9IE=
=+wWZ
-END PGP SIGNATURE-

Bug#1013775: haskell-language-haskell-extract FTBFS: error: Couldn't match expected type ‘Maybe Exp’ with actual type ‘Exp’

[Adrian Bunk]

Source: haskell-language-haskell-extract
Version: 0.2.4-10
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-language-haskell-extract=sid

...
src/Language/Haskell/Extract.hs:28:30: error:
• Couldn't match expected type ‘Maybe Exp’ with actual type ‘Exp’
• In the expression: LitE $ StringL n
  In the first argument of ‘TupE’, namely
‘[LitE $ StringL n, VarE $ mkName n]’
  In the expression: TupE [LitE $ StringL n, VarE $ mkName n]
   |
28 |  let makePair n = TupE [ LitE $ StringL n , VarE $ mkName n]
   |  

src/Language/Haskell/Extract.hs:28:49: error:
• Couldn't match expected type ‘Maybe Exp’ with actual type ‘Exp’
• In the expression: VarE $ mkName n
  In the first argument of ‘TupE’, namely
‘[LitE $ StringL n, VarE $ mkName n]’
  In the expression: TupE [LitE $ StringL n, VarE $ mkName n]
   |
28 |  let makePair n = TupE [ LitE $ StringL n , VarE $ mkName n]
   | ^^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump

[Petter Reinholdtsen]

[László Böszörményi]
> As noted by libtiff upstream as well, this function was internal of
> tiff and its declaration was in a header file that was not installed
> publicly. They could change that without prior notice.

While it might sound sensible on the surface, the realities is that the
libraries binary interface (aka ABI) changed, removing a public symbol
from the library.  Such API change require a no major SONAME number to
avoid breaking programs using the library.

> If linuxcnc-uspace still wants to use it, then copy that function[1]
> and its details to their source tree. They already done copying with
> the _TIFFsetString() function declaration.  Then I can add a break for
> its older versions for tiff.

It is not linuxcnc-uspace that is using it.  It is the tcl/tk Img
library.  To test for yourself, try running 'wish' and give it the 
'package require Img' command to load the Img library.  linuxcnc do the
equivalent loading, but using the python Tk library.

Removing the symbol without bumping the SONAME made it impossible for
programs using the symbol to keep the old working library version.  This
was the ratinale for my severity setting critical.  Given that the
symbol removal without bumping SONAME broken libtk-img and linuxcnc,
what is your argument for lowering the severity to normal?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1013774: haskell-th-extras FTBFS: error: Expecting one more argument to ‘TyVarBndr’

[Adrian Bunk]

Source: haskell-th-extras
Version: 0.0.0.4-6
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-th-extras=sid

...
src/Language/Haskell/TH/Extras.hs:42:17: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature: nameOfBinder :: TyVarBndr -> Name
   |
42 | nameOfBinder :: TyVarBndr -> Name
   | ^

src/Language/Haskell/TH/Extras.hs:51:27: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature: varsBoundInCon :: Con -> [TyVarBndr]
   |
51 | varsBoundInCon :: Con -> [TyVarBndr]
   |   ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013773: haskell-geniplate-mirror FTBFS: Encountered missing or private dependencies: template-haskell <2.17

[Adrian Bunk]

Source: haskell-geniplate-mirror
Version: 0.7.7-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-geniplate-mirror=sid

...
hlibrary.setup: Encountered missing or private dependencies:
template-haskell <2.17

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013772: haskell-regex-pcre FTBFS: Encountered missing or private dependencies: base >=4.3 && <4.14

[Adrian Bunk]

Source: haskell-regex-pcre
Version: 0.95.0.0-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-regex-pcre=0.95.0.0-2%2Bb2

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.3 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013771: haskell-statestack FTBFS: Encountered missing or private dependencies: base >=4.8 && <4.14

[Adrian Bunk]

Source: haskell-statestack
Version: 0.3-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-statestack=0.3-1%2Bb2

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.8 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013769: haskell-th-data-compat FTBFS: error: Expecting one more argument to ‘TyVarBndr’

[Adrian Bunk]

Source: haskell-th-data-compat
Version: 0.1.0.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-th-data-compat=0.1.0.0-1%2Bb2

...
src/Language/Haskell/TH/Compat/Data/Current.hs:25:28: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature:
dataD' :: CxtQ -> Name -> [TyVarBndr] -> [ConQ] -> [Name] -> DecQ
   |
25 | dataD' :: CxtQ -> Name -> [TyVarBndr] -> [ConQ] -> [Name]
   |^

src/Language/Haskell/TH/Compat/Data/Current.hs:30:38: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the first argument of ‘Maybe’, namely
‘(Cxt, Name, [TyVarBndr], Maybe Kind, [Con], [Type])’
  In the type signature:
unDataD :: Dec
   -> Maybe (Cxt, Name, [TyVarBndr], Maybe Kind, [Con], [Type])
   |
30 | unDataD :: Dec -> Maybe (Cxt, Name, [TyVarBndr], Maybe Kind, [Con], [Type])
   |  ^

src/Language/Haskell/TH/Compat/Data/Current.hs:36:31: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature:
newtypeD' :: CxtQ -> Name -> [TyVarBndr] -> ConQ -> [Name] -> DecQ
   |
36 | newtypeD' :: CxtQ -> Name -> [TyVarBndr] -> ConQ -> [Name]
   |   ^

src/Language/Haskell/TH/Compat/Data/Current.hs:41:41: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the first argument of ‘Maybe’, namely
‘(Cxt, Name, [TyVarBndr], Maybe Kind, Con, [Type])’
  In the type signature:
unNewtypeD :: Dec
  -> Maybe (Cxt, Name, [TyVarBndr], Maybe Kind, Con, [Type])
   |
41 | unNewtypeD :: Dec -> Maybe (Cxt, Name, [TyVarBndr], Maybe Kind, Con, 
[Type])
   | ^

src/Language/Haskell/TH/Compat/Data/Current.hs:52:42: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the first argument of ‘Maybe’, namely ‘[TyVarBndr]’
  In the first argument of ‘Maybe’, namely
‘(Cxt, Maybe [TyVarBndr], Type, Maybe Kind, [Con], [Type])’
  In the type signature:
unDataInstD :: Dec
   -> Maybe (Cxt, Maybe [TyVarBndr], Type, Maybe Kind, 
[Con], [Type])
   |
52 | unDataInstD :: Dec -> Maybe (Cxt, Maybe [TyVarBndr], Type, Maybe Kind, 
[Con], [Type])
   |  ^

src/Language/Haskell/TH/Compat/Data/Current.hs:63:45: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the first argument of ‘Maybe’, namely ‘[TyVarBndr]’
  In the first argument of ‘Maybe’, namely
‘(Cxt, Maybe [TyVarBndr], Type, Maybe Kind, Con, [Type])’
  In the type signature:
unNewtypeInstD :: Dec
  -> Maybe (Cxt, Maybe [TyVarBndr], Type, Maybe Kind, 
Con, [Type])
   |
63 | unNewtypeInstD :: Dec -> Maybe (Cxt, Maybe [TyVarBndr], Type, Maybe Kind, 
Con, [Type])
   | ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013770: RFS: moc/1:2.6.0~svn-r3005-2 [RC] -- ncurses based console audio player

[Elimar Riesebieter]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: moc
   Version : 1:2.6.0~svn-r3005-2
   Upstream Author : Damian Pietras  
 * URL : https://moc.daper.net
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/riesebie/moc
   Section : sound

The source builds the following binary packages:

  moc - ncurses based console audio player
  moc-ffmpeg-plugin - ncurses based console audio player - ffmpeg plugin

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/moc/moc_2.6.0~svn-r3005-2.dsc

Changes since the last upload:

 moc (1:2.6.0~svn-r3005-2) unstable; urgency=medium
 .
   * Introduced patches 0005 to 0007 to fix ffmpeg5 FTBFS. (Closes: 1004595)
   * Declare compliance with Debian Policy 4.6.1 (No changes needed.).
   * Rename configure.in to configure.ac.
   * Extend copyrights.

Regards,
-- 
Elimar


signature.asc
Description: PGP signature

Bug#1013767: haskell-th-expand-syns FTBFS: Encountered missing or private dependencies: template-haskell <2.17

[Adrian Bunk]

Source: haskell-th-expand-syns
Version: 0.4.6.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-th-expand-syns=0.4.6.0-1%2Bb2

...
hlibrary.setup: Encountered missing or private dependencies:
template-haskell <2.17

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013766: haskell-memory FTBFS: error: Variable not in scope

[Adrian Bunk]

Source: haskell-memory
Version: 0.15.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-memory=0.15.0-1%2Bb2

...
Data/ByteArray/Types.hs:39:1: warning: [-Wunused-imports]
The qualified import of ‘Basement.PrimType’ is redundant
  except perhaps to import instances from ‘Basement.PrimType’
To import instances alone, use: import Basement.PrimType()
   |
39 | import qualified Basement.PrimType as Base (primSizeInBytes)
   | 

Data/ByteArray/ScrubbedBytes.hs:93:71: error:
Variable not in scope:
  unsafeCoerce# :: MutableByteArray# RealWorld -> ByteArray#
   |
93 | let !scrubber = (getScrubber sz) (byteArrayContents# 
(unsafeCoerce# mbarr))
   |   
^

Data/ByteArray/ScrubbedBytes.hs:151:38: error:
Variable not in scope:
  unsafeCoerce# :: MutableByteArray# RealWorld -> ByteArray#
|
151 | a <- f (Ptr (byteArrayContents# (unsafeCoerce# mba)))
|  ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 707
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Zhang Boyang]

Hi,

Some good news, I tested:

1) Build my unofficial DVD set (17 DVDs), and merge them using the merge 
script on my Debian machine.


2) Build my unofficial DLBD set (2 DLBDs), and merge them using the 
merge script on my Debian machine.


3) Merge 2 DLBDs using the merge script under a Alpine Linux environment 
(everything is almost busybox).


4) Run d-i cdrom-check on merged.iso from 1), 2), and 3).

5) Do fresh install into virtual machine, then install random packages 
selected from {SOME-ISO-NAME}.list.gz .


These experiments all succeeded. Thank you very much! Good Job! :)

On 2022/6/24 00:53, Thomas Schmitt wrote:

Run time for an All-in-one ISO is estimated about 6 to 7 times the time
of DVD-1+2+3.
So i expect ~230 seconds for full MD5 regeneration, ~ 50 seconds for
a loop that runs on dash, and ~6 seconds with a bashism.

For now i decided to take the 50 seconds with dash.


I think runtime is not a issue, 50 seconds is totally acceptable. But if 
you really want to reduce runtime I would suggest using `sort -s -u -k 2 
merged_md5sum.txt' instead of processing each line by hand. By using 
stable sort (`-s') and unique (`-u'), only first record of duplicate set 
will be output. So as long as md5sum.txt in Disc1 comes first, it will 
definitely in final result. I saw there are some other logic to process 
md5 records from different group of files, so we can use `grep' and 
`grep -v' to split them, process them separately, then merge them 
finally. Unfortunately the option `-s' of `sort' is not standard 
(although widely accepted), and BusyBox has bugs about it and must use 
`sort -s -k 2 | uniq -f 1' to workaround (Link: 
https://bugs.busybox.net/show_bug.cgi?id=14871).



Thank you again :)

Best Regards,
Zhang Boyang

Bug#1013765: haskell-show-combinators FTBFS: Encountered missing or private dependencies: base >=4.8 && <4.14

[Adrian Bunk]

Source: haskell-show-combinators
Version: 0.2.0.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-show-combinators=0.2.0.0-1%2Bb1

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.8 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013764: O: spout -- Tiny abstract black and white 2D cave-shooter

[Scott Leggett]

Package: wnpp
Severity: normal
Control: affects -1 src:spout

I intend to orphan the spout package.

The package description is:
This is a small, abstract shooting game from Japanese developer Kuni. It is a
'caveflier' in which the exhaust from the engine also serves as a tool to
erode the cave walls.
.
Your goal is to fly upwards as long as you possibly can, without crashing
against the cave walls and the window borders.

I no longer have the time/motivation for working on Debian packaging and
I no longer use this package.

Bug#1013763: O: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Scott Leggett]

Package: wnpp
Control: affects -1 src:dhcpcd5
Severity: normal

I intend to orphan the dhcpcd5 package.

The package description is:
dhcpcd is a one stop network management daemon which includes
  * RFC compliant DHCPv4 and DHCPv6 clients
  * DHCPv6 Prefix Delegation support
  * IPv4LL (aka ZeroConf) support
  * ARP address conflict resolution
  * Link carrier detection
  * Wireless SSID profiles
  * ARP ping profiles

I no longer have the time/motivation for working on Debian packaging and
I no longer use this package.

Bug#1013762: O: pasystray -- PulseAudio controller for the system tray

[Scott Leggett]

Package: wnpp
Severity: normal
Control: affects -1 src:pasystray

I intend to orphan the pasystray package.

The package description is:
Pasystray enables control of various PulseAudio server settings from the X11
system tray. It can:
* adjust the volume of streams and sinks/sources
* transfer streams between sinks/sources
* switch the default sink/source
* set the default server (PULSE_SERVER)
* detect network PulseAudio services
* rename devices
.
The commands associated with the suggested dependencies (paman, paprefs,
pavucontrol, and pavumeter) may be launched from the menu provided by
pasystray. If a command is not available, that particular menu item is
disabled. pulseaudio-module-zeroconf enables detection and management of
network PulseAudio services.

I no longer have the time/motivation for working on Debian packaging and
I no longer use this package.

Bug#1013761: haskell-haskell-src FTBFS: Encountered missing or private dependencies: base >=4.13.0.0 && <4.14

[Adrian Bunk]

Source: haskell-haskell-src
Version: 1.0.3.1-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=haskell-haskell-src=1.0.3.1-1%2Bb2

...
Configuring haskell-src-1.0.3.1...

hlibrary.setup: Encountered missing or private dependencies:
base >=4.13.0.0 && <4.14

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 620
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1013672:

[Akbarkhon Variskhanov]

I opened an issue upstream:
https://gitlab.gnome.org/GNOME/gnome-session/-/issues/108

And created a merge request with a proposed fix.
It builds and functions properly, with 'g-s-c-s' not installed as expected.

Hopefully, it gets merged.

Thanks.

Bug#1013760: nmu: kmscon_9.0.0-1

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: by...@debian.org
Severity: normal

Since package kmscon https://tracker.debian.org/pkg/kmscon just passed the NEW
queue, please rebuild it on amd64 to remove the uploaded binary package.
Thanks!

nmu kmscon_9.0.0-1 . amd64 . unstable . -m "Rebuild on buildd"

Best,
Boyuan Yang


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

Bug#1013759: ITP: golang-github-mattn-go-ciede2000 -- Go implementation of the CIE Delta E 2000 Color-Difference algorithm

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-mattn-go-ciede2000
  Version : 0~
  Upstream Author : Yasuhiro Matsumoto
* URL : https://github.com/mattn/go-ciede2000
* License : Expat
  Programming Lang: Golang
  Description : Go implementation of the CIE Delta E 2000 Color-Difference 
algorithm

 This package provides the Go implementation of the CIE Delta E 2000
 Color-Difference algorithm.
 .
 This is a golang port of https://github.com/gfiumara/CIEDE2000.

This package will be maintained under Debian Go Packaging Team.
This is dependencies of dyff (https://bugs.debian.org/1013751).


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1013758: rust-hyper-tls: please upgrade to v0.5

[Jonas Smedegaard]

Source: rust-hyper-tls
Version: 0.3.2-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream branch v0.5, needed by projects I am
preparing for Debian.

 - Jonas


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK3C6QACgkQLHwxRsGg
ASFOJg/9Eb1Utdxbsj8IPdwx4e5S/eDpEduaKT9Am/oWexfSlpBTmZCwNmKlmAho
WCxGSPt37uFSEzTgO0RU43Ro4Lzte57IhFriQ7LH0mglbmbpMqenDDMZ+m+4JvNG
v/aScc5a0/8jznpo9/Xr3MUOXePcj/OPCREK6212ko+s+4LoYgL2emniPTUB4Ohw
TLqd6df+iZVDdhGcp4oTHYGBp1Duic7uHSHiMSexaPlbaghlEy9cIPIwMD9x5aGW
fIeROLYxL+I9BuRHITvmqcjdrHDgU0TjqfzvVAH4ktpp/XeNB6rPk0ecQ1UdHAKs
xRgHqrca6s34DnQ+dRvNbfPkBBdlexpoNm7VOY+6PPJzXZlhQTqiHts985QtLCKj
5PSyB0FHKPqtqKUfk/LpXPqR/Lq21X+QbHs3+UO36hYSZTxQABNyc5afkJbBVWBf
7J+xEVybn6QPsTh4RbqtmYa1zYPwTTqkgiPjQ/rNb1uwS8hkv0hB2Y0sFqXWv1df
TcHYKItdy7cPdG27TbKGXeAr1TV5J5+H5bPs+QSXl/y1riLrMIIEXALuCkyQwMYD
McGc6pSM+VZj0KbwFVKMj1uovpZxUZ2sAEyZQObOt9+ppcvNm3IA1oJTDtnIcBCd
51Z8zcrtmhGqrL4ZX5OcD1keaN4TrN9UKETrACZiVvlIQmWOFSI=
=5ao7
-END PGP SIGNATURE-

Bug#1013757: rust-hyper-tls: impossible to install

[Jonas Smedegaard]

Source: rust-hyper-tls
Version: 0.3.2-2
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Depends on non-existing branches of crates bytes, futures, and hyper.

 - Jonas


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK3C1MACgkQLHwxRsGg
ASFOHxAAh4gExB/zozjN3jz36v/hElzNA966uncKfOC6op0RA3uKY/fJYV8/0C32
hLrdWbBOs4uV4vC7OldA7/RMNR/4+Cu0CR/a0vLw+6fPGCmV7+dBxtAhw9VcyMHq
35xUJZWNm90OPCsIcvj8HaXJMG2XY3N/KocfxAg4jb1aKNVenNQ3wz6bOMM0g2q4
iNKv5XgyVF890SQnOiitnQOlyk5YQEhmcKn4Grp/rEf0tkdQesEhamwWVqpgn+1a
6tGWlJMhRrFKsblYnMbh0U8XeYSW698MhrikO0QF5yT6hdkAWKAEY2NUDsPdRzWT
YA0zghTJxcADtMvpfhu98CIaHOYB+qXCQHLJhcf3s1muRTDCxpzPKItbEnQpT1eE
KNo4FMiVNh6fBNSdUB4lY+ccKCh98tMfH5qFpvVQEQQ9MnWpbQWRQLRMalCWp48L
uga0Ip7TVkmWwE2tJu/4dHzdWLeQcySAP9U0dwkSfTM8kArRyZjguBRyDlmWYqcO
x5pwX9jPc4to816i4ddx/r1h+VyIAaWchgbGMMjztK6by7C6BWcU331H5TZM4YQ/
NQO4uneZ++kd6N04bh553NKhgLqHpB0twpfNlsMIrdKjboYQ3fuCRTVLhtbVppbd
T0uyOkNbCf8fj6Kq2eTOzzhWVtJKLz0y9dwar/GY6BQKEjDBLOQ=
=+POJ
-END PGP SIGNATURE-

Bug#1013756: solfege: crash with pyalsa

[Michael Below]

Package: solfege
Version: 3.23.4-11
Severity: normal
X-Debbugs-Cc: be...@judiz.de

Dear Maintainer,

when I tried solfege for the first time it used OSS MIDI through the
sound card. There was a message in the config window that ALSA couldn't
be used because pyalsa was missing. I installed python3-pyalsa from
testing, and the next time I opened the config dialog in solfege it
crashed. I expected it to offer ALSA MIDI instead.

Cheers
Michael


Traceback (most recent call last):
  File "/usr/share/solfege/solfege/mainwin.py", line 672, in 
open_preferences_window
self.g_config_window = ConfigWindow()
  File "/usr/share/solfege/solfege/configwindow.py", line 111, in __init__
self.create_sound_config()
  File "/usr/share/solfege/solfege/configwindow.py", line 467, in 
create_sound_config
self.create_linux_sound_page()
  File "/usr/share/solfege/solfege/configwindow.py", line 622, in 
create_linux_sound_page
connections = solfege.soundcard.alsa_sequencer.get_connection_list()
  File "/usr/share/solfege/solfege/soundcard/alsa_sequencer.py", line 123, in 
get_connection_list
sequencer = alsaseq.Sequencer(name='default',
OverflowError: signed integer is greater than maximum


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

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

Versions of packages solfege depends on:
ii  freepats  20060219-4
ii  gir1.2-gtk-3.03.24.34-1
ii  python3   3.10.4-1+b1
ii  python3-apt   2.3.0+b1
ii  python3-gi3.42.1-1
ii  python3-gi-cairo  3.42.1-1
ii  sensible-utils0.0.17
ii  timidity  2.14.0-8+b1

Versions of packages solfege recommends:
ii  csound   1:6.17.0~dfsg-3+b1
ii  solfege-doc  3.23.4-11

solfege suggests no packages.

-- no debconf information

Bug#1013755: bullseye-pu: package ganeti/3.0.2-1~deb11u1

[Apollon Oikonomopoulos]

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

Dear SRMs,

I would like to update Ganeti to the current upstream bugfix version
(3.0.2) - including all Debian packaging fixes currently in unstable - 
and I seek your approval.

3.0.2 was released a while back[1] as a bugfix-only release. Due to my 
involvement upstream, I had full oversight of the release process and I 
can confirm it solves important issues, the vast majority of which affect
Bullseye, while it does not introduce any breaking changes in behavior.  
Note that every commit since v3.0 has been tested against Debian Stable 
and Testing upstream using an automated CI/CD pipeline. I believe 
bumping to 3.0.2 is much safer and cleaner than cherry-picking at
least a dozen of commits as patches on top of 3.0.1.

Apart from upstream fixes, this p-u also includes fixes for Debian bugs #993559
and #140 affecting Debian packaging, as well as the removal of an 
unnecessary
dependency on bridge-utils. Note that I might revert the latter for the stable
update to avoid breaking any custom scripts (e.g. hooks) that still rely on
brctl mid-release.

I'm attaching a full source debdiff against 3.0.1-2. The following 
information is for ease of review, please let me know if there is any 
additional information I can provide.

[1] https://github.com/ganeti/ganeti/releases/tag/v3.0.2

Cheers,
Apollon

Annotated upstream commit list since 3.0.1
--
$ git log --oneline --no-merges v3.0.1..v3.0.2
6f97ee783 Prepare for the 3.0.2 release
  Version bump & documentation changes

4e35c0093 Fix lvcreate for newer lvm versions (#1586)
  Already fixed in Bullseye (#982960), patch dropped in this p-u.

7b89f42fd KVM: handle asynchronous events during QMP connect
Reliability fix, issue present in Bullseye. Documented as affecting 
Bullseye
  in https://github.com/ganeti/ganeti/issues/1649

2d04d0190 Fix NIC hotplug with `vhost_net=True`
Reliability fix, issue present in Bullseye, see
  https://github.com/ganeti/ganeti/issues/1651

f1e6d7ee1 relax VLAN check with VETHs
  Slight behavior change, backwards compatible

9e7210a0b doc: Remove duplicate index entry.
  FTBFS, fixed post-bullseye in our 3.0.1-3 (#997053)

c5bb09744 work around dynamic auto-ro for live migration
  Compatibility fix for QEMU >=4.0, affects bullseye

06a043ad8 KVM: use same code to generate aio/cache parameters for KVM start and 
hotplugging
59994617c KVM hypervisor: only accept valid combinations of disk_aio and 
disk_cache
cb1810cf9 Refactor: Move KVM parameter check/validation code to separate methods
Slight code refactoring to properly sanitize disk parameters using the 
same
  rules when the instance starts up and when disks are hotplugged. Fixes disk
  hotplugging under certain scenarios, see 
https://github.com/ganeti/ganeti/issues/1645.
  Note that these commits are responsible for the majority of the diffstat in 
this p-u.

c851eb73b make check-local happy: fix end-of-line whitespace
  Linting, irrelevant for Debian

543c9e243 allow Ganeti project copyright and year 202x
  Documentation change

432bab2fa add `check-local` to the github CI
  CI, irrelevant for Debian

d512200d7 Qemu-Guest-Agent (QGA): use implicit PCI slot
Fixes disk/NIC hotplugging when using the QEMU guest agent, see
  https://github.com/ganeti/ganeti/issues/1620. Affects Bullseye.

3951ba628 Do not load ROM file for NICs during hotplug when QEMU is running in 
chroot mode
  Fixes hotplugging issue, affects Bulsseye

185481da9 Warn users that changing DRBD parameters does not affect running 
instances
  CLI output change

c4a603b6e Fix live migration of xen instances (#1582)
  Included as patch in Bullseye, dropped in this p-u

d4e89d2f4 RAPI: Correctly return HTTP 400 on request parse error
  Leftover bug from the Python 3 conversion, affects Bullseye

2df1f2cd3 fix building docs on Debian Bullseye (#1602)
FTBS, affects Bullseye, fixed in Debian in 3.0.1-3, patch dropped in 
this
  p-u.

d845e7d68 Adjust for Pyparsing 3.0.
  Bugfix, affects Bookworm but does not break Bullseye.

a5ad39397 Fix Byte vs String comparison
Leftover bug from the Python 3 conversion, affects some CLI commands in
  Bullseye.

95125c644 Loosen Cabal version constraints.
  Releng
  
8f8e82933 Adjust for TupE type change in Template Haskell 2.16.
  GHC 8.10 compatibility using conditional code, noop under Bullseye.

f0189ae15 fix dictionary usage bug leftover from 2to3 migration
  Leftover bug from the Python 3 conversion

c562509fe Fix unsupported keymap include in >=qemu-4.0 (#1612)
  QEMU 4.0 compatibility fix, affects Bullseye
diff -Nru ganeti-3.0.1/autotools/check-header 
ganeti-3.0.2/autotools/check-header
--- ganeti-3.0.1/autotools/check-header 2021-02-03 10:24:16.0 +0200
+++ ganeti-3.0.2/autotools/check-header 2022-02-28 22:51:21.0 +0200
@@ -76,10 +76,11 @@
 
 
 

Bug#1013754: python-h5netcdf: FTBFS with NetCDF 4.9.0 (test failures)

[Bas Couwenberg]

Source: python-h5netcdf
Version: 1.0.0-3
Severity: serious
Tags: upstream patch ftbfs

Dear Maintainer,

Your package FTBFS with NetCDF 4.9.0 which added more compression options, this 
also causes the autopkgtest to fail:

=== FAILURES ===
__ test_write_legacyapi_read_netCDF4 ___

tmp_local_netcdf = 
'/tmp/pytest-of-debci/pytest-0/test_write_legacyapi_read_netC0/testfile.nc'

def test_write_legacyapi_read_netCDF4(tmp_local_netcdf):
>   roundtrip_legacy_netcdf(tmp_local_netcdf, netCDF4, legacyapi)

tests/test_h5netcdf.py:450: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/test_h5netcdf.py:446: in roundtrip_legacy_netcdf
read_legacy_netcdf(tmp_netcdf, read_module, write_module)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

tmp_netcdf = 
'/tmp/pytest-of-debci/pytest-0/test_write_legacyapi_read_netC0/testfile.nc'
read_module = 
write_module = 

def read_legacy_netcdf(tmp_netcdf, read_module, write_module):
ds = read_module.Dataset(tmp_netcdf, "r")
assert ds.ncattrs() == ["global", "other_attr"]
assert ds.getncattr("global") == 42
if write_module is not netCDF4:
# skip for now: https://github.com/Unidata/netcdf4-python/issues/388
assert ds.other_attr == "yes"
with pytest.raises(AttributeError):
ds.does_not_exist
assert set(ds.dimensions) == set(
["x", "y", "z", "empty", "string3", "mismatched_dim", "unlimited"]
)
assert set(ds.variables) == set(
[
"foo",
"y",
"z",
"intscalar",
"scalar",
"var_len_str",
"mismatched_dim",
"foo_unlimited",
]
)

assert set(ds.groups) == set(["subgroup"])
assert ds.parent is None
v = ds.variables["foo"]
assert array_equal(v, np.ones((4, 5)))
assert v.dtype == float
assert v.dimensions == ("x", "y")
assert v.ndim == 2
assert v.ncattrs() == ["units"]
if write_module is not netCDF4:
assert v.getncattr("units") == "meters"
assert tuple(v.chunking()) == (4, 5)
>   assert v.filters() == {
"complevel": 4,
"fletcher32": False,
"shuffle": True,
"zlib": True,
}
E   AssertionError: assert {'blosc': Fal...': False, ...} == 
{'complevel':... 'zlib': True}
E Omitting 4 identical items, use -vv to show
E Left contains 4 more items:
E {'blosc': False, 'bzip2': False, 'szip': False, 'zstd': False}
E Use -v to get the full diff

tests/test_h5netcdf.py:259: AssertionError
___ test_write_h5netcdf_read_netCDF4 ___

tmp_local_netcdf = 
'/tmp/pytest-of-debci/pytest-0/test_write_h5netcdf_read_netCD0/testfile.nc'

def test_write_h5netcdf_read_netCDF4(tmp_local_netcdf):
write_h5netcdf(tmp_local_netcdf)
>   read_legacy_netcdf(tmp_local_netcdf, netCDF4, h5netcdf)

tests/test_h5netcdf.py:468: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

tmp_netcdf = 
'/tmp/pytest-of-debci/pytest-0/test_write_h5netcdf_read_netCD0/testfile.nc'
read_module = 
write_module = 

def read_legacy_netcdf(tmp_netcdf, read_module, write_module):
ds = read_module.Dataset(tmp_netcdf, "r")
assert ds.ncattrs() == ["global", "other_attr"]
assert ds.getncattr("global") == 42
if write_module is not netCDF4:
# skip for now: https://github.com/Unidata/netcdf4-python/issues/388
assert ds.other_attr == "yes"
with pytest.raises(AttributeError):
ds.does_not_exist
assert set(ds.dimensions) == set(
["x", "y", "z", "empty", "string3", "mismatched_dim", "unlimited"]
)
assert set(ds.variables) == set(
[
"foo",
"y",
"z",
"intscalar",
"scalar",
"var_len_str",
"mismatched_dim",
"foo_unlimited",
]
)

assert set(ds.groups) == set(["subgroup"])
assert ds.parent is None
v = ds.variables["foo"]
assert array_equal(v, np.ones((4, 5)))
assert v.dtype == float
assert v.dimensions == ("x", "y")
assert v.ndim == 2
assert v.ncattrs() == ["units"]
if write_module is not netCDF4:
assert v.getncattr("units") == "meters"
assert tuple(v.chunking()) == (4, 5)
>   assert v.filters() == {
"complevel": 4,
"fletcher32": False,
"shuffle": True,
"zlib": True,
}
E   AssertionError: assert {'blosc': Fal...': False, 

Bug#1013753: libb-tbb: Does not provide libmalloc2 on mips64el/mipsel, breaking reverse dependencies

[Tobias Frost]

Source: onetbb
Version: 2021.5.0-11
Severity: serious
Justification: breaks other packages.
Control: tags -1 patch
Control: affects -1 src:opencascade

Please apply the patch from the MR at
https://salsa.debian.org/science-team/tbb/-/merge_requests/2

The current state breaks quite a few reverse dependencies, for example
opencascade cannot migrate because of this.

Because of the breakage, I'm considering doing an NMU upload soonish.

-- 
tobi

Bug#1011816: Bug#1004471: Update node-terser to latest upstream (node-terser 5)

[Jonas Smedegaard]

[ dropping randomly one of the cross-posted bugreports ]

Quoting Yadd (2022-06-25 12:13:48)
> On 25/06/2022 12:03, Jonas Smedegaard wrote:
> > Quoting Yadd (2022-06-25 09:51:05)
> >> On 30/05/2022 13:07, Jonas Smedegaard wrote:
> > Your fixing the issues is great.  The minor issue I had with it
> > was your sharing fixes for multiple issues as a single patch, making it
> > hard to follow what exactly is going on, and consequently making it hard
> > to navigate in it - i.e. adopt only some changes but not others.
> > 
> > Concretely, I am not ready to move to terser v5 yet, and this RC bug
> > does *not* require bumping to terser v5.  Your sharing a fix for this
> > issue that goes "first upgrade to terser v5, then patch that different
> > codebase like this..." made it hard for me to change that *one line*
> > really related to this bug:
> > 
> > -+if ("ecma" in opts) {
> > ++if ("ecma" in opts && opts.ecma != undefined) {
> > 
> > Let me repeat to emphasize: I truly appreciate your work triaging bugs!
> > 
> > Just please consider making "atomic changes": One git commit (or patch
> > file) per semantic change - not multiple lesser-related changes lumped
> > together.
> 
> Thanks, usually  it seems like you prefer debdiff instead of MR, that's 
> why I did this. Would you rather I make some MRs this time?

No thanks: I dislike MRs because they put the burden on the receiver to
play along with a specific model of using git indirectly via a custom
web interface (or a custom REST interface).

But the alternative to MRs is not a debdiff, but a diff.

If it takes 7 changes to fix a bug, then share that as 7 distinct
pieces, either as a git branch somewhere containing 7 commits, or as 7
unified diff patches attached to an email.


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump

[GCS]

Control: tags 1012825 patch
Control: severity 1012825 normal
Control: unblock 1012789 by 1012825

On Fri, Jun 24, 2022 at 11:57 AM Petter Reinholdtsen  wrote:
> Until upstream decide to reinsert the symbol or bump the SONAME, I
> suggest to carry this patch.  It should get the broken packages in
> Debian working again.
 As noted by libtiff upstream as well, this function was internal of
tiff and its declaration was in a header file that was not installed
publicly. They could change that without prior notice.
If linuxcnc-uspace still wants to use it, then copy that function[1]
and its details to their source tree. They already done copying with
the _TIFFsetString() function declaration.
Then I can add a break for its older versions for tiff.

Regards,
Laszlo/GCS
[1] https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tif_dir.c#L43

Bug#1001907: Progress?

[Ben Westover]

Hello Juri,

Have you had any progress on your packaging of pmbootstrap?
If not, I'd be happy to help you finish the job.

Regards
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013670: transition: srt

[Sebastian Ramacher]

Control: forwarded -1 https://release.debian.org/transitions/html/auto-srt.html

On 2022-06-24 17:32:43, Florian Ernst wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> please grant a transition slot for the srt transition.
> 
> Upstream has changed the soname from 1.4 to 1.5, and the srt packaging
> has been adjusted to reflect this. The following source package have
> been build-depending on srt:
> 
> ffmpeg
> gst-plugins-bad1.0
> nageru
> vlc
> 
> I have successfully rebuilt all of them on amd64 against srt as present
> in experimental, where srt itself has successfully built on all release
> architectures..

Let's wait until ffmpeg migrated and then we should be good to go ahead
with this one.

Cheers

> 
> The information on
> https://release.debian.org/transitions/html/auto-srt.html looks correct
> to me.
> 
> Ben file:
> 
> title = "srt";
> is_affected = .depends ~ "libsrt1.4-gnutls" | .depends ~ "libsrt1.4-openssl" 
> | .depends ~ "libsrt1.5-gnutls" | .depends ~ "libsrt1.5-openssl";
> is_good = .depends ~ "libsrt1.5-gnutls" | .depends ~ "libsrt1.5-openssl";
> is_bad = .depends ~ "libsrt1.4-gnutls" | .depends ~ "libsrt1.4-openssl";
> 
> Cheers,
> Flo



-- 
Sebastian Ramacher

Bug#990189: alsa-ucm-conf: New upstream version 1.2.7.1

[Clément Hermann]

Package: alsa-ucm-conf
Version: 1.2.6.3-1
Followup-For: Bug #990189

Dear Maintainer,

upstream is now at 1.2.7.1, and there are many interesting changes for
multichannel cards.

Thanks!

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

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

Versions of packages alsa-ucm-conf depends on:
ii  libasound2  1.2.6.2-0.1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

Bug#1013752: Transition KDE PIM 22.04

[Patrick Franz]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org

Hi Release team,

we would like to request a transition for KDE PIM 22.04.

We have uploaded KDE PIM 22.04 to experimental, but since KDE PIM
does not provide ABI stability and some packages outside
KDE PIM depend on it, we need a transition.

The packages depending on KDE PIM are:

* digikam
* kgpg
* kio-gdrive
* kjots
* kmymoney
* kraft
* zanshin

kio-gdrive, kmymoney, kraft and zanshin simply need a rebuild against
KDE PIM 22.04.

A fixed version of kgpg is in experimental and just needs to be uploaded
to unstable once KDE PIM 22.04 is uploaded there. There are patches
available for both digikam and kjots. I can patch kjots myself and point
the digikam maintainers to the existing patch.

Here is the Ben file:

---
title = "KDEPIM 22.04";

is_affected = .depends ~ /libkf5.*-21.12/ | .depends ~ /libkf5.*-22.04/;
is_good = .depends ~ /libkf5.*-22.04/;
is_bad = .depends ~ /libkf5.*-21.12/;
---

Thank you.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1013751: ITP: dyff -- diff tool for YAML files

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dyff
  Version : 1.5.4
  Upstream Author : Matthias Diester, et al.
* URL : https://github.com/homeport/dyff
* License : Expat
  Programming Lang: Golang
  Description : diff tool for YAML files

dyff is a diff tool designed for YAML only to show the parts of a YAML
file that change.

Each difference is referenced by its location in the YAML document by
using either the Spruce or go-patch path syntax. The output report aims
to be as compact as possible to give a clear and simple overview of the
change.

Similar to the standard diff tool, it follows the principle of
describing the change by going from the from input file to the target to
input file.


This package will be maintained under Debian Go Packaging Team.


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1013750: alsa-lib: new upstream release 1.2.7.1

[Clément Hermann]

Source: alsa-lib
Version: 1.2.4-1.1
Severity: wishlist

Dear Maintainer,

the 1.2.7.1 upstream release is available.

It's especially interesting to me because of changes in the UCM
interface that allows to handle multichannel interfaces better (macros
for making splitting/joining channels easier in UCM, e.g for pro-audio
interfaces, and the new configs upstream need 1.2.7 alsa-lib).

(I'll file a separate bug for the same request on alsa-ucm-conf).

Thanks!

nodens

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

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

Bug#1013749: src:python-debianbts: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: python-debianbts
Version: 3.2.0
Severity: serious
Control: close -1 3.2.1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013748: src:phosh: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: phosh
Version: 0.17.0-1
Severity: serious
Control: close -1 0.17.0-2
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013747: src:ensmallen: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: ensmallen
Version: 2.18.2-1
Severity: serious
Control: close -1 2.19.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1010431

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:ensmallen has been trying to migrate for 
62 days [2]. Hence, I am filing this bug. Your package has an 
autopkgtest failure that I already reported: bug #1010431.


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=ensmallen



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010769: mailman3: diff for NMU version 3.3.3-1.1

[Florian Schlegel]

Control: tags 1010769 + patch
Control: tags 1010769 + pending

Dear maintainer,

I've prepared an NMU for mailman3 (versioned as 3.3.3-1.1).
I haven't uploaded anything, as I don't know how to do that. Please 
consider using my patch and push it towards Debian stable.


Regards
Florian Schlegel

diff -Nru mailman3-3.3.3/debian/changelog mailman3-3.3.3/debian/changelog
--- mailman3-3.3.3/debian/changelog 2021-02-04 22:32:08.0 +0100
+++ mailman3-3.3.3/debian/changelog 2022-06-25 02:56:29.0 +0200
@@ -1,3 +1,10 @@
+mailman3 (3.3.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+- backport fix for sqlite db being locked by runner (Closes: #1010769)
+
+ -- Florian Schlegel   Sat, 25 Jun 2022 02:56:29 +0200
+
 mailman3 (3.3.3-1) unstable; urgency=medium

   *  New upstream release 3.3.3.
diff -Nru 
mailman3-3.3.3/debian/patches/0004-fix_runner_blocking_sqlite.patch 
mailman3-3.3.3/debian/patches/0004-fix_runner_blocking_sqlite.patch
--- mailman3-3.3.3/debian/patches/0004-fix_runner_blocking_sqlite.patch 
1970-01-01 01:00:00.0 +0100
+++ mailman3-3.3.3/debian/patches/0004-fix_runner_blocking_sqlite.patch 
2022-06-25 02:56:29.0 +0200

@@ -0,0 +1,12 @@
+Index: mailman3-3.3.3/src/mailman/model/bounce.py
+===
+--- mailman3-3.3.3.orig/src/mailman/model/bounce.py
 mailman3-3.3.3/src/mailman/model/bounce.py
+@@ -206,6 +206,7 @@ class BounceProcessor:
+ mlist.bounce_score_threshold, action)
+ event.processed = True
+
++@transactional
+ @dbconnection
+ def send_warnings_and_remove(self, store):
+ """Send a warning email to the users who are disabled, if needed.
diff -Nru mailman3-3.3.3/debian/patches/series 
mailman3-3.3.3/debian/patches/series
--- mailman3-3.3.3/debian/patches/series2021-02-04 
22:32:08.0 +0100
+++ mailman3-3.3.3/debian/patches/series2022-06-25 
02:56:29.0 +0200

@@ -1,3 +1,4 @@
 0001_README_remove_embedded_images.patch
 0002-remove_sphinxcontrib.zopeext_dependency.patch
 0003-Remove-failing-test.patch
+0004-fix_runner_blocking_sqlite.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013746: [coreboot]

[Руслан Дядюль]

Package: coreboot Version: None Severity: Tags: X-Debbugs-CC: Dear
Maintainer, *** Please consider answering these questions, where
appropriate *** * What led up to the situation? * What exactly did you do
(or not do) that was effective (orineffective)? * What was the outcome of
this action? * What outcome did you expect instead? *** End of the template
- remove these lines ***

Bug#1013672:

[Akbarkhon Variskhanov]

I see that building "session_selector" is disabled by default.

It's probably best to report this upstream.

Bug#1013420: corsix-th FTBFS with ffmpeg 5.0.1

[Phil Morrell]

The next release is due imminently, which adds support for ffmpeg 5, so
this will be closed via that upload.


signature.asc
Description: PGP signature

Bug#1013731: linux-image-5.10.0-13-amd64: 5.10.0-13-amd64 RTL8153 power management kernel hang

[Diederik de Haas]

On zaterdag 25 juni 2022 05:33:01 CEST Ian Turner wrote:
> I wonder if it makes sense to cherry pick this patch into Bullseye, 

I'm not seeing any patch? Only a request to test a 5.13 kernel ... and then 
the discussion stopped (without answer wrt 5.13 kernel).

> assuming that Bullseye will not get 5.13 or later.

That is a correct assumption, Bullseye will stay on 5.10.
That doesn't automatically mean it can't be fixed in 5.10 as well.

First you'd need to identify the exact commit that fixed the issue, which 
usually follows identifying the exact commit that caused the issue.
Once you have that, you can ask *upstream* whether that commit can be 
backported to (upstream) stable kernel versions, like 5.10.
Once that happens, Debian's 5.10 should pick that up when a newer 5.10 kernel 
gets packaged for Bullseye.

HTH,
  Diederik

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

Bug#1004471: Update node-terser to latest upstream (node-terser 5)

[Yadd]

On 25/06/2022 12:03, Jonas Smedegaard wrote:

Quoting Yadd (2022-06-25 09:51:05)

On 30/05/2022 13:07, Jonas Smedegaard wrote:

Quoting Yadd (2022-05-30 12:05:41)

here is a debdiff (debian part only) to update terser to version 5.13.1.
This fixes also #1011816 (FTBFS)


Thanks!

It seems you are sharing that patch as a proposal, as you only pushed
some parts of it to git.

...and I disagree with some minor parts of it, so that's good: I will
take a look at it, and when I get a better sense of it reply back here
in more detail which parts I disagree with.


Hi Jonas,

did you have some time to look at this ?


Thanks for nudging - I had actually forgotten about this, but now dusted
off and finalized my work (terser v4.8 will be in unstable shortly).
Thanks again!

Your fixing the issues is great.  The minor issue I had with it
was your sharing fixes for multiple issues as a single patch, making it
hard to follow what exactly is going on, and consequently making it hard
to navigate in it - i.e. adopt only some changes but not others.

Concretely, I am not ready to move to terser v5 yet, and this RC bug
does *not* require bumping to terser v5.  Your sharing a fix for this
issue that goes "first upgrade to terser v5, then patch that different
codebase like this..." made it hard for me to change that *one line*
really related to this bug:

-+if ("ecma" in opts) {
++if ("ecma" in opts && opts.ecma != undefined) {

Let me repeat to emphasize: I truly appreciate your work triaging bugs!

Just please consider making "atomic changes": One git commit (or patch
file) per semantic change - not multiple lesser-related changes lumped
together.


Thanks, usually  it seems like you prefer debdiff instead of MR, that's 
why I did this. Would you rather I make some MRs this time?