Bug#1018861: adduser --gid fails with "group '-1' does not exist"

[Boris Kolpackov]

Package: adduser
Version: 3.128

I get the following error when first adding a group and then trying
to add a user with this group:

# addgroup --gid 2000 build
# adduser --uid 2000 --gid 2000 --home /build --gecos "" --disabled-password 
build
Adding user `build' ...
Use of uninitialized value $grname in printf at /usr/sbin/adduser line 625.
Adding new user `build' (2000) with group ` (-1)' ...
useradd: group '-1' does not exist
adduser: `/sbin/useradd -d /build -g -1 -s /bin/bash -u 2000 build' returned 
error code 6. Exiting.

The group appears to have been added successfully:

# getent group 2000
build:x:2000:

Also, the same command but which uses --ingroup instead of --gid
succeeds:

# adduser --uid 2000 --ingroup build --home /build --gecos "" 
--disabled-password build
Adding user `build' ...
Adding new user `build' (2000) with group `build (2000)' ...
Creating home directory `/build' ...
Copying files from `/etc/skel' ...
Adding new user `build' to supplemental / extra groups `users' ...
Adding user `build' to group `users' ...

I tried to look around in the adduser Perl script but couldn't see
anything obvious. This is using Debian testing (bookworm) and I see
that the adduser package hasn't changed since stable (bullseye) and
I definitely tried the same with an earlier snapshot of testing so
the issue is probable not in the script itself. Maybe in one of the
Perl modules?

Also, for completeness, this is running under systemd-nspawn -D --boot.
Let me know if you need me to run any tests in this environment. I have
it readily available.

Bug#1018859: rutsc: Please update to 1.63.0

[Carsten Schoenert]

Package: rutsc
Severity: wishlist

Dear Maintainer,

while trying to keep track of the current Thunderbird beta versions
within experimental I noticed the build is failing due rutsc is detected
as too old. The following output is getting produced starting with
Thunderbird 105.0b1.

 0:05.70 checking for rustc... /usr/bin/rustc
 0:05.70 checking for cargo... /usr/bin/cargo
 0:05.94 checking rustc version... 1.59.0
 0:05.95 checking cargo version... 1.56.0
 0:05.97 ERROR: Rust compiler 1.59.0 is too old.
 0:05.97
 0:05.97 To compile Rust language sources please install at least
 0:05.97 version 1.61.0 of the 'rustc' toolchain (or, if using nightly,
 0:05.97 at least one version newer than 1.61.0) and make sure it is
 0:05.97 first in your path.
 0:05.97
 0:05.97 You can verify this by typing 'rustc --version'.
 0:05.97
 0:05.97 If you have the 'rustup' tool installed you can upgrade
 0:05.97 to the latest release by typing 'rustup update'. The
 0:05.97 installer is available from https://rustup.rs/
 0:05.97

The current most stable marked version of rustc is 1.63.0, so could you
please update the rustc package to that version?

Thx & regards
Carsten


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

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

Bug#1018858: firefox-esr: Scrollbar behind fixed div clickable in responsive mode

[Justus Wilhelm Perlwitz]

Package: firefox-esr
Version: 91.13.0esr-1~deb11u1
Severity: normal
X-Debbugs-Cc: he...@justus.pw

Dear Maintainer,

* What led up to the situation?
I am creating a page that has a scrollable overflow-y. When I display a
fixed div overlay over it, the scrollbar is not clickable, normally.
Now, when entering responsive mode, the scrollbar becomes clickable and
I can scroll around in the underlying div.

* What exactly did you do (or not do) that was effective (or
 ineffective)?
The bug can be reproduced in this tailwind play:
https://play.tailwindcss.com/9lNAma5EhI

* What was the outcome of this action?
The scrollbar became clickable/draggable.

* What outcome did you expect instead?
The scrollbar should not be clickable/draggable.


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads)
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) (ignored: LC_ALL 
set to en_US.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 firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u3
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.4-0+deb11u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  pulseaudio 14.2-2

-- no debconf information

Bug#898400: ITP: sccache - compiler cache for fast recompilation of C/C++/Rust code

[Jonas Smedegaard]

Hi Bill,

Quoting Blair Noctis (2022-08-31 22:12:48)
> Hi Jonas, was trying this too then saw your ITP, happy to help.

Great!


> I've manged to build a binary package, and using it on itself looks good
> (at least it didn't fail cargo build or cargo test).

That's good to know that the tool actually works - I hadn't found (i.e.
taken) time to play with the built binary package yet myself).


> Dependencies are updated and patched to keep up with crates.io versions.
> 
> That said, I'm using the debcargo-conf "toolchain" [1]. Does the team
> have some coordination on this?

Do you mean to say that you updated and patched the packaging that I
have already prepared, or that you started from scratch and needed to
essentially repeat (team-style) some parts of what I'd already done?

Please note that sccache is *not* maintained in the Rust team, as I
disagree with the method used (and mandated) within that team - which
seams to be *exactly* the "toolchain" that you are pointing to here.

If that doesn't discourage you from collaborating directly with me on
getting sccache into Debian, then great: Please have a look at what I've
already put together and tell me if any of it is not obvious to you...

If you prefer working same style as the Debian Rust team, then that's
great too: Please join that team (if you haven't already) and help
package some of the dependencies still missing in Debian, as listed at
https://salsa.debian.org/debian/sccache/-/blob/debian/latest/debian/TODO
but please then leave packaging of sccache itself to me.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1018802: localechooser: reproducible builds: locale and parallelism trigger reproducibility issues

[Philip Hands]

Vagrant Cascadian  writes:

> That attached patches fix this by passing --no-parallel to dh (parallism
> was probably introduced in the switch from debhelper compat 9 to 13),
> and by exporting LC_ALL=C.UTF-8 in debian/rules.

I've stuck this onto salsa:

  https://salsa.debian.org/philh/localechooser/-/commits/bug/1018802

which builds, and passed most of the tests:

  https://salsa.debian.org/philh/localechooser/-/pipelines/417953

which leads on to an openQA tests, where they also pass (apart from a
few that are broken in general at present):

https://openqa.debian.net/tests/overview?distri=debian=-salsa-417953%3Aphilh%3Alocalechooser%3Abug%2F1018802=13=salsa_testing

and where one can see here that it really is the patched version of
localechooser that's in use:

  https://openqa.debian.net/tests/73247#step/rescue/53

so that all looks fine to me.

Of course, the "most" regarding passing tests does not include repotest,
which is a bit of a shame, as I had hoped to be able to show a before
and after with that test passing, but currently the repotest script
includes a '*.deb' that ignores udebs and so finds nothing to test :-/

I'll sort out an upload soon -- just thought I'd mention what I've done
so far to save others duplicating effort.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1015733: ghc: ABI reproducibility broken in 9.0.2

[Paul Gevers]

Hi all,

On Tue, 19 Jul 2022 17:51:07 -0400 Scott Talbert  wrote:

Haskell ABI reproducibility is broken in ghc 9.0.2.  If you rebuild the
ghc-9.0.2-3 package repeatedly, the library packages that it provides (e.g.,
libghc-array-dev, libghc-base-dev, etc.) will have different hashes.

Making this RC because it makes it impossible to rebuild the ghc package
without rebuilding all 1000+ Haskell packages at the same time.


Ping. Can this please be looked at? This is affecting more and more 
packages that can't migrate to testing (and I [Release Team hat on] 
don't want ghc in testing with this bug).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018857: bullseye-pu: package dpkg/1.20.12

[Guillem Jover]

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

[ Reason ]

This update backports multiple fixes from unstable for RC bugs and fixes
broken behavior. It makes the dpkg-fsys-usrunmess script more robust,
fixes mishandling of versioned symbols due to output changes in objdump,
fixes the removal-on-upgrade conffile support, and adds support for the
ARC arch. There's also a tiny fix for the Dutch translated man pages.

[ Impact ]

* The dpkg-shlibdeps problem would cause wrong dependency information
  which could lead to programs unable to run-time link due to missing
  symbols.

* The removal-on-upgrade conffile support could end up removing
  pathnames owned by other packages.

* The dpkg-fsys-usrunmess changes make the script more robust, to
  reduce the potential for breakage and avoid known problematic
  scenarios that can leave the system messed up, requiring arduous
  recovery.

* The arc arch porters cannot introduce it properly as the infr runs
  on stable which currently does not know about it.

[ Tests ]

* The fix for dpkg-shlibdeps can be verified by running that version
  on unstable/testing and building cppcheck. (I have pending adding
  a minimal test case into the test suite in git main though.)

* The removal-on-upgrade conffile fix contains functional tests.

* The dpkg-fsys-usrunmess has been run on a merged-/usr system with
  the various conditions and it works as expected.

* The arc arch addition is trivial, but still contains some test suite
  coverage.

[ Risks ]

All these fixes have been in unstable/testing for months now, w/ no
reported regressions. The biggest changes are for the
removal-on-upgrade conffile support, but that ends up being more of
moving code around, and the changes to dpkg-fsys-usrunmess. But none
are that big anyway.

[ Checklist ]

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

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem


dpkg-1.20.11-1.20.12.debdiff.xz
Description: application/xz

Bug#1018856: src:magic-haskell: fails to migrate to testing for too long: part of unfinshed ghc transition

[Paul Gevers]

Source: magic-haskell
Version: 1.1-9
Severity: serious
Control: close -1 1.1-10
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:magic-haskell has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package is part of 
the unfinished ghc transition.


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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1

[Paul Wise]

On Thu, 2022-09-01 at 10:29 +0800, Paul Wise wrote:

> Thanks for that. For the record, I'm not involved in the package and
> the bug report was only a drive-by bug for an unimportant issue,
> so I don't have any intention to work on this myself.

PS: I just noticed the package is orphaned, so anyone, including
yourself, can update the package fixing any issues. Please read the
following links and you will get an idea of how to get this issue fixed
in Debian. There are active sponsors who accept updates to orphaned
packages, so you shouldn't have any problem getting yours accepted.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmus-vs-qa-uploads
https://mentors.debian.net/intro-maintainers/
https://mentors.debian.net/sponsors/rfs-howto/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1018854: buster-pu: package dpkg/1.19.9

[Guillem Jover]

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

[ Reason ]

This update fixes the same regression (introduced in the security fix
in dpkg 1.19.8) that was fixed in bullseye for dpkg 1.20.11 (#1014206).

[ Impact ]

This introduced a regression when unpacking source packages.

[ Tests ]

As lintian does not appear to have had the failing test there, I did
the following quick verification:

  - Download a source package.
  - Unpack the orig tarball.
  - Remove all write permissions from all files.
  - Repack and amend the .dsc
  - Unpacking with dpkg-source -x does not work in buster, works with
the fixed package.

(And I'll be adding a functional test in dpkg 1.21.x to cover this…)

[ Risks ]

The code has been in unstable, bookworm and bullseye for a while. The
patch applied cleanly, and it's minimal.

[ Checklist ]

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

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru dpkg-1.19.8/.dist-version dpkg-1.19.9/.dist-version
--- dpkg-1.19.8/.dist-version   2022-05-24 13:40:09.0 +0200
+++ dpkg-1.19.9/.dist-version   2022-09-01 03:40:03.0 +0200
@@ -1 +1 @@
-1.19.8
+1.19.9
diff -Nru dpkg-1.19.8/ChangeLog dpkg-1.19.9/ChangeLog
--- dpkg-1.19.8/ChangeLog   2022-05-24 13:40:09.0 +0200
+++ dpkg-1.19.9/ChangeLog   2022-09-01 03:40:03.0 +0200
@@ -1,3 +1,137 @@
+commit e2254431dca4eccb5125c21cb7299090e6725b3a
+Author: Guillem Jover 
+Date:   Thu Sep 1 03:43:20 2022 +0200
+
+Release 1.19.9
+
+ debian/changelog | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+commit e1e6c85841778630facbefa1b8ed928668283d79
+Author: Guillem Jover 
+Date:   Thu Sep 1 03:40:03 2022 +0200
+
+po: Regenerate .pot files and merge .po files with them
+
+ dselect/po/bs.po| 2 +-
+ dselect/po/ca.po| 2 +-
+ dselect/po/cs.po| 2 +-
+ dselect/po/da.po| 2 +-
+ dselect/po/de.po| 2 +-
+ dselect/po/dselect.pot  | 4 ++--
+ dselect/po/el.po| 2 +-
+ dselect/po/es.po| 2 +-
+ dselect/po/et.po| 2 +-
+ dselect/po/eu.po| 2 +-
+ dselect/po/fr.po| 2 +-
+ dselect/po/gl.po| 2 +-
+ dselect/po/hu.po| 2 +-
+ dselect/po/id.po| 2 +-
+ dselect/po/it.po| 2 +-
+ dselect/po/ja.po| 2 +-
+ dselect/po/ko.po| 2 +-
+ dselect/po/nb.po| 2 +-
+ dselect/po/nl.po| 2 +-
+ dselect/po/nn.po| 2 +-
+ dselect/po/pl.po| 2 +-
+ dselect/po/pt.po| 2 +-
+ dselect/po/pt_BR.po | 2 +-
+ dselect/po/ro.po| 2 +-
+ dselect/po/ru.po| 2 +-
+ dselect/po/sk.po| 2 +-
+ dselect/po/sv.po| 2 +-
+ dselect/po/tl.po| 2 +-
+ dselect/po/vi.po| 2 +-
+ dselect/po/zh_CN.po | 2 +-
+ dselect/po/zh_TW.po | 2 +-
+ man/po/dpkg-man.pot | 4 ++--
+ po/ast.po   | 2 +-
+ po/bs.po| 2 +-
+ po/ca.po| 2 +-
+ po/cs.po| 2 +-
+ po/da.po| 2 +-
+ po/de.po| 2 +-
+ po/dpkg.pot | 4 ++--
+ po/dz.po| 2 +-
+ po/el.po| 2 +-
+ po/eo.po| 2 +-
+ po/es.po| 2 +-
+ po/et.po| 2 +-
+ po/eu.po| 2 +-
+ po/fr.po| 2 +-
+ po/gl.po| 2 +-
+ po/hu.po| 2 +-
+ po/id.po| 2 +-
+ po/it.po| 2 +-
+ po/ja.po| 2 +-
+ po/km.po| 2 +-
+ po/ko.po| 2 +-
+ po/ku.po| 2 +-
+ po/lt.po| 2 +-
+ po/mr.po| 2 +-
+ po/nb.po| 2 +-
+ po/ne.po| 2 +-
+ po/nl.po| 2 +-
+ po/nn.po| 2 +-
+ po/pa.po| 2 +-
+ po/pl.po| 2 +-
+ po/pt.po| 2 +-
+ po/pt_BR.po | 2 +-
+ po/ro.po| 2 +-
+ po/ru.po| 2 +-
+ po/sk.po| 2 +-
+ po/sv.po| 2 +-
+ po/th.po| 2 +-
+ po/tl.po| 2 +-
+ po/tr.po| 2 +-
+ po/vi.po| 2 +-
+ po/zh_CN.po | 2 +-
+ po/zh_TW.po | 2 +-
+ scripts/po/ca.po| 2 +-
+ scripts/po/de.po| 2 +-
+ scripts/po/dpkg-dev.pot | 4 ++--
+ scripts/po/es.po| 2 +-
+ scripts/po/fr.po| 2 +-
+ scripts/po/pl.po| 2 +-
+ scripts/po/ru.po| 2 +-
+ scripts/po/sv.po| 2 +-
+ 82 files changed, 86 insertions(+), 86 deletions(-)
+
+commit d0f3775a0334261b793acc87c56146df7bb3fc66
+Author: Guillem Jover 
+Date:   Sat Jun 4 05:48:21 2022 +0200
+
+

Bug#950993: orage: calendar window doesn't work anymore

[Paul Wise]

On Wed, 2022-08-31 at 14:05 +0200, B wrote:

> my bad, I did not remember that the sound comes at the exact alarm time
> (my parm: open alarm window 1 minute before its triggering time), sounds
> came right at the good time.
> 
> So, everything's ferpect.

Sounds like we can probably close this bug, but could you confirm that
it works with the Debian package? It sounds like you are running Debian
stable so you will need to build yourself a backport of the package.
Please ensure you uninstall the upstream build that you did first tho.
The orage package isn't yet in testing, so you will need to download
the source package from unstable instead, but these docs should help:

https://wiki.debian.org/SimpleBackportCreation

> BTW thanks to whoever reintroduced this very useful software into XFCE.

For Debian that would be Unit 193 from the Debian XFCE team:

https://tracker.debian.org/news/1351348/accepted-orage-4160-1-source-all-amd64-into-unstable-unstable/

For upstream that would be Erkki Moorits and other contributors:

https://gitlab.xfce.org/apps/orage/-/commits/master

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1018855: gtkpod: unmaintained upstream

[Jeremy Bicha]

Source: gtkpod
Version: 2.1.5-9
Severity: important
Tags: bookworm trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs

gtkpod's last upstream release was in 2015. The iPods were
discontinued in 2017. iPod Touches weren't discontinued until 2022 but
I don't know if gtkpod supported the IPod Touch, especially newer
versions.

At one point, various music player apps in Debian uses gtkpod but none
do currently.

For gtkpod to have a future in Debian, someone will need to fork the
project and continue development.

Thank you,
Jeremy Bicha

Bug#1018853: gtkpod: depends on libanjuta which is unmaintained upstream

[Jeremy Bicha]

Source: gtkpod
Version: 2:3.34.0-6
Severity: important
Tags: bookworm trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1018852 by -1

Anjuta's last upstream release was 3 years ago. It has been archived
which means bug reports, translation updates, and bug fixes are no
longer being accepted. [1]

In contrast, GNOME Builder is very actively maintained and is GNOME's
recommended integrated development app.

In this situation, we would normally remove anjuta, but it also
provides a library that is used by gtkpod.

[1] https://gitlab.gnome.org/GNOME/anjuta

Thank you,
Jeremy Bicha

Bug#1018852: anjuta: unmaintained upstream

[Jeremy Bicha]

Source: anjuta
Version: 2:3.34.0-6
Severity: important
Tags: trixie sid upstream wontfix
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: unmaintained-upstream oldlibs

Anjuta's last upstream release was 3 years ago. It has been archived
which means bug reports, translation updates, and bug fixes are no
longer being accepted. [1]

In contrast, GNOME Builder is very actively maintained and is GNOME's
recommended integrated development app.

Ideally, we would remove anjuta but it also provides a library which
is used by other Debian packages.

[1] https://gitlab.gnome.org/GNOME/anjuta

Thank you,
Jeremy Bicha

Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1

[Paul Wise]

On Wed, 2022-08-31 at 17:10 +0200, Thomas Uhle wrote:

> Now I have attached the patch to upstream's bug ticket as requested
> after recovering my Sourceforge account.  Anyway, I don't have hope
> that there is going to happen much.  Yet it would be good if Debian's
> libdbus-c++-* packages could be updated at least.

Thanks for that. For the record, I'm not involved in the package and
the bug report was only a drive-by bug for an unimportant issue,
so I don't have any intention to work on this myself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1018726: RM: anjuta -- RoM; unmaintained IDE, use gnome-builder instead

[Jeremy Bicha]

Control: tags -1 +moreinfo

Oh, I need to figure out gtkpod first.

Thank you,
Jeremy Bicha

Bug#1018801: stdx-allocator ftbfs: assertThrown failed: No Exception was thrown.

[Matthias Klumpp]

Am Mi., 31. Aug. 2022 um 03:01 Uhr schrieb Steve Langasek
:
>
> Source: stdx-allocator
> Version: 3.1.0~beta.2-3
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic
>
> Hi Matthias,
>
> After fixing up stdx-allocator build-deps so that they're installable,
> stdx-allocator fails to build from source due to a test failure:
>
> [...]

Hah! I need to test this, but this *may* just be related to removing
the dip1008 flag from the mir-core flags list entirely - it may be
needed after all.
Or this is completely unrelated to that and a completely different bug
- unfortunately, I can only really dive into this at the weekend...

Thanks!
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018796: mir-core: FTBFS with gdc: unrecognized commandline option -preview=dip1008

[Matthias Klumpp]

Am Mi., 31. Aug. 2022 um 01:09 Uhr schrieb Steve Langasek
:
>
> Package: mir-core
> Version: 1.1.111-1
> Severity: serious
> Tags: patch
> Justification: ftbfs
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic ubuntu-patch
>
> Hi Matthias,
>
> The mir-core package is failing to build on all gdc archs in unstable
> because meson.build includes a compiler option, '-preview=dip1008', which is
> ldc-specific and not understood by gdc.
>
> Patching this option out lets the package build on all archs, including
> those using ldc, so it doesn't appear to be needed.

How odd, that particular DIP was apparently postponed:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
Not sure if we can just drop the flag, but I assume the answer is yes,
in which case we should forward this patch upstream as well.
If not, then the Meson code needs to pass "-fpreview=dip1008" (instead
of -preview...) to the compiler if its identifier is gnu.
Thanks for looking into this!

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018795: dh-dlang: support for mapping dpkg-buildflags for ldc but it's not used

[Matthias Klumpp]

Hi!

Am Mi., 31. Aug. 2022 um 00:57 Uhr schrieb Steve Langasek
:
>
> Package: dh-dlang
> Version: 0.6.5
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic ubuntu-patch
>
> Hi Matthias,
>
> I noticed in Ubuntu when trying to rebuild most packages against ldc 1.30.0
> that they were now failing to build with current dh-dlang, because including
> /usr/share/dh-dlang/dlang-flags.mk caused dpkg-buildflags' LDFLAGS to be
> exported and these flags are not understood by ldc (specifically:
> -Wl,-Bsymbolic-functions and -Wl,-z,relro on Ubuntu).  This can be seen in
> Debian in the failed build of gir-to-d:
>
> [...]
> ../meson.build:1:0: ERROR: Unable to detect linker for compiler `ldc2 
> -L=--version /tmp/tmpsh_a2h39.d -Wl,-z,relro -O -g -release -wi --allinst`
> stdout:
> stderr: ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 
> --help'
> ldc2: Did you mean '--icp-lto'?
> [...]
>
>   
> (https://buildd.debian.org/status/fetch.php?pkg=gir-to-d=amd64=0.22.0-3%2Bb1=1661202072=0)

So, this is actually a Meson regression, that is tracked as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017087 and already
fixed upstream, but sadly not yet resolved in Debian.
IMHO the right place to fix this issue is in Meson, and not to work
around it in dh-dlang, because the Meson fix will even work for
packages which don't use dh-dlang, although there also *should* not be
any harm in applying a workaround - however

> Paradoxically, there is support in dh-dlang for mapping these flags for ldc,
> but this support is not included automatically in dlang-flags.mk.

... AFAIR using this for LDFLAGS caused problems with other D tools (I
specifically recall dub), but this has been long ago and the D
toolchain was much buggier than it is today (yes, even more! :-P), so
maybe that issue was solved...

TBH, I genuinely don't know what the best course of action is here -
obviously we need the Meson regression fixed, but I'm not sure if we
should also apply this patch and possibly thereby mask future problems
(or create new ones, but we'd notice these rather quickly!).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018851: bash: long PS1 may or may not cause bad cursor positioning, depending on the position of a space

[Michael Gold]

Package: bash
Version: 5.2~rc2-2

Dear Maintainer,

I was seeing incorrect cursor behaviour when my PS1 prompt got long, and
was surprised to learn that merely moving a space character from after a
control sequence to before it fixed the problem.  Based on the man page,
I think I've used the "non-printing" escapes correctly.

Try this in an 80-character-wide terminal:
x159=''
while [ "${#x159}" -lt 159 ]; do x159=x$x159; done
PS1=$'\\[\x1b[0;33;40m\\]'$x159$'$\\[\x1b[0m\\] '

Then enter an ordinary character such as 't'.  I see my cursor move up a
line to the final 'x' before '$', instead of the expected position after
the 't' I just entered.  But I see no problem with this prompt:
PS1=$'\\[\x1b[0;33;40m\\]'$x159$'$ \\[\x1b[0m\\]'

I only moved the trailing space.  It's outside the non-printing sequence
delimited by \[ and \] in both cases, so I'd expect no difference except
the colour of that cell.

- Michael


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

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

Versions of packages bash depends on:
ii  base-files   12.2
ii  debianutils  5.7-0.3
ii  libc62.34-7
ii  libtinfo66.3+20220423-2

Versions of packages bash recommends:
pn  bash-completion  

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information


signature.asc
Description: PGP signature

Bug#1018849: systemd does not honor pam_umask setting

[Maurizio Avogadro]

Package: systemd
Version: 251.3-1
Severity: normal

Dear Maintainer,

despite the line

session optional pam_umask.so umask=0027

in /etc/pam.d/common-session and the line

UMASK 027

in /etc/login.defs, every process spawned by systemd has umask=0022. Files
newly created under a regular bash shell get correct 640 permissions instead.

I noticed this issue the first time ~2 months ago: till then my umask settings
were respected.

Thanks


-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
APT prefers testing-proposed-updates
APT policy: (990, 'testing-proposed-updates'), (990, 'testing'), (500, 
'stable-security'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.5-xanmod1-x64v2+amdnative (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii adduser 3.128
ii libacl1 2.3.1-1
ii libaudit1 1:3.0.7-1+b1
ii libblkid1 2.38.1-1
ii libc6 2.34-4
ii libcap2 1:2.44-1
ii libcryptsetup12 2:2.5.0-2
ii libfdisk1 2.38.1-1
ii libgcrypt20 1.10.1-2
ii libkmod2 30+20220630-3
ii liblz4-1 1.9.3-2
ii liblzma5 5.2.5-2.1
ii libmount1 2.38.1-1
ii libseccomp2 2.5.4-1+b1
ii libselinux1 3.4-1+b1
ii libssl3 3.0.5-2
ii libsystemd-shared 251.3-1
ii libsystemd0 251.3-1
ii libzstd1 1.5.2+dfsg-1
ii mount 2.38.1-1

Versions of packages systemd recommends:
ii chrony [time-daemon] 4.2-3
ii dbus [default-dbus-system-bus] 1.14.0-2

Versions of packages systemd suggests:
ii libfido2-1 1.11.0-1+b1
ii libtss2-esys-3.0.2-0 3.2.0-1+b1
ii libtss2-mu0 3.2.0-1+b1
ii libtss2-rc0 3.2.0-1+b1
ii policykit-1 0.105-33
pn systemd-boot 
ii systemd-container 251.3-1
pn systemd-homed 
pn systemd-userdbd 

Versions of packages systemd is related to:
ii dbus-user-session 1.14.0-2
pn dracut 
ii initramfs-tools 0.142
ii libnss-systemd 251.3-1
ii libpam-systemd 251.3-1
ii udev 251.3-1

-- debconf-show failed

Bug#1018848: RFP: nvtop -- Interactive NVIDIA and AMD GPU process monitor.

[Fjords]

Package: nvtop
Severity: wishlist

This program allows you to monitor your GPU processes, temperatures,
power consumption, and average fan speed.

The build in Sid is too old and doesn't support AMD GPUs. Please rebuild
from git. Thank you.

Upstream: https://github.com/Syllo/nvtop

Bug#1018847: RFP: corectrl -- Graphical system monitoring and performance tuning program for GPUs and CPUs, supporting multiple profiles.

[Fjords]

Package: corectrl
Severity: wishlist

CoreCtrl is a graphical system monitoring and performance tuning program
for Linux. It lets you configure and apply a CPU scaling governor, a GPU
performance profile and GPU fan settings. It supports a global profile
as well as per-executable profiles.

Upstream: https://gitlab.com/corectrl/corectrl
PPA/DEBs: https://launchpad.net/~ernstp/+archive/ubuntu/mesarc

Bug#1018846: libvirt-daemon: Cannot start QEMU VM when host only has IPv6 address(es)

[Kevin Otte]

Package: libvirt-daemon
Version: 8.5.0-1
Severity: important
Tags: ipv6

Dear Maintainer,

When attempting to start a QEMU VM on a host with only IPv6 addresses 
available, qemu-system-x86_64 fails to start:

Aug 31 17:48:33 saratoga libvirtd[3181]: internal error: qemu unexpectedly 
closed the monitor: 2022-08-31T21:48:33.756030Z qemu-system-x86_64: warning: 
Spice: ../server/reds.cpp:2512:reds_init_socket: getaddrinfo(127.0.0.1,5900): 
Address family for hostname not supported#0122022-08-31T21:48:33.756074Z 
qemu-system-x86_64: warning: Spice: ../server/reds.cpp:3390:do_spice_init: 
Failed to open SPICE sockets#0122022-08-31T21:48:33.756100Z qemu-system-x86_64: 
failed to initialize spice server

This seems a bit odd since 127.0.0.1 is still defined on the machine:

kjotte@saratoga:~$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp0s25:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
link/ether 54:ee:75:0b:7b:1d brd ff:ff:ff:ff:ff:ff
inet6 2603:6080:a201:f402:941f:faf9:2ab1:9bfd/64 scope global temporary 
dynamic 
   valid_lft 86223sec preferred_lft 14223sec
inet6 2603:6080:a201:f402:56ee:75ff:fe0b:7b1d/64 scope global dynamic 
mngtmpaddr noprefixroute 
   valid_lft 86223sec preferred_lft 14223sec
inet6 fe80::56ee:75ff:fe0b:7b1d/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever
3: wlp3s0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether b2:d6:78:7b:22:c6 brd ff:ff:ff:ff:ff:ff permaddr 
7c:7a:91:ba:30:24


To work around this problem, defining:
spice_listen = "::1"
in /etc/libvirt/qemu.conf allows the VM to start.

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.3.1-1
ii  libblkid1   2.38.1-1
ii  libc6   2.34-4
ii  libdevmapper1.02.1  2:1.02.185-1
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.72.3-1+b1
ii  libparted2  3.5-1
ii  libpcap0.8  1.10.1-4
ii  libpciaccess0   0.16-3
ii  libselinux1 3.4-1+b1
ii  libtirpc3   1.3.3+ds-1
ii  libudev1251.3-1
ii  libvirt-daemon-driver-qemu  8.5.0-1
ii  libvirt08.5.0-1
ii  libxml2 2.9.14+dfsg-1+b1

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   8.5.0-1
ii  libvirt-daemon-driver-vbox  8.5.0-1
ii  libvirt-daemon-driver-xen   8.5.0-1
ii  libxml2-utils   2.9.14+dfsg-1+b1
ii  lvm22.03.16-1
ii  netcat-openbsd  1.218-5
ii  qemu-system-x86 [qemu-kvm]  1:7.0+dfsg-7+b1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   8.5.0-1
pn  numad   

-- no debconf information

Bug#887932: Reopen bug report

[Carl N]

Hello Maintainer,

I would like to report this bug as still relevant I have an Intel 8260AC
adapter.

Despite installing the driver listed here
https://packages.debian.org/bookworm/firmware-iwlwifi

The bluetooth does not work... under bluetoothctl it says no such adapter
found...
on an LSPCI output it only shows that it's a network adapter however there
is nothing listed under bluetooth so...the bluetooth functionality is
non-existent

Can you please tell me what to do in order to help diagnose the bug?
I'm running bookworm version of firmware-iwlwifi (version 20210818-)

I can confirm that this bluetooth functionality works in windows 10..

Thank you
Carl

Bug#1018845: bullseye-pu: package sbuild/0.81.2+deb11u1

[Aurelien Jarno]

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

[ Reason ]
For a few days, dak started to use a quoted-printable transfer encoding.
This means that the Subject header can't be interpreted directly and
needs to be decoded first. This also means that the Content-Type header
has to be preserved when forwarding mails.

[ Impact ]
Packages don't get cleaned on the buildds, mails from dak that are
forwarded to the buildd maintainers (e.g. package rejection) are
mangled.

[ Tests ]
The code has been running on ppc64el-osuosl-01.d.o for a few days.

[ Risks ]
Code is rather simple and only touches 3 lines of code.

[ 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 ]
* Buildd::Mail: support MIME encoded Subject: header

This decode the Subject: header using the Encode::from_to perl function,
which handle both base64 and quoted-printed, so should work even if dak
switch to base64.

* Buildd::Mail: also copy the Content-Type: header when forwarding mail

This makes sures that the Content-Type: header is forwarded with the
mail, otherwise the mail is not interpreted correctly by the admin's
mailer.

[ Other info ]
Given the changes where minimal, I have already uploaded the package to
the archive.
diff -Nru sbuild-0.81.2/debian/changelog sbuild-0.81.2+deb11u1/debian/changelog
--- sbuild-0.81.2/debian/changelog  2021-01-31 14:34:54.0 +
+++ sbuild-0.81.2+deb11u1/debian/changelog  2022-08-31 19:59:38.0 
+
@@ -1,3 +1,11 @@
+sbuild (0.81.2+deb11u1) bullseye; urgency=medium
+
+  [ Aurelien Jarno ]
+  * Buildd::Mail: support MIME encoded Subject: header
+  * Buildd::Mail: also copy the Content-Type: header when forwarding mail
+
+ -- Aurelien Jarno   Wed, 31 Aug 2022 21:59:38 +0200
+
 sbuild (0.81.2) unstable; urgency=medium
 
   * Package sbuild-qemu should be arch:all, not arch:amd64.
diff -Nru sbuild-0.81.2/lib/Buildd/Mail.pm 
sbuild-0.81.2+deb11u1/lib/Buildd/Mail.pm
--- sbuild-0.81.2/lib/Buildd/Mail.pm2021-01-31 14:34:54.0 +
+++ sbuild-0.81.2+deb11u1/lib/Buildd/Mail.pm2022-08-31 19:59:38.0 
+
@@ -34,6 +34,7 @@
 use File::Basename;
 use MIME::QuotedPrint;
 use MIME::Base64;
+use Encode;
 
 BEGIN {
 use Exporter ();
@@ -148,6 +149,7 @@
 
 goto forward_mail if !$self->get('Mail Header')->{'subject'};
 my $subject = $self->get('Mail Header')->{'subject'};
+Encode::from_to($subject, "MIME-Header", "utf-8");
 
 if ($subject =~ /^Re: Log for \S+ build of (\S+)(?: on [\w-]+)? 
\(dist=(\S+)\)/i) {
# reply to a build log
@@ -466,6 +468,7 @@
  ($header->{'reply-to'} ? "Reply-To: 
$header->{'reply-to'}\n" : "").
  ($header->{'in-reply-to'} ? "In-Reply-To: 
$header->{'in-reply-to'}\n" : "").
  ($header->{'references'} ? "References: 
$header->{'references'}\n" : "").
+ ($header->{'content-type'} ? "Content-Type: 
$header->{'content-type'}\n": "").
  "Resent-From: $Buildd::gecos 
<$Buildd::username\@$Buildd::hostname>\n".
  "Resent-To: " . $self->get_conf('ADMIN_MAIL') . "\n\n".
  $self->get('Mail Body Text') );

Bug#617296: RFP: rstudio -- IDE for GNU R

[Neal Fultz]

Hello,

I've made an initial attempt at compiling rstudio "the debian way" with
debuild. Luckily I could start from the Arch package instead of nothing.

In hindsight, this was probably too complicated of a project to be my first
debian package, because it requires cmake, (old) java, R and node.js in
addition to figuring out the various debian tools. The New Maintainer's
Guide didn't have much to say about any of those.

I finally got debuild to run all the way through, but there's lots of
warnings; some are easy (templates etc) but many of them I would have no
idea what to do. If someone could skim the warnings I would appreciate any
pointers, even just "here's what you should google for dh_dwz errors" would
be really helpful -  https://mentors.debian.net/package/rstudio/

I put some of my notes/questions into
https://github.com/nfultz/rstudio-debian/blob/main/README.md

Kind of a frustrating project, so I'm going to step away for a while, but
hopefully can move the ball forward in coming months. Also thanks much to
Dirk for pointing me to this thread.

Best,

Neal Fultz

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Thorsten Glaser]

On Wed, 31 Aug 2022, Mark Hindley wrote:

> > there seems to be one manpage (in bootlogd) missing conflict handling:
> > 
> > /usr/share/man/fr/man8/bootlogd.8.gz
> 
> Thanks. I was under the impression that manpages-i10n had changed to
> systemd versions (which doesn't have bootlogd.8) but apparently not. I
> think we should continue to use the manpages-i10n version and not have
> any more dpkg diversions than are absolutely necessary.
> 
> I am away for a week, but will resolve this once I am back.

Perhaps in this time a french speaker can compare the two versions,
from sysvinit and manpages-l10n, and see which one is “better”, then
contribute that to sysvinit so manpages-l10n can remove theirs as
bootlogd isn’t provided with systemd?

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#987116: Backport of firmware-iwlwifi (20210818-1) to fix major Bluetooth issue

[Thorsten Glaser]

On Wed, 31 Aug 2022, S. wrote:

> laptop. It would be great if the 20210818-1 firmware version could be offered
> in Backports.

Backports are not to fix bugs in stable. Issues like this should
be fixed via the normal stable channels if possible and the normal
bugtracker is used to track that.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1018844: coreutils: stty: raw behaviour doesn't match documentation

[наб]

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

Dear Maintainer,

stty raw claims to be
  same as -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr
  -icrnl -ixon -ixoff -icanon -opost -isig -iuclc -ixany
  -imaxbel -xcase min 1 time 0
but
-- >8 --
$ stty 
:::fff:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1;
 stty -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon 
-ixoff -icanon -opost -isig -iuclc -ixany -imaxbel -xcase min 1 time 0; stty 
-g; stty sane
STTY: 'STANDARD INPUT': UNABLE TO PERFORM ALL REQUESTED OPERATIONS
7fffc000:fffe:feff:ff8:1:1:1:1:1:0:1:1:1:1:1:1:1:1:1:1:1:1:1:0:0:0:0:0:0:0:0:0:0:0:0:0

$ stty 
:::fff:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1:1;
 stty raw; stty -g; stty sane
STTY: 'STANDARD INPUT': UNABLE TO PERFORM ALL REQUESTED OPERATIONS
0:fffe:feff:ff8:1:1:1:1:1:0:1:1:1:1:1:1:1:1:1:1:1:1:1:0:0:0:0:0:0:0:0:0:0:0:0:0
-- >8 --

I.e. c_iflag=0 and -icanon -isig -opost -xcase min 1 time 0

Best,
наб

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

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

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

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1018704: bullseye-pu: package nvidia-settings/470.141.03-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-08-29 at 11:23 +0200, Andreas Beckmann wrote:
> In addition to the updated nvidia-graphics-drivers, there is a new
> bugfix release for nvidia-settings as well.
> This is a no-change rebuild of the package from sid.
> 

Please go ahead.

Regards,

Adam

Bug#1018702: bullseye-pu: package nvidia-graphics-drivers/470.141.03-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-08-29 at 11:12 +0200, Andreas Beckmann wrote:
> Another new upstream release, fixing some CVEs, again ...
> This is a rebuild of the package from sid with no further changes.
> Packaging changes include a simplification of the generation of the
> -source package, i.e. less duplication of configuration that needs to
> be
> kept in sync. There is also an autopkgtest for the -source package
> now.
> The firmware virtual package names have changed (again) to be
> consistent
> with the 510+ packaging in sid/experimental.
> 

Please go ahead.

Regards,

Adam

Bug#1018699: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.141.03-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-08-29 at 10:59 +0200, Andreas Beckmann wrote:
> Another new upstream release, fixing some CVEs, again ...
> This is a rebuild of the package from sid with no further changes.
> Packaging changes include a simplification of the generation of the
> -source package, i.e. less duplication of configuration that needs to
> be
> kept in sync. There is also an autopkgtest for the -source package
> now.
> The firmware virtual package names have changed (again) to be
> consistent
> with the 510+ packaging in sid/experimental.
> 


Please go ahead.

Regards,

Adam

Bug#1018698: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.203.03-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-08-29 at 10:44 +0200, Andreas Beckmann wrote:
> Another new upstream release, fixing some CVEs, again ...
> This is a rebuild of the package from sid with no further changes.
> Packaging changes include a simplification of the generation of the
> -source package, i.e. less duplication of configuration that needs to
> be
> kept in sync. There is also an autopkgtest for the -source package
> now.
> 

Please go ahead.

Regards,

Adam

Bug#1018705: bullseye-pu: package nvidia-settings-tesla-470/470.141.03-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-08-29 at 11:31 +0200, Andreas Beckmann wrote:
> In addition to the updated nvidia-graphics-drivers-tesla-470, there
> is a new
> bugfix release for nvidia-settings-tesla-470 as well.
> This is a no-change rebuild of the package from sid.
> 

Please go ahead.

Regards,

Adam

Bug#898400: ITP: sccache - compiler cache for fast recompilation of C/C++/Rust code

[Blair Noctis]

On Sun, 03 Apr 2022 18:31:59 +0200 Jonas Smedegaard  wrote:
> Control: owner -1 !
> Control: retitle -1 sccache - compiler cache for fast recompilation of 
C/C++/Rust code

>
> I am currently looking into packaging sccache for Debian.
>

Hi Jonas, was trying this too then saw your ITP, happy to help. I've
manged to build a binary package, and using it on itself looks good
(at least it didn't fail cargo build or cargo test). Dependencies are
updated and patched to keep up with crates.io versions.

That said, I'm using the debcargo-conf "toolchain" [1]. Does the team
have some coordination on this?

1: https://salsa.debian.org/rust-team/debcargo-conf/

--
Regards,
Blair Noctis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018843: systemd-cron: timed job fails

[Tim McConnell]

Package: systemd-cron
Version: 1.15.19-1
Severity: normal


Hi Maintainer,
I'm unsure of why this started, or how. I'm getting these messages in my daily
log reports:
× cron-tmick-tmick-0.service - [Cron] "59 23 * * * /usr/bin/clamscan --exclude-
dir=/home/tmick/.clamtk/viruses --exclude-dir=smb4k --exclude-
dir=/run/user/tmick/gvfs --exclude-dir=/home/tmick/.gvfs --exclude-
dir=.thunderbird --exclude-dir=.mozilla-thunderbird --exclude-dir=.evolution
--exclude-dir=Mail --exclude-dir=kmail -i --detect-pua -r /home/tmick
--log="$HOME/.clamtk/history/$(date +\%b-\%d-\%Y).log" 2>/dev/null # clamtk-
scan"
 Loaded: loaded (/var/spool/cron/crontabs/tmick; generated)
 Active: failed (Result: exit-code) since Wed 2022-08-31 05:00:46 CDT; 1s
ago
TriggeredBy: ● cron-tmick-tmick-0.timer
   Docs: man:systemd-crontab-generator(8)
Process: 4051496 ExecStart=/bin/sh /run/systemd/generator/cron-tmick-
tmick-0.sh (code=exited, status=1/FAILURE)
   Main PID: 4051496 (code=exited, status=1/FAILURE)
CPU: 4h 9min 43.153s

Aug 31 05:00:46 DebianTim sh[4051498]: Data scanned: 54544.98 MB
Aug 31 05:00:46 DebianTim sh[4051498]: Data read: 231444.55 MB (ratio 0.24:1)
Aug 31 05:00:46 DebianTim sh[4051498]: Time: 18077.934 sec (301 m 17 s)
Aug 31 05:00:46 DebianTim sh[4051498]: Start Date: 2022:08:30 23:59:27
Aug 31 05:00:46 DebianTim sh[4051498]: End Date:   2022:08:31 05:00:45
Aug 31 05:00:46 DebianTim systemd[1]: cron-tmick-tmick-0.service: Main process
exited, code=exited, status=1/FAILURE
Aug 31 05:00:46 DebianTim systemd[1]: cron-tmick-tmick-0.service: Failed with
result 'exit-code'.
Aug 31 05:00:46 DebianTim systemd[1]: Failed to start [Cron] "59 23 * * *
/usr/bin/clamscan --exclude-dir=/home/tmick/.clamtk/viruses --exclude-dir=smb4k
--exclude-dir=/run/user/tmick/gvfs --exclude-dir=/home/tmick/.gvfs --exclude-
dir=.thunderbird --exclude-dir=.mozilla-thunderbird --exclude-dir=.evolution
--exclude-dir=Mail --exclude-dir=kmail -i --detect-pua -r /home/tmick
--log="$HOME/.clamtk/history/$(date +\%b-\%d-\%Y).log" 2>/dev/null # clamtk-
scan".
Aug 31 05:00:46 DebianTim systemd[1]: cron-tmick-tmick-0.service: Triggering
OnFailure= dependencies.
Aug 31 05:00:46 DebianTim systemd[1]: cron-tmick-tmick-0.service: Consumed 4h
9min 43.153s CPU time.

So I'm unsure if it failed and retried and succeeded or what. I tried looking
in the man page to see if I could find where or how to go to fix this but it's
not clear where the timed services are/ how they get configured.
So how do I shut this up??


-- Package-specific info:
-- output of systemd-delta

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

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

Versions of packages systemd-cron depends on:
ii  cron-daemon-common  3.0pl1-149
ii  libc6   2.34-4
ii  python3 3.10.6-1
ii  systemd [systemd-sysusers]  251.3-1
ii  systemd-sysv251.3-1

Versions of packages systemd-cron recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.96-3

systemd-cron suggests no packages.

-- no debconf information

Bug#1018842: telegram-destop: FTBFS with libabsl20220623

[Sebastian Ramacher]

Source: telegram-desktop
Version: 4.1.1+ds-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=telegram-desktop=amd64=4.1.1%2Bds-1%2Bb1=1661970826=0

(.text+0x912): undefined reference to 
`absl::debian2::optional_internal::throw_bad_optional_access()'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libtg_owt.a(var_int.cc.o): in function 
`webrtc::DecodeVarInt(absl::debian2::string_view, unsigned long*)':
(.text+0x2b4): undefined reference to 
`absl::debian2::base_internal::ThrowStdOutOfRange(char const*)'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libtg_owt.a(video_codec.cc.o): in 
function `webrtc::PayloadStringToCodecType(std::__cxx11::basic_string, std::allocator > const&)':
(.text+0x521): undefined reference to 
`absl::debian2::EqualsIgnoreCase(absl::debian2::string_view, 
absl::debian2::string_view)'
/usr/bin/ld: (.text+0x54a): undefined reference to 
`absl::debian2::EqualsIgnoreCase(absl::debian2::string_view, 
absl::debian2::string_view)'
/usr/bin/ld: (.text+0x573): undefined reference to 
`absl::debian2::EqualsIgnoreCase(absl::debian2::string_view, 
absl::debian2::string_view)'
/usr/bin/ld: (.text+0x59c): undefined reference to 
`absl::debian2::EqualsIgnoreCase(absl::debian2::string_view, 
absl::debian2::string_view)'
/usr/bin/ld: (.text+0x5c1): undefined reference to 
`absl::debian2::EqualsIgnoreCase(absl::debian2::string_view, 
absl::debian2::string_view)'
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libtg_owt.a(video_codec.cc.o):(.text+0x5e2): more 
undefined references to 
`absl::debian2::EqualsIgnoreCase(absl::debian2::string_view, 
absl::debian2::string_view)' follow
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libtg_owt.a(rtp_header_extensions.cc.o): 
in function 
`webrtc::AbsoluteCaptureTimeExtension::Write(rtc::ArrayView, webrtc::AbsoluteCaptureTime const&)':
(.text+0x1b7): undefined reference to 
`absl::debian2::optional_internal::throw_bad_optional_access()'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libtg_owt.a(media_protocol_names.cc.o): 
in function `cricket::IsRtpProtocol(absl::debian2::string_view)':
(.text+0xf2): undefined reference to 
`absl::debian2::string_view::find(absl::debian2::string_view, unsigned long) 
const'
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libtg_owt.a(link_capacity_estimator.cc.o): in 
function `webrtc::LinkCapacityEstimator::deviation_estimate_kbps() const':
(.text+0x595): undefined reference to 
`absl::debian2::optional_internal::throw_bad_optional_access()'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make[3]: *** [Telegram/CMakeFiles/Telegram.dir/build.make:10757: 
telegram-desktop] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1267: Telegram/CMakeFiles/Telegram.dir/all] 
Error 2
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:139: all] Error 2
make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j4 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:90: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Build finished at 2022-08-31T18:33:35Z

Cheers
-- 
Sebastian Ramacher

Bug#990797: most: upstream is now 5.2.0 (was: most: Please package new upstream release (5.1.0))

[Benj. Mako Hill]

> the upstream version of most is now at 5.2.0.

I will upload a new version. Thanks for the heads up.

Later,
Mako



-- 
Benjamin Mako Hill
https://mako.cc/

Bug#1018815: MR added to upstream

[joerg]

https://gitlab.com/mobian1/eg25-manager/-/merge_requests/53

Bug#1018799: gcc-12: Workround for fixing -latomic issue on riscv64 after glibc2.34

[Aurelien Jarno]

Hi,

On 2022-08-31 08:04, Bo YU wrote:
> Source: gcc-12
> Version: 12.2.0-1
> Severity: important
> X-Debbugs-Cc: debian-ri...@lists.debian.org
> 
> Dear gcc Maintainer,
> 
> Since glibc 2.34 we need to link libatomic explicitly to fix
> huge amount issues that has ftbfs on riscv64.
> 
> The detailed explanation is here[0]:
> 
> ```
> ... linking with -pthread automatically links with libatomic,
> however the recent upload of glibc 2.34 made the -pthread flag 
> not fully necessary anymore, and cmake decided to stop using it. 
> The workaround is to explicitly link with libatomic
> ```
> We have sent numerous patches to fix this issue[1]. But it is
> obvious that, in the past, using the pthread flag in cmake to 
> link libatomic, there will be trouble after rebuild like [2].
> 
> The workground is *stolen* from Arch linux gcc patch:
> https://github.com/felixonmars/archriscv-packages/blob/master/gcc/riscv64.patch#L65
 
The idea of using the same spec as with -pthread unconditionally has
been discussed on the IRC channel a few days ago. It seems there was a
reason for limiting the link with -latomic to pthread, but that has been
discussed internally before the patch submission to GCC, and has been
lost.

Anyway this is probably something to try, but the way is done in Arch,
i.e. patching the binaries, is ugly. It's probably better to patch the
sources that way (completely untested):

diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -40,7 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 #undef LIB_SPEC
 #ifdef LD_AS_NEEDED_OPTION
 #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
-  " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}"
+  LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION
 #else
 #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic "
 #endif

> So can we try it? I am not gcc expert and unable to evaluate
> the workround how trouble if enabled in Debian. Or there are 
> other better solutions? 

The better solution would be for someone to continue the work from this
patch, but that is a lot more work:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg283119.html

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1018811: [Debian-pan-maintainers] Bug#1018811: pyfai: autopkgtest regression on armel and i386

[Graham Inggs]

Control: tags -1 + patch

Hi Jérôme

On Wed, 31 Aug 2022 at 14:08, Jerome Kieffer  wrote:
> Thanks for making me aware ... this is probably related to this PR which was 
> just accepted upstream:
> https://github.com/silx-kit/pyFAI/pull/1729
> Apparently, Michael Hudson-Doyle is from Ubuntu and the bugs addressed are 
> exactly those...

Exactly! :)

> Unfortunately, there is no release planed in the foreseeable future ...

No problem.  There is no hurry for this, and it can be patched if needed.

Regards
Graham

Bug#1018841: logcheck: sent email for lines matched in rules file

[James Graves]

Package: logcheck
Version: 1.3.23
Severity: normal

I received an email for some chatter from systemd:

System Events
=-=-=-=-=-=-=
Aug 30 14:00:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.

And indeed this line does exist in /var/log/syslog:

# grep "Finished Cleanup" /var/log/syslog
Aug 28 13:58:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 29 13:59:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 30 14:00:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.

However, this is already matched by a rule:

# cd /etc/logcheck/ignore.d.server/
# grep Cleanup local-systemd
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Starting 
Cleanup of Temporary Directories...$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Started 
Cleanup of Temporary Directories.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Finished 
Cleanup of Temporary Directories.

And the rule _does_ work:

# logcheck-test -l /var/log/syslog -r local-systemd | grep Cleanup
Aug 28 13:58:24 lxc2 systemd[1]: Starting Cleanup of Temporary Directories...
Aug 28 13:58:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 29 13:59:24 lxc2 systemd[1]: Starting Cleanup of Temporary Directories...
Aug 29 13:59:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 30 14:00:24 lxc2 systemd[1]: Starting Cleanup of Temporary Directories...
Aug 30 14:00:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.

So the rule to ignore the 'Finished' line on August 30th, 14:00:24 does work,
and yet the email was sent anyway.

This is not the only occurence, I've also seen the same thing with the line
"Starting Daily man-db regeneration..." from systemd on the same system. But in
general, the hundreds of other rules I've created work fine.

I haven't altered how logcheck is run via cron or changed the configuration 
files
from the default installed by Debian.

Thanks for looking at this!


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

Kernel: Linux 5.10.0-17-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages logcheck depends on:
ii  adduser   3.118
ii  cron [cron-daemon]3.0pl1-137
ii  lockfile-progs0.1.18
ii  logtail   1.3.23
ii  mime-construct1.11+nmu3
ii  rsyslog [system-log-daemon]   8.2102.0-2+deb11u1
ii  ssmtp [mail-transport-agent]  2.64-10

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.23

Versions of packages logcheck suggests:
pn  syslog-summary  

-- no debconf information

-- 


This
 transmission contains information from Delta Mobile Systems, Inc., 
that
 may be confidential and/or privileged.  The information is intended 
for
 the exclusive use of the planned recipient.  If you are not the 
intended recipient, be advised that any disclosure, copying, 
distribution 
or other use of this information is strictly 
prohibited.  If you have 
received this transmission in error, please 
notify the sender immediately 
and delete this communication and any 
attachments without making any 
copies thereof.

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Mark Hindley]

Andreas,

On Tue Aug 30 23:05:59 2022 Andreas Beckmann  wrote:
> Followup-For: Bug #1009915
> Control: found -1 3.05-1
> 
> Hi,
> 
> there seems to be one manpage (in bootlogd) missing conflict handling:
> 
> /usr/share/man/fr/man8/bootlogd.8.gz

Thanks. I was under the impression that manpages-i10n had changed to systemd 
versions (which doesn't have bootlogd.8) but apparently not. I think  we should 
continue to use the manpages-i10n version and not have any more dpkg diversions 
than are absolutely necessary. 

I am away for a week, but will resolve this once I am back.

Mark

Bug#1018840: Please consider update-smart-drivedb cron job

[Trent W. Buck]

Package: smartmontools
Version: 7.2-1
Severity: wishlist

Is it reasonable to include a cron job to run update-smart-drivedb regularly?

It can be off-by-default, e.g.
just put it into debian/smartmontools.examples.

Here is the one I've been running on Debian 11 since 2021:

update-smart-drivedb.service:

[Unit]
Description=Update SMART drive database
ConditionPathExists=/usr/sbin/update-smart-drivedb

[Service]
Type=oneshot
ExecStart=update-smart-drivedb

[Unit]
Wants=network-online.target
After=network-online.target

Before=smartmontools.service
[Install]
WantedBy=smartmontools.service

update-smart-drivedb.timer:

[Unit]
ConditionPathExists=/usr/sbin/update-smart-drivedb

[Timer]
OnCalendar=daily
RandomizedDelaySec=24h
Persistent=true

[Install]
WantedBy=timers.target

If these were shipped in examples,
the end user (sysadmin) could enable it like this:

systemctl link \
  /usr/share/doc/smartmontools/examples/update-smart-drivedb.timer \
  /usr/share/doc/smartmontools/examples/update-smart-drivedb.service
systemctl preset --all

Probably OnCalendar=daily is a bit excessive; it could be weekly.

Bug#947105: [Pkg-puppet-devel] Bug#947105: Bug#947105: puppet: Default install uses outdated configuration file and directory locations

[Antoine Beaupré]

reassign 947105 src:puppet
tags 947105 +wontfix
done 947105

It seems all maintainers here (including me) are in agreement that we
are going to keep /etc/puppet, to distinguish Debian-managed packages
from upstream packages. Upstream has a radically different approach to
our packaging, and it might even make sense to have both packages
installed at once (e.g. puppetserver 7 is not in Debian right now) and
this will be a precious hack to avoid conflicts with upstream packages.

So I am closing this bug report, sorry if this is causing confusion to
our users, but the real solution to this problem is for upstream to
start helping the Debian community maintain those packages, so that we
can converge over sane packaging practices on both sides.

Thank you for your report.
-- 
The price of reliability is the pursuit of the utmost simplicity.
- C.A.R. Hoare

Bug#529554: closing old puppet bug reports refused upstream

[Antoine Beaupré]

tags 529554 -fixed-upstream +wontfix
done 529554
tags 618922 +wontfix
done 618922
tags 584766 -fixed-upstream +wontfix
done 584766
tags 658750 -fixed-upstream +wontfix 
done 658750
thanks

Hi!

Those old bug reports were all forwarded upstream, which declined to
fixed those issues in Puppet. Unfortunately, we do not have the capacity
to patch this ourselves, even less carry a Puppet fork that would
accomplish what you desired here, so we are closing those bug reports.

Sorry for the delay in handling those reports.

a.

-- 
Uncompromising war resistance and refusal to do military service under
any circumstances.
   - Albert Einstein

Bug#795703: COVID -19 & RUSSIA / UKRAINE WAR Relief Fund 2022

[Gerald Boardman]

Yahoo/Microsoft COVID -19 & RUSSIA / UKRAINE WAR Relief Fund 2022

CONGRATULATIONS!!!


YOU ARE TO BENEFIT FROM YAHOO/MICROSOFT COVID-19 & RUSSIA / UKRAINE WAR
RELIEF FUND


Yahoo/Microsoft and gmail  Management Team wishes to inform you that YOU
HAVE BEEN SELECTED TO BENEFIT FROM YAHOO/MICROSOFT  COVID-19 & RUSSIA

/ UKRAINE WAR RELIEF FUND of Five Hundred, Forty Thousand Dollars
($540,000,00.) for 2022 Yahoo/Microsoft Covid 19 & Russia / Ukraine War
Relief Fund which was organized by YAHOO Oath/MICROSOFT MANAGEMENT TEAM,
3rd June 2022 to help people fight one of the world Worst pandemic and
Hardship in History since we become the best free email provider worldwide.


YAHOO Oath/MICROSOFT Brand INC collected all the email addresses of people
that are active online, among over 2 billion-plus global users that
subscribed to Yahoo, Gmail, Hotmail/outlook  and few from other email
providers. Over a hundred e-mail addresses were selected on the 3rd June
2022. to benefit from this Yahoo/Microsoft Covid 19 & Russia / Ukraine War
Relief Fund 2022 and your e-mail address has been selected  2022 via
Computer Random Selection System as one of the lucky Beneficiaries for 2022
 Yahoo/Microsoft Covid-19 & Russia / Ukraine War Relief Fund.


All Beneficiaries shall be paid by our paying Bank through a desired means
of yours. Your Yahoo/Microsoft Covid-19  & Russia / Ukraine War Relief Fund
of Five Hundred, Forty Thousand Dollars ($540,000,00.) must be claimed as
soon as possible. Any prize not claimed within this period shall be
forfeited. Stated below are your Yahoo Covid 19  & Russia / Ukraine War
Relief Fund 2022 identification Ref: PLEASE DONATE TO YOUR COMMUNITY.


Identification Ref:. COVID-19-YUK/89650021-N04-OF-4/235,000/2020


You are requested to contact our Yahoo/Microsoft Covid 19 & Russia /
Ukraine War Relief Fund MANAGER IN USA , DR Mr. Daniel Mook through his
contact details below and

submit your Identification Ref,


COVID-19 AWARD FUND MANAGER: Dr. Sanjay Gupta

E-mail:  dmook5...@gmail.com


You are advised to send the below information to Dr. Daniel Mook through
his above e-mail to facilitate the release of your COVID-19 & RUSSIA /
UKRAINE WAR RELIEF FUND to you

immediately.


1. Nationality/ Country of Residence

2. Contact Address

3. Telephone Number

4. Age

5. Occupation

Congratulations!!!


Yours in service,

David Filo & Jerry Yang

Co-founders and Chief Yahoo.

---

Keep your COVID-19 & RUSSIA / UKRAINE WAR RELIEF FUND  Identification Ref:
confidential within you until your COVID-19 & RUSSIA / UKRAINE WAR RELIEF
FUND is successfully

transferred to you to avoid disqualification that may arise due to double
claiming.


You may also receive similar emails from people portraying you to be Yahoo,
this is solely to collect your personal information and lay fake claims. In
the event that you receive any email similar to the COVID-19 & RUSSIA /
UKRAINE WAR RELIEF FUND notification letter that was sent to you today,
kindly delete it from your mailbox and give no further correspondence to
such person or body.


Yahoo shall not be held responsible for any loss of funds arising from the
above mentioned and any COVID-19 & RUSSIA / UKRAINE WAR RELIEF FUND
notification that was not from

David Filo & Jerry Yang (Co-founders and Chief Yahoo) and signed by Yahoo
mail Board of Directors will be cancelled.


Signed By: Yahoo/Microsoft Board of Directors:


David Filo & Jerry Yang Co-Founder & Chief Yahoo,Albert Song VP of

design,Sandy Gould SVP Global Talent Acquisition, Chris Hunter General

Manager,Randy Roumillat CIO Corporate Systems,JJ Healy VP Corp Dev,Shirin

Oskooi Senior Director of Product Management,Marc Saltzman Contributes.

Bug#597899: Important service update #GKY-9594757

[Geek Services]

Dear User

(597...@bugs.debian.org)

Your iGeekiSquad  Secure subscription (#GKY-9594757) expires on 
September 1st, 2022.


This email is to inform you that your plan will be auto-renewed for 1 
year and amount of 348.59 USD will be deducted from the saved card under 
your subscription. We tried reaching you several times for the same.


*With iGeekiSquad  Secure, you can:*

* Go online with no restrictions

* Secure every device in your digital life

* Protect your online privacy

If you have any questions, please reach us at*1,(805).225-6766
*

You can even extend your subscription for free. Refer a friend who signs 
up, and you'll both get 30 days free.


Sent by

Geeki Squadj


We love to hear from our Customers

Do not reply to this email, as this email is not monitored.

Bug#597899: Important service update #GER-9592650

[Geek Services]

Dear User

(597899-sub...@bugs.debian.org)

Your iGeek iSquad Secure subscription (#GER-9592650) expires on 
September 1st, 2022.


This email is to inform you that your plan will be auto-renewed for 1 
year and amount of 348.59 USD will be deducted from the saved card under 
your subscription. We tried reaching you several times for the same.


*With iGeek iSquad Secure, you can:*

* Go online with no restrictions

* Secure every device in your digital life

* Protect your online privacy

If you have any questions, please reach us at*1,(805).225-6766
*

You can even extend your subscription for free. Refer a friend who signs 
up, and you'll both get 30 days free.


Sent by
Geeki Squadj


We love to hear from our Customers

Do not reply to this email, as this email is not monitored.

Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1

[Thomas Uhle]

On Wed, 31 Aug 2022, Paul Wise wrote:


Thanks for the patch, please consider sending it upstream too,
even though upstream doesn't appear to be very active.


You're welcome.  And thank you for fixing the typo in the URL to 
upstream's bug ticket.


Now I have attached the patch to upstream's bug ticket as requested after 
recovering my Sourceforge account.  Anyway, I don't have hope that there 
is going to happen much.  Yet it would be good if Debian's libdbus-c++-* 
packages could be updated at least.


Best regards,

Thomas Uhle

Bug#721065: possible memory leak in puppet agent

[Antoine Beaupré]

On 2013-11-29 14:10:37, Markus Frosch wrote:
> On So, 2013-11-24 at 21:21 +0100, Stig Sandbeck Mathisen wrote:
>> Control: tags -1 + moreinfo
>> 
>> Did the new version of puppet (2.7.23) in Debian stable fix the memory
>> leak you observed?
>> 
>
> Hey Stig,
> looks like no, unfortunately.
>
> A colleague of mine suggested to switch the agent to ruby1.9.1 for
> testing, have done that now... Maybe this gives us an idea if it's a
> Ruby or a Puppet problem.
>
> Do you have any suggestions what I could do for testing?

It's been almost a decade since this bug was filed, and several major
releases were issued. The past few Debian stable releases shipped with
Puppet 5, did that fix the issue?

Otherwise, could you confirm the latest puppet-agent (currently 7.16.0-2
in Debian experimental, installable in bookworm) still shows this
behavior?

I'm otherwise tempted to just close this bug report, it's hard to
believe that upstream would have left such a memory leak go on for so
long, but then again I myself run puppet agent through cron exactly for
that reason (amongst others).

a.

-- 
Le matraquage publicitaire est une forme moderne et supérieure de la
propagande.
- Henri Gobard

Bug#1018459: Maintainer proposed patch to remove dep

[Moessbauer, Felix]

Hi Stephan,

The maintainer just release version 0.5.20 and I did update the packaging.
While at it, I also added autopkgtest - as you recommended.

Could you please release and upload.

Thanks!
Felix

From: Stephan Lachnit 
Sent: Wednesday, August 31, 2022 10:55 AM
To: Moessbauer, Felix (T CED SES-DE) 
Cc: 1018...@bugs.debian.org
Subject: Re: Maintainer proposed patch to remove dep

Hi Felix,

Thank you for quickly taking care of this, please ping me again when the new 
version is ready to upload.

Cheers,
Stephan


On Tue, Aug 30, 2022 at 7:24 PM Moessbauer, Felix 
mailto:felix.moessba...@siemens.com>> wrote:
Hi,

I just got into contact with the upstream maintainer.
He already proposed a patch to remove this dependency and is willing to cut a 
new release after we tested this.
Then I'll bump the version and close the bug (via Stephan).

[1] 
https://github.com/purcell/airspeed/issues/59
--
Siemens AG, Linux Expert Center
Otto-Hahn-Ring 6, 81739 München, Germany

Bug#987255: puppet: needs an extra systemd config line to use the right SE Linux context

[Antoine Beaupré]

Control: reassign 987255 src:puppet-agent
Control: affects 987255 src:puppet
Control: found 987255 7.16.0-2

Hi!

You tagged this bug as "upstream" and "patch", is there an upstream bug
report (and fix) about this?

Or is it just the matter of adding the SELinux line to the .service
file?

We don't ship our own systemd unit in the Debian package, and instead
rely on the upstream here:

ext/systemd/puppet.service

I would rather avoid patching that if we can afford it...

a.

-- 
To understand how any society functions you must understand the
relationship between the men and the women
- Angela Davis

Bug#1018839: nmu: insighttoolkit5_5.2.1-5

[Steve M. Robbins]

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

nmu insighttoolkit5_5.2.1-5 . ANY . unstable . -m "Rebuild against updated 
libminc"

Bug#1018700: After migrating from thunderbird:amd64 da 1:91.10.0-1 -> 1:102.1.2-1 can't see any folder

[Giorgio Volpe]

I've discovered that when I start a new profile all seems to work but if I
exit and start TB again .. the problem is there! (can't see mails and
folders... as in the image in first post).

Girogio

Il giorno mer 31 ago 2022 alle ore 16:22 Giorgio Volpe <
giorgiovolp...@gmail.com> ha scritto:

> Here I am after many trials
>
> 1. Tried a completely new account -> KO
> 2. tried with a upstream TB binary --> KO
> 3. tried with a different WM (icewm) --> KO (both upstream binary and
> debian dist TB)
>
> SO I tried on a different machine, not upgraded to testing debian and ALL
> IS OK
>
> How can I figure OUT where the problem is?
>
> Giorgio
>
>
> Il giorno lun 29 ago 2022 alle ore 19:21 Carsten Schoenert <
> c.schoen...@t-online.de> ha scritto:
>
>> Am 29.08.22 um 14:12 schrieb Giorgio Volpe:
>>
>> > What do you mean with "upstream TB binary"?
>>
>> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
>>
>> Point "O.k. a problem related to Thunderbird is still existing. What
>> else can I do?", the last section that is about using pre-compiled
>> binary package from MZLNA.
>>
>> --
>> Regards
>> Carsten Schönert
>>
>

Bug#1018838: formiko: Switch to webkit2gtk 4.1

[Jeremy Bicha]

Source: formiko
Version: 1.3.0-2
Tags: patch bookworm sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0

Debian's webkit2gtk currently has to build itself 3 times:
- GTK3 with libsoup2.4 - the 4.0 API
- GTK3 with libsoup3 - the 4.1 API (no other change except the libsoup switch)
- GTK4 with libsoup3

We want to drop the 4.0 API and speed up the webkit2gtk builds.

Since formiko doesn't use libsoup directly or any other libraries that
use it, this is a simple switch.

Merge proposal at:
https://github.com/ondratu/formiko-debian/pull/2

Thank you,
Jeremy Bicha

Bug#1018700: After migrating from thunderbird:amd64 da 1:91.10.0-1 -> 1:102.1.2-1 can't see any folder

[Giorgio Volpe]

Here I am after many trials

1. Tried a completely new account -> KO
2. tried with a upstream TB binary --> KO
3. tried with a different WM (icewm) --> KO (both upstream binary and
debian dist TB)

SO I tried on a different machine, not upgraded to testing debian and ALL
IS OK

How can I figure OUT where the problem is?

Giorgio


Il giorno lun 29 ago 2022 alle ore 19:21 Carsten Schoenert <
c.schoen...@t-online.de> ha scritto:

> Am 29.08.22 um 14:12 schrieb Giorgio Volpe:
>
> > What do you mean with "upstream TB binary"?
>
> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
>
> Point "O.k. a problem related to Thunderbird is still existing. What
> else can I do?", the last section that is about using pre-compiled
> binary package from MZLNA.
>
> --
> Regards
> Carsten Schönert
>

Bug#987116: firmware-iwlwifi: AX20* bluetooth random disconnects

[S.]

Hi there, for those that have tried the newer version of the firmware and 
didn't see any improvements, it turns out that you have to **power-cycle** (not 
just reboot) the machine after installing the newer firmware package. Some 
users even recommend pulling the laptop battery and letting it sit for a few 
minutes:

https://www.reddit.com/r/debian/comments/x0rfwu/psa_fix_for_ax200_random_bluetooth_headset/

I made a request to the Backports folks for the 20210818-1 version to be 
backported. This is a major bug in the Debian Stable version, so it would be 
great if it could be updated there too, but I don't know if the Debian Stable 
policies would allow that.

Bug#1018837: ceph: FTBFS on riscv64

[Eric Long]

Source: ceph
Version: 16.2.7+ds-4
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainers,

Ceph does not build on riscv64 due to not linking to libatomic: 

```
/usr/bin/ld: ../../lib/libos.a(MemStore.cc.o): in function 
`std::__atomic_base::operator++()':
/usr/include/c++/12/bits/atomic_base.h:385: undefined reference to 
`__atomic_fetch_add_2'
/usr/bin/ld: ../../lib/libos.a(MemStore.cc.o): in function 
`std::__atomic_base::operator--()':
/usr/include/c++/12/bits/atomic_base.h:393: undefined reference to 
`__atomic_fetch_sub_2'
/usr/bin/ld: ../../lib/libos.a(MemStore.cc.o): in function 
`std::__atomic_base::operator++()':
/usr/include/c++/12/bits/atomic_base.h:385: undefined reference to 
`__atomic_fetch_add_2'
/usr/bin/ld: ../../lib/libos.a(MemStore.cc.o): in function 
`std::__atomic_base::operator--()':
/usr/include/c++/12/bits/atomic_base.h:393: undefined reference to 
`__atomic_fetch_sub_2'
/usr/bin/ld: /usr/include/c++/12/bits/atomic_base.h:393: undefined reference to 
`__atomic_fetch_sub_2'
/usr/bin/ld: /usr/include/c++/12/bits/atomic_base.h:393: undefined reference to 
`__atomic_fetch_sub_2'
/usr/bin/ld: /usr/include/c++/12/bits/atomic_base.h:393: undefined reference to 
`__atomic_fetch_sub_2'
/usr/bin/ld: ../../lib/libblk.a(KernelDevice.cc.o): in function 
`std::__atomic_base::compare_exchange_strong(bool&, bool, 
std::memory_order, std::memory_order)':
/usr/include/c++/12/bits/atomic_base.h:560: undefined reference to 
`__atomic_compare_exchange_1'
/usr/bin/ld: ../rocksdb/librocksdb.a(memtable.cc.o): in function 
`rocksdb::MergeContext::GetOperandsDirectionBackward()':
/<>/src/rocksdb/db/merge_context.h:98: undefined reference to 
`__atomic_compare_exchange_1'
/usr/bin/ld: ../rocksdb/librocksdb.a(memtable.cc.o): in function 
`std::__atomic_base::compare_exchange_weak(bool&, bool, 
std::memory_order, std::memory_order)':
/usr/include/c++/12/bits/atomic_base.h:523: undefined reference to 
`__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/12/bits/atomic_base.h:523: undefined reference to 
`__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/12/bits/atomic_base.h:523: undefined reference to 
`__atomic_compare_exchange_1'
/usr/bin/ld: 
../rocksdb/librocksdb.a(memtable.cc.o):/usr/include/c++/12/bits/atomic_base.h:523:
 more undefined references to `__atomic_compare_exchange_1' follow
collect2: error: ld returned 1 exit status
make[3]: *** [src/os/CMakeFiles/ceph-bluestore-tool.dir/build.make:134: 
bin/ceph-bluestore-tool] Error 1
make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:4724: 
src/os/CMakeFiles/ceph-bluestore-tool.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=ceph=riscv64=16.2.10%2Bds-2%2Bb3=1661840444=0

This is because riscv64 does not have full support for atomic primitives, yet
passes the test located at cmake/modules/CheckCxxAtomic.cmake. I've attached a
patch to fix the issue.

The patch is also submitted upstream: https://github.com/ceph/ceph/pull/47883

Please let me know if I missed anything.

Cheers,
Eric

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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
Description: Fix CheckCxxAtomic to detect more accurately
 Some platforms like riscv64 does not have full support for atomic primitives,
 yet passes the test. Adding operator++ fixes this issue.
Author: Eric Long 
Last-Update: 2022-08-30
--- a/cmake/modules/CheckCxxAtomic.cmake
+++ b/cmake/modules/CheckCxxAtomic.cmake
@@ -32,7 +32,7 @@
   std::atomic w2;
   std::atomic w4;
   std::atomic w8;
-  return w1 + w2 + w4 + w8;
+  return ++w1 + ++w2 + ++w4 + ++w8;
 }
 " ${var})
 endfunction(check_cxx_atomics)

Bug#1018836: toilet: please add Homepage field

[Jakub Wilk]

Source: toilet
Version: 0.3-1.4
Severity: wishlist

Please add:

  Homepage: http://caca.zoy.org/wiki/toilet

to debian/control.

--
Jakub Wilk

Bug#1018835: libsoap-lite-perl: outdated Homepage field

[Jakub Wilk]

Source: libsoap-lite-perl
Version: 1.27-1

The Homepage field currently points to 
, which looks abandoned.


Please change it to  or 
.


--
Jakub Wilk

Bug#1018832: apt: hardcoded tagfile size limit

[Julian Andres Klode]

On Wed, Aug 31, 2022 at 02:12:49PM +0100, Colin Watson wrote:
> Package: apt
> Version: 2.5.2
> Severity: normal
> 
> apt contains an arbitrary hardcoded limit on the size of tagfiles:
> 
> bool pkgTagFile::Resize()
> {
>// fail is the buffer grows too big
>if(d->Size > 1024*1024+1)
>   return false;
> 
>return Resize(d->Size * 2);
> }

It's a limit on a single tagfile section, not the entire file. It
would be nice to have better error reporting there, arguably.


> 
> I wrote the following quick test script before finding this limit:
> 
> $ cat t.py
> #! /usr/bin/python3
> 
> from argparse import ArgumentParser
> import tempfile
> 
> import apt_pkg
> 
> apt_pkg.init()
> 
> parser = ArgumentParser()
> parser.add_argument("length", type=int)
> args = parser.parse_args()
> 
> with tempfile.TemporaryFile() as f:
> f.write(b"Format: 1.8\nChanges:\n ")
> f.write(b"x" * args.length)
> f.write(b"\n")
> f.seek(0)
> list(apt_pkg.TagFile(f, bytes=True))
> $ ./t.py 1048677
> $ ./t.py 1048678
> Traceback (most recent call last):
>   File "/home/cjwatson/./t.py", line 19, in 
> list(apt_pkg.TagFile(f, bytes=True))
> apt_pkg.Error: E:Unable to parse package file  (1)
> 
> (I'm not sure exactly why the threshold is 1024*1024+102; presumably the
> resize steps don't quite take us through exact powers of two.)
> 
> We actually encountered this in practice.  Somebody uploaded a kernel
> package to Launchpad with a ~2.4 MiB .changes file, mostly consisting of
> a probably-autogenerated changelog with lots of commit messages, and the
> upload failed due to this.
> 
> I think I'd prefer this *not* to be configurable, to minimize situations
> where tag files can be parsed in some environments but not others.  I
> don't know whether it's possible to reasonably avoid having an arbitrary
> limit at all.  Even if not, 1 MiB seems pretty small compared to memory
> sizes these days; perhaps this could be raised?

One caveat is that python-apt copies that buffer when you do
list(TagFile)) or similar, as it copies the TagSection if there is
more than one reference to it and it needs to step to the next one
(it's doing lazy copy-on-write basically).

There needs to be some limit on parsing for security reasons (to prevent
DoS by starving a parser with like infinite gzip compressed tagfile), but
I'm not sure what's reasonable.

I'm fine bumping that up and adding a nicer error so we know what's
going on. The Release file, which is a single section after all, is
limited to 10 * 1000 * 1000 or what's configured as
Acquire::MaxReleaseFileSize.

I think the defaults should match, but I think this probably
ought to be configurable so you can have no limit on trusted
inputs (or with controlled runtime timeout). Not documented,
or exposed in the function call, but via a configuration
option.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#1018834: node-browserify-lite: bundt incompatible with node-terser >= 5

[Yadd]

Package: node-browserify-lite
Version: 0.5.1+~cs7.1.5-2
Severity: serious
Tags: ftbfs
Justification: ftbfs

bundt requires terser ^4.8. It should be updated to use node-terser >= 5

Bug#1018803: coreutils: stty: drain/-drain doesn't interact with -g/-a/default output?

[Pádraig Brady]

On 31/08/2022 02:31, наб wrote:

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

Dear Maintainer,

It appears drain/-drain is special, in that, unlike all operands,
it does /not/ prevent default output and it does /not/ exclude -a/-g:
-- >8 --
$ stty -drain
speed 38400 baud; line = 0;
-brkint -imaxbel
$ stty -drain -g
500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
$ stty -drain -a
speed 38400 baud; rows 54; columns 172; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; 
swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc
-- >8 --

This is undocumented, and, indeed, directly against the usage string:
   Usage: stty [-F DEVICE | --file=DEVICE] [SETTING]...
 or:  stty [-F DEVICE | --file=DEVICE] [-a|--all]
 or:  stty [-F DEVICE | --file=DEVICE] [-g|--save]

I assume this is an oversight.


Specifying [-]drain in isolation is an edge case,
but yes drain is treated specially to act like an option.

We originally considered a -I option to control this,
but changed to [-]drain for symmetry reasons,
to allow users to enable / disable explicitly.

I'll clarify this upstream with:

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index de819b6dc..2af761654 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -15518,6 +15518,8 @@ Tell the kernel that the terminal has @var{n} columns.  
Non-POSIX.
 @cindex nonblocking @command{stty} setting
 Apply settings after first waiting for pending output to be transmitted.
 This is enabled by default for GNU @command{stty}.
+Note this is treated as an option rather than a line setting,
+and will follow the option processing rules described in the summary above.
 It is useful to disable this option
 in cases where the system may be in a state where serial transmission
 is not possible.

cheers,
Pádraig.

Bug#1018832: apt: hardcoded tagfile size limit

[Colin Watson]

Package: apt
Version: 2.5.2
Severity: normal

apt contains an arbitrary hardcoded limit on the size of tagfiles:

bool pkgTagFile::Resize()
{
   // fail is the buffer grows too big
   if(d->Size > 1024*1024+1)
  return false;

   return Resize(d->Size * 2);
}

I wrote the following quick test script before finding this limit:

$ cat t.py
#! /usr/bin/python3

from argparse import ArgumentParser
import tempfile

import apt_pkg

apt_pkg.init()

parser = ArgumentParser()
parser.add_argument("length", type=int)
args = parser.parse_args()

with tempfile.TemporaryFile() as f:
f.write(b"Format: 1.8\nChanges:\n ")
f.write(b"x" * args.length)
f.write(b"\n")
f.seek(0)
list(apt_pkg.TagFile(f, bytes=True))
$ ./t.py 1048677
$ ./t.py 1048678
Traceback (most recent call last):
  File "/home/cjwatson/./t.py", line 19, in 
list(apt_pkg.TagFile(f, bytes=True))
apt_pkg.Error: E:Unable to parse package file  (1)

(I'm not sure exactly why the threshold is 1024*1024+102; presumably the
resize steps don't quite take us through exact powers of two.)

We actually encountered this in practice.  Somebody uploaded a kernel
package to Launchpad with a ~2.4 MiB .changes file, mostly consisting of
a probably-autogenerated changelog with lots of commit messages, and the
upload failed due to this.

I think I'd prefer this *not* to be configurable, to minimize situations
where tag files can be parsed in some environments but not others.  I
don't know whether it's possible to reasonably avoid having an arbitrary
limit at all.  Even if not, 1 MiB seems pretty small compared to memory
sizes these days; perhaps this could be raised?

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

Kernel: Linux 5.15.0-41-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_LIVEPATCH
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages apt depends on:
ii  adduser 3.127
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.35-3
ii  libapt-pkg6.0   2.5.2
ii  libc6   2.34-4
ii  libgcc-s1   12.2.0-1
ii  libgnutls30 3.7.7-2
ii  libseccomp2 2.5.4-1+b1
ii  libstdc++6  12.2.0-1
ii  libsystemd0 251.4-1

Versions of packages apt recommends:
ii  ca-certificates  20211016

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.21.9
ii  gnupg2.2.35-3
ii  gnupg1   1.4.23-1.1+b1
ii  gnupg2   2.2.35-3
ii  powermgmt-base   1.37

-- no debconf information

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#1017356: libpmix2: symbol lookup error: undefined symbol: pmix_value_load

[Drew Parsons]

The 4.1.2 workaround will want the pandoc drop patched in from 4.2.0 to 
build on the minor arches.

Bug#1017541: auditd: Fails to generate/log events after systemd upgrade

[Michael Biebl]

Hi Sven

Am 31.08.22 um 14:01 schrieb Sven Mueller:

On Tue, Aug 30, 2022 at 9:49 PM Michael Biebl  wrote:


Am 30.08.22 um 19:46 schrieb Michael Biebl:


Am 30.08.22 um 19:31 schrieb Michael Biebl:

On Wed, 17 Aug 2022 19:17:16 +0200 Sven Mueller  wrote:


It's reproducible only with systemd upgrades. We've reproduced it with
different versions of systemd, but always upgrading from 249.7-1 to
the version tested.


I assume this reproducer can be further reduced to

systemctl restart systemd-journald

? (which is part of systemd.postinst)


Could you check if replacing
debian/patches/Don-t-enable-audit-by-default.patch with the attached
patch helps?


It was pointed out on IRC that we probably need to initialize the value
with -1 (so it is "unset") instead of simply removing the line.


I'll be honest: I currently don't have the time to test this (ooo for
a while starting on Friday). But it seems unlikely that this change
targets the root cause of our issue. Neither the patch nor the
affected code seems to have changed recently enough (since 249.7-1 -
we did multiple upgrades in between).


This part is indeed weird
git diff v249.7..v250 -- src/journal/
on a cursory glance doesn't show anything which could be the cause of this.


However, a quick test I was able to do was to use `Audit=` in
journald.conf to avoid the issue. Which makes me doubt my own words in
the previous paragraph. But as I said: We didn't run into these issues
with previous upgrades. Which is weird, since the postinst also didn't
change considerably enough to explain it.


Yeah, setting 'Audit=', i.e. an empty string, will have the same effect 
as the patch. So thanks for confirming this is going in the right direction.




You are right, that `systemctl try-restart systemd-journald.service`
is enough to trigger the issue. And I suspect that making .set_audit
default to being unset (-1) would likely avoid our issue (as the test
with Audit= in the config, which should also set it to -1)  seems to
show.


Aside from initializing set_audit to -1, the auditd package could also 
ship a drop-in snippet for journald, setting Audit=yes explicitly.

Not quite sure if that has other side-effects one should be aware of.

So at this point, it's probably best to wait for feedback from Laurent, 
the auditd maintainer.


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990797: most: upstream is now 5.2.0 (was: most: Please package new upstream release (5.1.0))

[Sven Oliver Moll]

Package: most
Version: 5.0.0a-4
Followup-For: Bug #990797

Dear Maintainer,

the upstream version of most is now at 5.2.0.

Please update, or if you are not able to update, please set package to "orphan".

Greetings,
SvOlli


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

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

Versions of packages most depends on:
ii  libc6  2.34-7
ii  libslang2  2.3.3-1

most recommends no packages.

most suggests no packages.

-- no debconf information

Bug#1018830: Acknowledgement (linux-image-5.10.0-17-amd64: SO_RCVLOWAT only works reliably with select but not with recv)

[Michael Becker]

I have now added a SO_RCVTIMEO of ten seconds.
If first calling select the recv call returns after 3 seconds with 700 byte.
If not calling select the recv call returns after 10 seconds with 700 byte and 
errno=0



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008240: Inside mmdebstrap hooks, find /dev/ -type f matches irregular files

[Trent W. Buck]

Andreas Metzler wrote:
> Control: forcemerge 912180 1008240
> 
> FWIW this is a duplicate of 912180.
> AFAIU the upstream bug discussion find uses getdents() and avoids unecessary 
> stats().
> However Linux returns incorrect information.
> The possible performance penalty might be huge.

Thanks for the clarification.

I think the next steps are therefore:

  1. file a bug to against linux (kernel),
 to fix the wrong getdents behaviour.

  2. ensure /usr/share/info/find.info mentions

  * that find on Linux has this incorrect behaviour

  * that it's Linux's fault (linking to #1)

  * that find can't work around it without a significant performance cost

  * if the end user can work around it, how to do so.
e.g. changing "-type f" to "-type f -not -type b -not -type c"

(that example does NOT work)

What do you think?


AFAICT #2 isn't already done upstream, though I may be looking wrong.
https://www.gnu.org/software/findutils/manual/html_mono/find.html
https://git.savannah.gnu.org/cgit/findutils.git/plain/doc/find.texi

AFAICT #1 isn't already done upstream, though I may be looking wrong.
https://docs.kernel.org/admin-guide/reporting-issues.html
https://bugzilla.kernel.org/buglist.cgi?quicksearch=getdents
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux;include=subject%3Agetdents
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux;include=subject%3Afind
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux;include=subject%3Abind

Bug#1018831: curl: CVE-2022-35252: control code in cookie denial of service

[Salvatore Bonaccorso]

Source: curl
Version: 7.84.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for curl.

CVE-2022-35252[0]:
| control code in cookie denial of service

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-35252
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35252
[1] https://curl.se/docs/CVE-2022-35252.html
[2] https://www.openwall.com/lists/oss-security/2022/08/31/2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1018830: linux-image-5.10.0-17-amd64: SO_RCVLOWAT only works reliably with select but not with recv

[Michael]

Package: src:linux
Version: 5.10.136-1
Severity: normal

I have written a server which sets SO_RCVLOWAT to 700, waits to receive 700 
byte, send back 2 byte and exit.
The related client sends 2 packets with 350 byte each, tries to receive two 
byte and exit.

If the server waits on the socket using a select call everything works as 
expected.

If the server calls recv without preceeding select the server hangs until I 
stop the client by hitting ctrl-c.
Wireshark shows that two packets each with 350 byte data are sent to the server 
and are acknowledged by the server. Neverthelss the recv call does not return.

I have removed all error checking to shorten the programs as much as possible.
If you start the server without parameter, it makes a call to select and only 
if that call is successfull it calls recv.
If you start the server with a parameter it does not call select but 
immediately calls recv.

On Debian 8 and 9 everything works as expected in both cases (server started 
with parameter and without parameter).
On Debian 10 and 11 the second variant only works unreliably – in most cases 
the server program hangs and receives the 700 byte only if I stop the client by 
pressing ctrl-c.

/*
 * server.c
 * compile with "gcc -o server server.c
 * run either "./server &" or "./server 1 &"
 * afterwards start the below client with "./client"
 */
#include 
#include 
#include 
#include 

int main(int argc, char ** argv)
{
  struct sockaddr_in sin;
  int listenSocket;
  int rcvSocket;
  socklen_t len;
  struct sockaddr socketAddr;
  struct timeval tv;
  char buffer[700];
  int minBytes;
  fd_set rmask;
  int noWait=0;
  int rcvd;
  int one=1;

  if (argc > 1) {
noWait = 1;
fprintf(stderr, "running without select\n");
  }

  memset((char *) , 0, sizeof(struct sockaddr_in));
  sin.sin_family = AF_INET;
  sin.sin_addr.s_addr = 0x017f;
  sin.sin_port = htons(5756);
  listenSocket = socket(AF_INET, SOCK_STREAM, 0);
  setsockopt(listenSocket, SOL_SOCKET, SO_REUSEADDR, (char *) , 
sizeof(one));
  bind(listenSocket, (struct sockaddr *) , sizeof(sin));
  listen(listenSocket, 1);
  memset(, 0, sizeof(socketAddr));
  len = sizeof(socketAddr);
  rcvSocket = accept(listenSocket, , );

  minBytes = 700;
  setsockopt(rcvSocket, SOL_SOCKET, SO_RCVLOWAT, (char *) , 
sizeof(int));

  tv.tv_sec = 10;
  tv.tv_usec = 0;
  FD_ZERO();
  FD_SET(rcvSocket, );

  if (noWait || select(rcvSocket + 1, , (fd_set *) 0L, (fd_set *) 0L, 
) > 0) {
rcvd = recv(rcvSocket, buffer, 700, 0);
fprintf(stderr, "received %d byte\n", rcvd);
send(rcvSocket, "OK", 2, 0);

shutdown(rcvSocket, SHUT_RDWR);
close(rcvSocket);
  }

  shutdown(listenSocket, SHUT_RDWR);
  close(listenSocket);

  return 0;
}
/*
 * end of server.c
 */

/*
 * client.c
 * compile with "gcc -o client client.c
 * first run either the above "./server &" or "./server 1 &"
 * afterwards start client with "./client"
 */
#include 
#include 
#include 

int main(int argc, char ** argv)
{
  int socketNo;
  char buffer[350];
  struct addrinfo *ai;
  struct addrinfo hints;

  memset(, 0, sizeof(hints));
  hints.ai_family = AF_INET;
  hints.ai_socktype = SOCK_STREAM;
  hints.ai_protocol = IPPROTO_TCP;

  getaddrinfo("localhost", "5756", , );
  socketNo = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP);
  connect(socketNo, ai->ai_addr, ai->ai_addrlen);
  freeaddrinfo(ai);

  memset(buffer, '1', 350);
  send(socketNo, buffer, 350, 0L);
  sleep(3);
  send(socketNo, buffer, 350, 0L);
  recv(socketNo, buffer, 2, 0);

  shutdown(socketNo, SHUT_RDWR);
  close(socketNo);

  return 0;
}
/*
 * end of client.c
 */




-- Package-specific info:
** Version:
Linux version 5.10.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.136-1 (2022-08-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-17-amd64 
root=UUID=72fa6125-16d6-4e09-9dd1-534c91cf447d ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: TUXEDO
product_name: TUXEDO Pulse 14 Gen1
product_version: Standard
chassis_vendor: TUXEDO
chassis_version: Standard
bios_vendor: American Megatrends Inc.
bios_version: N.1.07.A03
board_vendor: TUXEDO Computers
board_name: PULSE1401
board_version: Standard

** Loaded modules:
nfnetlink_queue
nfnetlink_log
vhost_net
vhost
vhost_iotlb
tap
sd_mod
sg
uas
usb_storage
dm_mod
tun
xt_conntrack
ipt_REJECT
nf_reject_ipv4
ctr
ccm
xt_CHECKSUM
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nft_counter
xt_tcpudp
nft_compat
bridge
stp
llc
nf_tables
libcrc32c
nfnetlink
cmac
algif_hash
algif_skcipher
af_alg
bnep
btusb
btrtl
btbcm
btintel
bluetooth
snd_hda_codec_realtek
edac_mce_amd
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
kvm_amd
jitterentropy_rng
snd_hda_intel
iwlmvm
drbg
snd_intel_dspcfg
soundwire_intel
kvm
soundwire_generic_allocation
mac80211
snd_soc_core

Bug#1018811: [Debian-pan-maintainers] Bug#1018811: pyfai: autopkgtest regression on armel and i386

[Jerome Kieffer]

Hi Graham,

Thanks for making me aware ... this is probably related to this PR which was 
just accepted upstream:
https://github.com/silx-kit/pyFAI/pull/1729
Apparently, Michael Hudson-Doyle is from Ubuntu and the bugs addressed are 
exactly those...

Unfortunately, there is no release planed in the foreseeable future ... 
Cheers,

Jerome (upstream author of pyFAI)

On Wed, 31 Aug 2022 08:35:02 +0200
Graham Inggs  wrote:

> Source: pyfai
> Version: 0.21.3+dfsg1-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Hi Maintainer
> 
> The autopkgtests of pyfai have regressed on armel and i386 [1][2],
> where they passed previously (see results of e.g. 0.20.0+dfsg1-3).  I
> have copied what I hope is the relevant part of the log below.
> 
> These test failures are known upstream, as can be seen in the
> following code snippets.
> 
> pyFAI/test/test_histogram.py:
> @unittest.skipIf(UtilsTest.low_mem, "test unreliable on 32bits processor")
> def test_count_csr(self):
> 
> pyFAI/test/test_histogram.py:
> @unittest.skipIf(UtilsTest.low_mem, "test unreliable on 32bits processor")
> def test_numpy_vs_cython_vs_csr_2d(self):
> 
> pyFAI/test/test_csr.py:
> @unittest.skipIf(UtilsTest.low_mem, "test unreliable on 32bits processor")
> def test_2d_nosplit(self):
> 
> This was noticed in Ubuntu, when the upload of glibc 2.36 caused the
> same tests to start failing on armhf.
> 
> Regards
> Graham
> 
> 
> [1] https://ci.debian.net/packages/p/pyfai/unstable/armel/
> [2] https://ci.debian.net/packages/p/pyfai/unstable/i386/
> 
> 
> ==
> FAIL: test_count_csr (pyFAI.test.test_histogram.TestHistogram2d)
> Test that the pixel count and the total intensity is conserved
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py",
> line 339, in test_count_csr
> self.assertTrue(delta == 0, msg="check all pixels were counted")
> AssertionError: False is not true : check all pixels were counted
> 
> ==
> FAIL: test_numpy_vs_cython_vs_csr_2d 
> (pyFAI.test.test_histogram.TestHistogram2d)
> Compare numpy histogram with cython simple implementation
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py",
> line 373, in test_numpy_vs_cython_vs_csr_2d
> self.assertTrue(delta_max <= self.err_max_cnt, "pixel count
> difference numpy/csr : max delta=%s" % delta_max)
> AssertionError: False is not true : pixel count difference numpy/csr :
> max delta=8.0
> 
> ==
> FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR)
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/pyFAI/test/test_csr.py", line
> 195, in test_2d_nosplit
> self.assertLess(error.mean(), 1e-3, "img are almost the same")
> AssertionError: 244.15215998872887 not less than 0.001 : img are almost the 
> same
> 
> --
> Ran 376 tests in 285.382s
> 
> FAILED (failures=3, skipped=10)
> 
> -- 
> Debian-pan-maintainers mailing list
> debian-pan-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers


-- 
Jérôme Kieffer
tel +33 476 882 445

Bug#950993: orage: calendar window doesn't work anymore

[Bzzzz]

On Mon, 08 Aug 2022 10:04:28 +0800
Paul Wise  wrote:


CORRECTION
==

Hi again Paul,

my bad, I did not remember that the sound comes at the exact alarm time
(my parm: open alarm window 1 minute before its triggering time), sounds
came right at the good time.

So, everything's ferpect.

BTW thanks to whoever reintroduced this very useful software into XFCE.

Cheers,

Jean-Yves


> On Sun, 09 Feb 2020 12:12:06 + Jiff wrote:
>
> > - a click on the orage clock opens the calendar window for ~500ms
> >(just the frame, no text) and it closes at once.
>
> orage 4.16.0-1 has been reintroduced into Debian unstable.
>
> Please try it and see if the crash has been fixed.
>
> If the crash has been fixed, please let us know on this bug.
>
> If the crash has not been fixed, please search the upstream bug
> database for orage to see if the crash is already reported and if it
> is not reported, then report a new issue upstream. Please let us know
> about any upstream bugs you file.
>
> https://docs.xfce.org/apps/orage/bugs
>
> I note that there is one segfault bug mentioned, so please try to see
> if that bug report matches the behaviour on your system and if it is
> then you can subscribe to that upstream bug report. Please let us know
> if this bug matches the behaviour on your system.
>
> https://gitlab.xfce.org/apps/orage/-/issues/2
>

Bug#1018829: RM: NBS binaries not built anymore from gcc-defaults-ports

[Matthias Klose]

Package: ftp.debian.org

Please remove the NBS binaries not built anymore from gcc-defaults-ports:

gdc-alpha-linux-gnu, gdc-m68k-linux-gnu, gdc-multilib-sparc64-linux-gnu, 
gdc-sh4-linux-gnu, gdc-sparc64-linux-gnu

Bug#950993: orage: calendar window doesn't work anymore

[Bzzzz]

On Mon, 08 Aug 2022 10:04:28 +0800
Paul Wise  wrote:

> On Sun, 09 Feb 2020 12:12:06 + Jiff wrote:
>
> > - a click on the orage clock opens the calendar window for ~500ms
> >(just the frame, no text) and it closes at once.
>
> orage 4.16.0-1 has been reintroduced into Debian unstable.
>
> Please try it and see if the crash has been fixed.
>
> If the crash has been fixed, please let us know on this bug.

Hi Paul,

Sorry for the delay.

As unstable pkgs were uninstallable because of the lower version of
libc6, I compiled orage from the XFCE gitlab :
* installed all pkgs autogen was ranting about missing,
* also installed libxfce4|panel|ui as they appeared at the end of the
  compilation,
* make,
* make install.

Alarms are now working and orage isn't crashing anymore :)

The only problem I meet is the regular sound (Spo.wav) is not played -
Of course I changed the path from : /usr/share orage/sound/Spo.wav
/usr/local/share orage/sound/Spo.wav in my alarms, the sound command is:
/usr/bin/play, but no sound at all :/
I checked as a user that it is working right from the command line.

So, apart the sound problem, everything's fine.

Thanks,

Jean-Yves



> If the crash has not been fixed, please search the upstream bug
> database for orage to see if the crash is already reported and if it
> is not reported, then report a new issue upstream. Please let us know
> about any upstream bugs you file.
>
> https://docs.xfce.org/apps/orage/bugs
>
> I note that there is one segfault bug mentioned, so please try to see
> if that bug report matches the behaviour on your system and if it is
> then you can subscribe to that upstream bug report. Please let us know
> if this bug matches the behaviour on your system.
>
> https://gitlab.xfce.org/apps/orage/-/issues/2
>

Bug#1011951: python-gevent: Build-Depends: libpython3.9-testsuite

[Emanuele Rocca]

tag 1011951 pending
thanks

Fixed in git:
https://salsa.debian.org/python-team/packages/python-gevent/-/blob/9fc8b389269f5d6415ef1019e81e2a458667829b/debian/changelog

Bug#1002725: RE:evince: printing broken as apparmor denies access to pxgsettings

[Andrej Shadura]

Hi,


A couple of weeks or maybe months ago I noticed Evince started freezing
when I’m trying to print anything. Upon checking the journal, I found
this:

Dec 28 11:04:07 nuevo audit[3361741]: AVC apparmor="DENIED" operation="exec" profile="/usr/bin/evince" 
name="/usr/lib/x86_64-linux-gnu/libproxy/0.4.17/pxgsettings" pid=3361741 comm="sh" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0

Indeed, by switching evince to complain mode, I was able to proceed;
many more messages about attempted (and allowed) attempts to access this
file appeared in the logs.


I’ve submitted a merge request fixing the issue.

https://salsa.debian.org/gnome-team/evince/-/merge_requests/5

--
Cheers,
  AndrejFrom a54f075aa23b51b0ec904a0aecc3402bf2b3c106 Mon Sep 17 00:00:00 2001
From: Andrej Shadura 
Date: Wed, 31 Aug 2022 13:02:10 +0200
Subject: Print dialog requires access to libproxy’s pxgsettings

Closes: #1002725
---
 debian/apparmor-profile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/apparmor-profile b/debian/apparmor-profile
index 95c28421cab9..904f0ead7e3c 100644
--- a/debian/apparmor-profile
+++ b/debian/apparmor-profile
@@ -68,6 +68,9 @@
   /usr/bin/krusader Cx -> sanitized_helper, # KDE
   /usr/bin/thunar Cx -> sanitized_helper,   # XFCE
 
+  # Print Dialog
+  /usr/lib/@{multiarch}/libproxy/*/pxgsettings Cx -> sanitized_helper,
+
   # For Xubuntu to launch the browser
   #include 
 
-- 
2.35.1

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Simon McVittie]

On Wed, 31 Aug 2022 at 06:51:47 -0400, Jeremy Bicha wrote:
> This will also affect Cinnamon once Cinnamon gets around to building
> their cjs fork of gjs with a newer mozjs.

cjs is currently still on mozjs78, so I would not expect this to happen
soon, and I think it should be treated as a separate transition. I hope
they'll skip mozjs91 and proceed directly from mozjs78 to mozjs102,
but I don't know.

The number of packages using cjs is much smaller (I think it's literally
just cinnamon, which is their equivalent of gnome-shell) so their version
of this transition will be much smaller. I expect that when the time
comes, the choices available to the Cinnamon maintainers will be similar
to the ones mentioned in this transition.

As with this transition, I would personally be inclined to remove
cjs:armel, libcjs{0,-dev}:armel and cinnamon:armel, leaving the
cinnamon-core, cinnamon-desktop-environment and task-cinnamon-desktop
Architecure:all metapackages (analogous to GNOME's gnome-core, gnome
and task-gnome-desktop) uninstallable on armel; but I'm not a cinnamon
maintainer and they might decide to proceed differently.

smcv

Bug#1018826: RM: hotswap -- RoQA; orphaned, obsolete hardware support, FTBFS

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove hotswap. It is currently orphaned, was not in bullseye,
currently FTBFS. It provides support for obsolete hardware
(hot-swappable IDE drives), and apparently nobody cares anymore.

Thanks,
Chris

Bug#1018825: RM: vzdump -- RoQA; orphaned, missing kernel support

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove vzdump. It is orphaned for a long time, and requires
kernel patches that have not been in Debian since stretch or older.

Thanks,
Chris

Bug#970917: #970917: vzquota: unusable without kernel support

[Chris Hofstaedtler]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: vzquota -- RoQA; orphaned, missing kernel support
Control: affects -2 src:vzquota
Control: severity -2 normal

Dear ftpmasters,

please remove vzquota. It is orphaned for a long time, and requires
kernel patches that have not been in Debian since stretch or older.

Thanks,
Chris

Bug#970916: #970916: vzctl: unusable without kernel support

[Chris Hofstaedtler]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: vzctl -- RoQA; orphaned, missing kernel support
Control: affects -2 src:vzctl
Control: severity -2 normal

Dear ftpmasters,

please remove vzctl. It is orphaned for a long time, and requires
kernel patches that have not been in Debian since stretch or older.

Thanks,
Chris

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Jeremy Bicha]

This will also affect Cinnamon once Cinnamon gets around to building
their cjs fork of gjs with a newer mozjs.

Thank you,
Jeremy Bicha

Bug#1018822: Exceptions on Python 3.8

[Jelmer Vernooij]

package: python3-debian
severity: important
thanks

I'm get exceptions importing the _deb822_repo module on Python 3.8:

   File 
"/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/copyright.py",
 line 58, in 
from debian._deb822_repro import (
  File 
"/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/_deb822_repro/__init__.py",
 line 166, in 
from debian._deb822_repro.parsing import (
  File 
"/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/_deb822_repro/parsing.py",
 line 12, in 
from debian._deb822_repro._util import (combine_into_replacement, 
BufferingIterator,
  File 
"/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/_deb822_repro/_util.py",
 line 120, in 
_bufferingIterator_Base = collections.abc.Iterator[T]
TypeError: 'ABCMeta' object is not subscriptable

The odd thing is that both 3.7 and 3.9 work fine.


signature.asc
Description: PGP signature

Bug#803502: ITP: osquery -- operating system instrumentation framework

[Petter Reinholdtsen]

Hi,

What is the latest news on getting osquery into Debian?

I notice https://tracker.debian.org/pkg/rocksdb > is already in
place.  Is there a draft packaging anywhere?  If there is need for a
package sponsor, feel free to check
http://www.hungry.com/~pere/debian-sponsoring.html > for my
sponsoring preferences
-- 
Happy hacking
Petter Reinholdtsen

Bug#1018821: gdb: FTBFS with readline 8.2 due to constness changes

[Andreas Beckmann]

Source: gdb
Version: 12.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

gdb FTBFS in sid since readline 8.2 was uploaded there:

/build/gdb-12.1/gdb/completer.c: In function 'char* 
gdb_completion_word_break_characters_throw()':
/build/gdb-12.1/gdb/completer.c:2014:10: error: invalid conversion from 'const 
char*' to 'char*' [-fpermissive]
 2014 |   return rl_completer_word_break_characters;
  |  ^~
  |  |
  |  const char*


Andreas

Bug#1016084: transition: petsc

[Drew Parsons]

On 2022-08-16 21:44, Drew Parsons wrote:


We're conflicted by pmix Bug#1017356.

I would be better if MPI (ucx/pmix) upgrades were handled as a
transition tested first in experimental :(


The pmix problem is now worked around by reverting back to the earlier 
version. I'll proceed with the transition of the numerical stack now.


Drew

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Simon McVittie]

On Wed, 31 Aug 2022 at 06:40:38 +0200, Paul Gevers wrote:
> For avoidance of doubt, I didn't ACK or NACK the transition. I just wanted
> to answer Simon's question about the course of solutions.

I think we'll probably want to swap from a mozjs91-based gjs to a
mozjs102-based gjs either before or during the mutter/Shell transition
(#1018118), because upstream are going to expect to be using a
mozjs102-based gjs for the Shell 43 final release. This is important
if mozjs102 introduced new language features that mozjs91 didn't have;
I don't know whether that's actually true, but it seems wise to err on
the side of caution.

Given the amount of overlap, it might make most sense to combine #1018076
with #1018118.

Jeremy wants to do the libsoup3/e-d-s/etc. transition (#1016706) before
the mutter transition, and that in turn is currently blocked by the
unplanned abseil transition, so we have some time to get everything in
order and do preparations in other packages. I'm preparing an ostree
upload that will disable its gjs build-dependency on armel, and I've
reported a bug asking for the corresponding change in libguestfs.

smcv

Bug#1018819: libguestfs: please mark gjs build-dep as [!armel]

[Simon McVittie]

Source: libguestfs
Version: 1:1.40.2-2
Severity: important
Control: block 1018076 by -1

It is looking as though gjs will need to drop support for the armel
architecture soon, when it switches from being based on mozjs91 to
mozjs102 (due to armel's lack of atomic instructions, #1017979).

libguestfs is one of a few packages that build-depends on gjs for a
test suite. Please could you mark this as [!armel] so that libguestfs
will still be buildable after the transition to mozjs102? This is similar
to what happened in 2018 with s390x (#910287).

gjs seems to work OK on s390x now, so you could either use

gjs [!armel] 

for better test coverage on s390x, or

gjs [!armel !s390x] 

to avoid needing to take action if s390x regresses again. It's up to
you which one you prefer.

If there hasn't been an upload of libguestfs with this change by the time
transition #1018076 is ready to go ahead, then libguestfs will have to
either be NMU'd or have an architecture-specific removal from armel.

Thanks,
smcv

Bug#1017716: ITP: muon-meson -- Meson-compatible build system

[Stephan Lachnit]

Hi Andrea,

I would ofc sponsor this when it is ready to upload.

Wrt to the executable name: have you talked to upstream yet? I'm sure
Debian isn't the only distro that has the muon problem, and I'm sure the
maintainer would not like to see this program having different names on
different distros. Maybe it also makes sense to talk to upstream KDE if
they might consider renaming the executable (even though it is dead, I
think everyone could tag a minor release with such a change).

I think we should definitely avoid that muon has a non-standard binary
name. It is used e.g. as meson build files formatter in certain IDE
extensions, and they will not be aware of this.

Regards,
Stephan


On Fri, Aug 19, 2022 at 2:00 PM Andrea Pappacoda 
wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Andrea Pappacoda 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: muon-meson
>   Version : git HEAD
>   Upstream Author : Stone Tickle 
> * URL : https://muon.build
> * License : GPL-3.0
>   Programming Lang: C
>   Description : Meson-compatible build system
>
> muon is an implementation of the Meson build system in c99 with
> minimal dependencies.
> .
> It uses libpkgconf for dependency discovery, and is close to
> feature-complete with the core of Meson for C and C++.
>
> While still not "stable", muon is capable of compiling quite complex C and
> C++
> projects, and being written in C99 it can greatly help with
> bootstrappability
> when compared to Meson's dependency on a Python interpreter and standard
> library.
>
> The upstream name is "muon", but this package and /usr/bin/ name is already
> used by KDE Muon, a [dead] synaptic alternative.
>
> I'm not sure how to handle this conflict; naming the Debian package "muon-
> meson" or "muon-build" seems fine, but renaming the "muon" binary might be
> less
> desirable.
>
> [dead]: https://www.reddit.com/r/kde/comments/wrnuq3/is_muon_dead/
>
>

Bug#1018223: ITP: zarchive -- Library for creating and reading zstd-compressed file archives

[Stephan Lachnit]

Hi Andrea,

I would love to see cemu in Debian, so I'll gladly sponsor zarchive and
cemu once you think it is ready to review.

Regards,
Stephan


On Sat, Aug 27, 2022 at 1:00 PM Andrea Pappacoda 
wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Andrea Pappacoda 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: zarchive
>   Version : 0.1.1
>   Upstream Author : Exzap 
> * URL : https://github.com/Exzap/ZArchive
> * License : MIT-0
>   Programming Lang: C++
>   Description : Library for creating and reading zstd-compressed file
> archives
>
> ZArchive is yet another file archive format. Think of zip, tar, 7z, etc.
> but
> with the requirement of allowing random-access reads and supporting
> compression.
>
> This is a dependency of cemu, see #1018037
>
>

Bug#1018459: Maintainer proposed patch to remove dep

[Stephan Lachnit]

Hi Felix,

Thank you for quickly taking care of this, please ping me again when the
new version is ready to upload.

Cheers,
Stephan


On Tue, Aug 30, 2022 at 7:24 PM Moessbauer, Felix <
felix.moessba...@siemens.com> wrote:

> Hi,
>
>
>
> I just got into contact with the upstream maintainer.
> He already proposed a patch to remove this dependency and is willing to
> cut a new release after we tested this.
>
> Then I’ll bump the version and close the bug (via Stephan).
>
>
>
> [1] https://github.com/purcell/airspeed/issues/59
>
> --
>
> Siemens AG, Linux Expert Center
> Otto-Hahn-Ring 6, 81739 München, Germany
>
>
>

Bug#1018818: bpfcc: FTBFS with libbpf 1.0.0

[Sudip Mukherjee]

Source: bpfcc
Version: 0.24.0+ds-1
Severity: important
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Tags: ftbfs
Usertags: libbpf1

Dear Maintainer,

bpfcc FTBFS with libbpf 1.0.0 (available in experimental).
These are some of the errors from the build log:

In file included from /<>/src/cc/bcc_libbpf_inc.h:5,
 from /<>/src/cc/libbpf.c:57:
/usr/include/bpf/btf.h: In function ‘btf_enum64_value’:
/usr/include/bpf/btf.h:496:25: error: invalid use of undefined type ‘const 
struct btf_enum64’
  496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
  | ^~


/<>/src/cc/libbpf.c: In function ‘libbpf_bpf_map_create’:
/<>/src/cc/libbpf.c:304:28: error: invalid use of undefined type 
‘struct bpf_create_map_attr’
  304 |   p.map_flags = create_attr->map_flags;
  |^~


/<>/src/cc/libbpf.c: In function ‘bcc_create_map’:
/<>/src/cc/libbpf.c:376:10: error: variable ‘attr’ has initializer 
but incomplete type
  376 |   struct bpf_create_map_attr attr = {};
  |  ^~~
/<>/src/cc/libbpf.c:376:30: error: storage size of ‘attr’ isn’t 
known
  376 |   struct bpf_create_map_attr attr = {};
  |  ^~~~


/<>/src/cc/libbpf.c: In function ‘libbpf_bpf_prog_load’:
/<>/src/cc/libbpf.c:640:37: error: invalid use of undefined type 
‘const struct bpf_load_program_attr’
  640 |   p.expected_attach_type = load_attr->expected_attach_type;
  | ^~


In file included from /<>/src/cc/bcc_libbpf_inc.h:5,
 from /<>/src/cc/libbpf.c:57:
/usr/include/bpf/btf.h: In function ‘btf_enum64_value’:
removing 'bcc-0.24.0' (and everything under it)
/usr/include/bpf/btf.h:496:25: error: invalid use of undefined type ‘const 
struct btf_enum64’
  496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
  | ^~


/<>/src/cc/libbpf.c: In function ‘bpf_attach_xdp’:
/<>/src/cc/libbpf.c:1549:9: warning: implicit declaration of 
function ‘bpf_set_link_xdp_fd’; did you mean ‘bpf_link__fd’? 
[-Wimplicit-function-declaration]
 1549 |   ret = bpf_set_link_xdp_fd(ifindex, progfd, flags);
  | ^~~
  | bpf_link__fd


-- 
Regards
Sudip

Bug#1018169: Acknowledgement (ITP:php-svg-lib -- SVG file parsing / rendering library)

[Katharina Drexel]

The package has been built and is here:
https://salsa.debian.org/php-team/pear/php-svg-lib/

But it will only work with a more actual version of php-horde-css-parser. This
package is in the horde-team section where I can't push, so version 8.4.0 is 
here:
https://github.com/sunflowerbofh/PHP-CSS-Parser/tree/debian/8.4.0

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Sylvain Joubert]

Ok, I just figured out why you probably can't reproduce the issue: you need
to use clang as a compiler.
If you use `CXX=clang++-14 cmake [...]` as a configure command line you'll
likely trigger the error.

And the required package providing OpenMP for clang must match the clang
version used: if I install libomp-13-dev while using clang++-14 for example
I'll still get the error.

With this additional info I get that the issue is triggered with a
non-default setup, so I'm not sure how or even if it can be fixed
correctly. Especially given that the proper dependency is heavily dependent
on the clang version used/installed.
Given that understanding I'd be fine with leaving things as is. And maybe
it's the upstream MathGL2Config.cmake that needs a rework to deal more
easily with various setups.

Anyway, thanks for taking a look.

Le mer. 31 août 2022 à 10:03, Sylvain Joubert  a
écrit :

> Hi,
> Here is the minimal CMakeLists.txt that reproduces the issue:
>
> cmake_minimum_required(VERSION 3.22.0)
> project(mgl_test LANGUAGES CXX)
> find_package(MathGL2 REQUIRED)
>
> If the packages libomp-dev and libomp-XX-dev that it drags (libomp-11-dev
> on stable, libomp-14-dev on my testing setup) are not installed I get the
> initial reported error.
>
>
> Le mar. 30 août 2022 à 22:03, Rafael Laboissière  a
> écrit :
>
>> Control: tags -1 moreinfo
>>
>> * Sylvain Joubert  [2022-03-02 11:17]:
>>
>> >  Package: libmgl-dev
>> >  Version: 8.0.1-1
>> >  Severity: normal
>> >
>> > Dear Maintainer,
>> >
>> > Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm
>> facing the
>> > following error:
>> >
>> >  CMake Error at
>> /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
>> >  (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
>> OpenMP_CXX_LIB_NAMES)
>> >  Call Stack (most recent call first):
>> >  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
>> >  (_FPHSA_FAILURE_MESSAGE)
>> >   /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
>> >  (find_package_handle_standard_args)
>> >   /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
>> >  (find_package)
>> >   /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
>> >  [...]
>> >
>> > It appears the libmgl-dev package is missing a dependency on an OpenMP
>> > related package. Installing libomp-dev fixes the issue though I'm not
>> > sure this is the correct package to depend on.
>>
>> Thank you for the bug report.
>>
>> Could you please provide an example that trigger the bug? For
>> inspiration, look at Bug #1004218 [1] or #1004219 [2].
>>
>> Best,
>>
>> Rafael Laboissière
>>
>>   [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218
>>   [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219
>>
>

Bug#922381: go-mtpfs: Mounted filesystem disappeared shortly

[Julian Gilbey]

> On Fri, Feb 15, 2019 at 10:50:32AM +0100, Kamil Jonca wrote:
> > Package: go-mtpfs
> > Version: 0.0~git20180209.d6f8f3c-1
> > Severity: important
> > 
> > I have lenovo K5 Android phone.
> > when I mount it with:
> > go-mtpfs -dev 'b41adca4' /media/skowronek/
> > 
> > files are visible for a while, but then disappeared - cannot see them 
> > (although they remain on phone)
> > Honestly - i do not know if it is bug in go-mtpfs or libusb lub mtp library.
> 
> Dear Kamil,
> 
> I'm sorry I've taken so long to reply to this report.  I, too,
> observe the same behaviour and do not know its cause.
> 
> I've reported it upstream, but it seems that upstream development has
> stopped, so this may never be fixed.

Dear all,

I've forward this issue upstream, and @mnalis suggested the following
(see https://github.com/hanwen/go-mtpfs/issues/160):

  Does using go-mtpfs -usb-timeout 1 perhaps help?
  
  Are there any errors printed when it stops working?
  If not, perhaps running with -debug usb,mtp might print some info?

If you are still experiencing these issues, please do try this; feel
free to reply directly to GitHub or to this Debian bug report.

Best wishes,

   Julian

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Sylvain Joubert]

Hi,
Here is the minimal CMakeLists.txt that reproduces the issue:

cmake_minimum_required(VERSION 3.22.0)
project(mgl_test LANGUAGES CXX)
find_package(MathGL2 REQUIRED)

If the packages libomp-dev and libomp-XX-dev that it drags (libomp-11-dev
on stable, libomp-14-dev on my testing setup) are not installed I get the
initial reported error.


Le mar. 30 août 2022 à 22:03, Rafael Laboissière  a
écrit :

> Control: tags -1 moreinfo
>
> * Sylvain Joubert  [2022-03-02 11:17]:
>
> >  Package: libmgl-dev
> >  Version: 8.0.1-1
> >  Severity: normal
> >
> > Dear Maintainer,
> >
> > Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm
> facing the
> > following error:
> >
> >  CMake Error at
> /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
> >  (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
> OpenMP_CXX_LIB_NAMES)
> >  Call Stack (most recent call first):
> >  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
> >  (_FPHSA_FAILURE_MESSAGE)
> >   /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
> >  (find_package_handle_standard_args)
> >   /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
> >  (find_package)
> >   /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
> >  [...]
> >
> > It appears the libmgl-dev package is missing a dependency on an OpenMP
> > related package. Installing libomp-dev fixes the issue though I'm not
> > sure this is the correct package to depend on.
>
> Thank you for the bug report.
>
> Could you please provide an example that trigger the bug? For
> inspiration, look at Bug #1004218 [1] or #1004219 [2].
>
> Best,
>
> Rafael Laboissière
>
>   [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218
>   [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219
>

Bug#1018816: podman operations generate warnings from bad parsing of DBUS_SESSION_BUS_ADDRESS

[Paul Millar]

Package: podman
Version: 3.0.1+dfsg1-3+deb11u1
Severity: normal
Tags: upstream

Dear Maintainer,

I have noticed that operations, such as 'podman ps' occationally print 
warning messages.  Here is an example of this:


paul@celebrimbor:~/git/podman (main)$ podman ps 
WARN[] The cgroupv2 manager is set to systemd but there is no systemd user 
session available 
WARN[] For using systemd, you may need to login using an user session 
WARN[] Alternatively, you can enable lingering with: `loginctl 
enable-linger 1000` (possibly as root) 
WARN[] Falling back to --cgroup-manager=cgroupfs
WARN[] The cgroupv2 manager is set to systemd but there is no systemd user 
session available 
WARN[] For using systemd, you may need to login using an user session 
WARN[] Alternatively, you can enable lingering with: `loginctl 
enable-linger 1000` (possibly as root) 
WARN[] Falling back to --cgroup-manager=cgroupfs
CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES
paul@celebrimbor:~/git/podman (main)$ 


I tracked this problem down to the value of DBUS_SESSION_BUS_ADDRESS and 
how podman parses the value of this environment variable.  It appears 
that this environment variable is (in general) a comma-separated list of 
key-value pairs, although I couldn't find a definitive statement on this 
in the DBUS specs.

The podman code in the v3.0 branch (from which bullseye's v3.0.1 is 
tagged) assumes that the environment variable is a single key-value 
pair; i.e., that it contains no commas.  This works fine sometimes; 
e.g.,


paul@celebrimbor:~$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus
paul@celebrimbor:~$ podman ps
CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES
paul@celebrimbor:~$ 


However, sometimes the DBUS_SESSION_BUS_ADDRESS value contains a 'guid' 
item; e.g.,


paul@celebrimbor:~/git/podman (main)$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus,guid=5c5c86e60aa45c4c51dcfa0a630db85e
paul@celebrimbor:~/git/podman (main)$ 


I haven't determined under what circumstances trigger the 
DBUS_SESSION_BUS_ADDRESS environment variable to contain this additional 
'guid' item.  Sometimes it's there and sometimes not.

The presence of the 'guid' item causes some operations (e.g., 'podman 
ps') to issue the above warning.  If the 'guid' item is removed then 
'podman ps' works as expected:


paul@celebrimbor:~/git/podman (main)$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus,guid=5c5c86e60aa45c4c51dcfa0a630db85e
paul@celebrimbor:~/git/podman (main)$ DBUS_SESSION_BUS_ADDRESS=$(echo 
$DBUS_SESSION_BUS_ADDRESS | cut -d, -f1) podman ps
CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES
paul@celebrimbor:~/git/podman (main)$ 


This problem appears to be specific to the podman version.  In 
particular, it appears to have been fixed upstream with commit 
732ece6ae2.  This commit touches various parts of the code base. Fixing 
how the DBUS_SESSION_BUS_ADDRESS value is parsed is only one aspect of 
that change.

Commit 732ece6ae2 is available from podman v3.3.0 onwards, but the 
change has not be back-ported to the earlier branches.  Therefore, the 
v3.0 branch (from which v3.0.1 is tagged) contains this assumption about 
the DBUS_SESSION_BUS_ADDRESS value.

I opened an issue against podman in github, requesting that the change 
be back-ported to the v3.0 branch:


https://github.com/containers/podman/issues/15546


This would allow a new v3.0 release (v3.0.3) that Debian could adopt and 
resolve this issue.

The issue was closed, requesting that I open a ticket here (against the 
Debian package) and that I cite the above issue as context.

At the risk of pointing out the obvious, I would suggest there are four 
ways to resolve this issue:

 1. Fix DBUS_SESSION_BUS_ADDRESS so it never includes the 'guid' value.

 2. Pursuade upstream to back-port (part of) commit 732ece6ae2 to the 
v3.0 branch and make another release (v3.0.3) that Debian could 
adopt.

 3. Patch the v3.0.1 source code (using part of commit 732ece6ae2) 
within the Debian build process.

 4. Adopt a newer version of podman in bullseye.  I see that bookworm is 
currently set to use v3.4.7.


For me, this is a relatively minor problem, as I know how to work around 
it; however, it may cause others to waste time searching for a solution.


Moreover, there are several web pages / forum posts that describe these 
symptoms but do not make a correct diagnostic about what is the 
underlying problem.  Therefore, I think there is a risk that people may 
make unnecessary configuration changes or configure their system 
sub-optimally.

Cheers,
Paul.

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

Kernel: Linux 5.10.0-17-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),