Bug#1053348: atop gets a segmentation fault

[Tiger!P]

On Tue, May 28, 2024 at 07:22:56PM +0200, Marc Haber wrote:
> On Sun, Jan 14, 2024 at 07:38:25PM +0100, Tiger!P wrote:
> > I have not seen a segfault with 2.10.0-1 yet.
> > I have updated atop to 2.10.0-1 on multiple system and will report when
> > I see a crash again.
> 
> Are you fine with me marking this report as "closed with version
> 2.10.0-1"?

Yes, you can close the report.
Thank you for the support.

Tiger!P

Bug#1071251: apt install deletes a lot of packages

[Darek P]

Package: apt
Version: 2.7.12

When I tried to install `ddd` with `apt install ddd` apt removed a lot of
"not related" packages.

Start-Date: 2024-05-12 17:37:20
Commandline: apt install ddd
Requested-By: dpiwowarski (1000)

Install: libv4lconvert0t64:amd64 (1.26.1-4+b1, automatic),
libv4lconvert0t64:i386 (1.26.1-4+b1, automatic), libpcap0.8t64:amd64
(1.10.4-5, automatic), libpcap0.8t64:i386 (1.10.4-5, automatic), ddd:amd64
(1:3.3.12-5.4+b1), libwine:amd64 (9.0~repack-4+b1, automatic),
libhogweed6t64:amd64 (3.9.1-2.2, automatic), libhogweed6t64:i386
(3.9.1-2.2, automatic), libv4l-0t64:amd64 (1.26.1-4+b1, automatic),
libv4l-0t64:i386 (1.26.1-4+b1, automatic), libodbc2:amd64 (2.3.12-1+b2,
automatic), libpsl5t64:amd64 (0.21.2-1.1, automatic), libpsl5t64:i386
(0.21.2-1.1, automatic), libdv4t64:amd64 (1.0.0-17.1, automatic),
libdv4t64:i386 (1.0.0-17.1, automatic), libopencore-amrnb0:i386
(0.1.6-1+b1, automatic), libopencore-amrwb0:i386 (0.1.6-1+b1, automatic),
libreadline8t64:amd64 (8.2-4, automatic), libcups2t64:amd64 (2.4.7-1.2+b1,
automatic), libcups2t64:i386 (2.4.7-1.2+b1, automatic), libnettle8t64:amd64
(3.9.1-2.2, automatic), libnettle8t64:i386 (3.9.1-2.2, automatic),
libatspi2.0-0t64:amd64 (2.52.0-1, automatic), libcurl3t64-gnutls:amd64
(8.7.1-5, automatic), libcurl3t64-gnutls:i386 (8.7.1-5, automatic),
libosmesa6:amd64 (24.0.6-1+b1, automatic), libasound2t64:amd64
(1.2.11-1+b1, automatic), libasound2t64:i386 (1.2.11-1+b1, automatic),
libsoup-3.0-0:i386 (3.4.4-5+b1, automatic), libssh2-1t64:amd64
(1.11.0-4.1+b2, automatic), libssh2-1t64:i386 (1.11.0-4.1+b2, automatic),
libxt6t64:amd64 (1:1.2.1-1.2, automatic), libgirepository-2.0-0:amd64
(2.80.1-1, automatic), libxtst6:i386 (2:1.2.3-1.1+b1, automatic),
wine64:amd64 (9.0~repack-4+b1, automatic), libllvm17t64:amd64 (1:17.0.6-12,
automatic), libllvm17t64:i386 (1:17.0.6-12, automatic),
libgphoto2-6t64:amd64 (2.5.31-2.1+b1, automatic), libgphoto2-6t64:i386
(2.5.31-2.1+b1, automatic), liborc-0.4-0t64:amd64 (1:0.4.38-1, automatic),
liborc-0.4-0t64:i386 (1:0.4.38-1, automatic), libcurl4t64:amd64 (8.7.1-5,
automatic), libcurl4t64:i386 (8.7.1-5, automatic), libatk1.0-0t64:amd64
(2.52.0-1, automatic), libgnutls-dane0t64:amd64 (3.8.5-2, automatic),
libflac12t64:amd64 (1.4.3+ds-2.1, automatic), libflac12t64:i386
(1.4.3+ds-2.1, automatic), libgphoto2-port12t64:amd64 (2.5.31-2.1+b1,
automatic), libgphoto2-port12t64:i386 (2.5.31-2.1+b1, automatic),
libcapi20-3t64:amd64 (1:3.27-3.1, automatic), libcapi20-3t64:i386
(1:3.27-3.1, automatic), libsysprof-capture-4-dev:amd64 (46.0-1,
automatic), libdw1t64:amd64 (0.191-1+b1, automatic), libdw1t64:i386
(0.191-1+b1, automatic), libssl3t64:amd64 (3.2.1-3, automatic),
libssl3t64:i386 (3.2.1-3, automatic), libgnutls30t64:amd64 (3.8.5-2,
automatic), libgnutls30t64:i386 (3.8.5-2, automatic), libmpg123-0t64:amd64
(1.32.6-3, automatic), libmpg123-0t64:i386 (1.32.6-3, automatic),
libduktape207:i386 (2.7.0-2+b1, automatic), libgtk-3-0t64:amd64 (3.24.41-4,
automatic), libmotif-common:amd64 (2.3.8-3.1, automatic),
libpng16-16t64:amd64 (1.6.43-5, automatic), libpng16-16t64:i386 (1.6.43-5,
automatic), libatk-bridge2.0-0t64:amd64 (2.52.0-1, automatic),
libelf1t64:amd64 (0.191-1+b1, automatic), libelf1t64:i386 (0.191-1+b1,
automatic), libxm4:amd64 (2.3.8-3.1, automatic), libglib2.0-0t64:amd64
(2.80.1-1, automatic), libglib2.0-0t64:i386 (2.80.1-1, automatic),
libimlib2t64:amd64 (1.12.1-1.1, automatic)

Upgrade: libpulse0:amd64 (16.1+dfsg1-3, 16.1+dfsg1-5), libpulse0:i386
(16.1+dfsg1-3, 16.1+dfsg1-5), libglib2.0-dev-bin:amd64 (2.78.4-1,
2.80.1-1), libgdk-pixbuf2.0-bin:amd64 (2.42.10+dfsg-3+b1,
2.42.10+dfsg-3+b3), libglx-mesa0:amd64 (23.3.5-1, 24.0.6-1+b1),
libglx-mesa0:i386 (23.3.5-1, 24.0.6-1+b1), libproxy1v5:amd64 (0.4.18-2,
0.5.6-1), libproxy1v5:i386 (0.4.18-2, 0.5.6-1), malcontent:amd64 (0.11.1-1,
0.11.1-3), libglib2.0-bin:amd64 (2.78.4-1, 2.80.1-1), libglib2.0-dev:amd64
(2.78.4-1, 2.80.1-1), gir1.2-gstreamer-1.0:amd64 (1.22.10-1, 1.24.3-1),
gstreamer1.0-gl:amd64 (1.22.10-1, 1.24.3-1), gir1.2-freedesktop:amd64
(1.78.1-15, 1.80.1-2), libpulsedsp:amd64 (16.1+dfsg1-3, 16.1+dfsg1-5),
libwine:i386 (9.0~repack-4, 9.0~repack-4+b1), gir1.2-glib-2.0:amd64
(1.78.1-15, 2.80.1-1), openjdk-17-jdk-headless:amd64 (17.0.10+7-1,
17.0.11+9-1), libcairo2:amd64 (1.18.0-1+b1, 1.18.0-3+b1), libcairo2:i386
(1.18.0-1+b1, 1.18.0-3+b1), libgbm1:amd64 (23.3.5-1, 24.0.6-1+b1),
libgbm1:i386 (23.3.5-1, 24.0.6-1+b1), libgbm-dev:amd64 (23.3.5-1,
24.0.6-1+b1), libpcap0.8-dev:amd64 (1.10.4-4, 1.10.4-5),
pulseaudio-utils:amd64 (16.1+dfsg1-3, 16.1+dfsg1-5), at-spi2-core:amd64
(2.50.0-1+b1, 2.52.0-1), cups-client:amd64 (2.4.7-1+b1, 2.4.7-1.2+b1),
cups-ppdc:amd64 (2.4.7-1+b1, 2.4.7-1.2+b1), libpng-dev:amd64 (1.6.43-1,
1.6.43-5), cups-daemon:amd64 (2.4.7-1+b1, 2.4.7-1.2+b1),
libproxy1-plugin-networkmanager:amd64 (0.4.18-2, 0.5.6-1),
libfreetype6:amd64 (2.13.2+dfsg-1+b1, 2.13.2+dfsg-1+b4), libfreetype6:i386
(2.13.2+dfsg-1+b1, 2.13.2+dfsg-1+b4), libgstreamer-gl1.0-0:amd64

Bug#1070251: tt-rss: LibXML error 4 at line 1 (column 1): Start tag expected, '<' not found

[Tiger!P]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1.2
Severity: important

Dear Maintainer,

At the moment I have a few RSS-feeds that have an error and more feeds are
getting the same error.

"LibXML error 4 at line 1 (column 1): Start tag expected, '<' not found"

This is shown at least for the following feeds:
https://gohugo.io/news/index.xml
http://www.blender.org/feed/
https://blog.gitea.io/index.xml

When I look at the feeds themselves, I do not see an issue with them, so I
would expect that tt-rss would be able to handle them.

It might have to do with a libxml2 package update I did recently.
2024-05-01 22:22:55 upgrade libxml2:amd64 2.9.14+dfsg-1.3+b2 2.9.14+dfsg-1.3+b3

I already restarted tt-rss, but this does not solve the issue.


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/4 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

Versions of packages tt-rss depends on:
ii  dbconfig-common   2.0.24
ii  dbconfig-mysql2.0.24
ii  debconf [debconf-2.0] 1.5.86
ii  fonts-material-design-icons-iconfont  6.7.0+dfsg-1
ii  init-system-helpers   1.66
ii  libapache2-mod-php8.2 [php-json]  8.2.12-1+b1
ii  libjs-dojo-core   1.17.2+dfsg1-2.1
ii  libjs-dojo-dijit  1.17.2+dfsg1-2.1
ii  libjs-scriptaculous   1.9.0-3
ii  lsb-base  11.6
ii  php   2:8.2+93
ii  php-cli   2:8.2+93
ii  php-intl  2:8.2+93
ii  php-json  2:8.2+93
ii  php-mbstring  2:8.2+93
ii  php-mysql 2:8.2+93
ii  php-pgsql 2:8.2+93
ii  php-php-gettext   1.0.12-6
ii  php-psr-log   1.1.4-2
ii  php-xml   2:8.2+93
ii  php8.2 [php]  8.2.12-1
ii  php8.2-cli [php-json] 8.2.12-1+b1
ii  php8.2-fpm [php-json] 8.2.12-1+b1
ii  php8.2-intl [php-intl]8.2.12-1+b1
ii  php8.2-mbstring [php-mbstring]8.2.12-1+b1
ii  php8.2-pgsql [php-pgsql]  8.2.12-1+b1
ii  php8.2-phpdbg [php-json]  8.2.12-1+b1
ii  php8.2-xml [php-xml]  8.2.12-1+b1
ii  phpqrcode 1.1.4-3.1
ii  sysvinit-utils [lsb-base] 3.09-1

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.58-1+b1
ii  ca-certificates 20240203
ii  nginx [httpd]   1.24.0-2+b1
ii  php-curl2:8.2+93
ii  php-gd  2:8.2+93
pn  php-mcrypt  
ii  php8.2-curl [php-curl]  8.2.12-1+b1
ii  php8.2-gd [php-gd]  8.2.12-1+b1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/tt-rss/config.php changed [not included]

-- debconf information:
  tt-rss/passwords-do-not-match:
* tt-rss/database-type: pgsql
  tt-rss/mysql/method: Unix socket
  tt-rss/pgsql/authmethod-admin: ident
  tt-rss/install-error: abort
  tt-rss/mysql/admin-user:
  tt-rss/dbconfig-reinstall: false
  tt-rss/pgsql/manualconf:
  tt-rss/internal/skip-preseed: false
  tt-rss/dbconfig-remove: true
* tt-rss/self_url_path: http://localhost/
  tt-rss/db/basepath:
  tt-rss/mysql/authplugin: default
  tt-rss/missing-db-package-error: abort
* tt-rss/dbconfig-install: true
  tt-rss/internal/reconfiguring: false
  tt-rss/remove-error: abort
* tt-rss/reconfigure-webserver:
  tt-rss/pgsql/changeconf: false
  tt-rss/dbconfig-upgrade: true
* tt-rss/remote/host: localhost
  tt-rss/pgsql/method: TCP/IP
  tt-rss/db/app-user: ttrss@localhost
  tt-rss/purge: false
  tt-rss/upgrade-backup: true
  tt-rss/db/dbname: ttrss
  tt-rss/upgrade-error: abort
  tt-rss/remote/port:
  tt-rss/pgsql/no-empty-passwords:
  tt-rss/pgsql/admin-user: postgres
  tt-rss/pgsql/authmethod-user: password
  tt-rss/remote/newhost: localhost

Bug#1069280: Offer to co-maintain or adopt less

[P. J. McDermott]

Milan,

I see you're at least catching up on src:less bug reports, so I won't
pursue the salvaging process.  But my offer to help co-maintain still
stands.

Either way, as a reminder in case it helps you, in my Salsa fork[1] I:

  * Updated to the latest upstream release version 643, closing bugs
#1069037, #901071, #1059967, #931216, and #977494
  * Worked around tests broken since version 632
  * Dropped End-OSC8-hyperlink-on-invalid-embedded-escape-sequen.patch,
applied upstream
  * Refreshed debian/patches/02-655926-more_can_go_backwards.patch
  * Added GNU/Hurd PATH_MAX FTBFS patch from #1060420, applied upstream
  * Fixed lintian old-fsf-address-in-copyright-file,
trailing-whitespace, uses-debhelper-compat-file, and
package-uses-old-debhelper-compat-version (all lintian tags
including info and pedantic are fixed)
  * Added patches (one from upstream, one from me applied upstream) to
fix troff warnings introduced in upstream versions 595 and 608
  * Added DEP-3 headers to debian/patches/less-is-more-434417.patch and
debian/patches/02-655926-more_can_go_backwards.patch both of which I
forwarded upstream (and the latter was accepted)
  * Added .gitignore to fix gbp-buildpackage complaining about .pc/
  * Added debian/salsa-ci.yml

I've rebased upon Salvatore's NMU.  Let me know if I should request
commit access on Salsa to debian/less.git (as a non-DD I don't
automatically have access).  It looks like you have merge requests
disabled.

Feel free to take any or all of my changes and exclude any you don't
like, such as the Uploaders change.

[1]: https://salsa.debian.org/pehjota/less
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/


pgpyTs9yKP1Ww.pgp
Description: OpenPGP digital signature

Bug#1063501: building curl from source fails the island test

[P. J. McDermott]

Hi josch,

On 2024-04-21 at 01:26, Johannes Schauer Marin Rodrigues wrote:
> Quoting Milan Kupcevic (2024-04-21 01:03:12)
> > On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:  
> > > How about using the upstream git instead of the release tarball as the 
> > > base for
> > > the packaging?  
> > I would rather stick with the official release tarballs as they get signed
> > with the upstream developer's key.  
> 
> I think we just recently had a long discussion in Debian about using the
> upstream git as source for the packaging instead of the release tarball in the
> light of how the recent xz-utils attack was performed. Maybe you can convince
> upstream to sign their git commits and/or tags.

It's actually more than just commit/tag signing.  Upstream releases[1]
"RECOMMENDED" release and "BETA" versions, doesn't distinguish[2]
between them in Git tags[3], and tells users to get release versions as
tar archives[4] and only use the Git repository for developing less[5].

[1]: https://www.greenwoodsoftware.com/less/download.html
[2]: https://github.com/gwsw/less/issues/441
[3]: https://github.com/gwsw/less/tags
[4]: https://github.com/gwsw/less/issues/245#issuecomment-1012323104
[5]: https://github.com/gwsw/less/blob/5e425e2/README#L20
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/


pgpSQxAXR5WeB.pgp
Description: OpenPGP digital signature

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-20 at 16:19, Christoph Anton Mitterer wrote:
> On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote:
> > Then the salvage procedure can play out for the full 28+ days
> > specified
> > by developers-reference (21 days to allow the maintainer to object
> > followed by a DELAYED/7 adoption upload).  I've already soft-proposed
> > to
> > salvage in bug #1069280 yesterday.  And as mentioned there I'm not
> > yet a
> > DD or DM, so I'd need to find a sponsor (and access to
> > debian/less.git).  
> 
> In the light of the recent XZ backdoor, wouldn't it generally be more
> desirable to get more co-maintainers, rather than replacing an existing
> one?

Sure, that's exactly the plan.  I don't intend to remove or prevent
anyone from co-maintaining src:less.  Note that my proposal to adopt,
co-maintain, or salvage (bug #1069280) said that I would keep the
current maintainer in Uploaders or Maintainer unless he requests
otherwise.  My intent is not to force out the existing maintainer,
but to help where he seems to have been too busy to properly maintain
src:less for at least two years.  (No shame in being busy, but it looks
like the package could use some help keeping up with new upstream
releases, security issues like these, etc.)

And the repository is already in the "debian" Salsa group (formerly
"collab-maint" on Alioth), where any DD can commit to it.  Also, if I
adopt or salvage src:less, I plan to allow low-threshold NMU[1].  Other
than that, I don't know of an appropriate team for it.

[1]: https://wiki.debian.org/LowThresholdNmu
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-19 at 15:55, Salvatore Bonaccorso wrote:
> Hi,
> 
> FWIW, I'm actually preparing a security update for the two CVEs and
> for bookworm I was first planning to do a 590-2.1 reaching unstable,
> and so then 590-2.1~deb12u1 for bookworm.
> 
> But if you want to override it with a NMU and proposing to salvage the
> package this is equally fine.

Your DELAYED/2 NMU is probably the fastest and best way to get these
CVEs fixed in unstable and bookworm, so that's fine, thanks.  Any plans
for 551-2 in bullseye?  The two patches in your NMU apply cleanly there.

Then the salvage procedure can play out for the full 28+ days specified
by developers-reference (21 days to allow the maintainer to object
followed by a DELAYED/7 adoption upload).  I've already soft-proposed to
salvage in bug #1069280 yesterday.  And as mentioned there I'm not yet a
DD or DM, so I'd need to find a sponsor (and access to debian/less.git).

If your NMU and my salvaging procedure go through, I'll rebase my work
upon and acknowledge your NMU.  And I'd like to backport a 643-1 to
bookworm and bullseye sloppy (and update bullseye-backports with your
NMU, unless you do that).

You and I both apparently made the exact same changes to backport the
CVE-2024-32487 patch (except your patch still has the original upstream
diffstat instead of the backport, which is fine), so that's a good
confirmation that my patch was (and yours is) correct.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-12 at 16:10, Christoph Anton Mitterer wrote:
> Hey.
> 
> There seems to be a somewhat similar issue reported by Jakub Wilk on
> oss-security:
> https://www.openwall.com/lists/oss-security/2024/04/12/5
> 
> where quoting causes troubles (though I couldn't replay the demo).

That was since assigned CVE-2024-32487 and Debian bug #1068938.

> Any chance to get both fixed in Debian unstable?

While the maintainer appears to be somewhat active elsewhere in Debian,
this package hasn't seen an upload in over a year and the packaged
version is getting close to three years old.  (Although I found that
updating to the latest upstream release version introduces new test
suite and lintian issues requiring some upstream patches backported and
reverted/fixed.)

In my Salsa fork[1] I have updated the package (fixing CVE-2022-48624)
and backported (with necessary code changes) the CVE-2024-32487 fix.
I would like to adopt, co-maintain, or if necessary salvage src:less
(see bug #1069280).  But the procedure[2] for that requires 28 days of
waiting for the maintainer to respond.  Perhaps in the meantime a new
upstream version NMU is warranted, or should the procedure be sped up
somehow?

[1]: https://salsa.debian.org/pehjota/less
[2]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#how-to-salvage-a-package
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1069280: Offer to co-maintain or adopt less

[P. J. McDermott]

Source: less
Severity: important
X-Debbugs-Cc: Milan Kupcevic 

Milan,

Although you're still somewhat active in Debian (e.g. on src:simulide),
you appear to be busy, which is understandable and common.  I'd like to
help maintain src:less by either joining as a co-maintainer in Uploaders
or adopting the package as its primary Maintainer (and keeping you in
Uploaders unless you disagree).

In my Salsa fork[1] I have already updated to the latest upstream
release version 643, noting five fixed Debian bugs including one CVE.
Then I backported four upstream patches: one for the other CVE (patch
required changes to apply), one to fix a Debian FTBFS bug, and two
trivial patches (one authored by me and accepted upstream) to fix
lintian warnings introduced in the new upstream version.  I also
reverted an upstream change that broke tests, but this should
be investigated further to fix upstream.  Finally, I updated
debian/copyright, Rules-Requires-Root, and debhelper-compat, which all
cleared some existing lintian tags.

I plan to also apply some lesspipe etc. patches from the BTS and from
another Salsa fork, as well as forward upstream debian/patches/* (and
maybe at least one patch from the BTS).  Also on the BTS there are some
old fixed bugs that can be closed and some that could maybe be fixed.

I am not a DD or DM however, so I will need you or another DD to
grant[2] me access to debian/less.git and to sponsor uploads.

I may also be interested in helping maintain src:gzip and/or src:avrdude
in the future (I don't use any of your six other packages), but for now
I'm focusing on src:less as the most critical package.

If I don't see a response here or other activity on src:less by you
within the next week or so, I will retitle this bug report to an ITS.
I will consider this first message the start of the 21 days specified
in developers-reference[3] (during which you're welcome to object to
salvaging) before seeking a sponsor for a DELAYED/7 upload with me as
Maintainer and you in Uploaders.

Although the CVE bugs (now marked grave severity) may justify uploading
sooner, perhaps as an NMU initially.

I believe src:less is eligible[4][5] for salvaging given the lack of
maintainer uploads or VCS commits in over a year, three new upstream
release versions not packaged for almost three years, several bug
reports with no maintainer activity[6] in over two years[7], two CVEs
(#1064293 and #1068938), an arguable DFSG violation (#1063501), and
several patches in the BTS (including #1060420 applied upstream).

[1]: https://salsa.debian.org/pehjota/less
[2]: 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
[3]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#how-to-salvage-a-package
[4]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#when-a-package-is-eligible-for-package-salvaging
[5]: https://wiki.debian.org/PackageSalvaging
[6]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;correspondent=milan%40debian.org;ordering=raw;src=less
[7]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004383;msg=7
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#601356: Good Day

[P Slade]

 
Good Day, My name is Paul Slade, I have a genuine business to
transact with you. Please get back to me  for more details please it's
very
important.
 
Thanks,
 
Paul Slade.
--
P Slade
Отправлено из Почты  Mail.ru

Bug#1065110: ypbind-mt: FTBFS: missing build-dep on libnsl-dev

[Francesco P. Lovergine]

On Thu, Feb 29, 2024 at 10:03:53PM +0100, Aurelien Jarno wrote:


This could be fixed by adding an explicit Build-Depends on libnsl-dev.
The glibc change will likely be reverted in the short term, but given
its a change we want to do for Trixie, this will only lower the severity
of the bug.

Regards
Aurelien



Thanks, this seems the less impacting solution.

--
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1059393: openssh: CVE-2023-51767

[P Tamil Selvam]

Hi Team,

Pls. let us know the ETA by when openssh issue will be fixed in bookworm 
release ?

Regards,
Tamil Selvam .P

Bug#1061290: RFS: rgbds/0.7.0-3 [ITP] -- Game Boy ASM programming tools

[P. J. McDermott]

I'm not a DD so I can't upload this, but I took a look.  I see you've
addressed most of the comments on Mentors in the repository on GitHub,
so I'm reviewing that rather than the older upload on Mentors.

Build-Depends lists pkg-config, which is a transitional package since
bookworm that should be replaced with the newer pkgconf.  lintian warns
about this:

W: rgbds source: build-depends-on-obsolete-package Build-Depends: 
pkg-config => pkgconf

This is just a suggestion/tip and not at all required, but it's popular
to use `wrap-and-sort -ast` to put each dependency on its own line (with
a trailing comma).  This would make the diff clearer in commits like
d1842536 and 22baba8b.

The years in the Copyright field of the "Files: *" stanza of d/copyright
look outdated: "1997-2020" when LICENSE says "1997-2023" since commit
f8af5696.

Not required by all sponsors, but Emmanuel on Mentors and Tobias here
suggested maintaining the packaging Git repository on Salsa (and
updating the Vcs- fields):

https://salsa.debian.org/
https://salsa.debian.org/games-team
https://salsa.debian.org/debian

You may also want to look into git-buildpackage with pristine-tar and a
DEP-14 branch layout:

https://honk.sigxcpu.org/piki/projects/git-buildpackage/
https://www.eyrie.org/~eagle/notes/debian/git.html
https://dep-team.pages.debian.net/deps/dep14/

Looks OK otherwise to me, and the package builds fine under sbuild with
no lintian tags (even informational or pedantic) other than the obsolete
package warning above; nice work!  So, once the pkg-config -> pkgconf
switch and copyright years update are done, I think it's good enough for
someone to upload.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063707: liblua5.4-0: C++ library missing all "lua*" function symbols

[P. J. McDermott]

Control: tags -1 - patch

After submitting the aforementioned merge request (and another one with
other improvements including CI pipelines), I see now that the patch
removal was intentional:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032533

On 2023-03-08 at 14:44, Jackson wrote:
> This patchfile undermines that Lua can be built as C++ to manage unwinding
> exceptions; according to the date, it has been in the Debian Lua repository 
> for
> over seven years. For example, future releases of MAME (package: mame) will
> break using USE_SYSTEM_LUA_LIB if this fallacy not resolved, since they link
> their own copy.

I'm not sure what this bug report is trying to say or how `extern "C"`
(simply preventing C++ name mangling) could undermine or break anything
in what is really a C library (C symbol names, just compiled to throw
and catch C++ exceptions).  (Does MAME link against both a system C++
Lua and its own C Lua copy?)  But whatever.

And from https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/4#note_444235
> With this we found that the current c++ library in sid is probably broken 
> (and unused since nobody complained so far)

Yes, it is broken, but I'm trying to use it for the upcoming
wesnoth-1.18 which can now use a system copy of Lua (after over a month
of work toward that goal):
https://github.com/wesnoth/wesnoth/pull/8234

Since lua5.4 was promoted to Ubuntu main in 23.10 and Wesnoth now uses
Lua without modifications, the goal is for wesnoth-1.18 to use the
lua5.4 package supported in Ubuntu main (instead of Wesnoth's embedded
code copy stuck in universe) before the Ubuntu Noble Debian Import
Freeze on 2024-02-29.  So I hope this can somehow be fixed well before
then (wesnoth-1.18 still has to go through NEW before that date).

I found that the reason it is broken with `extern "C"` removed and name
mangling newly enabled is that debian/patches/0001-build-system.patch
links using the export map debian/version-script which doesn't list
the C++ symbols.  Adding the C++ symbols to debian/version-script and
debian/liblua5.4-0.symbols as I attempted in the updated merge requests
would fix this, however C++ symbol names are architecture-specific.
So we'll have to either collect arch-specific names with `(arch=foo)`
tags[1] (by making buildds fail for a while[2]) or switch to using
shlibs[3].  The wiki recommends shlibs: "For C++ libraries it is often
better not to ship symbols files."[1]  Sounds good, especially since
going through multiple uploads and waiting for buildds to fail would
take time.  Except switching to shlibs means losing the version
information noting that the mangled symbols didn't exist before now,
so users who install a package (that uses the C++ library's mangled
symbols) without updating liblua5.4-0 will see run-time linker errors.
To solve that, we need to also bump the C++ library's SONAME version
(which is appropriate anyway, given that the ABI completely changed).
So unless you disagree (or beat me to it), I'll work on switching to
shlibs and bumping the SONAME version.

Restoring `extern "C"` would avoid all this mess and keep the previous
unmangled symbols in case anyone was using the C++ library before now.
But the previous bug report claims that this breaks something (so let's
break everything else instead).

[1]: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries
[2]: https://www.eyrie.org/~eagle/journal/2012-01/008.html
[3]: https://www.eyrie.org/~eagle/journal/2012-02/001.html
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063707: liblua5.4-0: C++ library missing all "lua_*" function symbols

[P. J. McDermott]

tags -1 + patch
thanks

https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/5

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063707: liblua5.4-0: C++ library missing all "lua_*" function symbols

[P. J. McDermott]

Package: liblua5.4-0
Version: 5.4.6-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: p...@pehjota.net

Hi,

Since version 5.4.6-1, liblua5.4-c++.so.0.0.0 defines no "lua_*"
function symbols (only "lua_ident@@LUA_5.4"):

$ readelf -s /usr/lib/x86_64-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_
   101: 000315e0   129 OBJECT  GLOBAL DEFAULT   15 
lua_ident@@LUA_5.4
$ readelf -s /usr/lib/i386-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_
   106: 00030600   129 OBJECT  GLOBAL DEFAULT   15 lua_ident@@LUA_5.4

Version 5.4.4-3 is OK:

$ readelf -s /usr/lib/x86_64-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F 
lua_ | head -n 5
   102: a610   220 FUNCGLOBAL DEFAULT   13 
lua_pus[...]@@LUA_5.4
   103: a940   160 FUNCGLOBAL DEFAULT   13 
lua_getfield@@LUA_5.4
   104: a5e048 FUNCGLOBAL DEFAULT   13 
lua_pus[...]@@LUA_5.4
   105: b330   273 FUNCGLOBAL DEFAULT   13 
lua_set[...]@@LUA_5.4
   107: bbf086 FUNCGLOBAL DEFAULT   13 
lua_toclose@@LUA_5.4
$ readelf -s /usr/lib/i386-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_ 
| head -n 5
   107: 678064 FUNCGLOBAL DEFAULT   13 lua_pus[...]@@LUA_5.4
   108: 6a10   173 FUNCGLOBAL DEFAULT   13 lua_getfield@@LUA_5.4
   109: 674060 FUNCGLOBAL DEFAULT   13 lua_pus[...]@@LUA_5.4
   110: 74f0   253 FUNCGLOBAL DEFAULT   13 lua_set[...]@@LUA_5.4
   112: 7c3085 FUNCGLOBAL DEFAULT   13 lua_toclose@@LUA_5.4

The problem is that 0003-extern_C.patch was refreshed but mistakenly
removed from debian/patches/series in version 5.4.6-1 (commit d46ea48)
and then removed completely from debian/patches/ in version 5.4.6-2
(commit 02278c6).

Bug#1060306: [Pkg-clamav-devel] Bug#1060306: clamav on debian oldstable outdated

[p-----berger]

With CVE-2024-20328 
(https://amitschendel.github.io/vulnerabilites/CVE-2024-20328/) and 
CVE-2024-20290 
(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-20290) the 
update now seems urgent! You seem to have released a patch 
(https://blog.clamav.net/2023/11/clamav-130-122-105-released.html) but 
debian oldstable still uses 0.103.10.


t

Am 09.01.24 um 20:57 schrieb Sebastian Andrzej Siewior:

On 2024-01-09 10:09:46 [+0100], p-berger wrote:

Package: clamav
Version: 0.103.10+dfsg-0+deb11u1


The daily logs tell that clamav installation is outdated. I suggest to
bump the oldstable version to a current version like 0.103.11 which is
suggested in the error message.

Here is the error log:

WARNING: Your ClamAV installation is OUTDATED!
 WARNING: Local version: 0.103.10 Recommended version: 0.103.11

Thank you for the report. I saw that, I just didn't get around. I try to
take care of this over the weekend.

Sebastian

Bug#1063147: 'telinit u' infinitely re-exec's itself inside containers

[Daniel P . Berrangé]

Package: systemd-sysv
Version: 255.3-2

Running 'telinit u' within a podman container results in an infinite
loop as telinit repeatedly re-exec's itself.

This behaviour comes from systemctl.c which has this logic for handling
'telinit':

if (sd_booted() > 0) {
arg_action = _ACTION_INVALID;
return telinit_parse_argv(argc, argv);
} else {
/* Hmm, so some other init system is running, we need 
to forward this request to it.
 */
arg_action = ACTION_TELINIT;
return 1;
}

Inside a container 'sd_booted()' will (typically) indicate systemd is
NOT running, thus the 'else' clause will be followed. ACTION_TELINIT
instructs the caller to execve() the telinit binary belonging to any
*non-systemd* init impl, if any.

This binary is determined by the 'telinit-path' meson build option,
which defaults to  /lib/sysvinit/telinit.

Debian used to override this to /usr/lib/sysvinit/telinit, but a few
months ago in Sid, this was changed to point to /usr/sbin/telinit,
which is a symlink back to /usr/bin/systemctl:

  
https://salsa.debian.org/systemd-team/systemd/-/commit/da95bc801088a6ab454851cf01addf97dd2c1ab3

IOW, Debian dpkg build has told systemd that the non-systemd telinit
binary is the systemd telinit binary. Hilarity now ensues as it ends
up exec'ing itself for all eternity :-)


You might ask why should anyone hit this scenario ? Well consider that
the 'libc6' package will run 'telinit u' in its postinst script, if it
sees it is in a non-systemd environment.

Not immediately a problem, since libc6 will be pre-installed in any
container or VM disk image and thus the 'postinst' script won't run
[not sure if 'postinst' is run on upgrades too ?].

Debian containers are an execellent environment for testing cross
compiles though, and thus people will install a foreign arch libc6
package in the container which does trigger the postinst script. The
following hangs (well loops forever in execve()):

  $ podman run -it debian:sid-slim
  # dpkg --add-architecture i386
  # apt-get update
  # apt-get install systemd-sysv
  # apt-get install libc6:i386

Simpler example

  $ podman run -it debian:sid-slim
  # dpkg --add-architecture i386
  # apt-get update
  # apt-get install systemd-sysv strace
  # strace -e trace=execve telinit u
  strace: Process 232065 attached
  execve("/usr/sbin/telinit", ["telinit", "u"], 0x7ffd9b26ba00 /* 24 vars */) = 0
  execve("/usr/sbin/telinit", ["telinit", "u"], 0x7ffdab55f1d0 /* 24 vars */) = 0
  execve("/usr/sbin/telinit", ["telinit", "u"], 0x7ffe79152400 /* 24 vars */) = 0
  100's more times

Even then though, most people won't (knowingly) install the systemd-sysv
dpkg, so won't hit this problem. A few packages will pull in systemd-sysv
behind the scenes, so you can unwittingly hit the problem. For libvirt
CI, we install the open-iscsi and policykit-1 packages which both pull
in  systemd-sysv, so this hangs:

  $ podman run -it debian:sid-slim
  # dpkg --add-architecture i386
  # apt-get update
  # apt-get install systemd-sysv
  # apt-get install open-iscsi:i386

Our foreign arch CI jobs that use Sid are thus suffering broken container
builds right now.

The simple solution appears to be to just remove the '-Dtelinit-path'
option from debian/rules, and leave it on systemd's built-in defaults.
The binary at this default path won't exist, and thus on a non-systemd
execution environment 'telinit u' will simply exit with an error:

  # telinit u
  Couldn't find an alternative telinit implementation to spawn.

which is a sensible behaviour and what has happened in containers with
Debian until recent Sid.  Other distros (eg Fedora) leave the telinit
binary on systemd's default (non-existant) path too.

Possibly the upstream systemctl.c code should be made to protect itself
against such a mis-configuration by setting an env variable it can look
at to detect re-exec of itself.

Possibly libc6 package postinst script should skip running its
'telinit u' action if it detects it is inside a container, though that
could possibly break something if people do have a real in-systemd init
running ? Seems fairly low probability.

With regards,
Daniel

Bug#1061195: ITP: libgeo-wkt-simple-perl -- Simple utils to parse/build Well Known Text(WKT) format string

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libgeo-wkt-simple-perl
  Version : 0.05
  Upstream Contact: Yuto KAWAMURA 
* URL : https://metacpan.org/release/KAWAMURAY/Geo-WKT-Simple-0.05
* License : Perl
  Programming Lang: Perl
  Description : Simple utils to parse/build Well Known Text(WKT) format 
string

 This module can parse/build WKT format string into/from pure Perl data
 structure. It is simpler than Geo::WKT and does not depend on the Proj
 library, and even support MULTI(LINE|STRING|POLYGON) objects.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1060388: sponsor for endless-sky

[P. J. McDermott]

On 2024-01-17 at 10:22, Bo YU wrote:
> Hi,
> 
> First sorry without contacting here before NMU.

Welcome!

> I am looking for a sponsor for my package "endless-sky":

I'm not a DD, but I gave this a look and have a couple comments.

>  * Vcs  : https://salsa.debian.org/games-team/endless-sky

Do you have an account on Salsa?  You could fork the repository and
submit an MR so that the changes are ready to merge and upload.  If not,
that's OK; I think the changes are small enough for one of us to just
commit in one shot.

>  endless-sky (0.10.4-0.1) UNRELEASED; urgency=medium
>  .
>* Non-maintainer upload.
>* New upstream version 0.10.4. (Closes: #1059987)
>* rebase debian/patches

I see out/troff.patch and out/spelling.patch were applied upstream and
removed from debian/patches/series, but the patch files are still under
debian/patches/.  They should be removed.

>* Change Build-Depends on 'cmake' to'cmake (>= 3.21)'.
>  (Closes: #1054624).

(Coincidentally, seeing this bug on Friday reminded me to do a similar
cmake B-D version bump in another package.)

Other than the suggestions of Git and removing patch files, this looks
OK to me for an NMU.  But of course it needs a DD's review (ideally
Damyan).

Since the changes are apparently not in Git, here's the diff I
reviewed:

 changelog |   10 ++
 control   |2 +-
 patches/atomics.patch |   29 ++---
 patches/series|2 --
 4 files changed, 29 insertions(+), 14 deletions(-)
---
diff -Naur endless-sky-0.10.2/debian/changelog 
endless-sky-0.10.4/debian/changelog
--- endless-sky-0.10.2/debian/changelog 2023-10-10 10:57:15.0 -0400
+++ endless-sky-0.10.4/debian/changelog 2024-01-07 20:42:17.0 -0500
@@ -1,3 +1,13 @@
+endless-sky (0.10.4-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version 0.10.4. (Closes: #1059987)
+  * rebase debian/patches
+  * Change Build-Depends on 'cmake' to'cmake (>= 3.21)'.
+(Closes: #1054624).
+
+ -- Bo YU   Mon, 08 Jan 2024 09:42:17 +0800
+
 endless-sky (0.10.2-6) unstable; urgency=medium
 
   [ Adrian Bunk ]
diff -Naur endless-sky-0.10.2/debian/control endless-sky-0.10.4/debian/control
--- endless-sky-0.10.2/debian/control   2023-10-06 09:23:26.0 -0400
+++ endless-sky-0.10.4/debian/control   2024-01-07 20:42:17.0 -0500
@@ -8,7 +8,7 @@
 Vcs-Git: https://salsa.debian.org/games-team/endless-sky.git
 Homepage: https://endless-sky.github.io
 Build-Depends:
- cmake,
+ cmake (>= 3.21),
  debhelper-compat (= 13),
  g++ (>=4.6),
  libgl-dev,
diff -Naur endless-sky-0.10.2/debian/patches/atomics.patch 
endless-sky-0.10.4/debian/patches/atomics.patch
--- endless-sky-0.10.2/debian/patches/atomics.patch 2023-10-05 
06:08:09.0 -0400
+++ endless-sky-0.10.4/debian/patches/atomics.patch 2024-01-07 
20:42:17.0 -0500
@@ -1,17 +1,24 @@
-Description: link with libatomic
- On armel and mipsel, there are a bunch of missing __atomic_load_8 symbols
- during linking
- .
- These are provided by libatomic and that is even in the build-dependencies,
- but is missing on the linker command line.
- .
- The right spot to add it is a bit tricky, appending it to SConstrict near
- 'pthread' doesn't seem to have any effect, but adding to CMakeLists.txt works.
-Author: Damyan Ivanov 
+From: Damyan Ivanov 
+Date: Mon, 8 Jan 2024 07:21:47 +0800
+Subject: link with libatomic
 
+On armel and mipsel, there are a bunch of missing __atomic_load_8 symbols
+during linking
+
+These are provided by libatomic and that is even in the build-dependencies,
+but is missing on the linker command line.
+
+The right spot to add it is a bit tricky, appending it to SConstrict near
+'pthread' doesn't seem to have any effect, but adding to CMakeLists.txt works.
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index fa0903a..d7807e9 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
-@@ -123,7 +123,7 @@ target_link_libraries(ExternalLibraries
+@@ -125,7 +125,7 @@ target_link_libraries(ExternalLibraries INTERFACE 
SDL2::SDL2 PNG::PNG JPEG::JPEG
  if(WIN32)
target_link_libraries(ExternalLibraries INTERFACE rpcrt4 Winmm)
  else()
diff -Naur endless-sky-0.10.2/debian/patches/series 
endless-sky-0.10.4/debian/patches/series
--- endless-sky-0.10.2/debian/patches/series2023-10-05 02:53:48.0 
-0400
+++ endless-sky-0.10.4/debian/patches/series2024-01-07 20:42:17.0 
-0500
@@ -1,3 +1 @@
-out/troff.patch
-out/spelling.patch
 atomics.patch
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1053348: atop gets a segmentation fault

[Tiger!P]

On Sat, Jan 13, 2024 at 09:55:46PM +0100, Marc Haber wrote:
> On Mon, Oct 02, 2023 at 12:50:04PM +0200, Tiger!P wrote:
> > I ran `atop 2` for some time and then it got a segmentation fault.
> > Because it didn't create a core file, I changed settings to get a
> > core file and started atop in the same way.
> 
> Does this still happen with the new atop version in sid?

I have not seen a segfault with 2.10.0-1 yet.
I have updated atop to 2.10.0-1 on multiple system and will report when
I see a crash again.

Tiger!P

Bug#1060757: ITP: libdata-find-perl -- Find data in arbitrary data structures

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libdata-find-perl
  Version : 0.03
  Upstream Contact: Andy Armstrong 
* URL : https://github.com/AndyA/Data--Find
* License : Perl
  Programming Lang: Perl
  Description : Find data in arbitrary data structures

  A simple module to navigate a Perl data structure with
  three exported subroutines (diter, dfind and dwith) 
  and find data occurrences.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1060437: amavisd-new can't scan .F files

[p-----berger]

Package: amavisd-new
Version: 2.11.1 (20181009)


The daily logs tell amavisd-new is not able to scan .F files.

Here is the error log:

Amavis Startup
 Amavis /usr/sbin/amavisd-new
 Version2.11.1 (20181009)
 Antivirus scanners
 Primary internal
 clamav-socket
 Code, modules and external programs
 Not found
 .F tried: unfreeze, freeze -d, 
melt, fcat
 Decoders
 None
 .F tried: unknown
 SpamAssassin plugins




I am using Debian GNU/Linux 11 (bullseye), kernel 5.10.0-23-cloud-arm64

Bug#1060306: clamav on debian oldstable outdated

[p-----berger]

Package: clamav
Version: 0.103.10+dfsg-0+deb11u1


The daily logs tell that clamav installation is outdated. I suggest to bump the 
oldstable version to a current version like 0.103.11 which is suggested in the 
error message.

Here is the error log:

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.103.10 Recommended version: 0.103.11
DON'T PANIC! Readhttps://docs.clamav.net/manual/Installing.html
daily.cld database is up-to-date (version: 27148, sigs: 2050557, f-level: 
90, builder: raynman)
main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, 
builder: sigmgr)
bytecode.cld database is up-to-date (version: 334, sigs: 91, f-level: 90, 
builder: anvilleg)
 
 Your ClamAV installation is OUTDATED!

 Local version: 0.103.10 Recommended version: 0.103.11


I am using Debian GNU/Linux 11 (bullseye), kernel 5.10.0-23-cloud-arm64

Bug#1060213: puredata-import: This Pd object is deprecated and superseeded

[Peter P.]

Package: puredata-import
Severity: normal
X-Debbugs-Cc: peterpar...@fastmail.com

Dear Maintainer,

the [import] object is a specific feature of the old pd-extended
distribution. The object has by now become redundant as there is
[declare]. See the discussion at 
https://lists.puredata.info/pipermail/pd-list//2024-01/132865.html

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

Kernel: Linux 6.1.0-17-rt-amd64 (SMP w/4 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)

Versions of packages puredata-import depends on:
ii  libc6  2.36-9+deb12u3
ii  puredata   0.54.1+ds-2~bpo12+1
ii  puredata-core  0.54.1+ds-2~bpo12+1

Versions of packages puredata-import recommends:
pn  pd-libdir  

puredata-import suggests no packages.

Bug#1060212: pd-pmpd: Update to current version 0.12 and remove recommendation of package puredata-import

[Peter P.]

Package: pd-pmpd
Version: 0.9-7
Severity: normal
X-Debbugs-Cc: peterpar...@fastmail.com

Dear Maintainer,

   * What led up to the situation?
The current version of the pd-pmpd package on Debian stable is 0.9-7
while the upstream software is already at 0.12.
pd-pmpd furthermore recommends puredata-import, which is deprectated,
see discussion at 
https://lists.puredata.info/pipermail/pd-list//2024-01/132865.html

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

Kernel: Linux 6.1.0-17-rt-amd64 (SMP w/4 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)

Versions of packages pd-pmpd depends on:
ii  libc6   2.36-9+deb12u3
pn  pd-libdir   
ii  puredata-core [pd]  0.54.1+ds-2~bpo12+1

Versions of packages pd-pmpd recommends:
pn  pd-import  

pd-pmpd suggests no packages.

Bug#942274: uscan: handling several levels of http links

[P. J. McDermott]

On Sun, 13 Oct 2019 18:36:51 +0200 Samuel Thibault  wrote:
> Package: devscripts
> Version: 2.19.6
> Severity: wishlist
> 
> Hello,
> 
> For the hwloc package, there is on single webpage that references all
> releases.
> 
[...]
> 
> But this doesn't seem supported. Am I missing something or is handling
> several levels of http links not supported?

I've run into this with the 7kaa-music package:
https://salsa.debian.org/games-team/7kaa-music

Upstream lists versions at:
https://www.7kfans.com/download/
That page links to pages such as:
https://www.7kfans.com/download/v2.15.6.html
And those pages link to the tar archive:
https://www.7kfans.com/downloads/7kaa-music-2.15.tar.bz2

So I need uscan to somehow recurse from the main download page to the
latest version's page to find the tar archive link.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1059274: ITP: 7kaa-music -- Seven Kingdoms: Ancient Adversaries - music soundtrack

[P. J. McDermott]

Package: wnpp
Severity: wishlist
Owner: "P. J. McDermott" 
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org, p...@pehjota.net

* Package name: 7kaa-music
  Version : 2.15
  Upstream Author : Bjorn Lynne, Enlight Software Ltd.,
Jesse Allen 
* URL : https://www.7kfans.com/download/
* License : Custom non-free license
  Description : Seven Kingdoms: Ancient Adversaries - music
soundtrack

Seven Kingdoms, designed by Trevor Chan, brings a unique blend of
real-time strategy with the addition of trade, diplomacy, and espionage.

This package contains the optional original music from the 1997 release
of Seven Kingdoms.

---

This package provides the optional music for the 7kaa package, which is
already in Debian and already "Suggests: 7kaa-music (>= 2.15)".

I will maintain this within the Debian Games Team and will get
sponsorship there.

Packaging exists at <https://salsa.debian.org/games-team/7kaa-music> and
is awaiting review and upload by a sponsor.

Bug#1034649: 7kaa: Unplugging USB headset hangs 7kaa

[P. J. McDermott]

Hi Nils,

On Thu, 20 Apr 2023 22:20:34 +0200 Nils Dagsson Moskopp 
 wrote:
> whenever I unplug the USB headset while 7kaa is running, it hangs.
> 7kaa prints a single line of output to the terminal, quoted below:
> 
> > AL lib: (EE) ALCpulsePlayback_streamStateCallback: Received stream failure!

This looks like one of (many[1][2][3][4]) bugs in OpenAL's PulseAudio
backend (apparently OpenAL's upstream maintainer doesn't use PulseAudio,
which I don't either).  I found reports of it affecting at least one
other game.  If we can't solve it here, I'll reassign.

An apparent solution is to edit "/etc/openal/alsoft.conf" and under
"[pulse]" change "allow-moves" to "true".  Can you try this and report
whether that solves the issue?

It's also possible that there's an infinite loop somewhere in 7kaa's
src/openal/openal_audio.cpp triggered by this OpenAL error.  Could you
please install 7kaa-dbgsym, run 7kaa under gdb, reproduce the hang, and
get a backtrace?

$ apt install 7kaa-dbgsym gdb
$ gdb 7kaa
(gdb) run
^C
(gdb) backtrace
(gdb) quit

> Versions of packages 7kaa depends on:
[...]
> ii  libopenal1   1:1.19.1-2

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548373
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551018
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562524
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566634
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1056834: pyfuse3: ftbfs with cython 3.0.x

[Francesco P. Lovergine]

On Mon, Dec 11, 2023 at 12:30:24PM +0100, Sebastiaan Couwenberg wrote:

On 12/11/23 12:04, Francesco P. Lovergine wrote:
Unfortunately pyfuse3 is currently not more actively developedi (see 
it's github page), I wonder if it makes sense maintaining it in 
Debian, even considering the Python

life cycle which far from being slow and could render the whole thing
strongly obsolete even at mid-term.

Removing the package because it's dead upstream makes sense.

The rdeps will need to be updated before it can be removed:

# Broken Depends:
s3ql: s3ql

# Broken Build-Depends:
borgbackup: python3-pyfuse3
borgbackup2: python3-pyfuse3
s3ql: python3-pyfuse3 (3.2.0 >=)
  python3-pyfuse3 (4.0.0 <)



For borg it's a pure recommends. About S3ql it strictly depends
on pyfuse3 which is the async Trio based implementation of the
fuse library. The current status of the whole fuse-in-Python
is quite confused and I guess for such kind of things soon
we will see a general shift to other more performant ecosystems,
such as rust. At the time, I hoped that things would evolve for
the best in the Python ecosystem, but I was too much optimistic...

--
Francesco P. Lovergine

Bug#1056834: pyfuse3: ftbfs with cython 3.0.x

[Francesco P. Lovergine]

Hi folks,

Unfortunately pyfuse3 is currently not more actively developedi (see it's github page), 
I wonder if it makes sense maintaining it in Debian, even considering the Python

life cycle which far from being slow and could render the whole thing
strongly obsolete even at mid-term.

On Sun, Dec 10, 2023 at 10:04:19AM +0100, Sebastiaan Couwenberg wrote:

Control: tags -1 patch

On Sun, 26 Nov 2023 10:06:00 + Matthias Klose wrote:

If the package cannot be built with cython 3.0.5, please change the
build dependency from cython3 to cython3-legacy (available now in
unstable).  There is no replacement for cython3-dbg.


The attached patch switches to cython3-legacy as the short term workaround.

The package still fails to build due to #1042652.

Kind Regards,

Bas

--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



diff -Nru pyfuse3-3.2.1/debian/changelog pyfuse3-3.2.1/debian/changelog
--- pyfuse3-3.2.1/debian/changelog  2022-10-17 04:54:25.0 +0200
+++ pyfuse3-3.2.1/debian/changelog  2023-12-10 09:59:51.0 +0100
@@ -1,3 +1,10 @@
+pyfuse3 (3.2.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to cython3-legacy.
+
+ -- Bas Couwenberg   Sun, 10 Dec 2023 09:59:51 +0100
+
pyfuse3 (3.2.1-2) unstable; urgency=medium

  [ Debian Janitor ]
diff -Nru pyfuse3-3.2.1/debian/control pyfuse3-3.2.1/debian/control
--- pyfuse3-3.2.1/debian/control2022-10-17 04:54:25.0 +0200
+++ pyfuse3-3.2.1/debian/control2023-12-10 09:59:50.0 +0100
@@ -4,7 +4,7 @@
Maintainer: Debian Python Team 
Uploaders: Nikolaus Rath ,
   Francesco Paolo Lovergine 
-Build-Depends: cython3,
+Build-Depends: cython3-legacy,
   debhelper-compat (= 13),
   dh-python,
   fuse3,



--
Francesco P. Lovergine

Bug#1054268: Re: mate-applets: mate weather applet not retrieving data

[Christian P. MOMON]

 Hi,

 This bug is related to the following official ticket:
https://github.com/mate-desktop/libmateweather/issues/123

 This is due to a change of data server URL:
https://github.com/mate-desktop/libmateweather/commit/b75056f5bccf506959a2075305f7e8abbb2502dd
– "https://www.aviationweather.gov/adds/dataserver_current/httpparam;,
+ "https://www.aviationweather.gov/cgi-bin/data/dataserver.php;,

 The fix is merged and available in release 1.26.2:
https://github.com/mate-desktop/libmateweather/releases/tag/v1.26.2
https://github.com/mate-desktop/libmateweather/commits/1.26

 Hope to see the fix soon in bookworm :o)

 Librement,

 Cpm.
--
DEVINSY sarl - Développements en S.I.
http://www.devinsy.fr/
Tél. +33 (0)6 26 72 40 04


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053749: systemd-sysusers: on WSL1, /etc/passwd lock fails, breaks other dpkg postinst

[Max P.]

Package: systemd
Version: 254.5-1
Severity: normal
X-Debbugs-Cc: max+b...@prehl.us

Dear Maintainer,

I am new to submitting bug reports so please bear with me.

I am running Debian Sid in WSL1. As of a few releases ago, systemd and 
systemd-timesyncd started using systemd-sysusers in their dpkg postinst
scripts. It was during some system upgrades that I found out that 
systemd-sysusers is quite broken on the WSL1 system due to a bad lock 
implementation.

You can see several reports in this post:
- https://superuser.com/a/1805742/1298503

I was able to work around this issue by following some of the advice in
the thread.  Moving the postinst scripts temporarily, then running dpkg
--configure, then putting them back.

It was while exploring these scripts that I found the references to
systemd-sysusers.

I tried using systemd-sysusers on it's own and it will not work AT ALL,
it only produces the error:

`Failed to take /etc/passwd lock: Permission denied`

Because it was so badly broken, i also opened a report on the systemd
upstream repo:
- https://github.com/systemd/systemd/issues/29512

I'm hoping at the very least that Debian can build in some fallbacks in
the postinst scripts so that we are still able to update our systems on
WSL1 without intense workarounds.


-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-19041-Microsoft (UP)
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: unable to detect

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-2
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-2
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.4-0.1
ii  libmount1  2.39.2-2
ii  libp11-kit00.25.0-4
ii  libseccomp22.5.4-1+b3
ii  libselinux13.5-1
ii  libssl33.0.11-1
ii  libsystemd-shared  254.5-1
ii  libsystemd0254.5-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.2-2
ii  systemd-dev254.5-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-1
ii  systemd-timesyncd [time-daemon]  254.5-1

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1
pn  libqrencode4  
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
pn  polkitd   
ii  python3   3.11.4-5+b1
pn  python3-pefile
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-1
pn  dracut 
pn  initramfs-tools
pn  libnss-systemd 
ii  libpam-systemd 254.5-1
ii  udev   254.5-1

-- no debconf information

Bug#1053604: ITP: libgeo-gdal-ffi-perl -- foreign function interface for GDAL/OGR binding

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libgeo-gdal-ffi-perl
  Version : 0.1
  Upstream Contact: Ari Jolma 
* URL : https://metacpan.org/release/Geo-GDAL-FFI
* License : Artistic-2.0
  Programming Lang: Perl
  Description : foreign function interface for GDAL/OGR binding

 This is a foreign function interface (FFI) to the GDAL/OGR geospatial data 
access
 library. 
 .
 The FFI interface is based on the C API for GDAL/OGR as defined in version 3.5+
 and replaces the deprecated Geo::GDAL interface based on XS.

-- 
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Wed, Sep 20, 2023 at 10:29:49AM +0200, Francesco P. Lovergine wrote:


The resulting package needs to be arch:any to create a correct 
internal Geo::GDAL::gdal.pm module per arch,


Err, not required if depending on libgdal-dev, indeed.

--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 06:36:13PM +0200, Francesco P. Lovergine wrote:

On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote:

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
  dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())



Mmmm, let me see. The chain I used was to impact minimally on changes for the 
module
taken from CPAN. I would be happy to minimize the use of all that stuff, I was 
not exactly
enthusiastic about the new course at the time.



Ok, it seems that the solution is much more easy than the prospected. The 
implementation is smart
enough to keep the gdal.so in the right place, something I oversight before. The resulting 
package needs to be arch:any to create a correct internal Geo::GDAL::gdal.pm module per arch,

but it seems working. That said, I would try to patch to avoid the 
Platypus::Declare use
which is currently discouraged/deprecated: I would avoid to read other 
complains by gregor :-D

Thanks a lot for the hints.


--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote:

On Tue, 19 Sep 2023 17:48:41 +0200, Francesco P. Lovergine wrote:


> Sorry to be a pain again :) but: Do we really need this?

Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
https://wiki.debian.org/BookwormGdalPerl
which is my main goal to avoid to mantain an unofficial repo for the rest
of time.


You mean because of Alien::gdal?

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
   dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())



Mmmm, let me see. The chain I used was to impact minimally on changes for the 
module
taken from CPAN. I would be happy to minimize the use of all that stuff, I was 
not exactly
enthusiastic about the new course at the time.


--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 05:39:12PM +0200, gregor herrmann wrote:

On Tue, 19 Sep 2023 11:37:29 +0200, Francesco P. Lovergine wrote:


Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-base-modulebuild-perl

…

 .
 This module is in maintenance mode, use Alien::Build for new stuff.


Sorry to be a pain again :) but: Do we really need this?

Alien::Build is already questionable¹, although I admit that patching
the requirement out can be a bit cumbersome -- but a subclass that
says "This module is in maintenance mode, use Alien::Build for new
stuff." looks a bit like a candidate for not-packaging to me …



Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
https://wiki.debian.org/BookwormGdalPerl
which is my main goal to avoid to mantain an unofficial repo for the rest
of time. 


--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-base-modulebuild-perl
  Version : 1.17
  Upstream Contact: Joel A Berger 
* URL : https://metacpan.org/release/Alien-Base-ModuleBuild
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : subclass of Module::Build for building Alien:: modules and 
their libraries

 This is a subclass of Module::Build, that with Alien::Base allows for easy
 creation of Alien distributions. Alien::Base::ModuleBuild is used during the
 build step of your distribution. When properly configured it will
 use pkg-config to find and use the system version of the library
 download, build and install the library if the system does not provide it.
 .
 This module is in maintenance mode, use Alien::Build for new stuff.

-- 
Francesco P. Lovergine

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco P. Lovergine]

On Mon, Sep 18, 2023 at 02:40:50PM +0200, Francesco P. Lovergine wrote:

I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?




Yep indeed. Maybe a wrapper could be tought for packages that have some 
optional dep on that?



I would simply patch Mozilla::CA to have SSL_ca_file() returning the Debian directory 
/usr/share/ca-certificates/mozilla instead of the cacert.pem file. That would avoid to patch 
third-parties code that eventually use explicitly the modules. 
This is compatible with the IO::Socket::SSL module.


Does it make sense? 


--
Francesco P. Lovergine

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco P. Lovergine]

On Mon, Sep 18, 2023 at 02:33:18PM +0200, gregor herrmann wrote:

On Mon, 18 Sep 2023 14:29:08 +0200, gregor herrmann wrote:


> * Package name: libmozilla-ca-perl

We don't package Mozilla::CA in Debian because we have
ca-certificates with the same certs.


I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?




Yep indeed. Maybe a wrapper could be tought for packages that have some 
optional dep on that?

--
Francesco P. Lovergine

Bug#1050575: gnome randomly ignoring my keybinding settings

[Michael P. Soulier]

Package: gnome
Version: 1:43+1
Severity: important
X-Debbugs-Cc: msoul...@digitaltorque.ca

Dear Maintainer,

I set my keybindings to change workspaces on Super+1 to 4, for each of the 4
workspaces. Suddenly when I login, Super+3 opens the damned calendar instead.
But that's on a default X session. If I login with Wayland, suddenly 1-3 work
but Super+4 opens my browser.

None of this shows up in the settings. 

The quality of Gnome, which was already buggy, seems much lower in Debian 12.

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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.8-10
ii  cheese   43.0-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 12.0.6+nmu1~deb12u1
ii  evolution3.46.4-2
ii  evolution-plugins3.46.4-2
ii  file-roller  43.0-1
ii  gnome-calendar   43.1-2
ii  gnome-clocks 43.0-1
ii  gnome-color-manager  3.36.0-1+b1
ii  gnome-core   1:43+1
ii  gnome-maps   43.5-2~deb12u1
ii  gnome-music  42.1-1
ii  gnome-sound-recorder 43~beta-1
ii  gnome-tweaks 42~beta-4
ii  gnome-weather43.0-1
ii  gstreamer1.0-libav   1:1.22.3-dmo1
ii  gstreamer1.0-plugins-ugly1:1.22.3-dmo1+deb12u1
ii  libgsf-bin   1.14.50-1
ii  libproxy1-plugin-networkmanager  0.4.18-1.2
ii  libreoffice-calc 4:7.4.7-1
ii  libreoffice-gnome4:7.4.7-1
ii  libreoffice-impress  4:7.4.7-1
ii  libreoffice-writer   4:7.4.7-1
ii  network-manager-gnome1.30.0-2
ii  orca 43.1-1
ii  rhythmbox3.4.6-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.6-2+b1
ii  rhythmbox-plugins3.4.6-2+b1
ii  rygel-playbin0.42.1-1
ii  rygel-tracker0.42.1-1
ii  seahorse 43.0-1
ii  shotwell 0.30.17-1+b1
ii  simple-scan  42.5-2
ii  totem-plugins43.0-2
ii  xdg-user-dirs-gtk0.11-1

Versions of packages gnome recommends:
ii  gnome-games   1:43+1
ii  gnome-initial-setup   43.2-6
ii  gnome-remote-desktop  43.3-1
ii  transmission-gtk  3.00-2.1+b1

Versions of packages gnome suggests:
pn  alacarte  
pn  empathy   
pn  firefox-esr-l10n-all | firefox-l10n-all   
pn  goobox | sound-juicer 
pn  polari
pn  vinagre   
pn  webext-ublock-origin-firefox | webext-ublock-origin-chromium  

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme43-1
ii  at-spi2-core  2.46.0-5
ii  baobab43.0-1
ii  dconf-cli 0.40.0-4
ii  dconf-gsettings-backend   0.40.0-4
ii  eog   43.2-1
ii  evince43.1-2+b1
ii  evolution-data-server 3.46.4-2
ii  fonts-cantarell   0.303.1-1
ii  gdm3  43.0-3
ii  gkbd-capplet  3.28.1-1
ii  glib-networking   2.74.0-4
ii  gnome-backgrounds 43.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-calculator  1:43.0.1-2
ii  gnome-characters  43.1-1
ii  gnome-contacts43.1-1
ii  gnome-control-center  1:43.6-2~deb12u1
ii  gnome-disk-utility43.0-1
ii  gnome-font-viewer 43.0-1
ii  gnome-keyring 42.1-1+b2
ii  gnome-logs43.0-1
ii  gnome-menus   3.36.0-1.1
ii  gnome-online-accounts 3.46.0-1
ii  gnome-session 43.0-1
ii  gnome-settings-daemon 43.0-4
ii  gnome-shell   43.6-1~deb12u1
ii  gnome-shell-extensions43.1-1
ii  gnome-software43.5-1~deb12u1
ii  gnome-sushi   43.0-2
ii  gnome-system-monitor  42.0-2
ii  gnome-terminal3.46.8-1
ii  gnome-text-editor 43.2-1
ii  gnome-themes-extra3.28-2
ii  gnome-user-docs   43.0-2
ii  gnome-user-share  

Bug#1050574: xfsprogs: I/O errors and desktop locks up on mkfs

[Michael P. Soulier]

Package: xfsprogs
Version: 6.1.0-1
Severity: important
X-Debbugs-Cc: msoul...@digitaltorque.ca

Dear Maintainer,

I was trying to format a 4TB usb external drive. Every time I tried, I saw I/O
errors and my gnome desktop froze, requiring a complete power-cycle to recover. 

I finally used ext4 with no problems. Could be hardware but the enclusure and
drive are both brand new, and I don't know why one would succeed and the other
fail.

Some dmesg output:

Aug 26 08:58:37 anton sudo[6470]: msoulier : TTY=pts/0 ; PWD=/home/msoulier ; US
ER=root ; COMMAND=/usr/sbin/mkfs -t xfs -f /dev/sdc1
Aug 26 08:58:37 anton sudo[6470]: pam_unix(sudo:session): session opened for use
r root(uid=0) by (uid=1000)
Aug 26 08:58:37 anton kernel: DMAR: DRHD: handling fault status reg 3
Aug 26 08:58:37 anton kernel: xhci_hcd :00:14.0: WARNING: Host System Error
Aug 26 08:58:37 anton kernel: DMAR: [DMA Read NO_PASID] Request device [00:14.0]
 fault addr 0xff58f000 [fault reason 0x06] PTE Read access is not set
Aug 26 08:58:39 anton kernel: usb 2-3: device not accepting address 2, error -10
8
Aug 26 08:58:42 anton kernel: usb 2-3: USB disconnect, device number 2
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#4 uas_eh_abort_handler 0 uas
-tag 11 inflight: CMD OUT
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#4 CDB: Write(16) 8a 00 00 00
 00 00 e8 e1 34 48 00 00 04 00 00 00
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#2 uas_eh_abort_handler 0 uas
-tag 10 inflight: CMD OUT
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#2 CDB: Write(16) 8a 00 00 00
 00 00 e8 e1 30 48 00 00 04 00 00 00
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#1 uas_eh_abort_handler 0 uas
-tag 9 inflight: CMD OUT
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#1 CDB: Write(16) 8a 00 00 00
 00 00 e8 e1 2c 48 00 00 04 00 00 00
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#0 uas_eh_abort_handler 0 uas
-tag 8 inflight: CMD OUT
Aug 26 08:59:08 anton kernel: sd 2:0:0:0: [sdc] tag#0 CDB: Write(16) 8a 00 00 00
 00 00 e8 e1 28 48 00 00 04 00 00 00
Aug 26 08:59:09 anton kernel: scsi host2: uas_eh_device_reset_handler start
Aug 26 08:59:09 anton kernel: usb 2-1: device not accepting address 4, error -10
8
Aug 26 08:59:10 anton kernel: usb 2-1: device not accepting address 4, error -10
8
Aug 26 08:59:10 anton kernel: usb 2-1: device not accepting address 4, error -10
8
Aug 26 08:59:11 anton kernel: usb 2-1: device not accepting address 4, error -10
8



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

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

Versions of packages xfsprogs depends on:
ii  libblkid1   2.38.1-5+b1
ii  libc6   2.36-9+deb12u1
ii  libdevmapper1.02.1  2:1.02.185-2
ii  libedit23.1-20221030-2
ii  libicu7272.1-3
ii  libinih155-1
ii  liburcu80.13.2-1
ii  libuuid12.38.1-5+b1
ii  python3 3.11.2-1+b1

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
ii  acl  2.3.1-3
pn  attr 
pn  quota
ii  xfsdump  3.1.11-0.1

-- no debconf information

Bug#981458: vtun systemd service

[Francesco P. Lovergine]

On Tue, Jul 04, 2023 at 11:24:21AM +0200, Andreas Henriksson wrote:

Hello Francesco P. Lovergine,

Thanks for your feedback on this!

On Mon, Jul 03, 2023 at 06:17:20PM +0200, Francesco P. Lovergine wrote:

Uhm, it seems to me quite irritual using a template unit file without a 
template variable. Which reflects
the quite strange use of /etc/default/vtun with multiple indexed vars,
instead of multiple configuration files such as:

/etc/vtun.d/config?.vars (or even under /etc/vtun if you prefer so)

and of course you can override the env variables by using an
/etc/vtun.d/%i.vars

where it makes sense in the template file. I think this would be the right 
moment to convert the
insane limited number of env var sets in /etc/default/vtun into multiple 
ordinary configuration
files and using something like that.

EnvironmentFile=-/etc/vtun.d/%i.vars

would override name, host and args variables.

I'm missing something?


While I atleast partially agree with your initial sentence, I'm not
onboard with your suggested solution.
In my understanding use of EnvironmentFile= is discuraged (and if I'm
not mistaken I've even read statements saying it was a mistake to ever
add it as an option).

It seems to me like you're bending over backwards trying to invent
something that actually needs the instance variable.

(I'm however fine with anything that gets things moving forward of using
native units instead of init script. I'm also not even a user of this
package/program as previously stated, so it affects me very little.
Use what ever solution you find acceptable!)

Regards,
Andreas Henriksson



First of all, sorry for the use of irritual instead of weird (false friend term 
applies
in this case, for non native speakers). 


About the discouraging of EnvironmentFile could you please point where
it is expressed in the Policy? For sure, Debian has impressive use of the 
/etc/default/ tree
which was and still is Debian specific. That is probably the origin of those 
rumors.

Indeed, enabling/disabling of services by using an option in /etc/default/ (as 
for a lots
of services in the past) is considered a bad practice due to the old init sysv days. 
Today, one should enable/disable the unit instead, which is much more clean. That make sense. 
I disagree with a general deprecation

of Environment entries instead (files or vars), which is optimal mode of solving
configuration issues without writing whole units or overrides. But on those 
regards,
using a non-templated unit as a pseudo-templated is a very strange choice.

Anyway it is your choice.

--
Francesco P. Lovergine

Bug#981458: vtun systemd service

[Francesco P. Lovergine]

On Mon, Jul 03, 2023 at 04:03:47PM +0200, Andreas Henriksson wrote:

Control: forcemerge -1 1039413
Control: severity -1 important
Control: retitle -1 vtun: please provide vtun@.service and mask init script

Hello,

I'm attaching a patch for the vtun debian package that should hopefully
be a good start in migrating to native systemd units.
The patch is COMPLETELY UNTESTED as I'm not myself a user of vtun.
Please make sure to set FIRST_SYSTEMD_SERVICE_VERSION to the correct
debian package version including these changes.

The attached patch adds a vtun@.service as the init script seems to have
used a home-brew template units style.
The /etc/default/vtun CLIENT$i_* variables are broken up into separate
vtun@.service instances, eg CLIENT1_NAME, CLIENT1_HOST, CLIENT1_ARGS
goes to vtun@CLIENT1.service override as NAME, HOST and OPTIONS.
This is done as a one-time migration
(This also lifts the restrictions of having 0-9 instances.)

You most likely also want to make sure vtun.service (without the @)
is a symlink to /dev/null, to mask the init script.


See also:

https://src.fedoraproject.org/rpms/vtun/tree/81e15b3a03b89bffe0e6076a235720d40f343292

You might also want to provide the socket unit

Regards,
Andreas Henriksson



diff '--color=auto' -uriNp vtun-3.0.4/debian/postinst 
vtun-3.0.4.systemd/debian/postinst
--- vtun-3.0.4/debian/postinst  2019-11-11 01:17:37.0 +0100
+++ vtun-3.0.4.systemd/debian/postinst  2023-07-03 15:47:08.717223223 +0200
@@ -46,6 +46,36 @@ case "$1" in
;;
esac

+# migrate old init.d style settings to systemd
+FIRST_SYSTEMD_SERVICE_VERSION="3.0.4-2.1"
+if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt-nl 
"$FIRST_SYSTEMD_SERVICE_VERSION~" ; then
+(
+echo "Checking if we need to migrate /etc/default/vtun settings to 
'vtun@.service'."
+if [ -e /etc/default/vtun ]; then
+. /etc/default/vtun
+fi
+
+for i in 0 1 2 3 4 5 6 7 8 9; do
+eval name=\$CLIENT${i}_NAME
+eval host=\$CLIENT${i}_HOST
+eval args=\$CLIENT${i}_ARGS
+if [ -n "$name" ] && [ -n "$host" ]; then
+    echo "One-time migration of vtun CLIENT$i settings to 
vtun@CLIENT$i.service"
+mkdir -p "/etc/systemd/system/vtun@CLIENT$i.service.d/"
+echo "[Service]" >> 
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"NAME=$name\"" >> 
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"HOST=$host\"" >> 
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"OPTIONS=$args\"" >> 
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+if [ -n "${RUN_SERVER:-}" ] && [ "${RUN_SERVER:-}" != "no" ]; 
then
+deb-systemd-helper enable "vtun@CLIENT$i"
+fi
+fi
+
+done
+)
+fi
+
+
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

diff '--color=auto' -uriNp vtun-3.0.4/debian/vtun@.service 
vtun-3.0.4.systemd/debian/vtun@.service
--- vtun-3.0.4/debian/vtun@.service 1970-01-01 01:00:00.0 +0100
+++ vtun-3.0.4.systemd/debian/vtun@.service 2023-07-03 15:23:25.513183684 
+0200
@@ -0,0 +1,12 @@
+[Unit]
+Description=Virtual Tunnels over TCP/IP networks
+After=network.target
+
+[Service]
+ExecStart=/usr/sbin/vtund -n $OPTIONS $NAME $HOST
+# Reload should be synchronous, but signals are not...
+ExecReload=/usr/bin/kill -HUP $MAINPID
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target



Uhm, it seems to me quite irritual using a template unit file without a 
template variable. Which reflects
the quite strange use of /etc/default/vtun with multiple indexed vars,
instead of multiple configuration files such as:

/etc/vtun.d/config?.vars (or even under /etc/vtun if you prefer so)

and of course you can override the env variables by using an /etc/vtun.d/%i.vars 


where it makes sense in the template file. I think this would be the right 
moment to convert the
insane limited number of env var sets in /etc/default/vtun into multiple 
ordinary configuration
files and using something like that.

EnvironmentFile=-/etc/vtun.d/%i.vars

would override name, host and args variables.

I'm missing something?


--
Francesco P. Lovergine

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

On Fri, Jun 30, 2023 at 12:54:23PM +0100, Jonathan Wiltshire wrote:


Can I have a source-only upload please? I'll reject the upload for now, you
can reuse the same version.



Done.

--
Francesco P. Lovergine

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

On Mon, Jun 26, 2023 at 07:28:36PM +0200, Francesco P. Lovergine wrote:


Updated debdiff attached.



Sorry wrong diff, this is the correct one :-/

--
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+  * Now do not enable proftpd.socket to avoid conflicts at boot time.
+(Closes: #1038416)
+  * Introduced a new prerm script to manage stop of service/socket before
+remove.
+  * Added an entry to NEWS file to explain the change in unit files
+and how to deal with changes.
+  * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine   Thu, 22 Jun 2023 11:15:57 +0200
+
 proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
 
   * Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,16 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+If you upgrade from 1.3.8+dfsg-4 (i.e. th 12.0 edition of bookworm) note
+that you will need to
+systemctl disable --now proftpd.socket
+systemctl enable --now proftpd.service
+after upgrade, if you run the proftpd in (default) standalone mode and you did not
+do that before. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416
+for more information. For other information about inetd/standalone switching
+see also the relevant section in /usr/share/doc/proftpd-core/README.Debian.gz. 
+
+ -- Francesco Paolo Lovergine   Wed, 21 Jun 2023 15:21:32 +0200
+
 proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
 
 The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	2023-06-22 11:15:57.0 +0200
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian	2023-06-22 11:15:57.0 +0200
@@ -104,8 +104,7 @@
 
 That could be done by running 
 
-	service proftpd stop
-	systemctl disable proftpd.service
+	systemctl disable --now proftpd.service
 
 then changing from 'standalone' to 'inetd' the ServerType entry in
 /etc/proftpd/proftpd.conf, and: 
@@ -131,10 +130,7 @@
 
   - or using systemd support for socket. To do that run:
 
-	systemctl stop proftpd.service
-	systemctl disable proftpd.service
-	systemctl enable proftpd.socket
-	systemctl start proftpd.socket
+	systemctl enable --now proftpd.socket
 
 ** Other information
 
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/rules proftpd-dfsg-1.3.8+dfsg/debian/rules
--- proftpd-dfsg-1.3.8+dfsg/debian/rules	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/rules	2023-06-22 11:15:57.0 +0200
@@ -93,7 +93,7 @@
 	dh_installinit --name=$(NAME)
 
 override_dh_installsystemd:
-	dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).socket
+	dh_installsystemd -p$(PACKAGE) --no-enable --no-start --name=$(NAME) $(NAME).socket
 	dh_installsystemd -p$(PACKAGE) --name=$(NAME)@ $(NAME)@.service
 	dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).service
 

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

On Mon, Jun 26, 2023 at 10:50:05AM +0200, Francesco P. Lovergine wrote:

Ok, I did my homework again and found that the best thing to do seems removing 
the
proftpd-run.service and enabling the proftpd.service only at 
installation time. That would allow proftpd working flawlessly at 
least for new installation on bookworm and even upgrades from bullseye 
to p-u.


Unfortunately, an upgrade from -4 would not fix the situation, which 
should be fixed by the admin in any case, by simply disabling 
proftpd.socket by hand. But for annotating this thing in NEWS, I can't 
see any other details to have care.


If you (RMs) like this plan, I would submit one more debdiff with the proposed 
changes
and wait for a final approvement, if possible.



Updated debdiff attached.

--
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+  * Now do not enable proftpd.socket to avoid conflicts at boot time.
+(Closes: #1038416)
+  * Introduced a new prerm script to manage stop of service/socket before
+remove.
+  * Added an entry to NEWS file to explain the change in unit files
+and how to deal with changes.
+  * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine   Thu, 22 Jun 2023 11:15:57 +0200
+
 proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
 
   * Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,16 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+If you upgrade from 1.3.8+dfsg-4 (i.e. th 12.0 edition of bookworm) note
+that you will need to
+systemctl disable --now proftpd.socket
+systemctl enable --now proftpd.service
+after upgrade, if you run the proftpd in (default) standalone mode and you did not
+do that before. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416
+for more information. For other information about inetd/standalone switching
+see also the relevant section in /usr/share/doc/proftpd-core/README.Debian.gz. 
+
+ -- Francesco Paolo Lovergine   Wed, 21 Jun 2023 15:21:32 +0200
+
 proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
 
 The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	2023-06-22 11:15:57.0 +0200
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian	2023-06-22 11:15:57.0 +0200
@@ -104,8 +104,8 @@
 
 That could be done by running 
 
-	service proftpd stop
-	systemctl disable proftpd.service
+	systemctl stop proftpd.service
+	systemctl disable proftpd-run.service (only for xinetd/inetd use)
 
 then changing from 'standalone' to 'inetd' the ServerType entry in
 /etc/proftpd/proftpd.conf, and: 
@@ -132,10 +132,10 @@
   - or using systemd support for socket. To do that run:
 
 	systemctl stop proftpd.service
-	systemctl disable proftpd.service
-	systemctl enable proftpd.socket
 	systemctl start proftpd.socket
 
+The proftpd-run.service will take care of the mode switching at boot time.
+
 ** Other information
 
 Please, read accurately the NEWS, README and changelog file in /usr/share/doc/proftpd-basic
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/rules proftpd-dfsg-1.3.8+dfsg/debian/rules
--- proftpd-dfsg-1.3.8+dfsg/debian/rules	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/rules	2023-06-22 11:15:57.0 +0200
@@ -93,7 +93,7 @@
 	dh_installinit --name=$(NAME)
 
 override_dh_installsystemd:
-	dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).socket
+	dh_installsystemd -p$(PACKAGE) --no-enable --no-start --name=$(NAME) $(NAME).socket
 	dh_installsystemd -p$(PACKAGE) --name=$(NAME)@ $(NAME)@.service
 	dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).service
 

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

On Sun, Jun 25, 2023 at 05:27:04PM +0100, Jonathan Wiltshire wrote:

> Maybe I missed something important, but this seems a very odd way of doing
> things. Do you really set up a dummy service unit which is expected to fail
> in standalone mode, and therefore starts the socket instead?
>
> Why not use an ExecStartPre= or ExecCondition= in your normal units to
> prevent starting when in inetd mode?
>

Unfortunately, Exec* directives can only be used in .service units.


This statement is at odds with the documentation for systemd.socket(5).



I meant ExecCondition (see https://github.com/systemd/systemd/issues/14012),
but indeed there is not way to by-pass the socket opening within a
socket unit. Once enabled, the ftp socket is under systemd control, the
only way to prevent that is by using ConditionPathExists AFAIK.


That's
the reason to enable an external oneshot .service unit to start
alternatively one of the two other units. Ideally one day or another such
features could
be available also in other type of units (there is an issue open since
2019). Incidentally, it is possible to add a ConditionPathExists and a
something like /etc/proftpd/proftpd_not_to_be_run (which is the trick used
in sshd) but would be completely Debian specific and out of the usual
workflow to manage inetd/standalone modes in proftpd. So, I'm not that keen
on
this kind of trick.


I don't think a ConditionPathExists hack is necessary here. Yes, in the
standalone case you will end up with the socket unit failing, and the local
admin will have to disable that if it annoys them, but any competent
administrator should be able to figure that out with the help of
NEWS.Debian.



Ok, I did my homework again and found that the best thing to do seems removing 
the
proftpd-run.service and enabling the proftpd.service only at installation time. 
That would allow proftpd working flawlessly at least for new installation on bookworm 
and even upgrades from bullseye to p-u. 

Unfortunately, an upgrade from -4 would not fix the situation, which should 
be fixed by the admin in any case, by simply disabling proftpd.socket by hand. 
But for annotating this thing in NEWS, I can't see any other details to have care. 


If you (RMs) like this plan, I would submit one more debdiff with the proposed 
changes
and wait for a final approvement, if possible.


--
Francesco P. Lovergine

Bug#1039093: ITP: libalien-build-perl -- module to build external dependencies for use in CPAN

[Francesco P. Lovergine]

Package: wnpp
Owner: Francesco Paolo Lovergine 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-build-perl
  Version : 2.80
  Upstream Author : Graham Ollis 
* URL : https://metacpan.org/release/Alien-Build
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to build external dependencies for use in CPAN

Alien::Build provides tools for building external (non-CPAN) dependencies for
CPAN. It is mainly designed to be used at install time of a CPAN client, and
work closely with Alien::Base which is used at runtime.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

On Sun, Jun 25, 2023 at 11:06:17AM +0200, Francesco P. Lovergine wrote:


Why not use an ExecStartPre= or ExecCondition= in your normal units to
prevent starting when in inetd mode?



Unfortunately, Exec* directives can only be used in .service units. 
That's the reason to enable an external oneshot .service unit to start 
alternatively one of the two other units. Ideally one day or another 
such features could
be available also in other type of units (there is an issue open since 
2019). Incidentally, it is possible to add a ConditionPathExists and a 
something like /etc/proftpd/proftpd_not_to_be_run (which is the trick 
used in sshd) but would be completely Debian specific and out of the 
usual workflow to manage inetd/standalone modes in proftpd. So, I'm 
not that keen on

this kind of trick.



Even, the ConditionPathExists would also imply adding code to
manage in postinst that kind of stuff, in order to update
admin's configuration in a proper way to respect the rule of least
surprise at upgrade time ...


--
Francesco P. Lovergine

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

First of all, thanks for the review. 


Answers are embedded below.

On Sat, Jun 24, 2023 at 05:45:33PM +0100, Jonathan Wiltshire wrote:

Control: tag -1 moreinfo

On Thu, Jun 22, 2023 at 02:29:54PM +0200, Francesco P. Lovergine wrote:

diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog 
proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog2023-03-14 10:16:31.0 
+0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog2023-06-22 11:15:57.0 
+0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm-proposed-updates; urgency=medium


You should target `bookworm`, not the admin suites.



Right, to be done.


diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 
proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm   1970-01-01 
01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm   2023-06-22 
11:13:30.0 +0200
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.service' >/dev/null || true
+deb-systemd-invoke stop 'proftpd.socket' >/dev/null || true
+fi


This gives rise to a race condition where the socket starts the service
again before the socket is stopped.



Well, this is exactly what debhelper does in current prerm in bookworm. 
Eventually, it could be unified in `deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' || true` 
like other packages do.

I'm not sure if this is what you intend, but if that risks a race condition it 
would applies to
a lots of other packages.


diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service 
proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service 
1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service 
2023-06-22 11:12:42.0 +0200
@@ -0,0 +1,14 @@
+[Unit]
+Description=ProFTPD FTP Server in standalone/socket mode
+Documentation=man:proftpd(8)
+OnFailure=proftpd.socket
+OnSuccess=proftpd.service
+
+[Service]
+Type=oneshot
+Environment=CONFIG_FILE=/etc/proftpd/proftpd.conf
+EnvironmentFile=-/etc/default/proftpd
+ExecStart=/usr/bin/grep -iqE '^[[:space:]]*ServerType[[:space:]]+standalone$' 
$CONFIG_FILE


Maybe I missed something important, but this seems a very odd way of doing
things. Do you really set up a dummy service unit which is expected to fail
in standalone mode, and therefore starts the socket instead?

Why not use an ExecStartPre= or ExecCondition= in your normal units to
prevent starting when in inetd mode?



Unfortunately, Exec* directives can only be used in .service units. That's 
the reason to enable an external oneshot .service unit to start alternatively 
one of the two other units. Ideally one day or another such features could
be available also in other type of units (there is an issue open since 2019). 
Incidentally, it is possible to add a ConditionPathExists and a something 
like /etc/proftpd/proftpd_not_to_be_run (which is the trick used in sshd) 
but would be completely Debian specific and out of the usual workflow 
to manage inetd/standalone modes in proftpd. So, I'm not that keen on

this kind of trick.

--
Francesco P. Lovergine

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: proftpd-d...@packages.debian.org, 
pkg-proftpd-maintain...@alioth-lists.debian.net
Control: affects -1 + src:proftpd-dfsg

Hi

this is a pre-check before uploading in bookworm p-u a fixed package.

The proposed solution is described in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416#25
and implies adding and enable one more unit to pre-check the socket vs service 
units,
and install/upgrade the other units in disabled mode. That even requires
stopping the service at prerm stage.

[ Reason ]

Murphy law applies and we (ProFTPD team) found a serious flaw in bookworm
proftpd - as summarized in the report #1038416 - which prevents having a 
working service after a new install or even an upgrade in bookworm.

[ Impact ]

The default proftpd configuration requires a standalone daemon running,
but the installation of a .socket unit prevents it to run and is not
working even, because the distributed proftpd.conf (and generally the
system admin's one) renders unusable the program via systemd. This is
evident after rebooting, while the daemon is regularly
working just after installation.

At the end of the day the admin get a not working service and 
needs to manually disable the .socket and enable the .service, or
change ServerType to inetd. This is unexpected and suboptimal.

[ Tests ]

The proposed solution works on a fresh install or an upgrade.

[ Risks ]

The change is quite trivial and should not impact other parts of the system.

[ 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 ]

Adding a new service unit which runs on-exit/on-success alternatively
the original .socket/.service unit on the basis of the current
proftpd configuration after install. The prerm script now stop services
just before removing package units.
Changes include documentation of the new units management in NEWS
and README.Debian.

[Other info]


-- 
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm-proposed-updates; urgency=medium
+
+  * Introduced a new systemd service to start the main socket/service 
+on the basis of the proftpd.conf configuration (standalone/inetd).
+(Closes: #1038416)
+  * Introduced a new prerm script to manage stop of service/socket now
+not more managed by DH scripts.
+  * Added an entry to NEWS file to explain the change in unit files.
+  * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine   Thu, 22 Jun 2023 11:15:57 +0200
+
 proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
 
   * Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm-proposed-updates; urgency=medium
+
+Starting from this version a new systemd unit file 'proftpd-run.service' has
+been introduced to allow switching between standalone and systemd (socket) mode.
+In order to switch mode, it is possible to change ServerType from standalone to inetd
+in /etc/proftpd/proftpd.conf and run systemctl stop proftpd.service
+systemctl start proftpd.socket
+The only unit to be maintained enabled is proftpd-run.service, and disabling
+it would ensures to stop the ftp service at boot time.
+
+ -- Francesco Paolo Lovergine   Wed, 21 Jun 2023 15:21:32 +0200
+
 proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
 
 The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	2023-06-22 11:13:30.0 +0200
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.service' >/dev/null || true
+deb-systemd-invoke stop 'proftpd.socket' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.

Bug#1038416: possible fix

[Francesco P. Lovergine]

severity 1038416 serious
tags 1038416 + patch bookworm
thanks


Hi all,

Here we go, there is a better solution. 


It is possible to install and enable a third unit file such as:

+++ /etc/systemd/system/proftpd-run.service:

[Unit]
Description=ProFTPD FTP Server in standalone/socket mode
OnFailure=proftpd.socket
OnSuccess=proftpd.service

[Service]
Type=oneshot
Environment=CONFIG_FILE=/etc/proftpd/proftpd.conf
EnvironmentFile=-/etc/default/proftpd
ExecStart=/usr/bin/grep -iqE '^[[:space:]]*ServerType[[:space:]]+standalone$' 
$CONFIG_FILE
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Here one can enable only this service and install only the other ones.

systemctl disable proftpd.service
systemctl disable proftpd.socket
systemctl enable --now proftpd-run.service

do the task.

I would add this solution to git and prepare an ad hoc p-u for bookworm, but 
I'd prefer having a go from the release team, before that.


- cheers


On Tue, Jun 20, 2023 at 08:42:57PM +0200, Francesco P. Lovergine wrote:

For reference, all this is a side effect of the proposed fix for #991266,
strangely not caught at the time.

On Tue, Jun 20, 2023 at 08:00:19PM +0200, Francesco P. Lovergine wrote:

Bruno, that's right

Unfortunately yes: originally the socket unit file was concepted as an example
file to keep into the documentation and the Conflicts there does not 
ensure that the .socket unit is ignored when the .service is 
enabled.


The simplest workaroud is

systemctl disable --now proftpd.socket
systemctl enable --now proftpd.service

but the initial installation is definitively broken, because proftpd 
starts as a systemd socket, which is not intended by the distributed 
proftpd.conf.


Hilmar, the simplest thing to do is probably addig a mask/disable of 
proftpd.socket at postinst time,
and an enable --now for the proftpd.service, when server should be 
run in standalone mode (check via grepping proftpd.conf), after 
installing systemd stuff in --no-enable --no-start mode.


This is of course not completely fair because ignores xinetd/inetd setup.



--
Francesco P. Lovergine

___
Pkg-proftpd-maintainers mailing list
pkg-proftpd-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers



--
Francesco P. Lovergine

Bug#1038416: (no subject)

[Francesco P. Lovergine]

For reference, all this is a side effect of the proposed fix for #991266,
strangely not caught at the time.

On Tue, Jun 20, 2023 at 08:00:19PM +0200, Francesco P. Lovergine wrote:

Bruno, that's right

Unfortunately yes: originally the socket unit file was concepted as an example
file to keep into the documentation and the Conflicts there does not 
ensure that the .socket unit is ignored when the .service is enabled.


The simplest workaroud is

systemctl disable --now proftpd.socket
systemctl enable --now proftpd.service

but the initial installation is definitively broken, because proftpd 
starts as a systemd socket, which is not intended by the distributed 
proftpd.conf.


Hilmar, the simplest thing to do is probably addig a mask/disable of 
proftpd.socket at postinst time,
and an enable --now for the proftpd.service, when server should be run 
in standalone mode (check via grepping proftpd.conf), after installing 
systemd stuff in --no-enable --no-start mode.


This is of course not completely fair because ignores xinetd/inetd setup.



--
Francesco P. Lovergine

Bug#1038416: (no subject)

[Francesco P. Lovergine]

Bruno, that's right

Unfortunately yes: originally the socket unit file was concepted as an example
file to keep into the documentation and the Conflicts there does not ensure that 
the .socket unit is ignored when the .service is enabled. 

The simplest workaroud is 


systemctl disable --now proftpd.socket
systemctl enable --now proftpd.service

but the initial installation is definitively broken, because proftpd 
starts as a systemd socket, which is not intended by the distributed proftpd.conf.


Hilmar, the simplest thing to do is probably addig a mask/disable of 
proftpd.socket at postinst time,
and an enable --now for the proftpd.service, when server should be run in standalone mode (check via grepping proftpd.conf), 
after installing systemd stuff in --no-enable --no-start mode.


This is of course not completely fair because ignores xinetd/inetd setup.

On Tue, Jun 20, 2023 at 04:21:41PM +0200, Bruno wrote:

I guess that the systemd unit protfpd.socket should be disabled

$ systemctl is-enabled proftpd.sockets 
disabled



May be the Debian package postinst script wrongly enabled it





___
Pkg-proftpd-maintainers mailing list
pkg-proftpd-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers



--
Francesco P. Lovergine

Bug#1035438: cl-quicklisp: installation instructions do not work

[Michael P. Soulier]

On 2023-05-13 05:55, Sébastien Villemot wrote:

I tested it locally and this alternative method works. Can you share
the error message you get?


Clearly I did something wrong as I can't reproduce this now.

Thanks,
Mike

Bug#1035438: cl-quicklisp: installation instructions do not work

[Michael P. Soulier]

On 13/05/23 Sébastien Villemot said:

> Indeed it looks like the recommendation to use “sbcl --script …” is
> incorrect, since SBCL terminates after loading the file, without giving
> access to a REPL from which you could do the installation.
> 
> You should follow the other installation option given in the same
> README file, which is to use (load #p"/usr/share/common-
> lisp/source/quicklisp/quicklisp.lisp") in the REPL before running
> (quicklisp-quickstart:install).

I found that it did not work for me. I had to grab the latest quicklisp from the
website.

Cheers,
Mike


signature.asc
Description: PGP signature

Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault

[Francesco P. Lovergine]

On Fri, May 12, 2023 at 01:01:24PM +0100, Robert Pumphrey wrote:

Thank you for the fast response.

On the NIS master, I have moved the domain directory /var/yp/domain to 
a backup.


I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the NIS 
slaves. This ran successfully.


/usr/lib/yp/yphelper  --hostname   runs successfully on the master.

/usr/lib/yp/yphelper  --maps nameofnismaster  runs successfully on the 
master and gives a list of maps.




This is quite strange, because in moving from bullseye to bookworm
no chages in the binary gdbm files have been required in my test. 
Test done after generating maps in bullseye. 
Are your current maps older than that?

Even, I'm assuming you are on a amd64 arch.

I have noticed that if the /etc/hosts file does not have an entry for 
local machine, then /usr/lib/yp/yphelper  --hostname seg faults.




This is expressly mandatory in NIS configuration, as by documentation.
Every hostname used must be resolved at /etc/hosts level.
Anyway that should not cause a segfault but an error, indeed. That seems
an upstream issue (or several for each tool).

All the other trials could be a direct consequence of that.


The NIS master now looks to be operating correctly.


On one of the NIS slaves, I moved the domain directory /var/yp/domain 
to a backup.


I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a 
segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running.


/usr/lib/yp/yphelVper  --hostname   runs successfully on the slave
/usr/lib/yp/yphelper  --maps nameofnismaster seg faults

So I have made some progress. Please let me know if there is anything 
else I can tell you.


Regards

Rob

On 12/05/2023 10:09, Francesco P. Lovergine wrote:

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it 
perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is 
somethig already

seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing 
changes in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? Could you please 
regenerate gdbm stuff by ypinit -m after cleaning up maps?


Anywyay, my next step will be preparing an upgrading box to test 
bullseye->bookworm, stay tuned.


On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

Package: ypserv
Version: 4.1-2
Severity: important

Dear Maintainer,

Recently upgraded our NIS master from buster to bullseye.
when I run
cd /var/yp; make
several apps fail to run and seg fault, for example

/usr/lib/yp/yphelper  --hostname
Segmentation fault


yppush -d example.com ypservers
Segmentation fault

makedbm does appear to make valid files when run from the cmd line



-- System Information:
Debian Release: 11.7
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable-security'), 
(500, 'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ypserv depends on:
ii  hostname   3.23
ii  libc6  2.31-13+deb11u6
ii  libcrypt1  1:4.4.18-4
ii  libgdbm6   1.19-2
ii  libnsl2    1.3.0-2
ii  libsystemd0    247.3-7+deb11u2
ii  libtirpc3  1.3.1-1+deb11u1
ii  lsb-base   11.1.0
ii  make   4.3-4.1
ii  rpcbind [portmap]  1.2.5-9
ii  ucf    3.0043

Versions of packages ypserv recommends:
ii  yp-tools  4.2.3-3

Versions of packages ypserv suggests:
pn  krb5-kdc   
ii  ypbind-mt  2.7.2-2

-- no debconf information




--
Certus Technology Associates Limited.
http://www.certus-tech.com
Tel: +44 (0)114 272 5081



--
Francesco P. Lovergine

Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault

[Francesco P. Lovergine]

severity 1035967 normal
thanks

On Fri, May 12, 2023 at 11:09:50AM +0200, Francesco P. Lovergine wrote:

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is somethig already
seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes 
in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? Could you please 
regenerate gdbm stuff by ypinit -m after cleaning up maps?


Anywyay, my next step will be preparing an upgrading box to test 
bullseye->bookworm, stay tuned.



... and as promised, I just tested an upgrade of a NIS server successfully. 
Services are all
operational and the pointed binaries do not issue a segfault.

In order to undestand your problem, I need to have details about your
configuration, and eventually also pinned packages, additional repos etc.

Feel free to send that stuff off-bugs.d.o to protect your site information, 
eventually.

Thanks.


On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

Package: ypserv
Version: 4.1-2
Severity: important

Dear Maintainer,

Recently upgraded our NIS master from buster to bullseye.
when I run
cd /var/yp; make
several apps fail to run and seg fault, for example

/usr/lib/yp/yphelper  --hostname
Segmentation fault


yppush -d example.com ypservers
Segmentation fault

makedbm does appear to make valid files when run from the cmd line



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

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

Versions of packages ypserv depends on:
ii  hostname   3.23
ii  libc6  2.31-13+deb11u6
ii  libcrypt1  1:4.4.18-4
ii  libgdbm6   1.19-2
ii  libnsl21.3.0-2
ii  libsystemd0247.3-7+deb11u2
ii  libtirpc3  1.3.1-1+deb11u1
ii  lsb-base   11.1.0
ii  make   4.3-4.1
ii  rpcbind [portmap]  1.2.5-9
ii  ucf3.0043

Versions of packages ypserv recommends:
ii  yp-tools  4.2.3-3

Versions of packages ypserv suggests:
pn  krb5-kdc   
ii  ypbind-mt  2.7.2-2

-- no debconf information



--
Francesco P. Lovergine



--
Francesco P. Lovergine

Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault

[Francesco P. Lovergine]

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is somethig already
seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). 
GDBM is quite weak in managing changes in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? 
Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps?


Anywyay, my next step will be preparing an upgrading box to test 
bullseye->bookworm, stay tuned.

On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

Package: ypserv
Version: 4.1-2
Severity: important

Dear Maintainer,

Recently upgraded our NIS master from buster to bullseye.
when I run
cd /var/yp; make
several apps fail to run and seg fault, for example

/usr/lib/yp/yphelper  --hostname
Segmentation fault


yppush -d example.com ypservers
Segmentation fault

makedbm does appear to make valid files when run from the cmd line



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

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

Versions of packages ypserv depends on:
ii  hostname   3.23
ii  libc6  2.31-13+deb11u6
ii  libcrypt1  1:4.4.18-4
ii  libgdbm6   1.19-2
ii  libnsl21.3.0-2
ii  libsystemd0247.3-7+deb11u2
ii  libtirpc3  1.3.1-1+deb11u1
ii  lsb-base   11.1.0
ii  make   4.3-4.1
ii  rpcbind [portmap]  1.2.5-9
ii  ucf3.0043

Versions of packages ypserv recommends:
ii  yp-tools  4.2.3-3

Versions of packages ypserv suggests:
pn  krb5-kdc   
ii  ypbind-mt  2.7.2-2

-- no debconf information



--
Francesco P. Lovergine

Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.

[Jim P.]

Package: libwebkit2gtk-4.0-37
Version: 2.40.1-1~deb11u1
Severity: important
X-Debbugs-Cc: j...@k4vqc.com

Dear Maintainer,

   * What led up to the situation?

  A:  The updates to libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  A: I downgraded to previous versions of libwebkit:

apt install libwebkit2gtk-4.0-37=2.38.5-1~deb11u1 
libjavascriptcoregtk-4.0-18=2.38.5-1~deb11u1 

   * What was the outcome of this action?

  A: Downgrading to the previous release resolves the problem with Gnome 
Evolution, BUT it leaves
 the user with an unpatched version of WebKit.

   * What outcome did you expect instead?

  :)


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

Kernel: Linux 5.10.0-22-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)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap  0.4.1-3
ii  gstreamer1.0-plugins-base   1.18.4-2
ii  gstreamer1.0-plugins-good   1.18.4-2+deb11u1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  10.2.1-6
ii  libc6   2.31-13+deb11u6
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libenchant-2-2  2.2.15-1
ii  libepoxy0   1.5.5-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1
ii  libglib2.0-02.66.8-1
ii  libgpg-error0   1.38-2
ii  libgstreamer-gl1.0-01.18.4-2
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libgtk-3-0  3.24.24-4+deb11u3
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1
ii  libhyphen0  2.8.8-7
ii  libicu6767.1-7
ii  libjavascriptcoregtk-4.0-18 2.40.1-1~deb11u1
ii  libjpeg62-turbo 1:2.0.6-4
ii  liblcms2-2  2.12~rc1-2
ii  libmanette-0.2-00.2.5-1
ii  libopenjp2-72.4.0-3
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libseccomp2 2.5.1-1+deb11u1
ii  libsecret-1-0   0.20.4-2
ii  libsoup2.4-12.72.0-2
ii  libsqlite3-03.34.1-3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7+deb11u2
ii  libtasn1-6  4.16.0-2+deb11u1
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libwayland-egl1 1.18.0-2~exp1.1
ii  libwayland-server0  1.18.0-2~exp1.1
ii  libwebp60.6.1-2.1
ii  libwebpdemux2   0.6.1-2.1
ii  libwoff11.0.2-1+b1
ii  libwpe-1.0-11.10.0-2
ii  libwpebackend-fdo-1.0-1 1.8.0-1
ii  libx11-62:1.7.2-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxml2 2.9.10+dfsg-6.7+deb11u4
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.34-4+deb11u1
ii  libxt6  1:1.2.0-1
ii  xdg-dbus-proxy  0.1.2-2
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-gl   1.18.4-2
ii  gstreamer1.0-libav1.18.4-3
ii  gstreamer1.0-plugins-bad  1.18.4-3
ii  libgl1-mesa-dri   20.3.5-1
ii  xdg-desktop-portal-gtk1.8.0-1

Versions of packages libwebkit2gtk-4.0-37 suggests:
ii  gstreamer1.0-alsa  1.18.4-2

-- no debconf information

Bug#1035438: cl-quicklisp: installation instructions do not work

[Michael P. Soulier]

Package: cl-quicklisp
Version: 20150128-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: msoul...@digitaltorque.ca

Dear Maintainer,

I followed the instructions in the README

msoulier@cortado:~$ sbcl --script /usr/share/common-
lisp/source/quicklisp/quicklisp.lisp

   quicklisp quickstart 2015-01-28 loaded 

To continue with installation, evaluate: (quicklisp-quickstart:install)

For installation options, evaluate: (quicklisp-quickstart:help)

So I loaded sbcl and ran the command:

* (quicklisp-quickstart:install)

debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread
#:
  Package QUICKLISP-QUICKSTART does not exist.

So the installation did not make the library available, and it cannot be used.

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
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 cl-quicklisp depends on:
ii  sbcl [lisp-compiler]  2:2.1.1-2

cl-quicklisp recommends no packages.

cl-quicklisp suggests no packages.

Bug#993985: wireguard should not depend on wireguard-dkms or wireguard-modules in Debian 11

[Kevin P. Fleming]

Package: wireguard-tools
Followup-For: Bug #993985

Dear Maintainer,

In Debian 11 (currently 'testing'), there are no packages which provide
'wireguard-dkms', and 'wireguard-modules' is provided by the standard 'linux-
image-' packages. As a result there is no apparent value in having
'wireguard-tools' recommend either of those.

In fact on a system which intentionally does *not* have the 'linux-
image-' package installed, installing 'wireguard-tools' will pull it in
unless the user tells it not to, and may pull it in in the future when the
'wireguard-tools' package is upgraded and 'apt upgrade' is run... unless the
user once again remember to tell 'apt' to not install recommended packages.


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

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

Versions of packages wireguard-tools depends on:
ii  libc6  2.36-9

Versions of packages wireguard-tools recommends:
ii  iptables   1.8.9-2
ii  linux-image-amd64 [wireguard-modules]  6.1.20-2
ii  nftables   1.0.6-2

Versions of packages wireguard-tools suggests:
pn  openresolv | resolvconf  

-- no debconf information

Bug#1035336: release-notes: libgdal-perl dropped in Bookworm

[Francesco P. Lovergine]

Package: release-notes
Severity: normal

The ubiquitous geospatial GDAL library dropped the XS-based Perl binding, 
almost one
year ago. As a consequence the Perl binding is not more directly supported at
upstream level and developers/users that need a Perl support for GDAL must
migrate to the FFI interface provided by Geo::GDAL::FFI package, available on
CPAN. As a direct consequence, Bookworm is missing a Perl binding for GDAL
(libgdal-perl in Bullseye and previous Debian releases).

A wiki page is available at https://wiki.debian.org/BookwormGdalPerl to help
users to start migration to the new interface.

Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'

[Kevin P. Fleming]

On Mon, Apr 10, 2023, at 17:52, Reinhard Tartler wrote:
> Control: tag -1 + unreproducible moreinfo
> 
> Hi Kevin,
> 
> great to hear from you in this space!
> 
> On Thu, Feb 9, 2023 at 8:36 AM Kevin P. Fleming  wrote:
>> Package: podman
>> Version: 4.3.1+ds1-5+b1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> I am seeing DNS resolution fail when using 'podman build' but succeed when
>> using 'podman run', with a Dockerfile which contains the same commands I run
>> manually in the 'podman run'-launched shell.
>> 
>> Dockerfile
>> --
>> FROM alpine:3.10
>> RUN cat /etc/resolv.conf
>> RUN apk add tar
>  
> Unfortunately, I can't reproduce. Please help me to reproduce this issue. 
> Also, maybe upstream has an idea, can you please report this issue at 
> https://github.com/containers/podman/issues/new/choose. In any case, here is 
> the output that I get:
> 
> siretart@x1:/tmp/dnstest$ cat >> Containerfile
> FROM alpine:3.10
> RUN cat /etc/resolv.conf
> RUN apk add tar
> siretart@x1:/tmp/dnstest$ cat Containerfile
> FROM alpine:3.10
> RUN cat /etc/resolv.conf
> RUN apk add tar
> siretart@x1:/tmp/dnstest$ podman build .
> STEP 1/3: FROM alpine:3.10
> Resolved "alpine" as an alias 
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/alpine:3.10...
> Getting image source signatures
> Copying blob 396c31837116 done  
> Copying config e7b300aee9 done  
> Writing manifest to image destination
> Storing signatures
> STEP 2/3: RUN cat /etc/resolv.conf
> search int.tauware.de
> nameserver 10.0.2.3
> nameserver 192.168.88.3
> --> 2ce59772eaf
> STEP 3/3: RUN apk add tar
> fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
> fetch 
> http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
> (1/1) Installing tar (1.32-r1)
> Executing busybox-1.30.1-r5.trigger
> OK: 6 MiB in 15 packages
> COMMIT
> --> 7c1bfd9e030
> 7c1bfd9e030f07b05cc9427a97c0bc5ff73bca5436bce389ad81da1a64f64a11

Confirmed; I can no longer reproduce the problem. Something somewhere in the 
stack got fixed :-)

Bug#983600: Is there a workaround for this?

[Kevin P. Fleming]

This package is a transitive *unused* dependency of something I'm trying to 
cross-build (using pbuilder), and the fact that I can't install it stops the 
entire process. If there's any way I can force this package to be installed 
despite the broken dependency chain I could likely make progress.

Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf

[Francesco P. Lovergine]

On Tue, Feb 14, 2023 at 11:28:50AM +0100, Chris Hofstaedtler wrote:

Hi,

multipath-tools upstream has in the past changed the defaults a
number of times, and I think has now settled on "the best thing to
do is manually configure it, because otherwise lots of edge cases
pop up".

* Francesco P. Lovergine  [230214 09:18]:

I finally figured out that

multipath -t >/etc/multipath.conf

generates an initial configuration which is usable, but for a

find_multipaths "strict"

which is the least friendly way of defining mappings and
practically prevents any auto-mapping (wwids need to be provided by hand).


Well, it wants you to use the `multipath` program to add a
binding/wwid. This is quite explicit, but also always works.
In my experience, once you leave the realm of test setups, its best
to have explicit configuration.



Well, at least some notes about the required manual configuration and steps
to get the wwids (e.g. hinting /lib/udev/scsi_id) and finalize the config,
or even alternative settings would be nice. 
I find the README.Debian included not the most clear possible. 


[...]

I'll note that this is a sample for 0.4.9, and this is very old.

Chris



That's taken from RHEL 7 documentation, I `suppose` now it is updated.


--
Francesco P. Lovergine

Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf

[Francesco P. Lovergine]

Package: multipath-tools
Version: 0.9.4-3
Severity: wishlist

Hi, 

after installation multipath-tools does not work properly in order to activate
mapping for devices automagically after the boot. 

I finally figured out that

multipath -t >/etc/multipath.conf

generates an initial configuration which is usable, but for a

find_multipaths "strict"

which is the least friendly way of defining mappings and 
practically prevents any auto-mapping (wwids need to be provided by hand).

While that is a perfectly working setup if properly manually configured, for 
sure it is 
not the easiast setting to cope with IMHO.

The final result, for instance, is that LVM could catch all single devices at 
boot 
and the  proper multipaths maps result broken, with the admin not familiar with
multipathd inners lost in the dark.

A very simple configuration such as:

defaults {
user_friendly_names yes
find_multipaths yes
}

and a round of update-initramfs after that, gives a proper working 
implementation, with
LVM perfectly capable of coping with variable names at boot time.

Note that RH folks provides a mpathconf script and an initial template
in /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf for that.

-- 
Francesco P. Lovergine

Bug#1031174: transmission-gtk: Transmission 4.0.0 is available

[Tiger!P]

Package: transmission-gtk
Version: 3.00-2.1+b1
Severity: normal

Dear Maintainer,

Transmission 4.0.0 has been released [1].
Could you create a package for this new version?

[1] https://transmissionbt.com/download and 
https://github.com/transmission/transmission/releases/tag/4.0.0

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

Kernel: Linux 6.0.0-6-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

Versions of packages transmission-gtk depends on:
ii  libayatana-appindicator3-1  0.5.92-1
ii  libc6   2.36-8
ii  libcurl47.87.0-2
ii  libevent-2.1-7  2.1.12-stable-5+b1
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.74.5-1
ii  libgtk-3-0  3.24.36-3
ii  libminiupnpc17  2.2.4-1+b1
ii  libnatpmp1  20150609-7.1+b2
ii  libpango-1.0-0  1.50.12+ds-1
ii  libssl3 3.0.7-2
ii  transmission-common 3.00-2.1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages transmission-gtk recommends:
ii  xdg-utils  1.1.3-4.1

transmission-gtk suggests no packages.

-- no debconf information

Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'

[Kevin P. Fleming]

Package: podman
Version: 4.3.1+ds1-5+b1
Severity: important

Dear Maintainer,

I am seeing DNS resolution fail when using 'podman build' but succeed when
using 'podman run', with a Dockerfile which contains the same commands I run
manually in the 'podman run'-launched shell.

Dockerfile
--
FROM alpine:3.10
RUN cat /etc/resolv.conf
RUN apk add tar

'podman run'
--
kpfleming@nvr21:~/ctr-dns$ podman run --rm -it alpine:3.10 /bin/sh
/ # cat /etc/resolv.conf
nameserver 10.0.2.3
nameserver 2001:470:8afe:255::2
options edns0 trust-ad
/ # apk add tar
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-
cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tar (1.32-r1)
Executing busybox-1.30.1-r5.trigger
OK: 6 MiB in 15 packages
/ # exit

`podman build`
--
kpfleming@nvr21:~/ctr-dns$ podman build .
STEP 1/3: FROM alpine:3.10
STEP 2/3: RUN cat /etc/resolv.conf
--> Using cache
6e684b0a8063a3c6ea051cc28b16ea19cc984ba9f154810cc3235d10e2ad4b2b
--> 6e684b0a806
STEP 3/3: RUN apk add tar
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.10/main: temporary error (try
again later)
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.10/main: No such file
or directory
fetch http://dl-
cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.10/community: temporary error
(try again later)
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.10/community: No such
file or directory
ERROR: unable to select packages:
  tar (no such package):
required by: world[tar]
Error: building at STEP "RUN apk add tar": while running runtime: exit status 1

When I add 'strace' to the image and trace the 'apk' invocation, I see that the
DNS queries sent to the servers listed in /etc/resolv.conf both time out, when
using 'podman build'.

I have tested the 4.4 package from 'experimental' with no change in behavior.


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

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

Versions of packages podman depends on:
ii  conmon   2.1.3+ds1-1
ii  crun 1.5+dfsg-1+b1
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-8
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  libsubid41:4.13+dfsg1-1
ii  runc 1.1.4+ds1-1+b1

Versions of packages podman recommends:
ii  buildah1.28.2+ds1-1
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.4-1
ii  fuse-overlayfs 1.9-1
ii  slirp4netns1.2.0-1
ii  uidmap 1:4.13+dfsg1-1

Versions of packages podman suggests:
ii  containers-storage  1.43.0+ds1-7
pn  docker-compose  
ii  iptables1.8.9-2

-- no debconf information

Bug#1030032: LLVM: should use debian multiarch

[Konstantin P.]

Package: src:llvm-toolchain-14
Version: 1:14.0.6-10
Distro: debian bookworkm

I want to cross-compile simple CMake project to mipsel in x86_64 machine. I
found than I cannot co-install LLVM versions from different architectures
by apt into one Debian machine. Even when I do not need llvm-config and any
of llvm binaries of mipsel architecture, only libraries and CMake files, I
cannot install llvm-14-dev:mipsel, because it depends on llvm-14:mipsel,
where all binaries are packaged, and llvm-14:mipsel conflicts with
llvm-14:amd64.

If all libraries and cmake files will be installed in
/usb/lib/DEB_HOST_MULTIARCH/, and will not depend on binaries (or depend on
binaries of "native" arch, if it is absolutely required), then CMake
projects can be compiled and packaged by cross-building with LLVM.

For now, it is not possible.

I found a similar bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897275, as wontfix. But
they are requesting a pkg-config file, which I do not need, I want only
better packaging, when I can use LLVM to cross-compile CMake packages by
installing it using APT without dirty hacks.

Bug#1029197: ip-transparent: yes is blocked by apparmor

[Tiger!P]

Package: unbound
Version: 1.17.0-1
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?
I wanted to configure a static IPv6 address in unbound, but that is not
(always) available when booting the system. Therefor I enabled
ip-transparent in the server section.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When I enabled 'ip-transparent: yes' in the server section, apparmor
blocked some capabilities when restarting unbound.

Jan 19 13:37:20 kernel: audit: type=1400 audit(1674131840.250:65): 
apparmor="DENIED" operation="capable" profile="unbound" pid=1072585 
comm="unbound" capability=13  capname="net_raw"
Jan 19 13:37:20 kernel: audit: type=1400 audit(1674131840.250:66): 
apparmor="DENIED" operation="capable" profile="unbound" pid=1072585 
comm="unbound" capability=12  capname="net_admin"


   * What outcome did you expect instead?

I would have expected that unbound would not be blocked by apparmor and
would be able to use the ip-transparent option without issue.


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

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

Versions of packages unbound depends on:
ii  adduser3.130
ii  init-system-helpers1.65.2
ii  libc6  2.36-8
ii  libevent-2.1-7 2.1.12-stable-5+b1
ii  libnghttp2-14  1.51.0-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libpython3.10  3.10.9-1
ii  libssl33.0.7-1
ii  libsystemd0252.4-1
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

Versions of packages unbound recommends:
ii  dns-root-data  2023010101

Versions of packages unbound suggests:
ii  apparmor  3.0.8-1
ii  openssl   3.0.7-1

-- no debconf information

Content-Type: multipart/mixed; boundary="===4881449298252092416=="
MIME-Version: 1.0
From: TigerP 
To: Debian Bug Tracking System 
Subject: ip-transparent: yes is blocked by apparmor
Bcc: TigerP 
Message-ID: 
<167413411988.1072823.1845641849211757387.report...@melaine.andor.aybara.org>
X-Mailer: reportbug 11.6.0
Date: Thu, 19 Jan 2023 14:15:19 +0100

This is a multi-part MIME message sent by reportbug.


--===4881449298252092416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: unbound
Version: 1.17.0-1
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?
I wanted to configure a static IPv6 address in unbound, but that is not 
(always) available when booting the system. Therefor I enabled ip-transparent 
in the server section.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When I enabled 'ip-transparent: yes' in the server section, apparmor blocked 
some capabilities when restarting unbound.

Jan 19 13:37:20 kernel: audit: type=1400 audit(1674131840.250:65): 
apparmor="DENIED" operation="capable" profile="unbound" pid=1072585 
comm="unbound" capability=13  capname="net_raw"
Jan 19 13:37:20 kernel: audit: type=1400 audit(1674131840.250:66): 
apparmor="DENIED" operation="capable" profile="unbound" pid=1072585 
comm="unbound" capability=12  capname="net_admin"


   * What outcome did you expect instead?

I would have expected that unbound would not be blocked by apparmor and would 
be able to use the ip-transparent option without issue.


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

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

Versions of packages unbound depends on:
ii  adduser3.130
ii  init-system-helpers1.65.2
ii  libc6  2.36-8
ii  libevent-2.1-7 2.1.12-stable-5+b1
ii  libnghttp2-14  1.51.0-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libpython3.10  3.10.9-1
ii  libssl33.0.7-1
ii  libsystemd0252.4-1
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

Versions of packages unbound recommends:
ii  dns-root-data  2023010101

Versions of packages unbound suggests:
ii  apparmor  3.0.8-1
ii  openssl   3.0.7-1

-- no debconf information

--===4881449298252092416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0

Bug#1027709: has_option command not found

[Francesco P. Lovergine]

Package: x2goserver-xsession
Version: 4.1.0.3-5
Severity: normal

Launching an x2go session on a sid host, my .xsession-x2go--errors
is populated of errors, like (sorry for the italian lang):

/etc/x2go/Xsession.d/30x11-common_xresources: riga 16: has_option: comando non 
trovato
/etc/x2go/Xsession.d/75dbus_dbus-launch: riga 9: has_option: comando non trovato
/etc/x2go/Xsession.d/90x11-common_ssh-agent: riga 9: has_option: comando non 
trovato

This is very similar to recurring error seen elsewhere due to a missing 
execution of /etc/X11/Xsession, e.g.

https://github.com/canonical/lightdm/issues/198
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1922414

Apparently this could also prevent x2go session starting (still not sure: 
currently the session starts and exits, 
with a warning:
dbus-update-activation-environment: warning: error sending to systemd: 
org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 
exited with status 1
).

-cheers

-- 
Francesco P. Lovergine

Bug#1027476: cron: postrm script fails because expected dpkg-statoverride is not present

[Kevin P. Fleming]

Package: cron
Version: 3.0pl1-154
Severity: normal

Dear Maintainer,

The postrm script in the current version of the cron package assumes the
presence of a dpkg-statoverride for /usr/bin/crontab, but no such statoverride
is present on my systems. As a result when I try to 'purge' the cron package
the process fails.

Recipe to reproduce the issue:

1) cd /root
2) mkdir foo
3) debootstrap --variant=minbase --include=logrotate,systemd-cron bookworm
4) chroot /root/foo /bin/bash
5) apt remove --purge cron

This results in the following output:

Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  cron*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 11054 files and directories currently installed.)
Purging configuration files for cron (3.0pl1-154) ...
dpkg-statoverride: warning: no override present
dpkg: error processing package cron (--purge):
 installed cron package post-removal script subprocess returned error exit
status 2
Errors were encountered while processing:
 cron
E: Sub-process /usr/bin/dpkg returned an error code (1)

Editing /var/lib/dpkg/info/cron.postrm to remove the first section resolves the
issue.


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

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

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-154
ii  init-system-helpers  1.65.2
ii  libc62.36-7
ii  libpam-runtime   1.5.2-5
ii  libpam0g 1.5.2-5
ii  libselinux1  3.4-1+b4
ii  sensible-utils   0.0.17

Versions of packages cron recommends:
ii  msmtp-mta [mail-transport-agent]  1.8.22-1

Versions of packages cron suggests:
pn  checksecurity   
ii  logrotate   3.21.0-1
ii  systemd-cron [anacron]  1.15.19-2+b1

Bug#1027006: Acknowledgement (hexchat: URL handling mechanism is broke under KDE)

[Felicia P]

Found the source of the issue with the gio command when running:

$ desktop-file-install --dir=$HOME/.local/share/applications 
.local/share/applications/firefox.desktop


value "\\$HOME/.local/firefox/firefox %u" for key "Exec" in group 
"Desktop Entry" contains a reserved character '$' outside of a quote


Adding quotes didn't help.  The solution was to hard-code my home 
directory in the Exec= line instead of using $HOME.  Then the gio 
command successfully runs:


$ gio mime x-scheme-handler/http firefox.desktop
Set firefox.desktop as the default for x-scheme-handler/http

$ gio mime x-scheme-handler/https firefox.desktop
Set firefox.desktop as the default for x-scheme-handler/https

$ gio mime x-scheme-handler/https
Default application for “x-scheme-handler/https”: firefox.desktop
Registered applications:
firefox.desktop
chromium.desktop
kfmclient_html.desktop
Recommended applications:
firefox.desktop
chromium.desktop
kfmclient_html.desktop


On 12/25/22 23:06, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1027006: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027006.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Mattia Rizzolo 

If you wish to submit further information on this problem, please
send it to 1027...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#1027006: hexchat: URL handling mechanism is broke under KDE

[Felicia P]

Package: hexchat
Version: 2.14.3-6+deb11u1
Severity: normal

Dear Maintainer,

According to the Hexchat FAQ
[https://hexchat.readthedocs.io/en/latest/faq.html#how-do-i-change-what-browser-is-opened]
in order to configure the file association for http and https links the
user is directed to use the 'gio' utility.  For example:
  gio mime x-scheme-handler/http firefox.desktop
  gio mime x-scheme-handler/https firefox.desktop

For users of KDE these commands will not run successfully, and other
methods of configuring http and https mimetype associations such as
setting [Default Applications] in ~/.config/mimetypes.list or in
~/.local/share/applications/mimetypes.list also have no effect.

Also note that the other two examples in the fact which use gvfs-mime
will not work either in Bullseye because gvfs-mime is deprecated and
points to gio.

The end result is that it is not possible to configure the http and
https mime type associations for Hexchat.

Instead, Hexchat should use a destkop-environment-neutral mime mechanism such as
xdg-mime.



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

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

Versions of packages hexchat depends on:
ii  hexchat-common   2.14.3-6+deb11u1
ii  libc62.31-13+deb11u5
ii  libcanberra0 0.30-7
ii  libdbus-glib-1-2 0.110-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk2.0-0  2.24.33-2
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libproxy1v5  0.4.17-1
ii  libssl1.11.1.1n-0+deb11u3
ii  libx11-6 2:1.7.2-5~ubuntu18.04

Versions of packages hexchat recommends:
ii  ca-certificates  20210119
ii  hexchat-perl 2.14.3-6+deb11u1
ii  hexchat-plugins  2.14.3-6+deb11u1
ii  hexchat-python3  2.14.3-6+deb11u1
ii  libglib2.0-bin   2.66.8-1

Versions of packages hexchat suggests:
pn  hexchat-otr  
pn  unifont  

-- no debconf information

Bug#1026353: mariadb-server: mariadb does not start after bullseye point release 11.6

[Matthew P Zagrabelny]

Package: mariadb-server
Version: 1:10.5.18-0+deb11u1
Severity: important

Dear Maintainer,

Unattended upgrade upgraded mariadb this morning and now the service does not
start:

Start-Date: 2022-12-18  06:15:03
Commandline: /usr/bin/unattended-upgrade
Upgrade: mariadb-server:amd64 (1:10.5.15-0+deb11u1, 1:10.5.18-0+deb11u1), 
mariadb-server-10.5:amd64 (1:10.5.15-0+deb11u1, 1:10.5.18-0+deb11u1)
End-Date: 2022-12-18  06:15:09

# systemctl status mariadb.service
● mariadb.service - MariaDB 10.5.18 database server
 Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Sun 2022-12-18 15:25:38 CST; 
38min ago
   Docs: man:mariadbd(8)
 https://mariadb.com/kb/en/library/systemd/
Process: 481 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d 
/var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 498 ExecStartPre=/bin/sh -c systemctl unset-environment 
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 507 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && 
VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && 
systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, 
status=0/SUCCESS)
Process: 604 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER 
$_WSREP_START_POSITION (code=exited, status=1/FAILURE)
   Main PID: 604 (code=exited, status=1/FAILURE)
 Status: "MariaDB server is down"
CPU: 190ms

Dec 18 15:25:36 mariadb-test-system systemd[1]: Starting MariaDB 10.5.18 
database server...
Dec 18 15:25:37 mariadb-test-system mariadbd[604]: 2022-12-18 15:25:37 0 [Note] 
/usr/sbin/mariadbd (mysqld 10.5.18-MariaDB-0+deb11u1) starting as process 604 
...
Dec 18 15:25:38 mariadb-test-system systemd[1]: mariadb.service: Main process 
exited, code=exited, status=1/FAILURE
Dec 18 15:25:38 mariadb-test-system systemd[1]: mariadb.service: Failed with 
result 'exit-code'.
Dec 18 15:25:38 mariadb-test-system systemd[1]: Failed to start MariaDB 10.5.18 
database server.

I've run:

# strace -f /usr/sbin/mariadbd

but there isn't anything that sticks out to me.

# journalctl -xe

Dec 18 16:09:48 mariadb-test-system systemd[1]: Starting MariaDB 10.5.18 
database server...
░░ Subject: A start job for unit mariadb.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit mariadb.service has begun execution.
░░
░░ The job identifier is 789.
Dec 18 16:09:49 mariadb-test-system mariadbd[8369]: 2022-12-18 16:09:49 0 
[Note] /usr/sbin/mariadbd (mysqld 10.5.18-MariaDB-0+deb11u1) starting as 
process 8369 ...
Dec 18 16:09:49 mariadb-test-system systemd[1]: mariadb.service: Main process 
exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit mariadb.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Dec 18 16:09:49 mariadb-test-system systemd[1]: mariadb.service: Failed with 
result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit mariadb.service has entered the 'failed' state with result 
'exit-code'.
Dec 18 16:09:49 mariadb-test-system systemd[1]: Failed to start MariaDB 10.5.18 
database server.
░░ Subject: A start job for unit mariadb.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit mariadb.service has finished with a failure.
░░
░░ The job identifier is 789 and the job result is failed.


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

Kernel: Linux 5.10.0-20-amd64 (SMP w/1 CPU thread)
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 mariadb-server depends on:
ii  mariadb-server-10.5  1:10.5.18-0+deb11u1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- no debconf information

Bug#1005092: [EXTERNAL] pytest-mpl: Request to review new version 0.16.1-1

[Singer, Leo P. (GSFC-6610)]

Hi Daichi,

I can’t sponsor it myself because I cannot get to my Debian key at the moment 
(it’s in my safety deposit box and I can’t find they key to it). Ole might be 
able to help you.

Leo

From: Daichi Fukui 
Date: Wednesday, November 23, 2022 at 08:10
To: "1005...@bugs.debian.org" <1005...@bugs.debian.org>
Cc: Leo Singer , "leo.sin...@ligo.org" 
, "D. Fukui" 
Subject: [EXTERNAL] pytest-mpl: Request to review new version 0.16.1-1

Hello Leo,

>
> It's been a while since we had a conversation some ten days ago.
> I just want to let you know that I'm still working on this and need some
> time to complete the package draft.
> This is because pytest returns a bunch of errors with the updated source
> code.
> I'm now trying to address them.
>
> Best,
> Fukui

Thanks for waiting for a long time.

I've created a new version of pytest-mpl source package [0], which is going to 
be 0.16.1-1 with this package.
This draft includes the following updates:
  * New upstream version 0.16.1 (Closes: #1005092)
  * Update copyright
  * Patch: adapt to upstream
  * Update d/watch version
  * Update d/copyright
  * Update debhelper version to 13
  * Add libjs-bootstrap and libjs-bootstrap4 as Depends
  * Update standards version
  * Add Rules-Requires-Root field
  * d/patches: update fields and indexes
  * Add the following new patches to address lintian reports
* Use-packaged-bootstrap.bundle.min.js.patch
* Add-mpl_image_compare-to-markers.patch
* Skip-failing-tests.patch
* Use-packaged-bootstrap.min.css.patch

If this update is satisfactory and helpful,
I would appreciate it if you review and sponsor this draft source package.

[0] 
https://salsa.debian.org/dfukui/pytest-mpl

Best,
Fukui

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Kevin P. Fleming]

On Sun, Nov 20, 2022, at 12:56, Kevin P. Fleming wrote:
> On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote:
>
>> If that would be helpful, we have some instructions on "simple
>> patching and building" the kernel with a additional patches on top
>> here:
>>
>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
>
> I found those via another path, and used them :-) Had a few little 
> issues along the way: failing to set DEBFULLNAME produces a broken 
> changelog entry so then the build won't run (and leaves the tree in a 
> broken state as well). Once I solved that problem I was able to make 
> packages, but the linux-headers-common package didn't get produced, so 
> I had to use --force-depends-version when installing the packages 
> (which I knew was safe since the headers had not changed).
>
> I now have the patched kernel in operation and should know whether the 
> problem is solved in 24-48 hours.

It's been more than 24 hours and connectivity is still in place, and it never 
lasted this long without the patch. I'm comfortable saying that this patch 
resolved the problem.

Bug#1024581: Acknowledgement (linux-image-6.0.0-0.deb11.2-amd64: System freeze)

[Felicia P]

Sorry the initial report was terse because I tried to get the bug sent 
out while running the buggy kernel before it froze.


Here is some more information:

In syslog there are messages like the following:

Message from syslogd@compute2 at Nov 21 08:38:58 ...
 kernel:[  256.407191] watchdog: BUG: soft lockup - CPU#10 stuck for 
44s! [kwor

ker/u48:0:9]

Message from syslogd@compute2 at Nov 21 08:39:18 ...
 kernel:[  276.291100] watchdog: BUG: soft lockup - CPU#1 stuck for 
23s! [migration/1:21]


Message from syslogd@compute2 at Nov 21 08:39:26 ...
 kernel:[  284.407071] watchdog: BUG: soft lockup - CPU#10 stuck for 
70s! [kworker/u48:0:9]


Message from syslogd@compute2 at Nov 21 08:39:46 ...
 kernel:[  304.291026] watchdog: BUG: soft lockup - CPU#1 stuck for 
49s! [migration/1:21]



The machine is a SuperMicro SYS-1028R-WTNR server

Please let me know if I can provide any more info.

--
Felicia

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Kevin P. Fleming]

On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote:

> If that would be helpful, we have some instructions on "simple
> patching and building" the kernel with a additional patches on top
> here:
>
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2

I found those via another path, and used them :-) Had a few little issues along 
the way: failing to set DEBFULLNAME produces a broken changelog entry so then 
the build won't run (and leaves the tree in a broken state as well). Once I 
solved that problem I was able to make packages, but the linux-headers-common 
package didn't get produced, so I had to use --force-depends-version when 
installing the packages (which I knew was safe since the headers had not 
changed).

I now have the patched kernel in operation and should know whether the problem 
is solved in 24-48 hours.

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Kevin P. Fleming]

On Sun, Nov 20, 2022, at 08:15, Salvatore Bonaccorso wrote:
> Hi,
>
> On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
>> Control: tags -1 + moreinfo
>> 
>> Hi,
>> 
>> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
>> > Package: src:linux
>> > Version: 6.0.7-1
>> > Severity: normal
>> > Tags: ipv6
>> > 
>> > Dear Maintainer,
>> > 
>> > This system has been operating for most of the last 12 months, using
>> > ProxyNDP on its external interface for eight addresses. After
>> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
>> > solicitations for those addresses after startup... it does not happen
>> > immediately, but reliably occurs. When the system is in this state
>> > (not responding to ND solicitations for the proxy addresses), the
>> > proxy addresses are still shown in 'ip neigh show proxy', and the
>> > single non-proxy address on the same interface continues operating
>> > normally.
>> > 
>> > Booting the system with the 5.19.0-2 kernel package cures the problem,
>> > with no other changes.
>> > 
>> > Example output:
>> > 
>> > root@net22:~# ip neigh show proxy
>> > 2607:5300:203:9743::1 dev ve-diw20 proxy 
>> > 2607:5300:203:9743::1 dev ve-matrix20 proxy 
>> > 2607:5300:203:9743::1 dev ve-ns3 proxy 
>> > 2607:5300:203:9743::1 dev ve-ldl20 proxy 
>> > 2607:5300:203:9743::1 dev ve-quassel21 proxy 
>> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy 
>> > 2607:5300:203:9743::1 dev ve-monica21 proxy 
>> > 2607:5300:203:9743::1 dev ve-mail20 proxy 
>> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy 
>> > 
>> > The addresses on enp1s0f0 are the ones which stop responding.
>> 
>> Does the following matches your problem?
>> 
>> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
>> 
>> Would you be able to test the mentioned patch to verify a fix for your
>> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
>> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
>
> For reference, the commit would be v2 as applied in netdev as
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1

While that description does not exactly match my problem, it is so similar as 
to almost certainly be the cause. I would be happy to try applying that patch, 
but it's been a while since I built a patched Debian kernel so it may take a 
couple of days :-)

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Kevin P. Fleming]

Package: src:linux
Version: 6.0.7-1
Severity: normal
Tags: ipv6

Dear Maintainer,

This system has been operating for most of the last 12 months, using
ProxyNDP on its external interface for eight addresses. After
upgrading to the 6.0 kernel series, the kernel stops responding to ND
solicitations for those addresses after startup... it does not happen
immediately, but reliably occurs. When the system is in this state
(not responding to ND solicitations for the proxy addresses), the
proxy addresses are still shown in 'ip neigh show proxy', and the
single non-proxy address on the same interface continues operating
normally.

Booting the system with the 5.19.0-2 kernel package cures the problem,
with no other changes.

Example output:

root@net22:~# ip neigh show proxy
2607:5300:203:9743::1 dev ve-diw20 proxy 
2607:5300:203:9743::1 dev ve-matrix20 proxy 
2607:5300:203:9743::1 dev ve-ns3 proxy 
2607:5300:203:9743::1 dev ve-ldl20 proxy 
2607:5300:203:9743::1 dev ve-quassel21 proxy 
2607:5300:203:9743::1 dev ve-mastodon22 proxy 
2607:5300:203:9743::1 dev ve-monica21 proxy 
2607:5300:203:9743::1 dev ve-mail20 proxy 
2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
2607:5300:203:9743:7::1 dev enp1s0f0 proxy 

The addresses on enp1s0f0 are the ones which stop responding.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: GIGABYTE
product_name: MX33-BS1-V1
product_version: 0100
chassis_vendor: GIGABYTE
chassis_version: To be filled by O.E.M.
bios_vendor: GIGABYTE
bios_version: F04a
board_vendor: GIGABYTE
board_name: MX33-BS1-V1
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4c53] (rev 01)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: icl_uncore

00:08.0 System peripheral [0880]: Intel Corporation Device [8086:4c11] (rev 01)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:12.0 Serial controller [0700]: Intel Corporation Tiger Lake-H Integrated 
Sensor Hub [8086:43fc] (rev 11) (prog-if 00 [8250])
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Integrated Sensor 
Hub [1458:1000]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: intel_ish_ipc

00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 
xHCI Host Controller [8086:43ed] (rev 11) (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H USB 3.2 Gen 2x1 
xHCI Host Controller [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-H Shared SRAM 
[8086:43ef] (rev 11)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Shared SRAM 
[1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-H Serial IO 
I2C Controller #0 [8086:43e8] (rev 11)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Serial IO I2C 
Controller [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-H 
Management Engine Interface [8086:43e0] (rev 11)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Management Engine 
Interface [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 

Bug#1022810: ddclient: Package installation does not respect systemd preset for disabling service

[Kevin P. Fleming]

Package: ddclient
Version: 3.9.1-7.1
Severity: normal

Dear Maintainer,

A systemd preset file is created to ensure that ddclient is not
automatically enabled and started, as in:

/etc/systemd/system-preset/00-ddclient.service.preset

disable ddclient.service


The ddclient package is then installed, and does not get enabled, but
does get started.

The preset file should be respected so that the admin's wishes for managing
the service state are taken into account.

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

Kernel: Linux 5.19.0-2-arm64 (SMP w/4 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), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.65.2
ii  libdata-validate-ip-perl   0.30-1
ii  lsb-base   11.4
ii  perl   5.34.0-5
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages ddclient recommends:
pn  libdigest-sha-perl   
ii  libio-socket-inet6-perl  2.73-1
ii  libio-socket-ssl-perl2.075-1
ii  perl [libjson-pp-perl]   5.34.0-5

ddclient suggests no packages.

-- debconf information:
  ddclient/password-repeat: (password omitted)
  ddclient/password: (password omitted)
* ddclient/server:
* ddclient/username: fsfgfdgd
  ddclient/interface:
* ddclient/names: fgfdfds
  ddclient/protocol-other:
  ddclient/proxy:
* ddclient/password-mismatch:
  ddclient/blankhostslist:
  ddclient/run_mode: As a daemon
  ddclient/hostslist:
* ddclient/protocol: dyndns2
  ddclient/daemon_interval: 5m
* ddclient/method: Web-based IP discovery service
  ddclient/web-url: https://api.ipify.org/
  ddclient/fetchhosts: Manually
  ddclient/web: ipify-ipv4 https://api.ipify.org/
* ddclient/service: other

Bug#1022131: AttributeError: 'Table' object has no attribute 'count' with gourmand

[p....@orange.fr]

Package: gourmand
Version: 1.1.0+really1.0.0-1
Severity: important
Tags: a11y

Dear Maintainer,

PAckage gourmand is terminating with "AttributeError: 'Table' object has 
no attribute 'count'" error


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

Kernel: Linux 6.0.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gourmand depends on:
ii  gir1.2-gtk-3.0   3.24.34-3
ii  python3  3.10.6-1
ii  python3-argcomplete  2.0.0-1
ii  python3-bs4  4.11.1-2
ii  python3-gi   3.42.2-2
ii  python3-gi-cairo 3.42.2-2
ii  python3-gst-1.0  1.20.3-1+b1
ii  python3-lxml 4.9.1-1+b1
ii  python3-pil  9.2.0-1+b1
ii  python3-reportlab    3.6.11-1
ii  python3-requests 2.27.1+dfsg-1
ii  python3-sqlalchemy   1.4.31+ds1-1
ii  python3-toml 0.10.2-1

Versions of packages gourmand recommends:
ii  gir1.2-poppler-0.18    22.08.0-2.1
ii  python3-gtkspellcheck  4.0.5-3
ii  python3-pyglet 1.5.27+ds-1

Versions of packages gourmand suggests:
pn  python3-ebooklib  

The complete error log:
 > gourmand
args = Namespace(db_url='', threads=False, gourmanddir='', 
thread_debug_interval=5.0, thread_debug=False, debug_file='', 
time=False, debug=None)

WARNING: Plugin module import failed
PATH: ['/usr/bin', '/usr/lib/python310.zip', '/usr/lib/python3.10', 
'/usr/lib/python3.10/lib-dynload', 
'/usr/local/lib/python3.10/dist-packages', 
'/usr/lib/python3/dist-packages', 
'/usr/lib/python3/dist-packages/gourmand/plugins', 
'/usr/lib/python3/dist-packages/gourmand/plugins/import_export']

Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", 
line 300, in get_module

     self._loaded = __import__(self.module)
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/web_import_plugin/__init__.py", 
line 1, in 

     from . import generic_web_importer_plugin
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/web_import_plugin/generic_web_importer_plugin.py", 
line 6, in 
     from gourmand.plugins.import_export.website_import_plugins.state 
import \
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/__init__.py", 
line 1, in 

     from . import (about_dot_com_plugin, allrecipes_plugin,
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/allrecipes_plugin.py", 
line 3, in 

     from . import schema_org_parser
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/schema_org_parser.py", 
line 7, in 

     import scrape_schema_recipe
ModuleNotFoundError: No module named 'scrape_schema_recipe'
WARNING: Failed to load plugin web_import_plugin
ERROR:root:
Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", 
line 129, in load_active_plugins

self.active_plugins.extend(self.available_plugin_sets[p].plugins)
   File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", 
line 312, in __getattr__

     return self.get_plugins()
   File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", 
line 320, in get_plugins

     return self.get_module().plugins
AttributeError: 'NoneType' object has no attribute 'plugins'
WARNING: Plugin module import failed
PATH: ['/usr/bin', '/usr/lib/python310.zip', '/usr/lib/python3.10', 
'/usr/lib/python3.10/lib-dynload', 
'/usr/local/lib/python3.10/dist-packages', 
'/usr/lib/python3/dist-packages', 
'/usr/lib/python3/dist-packages/gourmand/plugins', 
'/usr/lib/python3/dist-packages/gourmand/plugins/import_export']

Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", 
line 300, in get_module

     self._loaded = __import__(self.module)
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/__init__.py", 
line 1, in 

     from . import (about_dot_com_plugin, allrecipes_plugin,
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/allrecipes_plugin.py", 
line 3, in 

     from . import schema_org_parser
   File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/schema_org_parser.py", 
line 7, in 

     import scrape_schema_recipe
ModuleNotFoundError: No module named 'scrape_schema_recipe'
WARNING: Failed to load plugin website_import_plugins
ERROR

Bug#1022070: Info received (Booting semi-hangs with 'drm_atomic_helper_wait_for_flip_done' errors and alike)

[Kroon P C, Peter]

... and of course I managed to make a typo.
It should be Kernel: 5.10.0-19-amd64 x86_64 as in the original report.
Apologies for the noise.

Peter


Van: Debian Bug Tracking System 
Verzonden: donderdag 20 oktober 2022 14:12
Aan: Kroon P C, Peter
Onderwerp: Bug#1022070: Info received (Booting semi-hangs with 
'drm_atomic_helper_wait_for_flip_done'  errors and alike)

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 unknown-pack...@qa.debian.org

If you wish to submit further information on this problem, please
send it to 1022...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1022070: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D1022070data=05%7C01%7Cp.c.kroon%40pl.hanze.nl%7C8e4d84cbae284876a89308dab2945783%7Ca3b390147adc48faa11437c2434dbd69%7C0%7C0%7C638018647788582517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Tt9qgmwWl2%2BPfXgtY1OecRmGRLiVLvJFBQImbWU97Ok%3Dreserved=0
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1022070: Booting semi-hangs with 'drm_atomic_helper_wait_for_flip_done' errors and alike

[Kroon P C, Peter]

Hi all,

I'm encountering the same issue on the following hardware:

Kernel: 5.10.0-18-amd64 x86_64
bits: 64 
Distro: Debian GNU/Linux 11 (bullseye) 

Machine type: Mini-pc 
System: ASUSTeK 
product: MINIPC PN50 
UEFI: ASUSTeK 

CPU Info: Quad Core AMD Ryzen 3 4300U with Radeon Graphics [MCP] 
speed: 1367 MHz 
min/max: 1400/2700 MHz 

Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir 
driver: amdgpu 
v: kernel 

Display server: X.org 1.20.11 
loaded: amdgpu,ati
unloaded: fbdev,modesetting,vesa

Happy to help, let me know if I can provide more details.

Peter

Bug#1005092: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13

[Singer, Leo P. (GSFC-6610)]

Hi Daichi,

Yes, I can do that next week. (I am traveling and do not have my Debian key on 
me.)

Leo

From: Daichi Fukui 
Date: Tuesday, October 18, 2022 at 09:36
To: "1005...@bugs.debian.org" <1005...@bugs.debian.org>
Cc: "leo.sin...@ligo.org" 
Subject: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13

Dear maintainer
CC: Leo Singer

> Dear maintainer,
>
> I am currently packaging cmyt [1], which is a new dependency of the "yt"
> package. For testing, cmyt requires at least version 0.13 of pytest-mpl.
> Could I ask to update the version in Debian to this latest version?
>
> Thank you very much!
>
> Ole
If you don't mind, can I work on updating this package to version 0.13?
I'd be happy if I could contribute to this one and the Astro team.

FYI, I've CC'd this email to Leo because it seems Leo is the top contributor 
according to d/changelog.

Best,
Fukui

Bug#1019428: Please, fix sudo to cope with libgcrypt changes (apparently)

[Francesco P. Lovergine]

On Fri, Sep 09, 2022 at 07:38:48PM +0200, Marc Haber wrote:

Control: tag -1 unreproducible

On Fri, Sep 09, 2022 at 08:58:29AM +0200, Francesco P. Lovergine wrote:

Sudo reports tons of messages like:

sudo: Libgcrypt warning: missing initialization - please fix the application

in syslog. Please, fix to avoid eccessive verbosity due to that. This is a
quite annoying issue already fixed in other applications here and there (e.g. 
apt).


I do not see this behavior on my systems at all. Can you please
elaborate a bit?

Greetings
Marc



Indeed it seeems the warning is triggered under certain conditions that I still 
did
not detect. 

For sure, the warning is presented only during the first use of 
sudo in a login shell and it seems the same warning is presented for ssh,

immediately beforei that. Just to note, the same warning is confirmed in the 
past
for a series of programs (including sudo) and started to be shown after
the following change in gcrypt:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff_plain;h=7627f9646701e88c827bbadd1231221d5f0c89a6

See:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1397663

and other reports here and there. I could think it relates to the use of
forward agent for gnupg in login sessions, so not directly connected to sudo,
but triggered in any case at pam level (?). Eventually this issue should/could 
be
reassigned to gnupg, but I'm not sure.


--
Francesco P. Lovergine

Bug#1019428: Please, fix sudo to cope with libgcrypt changes (apparently)

[Francesco P. Lovergine]

Package: sudo
Version: 1.9.11p3-1
Severity: normal

Sudo reports tons of messages like:

sudo: Libgcrypt warning: missing initialization - please fix the application

in syslog. Please, fix to avoid eccessive verbosity due to that. This is a
quite annoying issue already fixed in other applications here and there (e.g. 
apt).

--
Francesco P. Lovergine

Bug#560260: libcap2-bin: cap_from_text(3) manpage missing

[Michael P. Soulier]

Package: libcap2-bin
Version: 1:2.44-1
Followup-For: Bug #560260
X-Debbugs-Cc: msoul...@digitaltorque.ca

Dear Maintainer,

The setcap(8) manpage references cap_from_text(3), which does not exist
on my system. 

-- 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-15-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcap2-bin depends on:
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1

Versions of packages libcap2-bin recommends:
pn  libpam-cap  

libcap2-bin suggests no packages.

-- no debconf information

Bug#1016969: installation-reports

[Badolato, Christian P]

Package: installation-reports

Boot method: Netboot amd64
Image version: 
https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/netboot.tar.gz
Date: 8/9/2022

Machine: Hyper-V Virtual Machine
Processor: AMD 64
Memory: 8GB
Partitions: N/A

Output of lspci -knn (or lspci -nn): N/A

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:
The current Debian 11.4 netboot image does not load linux kernel file when 
attempting to run a PXE netboot install. After selecting Install, the process 
hangs at "Loading debian-installer/amd64/linux..." and never states "Ok"; after 
several minutes the machine transitions to a black screen with a message 
stating the boot process failed. The exact same machine and PXE servers were 
used with Debian 11.3 netboot without issue and swapping the linux and 
initrd.gz files with the 11.3 netboot files resolves the issue and allows the 
kernel to load, however, it then fails on mismatched modules due to the current 
debian-installer repo being updated for Debian 11.4. Need the netboot installer 
image to be updated with a loadable kernel and initrd.gz.

Bug#983138: ypserv: path to "bash" varies on usrmerge system

[Francesco P. Lovergine]

On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:

On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:

The configure script sets the BASH variable to /bin/sh when run on a
usrmerge system, resulting in the pwupdate script differing between
builds:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html

  ./usr/lib/yp/pwupdate

  #!/bin/bash
  vs.
  #!/bin/sh


In general, the Debian technical committee resolution
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
treating this class of bug as release-critical for Debian 12.

However, without knowing anything about the specifics of this package,
I'm unsure whether this specific bug is RC or not: will the pwupdate
script still work correctly with a purely POSIX shell like dash? If it
does not, then the severity of this bug should be raised to serious.

Regardless of whether this is RC or not, it would be great to have it fixed
for Debian 12. Vagrant's patch looks appropriate.

Thanks,
   smcv


The patch looks good enough to fix the pwupdate generation. In any case, the
script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks 
indifferent.

-cheers

--
Francesco P. Lovergine

Bug#1012600:

[Kevin P. Fleming]

The 2.1.5 packages have made their way into bookworm, and my system is
now happily running kernel 5.18 with ZFS.

Bug#1012600:

[Kevin P. Fleming]

I'm no expert, but since these packages are in 'contrib' I suspect
they don't have the ability to block package upgrades in 'main'.

On Sun, Jun 19, 2022 at 5:51 AM Chris Putnam  wrote:
>
> Apologies if this question is well-answered, but why isn't this package 
> holding back the kernel to 5.17? In my mind an "apt upgrade" should not have 
> pulled 5.18, especially when the net result may well be an unbootable system. 
> Surely there's some way to mark this package as broken in tandem with 5.18?
>
> I'm also quite surprised this wasn't caught in sid before it was pulled into 
> testing. Is there any form of testing for this package going on in sid?

Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5

[Felicia P]

Please close this bug.  It is no longer applicable.  Thanks!

Bug#1012768: Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5

[Felicia P]

On 6/14/22 03:59, Simon Josefsson wrote:


1) Testing contains libgsasl7 1.10.0-5 that has a hard versioned
dependency on gsasl-common 1.10.0-5 for translation files.

2) Unstable now has libgsasl18 1.11.3-2 that depends on gsasl-common
1.11.3-2.



But unstable also still has libgsasl7 1.10.0-5.

Isn't it possible to update libgsasl7 in unstable to 1.11.3-2 to match 
gsasl-common's version or else just update the gsasl-common dependency 
in libgsasl7 to 1.11.3-2 ?

Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5

[Felicia P]

Package: libgsasl7
Version: 1.10.0-5+b1
Severity: important

Dear Maintainer,

libgsasl7 depends on gsasl-common 1.10.0-5 however the current version
of gsasl-common is now 1.11.3-2



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

Kernel: Linux 5.18.0-1-amd64 (SMP w/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)

Versions of packages libgsasl7 depends on:
ii  gsasl-common  1.10.0-5
ii  libc6 2.33-7
ii  libgssapi-krb5-2  1.19.2-2+b2
ii  libidn12  1.38-4
ii  libntlm0  1.6-4

libgsasl7 recommends no packages.

libgsasl7 suggests no packages.

-- no debconf information

Bug#1012637: libsystemd-shared: libsystemd-share dependency problem prevents configuration of systemd

[Felicia P]

It occurs when the command 'lb bootstrap' from the 'live-build' package 
is run, which in turn runs '/usr/lib/live/build/bootstrap'



On 6/10/22 14:06, Michael Biebl wrote:


Control: tags -1 + moreinfo

Am 10.06.22 um 22:53 schrieb Felicia P:

Package: libsystemd-shared
Version: 251.2-4
Severity: important

Dear Maintainer,

While running the scripts to build a Debian-live system the following 
command is failing

apparently due to an issue with libsystemd-shared_251.2-4_amd64.deb:


Please provide instructions how this problem can be reproduced (i.e. 
please provide the full scripts that you are using).