Bug#996727: ITP: ciftools-java -- Java library to read and write CIF files

[Andrius Merkys]

Hi Pierre,

On 2021-10-17 22:18, Pierre Gruet wrote:
> * Package name: ciftools-java
>   Version : 3.0.0
>   Upstream Author : Sebastian Bittrich
> * URL : https://github.com/rcsb/ciftools-java
> * License : Expat
>   Programming Lang: Java
>   Description : Java library to read and write CIF files

Thanks for an interesting ITP. I am very interested in CIF parsers.
Could you please add me as an uploader for ciftools-java next to yourself?

Best,
Andrius

Bug#986828: pending

[Daniel Baumann]

retitle 993247 FTBFS in sid (libunistring)
tag 993247 pending
retitle 993249 wrong path on merged-/usr systems (ifconfig)
tag 993249 pending
tag 986828
pending
thanks

Hi,

gnunet 0.15.3-1 fixes this bug, uploaded to NEW, should pass in some time..

Regards,
Daniel

Bug#996747: src:debianutils: fails to migrate to testing for too long: blocked by sramacher

[Helmut Grohne]

Source: debianutils
Version: 5.0-1
Severity: serious
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

You removed essential functionality without implementing a proper
removal transition. Your package is therefore blocked by Sebastian
Ramacher.

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. That's not the case here. 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.

I have not closed this bug in unstable as that version is considered
unfit for release by Sebastian Ramacher (release manager), so if that
dispute is resolved and the block is lifted, this bug needs to be closed
manually. 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.

Helmut

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

Bug#996748: securefs FTCBFS: uses CHECK_CXX_SOURCE_RUNS

[Helmut Grohne]

Source: securefs
Version: 0.11.1+ds-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

securefs fails to cross build from source, because it uses
CHECK_CXX_SOURCE_RUNS in a few occasions. In none of them, the result of
execution is actually checked. The results of the relevant syscalls are
ignored. As such, merely compiling these examples is equivalent and
works with cross compilation. Please consider applying the attached
patch.

Helmut
--- securefs-0.11.1+ds.orig/CMakeLists.txt
+++ securefs-0.11.1+ds/CMakeLists.txt
@@ -84,10 +84,10 @@
 add_executable(securefs main.cpp)
 add_executable(securefs_test ${TEST_SOURCES})
 
-include(CheckCXXSourceRuns)
-CHECK_CXX_SOURCE_RUNS("int main() { thread_local int i = 0; return i; }" HAS_THREAD_LOCAL)
+include(CheckCXXSourceCompiles)
+CHECK_CXX_SOURCE_COMPILES("int main() { thread_local int i = 0; return i; }" HAS_THREAD_LOCAL)
 
-CHECK_CXX_SOURCE_RUNS("
+CHECK_CXX_SOURCE_COMPILES("
 #include 
 
 int main() {
@@ -97,7 +97,7 @@
 }
 " HAS_CLOCK_GETTIME)
 
-CHECK_CXX_SOURCE_RUNS("
+CHECK_CXX_SOURCE_COMPILES("
 #include 
 #include 
 
@@ -107,7 +107,7 @@
 }
 " HAS_FUTIMENS)
 
-CHECK_CXX_SOURCE_RUNS("
+CHECK_CXX_SOURCE_COMPILES("
 #include 
 #include 
 #include 

Bug#996746: Outdated lua dependency

[Marko Lindqvist]

Package: freeciv
Version: 2.6.5-1

Noticed on https://tracker.debian.org/pkg/freeciv a warning that
freeciv depends on two packages which would need a new maintainer. One
of these is liblua5.2-dev. That should be easy to fix by updating the
dependencies, as freeciv-2.6 uses lua-5.3, not lua-5.2. As you don't
have lua-5.3 in dependencies, it might be that no debian packaged lua
gets used at all, but it instead falls back to compiling it from an
included copy.

On a related note I suspect that the other listed package, gnulib, is
not needed as a dependency either. Freeciv distribution should contain
all the required .m4 files, and I think you use those anyway (newer
serial). I could see the point of using .m4 files from the gnulib
package instead, but as things currently stand the abandoned package
has more outdated versions than freeciv distribution.


 - ML

Bug#996745: nm.debian.org: "Contributor" on some person pages incorrectly links to "None"

[Paul Wise]

Package: nm.debian.org
Severity: normal
X-Debbugs-CC: Boian Bonev 

The "Contributor" link for bbonev links to "None":

   $ curl -s https://nm.debian.org/person/bbonev/ | grep None.*Contributor
  Contributor

It looks like contributors.d.o doesn't know about bbonev even though
they are a DM and have done package uploads this year.

In this situation, probably hiding the "Contributor" link is the right
thing to do. Alternatively an error message could be shown.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#996744: kde-config-gtk-style: Version mismatch segfaults kded5 repeatedly

[Patrick Häcker]

Package: kde-config-gtk-style
Version: 4:5.23.0-2
Severity: normal

Dear Maintainer,

I am not sure, whether this is a kded5 or kde-config-gtk-style packaging
problem, but both can currently be installed in an incompatible way leading
to repeatedly crashing kded5 (like 10 Dr.Konqi windows on login and some more
windows later) and a reduced user experience due to a missing kded5 process.

Being on testing and doing a
apt install kde-plasma-desktop kwin-addons -t unstable

updates the following packages to 5.23:
breeze-cursor-theme breeze kde-cli-tools-data kde-cli-tools
kde-style-breeze kdeplasma-addons-data kwin-addons kwin-common
kwin-data kwin-style-breeze kwin-wayland-backend-x11 kwin-wayland
kwin-x11 libcolorcorrect5 libkdecorations2-5v5 libkdecorations2private9
libkf5screen-bin libkf5screen7 libkf5sysguard-bin libkf5sysguard-data
libkfontinst5 libkfontinstui5 libksgrd9 libksignalplotter9
libksysguardformatter1 libksysguardsensorfaces1 libksysguardsensors1
libksysguardsystemstats1 libkwin4-effect-builtins1 libkwineffects13
libkwinglutils13 libkwinxrenderutils13 libkworkspace5-5
libnotificationmanager1 libplasma-geolocation-interface5
libprocesscore9 libprocessui9 libtaskmanager6abi1 libweather-ion7
milou plasma-dataengines-addons plasma-desktop-data plasma-desktop
plasma-runners-addons plasma-wallpapers-addons plasma-widgets-addons
plasma-workspace-data plasma-workspace-wayland plasma-workspace

However, the following packages stay on 5.21:
kde-config-gtk-style kde-config-sddm kde-style-oxygen-qt5 khotkeys-data
khotkeys kinfocenter kmenuedit kscreen ksshaskpass ksysguardd
kwin-decoration-oxygen kwrited libkdecorations2private8 liboxygenstyle5-5
liboxygenstyleconfig5-5 libpowerdevilcore2 libpowerdevilui5
oxygen-sounds plasma-pa plasma-theme-oxygen plasma-workspace-wallpapers
polkit-kde-agent-1 powerdevil-data powerdevil qml-module-org-kde-ksysguard
sddm-theme-breeze sddm-theme-debian-breeze systemsettings

That is not necessarily a problem (although probably not what the user
expects and a likely source of trouble). However, kded5=5.85.0-1 and
kde-config-gtk-style=4:5.23.0-2 lead to the described crash above within
plasma-workspace=4:5.23.0-3 (no crash with plasma-workspace=4:5.21.5-3).

The segfault occurs in the described package combination if ~/.config/kded5rc
contains
[Module-gtkconfig]
autoload=true
and there is no crash for autoload=false for the getconfig module.

Although I think the versioned dependency or break should be fixed, this is
the stacktrace for completeness:
Thread 1 "kded5" received signal SIGSEGV, Segmentation fault.
0x7fffeab92510 in KDecoration2::DecorationSettings::font() const () from 
/lib/x86_64-linux-gnu/libkdecorations2.so.5
(gdb) bt
#0  0x7fffeab92510 in KDecoration2::DecorationSettings::font() const () at 
/lib/x86_64-linux-gnu/libkdecorations2.so.5
#1  0x7fffeab92737 in 
KDecoration2::DecorationSettings::DecorationSettings(KDecoration2::DecorationBridge*,
 QObject*) ()
at /lib/x86_64-linux-gnu/libkdecorations2.so.5
#2  0x7fffeb24f3b2 in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#3  0x7fffeb24e93e in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#4  0x7fffeb24e278 in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#5  0x7fffeb246ef5 in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#6  0x7fffeb241e0b in GtkConfig::setWindowDecorationsAppearance() const ()
at /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#7  0x7fffeb242781 in GtkConfig::applyAllSettings() const () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#8  0x7fffeb242ba4 in GtkConfig::GtkConfig(QObject*, QList 
const&) ()
at /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#9  0x7fffeb2434aa in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#10 0x77006a52 in KPluginFactory::create(char const*, QWidget*, 
QObject*, QList const&, QString const&) ()
at /lib/x86_64-linux-gnu/libKF5CoreAddons.so.5
#11 0x5556019d in  ()
#12 0x55561119 in  ()
#13 0x555615a3 in  ()
#14 0xb121 in  ()
#15 0x766a8e4a in __libc_start_main (main=
0xab10, argc=1, argv=0x7fffdec8, init=, 
fini=, rtld_fini=, stack_end=0x7fffdeb8) at 
../csu/libc-start.c:314
#16 0xb53a in  ()

Kind regards
Patrick

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kde-config-gtk-style depends on:
ii  libc6 2.32-4
ii  

Bug#862727: Concerning libjasper

[Norbert Preining]

Hi all,

sending everyone that discussed on the bug an email.

Since version 2.0.19 (2020-07-11) libjasper is now reasonably active
maintained and CVEs have been dealt with.

For support in some KDE/Plasma packages I have revived/made some
packaging of the current version (2.0.33, from 2021-08-01).

Adam, are you still interested in getting this back into Debian?
Any other comment?

BTW, my source package are built on OBS:
https://build.opensuse.org/package/show/home:npreining:debian-kde:other-deps/jasper

All the best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#996743: valgrind: new upstream release (3.18.1) adds close_range support

[Paul Wise]

Package: valgrind
Version: 1:3.17.0-1
Severity: wishlist

The latest valgrind release (3.18.1) adds support for the new
close_range syscall from Linux 5.9, please update to the new release.

https://valgrind.org/downloads/current.html#current
https://valgrind.org/docs/manual/dist.news.html
https://sourceware.org/git/?p=valgrind.git;a=commit;h=a21e890f82258c17ee47895fa28bb62937eb1af9
https://bugs.kde.org/show_bug.cgi?id=439090

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages valgrind depends on:
ii  libc6  2.32-4
ii  libc6-dbg  2.32-4

Versions of packages valgrind recommends:
ii  gdb   10.1-2
pn  valgrind-dbg  

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#951855:

[Boian Bonev]

Maybe Michal is busy? We already had one round and he accepted all the
fixes (found during packaging gammu) upstream. At that time there were
several things to improve and the package was not ready for uploading.

Also I will need sponsoring the upload, but I think that the proper way
is to wait for Michal to approve and sponsor this. In case he only
approves, I will file a RFS...

--
With best regards,
b.




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

Bug#994079: python3-matplotlib: TkAgg backend emits errors on savefig() with tight option

[Sandro Tosi]

> to switch to a different backend. I include an example below which triggers
> a slew of Tk error messages, although the output seems correct. Sometimes

can you include the output of that code as run on your system?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#996742: hostapd: Build with airtime policy configuration support

[Leonard Lausen]

Package: hostapd
Version: 2:2.9.0-21
Severity: normal

Dear Maintainer,

hostapd 2.9 supports airtime policies for improved performance. For
example, prioritisation of specific devices, and balancing or
limiting of groups of devices. Please allow users to enable it
by setting CONFIG_AIRTIME_POLICY=y in the hostapd/defconfig.

The support was introduced in the following commit, which also links a
paper with more details:
https://w1.fi/cgit/hostap/commit/?id=ef7217518be9705409cc330309221041c1312993

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.15.0-rc4-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hostapd depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+rpt2+rpi1
ii  libnl-3-200  3.4.0-1
ii  libnl-genl-3-200 3.4.0-1
ii  libnl-route-3-2003.4.0-1
ii  libssl1.11.1.1k-1+deb11u1
ii  lsb-base 11.1.0+rpi1

hostapd recommends no packages.

hostapd suggests no packages.

-- Configuration Files:
/etc/default/hostapd changed [not included]

-- no debconf information

Bug#996741: libtool: Missing CPPFLAGS at link step

[Samuel Thibault]

Package: libtool
Version: 2.4.6-15
Severity: normal

Hello,

While building libraries:

https://buildd.debian.org/status/fetch.php?pkg=speech-dispatcher=amd64=0.11.0~rc3-1=1634514330=0

libtool compiles some fooS.c files taking into account the CFLAGS, but
not the CPPFLAGS:

libtool: link: (cd .libs && gcc -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -fno-builtin 
"sd_dummyS.c")
[...]

blhc thus complains about it, because then there is not FORTIFY macro
defined etc.

Samuel

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
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

Versions of packages libtool depends on:
ii  autotools-dev  20180224.1+nmu1
ii  clang-11 [c-compiler]  1:11.1.0-4
ii  clang-9 [c-compiler]   1:9.0.1-20
ii  cpp4:10.2.1-1
ii  file   1:5.39-3
ii  gcc [c-compiler]   4:10.2.1-1
ii  gcc-10 [c-compiler]10.3.0-11
ii  gcc-11 [c-compiler]11.2.0-9
ii  gcc-6 [c-compiler] 6.5.0-2
ii  gcc-8 [c-compiler] 8.4.0-7
ii  gcc-9 [c-compiler] 9.4.0-3
ii  libc6-dev [libc-dev]   2.32-4

Versions of packages libtool recommends:
ii  libltdl-dev  2.4.6-15

Versions of packages libtool suggests:
ii  autoconf  2.71-2
ii  automake [automaken]  1:1.16.4-2
ii  automake1.11 [automaken]  1:1.11.6-6
pn  gcj-jdk   
ii  gfortran  4:10.2.1-1
ii  gfortran-10 [fortran95-compiler]  10.3.0-11
ii  gfortran-9 [fortran95-compiler]   9.4.0-3
ii  libtool-doc   2.4.6-15

-- no debconf information

-- 
Samuel
 hm. I've lost a machine.. literally _lost_. it responds to ping, it 
works completely, I just can't figure out where in my apartment it is.

Bug#995944: Does not use auto-detect if git is already in use

[Philip Rinn]

Control: severity -1 wishlist

Hi Trent,

thanks for your bug report. I think it's a great idea to improve qtpass, I'll 
forward your feature request upstream.


On 08.10.21 at 17:35, Trent W. Buck wrote:

I am flagging this as "serious" because it leads to data loss.
Specifically, I already lost the history of my test passwords.
Had I not noticed right away, I could have lost REAL passwords.


I disagree as I don't think what you describe is the "data loss" we assign the 
severity "serious" to - qtpass itself does not destroy any data. Humans/scripts 
who might not notice that files where added/changed by qtpass (obviously only by 
human interaction) without committing the changes might override the changes made 
by qtpass which might lead to data loss.


I agree that qtpass could have better defaults but this is a feature request -> 
severity "whishlist".


Thanks & best regards
Philip

Bug#995198: wsjtx: No transmit audio

[tony mancill]

On Sun, Oct 17, 2021 at 11:56:35PM +0200, Christoph Berg wrote:
> Re: tony mancill
> > I am tempted to upload a new source package to trigger a rebuild to see
> > if that solves the problem with the deb in the archive.  Perhaps wsjtx
> > got caught up in a transition causing this subtle failure?
> > 
> > Christoph or Dave, do you have any suggestions on how to track down the
> > root cause?
> 
> Since it works for me I don't have any idea how to debug this, except
> maybe to diffoscope the two debs.

That's a good idea.  The diffoscope results in 100MB of diff, almost all
of it in the resulting binaries, so I'm opting to focus on the build
environments for now.  There are a number of differences, most of which
appear to be benign.  The only significant ones are the GCC-10 -> GCC-11
transition and hamlib 4.1 -> 4.3

If anyone would like to take a look at the buildinfo from the archive
and locally build packages or the full diffoscope between the binary
packages, those files can be found here:

  https://people.debian.org/~tmancill/wsjtx-995198/.

> No objections to trying a rebuild of course.
> 
> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=wsjtx=armhf=2.5.0%2Brepack-1=1632820833=0
> 
> Maybe the problem is architecture-specific? The OP is on amd64 like
> me, though.

Yeah, I was surprised when it occurred for me.  Of course, I'm making an
assumption that the behavior I saw is the same as that from the original
bug report.

The fact that the "Tune" button couldn't even key my radio, despite the
fact that I'm using CAT, makes me suspect that I might have found a issue
with running a binary compiled against hamlib 4.1 against a system with
4.3 installed.  That upload was on 2021-10-12, which would explain why I
didn't see it a week ago; I updated my system on 2021-10-16.

But that still doesn't explain why you didn't see the problem.  Hmm... 

Thank you,
tony


signature.asc
Description: PGP signature

Bug#996740: Consider having very-long-line-length-in-source-file ignore autotools files

[Russ Allbery]

Felix Lechner  writes:

> We can now grant summary exceptions to package families. They are called
> screens (which mask hints). [1] They actually simplify the checks and
> are beautiful little things!

Oh, those are very cool.  That looks like exactly the right way to handle
this.  Thank you for implementing that!

> Yes, the exception is probably warranted. If it's okay with you,
> however, I will postpone the decision until the cruft check, which
> issues the offending tag, is fixed. It is currently malfunctioning.  [2]
> Thank you!

Yes, absolutely, this is a low priority.

-- 
Russ Allbery (r...@debian.org)  

Bug#984833: Alternative flash implementation

[Sebastian Tobie]

a few months ago i read about an software called Ruffle. I has an addon for 
firefox that replaces
the the object tag with an script that reimplements Flash in the browser. An 
demonstration is
available at https://ruffle.rs . The implementation is also used by archie.org 
to display archived
flash applications and games.
I hope this could help you with your problem.
-- 
Sebastian Tobie 

Bug#996740: Consider having very-long-line-length-in-source-file ignore autotools files

[Felix Lechner]

Control: severity -1 important

Hi Russ,

On Sun, Oct 17, 2021 at 3:57 PM Russ Allbery  wrote:
>
> how much
> (excellent!) work has been done to try to make Lintian's code flow
> simpler

Thank you for your kind words!

> I suspect a lot of
> packages are going to encounter them (presumably both will trigger on
> every package that includes a copy of the current version of libtool,
> which is most library packages using Automake)

We can now grant summary exceptions to package families. They are
called screens (which mask hints). [1] They actually simplify the
checks and are beautiful little things!

> an exception for autotools files would be warranted?

Yes, the exception is probably warranted. If it's okay with you,
however, I will postpone the decision until the cruft check, which
issues the offending tag, is fixed. It is currently malfunctioning.
[2] Thank you!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/screens
[2] https://bugs.debian.org/993613

Bug#994762: warnings about session IDs

[Antoine Beaupré]

On 2021-10-17 07:31:09, Ian Campbell wrote:
> (sorry for the delay)
>
> On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote:
>> > Worth a try I suppose, please let me know if it works and I'll update
>> > the service file in the package.
>> 
>> Okay, will try! I do see that XDG_SESSION_ID is a thing here...
>
> Thanks.

And I can confirm it works, or at least does not warn.

>> > Out-of-interest how does one go about activating the service file for
>> > your user, I suppose you copy it to ~/.config somewhere or pass it to
>> > some systemctl command -- it'd be great if I could add some
>> > instructions to the docs.
>> 
>> The post above does a lot of legwork, but basically, this is my
>> .xsession:
>
> Thanks. It's probably a bit of a broad setup/concept for the xss-lock
> docs but it's something I may try for myself at some point.

Yeah, it's an emerging idea, and probably very niche, ie. restricted to
non-GNOME/KDE/etc sessions... But I still think it's kind of cool.

Oh, and xss-lock is awesome, thanks. Feels like a bit of too many moving
parts and I'm somewhat worried about it not working sometimes, but it's
much snappier than xscreensaver and "feels" a little more secure because
the way the components are setup.

And now that I think of it, I wonder if those processes couldn't be
better sandboxed... Ideas?

a.

-- 
When I came back to the United States, I decided that if you could use
propaganda for war, you could certainly use it for peace. And
"propaganda" got to be a bad word because of the Germans using it, so
what I did was to try and find some other words so we found the words
"public relations".  - Edward Bernays

Bug#963041: Lagging behind several versions for snakemake - lots of failed tests in latest version

[Rebecca N. Palmer]

On 15/10/2021 14:46, Andreas Tille wrote:

Hi Rebecca

and whoever might care.  As usual snakemake is troublesome to upgrade.
I have injected the latest version into Git but there are lots of
failed tests.  It would be great if someone could care about this.

Kind regards

   Andreas.



I hadn't tried to upgrade snakemake because python-pulp is too old 
(#963041).


The test failures look like this isn't the only problem, but it is the 
one I'm not allowed to fix myself.

Bug#996740: Consider having very-long-line-length-in-source-file ignore autotools files

[Russ Allbery]

Package: lintian
Version: 2.109.0
Severity: wishlist

libpam-krb5 4.11-1 (just now uploaded and also available from Salsa)
produced the following new Lintian pedantic tags:

N:
P: libpam-krb5 source: very-long-line-length-in-source-file configure line 
13223 is 704 characters long (>512)
N: 
N:   The source file includes a line length that is well beyond the normally
N:   human made code line length.
N:   
N:   This very long line length does not allow Lintian to do correctly some
N:   source file checks.
N:   
N:   This line could also be the result of some text injected by a computer
N:   program, and thus could lead to FTBFS bugs.
N:   
N:   Last but not least, long line in source code could be used to obfuscate
N:   the source code and to hide stuff like backdoors or security problems.
N:   
N:   It could be due to jslint source comments or other build tool comments.
N:   
N:   You may report this issue upstream.
N: 
N:   Visibility: pedantic
N:   Show-Always: no
N:   Check: cruft
N:   Renamed from: insane-line-length-in-source-file
N: 
N:
P: libpam-krb5 source: very-long-line-length-in-source-file m4/libtool.m4 line 
6627 is 738 characters long (>512)

I am reluctant to request adding special exceptions given how much
(excellent!) work has been done to try to make Lintian's code flow
simpler, but given the source of those two hints, I suspect a lot of
packages are going to encounter them (presumably both will trigger on
every package that includes a copy of the current version of libtool,
which is most library packages using Automake), and they're not
actionable by the maintainer or by upstream.  Those files are already
being deleted and recreated by dh_autoreconf, and are present because
the upstream source tarball as released and signed by upstream is used
as the basis for packaging.

Perhaps the extra complexity of an exception for autotools files would
be warranted?  (configure and m4/libtool.m4 may be the only ones that
trigger this; I haven't done any further research.)

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

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

Versions of packages lintian depends on:
ii  binutils2.37-7
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl   

Bug#996687: www.debian.org: Inconsistence between keymaps related packages on packages.debian and in apt searches

[Holger Wansing]

Hi,

Stephane Ascoet  wrote (Sun, 17 Oct 2021 
10:49:15 +):
> 
> To install french keyboard support in Debian-live(having to do this is a 
> first problem, the boot menu choice having only partial effect), I searched 
> out how with "man loadkeys". I understood that keymaps where missing so I've 
> searched "keymaps" on the packages 
> Website(https://packages.debian.org/search?suite=default=all=any=names=keymaps).
>  I get a list with 8 console-keymaps-* packages. But non of them can be 
> installed via apt! I finally found the right virtual package with "aptitude 
> search" but this inconstancy is abnormal, the online package search should be 
> the mirror of the cli one


The packages you found via packages.debian.org are 'udeb' packages: special
packages to be only used by the debian-installer; they are not meant to be
installed on a usual Debian system.
That's why apt does not provide them to you for installation.


I agree, that this is not obvious to users/newcomers: at the search result
list, you only see


Paket console-keymaps-acorn
bullseye (stable) (debian-installer): keymaps for Acorn RISC-PC keyboards 
2:1.12-8: all

Paket console-keymaps-amiga
bullseye (stable) (debian-installer): keymaps for Amiga keyboards 
2:1.12-8: all

Paket console-keymaps-at
bullseye (stable) (debian-installer): keymaps for PC-style (PS/2 and AT) 
keyboards 
2:1.12-8: all


and so on.

Users might overlook the "(debian-installer)" hint or don't understand its
meaning.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#996569: getmail6 naming issues

[Charles Cazabon]

Hi, Sudip,

Thanks for the response.

> > On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote:
> > >
> > > I would appreciate it if this package/project was renamed to something
> > > that does not contain the word "getmail" or anything confusingly
> > > similar.
> 
> "getmail" and "getmail6" are separate source packages and they were
> kept separate with the hope that you will release the python3 version
> one day and then getmail can be reintroduced.

That's fine as far as it goes, but you have not addressed my concern and the
reason I filed this report.

I did not consent to the fork using my project name.  I am explicitly asking
it to be changed to something that does not infringe on my trademark
"getmail".

I would think that the Debian project is about acting ethically, and when the
owner of the upstream project explicitly asks a forked, buggy version to use a
different name, the ethical thing to do is to respect that request and pick a
new name.

> I am not sure how this is going to help. Any change I do now will be
> affecting the next Debian release in 2023.

Packages change in Debian all the time.  This can be changed.

> I will remove the transitional package before Debian Bookworm is
> released so that getmail and getmail6 will not be linked anymore.

You still have not committed to removing the name "getmail" from this project.
Can you please commit to doing this promptly, and let me know when it will be
done?

Charles
-- 
--
Charles Cazabon  
Software, consulting, and services available at http://pyropus.ca/
--

Bug#996739: tinyproxy: Environment file /etc/default/tinyproxy does not work with systemd

[Timo Sigurdsson]

Package: tinyproxy
Version: 1.10.0-5
Severity: normal

Dear Maintainer,

after installing tinyproxy for the first time on Debian 11.1 (bullseye), I 
looked at the defaults or environment file /etc/default/tinyproxy. It contains 
the following comment:
> # If running under systemd, please make sure to uncomment
> # both variables below!
> #CONFIG="/etc/tinyproxy/tinyproxy.conf"
> #FLAGS="-c $CONFIG"

Ok, so I did just that and the result is that tinyproxy fails to start. The 
problem is that variables within variables are not expanded by systemd, so 
tinyproxy complains it cannot find the configuration file $CONFIG.

In addition, the file suggests to append more command arguments by appending 
the variable like so:
> FLAGS="$FLAGS ..."
That however will not work either for the same reason. So this entire 
defaults/environment file is broken for systemd.

I would suggest to change the systemd unit to execute:
ExecStart=/usr/bin/tinyproxy $CONFIG $FLAGS

and change the defaults file to something like this:
#CONFIG="-c /etc/tinyproxy/tinyproxy.conf"
#FLAGS="... extra options go here ..."

Even if both variables are commented out/unset or the environment file is not 
found, tinyproxy will start if there is a configuration file in the default 
location.
I'm still puzzled, however, about what extra options one would use in the FLAGS 
variable. tinyproxy doesn't have a lot of options according to the man page. 
The only useful options are "-c" and "-d" when tinyproxy is supposed to 
actually run. But "-d" won't work with the systemd service Type=forking 
directive. So, if someone wanted to use "-d" for debugging purposes they'd 
either have to change the systemd unit file (in which case they might as well 
just add the option there" or simply bypass systemd and start the executable 
directly. So the examples in /etc/default/tinyproxy might be simplified 
altogether...

Thanks and regards,

Timo


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

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

Versions of packages tinyproxy depends on:
ii  adduser3.118
ii  logrotate  3.18.0-2
ii  lsb-base   11.1.0
ii  tinyproxy-bin  1.10.0-5

tinyproxy recommends no packages.

tinyproxy suggests no packages.

-- Configuration Files:
/etc/default/tinyproxy changed:
FLAGS="-c /etc/tinyproxy/tinyproxy.conf"

/etc/tinyproxy/tinyproxy.conf changed:
User tinyproxy
Group tinyproxy
Port 8443
Listen 192.168.122.10
Timeout 60
Syslog On
LogLevel Notice
PidFile "/run/tinyproxy/tinyproxy.pid"
MaxClients 3
MinSpareServers 1
MaxSpareServers 2
StartServers 1
MaxRequestsPerChild 0
Allow 192.168.218.10
ViaProxyName "tinyproxy"
Filter "/etc/tinyproxy/filter"
FilterDefaultDeny Yes
ConnectPort 443


-- no debconf information

Bug#996738: tinyproxy: Invalid fix for bug #968322 (issue still occurs): tinyproxy exits 2 on standard systemd stop signal SIGTERM

[Timo Sigurdsson]

Package: tinyproxy
Version: 1.10.0-5
Severity: important

Dear Maintainer,

I installed tinyproxy on an up-to-date Debian 11.1 (bullseye) installation. I'm 
seeing the issue that was reported in bug #968322 and later claimed to be fixed 
in version 1.10.0-5 (which I run) both with the default configuration and my 
custom configuration (see below) on two different machines. There seems to be 
some race condition or other magical circumstances involved, though, because 
after trying to reproduce this issue in a virtual machine, I could only trigger 
it with the default configuration after installing the package but not anymore 
with my custom configuration. But on my actual "production" system (a PC 
Engines APU2 box with some slower/dated AMD CPU) where tinyproxy was initially 
installed, I see the issue with both configurations.

Nevertheless, I tried a couple of changes to the systemd unit file and nothing 
solved the issue except the directive SuccessExitStatus=2.
I still found out one thing of note, though. I tried specifying an ExecStop 
command like so:
ExecStop=/usr/bin/kill -TERM $MAINPID

With this, after stopping the service, `systemctl status tinyproxy' showed that 
the kill command returned 0, but the main process returned 2. It seems to me 
that this contradicts the following statement in the original bug report which 
was:
> The issue is more likely caused by systemd paying attention to the return 
> value of its SIGTERM send calls [...]

I don't know whether that is helpful in terms of solving the cause for the 
issue. But I thought, I'd at least mention it.

As for the issue itself, unfortunately, the changes included in package version 
1.10.0-5 don't solve the issue entirely (at least not for me).


Thanks and regards,

Timo


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

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

Versions of packages tinyproxy depends on:
ii  adduser3.118
ii  logrotate  3.18.0-2
ii  lsb-base   11.1.0
ii  tinyproxy-bin  1.10.0-5

tinyproxy recommends no packages.

tinyproxy suggests no packages.

-- Configuration Files:
/etc/default/tinyproxy changed:
FLAGS="-c /etc/tinyproxy/tinyproxy.conf"

/etc/tinyproxy/tinyproxy.conf changed:
User tinyproxy
Group tinyproxy
Port 8443
Listen 192.168.122.10
Timeout 60
Syslog On
LogLevel Notice
PidFile "/run/tinyproxy/tinyproxy.pid"
MaxClients 3
MinSpareServers 1
MaxSpareServers 2
StartServers 1
MaxRequestsPerChild 0
Allow 192.168.218.10
ViaProxyName "tinyproxy"
Filter "/etc/tinyproxy/filter"
FilterDefaultDeny Yes
ConnectPort 443


-- no debconf information

Bug#996595: nvidia-legacy-390xx-driver: NVIDIA service is not starting with the system

[Alessandro Reis de Alcântara]

I installed the package with apt...

apt install nvidia-legacy-390xx-driver

Em dom., 17 de out. de 2021 18:26, Andreas Beckmann 
escreveu:

> On 17/10/2021 19.32, Alessandro Reis de Alcântara wrote:
> > I uninstalled every single package from nvidia and libnvidia again. Then
> I
> > reinstalled nvidia-legacy-390xx-driver. The libnvdia-cfg1 was installed
> > together again, I have no clue why But then, I removed the
> > libnvidia-cfg1 package. And then I was able to get the nvidia daemon up
> at
> > initialization.
>
> What command line or which graphical tool did you use to install the
> nvidia driver? Something seems to resolve the dependencies and
> recommendations differently than in my tests (where I don't see that
> library installed).
>
> I'll try to make the mere presence of libnvidia-cfg1 but no other driver
> components to no longer enable the "current" nvidia alternative (which
> has higher priority than the legacy one).
>
> > I just had a problem starting the cinnamon. I had to modify the
> > "/usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf" to get it
> working
> > fine. The file had to be like this:
>
> If you need to make modifications, place them in /etc/X11/xorg.conf.d/
> otherwise they get overwritten on upgrades.
>
> Andreas
>

Bug#996628: cwdaemon: replace libcw6-dev with libcw-dev

[Christoph Berg]

Re: Sebastian Ramacher
> Source: cwdaemon
> Version: 0.10.2-2
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> unixcw changed its -dev package in 3.6.0-2 from libcw6-dev to libcw-dev.
> Please update the build dependency accordingly.

We should probably also add "Provides: libcw6-dev" to libcw-dev.

Christoph

Bug#996569: getmail6 naming issues

[Sudip Mukherjee]

Hi Charles,

On Sat, Oct 16, 2021 at 8:33 PM Charles Cazabon
 wrote:
>
> On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote:
> >
> > So: fork is fine.  Imposing a large support burden on the original project 
> > is
> > not.  I would appreciate it if this package/project was renamed to something
> > that does not contain the word "getmail" or anything confusingly similar.

"getmail" and "getmail6" are separate source packages and they were
kept separate with the hope that you will release the python3 version
one day and then getmail can be reintroduced.

getmail -> https://tracker.debian.org/pkg/getmail
getmail6 -> https://tracker.debian.org/pkg/getmail6

>
> I have a specific suggestion for Debian to address this issue.
>
> 1.  The upstream author, or if he refuses, the Debian package maintainer, can
> pick a new package name that does not pollute my getmail package,
> community, mailing list, and trademark, and which will stop imposing this
> unwelcome support burden on me and the getmail mailing list/community.
> I don't know what name you'll pick; for the rest of this proposal, let's
> use "go-grab-my-email" as an example.

I am really sorry that users are asking you for support instead of
opening bugs with Debian, which was giving us the impression that
getmail6 is working fine. But again, the README and the manpage
clearly says that bugs should be reported to
https://github.com/getmail6/getmail6.

>
> 2.  Package it for Debian.  Have it use the `Obsoletes: getmail` metadata so
> that users upgrading a Debian system have getmail correctly removed and
> the go-grab-my-email package installed, similar to what happens with the
> "getmail6" package now.

It initially had "Conflicts: getmail" to make sure getmail is
uninstalled before any user tries to install getmail6 but then one
user of getmail asked for them to be linked. You can see the details
at https://bugs.debian.org/979060

>
> 3.  Additionally, make the new package display an informational screen via
> apt-listchanges when getmail is removed and go-grab-my-email is installed.
> It should say something like:

I am not sure how this is going to help. Any change I do now will be
affecting the next Debian release in 2023. When users of getmail
upgrades to Debian Bullseye they will always get getmail6 because of
the transitional package.

I will remove the transitional package before Debian Bookworm is
released so that getmail and getmail6 will not be linked anymore.


-- 
Regards
Sudip

Bug#995368: oldstable also affected

[Jo Valentine-Cooper]

Can confirm that mailman3 in oldstable/buster also appears affected by this
regression, and the same mitigation (removing the trailing slash from the
ProxyPass directive) works around it. (Found out while trying a fourth time
to finish procrastinating on migrating my mailman2 system to mailman3 in
prep for a procrastinated update to bullseye; the resulting stress was...
not fun. :( )

Same symptoms in the mailman3-web log:
WARNING 2021-10-17 17:01:08,583 12164 django.request Not Found: /mailman//
WARNING 2021-10-17 17:01:08,583 12164 django.request Not Found: /mailman//

Since uwsgi in oldstable, so far as I can tell, hasn't been so much as
glanced at in two and a half years but Apache was security-updated within
the last week or two, that has me wondering about where the bug really
lies...

uswgi versions:
$ dpkg -l | grep uwsgi
ii  uwsgi2.0.18-1 i386
fast, self-healing application container server
ii  uwsgi-core   2.0.18-1 i386
fast, self-healing application container server (core)
ii  uwsgi-plugin-python3 2.0.18-1 i386
WSGI plugin for uWSGI (Python 3)

mailman3 versions:
$ dpkg -l | grep mailman3
ii  mailman3 3.2.1-1  all
   Mailing list management system
ii  mailman3-doc 3.2.1-1  all
   Mailing list management system documentation
ii  mailman3-full3.2.1-1  all
   Full Mailman3 mailing list management suite (metapackage)
ii  mailman3-web 0+20180916-8 all
   Django project integrating Mailman3 Postorius and HyperKitty
ii  python3-django-mailman3  1.2.0-3  all
   Django library to help interaction with Mailman3 (Python 3 version)

apache versions:
$ dpkg -l | grep apache
ii  apache2  2.4.38-3+deb10u6 i386
Apache HTTP Server
ii  apache2-bin  2.4.38-3+deb10u6 i386
Apache HTTP Server (modules and other binary files)
ii  apache2-data 2.4.38-3+deb10u6 all
   Apache HTTP Server (common files)
ii  apache2-utils2.4.38-3+deb10u6 i386
Apache HTTP Server (utility programs for web servers)

Hope this helps.
-jo


-- 
Jo Valentine-Cooper (j...@nwcs.com)
Of course, I don't know how interesting any of this really is,
but now you've got it in your brain cells so you're stuck with it.
--Gary Larson

Bug#995198: wsjtx: No transmit audio

[Christoph Berg]

Re: tony mancill
> I am tempted to upload a new source package to trigger a rebuild to see
> if that solves the problem with the deb in the archive.  Perhaps wsjtx
> got caught up in a transition causing this subtle failure?
> 
> Christoph or Dave, do you have any suggestions on how to track down the
> root cause?

Since it works for me I don't have any idea how to debug this, except
maybe to diffoscope the two debs.

No objections to trying a rebuild of course.

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=wsjtx=armhf=2.5.0%2Brepack-1=1632820833=0

Maybe the problem is architecture-specific? The OP is on amd64 like
me, though.

Christoph

Bug#869535: lightdm: service fails to start due to incorrect data dir perms

[Phil Endecott]

I've also seem this warning message and the root.root permissions on 
/var/lib/lightdm/data/

This system previously had a very minimal (debootstrap'd) 
Debian Bullseye installation. I then did:

# apt-get install openbox lightdm

and rebooted. X starts and shows a background image but there are 
no login controls or anything else. On this first boot, 
/var/log/lightdm/lightdm.log says:

[+0.06s] WARNING: Could not enumerate user data directory 
/var/lib/lightdm/data: Error opening directory '/var/lib/lightdm/data': No such 
file or directory

Looking at the permissions:

# ls -ld /var
drwxr-xr-x 12 root root 4096 Oct 11 16:36 /var

# ls -ld /var/lib
drwxr-xr-x 23 root root 4096 Oct 17 16:34 /var/lib

# ls -ld /var/lib/lightdm/
drwxr-x--- 4 lightdm lightdm 4096 Oct 17 16:36 /var/lib/lightdm/

# ls -ld /var/lib/lightdm/data/
drwxr-xr-x 3 root root 4096 Oct 17 16:36 /var/lib/lightdm/data/

# ls -ld /var/lib/lightdm/data/lightdm/
drwxrwx--- 2 lightdm lightdm 4096 Oct 17 16:36 /var/lib/lightdm/data/lightdm/

# ls -l /var/lib/lightdm/data/lightdm/
total 0

Observe the ownership going down the hierarchy is root then lightdm 
then root then lightdm, which seems peculiar.

On the second boot, this warning was not shown - presumably the 
missing directory was created on the first boot albeit with the 
surprising ownership. lightdm still didn't work, but that was due 
to other issues.


Regards, Phil.

Bug#947319: lightdm: fails during startup (no invite)

[Phil Endecott]

I have also seen this message in the lightdm log:

[+0.06s] WARNING: Error getting user list from 
org.freedesktop.Accounts: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Accounts was not provided by any .service files


This went away when I installed accountsservice.

I believe that either lightdm itself or maybe the greeter package
should depend on accountsservice.


Regards, Phil.

Bug#996595: nvidia-legacy-390xx-driver: NVIDIA service is not starting with the system

[Andreas Beckmann]

On 17/10/2021 19.32, Alessandro Reis de Alcântara wrote:

I uninstalled every single package from nvidia and libnvidia again. Then I
reinstalled nvidia-legacy-390xx-driver. The libnvdia-cfg1 was installed
together again, I have no clue why But then, I removed the
libnvidia-cfg1 package. And then I was able to get the nvidia daemon up at
initialization.


What command line or which graphical tool did you use to install the 
nvidia driver? Something seems to resolve the dependencies and 
recommendations differently than in my tests (where I don't see that 
library installed).


I'll try to make the mere presence of libnvidia-cfg1 but no other driver 
components to no longer enable the "current" nvidia alternative (which 
has higher priority than the legacy one).



I just had a problem starting the cinnamon. I had to modify the
"/usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf" to get it working
fine. The file had to be like this:


If you need to make modifications, place them in /etc/X11/xorg.conf.d/ 
otherwise they get overwritten on upgrades.


Andreas

Bug#983339: linux-image-5.10.0-0.bpo.3-amd64: system freezes when idle for a couple of hours

[Mikhail V. Zhukov]

Package: src:linux
Version: 5.10.70-1
Followup-For: Bug #983339
X-Debbugs-Cc: mikhail.v.zhu...@gmail.com

I can confirm full freezing system after kernel try to turn off screen.
System can work more stable if I turn of monitor sleep in the settings.
System absolutely freezed I can't reboot by SAK keys.
I try change kernel to linux-image-5.14.0-0.bpo.2-amd64-unsigned and 
have no lucky because system not freeze but reboot. But in the log I saw
окт 16 23:31:10 jupiter kernel: BERT: Error records from previous boot:
окт 16 23:31:10 jupiter kernel: [Hardware Error]: event severity: fatal
окт 16 23:31:10 jupiter kernel: [Hardware Error]:  Error 0, type: fatal
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   section_type: Firmware 
Error Record Reference
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   Firmware Error Record Type: 
SOC Firmware Error Record Type1 (Legacy CrashLog Support)
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   Revision: 0
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   Record Identifier: 
1001003
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   :   
   
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0010: 01001003 0006 
ba08e638 0005  8...
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0020: 0003 0050 
091e004c 83ff  P...L...
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0030: 02002080 7f05fe03 
0001   . ..
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0040: 2207 0120 
80002031 4020  ...".. .1 .. @..
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0050: 0102 c7000200 
ff0f0204 ef01f08b  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0060: 750e6873 9a002000 
0011 2000  sh.u. ... ..
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0070: 04002400  
00500881 000ecf1a  .$P.
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0080: 04035d00 0007 
5af3f070 1020003c  .]..p..Z<. .
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0090: 00c6 fef3f100 
de3717fc ff477ecf  ..7..~G.
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   00a0: 7cf3f0ff 18321000 
034178cf 5af3f01e  ...|..2..xAZ
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   00b0: 103c 00c6 
   <...
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   00c0:  c8202000 
08241cfc 000d  .  ...$.
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   00d0: 010c0f1e 21c80003 
00b88030 1000  ...!0...
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   00e0:  034166c0 
   .fA.
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   00f0: 10c0 4200 
 0114b800  .B..
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0100: 0002 0009 
0080 4c92ab01  ...L
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0110: 8fb7 b26d54e3 
7048 4c92abfc  .Tm...Hp...L
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0120: 8fb7 000290e3 
0001 0001  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0130: 0001 0001 
001308f0 0001  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0140: 0001 ff01 
ff0f ff0f  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0150: ff0f ff0f 
ff0f ff0f  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0160: ff0f 000f 
   
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0170:   
   
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0180:   
 9800  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0190: 004018ff 0001 
0001 0001  ..@.
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   01a0: 0001 1c01 
003f1817 9701  ..?.
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   01b0: ff09a10f ff0f 
ff0f ff0f  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   01c0: ff0f 1b0f 
ff05a007 000f  
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   01d0:   
   
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   01e0:   
   
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   01f0:   
   
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0200:   
0920 dec90002  .. .
окт 16 23:31:10 jupiter kernel: [Hardware Error]:   0210: ff000a3e 011e3cf9 

Bug#996667: kernel panic with kernel upgrade on diskless PXE + NFS system

[Mike]

Thanks, Salvatore, for replying.

> From the booting kernel could you please add the boot log

Attached as boot.log.

> any of the information which
> would be collected by reportbug kernel, so we can understand what NIC
> you have on eth0.

Attached "lspci -vv" output.  LMK if there's more that you need.
Linux version 4.19.0-16-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.181-1 (2021-03-19)
Command line: vga=795 root=/dev/nfs nfsroot=__.__.__.__:/__ ip=dhcp rw 
initrd=___/initrd.img-4.19.0-16-amd64 BOOT_IMAGE=vmlinuz-4.19.0-16-amd64 
x86/fpu: x87 FPU will use FXSAVE
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000e4000-0x000f] reserved
BIOS-e820: [mem 0x0010-0x7f68] usable
BIOS-e820: [mem 0x7f69-0x7f69dfff] ACPI data
BIOS-e820: [mem 0x7f69e000-0x7f6c] ACPI NVS
BIOS-e820: [mem 0x7f6d-0x7f6ddfff] reserved
BIOS-e820: [mem 0x7f6e-0x7f6f] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xfff0-0x] reserved
NX (Execute Disable) protection: active
SMBIOS 2.5 present.
DMI: System manufacturer System Product Name/P5KPL-CM, BIOS 060202/24/2009
tsc: Fast TSC calibration using PIT
tsc: Detected 1814.842 MHz processor
last_pfn = 0x7f690 max_arch_pfn = 0x4
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
found SMP MP-table at [mem 0x000ff780-0x000ff78f]
RAMDISK: [mem 0x7de3-0x7f66efff]
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000FB7B0 14 (v00 ACPIAM)
ACPI: RSDT 0x7F69 3C (v01 A_M_I_ OEMRSDT  02000924 MSFT 
0097)
ACPI: FACP 0x7F690200 84 (v02 A_M_I_ OEMFACP  02000924 MSFT 
0097)
ACPI: DSDT 0x7F6905C0 007C10 (v01 A0968  A0968000  INTL 
20051117)
ACPI: FACS 0x7F69E000 40
ACPI: APIC 0x7F690390 6C (v01 A_M_I_ OEMAPIC  02000924 MSFT 
0097)
ACPI: MCFG 0x7F690400 3C (v01 A_M_I_ OEMMCFG  02000924 MSFT 
0097)
ACPI: OEMB 0x7F69E040 80 (v01 A_M_I_ AMI_OEM  02000924 MSFT 
0097)
ACPI: HPET 0x7F6981D0 38 (v01 A_M_I_ OEMHPET  02000924 MSFT 
0097)
ACPI: GSCI 0x7F69E0C0 002024 (v01 A_M_I_ GMCHSCI  02000924 MSFT 
0097)
No NUMA configuration found
Faking a node at [mem 0x-0x7f68]
NODE_DATA(0) allocated [mem 0x7f68b000-0x7f68]
Zone ranges:
  DMA  [mem 0x1000-0x00ff]
  DMA32[mem 0x0100-0x7f68]
  Normal   empty
  Device   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x1000-0x0009efff]
  node   0: [mem 0x0010-0x7f68]
Zeroed struct page in unavailable ranges: 2514 pages
Initmem setup node 0 [mem 0x1000-0x7f68]
Reserving Intel graphics memory at [mem 0x7f80-0x7fff]
ACPI: PM-Timer IO Port: 0x808
IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed0
smpboot: Allowing 4 CPUs, 3 hotplug CPUs
PM: Registered nosave memory: [mem 0x-0x0fff]
PM: Registered nosave memory: [mem 0x0009f000-0x0009]
PM: Registered nosave memory: [mem 0x000a-0x000e3fff]
PM: Registered nosave memory: [mem 0x000e4000-0x000f]
[mem 0x8000-0xfedf] available for PCI devices
Booting paravirtualized kernel on bare hardware
clocksource: refined-jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 7645519600211568 ns
random: get_random_bytes called from start_kernel+0x93/0x52a with crng_init=0
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1
percpu: Embedded 45 pages/cpu s144536 r8192 d31592 u524288
Built 1 zonelists, mobility grouping on.  Total pages: 513598
Policy zone: DMA32
Kernel command line: vga=795 root=/dev/nfs nfsroot=__.__.__.__:/__ ip=dhcp 
rw initrd=__/initrd.img-4.19.0-16-amd64 BOOT_IMAGE=vmlinuz-4.19.0-16-amd64 
Memory: 2002128K/2087096K available (10252K kernel code, 1242K rwdata, 3328K 
rodata, 1600K init, 2260K bss, 84968K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Kernel/User page tables isolation: enabled
ftrace: allocating 31978 entries in 125 pages
rcu: Hierarchical RCU implementation.
rcu:RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=4.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
NR_IRQS: 33024, nr_irqs: 456, preallocated irqs: 16
Console: colour dummy device 80x25
console [tty0] enabled
ACPI: Core revision 20180810
clocksource: hpet: 

Bug#996737: ksysguard: apt dist-upgrade wants to remove ksysguard due to broken dependencies

[manul]

Package: ksysguard
Version: 4:5.21.5-2
Severity: normal

Dear Maintainer,


apt dist-upgrade wants to remove ksysguard due to libkf5sysguard-bin breaks and 
replaces ksysguard (<< 4:5.21.80), but no later version is available in the sid 
repo.

Also see this 
https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/ksysguard.html#dadaa0da5452e7f3ebf4066d6b7206dc

I believe this also related to ksysguard bug #996736

Thanks,
manul


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

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

Versions of packages ksysguard depends on:
ii  kio  5.86.0-1
ii  ksysguard-data   4:5.21.5-2
ii  ksysguardd   4:5.21.5-2
ii  libc62.32-4
ii  libgcc-s111.2.0-8
ii  libkf5completion55.86.0-1
ii  libkf5configcore55.86.0-1
ii  libkf5configwidgets5 5.86.0-1
ii  libkf5coreaddons55.86.0-1
ii  libkf5dbusaddons55.86.0-1
ii  libkf5i18n5  5.86.0-1
ii  libkf5iconthemes55.86.0-1
ii  libkf5kiocore5   5.86.0-1
ii  libkf5kiowidgets55.86.0-1
ii  libkf5networkmanagerqt6  5.86.0-1
ii  libkf5newstuff5  5.86.0-3
ii  libkf5newstuffcore5  5.86.0-3
ii  libkf5notifications5 5.86.0-1
ii  libkf5solid5 5.86.0-1
ii  libkf5widgetsaddons5 5.86.0-1
ii  libkf5windowsystem5  5.86.0-1
ii  libkf5xmlgui55.86.0-1
ii  libksgrd94:5.21.5-3
ii  libksignalplotter9   4:5.21.5-3
ii  libksysguardformatter1   4:5.21.5-3
ii  libnl-3-200  3.4.0-1+b1
ii  libnl-route-3-2003.4.0-1+b1
ii  libpcap0.8   1.10.1-4
ii  libprocesscore9  4:5.21.5-3
ii  libprocessui94:5.21.5-3
ii  libqt5core5a 5.15.2+dfsg-12
ii  libqt5dbus5  5.15.2+dfsg-12
ii  libqt5gui5   5.15.2+dfsg-12
ii  libqt5network5   5.15.2+dfsg-12
ii  libqt5widgets5   5.15.2+dfsg-12
ii  libqt5xml5   5.15.2+dfsg-12
ii  libsensors5  1:3.6.0-7
ii  libstdc++6   11.2.0-8
ii  libudev1 247.9-4

ksysguard recommends no packages.

ksysguard suggests no packages.

-- no debconf information

Bug#996736: ksysguard: Version 5-23 is not availible, but plasma-desktop depends on this (recommended)

[Norbert Preining]

reassign 996736 plasma-desktop
retitle 996736 recommends dropped ksysguard
tag 996736 + pending
thanks

On Sun, 17 Oct 2021, Achim Schaefer wrote:
> ksysguard is recommened by plasma-desktop, but there is no Version 5-23, 
> which would be required by plasma-desktop 5-23.
> Please provide an updated version

THere is none, the recommends is wrong and will be fixed in the next
upload.

The new package to be recommended is
plasma-systemmonitor

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#996736: ksysguard: Version 5-23 is not availible, but plasma-desktop depends on this (recommended)

[Achim Schaefer]

Package: ksysguard
Version: 4:5.21.5-2
Severity: normal
X-Debbugs-Cc: bts.debian@schaefer-home.eu

Hi,

ksysguard is recommened by plasma-desktop, but there is no Version 5-23, which 
would be required by plasma-desktop 5-23.

Please provide an updated version




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

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

Versions of packages ksysguard depends on:
ii  kio  5.86.0-1
ii  ksysguard-data   4:5.21.5-2
ii  ksysguardd   4:5.21.5-2
ii  libc62.32-4
ii  libgcc-s111.2.0-9
ii  libkf5completion55.86.0-1
ii  libkf5configcore55.86.0-1
ii  libkf5configwidgets5 5.86.0-1
ii  libkf5coreaddons55.86.0-1
ii  libkf5dbusaddons55.86.0-1
ii  libkf5i18n5  5.86.0-1
ii  libkf5iconthemes55.86.0-1
ii  libkf5kiocore5   5.86.0-1
ii  libkf5kiowidgets55.86.0-1
ii  libkf5networkmanagerqt6  5.86.0-1
ii  libkf5newstuff5  5.86.0-3
ii  libkf5newstuffcore5  5.86.0-3
ii  libkf5notifications5 5.86.0-1
ii  libkf5solid5 5.86.0-1
ii  libkf5widgetsaddons5 5.86.0-1
ii  libkf5windowsystem5  5.86.0-1
ii  libkf5xmlgui55.86.0-1
ii  libksgrd94:5.21.5-3
ii  libksignalplotter9   4:5.21.5-3
ii  libksysguardformatter1   4:5.21.5-3
ii  libnl-3-200  3.4.0-1+b1
ii  libnl-route-3-2003.4.0-1+b1
ii  libpcap0.8   1.10.1-4
ii  libprocesscore9  4:5.21.5-3
ii  libprocessui94:5.21.5-3
ii  libqt5core5a 5.15.2+dfsg-12
ii  libqt5dbus5  5.15.2+dfsg-12
ii  libqt5gui5   5.15.2+dfsg-12
ii  libqt5network5   5.15.2+dfsg-12
ii  libqt5widgets5   5.15.2+dfsg-12
ii  libqt5xml5   5.15.2+dfsg-12
ii  libsensors5  1:3.6.0-7
ii  libstdc++6   11.2.0-9
ii  libudev1 249.5-1

ksysguard recommends no packages.

ksysguard suggests no packages.

-- debconf-show failed

Bug#996735: Wrong filename in error message: plocate.db is corrupt or an old version; please rebuild it.

[Steinar H. Gunderson]

On Mon, Oct 18, 2021 at 06:57:42AM +1100, Trent W. Buck wrote:
>   2. mlocate is gone in Debian 12, so
>  I wanted to test if locate(1plocate) could read a database generated by 
> updatedb(8mlocate).
>  If it could, I wouldn't have to upgrade all clients and servers at once.
>  (It can't, hence the error message about "corrupt or an old version".)

Notwithstanding this bug, plocate-build(1) can convert mlocate databases
to plocate format. It may not be exactly what you're asking for, but it
should at least be cheaper to put in a cron job somewhere.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

Control: tags 989365 - moreinfo

Hello Tobias,

would you be able to help sponsor recastnavigation? I believe the final
upload (#5) is the right now and according to:
https://mentors.debian.net/package/recastnavigation/
lintian is green/happy. The package is listed as needing a sponsor but so
far no takers. :(

Time is running out as openmw-0.47.0 has been tagged and it depends on
recastnavigation to build. Hopefully I've done my due-diligence here.|

As a side note, I'm also prepping openmw as well. Could I bother you with
uploading that as well or do I need to go through the same route?

Cheers,
Bret

On Mon, Jun 14, 2021 at 11:27 PM bret curtis  wrote:

> tags 989365 - moreinfo
>
>
> On Sun, Jun 13, 2021 at 10:29 AM Tobias Frost  wrote:
>
>> On Sun, Jun 13, 2021 at 12:03:26AM +0200, bret curtis wrote:
>> > > New packages (ITPs) can go to unstable; (they don't interfere with
>> the freeze)
>> >
>> > https://mentors.debian.net/package/recastnavigation/
>>
>> - the watch file seems not to work; (take a look at uscan(1) and
>>   https://wiki.debian.org/debian/watch#GitHub)
>>   You can also do some commit-based watch-file with uscan, uscan(1) says
>> how to
>>   (I doing something like that in dhewm3 and rbdoom3bfg)
>
>
> I updated this, but I couldn't test it directly because I was on a Ubuntu
> laptop and the uscan failed on version=4
> Can you validate this please?
>
> - d/control:
>>   - cmake (>= 3) | cmake3
>> - there is no cmake3 package; drop that alternative.
>> - the versioned dependency is not needed; even oldstable has cmake > 3
>>   - shouln't the library package also be named librecastnavigation?
>> (it should match the -dev package's name
>>   - you)
>>
>>
> Took care of all of this as well.
>
>
>> - d/copyright:
>>   - Can you add a debian/* section with your name to d/copyright?
>>   - I saw at least one file where the copyright years where 2010 and one
>> file
>> under PD not mentioned at all. There is also a font without source.
>> (in the Demo)
>> Please review every file and check your copyright file to make sure
>> that it
>> is complete.
>>   - (nitpick: Trailing whitespaces in d/copyright; plz remove…
>> as you likely know wrap-and-sort(1) can do that for you.
>>
>
> Nit picked. Everything is taken care of as well. We have a mix of: BSL-1,
> Apache, MIT and GPL-3 :)
>
>
>> (for the todo list -- not needed for this upload -- embedded code
>> library: fastlz)
>>   This library is intended to be copied in the source;
>>   - that copy  seems to be rather old. Maybe ask upstream to update
>> to some more recent version?
>>   - Possibly fastlz should be pacakged… A file search seems to
>> indicate that there would be other pacakges benefiting from this as
>> well.
>>   - Check for more details: https://wiki.debian.org/EmbeddedCopies
>>   - It seems only be used in the demo; if you dont use the demo in any
>> way,
>> you could Files-Exclude the demo and be done. This would also fix the
>> font
>> issue.
>>
>>
> fastlz is just for the demo and we do not currently ship the demo, so I'm
> not worried about this. Upstream is aware of this and they rather embed
> than use submodules, though I did push them to use cmake, so perhaps I can
> convince them to use cmake's fetch content instead? They are
> primarly focused on premake though. The Demo is not made here, so nothing
> to Exclude. :)
>
>
>> (can be done later too; no blocker for this upload:)
>> I see a tests folder… Would it make sense to run them in autopkgtsts?
>>
>
> This one I didn't do, but I can add this later. Is that okay?
>
>
>> please review your package and remove the moreinfo tag when ready.
>>
>
> Cool, thanks! :)
>
> Cheers,
> Bret
>

Bug#951855: RFA: gammu -- mobile phone management utility

[Bastian Germann]

Control: retitle -1 ITA: gammu -- mobile phone management utility
Control: owner -1 Boian Bonev 

Boian has uploaded a new gammu version at 
https://mentors.debian.net/package/gammu/

Bug#996735: Wrong filename in error message: plocate.db is corrupt or an old version; please rebuild it.

[Trent W. Buck]

Package: plocate
Version: 1.1.8-2
Severity: minor

I noticed plocate always reports a broken locatedb as "plocate.db", even when 
the filename is something else:

twb@hera[Desktop]$ LOCATE_PATH=$PWD/test.mlocatedb  locate 'tinyssh*deb'
plocate.db is corrupt or an old version; please rebuild it.

twb@hera[Desktop]$ locate 'tinyssh*deb'
[no output]

Clearly the broken file there is called "test.mlocatedb", not "plocate.db".

plocate should either not mention a filename, or
use the specific filename that had corruption/oldness.


Not really relevant to this bug report, but the context for this is:

  1. To reduce search load,
 I generate per-user locate databases on the NFS server, and
 tell clients to use them:

server$ sudo -H -u twb LC_MESSAGES=C nocache nice ionice -c3 chrt 
--idle 0 updatedb --require-visibility=no --output /home/twb/.locatedb 
--database-root /home/twb

client$ export LOCATE_PATH=/home/twb/.locatedb
client$ catfish   # or something else that calls locate(1).

  2. mlocate is gone in Debian 12, so
 I wanted to test if locate(1plocate) could read a database generated by 
updatedb(8mlocate).
 If it could, I wouldn't have to upgrade all clients and servers at once.
 (It can't, hence the error message about "corrupt or an old version".)


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages plocate depends on:
ii  libc6   2.32-4
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  liburing1   0.7-3
ii  libzstd11.4.8+dfsg-2.1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  nocache 1.1-1+b1
ii  powermgmt-base  1.36
ii  systemd-sysv247.3-6

-- no debconf information

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

Hi!

On 10/17/21 21:47, John Paul Adrian Glaubitz wrote:
> Since ruby3.0 used to build fine on ppc64el in the past, the easiest way would
> be to just bisect the issue. I can give it a try and see if I can find the
> problematic commit.

Ah, so the last successful build was 3.0.2-2 and the first failure was in 
3.0.2-3,
the only difference being the mipsel patch to fix an unaligned access.

However, 3.0.2-2 was built with gcc-10:

> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-2=1633362713=0

while 3.0.2-3 was built with gcc-11:

> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-3=1634169532=0

So, first we should try building with gcc-10 and see if that makes a difference.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996734: src:nim: fails to migrate to testing for too long: ftbfs on armhf

[Paul Gevers]

Source: nim
Version: 1.4.6+really1.4.2-2
Severity: serious
Control: close -1 1.4.8-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 993042

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:nim has been trying to migrate for 64 days
[2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996726: libkdecorations2-5v5 freeze KDE on login, general protection fault

[Patrick Franz]

Hi Jeroen,

if you are using Testing, you have an incomplete Plasma installation.
When you upgrade Plasma packages, be sure to always upgrade the entire 
stack at once.

We've uploaded a fix which should prevent this issue in the future. In 
the meantime, you can downgrade kdecoration to 5.21.5 by grabbing the 
debs from here: https://snapshot.debian.org/package/kdecoration/
4%3A5.21.5-2/


-- 
Med vänliga hälsningar

Patrick Franz

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[John Paul Adrian Glaubitz]

Hello Antonio!

On 10/17/21 20:57, Antonio Terceiro wrote:
> I'm copying the debian-powerpc list to see if anyone can help.
> 
> ruby3.0 fails to build on ppc64el. 4 test cases results in Segmentation
> faults.
> 
> I was able to reproduce this on the porter box, and the minimal test
> case, inside a build source tree, is this:
> 
> ./miniruby -e 'END {Process.kill :SEGV, $$}'

Since ruby3.0 used to build fine on ppc64el in the past, the easiest way would
be to just bisect the issue. I can give it a try and see if I can find the
problematic commit.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996733: src:ktorrent: fails to migrate to testing for too long: build-depends not satisfiable

[Paul Gevers]

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

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996732: src:kget: fails to migrate to testing for too long: build-depends not satisfiable

[Paul Gevers]

Source: kget
Version: 4:20.12.2-1
Severity: serious
Control: close -1 4:21.08.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996731: src:golang-github-go-macaron-i18n: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: golang-github-go-macaron-i18n
Version: 0.0~git20160612.0.ef57533-7
Severity: serious
Control: close -1 0.0~git20160612.0.ef57533-8
X-Debbugs-CC: jel...@debian.org
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:golang-github-go-macaron-i18n has been
trying to migrate for 64 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=golang-github-go-macaron-i18n




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996730: Certain menus don't work right when chrome is in the Normal Layer

[積丹尼 Dan Jacobson]

Package: icewm
Version: 2.8.0-1
Severity: grave

Are there any other users who can confirm
https://github.com/ice-wm/icewm/issues/62 ?

Bug#996729: src:git-annex: fails to migrate to testing for too long: ftbfs on armhf

[Paul Gevers]

Source: git-annex
Version: 8.20210223-2
Severity: serious
Control: close -1 8.20210903-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 994697

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:git-annex has been trying to migrate for
64 days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996672: SV: Bug#996672: linux-image-5.10.0-9-amd64: ite_cir floods syslog with receive overflow warning messages

[Salvatore Bonaccorso]

Hi Björn,

On Sun, Oct 17, 2021 at 05:40:43PM +, Björn Wiberg wrote:
> Hello Salvatore!
> 
> Many thanks for your reply!
> 
> I’m afraid I cannot switch to unstable (or ”mix”), and if I
> understand it correctly, the unsigned kernel from backports won’t
> boot if Secure Boot is being used (which is the case on this
> server)?

Right but i expect the signed packages to appear "soonish" as well.
The signing machinery needs to be triggered once the respective
linux-signed-{amd64,i386,arm64} are there. So we can afford to wait a
couple of days yet if you are open to test the bpo kernel version.
> 
> Not sure about the best way to go forward – should I attempt to
> report it upstream, or will you be doing so?

It would be best if you can report it directly, otherwise we the
kernel maintainers are the bottleneck, help from people actually able
to do tests is more than welcome :). The reason I asked to test as
well the bpo version is that this brings us nearer to mainline.

I checked possible commits in the driver, and there is not much
so I wanted to check if you can reproduce the issue still as well with
newer stable version or ideally even better with mainline directly.

https://git.kernel.org/linus/49e851de7e573529885fd1df4365e2459c6030ee
is already for fixing an issue at probe time, so not sure.

> Another option would of course be to wait and see if anything
> changes in future versions.  This bug report will still be
> searchable for others, and can be resurrected if needed.

>From my point of view keeping the list of bugs
https://bugs.debian.org/src:linux shorter than longer (with bugs where
we cannot really do something -- not to hide problems, but to have
them reported where it's more sensible, in many cases its just better
to handle upstream) is better.

So with the report downstream now with Debian, there should go along
at least a reporting upstream to narrow it down at the right place.

Hope this makes sense.

When you report it upstream, let us know as well in case we miss it.

Regards,
Salvatore

Bug#963041: Lagging behind several versions for snakemake - lots of failed tests in latest version

[Nilesh Patra]

On 10/18/21 12:13 AM, Rebecca N. Palmer wrote:

On 15/10/2021 14:46, Andreas Tille wrote:

Hi Rebecca

and whoever might care.  As usual snakemake is troublesome to upgrade.
I have injected the latest version into Git but there are lots of
failed tests.  It would be great if someone could care about this.

I hadn't tried to upgrade snakemake because python-pulp is too old (#963041).


Yeah, snakemake has now moved to pulp 2.0. pulp had another rev-dep on congress 
which is now removed from archive.
pulp is maintained in openstack, and I sent out an email to zigo and 
openstack-list asking to upgrade,

cf: https://lists.debian.org/debian-openstack/2021/10/msg1.html


The test failures look like this isn't the only problem, [...]


ACK.
Thanks a lot for your work!

Nilesh




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996728: bullseye-pu: package mrtg/2.17.7-2+deb11u1

[Joao Eriberto Mota Filho]

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

[ Reason ]
This update is not for a regression. I am the new maintainer of the mrtg. When
checking for spelling errors, I found two spelling errors in variables names in
the source code. These errors generated the bugs #995950 and #996090.

[ Impact ]
These spelling errors will break the program in some circumstances.

[ Tests ]
No tests were needed. It is a simple fix to follow the right names already in
source code. The upstream already approved and committed these fixes.

[ Risks ]
No risks, a trivial fix only.

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

[ Changes ]
Single fixes in variables names in source code.

[ Other info ]
No more info. Thanks.
diff -Nru mrtg-2.17.7/debian/changelog mrtg-2.17.7/debian/changelog
--- mrtg-2.17.7/debian/changelog2021-01-01 01:23:44.0 -0300
+++ mrtg-2.17.7/debian/changelog2021-10-17 15:50:42.0 -0300
@@ -1,3 +1,12 @@
+mrtg (2.17.7-2+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/: created two patches to fix spelling errors in source code.
+These spelling errors will break the program in some circumstances.
+  - deb11-01-fix-variable-name-cfgmaker.patch (Closes: #995950)
+  - deb11-02-fix-variable-name-MRTG_lib.patch (Closes: #996090)
+
+ -- Joao Eriberto Mota Filho   Sun, 17 Oct 2021 15:50:42 
-0300
+
 mrtg (2.17.7-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru mrtg-2.17.7/debian/patches/deb11-01-fix-variable-name-cfgmaker.patch 
mrtg-2.17.7/debian/patches/deb11-01-fix-variable-name-cfgmaker.patch
--- mrtg-2.17.7/debian/patches/deb11-01-fix-variable-name-cfgmaker.patch
1969-12-31 21:00:00.0 -0300
+++ mrtg-2.17.7/debian/patches/deb11-01-fix-variable-name-cfgmaker.patch
2021-10-17 15:50:42.0 -0300
@@ -0,0 +1,18 @@
+Description: fix an important spelling error in source code
+Author: Joao Eriberto Mota Filho 
+Bug-Debian: https://bugs.debian.org/995950
+Forwarded: https://github.com/oetiker/mrtg/pull/35
+Last-Update: 2021-10-17
+Index: mrtg-2.17.7/bin/cfgmaker
+===
+--- mrtg-2.17.7.orig/bin/cfgmaker
 mrtg-2.17.7/bin/cfgmaker
+@@ -956,7 +956,7 @@ sub DeviceInfo ($$$) {
+ my @variables = snmpwalk(v4onlyifnecessary($router, 
$ipv4only),$v3opt,'1.3.6.1.2.1.1'); # walk system
+ if (!(defined $variables[0])) {
+ # Do we need to fall back to IPv4?
+-my ($commmunity, $host) = ($1, $2) if ($router =~ /^(.*)@([^@]+)$/);
++my ($community, $host) = ($1, $2) if ($router =~ /^(.*)@([^@]+)$/);
+ if ( ( ! $ipv4only ) && ( $host !~ /^\[(.*)\]/) ) {
+ # Not using IPv4, not an IPv6 address, so a hostname
+ debug ('base',"No response using IPv6 for $router, trying again 
using IPv4");
diff -Nru mrtg-2.17.7/debian/patches/deb11-02-fix-variable-name-MRTG_lib.patch 
mrtg-2.17.7/debian/patches/deb11-02-fix-variable-name-MRTG_lib.patch
--- mrtg-2.17.7/debian/patches/deb11-02-fix-variable-name-MRTG_lib.patch
1969-12-31 21:00:00.0 -0300
+++ mrtg-2.17.7/debian/patches/deb11-02-fix-variable-name-MRTG_lib.patch
2021-10-17 15:50:42.0 -0300
@@ -0,0 +1,18 @@
+Description: fix an important mistake in variable name
+Author: Joao Eriberto Mota Filho 
+Bug-Debian: https://bugs.debian.org/996090
+Forwarded: https://github.com/oetiker/mrtg/pull/50
+Last-Update: 2021-10-17
+Index: mrtg-2.17.7/lib/mrtg2/MRTG_lib.pm
+===
+--- mrtg-2.17.7.orig/lib/mrtg2/MRTG_lib.pm
 mrtg-2.17.7/lib/mrtg2/MRTG_lib.pm
+@@ -1798,7 +1798,7 @@ sub populateconfcache ($) {
+  push @{$$confcache{___updated}}, $hostkey;
+ 
+ $SNMP_Session::suppress_warnings = $snmp_errlevel;
+-$Net_SNMP_util::supress_warnings = $net_snmp_errlevel;
++$Net_SNMP_util::suppress_warnings = $net_snmp_errlevel;
+ }
+ 
+ sub log2rrd ($$$) {
diff -Nru mrtg-2.17.7/debian/patches/series mrtg-2.17.7/debian/patches/series
--- mrtg-2.17.7/debian/patches/series   2021-01-01 01:23:44.0 -0300
+++ mrtg-2.17.7/debian/patches/series   2021-10-17 15:50:42.0 -0300
@@ -6,3 +6,5 @@
 dont_create_varlockmrtg.patch
 cfgmaker_debian_workdir.patch
 iptables-accounting_linewrap.patch
+deb11-01-fix-variable-name-cfgmaker.patch
+deb11-02-fix-variable-name-MRTG_lib.patch

Bug#996727: ITP: ciftools-java -- Java library to read and write CIF files

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org

* Package name: ciftools-java
  Version : 3.0.0
  Upstream Author : Sebastian Bittrich
* URL : https://github.com/rcsb/ciftools-java
* License : Expat
  Programming Lang: Java
  Description : Java library to read and write CIF files

CIFTools implements reading and writing of CIF files as well as their
efficiently encoded counterpart, called BinaryCIF.
The idea is to have a robust, type-safe implementation for the handling of
CIF files which does not care about the origin of the data: both conventional
text-based and binary files should be handled the same way.

This library is needed as a dependency for biojava5-live, which is a packaging
aim of Debian med team.
It will be team-maintained inside the Debian java team.

Bug#996726: libkdecorations2-5v5 freeze KDE on login, general protection fault

[Jeroen Tirry]

Package: libkdecorations2-5v5
Version: 4:5.23.0-2

After upgrade from version 4:5.21.5-2, after login the KDE session 
freezes completly.

The mouse pointer still moves, but the spinning circle stops.

From the journalctl:

Oct 17 20:45:37 kernel: traps :kde5[4854] general protection fault 
ip:7f5eb66ed510 sp:7ffdef9478d0 error 0 in 
libkdecorations2.so.5.23.0[7f5eb66df000+f000]


Debian/testing
SMP Debian 5.14.9-2

Greetings,

Jeroen

Bug#993904: Adding amdgcn-mesa-mesa3d back to libclc build

[Jordan Justen]

Hopefully this merge-request can help fix #993904 & #995069.

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/74


signature.asc
Description: signature

Bug#996725: src:cherrypy3: fails to migrate to testing for too long: blocked by mysql-8.0 which won't be allowed to migrate

[Paul Gevers]

Source: cherrypy3
Version: 8.9.1-8
Severity: serious
Control: close -1 18.6.1-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:cherrypy3 has been trying to migrate for
64 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 blocked by the migration of pytest-services, which
itself is blocked because of mysql-8.0. The Release Team blocks
mysql-8.0 because we don't want to support the two stacks (MariaDB and
MySQL) and Debian testing has MariaDB.

Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[Antonio Terceiro]

Source: ruby3.0
Version: 3.0.2-4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
X-Debbugs-CC: debian-powe...@lists.debian.org

I'm copying the debian-powerpc list to see if anyone can help.

ruby3.0 fails to build on ppc64el. 4 test cases results in Segmentation
faults.

I was able to reproduce this on the porter box, and the minimal test
case, inside a build source tree, is this:

./miniruby -e 'END {Process.kill :SEGV, $$}'

The actual build failures are:

>   1) Failure:
> TestBugReporter#test_bug_reporter_add 
> [/<>/test/-ext-/bug_reporter/test_bug_reporter.rb:24]:
> pid 111637 killed by SIGSEGV (signal 11)
> | -:1: [BUG] Segmentation fault at 0x0b880001b415
> | ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [powerpc64le-linux-gnu]
> | 
> | -- Control frame information ---
> | c:0003 p: s:0012 e:11 CFUNC  :kill
> | c:0002 p:0021 s:0006 e:05 EVAL   -:1 [FINISH]
> | c:0001 p: s:0003 E:c0 (none) [FINISH]
> | 
> | -- Ruby level backtrace information 
> | -:1:in `'
> | -:1:in `kill'
> | 
> | -- C level backtrace information ---
> .
> 
> 1. [2/2] Assertion for "stderr"
>| Expected /Sample bug reporter: 12345/
>| to match
>|   "-- Control frame information 
> ---\n"+
>|   "c:0003 p: s:0012 e:11 CFUNC  :kill\n"+
>|   "c:0002 p:0021 s:0006 e:05 EVAL   -:1 [FINISH]\n"+
>|   "c:0001 p: s:0003 E:c0 (none) [FINISH]\n\n"+
>|   "-- Ruby level backtrace information 
> \n"+
>|   "-:1:in `'\n"+
>|   "-:1:in `kill'\n\n"+
>|   "-- C level backtrace information 
> ---\n"
>| after 4 patterns with 125 characters.
> 
>   2) Failure:
> TestRubyOptions#test_segv_loaded_features 
> [/<>/test/ruby/test_rubyoptions.rb:757]:
> pid 119318 killed by SIGSEGV (signal 11)
> | -e:1: [BUG] Segmentation fault at 0x0b880001d216
> | ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [powerpc64le-linux-gnu]
> | 
> | -- Control frame information ---
> | c:0003 p: s:0012 e:11 CFUNC  :kill
> | c:0002 p:0016 s:0006 e:05 BLOCK  -e:1 [FINISH]
> | c:0001 p: s:0003 E:001240 (none) [FINISH]
> | 
> | -- Ruby level backtrace information 
> | -e:1:in `block in '
> | -e:1:in `kill'
> | 
> | -- C level backtrace information ---
> .
> 
> 1. [2/2] Assertion for "stderr"
>| <""> expected but was
>| <"-- C level backtrace information 
> ---\n">.
> 
>   3) Failure:
> TestRubyOptions#test_segv_setproctitle 
> [/<>/test/ruby/test_rubyoptions.rb:771]:
> pid 119319 killed by SIGSEGV (signal 11)
> | -e:1: [BUG] Segmentation fault at 0x0b880001d217
> | ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [powerpc64le-linux-gnu]
> | 
> | -- Control frame information ---
> | c:0003 p: s:0012 e:11 CFUNC  :kill
> | c:0002 p:0029 s:0006 e:05 EVAL   -e:1 [FINISH]
> | c:0001 p: s:0003 E:001a80 (none) [FINISH]
> | 
> | -- Ruby level backtrace information 
> | -e:1:in `'
> | -e:1:in `kill'
> | 
> | -- C level backtrace information ---
> .
> 
> 1. [2/2] Assertion for "stderr"
>| <""> expected but was
>| <"-- C level backtrace information 
> ---\n">.
> 
>   4) Failure:
> TestRubyOptions#test_segv_test 
> [/<>/test/ruby/test_rubyoptions.rb:751]:
> pid 119320 killed by SIGSEGV (signal 11)
> | -e:1: [BUG] Segmentation fault at 0x0b880001d218
> | ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [powerpc64le-linux-gnu]
> | 
> | -- Control frame information ---
> | c:0003 p: s:0012 e:11 CFUNC  :kill
> | c:0002 p:0015 s:0006 e:05 EVAL   -e:1 [FINISH]
> | c:0001 p: s:0003 E:001870 (none) [FINISH]
> | 
> | -- Ruby level backtrace information 
> | -e:1:in `'
> | -e:1:in `kill'
> | 
> | -- C level backtrace information ---
> .
> 
> 1. [2/2] Assertion for "stderr"
>| <""> expected but was
>| <"-- C level backtrace information 
> ---\n">.
> 
> Finished tests in 784.310094s, 26.8248 tests/s, 3410.9162 assertions/s.
> 21039 tests, 2675216 assertions, 4 failures, 0 errors, 107 skips
> 
> ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) 
> [powerpc64le-linux-gnu]
> make[2]: *** [uncommon.mk:800: yes-test-all] Error 4


The full build log is available from:
http://qa-logs.debian.net/2021/10/17/ruby3.0.log

A list of current common problems and possible solutions is available at

Bug#996723: src:python-pluggy: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: python-pluggy
Version: 0.13.0-6
Severity: serious
Control: close -1 0.13.0-7
X-Debbugs-CC: jel...@debian.org
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-pluggy has been trying to migrate
for 64 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-pluggy




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: python-volatile
Version: 2.1.0-2
Severity: serious
Control: close -1 2.1.0-3
X-Debbugs-CC: jel...@debian.org 
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-volatile has been trying to migrate
for 64 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-volatile




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996721: src:pyzbar: fails to migrate to testing for too long: uploader build arch:all binaries

[Paul Gevers]

Source: pyzbar
Version: 0.1.8-2
Severity: serious
Control: close -1 0.1.8-3
X-Debbugs-CC: jel...@debian.org
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:pyzbar has been trying to migrate for 64
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=pyzbar




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996720: src:ruby-protocol-http: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: ruby-protocol-http
Version: 0.20.0-2
Severity: serious
Control: close -1 0.22.5-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 995353

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:ruby-protocol-http has been trying to
migrate for 64 days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996718: Disregard,

[Charles Laws]

It says right up front on their web page that they aren't going EOL until
July 1, 2024. Apologies, please close out this bug and disregard. Not
enough coffee yet today.

Regards,

Charles

Bug#996718: Disregard,

[Charles Laws]

It says right up front on their web page that they aren't going EOL
until July 1, 2024. Apologies, please close out this bug and disregard. Not
enough coffee yet today.

Regards,

Charles

Bug#996719: "Provides: elpa-dash-functional" needs to be versioned to satify elpa-helpful

[Paul Gevers]

Package: elpa-dash
Version: 2.19.0+dfsg-1
Severity: important

Dear maintainers,

With the upload of 2.19.0+dfsg-1 elpa-dash took over
elpa-dash-functional via a Provides. However, elpa-helpful has a
versioned dependency on elpa-dash-functional. Policy 7.5 says this:
"""
If the Provides field does not specify a version number, it will
not satisfy versioned dependencies or violate versioned Conflicts or
Breaks.
"""

Please add a version to the Provides, otherwise elpa-dash can't take
over elpa-dash-functional in testing [1].

Paul

[1] https://release.debian.org/britney/update_output.txt

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

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

Versions of packages elpa-dash depends on:
ii  dh-elpa-helper  2.0.9
ii  emacsen-common  3.0.4

elpa-dash recommends no packages.

elpa-dash suggests no packages.

Bug#996107: budgie-desktop: compatibility with mutter 41

[David Mohammed]

It has now been uploaded and accepted into unstable. Thx.

On Sun, 17 Oct 2021, 14:27 Simon McVittie,  wrote:

> Control: severity -1 serious
> Control: block 996607 by -1
>
> On Mon, 11 Oct 2021 at 11:25:27 +0100, Simon McVittie wrote:
> > When we have mutter reliably passing tests on arm* in experimental (I'm
> > still fighting with this) and we get the go-ahead from the release team,
> > budgie-desktop will need a re-upload to unstable for the transition.
>
> The new version of mutter is now in unstable. Please upload the changes
> from 10.5.3-3 to unstable, or tell debian-gtk-gn...@lists.debian.org if
> you need someone to do a NMU.
>
> Thanks,
> smcv
>

Bug#732696: Updated os-prober script for Haiku OS

[Alexander G. M. Smith]

Package: os-prober
Version: 1.79
Tags: patch

There's an updated version of the /usr/lib/os-probes/mounted/83haiku 
file now available for the os-prober package.  Hope it can be added to 
the latest Debian distribution!


I've gone through the previous work everyone here has done on making an 
83haiku script and fixed it up to detect the current versions of Haiku 
as well as all the older ones.  Added some internal documentation too.  
It's now got an official home on the Haiku source git repository:


https://git.haiku-os.org/haiku/tree/3rdparty/os_probe/83haiku

There's also a related README.md in the same directory, which I'll 
reproduce here:


# os-probe for the Haiku Computer Operating System

This is the Linux "os-probes" file to detect Haiku OS and to 
automatically add

it to the GRUB boot menu.  Mostly relevant for x86 BIOS based computers.

Copy the 83haiku file to your Linux system in the os-probes subdirectory,
usually (in Fedora at least) it will be 
/usr/libexec/os-probes/mounted/83haiku

You can find older 83haiku versions in the repository history, though the
latest should be able to detect older (pre-package manager) Haiku too.

Then regenerate the GRUB boot configuration file.  This will happen
automatically the next time your kernel is updated.  To do it manually,
for old school MBR BIOS boot computers, the command is
`grub2-mkconfig --output /boot/grub2/grub.cfg`
If it doesn't find the Haiku partitions, try manually mounting them in Linux
and rerun the grub command.

Computers using the newer UEFI boot system have a EFI/HAIKU/BOOTX64.EFI file
that you manually install to your EFI partition, and booting is done
differently, so you don't need this 83Haiku file for them.  See
[UEFI Booting Haiku](https://www.haiku-os.org/guides/uefi_booting/) instead.

The original seems to have come from Debian and was written by François 
Revol.

It's in the
[Debian os-prober 
package](https://packages.debian.org/search?keywords=os-prober).

There's also a big discussion about updating it in
[Debian Bug Report 
#732696](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732696).
Latest version is now at 
https://git.haiku-os.org/haiku/tree/3rdparty/os_probe


_AGMS20210927_

Bug#996718: modsecurity-apache: Upstream source changes,

[CharlesL]

Source: modsecurity-apache
Severity: normal
Tags: upstream

Dear Maintainer,

Hello,

It appears as if the upstream source for this package has changed. The debian
documentation lists modsecurity.org, which is now a simple landing page that
says to go to https://github.com/SpiderLabs/ModSecurity for more information.

Regards,

Charles


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

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

Bug#996674: libminidns-java: please make the build reproducible

[tony mancill]

Hi Chris,

On Sun, Oct 17, 2021 at 08:57:30AM +0100, Chris Lamb wrote:
> Source: libminidns-java
> Version: 1.0.0-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0] we noticed that
> libminidns-java could not be built reproducibly.
> 
> This is because it generates a .jar file that contains an
> "org.minidns/version" file that can look like this:
> 
> 1.0.0 (non git build 2021-10-17)
> 
> That is, it includes the current build date. A patch is attached that
> makes it look like this:
> 
> 1.0.0 (Debian)
> 
>  [0] https://reproducible-builds.org/

Thank you for the bug report and the patch.  Sunil had previously
committed a very similar patch to the packaging repo to address the
issue with the reproducible build but it hadn't been uploaded yet.  I
have done that now.  (And apologies for the duplicated efforts.)

Cheers,
tony


signature.asc
Description: PGP signature

Bug#995198: wsjtx: No transmit audio

[tony mancill]

On Mon, Oct 04, 2021 at 07:32:28AM -0700, tony mancill wrote:
> On Mon, Sep 27, 2021 at 09:07:49PM +0100, Hilary Snaden wrote:
> > Package: wsjtx
> > Version: 2.5.0~rc6+repack-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > The program generates no audio output on transmit, in any mode. This is 
> > identical to a bug which I reported on the previous version of wsjtx, under 
> > Debian bullseye/sid (though on different hardware).
> > 
> > The program works satisfactorily on receive.
> > 
> > The similar (in function) program fldigi generates good, clean audio on 
> > transmit on the same machine.
> 
> I am not experiencing any problems with transmit with this version of
> wsjtx.  Can you provide more details about your configuration and/or
> hardware?

I believe I encountered the same behavior you are reporting with wsjtx
2.5.0+repack-1.  wsjtx receives audio as expected, but nothing is
generated during transmit or tune, and PTT (via CAT for my rig) doesn't
even switch my radio into TX.

This same version and configuration of wsjtx worked correctly a week
ago.  I run testing/unstable and update every few days, so my initial
thought was that the change in behavior was due to an apt update of the
system.

I tried reconfiguring and reinstalling wsjtx, and then uninstalling
pulseaudio, to no effect.  However, rebuilding wsjtx against unstable in
a clean chroot and installing the resulting deb results in a fully
functioning wsjtx again.

At this point, I couldn't tell you whether it is library dependency of
wsjtx or something in the build environment that has changed and is
addressed by the rebuild.  However, it is reproducible - meaning my
locally build .deb works consistently, and reinstalling the .deb from
the archive (I believe generated by this build [1]) fails to generate TX
audio.

I am tempted to upload a new source package to trigger a rebuild to see
if that solves the problem with the deb in the archive.  Perhaps wsjtx
got caught up in a transition causing this subtle failure?

Christoph or Dave, do you have any suggestions on how to track down the
root cause?

Thank you,
tony

[1] 
https://buildd.debian.org/status/fetch.php?pkg=wsjtx=armhf=2.5.0%2Brepack-1=1632820833=0


signature.asc
Description: PGP signature

Bug#996428: OpenSSH upgrade problem (8.0 => 8.4)

[John David Anglin]

Yes, that also worked for me.

Dave

On 2021-10-17 2:00 p.m., John Paul Adrian Glaubitz wrote:

Control: tags -1 +patch

Hello!

On 10/17/21 19:38, John Paul Adrian Glaubitz wrote:

This should be reported upstream. Chances are higher that upstream will see
the bug and fix it.

I'll forward it.

The attached patch fixes the problem for me and allows the build to succeed on
hppa without any problems. I have also opened a pull request upstream [1].

Adrian


[1] 
https://github.com/Yubico/libfido2/pull/444/commits/257e380a0e8433d9579606580bdaaba15e802c5c.



--
John David Anglin  dave.ang...@bell.net

Bug#996428: OpenSSH upgrade problem (8.0 => 8.4)

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hello!

On 10/17/21 19:38, John Paul Adrian Glaubitz wrote:
> This should be reported upstream. Chances are higher that upstream will see
> the bug and fix it.
> 
> I'll forward it.

The attached patch fixes the problem for me and allows the build to succeed on
hppa without any problems. I have also opened a pull request upstream [1].

Adrian

> [1] 
> https://github.com/Yubico/libfido2/pull/444/commits/257e380a0e8433d9579606580bdaaba15e802c5c.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From 257e380a0e8433d9579606580bdaaba15e802c5c Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Sun, 17 Oct 2021 19:49:00 +0200
Subject: [PATCH] cmake: Add -Werror when checking host compiler for
 -fstack-protector

Since calling GCC with -fstack-protector will just generate a warning
when it doesn't support the flag on a given host architecture, we need
to add -Werror so the warning turns into an error and cause the cmake
check HAVE_STACK_PROTECTOR_ALL to fail when the flag is not supported.

fixes gh#443
---
 CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ed3819e..64013ca 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -80,7 +80,7 @@ if(NOT MSVC)
 endif()
 
 check_c_compiler_flag("-Wshorten-64-to-32" HAVE_SHORTEN_64_TO_32)
-check_c_compiler_flag("-fstack-protector-all" HAVE_STACK_PROTECTOR_ALL)
+check_c_compiler_flag("-Werror -fstack-protector-all" HAVE_STACK_PROTECTOR_ALL)
 
 check_include_files(cbor.h HAVE_CBOR_H)
 check_include_files(endian.h HAVE_ENDIAN_H)
-- 
2.30.2

Bug#996078: gnome-shell-pomodoro: does not declare compatibility with GNOME Shell 41

[Tobias Frost]

Control: severity -1 normal
Control: retitle -1 gnome-shell-pomodoro: tighten dependency on g-shell

Hi Simon,

I've just uploaded 0.20.0 which declares compatiblity. However, I have missed
your suggestion regarding the Depends line, so I'll only downgrade the
severity but keep this bug open for another upload

-- 
tobi

Bug#996717: python-matplotlib-data: please Depends on fonts-dejavu | ttf-bitstream-vera

[Martin-Éric Racine]

Package: python-matplotlib-data
Version: 3.3.4-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

python-matplotlib-data currently has a hard Depends on ttf-bitstream-vera. 
Nowadays most people would instead install the Deja Vu fonts, which took off 
where Vera left and added glyphs for more languages. It would thus be desirable 
for python-matplotlib-data to Depends on fonts-dejavu | ttf-bitstream-vera 
instead.

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

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

Versions of packages python-matplotlib-data depends on:
pn  fonts-lyx   
pn  ttf-bitstream-vera  

python-matplotlib-data recommends no packages.

python-matplotlib-data suggests no packages.

- -- Configuration Files:
/etc/matplotlibrc [Errno 2] Tiedostoa tai hakemistoa ei ole: '/etc/matplotlibrc'

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFsYiYACgkQrh+Cd8S0
17Y2gA/+OaQrUSsoA2S0DlhEIVZ3mjntrOuRHCrSPsPUclm2mndt6N4HACzQRubd
rvC/Dyj++T2AsnIL66S6wWhxizhrWqK1gYs7p3MDbcgebwndPiL6z/y6sjGrdm/5
d2kGJa/wLwL6Txa8lXvv3E4jkOhBZidMBUGpe29gD9KdwdkASKzKAFOEYRG0y/l2
HRfKJMMyMKh8BV1xeUHSVkIt4tG1/mhrBaHFKuI9ON6T48EM6dwV9USmLLWVyfp1
9V8/9JA/n76iI62f1iX6VZtStadJwq2dxkDkIABFvdvboNKAVwVvDEkt8Yj9n4tt
DWhmKg5isP4kIqLuAqyZ2OaF2+FupyLzh/V5DC70Tsw33Sir3YgnDr1g57Pk1iyI
UNHpLiWg+Tbh7cZ2G1ss6w4wk5pjYufzW5uixDcn7PGA7CEg8gec57bccNSOiBUC
If4BfSpRI8dOJGYoE09z3cZB+Jmi2+N+W7KJ9THSem8ceGx3ZW4OyWhTHwHPWt1V
OiOyxLiAI/QlIJ92u8LM914PWLzKpcvHlxDqR5v73xopsqU7GRLTWLG+BhrSOCMe
S7xG0+2lp3NC6owL69w5R5/vTnv2C7q0ObyjziZCpAT02v6nX7O5uEsDBK2Z3Dvx
1WRwkU+/B6ujLgL4oVfqNhQ8zKe+vF9qkGvpXKjLqrFqmq9W5DU=
=+KXi
-END PGP SIGNATURE-

Bug#996672: SV: Bug#996672: linux-image-5.10.0-9-amd64: ite_cir floods syslog with receive overflow warning messages

[Björn Wiberg]

Hello Salvatore!

Many thanks for your reply!

I’m afraid I cannot switch to unstable (or ”mix”), and if I understand it 
correctly, the unsigned kernel from backports won’t boot if Secure Boot is 
being used (which is the case on this server)?

Not sure about the best way to go forward – should I attempt to report it 
upstream, or will you be doing so?

Another option would of course be to wait and see if anything changes in future 
versions.
This bug report will still be searchable for others, and can be resurrected if 
needed.

Best regards
Björn

Bug#996716: pyopencl: autopkgtest regression: test-depends on removed package

[Paul Gevers]

Source: pyopencl
Version: 2021.2.2-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
pyopencl   from testing2021.2.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The package
python3-pyopencl-dbg was dropped in the latest upload but the test still
depends on it. On top of that, the package also FTBFS on armel, armhf
and i386 (all 32-bits archs).

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/arm64/p/pyopencl/15992067/log.gz

autopkgtest [23:21:15]: testbed dpkg architecture: arm64
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) autopkgtest-satdep:arm64 < 0 @iU K Nb Ib >
Broken autopkgtest-satdep:arm64 Depends on python3-pyopencl-dbg:arm64 <
none @un H >
  Considering python3-pyopencl-dbg:arm64 1 as a solution to
autopkgtest-satdep:arm64 -2
  Removing autopkgtest-satdep:arm64 rather than change
python3-pyopencl-dbg:arm64
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  libmpdec3 libpython3.9-stdlib media-types python3.9
Suggested packages:
  python3.9-venv python3.9-doc
The following packages will be REMOVED:
  autopkgtest-satdep
The following NEW packages will be installed:
  libmpdec3 libpython3.9-stdlib media-types python3.9
0 upgraded, 4 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 2,258 kB of archives.
After this operation, 8,833 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian testing/main arm64 media-types all
4.0.0 [30.3 kB]
Get:2 http://deb.debian.org/debian testing/main arm64 libmpdec3 arm64
2.5.1-2 [84.4 kB]
Get:3 http://deb.debian.org/debian testing/main arm64
libpython3.9-stdlib arm64 3.9.7-4 [1,663 kB]
Get:4 http://deb.debian.org/debian testing/main arm64 python3.9 arm64
3.9.7-4 [480 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 2,258 kB in 0s (30.1 MB/s)
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 13210 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
Selecting previously unselected package media-types.
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 13210 files and directories currently installed.)
Preparing to unpack .../media-types_4.0.0_all.deb ...
Unpacking media-types (4.0.0) ...
Selecting previously unselected package libmpdec3:arm64.
Preparing to unpack .../libmpdec3_2.5.1-2_arm64.deb ...
Unpacking libmpdec3:arm64 (2.5.1-2) ...
Selecting previously unselected package libpython3.9-stdlib:arm64.
Preparing to unpack .../libpython3.9-stdlib_3.9.7-4_arm64.deb ...
Unpacking libpython3.9-stdlib:arm64 (3.9.7-4) ...
Selecting previously unselected package python3.9.
Preparing to unpack .../python3.9_3.9.7-4_arm64.deb ...
Unpacking python3.9 (3.9.7-4) ...
Setting up media-types (4.0.0) ...
Setting up libmpdec3:arm64 (2.5.1-2) ...
Setting up libpython3.9-stdlib:arm64 (3.9.7-4) ...
Setting up python3.9 (3.9.7-4) ...
Processing triggers for libc-bin (2.32-4) ...
autopkgtest: 

Bug#996428: OpenSSH upgrade problem (8.0 => 8.4)

[John Paul Adrian Glaubitz]

Hello!

On 10/14/21 00:14, John David Anglin wrote:
> There's a bug in the check for -fstack-protector-all:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996428

This should be reported upstream. Chances are higher that upstream will see
the bug and fix it.

I'll forward it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996715: node-regexpp: autopkgtest regression: MODULE_NOT_FOUND

[Paul Gevers]

Source: node-regexpp
Version: 3.2.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
node-regexpp   from testing3.2.0-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-regexpp/15981930/log.gz

autopkgtest [15:08:55]: test command1: [---
internal/modules/cjs/loader.js:406
throw e;
^

Error: Cannot find module
'/tmp/autopkgtest-lxc.68j86t4g/downtmp/build.5vP/src/index.js'
at createEsmNotFoundErr (internal/modules/cjs/loader.js:842:15)
at finalizeEsmResolution (internal/modules/cjs/loader.js:835:15)
at trySelf (internal/modules/cjs/loader.js:400:12)
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:793:24)
at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at [eval]:1:1
at Script.runInThisContext (vm.js:120:18)
at Object.runInThisContext (vm.js:309:38) {
  code: 'MODULE_NOT_FOUND',
  path: '/tmp/autopkgtest-lxc.68j86t4g/downtmp/build.5vP/src/package.json'
}
autopkgtest [15:08:55]: test command1: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996595: nvidia-legacy-390xx-driver: NVIDIA service is not starting with the system

[Alessandro Reis de Alcântara]

Hi, Andreas.

I uninstalled every single package from nvidia and libnvidia again. Then I
reinstalled nvidia-legacy-390xx-driver. The libnvdia-cfg1 was installed
together again, I have no clue why But then, I removed the
libnvidia-cfg1 package. And then I was able to get the nvidia daemon up at
initialization.

I just had a problem starting the cinnamon. I had to modify the
"/usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf" to get it working
fine. The file had to be like this:


> *Section "OutputClass"*
> *Identifier "intel"*
> *MatchDriver "i915"*
> *Driver "modesetting"**EndSection*



> *Section "OutputClass"*
> *Identifier "nvidia"*
> *MatchDriver"nvidia-drm"*
> *Driver "nvidia"*
> *Option "AllowEmptyInitialConfiguration"*
> *Option "PrimaryGPU" "yes"*
> *Option "IgnoreDisplayDevices" "CRT"*
> *ModulePath "/usr/lib/nvidia/xorg"*
> *ModulePath "/usr/lib/xorg/modules"**EndSection*


Now i'm running the nvidia 390xx legacy on Debian 11. Thanks for the
support. Any issue related to freezing problems, I will let you know.

Regards,

Em sáb., 16 de out. de 2021 às 18:08, Alessandro Reis de Alcântara <
alessandror...@gmail.com> escreveu:

> I uninstall all nvidia related package, before The installation to send
> The bug report... I used The following commands to uninstall everything:
>
> apt remove - -purge nvida* libnvidia*
> apt autoremove
>
> After this, i rebooted and then installed Just The
> nvidia-legacy-390xx-driver.
>
> I dont know why The libnvidia-config was installed together...
>
> I'll verify your recomendations and give you a feedback.
>
> Thanks a lot.
>
> Em sáb., 16 de out. de 2021 17:33, Andreas Beckmann 
> escreveu:
>
>> Thanks.
>>
>> Please also send the output of
>>
>> update-alternatives --display glx
>> update-alternatives --display nvidia
>>
>> Do you know why you have libnvidia-cfg1 (from the current, not the
>> legacy driver)installed? That probably stems from the attempt to install
>> nvidia-settings for the current driver.
>> (You also have libnvidia-legacy-390xx-cfg1 installed.)
>>
>> If you uninstall libnvidia-cfg1 everything should be back to normal again.
>>
>> Andreas
>>
>

-- 
Alessandro Reis de Alcântara
+55 (31) 99476-6758

Bug#996699: chatty: Cross-building fails to resolve libpurple-dev

[Travis Wrightsman]

Package: chatty
Version: 0.4.0-1
Severity: serious
Justification: fails to build from source
Tags: ftbfs upstream

Chatty fails to cross-build due to a dependency resolution error for the
libpurple-dev package.

I'm not sure this is a chatty-specific bug but I'm also not sure where
else to place it.

It occurs on Debian Salsa builds:
https://salsa.debian.org/DebianOnMobile-team/chatty/-/jobs/1940649#L1475

It also occurs when using git-buildpackage to cross-build for my (arm64)
PinePhone from my (amd64) laptop.

$ BUILDER=pbuilder DIST=bookworm git-pbuilder create
$ echo 
'PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-apt"' > 
~/.pbuilderrc
$ BUILDER=pbuilder gbp buildpackage --git-pbuilder 
--git-pbuilder-options="--host-arch arm64" --git-dist=bookworm
[...]
Building dependency tree...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:/build/chatty_0.4.0-1.dsc:arm64 : Depends: libpurple-dev:arm64 but 
it is not installable
E: Unable to correct problems, you have held broken packages.
E: pbuilder-satisfydepends failed.
[...]

Chatty builds successfully on the PinePhone using git-buildpackage.

Bug#996714: gnome-pass-search-provider: fails to migrate to testing for too long

[Boyuan Yang]

Source: gnome-pass-search-provider
Version: 0.0~20191115+da2db41-1
Severity: serious
X-Debbugs-CC: naturesha...@debian.org

As of today, package gnome-pass-search-provider failed to migrate to Debian
testing for 490 days. This is due to non-source-only upload blocking testing
migration. Please consider fixing this using a new source-only upload.

Thanks,
Boyuan Yang


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

Bug#962993: gnome-shell-pomodoro: Broken UI when display screen blacks out

[Tobias Frost]

Control: tags -1 fixed-upstream pending
Control: forwarded -1 
https://github.com/gnome-pomodoro/gnome-pomodoro/issues/561

Seems to be the linked issue and is reported to be fixed with 0.19.1.
Marking as pending, as I'm packaging 0.20.0 right now..

-- 
tobi

Bug#919479: gnome-shell-pomodoro: multimonitor setup: pomodoro break 'breaks' gnome shell, restart needed

[Tobias Frost]

Control: tags -1 unreproducible
Control: close -1   

On Sun, 11 Aug 2019 17:12:13 -0700 Joseph Herlant  wrote:
> Package: gnome-shell-pomodoro
> Followup-For: Bug #919479
> 
> Hi Wim,
> 
> Can you reproduce it in newer versions of the package?
> What windows manager do you use when you have the problem?
> Is it only happening with 3 screens?
> I've been running that app for a long time on dual screen using i3 and haven't
> faced the problem you're describing but I'm using testing.
> 
> Thanks for your help,
> Joseph
>

Same here, cannot reproduce. As there was no follow up from the bug reporter,
closing the bug now.

--
tobi

Bug#991177: libdebian-installer: reproducible builds: Embeds build path in libdebian-installer-extra.so.*

[Vagrant Cascadian]

On 2021-10-17, Cyril Brulebois wrote:
> Vagrant Cascadian  (2021-10-16):
>> On 2021-07-16, Cyril Brulebois wrote:
>> > I know we haven't always been stellar when it comes to merging repro
>> > build work, sorry about that. Any chance you could chase^Wremind us
>> > about such issues once Bullseye (r0, and maybe r1) is out the door?
>> 
>> The long-awaited requested reminder... is here! :)
>
> Thanks, the patch no longer applies cleanly (some fuzz, can be applied
> trivially anyway, no need to resubmit), and I do wonder whether Samuel's
> commit[1] doesn't make the issue go away on its own: CFLAGS is now
> inherited from the environment, and I'm seeing the flag you're proposing
> to add in various Makefile (and related) files after a build.
>
>  1. 
> https://salsa.debian.org/installer-team/libdebian-installer/-/commit/4b679de89592dccb6446637498e619738ee1
>
> Any chance you could check whether current master is fine, please?

Yes, that fixes the issue, great!

Just need to add the appropriate Closes line in debian/changelog and be
done with it, then. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#996700: gpaste: unsatisfiable dependency on gnome-shell

[Jérémy Lal]

Le dim. 17 oct. 2021 à 15:39, Simon McVittie  a écrit :

> Package: gpaste
> Version: 3.42.0-2
> Severity: grave
> Justification: renders package unusable
> Control: found -1 3.42.0-1
> Control: block 996607 by -1
>
> gpaste/3.42.0-1 and gpaste/3.42.0-2 have:
>
> > Depends: ..., gnome-shell (>= 3.41), gnome-shell (<< 3.42~), ...
>
> This is not satisfiable in unstable. gnome-shell jumped from version 3.38.x
> to version 40.x with the introduction of the new versioning scheme in
> GNOME 40, and the current version is 41.x, both of which are >= 3.42~.
>
> If the intention is to declare that this version of gpaste will only work
> with GNOME 41, then the way to write that is:
>
> Depends: ..., gnome-shell (>= 41), gnome-shell (<< 42~), ...
>
> I would also have expected that dependency to go on the
> gnome-shell-extension-gpaste binary package rather than on the gpaste
> binary package, but I don't use gpaste myself, so perhaps I'm missing
> some other reason why it needs a strict dependency.
>


Totally right. Reuploading a fix.

Jérémy

Bug#996713: firmware-brcm80211: firmware becomes non-responsive while running as an access point on RPI4

[Andres Salomon]

Package: firmware-brcm80211
Version: 20210315-3
Severity: normal

This bug is mostly for documentation purposes.

When running a raspberry pi 4b as an access point, after a random
period of time the on-chip firmware will crash and leave the wireless
driver (brcmfmac) unusable until the chip is reset. The rest of
the kernel is still fine, but the driver is unusable.

Here's the firmware version that's in Debian 11 (bullseye):

[   16.365079] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.clm_blob
[   16.373443] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 
2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b

Here's one example of the firmware crashing: 

Oct 12 17:40:06 wifi1 kernel: [263542.782712] brcmfmac: mmc_submit_one: CMD53 
sg block write failed -84
Oct 12 17:40:06 wifi1 kernel: [263542.785401] brcmfmac: brcmf_sdio_txfail: sdio 
error, abort command and terminate frame
Oct 12 17:40:52 wifi1 kernel: [263589.238359] brcmfmac: brcmf_sdio_hdparse: seq 
77: max tx seq number error
Oct 12 17:40:54 wifi1 kernel: [263591.678597] brcmfmac: brcmf_sdio_hdparse: seq 
240: max tx seq number error
Oct 12 17:40:54 wifi1 kernel: [263591.681542] brcmfmac: brcmf_sdio_hdparse: seq 
241: max tx seq number error
Oct 12 17:40:54 wifi1 kernel: [263591.684591] brcmfmac: brcmf_sdio_hdparse: seq 
242: max tx seq number error
Oct 12 17:40:54 wifi1 kernel: [263591.687778] brcmfmac: brcmf_sdio_hdparse: seq 
252: max tx seq number error
Oct 12 17:40:54 wifi1 kernel: [263591.690801] brcmfmac: brcmf_sdio_hdparse: seq 
253: max tx seq number error
Oct 12 17:40:54 wifi1 kernel: [263591.693780] brcmfmac: brcmf_sdio_hdparse: seq 
254: max tx seq number error
Oct 12 17:41:36 wifi1 kernel: [263633.105406] brcmfmac: brcmf_sdio_hdparse: seq 
171: max tx seq number error
Oct 12 17:50:57 wifi1 kernel: [264194.196126] brcmfmac: mmc_submit_one: CMD53 
sg block write failed -84
Oct 12 17:50:57 wifi1 kernel: [264194.199127] brcmfmac: brcmf_sdio_txfail: sdio 
error, abort command and terminate frame
Oct 12 17:52:12 wifi1 kernel: [264268.874931] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct 12 17:52:14 wifi1 kernel: [264271.434963] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct 12 17:52:14 wifi1 kernel: [264271.438681] ieee80211 phy0: 
brcmf_cfg80211_get_station: GET STA INFO failed, -110

Here's another one:

Oct  9 15:59:31 wifi1 kernel: [1543849.606976] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct  9 15:59:34 wifi1 kernel: [1543852.169907] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct  9 15:59:34 wifi1 kernel: [1543852.173684] ieee80211 phy0: 
brcmf_cfg80211_get_station: GET STA INFO failed, -110
Oct  9 15:59:42 wifi1 kernel: [1543860.103164] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct  9 15:59:44 wifi1 kernel: [1543862.663196] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct  9 15:59:44 wifi1 kernel: [1543862.666950] ieee80211 phy0: 
brcmf_cfg80211_get_station: GET STA INFO failed, -110
Oct  9 15:59:57 wifi1 kernel: [1543875.207367] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Oct  9 15:59:59 wifi1 kernel: [1543877.767429] ieee80211 phy0: 
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110

Notice how the crashes happened 3 days apart. The crash prior
to Oct 9th happened a full month before, so I no longer have
logs. I haven't found any kind of pattern in timing.

I'm currently trying a newer Cypress firmware (from unstable), so
we'll see if it also has the same crash.

Bug#926711: gnome-shell-pomodoro: workaround for notification volume going to 100%

[Tobias Frost]

Control: tags -1 unreproducible
Control: close -1

Triaging this big, I cannot reproduce it with 0.20.0, which will be uploaded
soon to sid.

Closing therefore.

--
tobi

Bug#991177: libdebian-installer: reproducible builds: Embeds build path in libdebian-installer-extra.so.*

[Cyril Brulebois]

Vagrant Cascadian  (2021-10-16):
> On 2021-07-16, Cyril Brulebois wrote:
> > I know we haven't always been stellar when it comes to merging repro
> > build work, sorry about that. Any chance you could chase^Wremind us
> > about such issues once Bullseye (r0, and maybe r1) is out the door?
> 
> The long-awaited requested reminder... is here! :)

Thanks, the patch no longer applies cleanly (some fuzz, can be applied
trivially anyway, no need to resubmit), and I do wonder whether Samuel's
commit[1] doesn't make the issue go away on its own: CFLAGS is now
inherited from the environment, and I'm seeing the flag you're proposing
to add in various Makefile (and related) files after a build.

 1. 
https://salsa.debian.org/installer-team/libdebian-installer/-/commit/4b679de89592dccb6446637498e619738ee1

Any chance you could check whether current master is fine, please?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#996712: libcache-memcached-fast-perl: autopkgtest failure on armhf: Fetched all keys / Match results

[Paul Gevers]

Source: libcache-memcached-fast-perl
Version: 0.27-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=libcache-memcached-fast-perl

https://ci.debian.net/data/autopkgtest/testing/armhf/libc/libcache-memcached-fast-perl/15943042/log.gz

t/nowait.t ..
1..5
ok 1 - A reference of type 'HASH' isa 'HASH'
not ok 2 - Fetched all keys

#   Failed test 'Fetched all keys'
#   at t/nowait.t line 37.
#  got: '0'
# expected: '1000'
not ok 3 - Match results

#   Failed test 'Match results'
#   at t/nowait.t line 42.
#  got: '0'
# expected: '1000'
ok 4
ok 5
# Looks like you failed 2 tests of 5.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/5 subtests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996711: src:cglm: fails to migrate to testing for too long: FTBFS on i386 and s390x

[Paul Gevers]

Source: cglm
Version: 0.7.9-1
Severity: serious
Tags: sid bookworm ftbfs
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:cglm has been trying to migrate for 64
days [2]. Hence, I am filing this bug. The current version FTBFS on i386
and s390x.

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 tagged this bug to only affect sid and bookworm, so it doesn't
affect (old-)stable.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996710: lintian: false positive missing-dep-for-interpreter when package depends on nodejs:any

[Yadd]

Le 17/10/2021 à 18:18, Felix Lechner a écrit :
> Hi Yadd,
> 
> On Sun, Oct 17, 2021 at 9:03 AM Yadd  wrote:
>>
>> it seems that lintian doesn't consider nodejs:any as a valid interpreter
>> for nodejs packages.
> 
> This is easily fixed (and I will explain why in the commit) but I
> cannot find a package on which to test the fix. Where did you see the
> issue, please?
> 
> Kind regards
> Felix Lechner

hi,

you can test acorn (experimental) for example. I just pushed a new
version but problem exists in the previous experimental version

https://salsa.debian.org/js-team/acorn

Thanks !
Yadd

Bug#996710: lintian: false positive missing-dep-for-interpreter when package depends on nodejs:any

[Felix Lechner]

Hi Yadd,

On Sun, Oct 17, 2021 at 9:03 AM Yadd  wrote:
>
> it seems that lintian doesn't consider nodejs:any as a valid interpreter
> for nodejs packages.

This is easily fixed (and I will explain why in the commit) but I
cannot find a package on which to test the fix. Where did you see the
issue, please?

Kind regards
Felix Lechner

Bug#932969: gprbuild: i686-w64-mingw32 compiler not found by gprconfig

[Stephen Kitt]

Control: reassign -1 gcc-mingw-w64

Hi,

On Sat, 16 Oct 2021 19:13:45 +0200, Nicolas Boulenguez 
wrote:
> The easyest solution would be for gnat-mingw-w64-i686 to install a
> symbolic link like the gnat-$arch for official architectures.
> 
> Stephen, is it possible to add a line like
>   usr/bin/gnat-mingw-w64-i686-gnatgccusr/bin/gnat-mingw-w64-i686-gcc
> to
>   debian/gnat-mingw-w64-i686.links ?

Yes, I can take care of that! I’m reassigning the bug to gcc-mingw-w64.

Regards,

Stephen


pgpSK8Lty2QTK.pgp
Description: OpenPGP digital signature

Bug#977285: new version

[Thorsten Alteholz]

Hi Davide,

thanks a lot for your report.

Unfortunately upstream released version 1.4.0.5 within the tarball of 
version 1.4.0. 
As Debian is guided by the version of the tarball, the version of the 
package seems to be outdated. But the changes for 1.4.0.5 are already part 
of the 1.4.0 package.


   Thorsten

Bug#996594: ardour shows no GUI after asking for and confirming session (core dumped)

[Tjeerd J. Pinkert]

Dear maintainer,

I tried to find the related source file in the ardour source package, 
but it was not found. Thus my conclusion, where is the source file?


There are several unrelated packages that have this source file in their 
list (https://codesearch.debian.net/search?q=freeverb.cpp or 
FreeVerb.cpp). I deinstalled lmms (including wine and a lot of i386 
packages) and the metapackage multimedia-audio-plugins, which depends on 
a lot of packages. This resolved the problem.


Trying to recreate the problem by reinstalling packages piecewise 
reinstalling multimedia-soundsynthesis recreated the problem (narrowing 
in, it's reproducible).


After installing package naspro-bridges (0.5.1-3) core dumps occurred 
seemingly at the same place during starting ardour:


Jack: JackClient::kGraphOrderCallback
no more csLADSPA plugins
lo server running on 14637
malloc_consolidate(): invalid chunk size
Aborted (core dumped)
user@machine:~$

Jack: JackClient::kGraphOrderCallback
no more csLADSPA plugins
lo server running on 14308
double free or corruption (fasttop)
Aborted (core dumped)
user@machine:~$

package naspro-bridges purged and continued installing the other 
packages separately. No other package caused problems. The strange thing 
being that the assertion failure did not come back.


How is it best to proceed? Shall I make a bugreport with the 
naspro-bridges package?


Best regards,


Tjeerd Pinkert


On 10/15/21 22:24, T. J. Pinkert wrote:

Package: ardour
Version: 1:6.5.0+ds0-1
Severity: important
X-Debbugs-Cc: t.j.pink...@alumnus.utwente.nl

Dear Maintainer,

I recently upgraded to Debian bullseye. Ardour was working fine on the
oldstable.
Upon starting ardour it gets as far as showing the session selection dialogue,
but then crashes.

Up till now I have not found a solution for the problem. However, when I
started ardour from the commandline I got the following debug information as
last few lines of the output:
...
no more csLADSPA plugins
ardour-6.5.0~ds0: src/freeverb/revmodel.cpp:37: void revmodel::setrate(int):
Assertion `rate <= TUNING_MAX_SAMPLE_RATE' failed.
Aborted (core dumped)
user@machine:~$

The sample rate for the selected session is 48 kHz for professional audio.
I think this must be a bug in the software. Ardour is supposed to be capable of
running at 48 kHz or higher sampling rates.

Best regards,


Tjeerd Pinkert

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

* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

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


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

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

Versions of packages ardour depends on:
ii  ardour-data   1:6.5.0+ds0-1
ii  ardour-lv2-plugins1:6.5.0+ds0-1
ii  libarchive13  3.4.3-2+b1
ii  libasound21.2.4-1.1
ii  libatkmm-1.6-1v5  2.28.0-3
ii  libaubio5 0.4.9-4+b4
ii  libc6 2.31-13+deb11u2
ii  libcairo2 1.16.0-5
ii  libcairomm-1.0-1v51.12.2-4
ii  libcurl3-gnutls   7.74.0-1.3+b1
ii  libcwiid1 0.6.91-2+b1
ii  libdbus-1-3   1.12.20-2
ii  libfftw3-single3  3.3.8-2
ii  libfluidsynth22.1.7-1.1
ii  libfontconfig12.13.1-4.2
ii  libgcc-s1 10.2.1-6
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libglibmm-2.4-1v5 2.64.2-2
ii  libgtk2.0-0   2.24.33-2
ii  libgtkmm-2.4-1v5  1:2.24.5-4
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  liblilv-0-0   0.24.12-2
ii  liblo70.31-1
ii  liblrdf0  0.6.1-2
ii  libltc11  1.3.1-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libpangoft2-1.0-0 1.46.2-3
ii  libpangomm-1.4-1v52.42.1-1
ii  libpulse0 14.2-2
ii  libqm-dsp01.7.1-4
ii  librubberband21.9.0-1
ii  libsamplerate00.2.1+ds0-1
ii  libsigc++-2.0-0v5 

Bug#996710: lintian: false positive missing-dep-for-interpreter when package depends on nodejs:any

[Yadd]

Package: lintian
Version: 2.109.0
Severity: normal

Hi,

it seems that lintian doesn't consider nodejs:any as a valid interpreter
for nodejs packages. I thinks a regexp should remove ":.*" for each
interpreter

Cheers,
Yadd

Bug#996709: ITP: rime-prelude -- Rime Input Method Engine basic configuration files

[Boyuan Yang]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: rime-prelude
  Version : 0.0~git20210627.3de303f-1
  Upstream Author : Gong Chen 
* URL : https://github.com/rime/rime-essay
* License : LGPL-3.0
  Programming Lang: N/A
  Description : Rime Input Method Engine basic configuration files

 RIME is the acronym of Rime Input Method Engine.
 .
 RIME is a lightweight, extensible input method engine supporting various
input
 schematas including glyph-based input methods, romanization-based input
methods
 as well as those for Chinese dialects. It has the ability to compose phrases
 and sentences intelligently and provide very accurate traditional Chinese
 output. RIME's cross-platform core library is written in C++, and can work
 consistently on different platforms with OS-specific wrappers.
 .
 This package provides the basic configuration files for RIME.

This package will be part of the effort to migrate from
https://tracker.debian.org/pkg/brise to https://github.com/rime/plum by
splitting individual data packages and maintaining them individually.

I plan to maintain this package under Debian Input Method Team:
https://salsa.debian.org/input-method-team/rime-prelude .

Thanks,
Boyuan Yang


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

Bug#996622: mdadm prints warning on every boot due to evifarfs on non-EFI system

[Patrick Häcker]

Hi Felix,

> > force_load efivarfs || true
>
> That invokes the following function when the initramfs is
> created (from /usr/share/initramfs-tools/hook-functions):
>
> # force_load module [args...]
> force_load()
> {
> manual_add_modules "$1"
> echo "${@}" >>"${DESTDIR}/conf/modules"
> }
>
> The hook could check if the module exists, but it seems more robust to
> do it at boot time.
>
> Is this a bug in mdadm or in initramfs-tools?

I am not sure. I think it's a question of expectation. When you have a UEFI
system and the efivarfs module cannot be loaded, then you'd expect the error.
However, when you have a non-UEFI system, you do not expect any message at
all. So I think it's mdadm's job to state this policy and ideally initramfs-
tools would make it as simple as possible to do so.

Maybe it's possible for mdadm to execute something similar to
manual_add_modules (being part of force_load in hook-functions) itself, which
does the right thing? If that works, it might be possible to rewrite this in a
more general way and make it available in initramfs-tools.

It guess, this is not the first time, that a module must be loaded
conditionally in the initramfs. Maybe bringing the issue to debian-devel might
lead to the solution.

Kind regards
Patrick


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

Bug#996708: open-iscsi: unusable with default installation

[Yangfl]

Package: open-iscsi
Version: 2.1.4-2

Hi,

After installing open-iscsi without modifying any configuration,
iscsiadm can't do any discovery using `iscsiadm -m discovery -t
sendtargets -p `, which seemly caused by failure to start
iscsid. Some log:

➜  ~  _ systemctl status iscsid.service
● iscsid.service - LSB: iSCSI initiator daemon (iscsid)
 Loaded: loaded (/etc/init.d/iscsid; generated)
 Active: active (exited) since Sun 2021-10-17 23:27:38 CST; 32s ago
TriggeredBy: ● iscsid.socket
   Docs: man:systemd-sysv-generator(8)
Process: 1586 ExecStart=/etc/init.d/iscsid start (code=exited, status=0/SUC>
CPU: 27ms

10月 17 23:27:38 desktop systemd[1]: Starting LSB: iSCSI initiator daemon (iscs>
10月 17 23:27:38 desktop iscsid[1593]: iSCSI logger with pid=1594 started!
10月 17 23:27:38 desktop iscsid[1586]: Starting iSCSI initiator daemon: iscsid
10月 17 23:27:38 desktop systemd[1]: Started LSB: iSCSI initiator daemon (iscsi>
➜  ~  _ systemctl status iscsid.socket
● iscsid.socket - Open-iSCSI iscsid Socket
 Loaded: loaded (/lib/systemd/system/iscsid.socket; enabled; vendor preset:>
 Active: active (running) since Sun 2021-10-17 23:26:35 CST; 1min 44s ago
   Triggers: ● iscsid.service
   Docs: man:iscsid(8)
 man:iscsiadm(8)
 Listen: @ISCSIADM_ABSTRACT_NAMESPACE (Stream)
 CGroup: /system.slice/iscsid.socket

10月 17 23:26:35 desktop systemd[1]: Listening on Open-iSCSI iscsid Socket.
➜  ~  _ systemctl status open-iscsi.service
● open-iscsi.service - Login to default iSCSI targets
 Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; vendor pr>
 Active: active (exited) since Sun 2021-10-17 23:26:43 CST; 1min 43s ago
   Docs: man:iscsiadm(8)
 man:iscsid(8)
Process: 745 ExecStart=/sbin/iscsiadm -m node --loginall=automatic (code=ex>
Process: 746 ExecStart=/lib/open-iscsi/activate-storage.sh (code=exited, st>
   Main PID: 746 (code=exited, status=0/SUCCESS)
CPU: 13ms

10月 17 23:26:43 desktop systemd[1]: Starting Login to default iSCSI targets...
10月 17 23:26:43 desktop iscsiadm[745]: iscsiadm: No records found
10月 17 23:26:43 desktop systemd[1]: Finished Login to default iSCSI targets.
➜  ~  ps aux|grep iscsid
user2451  0.0  0.0   6412  2204 pts/0S+   23:33   0:00
grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS
--exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn
--exclude-dir=.idea --exclude-dir=.tox iscsid

After stopping those services `systemctl stop iscsid.service;
systemctl stop iscsid.socket` and start iscsid manually, `iscsiadm -m
discovery` successes as expected.