Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Ansgar]

On Tue, 2023-06-06 at 11:04 +0100, Sean Whitton wrote:
> I don't think the TC has or should have any authority over dpkg
> upstream, but with dpkg being a native package, any implementation of
> our decision for the Debian archive is also implemented for dpkg
> upstream.  And it might be that the dpkg developers would be against
> the TC override solely or mostly because of this fact.  So possibly
> changing that would resolve things peacefully.

Given the Debian project owns dpkg.org, the upstream mailing list is
@lists.debian.org, official releases are published on deb.debian.org
and so on, I think the Debian project *is* the upstream for dpkg.

Ansgar

Bug#1037166: libelementary-data: versions of libelementary1 and libelementary-data don't match on ia64

[Ross Vandegrift]

Control: tags -1 wontfix

Hi Thomas,

On Tue, Jun 06, 2023 at 08:42:18PM +0200, Thomas Uhle wrote:
> So libelementary1 (version 1.25.1-1) expects to have libelementary-data from
> version 1.25.1-1 as well which is but from version 1.26.3-1 in the
> repositories.  That is why this dependency cannot be fulfilled on i64.

That's correct - EFL requires all of its components to be upgraded jointly.
And Debian likes to build arch-indep packages separately from arch-dependent.

> That is why some packages currently fail to build on Debian's ia64 build
> servers although they would compile if libelementary1 could be installed
> along with libefl-all-dev.  So I see two options: could you please either
> compile src:efl on ia64 using gcc-10 as long as the newer gcc versions are
> crashing, or could you please put back libelementary-data from version
> 1.25.1-1 into the ia64 repository.

I don't think either plan is workable.  Requiring gcc 10 is a temporary fix,
and is more drastic than I'm keen to accommodate.  And reverting
libelementary-data won't work either - afaik, I'd have to do a new source
upload which would fail due to this bug.

I think this requires fixing the bugs in gcc > 10.  You might ask about this on
debian-i...@lists.debian.org though the thread at [1] makes me doubt you'll get
a fix.

Sorry,
Ross

[1] - https://lists.debian.org/debian-ia64/2023/05/msg0.html

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index b34c183..30ce013 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -722,6 +722,43 @@ The name of the files and directories installed by 
> binary packages
>  outside the system PATH must be encoded in UTF-8 and should be
>  restricted to ASCII when it is possible to do so.
>  
> +.. _s-tmpfiles.d:
> +
> +tmpfiles.d
> +--
> +
> +Packages might need additional files or directories to implement their
> +functionality. Directories that are located under ``/var/`` or
> +``/etc/``, and files that are located under ``/var/``, must not be
> +created manually via maintainer scripts, but instead be declaratively
> +defined via the `tmpfiles.d
> +`_
> +interface.

This is an oddly specific list of directories and not at all the
directories that I would have expected to be handled by tmpfiles.d.  My
naive expectation would be that the most common path handled by tmpfiles.d
would be /run, /tmp, and /var/tmp.  I read through the other messages in
this bug but I didn't see the explanation for why those directories in
particular.

Given that neither /var (apart from /var/tmp) nor /etc are transient, I
would have expected packages to simply ship the directories under those
paths that they need in the package.  Why is that not the right approach?
Could you explain when tmpfiles.d should be used instead of shipping the
directory in the package?

> +The ``tmpfiles.d`` file format is defined by the ``systemd`` project, and is
> +guaranteed to be stable. Ideally, such definitions should be defined upstream
> +where applicable, and shipped as they are by Debian packages.
> +
> +Details about the syntax and installation paths for ``tmpfiles.d`` are 
> defined
> +by its `reference implementation's documentation,
> +`_ and will
> +not be redefined here.

I'm clearly missing something, but I was naively expecting this section to
start with something more like this:

Packages that need to create files or directories in file systems that
may be deleted on each reboot (for example, ``/run``, ``/tmp``, and
``/var/tmp``) should do so via configuration files in the
``/usr/lib/tmpfiles.d`` directory. The syntax of those files is
defined by the `systemd tmpfiles.d documentation
`__.

However, reading that documentation, it sounds like most of the cases for
other directories are handled by other systemd unit configuration
directives.  We should say that explicitly here and reproduce the list of
other directories that should be handled directly by the unit file if
that's what we want people to do.

What's the plan for creating directories in /run on non-systemd systems?
I had assumed that tmpfiles.d would be used for those directories so that
we can use the same mechanism for both systemd and non-systemd systems,
but it looks like that's not ideal for systemd systems.  Is it safe to use
*both* (e.g.) RuntimeDirectory= *and* tmpfiles.d for the same directory so
that tmpfiles.d is used for non-systemd systems?

> +``tmpfiles.d`` snippets should be detected at package build time by
> +tools such as ``debhelper``, packaged, and the appropriate snippet to
> +call them on installation, upgrade, removal, purge and other steps as
> +required, should be automatically added by helpers such as
> +``dh_installtmpfiles``.

Policy should not say things like this.  It's the job of Policy to define
what those snippets are and be specific.  It's Policy-compliant to not use
debhelper at all (we've had some discussions of changing that, but we
haven't yet).  debhelper is one implementation of Policy (and
additional non-Policy stuff), so we should be defining (at a high level)
what it needs to do and what any non-debhelper parallel implementation
should do.

Also, isn't the most obvious way to implement this to use triggers?  That
runs into the problem that Policy still doesn't have any documentation of
triggers, but (unlike debhelper) we can just require that implementations
of the tmpfiles.d mechanism pick up new files via triggers and do the
right thing, which feels appealing.

> Packages shipping ``tmpfiles.d`` snippets should depend on the
> +appropriate virtual packages in the following order:
> +``default-systemd-tmpfiles | systemd-tmpfiles``.

I read the discussion of this and agree this is the best approach.

> +Init systems are required to integrate with ``tmpfiles.d`` and run the
> +service that applies them on boot, and regularly for cleanup
> +purposes. The documentation for the reference implementation,
> +`systemd-tmpfiles,
> +`_
> +explains how to call the program so that the appropriate ``tmpfiles.d``
> +snippets are applied at the appropriate 

Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)

[Maxim Cournoyer]

Hi,

Olly Betts  writes:

> On Tue, Jun 06, 2023 at 02:12:50PM -0400, Maxim Cournoyer wrote:
>> I researched the problem and found that the feature I wanted was implemented
>> using XTest, which is detected at wxWidgets' build time [1].  Looking at the 
>> Debian
>> package dependencies, I found it did *not* depend on the libxtst6 package.
>>
>> [1]  https://github.com/wxWidgets/wxWidgets/issues/17530
>
> Have you actually tested a wx build with this enabled?

Yes, it's enabled in Guix, and my application works there, on the same
target (on top of Debian), e.g. in the environment:

--8<---cut here---start->8---
guix shell gtk+ python python-wxpython wxwidgets
--8<---cut here---end--->8---

If I step out of the environment and rely on the Debian-provided
(XTest-less) python3-wxgtk4.0/libwxgtk3.0-gtk3-0v5 packages instead, my
application no longer works (pressing the virtual keyboard doesn't cause
any text to appear in a text field, say).

> Comments in that ticket suggest that XTest doesn't work on Wayland and
> "Wayland is used by default in Debian 10 and newer" (10 is buster, the
> current stable release right now which is about to become oldstable):
>
> https://wiki.debian.org/Wayland
>
> It looks like there isn't a Wayland-specific implementation in the
> source and src/unix/uiactionx11.cpp uses X11-specific functions so
> building with --with-xtest may not really solve your problem.
>
> Forcing use of X11 for the app may help, e.g.:
>
>   GDK_BACKEND=x11 ./myapp

My application runs strictly in a X11 environment on top of Raspberry Pi
lite (which is based on Debian Bullseye).  That lite image doesn't come
with much and leaves the user choosing the components, similar to an
Arch Linux system.  I think even if for the default Wayland setup of
Debian building wxWidgets with XTest won't provide much, at least it
will be useful for users sticking to X11 and expecting
https://docs.wxpython.org/wx.UIActionSimulator.html?highlight=uiactionsimulator#wx.UIActionSimulator
to work with GTK+.  At any rate, the size of having XTest in the
distribution of libwxgtk3.0-gtk3-0v5 should be minimal, even if it's not
useful to everyone.  On Guix for example, the libxtst package and all
its transitive (referenced) dependencies weighs only 86 MiB:

--8<---cut here---start->8---
$ guix size libxtst
store item   totalself
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35  40.6
38.8  47.5%
/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib  75.3
34.7  42.5%
/gnu/store/qabydd2r26gcr9s26hzchip3a3h3zhg4-libxcb-1.15 78.5 
3.0   3.7%
/gnu/store/0hvkv5kvrk7ix29pfnbkyppbdxa7ki7n-libx11-1.8.181.2 
2.8   3.4%
/gnu/store/zzyywykw7kriln18rxqd82f0k5kidla7-bash-static-5.1.16   1.8 
1.8   2.2%
/gnu/store/z8kgahaarjpl0b1nzpqmzyrm4bbmnxw3-libxext-1.3.4   81.4 
0.1   0.2%
/gnu/store/xkzw5shd6bchzvhv9d6p08hsny749jdd-libxdmcp-1.1.3  75.4 
0.1   0.2%
/gnu/store/i7lls5jbad877g0fv7s87rlw0dgxp3wm-libxi-1.7.1081.5 
0.1   0.2%
/gnu/store/ck5m2chijap9c8warmx4af7ppc0wixsx-libxtst-1.2.3   81.6 
0.1   0.1%
/gnu/store/yilf64y14qciml3kkj3506i3n2gmaawb-libxau-1.0.10   75.3 
0.0   0.0%
total: 81.6 MiB
--8<---cut here---end--->8---

which is pretty small and probably composed of things already depended
on by the Debian libwxgtk3.0-gtk3-0v5 package.

[...]

>>* What was the outcome of this action?
>>
>> This bug/wishlist report.
>
> Hilarious, but more useful answers to these questions would be a
> short python script to allow us to easily check if wx.UIActionSimulator
> is working as you expect or not (e.g. currently this script produces
> no output, with working support it should output "...").

Ha!  I think the small program attached demonstrates it well, if you'd
like to try it.



uiactionsim_demo.py
Description: Binary data

>> wx.UIActionSimulator from wxPython/wxWidgets should produce key inputs
>> instead of nothing.  It should work like it does on Guix System.
>
> I notice that configure --help describes this feature as "experimental":
>
>   --enable-uiactionsimuse wxUIActionSimulator (experimental)
>
> That might be an outdated status though.

It's been marked experimental for the last 14 years... :-).

Thanks for your attention, and cheers!

-- 
Maxim

Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)

[Richard Laager]

The answer is so obvious as soon as someone said it!

The default "minsane" is "3" (see "tos minclock 4 minsane 3" in 
/etc/ntpsec/ntp.conf). Try commenting out that line, or if that doesn't 
work, set both to "1".


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)

[Richard Laager]

Since you've moved to chrony, this is probably moot for you. But in case 
it affects anyone else, I forwarded this upstream:

https://gitlab.com/NTPsec/ntpsec/-/issues/790

Can you confirm you were running the "ntp" package on bullseye, not 
"ntpsec"?


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Luca Boccassi  writes:

> There is a native alternative: aliases. We already do that today in the
> archive for the well-known 'dbus' unit. The dbus package ships the
> reference implementation, and dbus-broker which is an alternative
> implementation ships its own unit, which also lists 'dbus.service' as an
> alias. I have listed this in addition to your suggested paragraph.

Thanks!  This looks good to me.  I've reviewed all the bug traffic and
feel like this addresses the concerns, but not exactly in the way that
Sean, Bill, and Sam preferred.  I'd therefore like to see if this works
for them or if they still feel like it's too strong before I second it.
But if I were the only one deciding, I'd second this wording.  (Probably
not that surprising since you took all of my wording suggestions.)

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

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Nicholas D Steeves]

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

Dear Release Team,

[ Reason ]
https://security-tracker.debian.org/tracker/CVE-2023-28617
Bug #1033341

latex in ob-latex.el in Org Mode (≤9.6.1) allows attackers to execute
arbitrary commands via a file name or directory name that contains
shell metacharacters.

At this time, org-mode 9.1.14+dfsg-3 in buster continues to be
affected.  Bullseye's copy of Emacs also has a bundled version that is
effected, and I'm willing to patch that copy too.  Elpa-org-mode is a
modular add-on that upgrades and shadows that copy, by the way, so
the CVE should be fixed here first.

[ Impact ]
Security risk that is worth the effort to fix.  Emacs has no
sandboxing...  Carnil asked me to "consider proposing a fix via the
upcoming bullseye point release" (#1033341), so here I am!

[ Tests ]
For the version of src:org-mode, in bullseye, manual testing; however,
the same fix has been tested in the bundled copy of Org-mode that
is part of Emacs in bookworm.  This fix has seen two months of testing.

[ Risks ]
It's a trivial and fairly obvious fix that was discussed upstream here:
https://list.orgmode.org/tencent_04cf842704737012ccbcd63cd654dd41c...@qq.com/T/#m6ef8e7d34b25fe17b4cbb655b161edce18c6655e?cve=title

[ 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 ]
A cherry picked patch that has been tested in bookworm for two months,
an update to the series file, and a changelog entry.  The patch
replaces calls to the external "mv" command with Emacs internal
function "rename-file", which has been in active use since the '80s.


Thank you for all the work that you are doing for bookworm!
Regards,
Nicholas
diff -Nru org-mode-9.4.0+dfsg/debian/changelog 
org-mode-9.4.0+dfsg/debian/changelog
--- org-mode-9.4.0+dfsg/debian/changelog2020-09-24 10:07:33.0 
-0400
+++ org-mode-9.4.0+dfsg/debian/changelog2023-06-04 13:26:52.0 
-0400
@@ -1,3 +1,12 @@
+org-mode (9.4.0+dfsg-1+deb11u1) bullseye-security; urgency=medium
+
+  * Fix Org Mode command injection vulnerability CVE-2023-28617 by backporting
+0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch like src:emacs
+did (Closes: #1033341).  Thanks to Rob Browning's work in that package,
+fixing org-mode was trivially easy!
+
+ -- Nicholas D Steeves   Sun, 04 Jun 2023 13:26:52 -0400
+
 org-mode (9.4.0+dfsg-1) unstable; urgency=medium
 
   * New upstream version 9.4.0+dfsg
diff -Nru 
org-mode-9.4.0+dfsg/debian/patches/0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch
 
org-mode-9.4.0+dfsg/debian/patches/0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch
--- 
org-mode-9.4.0+dfsg/debian/patches/0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch
1969-12-31 19:00:00.0 -0500
+++ 
org-mode-9.4.0+dfsg/debian/patches/0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch
2023-06-04 03:17:12.0 -0400
@@ -0,0 +1,51 @@
+From 320ab831aad7b66605e3778abe51a29cc377fb46 Mon Sep 17 00:00:00 2001
+From: Xi Lu 
+Date: Sat, 11 Mar 2023 18:53:37 +0800
+Subject: Fix command injection vulnerability CVE-2023-28617
+
+https://security-tracker.debian.org/tracker/CVE-2023-28617
+
+Trivially backport the following upstream patch like emacs-1:28.2+1-15 did:
+
+  * lisp/ob-latex.el: Fix command injection vulnerability
+
+  (org-babel-execute:latex):
+  Replaced the `(shell-command "mv BAR NEWBAR")' with `rename-file'.
+
+  TINYCHANGE
+
+The second patch of the series does not appear to needed by Org-mode 9.4.0.
+
+Origin: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a8006ea580ed74f27f974d60b598143b04ad1741
+Bug-Debian: https://bugs.debian.org/1033341
+---
+ lisp/ob-latex.el | 13 +
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
+index 4b343dd..704ae4e 100644
+--- a/lisp/ob-latex.el
 b/lisp/ob-latex.el
+@@ -152,17 +152,14 @@ This function is called by 
`org-babel-execute-src-block'."
+   (if (string-suffix-p ".svg" out-file)
+   (progn
+ (shell-command "pwd")
+-(shell-command (format "mv %s %s"
+-   (concat (file-name-sans-extension 
tex-file) "-1.svg")
+-   out-file)))
++  (rename-file (concat (file-name-sans-extension tex-file) "-1.svg")
++   out-file t))
+ (error "SVG file produced but HTML file requested")))
+  ((file-exists-p (concat (file-name-sans-extension tex-file) ".html"))
+   (if (string-suffix-p ".html" out-file)
+-  (shell-command "mv %s %s"
+- (concat (file-name-sans-extension tex-file)
+-   

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Sean Whitton  writes:

> I think what's a bit peculiar here is using "must" for a case where
> there might be package-specific exceptions.  In other cases, Policy uses
> "should" for these cases.  Typically "must" rules are simple and
> completely determinate.

I prefer that too, but in this case, it feels like must is appropriate for
at least systemd configuration files.  And also, just intuitively, I feel
like must is correct when people are using diversions rather than a native
mechanism.  Diversions add weird edge cases and we really shouldn't be
using them lightly.

The wording I proposed and that Luca has now adopted therefore uses must
with a caveat.  Does that sound okay to you?

I think must is too strong for alternatives, where I think there are more
likely to be package-specific exceptions.  But I'd like to take a harder
line on diversions, and I do think that matches how we use diversions
between two Debian packages (work around some weird situation where we
have no better option).

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Bill Allombert  writes:
> On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:

>> If you prefer, I can reword the general rule to be stricter, ie:
>> "packages must not use diversions where native mechanisms are
>> available" or so. Would this be better?

> "native mechanisms" seems to vague.

I suggested "must not be used when a suitable override mechanism that
accomplishes the same goal is already available."  Does that sound okay?
It's a bit weaker and opens the door to arguments about whether the native
override mechanism accomplishes the same goal, but I think that's a
feature here rather than a bug.

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

Bug#1037174: RFS: damo/1.8.4-1 [ITP] -- Data Access Monitoring Operator

[Michel Alexandre Salim]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : damo
   Version  : 1.8.4-1
   Upstream contact : SeongJae Park 
 * URL  : https://damonitor.github.io/
 * License  : GPL-2
 * Vcs  : https://salsa.debian.org/python-team/packages/damo
   Section  : devel

The source builds the following binary packages:

  damo - Data Access Monitoring Operator

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/d/damo/damo_1.8.4-1.dsc

Changes for the initial release:

 damo (1.8.4-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1037157)

Regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature

Bug#1037173: /usr/bin/uscan: uscan: add V prefix in @ANY_VERSION@

[Carlos Henrique Lima Melara]

Package: devscripts
Version: 2.23.4
Severity: wishlist
File: /usr/bin/uscan
X-Debbugs-Cc: charlesmel...@outlook.com

Dear Maintainers,

I'm the maintainer of kristall, a package that use tags with capital V.
For example V0.4, V0.3, etc. Because of this, I have to add a V? before
@ANY_VERSION@ in the watch file. I think it might be the case for other
maintainers so I'm sending this suggestion. Could you add the V prefix
to @ANY_VERSION@?

I'll attach a draft patch to give you an idea (but surely you do
understand a lot more perl than I, so really take it as a draft).

Cheers,
Charles

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

-- 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-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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 devscripts depends on:
ii  dpkg-dev  1.21.22
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libc6 2.36-9
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.68-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.2-1+b1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.1
ii  curl7.88.1-10
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput-ng [dput]  1.35
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5
ii  libdpkg-perl1.21.22
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-3
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-2
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-28
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
ii  autopkgtest  5.28
pn  bls-standalone   
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
ii  libyaml-syck-perl1.34-2+b1
ii  mailutils [mailx]1:3.15-4
pn  mmdebstrap   
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:9.2p1-2
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3+git20230121-2

-- no debconf information
diff --git a/lib/Devscripts/Uscan/WatchFile.pm 
b/lib/Devscripts/Uscan/WatchFile.pm
index 06ab61df..71be4491 100644
--- a/lib/Devscripts/Uscan/WatchFile.pm
+++ b/lib/Devscripts/Uscan/WatchFile.pm
@@ -104,7 +104,7 @@ use List::Util qw/first/;
 use Moo;
 
 use constant {
-ANY_VERSION => '(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))',
+ANY_VERSION => '(?:[-_]?[Vv]?(\d[\-+\.:\~\da-zA-Z]*))',
 ARCHIVE_EXT =>
   '(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))',
 DEB_EXT => '(?:[\+~](debian|dfsg|ds|deb)(\.)?(\d+)?$)',

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 06 Jun 2023 16:46:04 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> > I'm not suggesting that you stop using emails to send your changes
- I'm
> > simply asking to reconsider making policy work like the vast
majority of
> > other parts of Debian, and _also_ accepts merge requests on Salsa,
in
> > _addition_ to emails.
> 
> I have considered it several times, and I considered it again as part
of
> this recent conversation before writing my reply.

Sure, it's your package so it's up to you.

-- 
Kind regards,
Luca Boccassi


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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Luca Boccassi  writes:

> It depends on your pain threshold.

Salsa is worse for me for working on Policy in pretty much every respect
than email with patches.  That's not a statement about my pain threshold.
It's a fundamental disagreement with you about which tools work better for
this specific type of maintenance.

> For me it's much easier and simpler and less painful to do all of that
> on Salsa, as opposed to wade through a bunch of random emails and
> scrolling up and down through the BTS.

I understand that you don't like email.  The Policy process is optimized
for the Policy editors, rather than for the preferences of people who are
working on a specific change that they care about.  I appreciate that this
can be annoying, but it's fairly typical for open source work.  See, for
example, the Linux kernel, which likewise doesn't take merge requests, no
matter how inconvenient that may be for contributors.

> I'm sure there were some suggestions earlier in the thread, that I now
> have forgotten about, and they will be lost because there's no way I'm
> going back wading through dozens of random replies to figure out what is
> applied and what is not.

That's fine; this is part of the job of the Policy editors.

> I'm not suggesting that you stop using emails to send your changes - I'm
> simply asking to reconsider making policy work like the vast majority of
> other parts of Debian, and _also_ accepts merge requests on Salsa, in
> _addition_ to emails.

I have considered it several times, and I considered it again as part of
this recent conversation before writing my reply.

> Then the submitter can choose. I suspect you are going to get a lot more
> contributions this way,

Maximizing contribution of merge requests doesn't help the bottleneck for
Policy changes.  Policy changes are often complex and require thought and
research.  Most of the patches we get are incorrect or incomplete to start
with.  The bottleneck is time from people with a lot of in-depth Debian
knowledge to think deeply about a problem.

If the people who routinely provide detailed and incredibly useful
analyses of Policy problems say that they would rather use Salsa to do so,
that's important feedback and I would like to hear that feedback.  But the
goal here is not to maximize development speed.  It's to think hard about
a problem and get the answer correct.

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

Bug#1037172: unixodbc-common,odbcinst: missing Breaks+Replaces: odbcinst1debian1

[Andreas Beckmann]

Package: unixodbc-common,odbcinst
Version: 2.3.11-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libsqliteodbc

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'lenny' to 'squeeze' to 'wheezy' to 'jessie' to 'stretch' to 'buster' to
'bullseye' to 'bookworm'.
It installed fine in 'lenny', and upgraded to 'squeeze', 'wheezy',
'jessie', 'stretch', 'buster', and 'bullseye' successfully,
but then the upgrade to 'bookworm' failed.

In case the package was not part of an intermediate stable release,
the version from the preceding stable release was kept installed.

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

...
  Selecting previously unselected package unixodbc-common.
  Preparing to unpack .../22-unixodbc-common_2.3.11-2_all.deb ...
  Unpacking unixodbc-common (2.3.11-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-JsWDst/22-unixodbc-common_2.3.11-2_all.deb (--unpack):
   trying to overwrite '/etc/odbc.ini', which is also in package 
odbcinst1debian1 2.2.11-16
...
  Selecting previously unselected package odbcinst.
  Preparing to unpack .../25-odbcinst_2.3.11-2_amd64.deb ...
  Unpacking odbcinst (2.3.11-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-JsWDst/25-odbcinst_2.3.11-2_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/odbcinst', which is also in package 
odbcinst1debian1 2.2.11-16
...
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-JsWDst/22-unixodbc-common_2.3.11-2_all.deb
   /tmp/apt-dpkg-install-JsWDst/25-odbcinst_2.3.11-2_amd64.deb

The mentioned Breaks+Replaces may have been there in the past,
but on some upgrade paths originating in lenny the obsolete packages may
have survived without being affected by B+R so far.

(In the concrete case, libsqliteodbc/lenny had a dependency on
odbcinst1debian1, libsqliteodbc/bookworm has a dependency on odbcinst
while in all releases inbetween there was no pdenedency on an *odbc*
package at all.)


cheers,

Andreas


libsqliteodbc_0.9998-3+b1.log.gz
Description: application/gzip

Bug#1037171: aide: fresh aide package install fails to add the requried _aide user to system

[Tomasz Ciolek]

Package: aide
Version: 0.18.3-1
Severity: serious
Justification: 5.d

Dear Maintainer,

A fresh aide package install on debina buster fails to add the requried _aide 
user to system. This block the ability to run 'aideinit' script.

While this is mentioned in /usr/share/doc/aide-common/README.Debian.gz there 
are no clear instrucntions as to whar range of UID/GID to give the _aide user 
when cerating them manually.

Pleas resolve as this blocks upgarde on most of my systems as I use aide across 
all of them.


-- 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-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aide depends on:
ii  libacl1   2.3.1-3
ii  libaudit1 1:3.0.9-1
ii  libc6 2.36-9
ii  libcap2   1:2.66-4
ii  libext2fs21.47.0-2
ii  libmhash2 0.9.9.9-9
ii  libpcre2-8-0  10.42-1
ii  libselinux1   3.4-1+b6
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages aide recommends:
ii  aide-common  0.18.3-1

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#1037170: dpkg: warning: while removing fonts-lyx, directory '/usr/share/fonts/truetype/lyx' not empty so not removeds

[Dan Jacobson]

Package: fonts-lyx
Version: 2.3.7-1

The .uuid file remained.

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Wed, 7 Jun 2023 00:02:06 +0200 Bill Allombert 
wrote:
> On Tue, Jun 06, 2023 at 03:16:02PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Jun 2023 15:23:35 +0200 Bill Allombert
,
> > Luca Boccassi  wrote:
> > > On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > > > > The diversion system is made precisely to work around other
> > packages
> > > > behavior,
> > > > > this is a feature not a bug. That it should only be used as
last
> > > > resort, I
> > > > > think everyone agree. But when it is, it should not be a RC
bug.
> > > > 
> > > > This is a technical matter, I'm not sure what 'consensus' means
in
> > this
> > > > context? Things _will not work_ as expected by shoe-horning
dpkg's
> > > > overrides onto systemd mechanisms, they _will_ break in weird
and
> > > > unexpected ways, and we as maintainers _will not support it_ -
> > whether
> > > > somebody else agrees or disagrees with this won't change any of
it.
> > > 
> > > Consensus is the way the Debian Policy update process works.
> > > But you do not need changes in Policy to report bugs about
package
> > that breaks
> > > others, there is the "grave" severity already.
> > 
> > That does not help, given currently policy allows it, without
changes
> > they could just say "policy allows me, so go fix it yourself". What
> > then?
> 
> That simply not how Policy works.
> Policy is for promoting interoperability and documenting current
practices.
> "Policy is not a stick to beat people with" as Manoj used to say.
> 
> If you are suggesting a policy change so that you can report RC bugs
on other
> packages, you are on the wrong track.

No, I am suggesting a policy change so that we do not end up in a messy
and unmaintainable situation, which I thought was one of the goals. The
current practice is that packages are not using diversions and
alternatives to take over systemd files. As I have already specified a
number of times, the number of packages that need changes following
this change is zero - because I have _already_ done the required work
to make it so. After having done this work for Bookwrom, I am
translating this current practice into policy, to ensure we don't
regress.

-- 
Kind regards,
Luca Boccassi


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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Wed, 7 Jun 2023 00:01:42 +0200 Bill Allombert 
wrote:
> On Tue, Jun 06, 2023 at 09:36:31PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Jun 2023 20:51:46 +0200 Dominik George
> >  wrote:
> > > > Ok, how about: "the whole project, minus
> > naturesha...@debian.org who
> > > > appears to be unfamiliar with the concept of hyperboles, is
moving
> > > > toward git and Salsa". Better?
> > > 
> > > No.
> > > 
> > > Your "hyperbole" very much read as "Come on, minority who cares
about
> > > the mail workflow, you're weird anachronists, get onto the Salsa
> > train already!"
> > > 
> > > So that's what I am criticizing.
> > 
> > Sure, and you just coincidentally happened to leave out the part
that
> > says the exact opposite:
> 
> This is beside the point. Your problematic statement was
> "The whole project is moving toward git and Salsa ".
> This is not conducive of productive interaction.

It was not problematic at all, unless you are deliberately trying to
see problems where there are none. It was an hyperbole: a huge number
of packages and teams are using effectively Salsa workflows for
collaboration today. Are you denying this?

-- 
Kind regards,
Luca Boccassi


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

Bug#1037169: linux-image-6.1.0-9-amd64: reboots when suspending

[Nicolas Évrard]

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

Dear Maintainer,

When the computer goes to suspend using eg 'systemctl suspend' it sometimes
fails to suspend and reboots instead. What can also happen is that the computer
won't come back from suspend and won't react to pings either, I'll have to
force a shutdown. And sometimes everything will work as expected.

I noticed this since a few months now, updating the kernel never changed the
behaviour.

Regards,

-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/mirabelle--vg-root ro quiet 
apparmor=0

** Not tainted

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

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: UX430UAR
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: UX430UAR.305
board_vendor: ASUSTeK COMPUTER INC.
board_name: UX430UAR
board_version: 1.0   

** Loaded modules:
omfs
jfs
xfs
reiserfs
hfs
nls_utf8
hfsplus
isofs
udf
crc_itu_t
cdrom
uinput
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
xt_conntrack
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack_netlink
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
xfrm_user
xfrm_algo
xt_addrtype
nft_compat
nf_tables
libcrc32c
nfnetlink
br_netfilter
bridge
stp
llc
ctr
bnep
overlay
snd_hda_codec_hdmi
ccm
algif_aead
des_generic
libdes
zstd
ecb
zstd_compress
algif_skcipher
zram
zsmalloc
cmac
md4
algif_hash
af_alg
btusb
btrtl
btbcm
btintel
btmtk
bluetooth
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
jitterentropy_rng
videodev
drbg
ansi_cprng
ecdh_generic
mc
ecc
binfmt_misc
snd_sof_pci_intel_skl
snd_sof_intel_hda_common
snd_hda_codec_realtek
x86_pkg_temp_thermal
intel_powerclamp
soundwire_intel
coretemp
snd_hda_codec_generic
soundwire_generic_allocation
soundwire_cadence
snd_sof_intel_hda
nls_ascii
snd_sof_pci
kvm_intel
nls_cp437
snd_sof_xtensa_dsp
vfat
fat
snd_sof
snd_sof_utils
soundwire_bus
kvm
snd_soc_skl
irqbypass
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_sst_ipc
snd_soc_sst_dsp
snd_soc_acpi_intel_match
ghash_clmulni_intel
snd_soc_acpi
sha512_ssse3
sha512_generic
snd_soc_core
snd_compress
i915
snd_hda_intel
snd_intel_dspcfg
iwlmvm
snd_intel_sdw_acpi
aesni_intel
snd_hda_codec
crypto_simd
cryptd
snd_hda_core
joydev
rapl
mei_hdcp
drm_buddy
intel_rapl_msr
mac80211
drm_display_helper
snd_hwdep
asus_nb_wmi
cec
snd_pcm
intel_cstate
asus_wmi
rc_core
processor_thermal_device_pci_legacy
bonding
intel_uncore
platform_profile
iTCO_wdt
processor_thermal_device
snd_timer
libarc4
sparse_keymap
processor_thermal_rfim
intel_pmc_bxt
ttm
ledtrig_audio
pcspkr
processor_thermal_mbox
tls
acpi_als
iTCO_vendor_support
snd
industrialio_triggered_buffer
processor_thermal_rapl
mei_me
intel_rapl_common
iwlwifi
wmi_bmof
drm_kms_helper
watchdog
kfifo_buf
int3403_thermal
soundcore
int3400_thermal
intel_xhci_usb_role_switch
ac
int340x_thermal_zone
mei
roles
i2c_algo_bit
intel_pch_thermal
intel_soc_dts_iosf
industrialio
acpi_thermal_rel
cfg80211
intel_pmc_core
button
acpi_pad
asus_wireless
hid_multitouch
evdev
serio_raw
sg
rfkill
pkcs8_key_parser
parport_pc
ppdev
lp
parport
drm
fuse
loop
efi_pstore
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
usbhid
ax88179_178a
uas
usbnet
mii
usb_storage
dm_mod
sd_mod
t10_pi
crc64_rocksoft
crc64
crc_t10dif
crct10dif_generic
ahci
hid_generic
libahci
xhci_pci
libata
xhci_hcd
crct10dif_pclmul
crct10dif_common
i2c_hid_acpi
crc32_pclmul
usbcore
crc32c_intel
scsi_mod
i2c_hid
i2c_i801
i2c_smbus
intel_lpss_pci
hid
intel_lpss
idma64
usb_common
scsi_common
video
battery
wmi

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enx00249b6ca1b2:  mtu 1500 qdisc 
fq_codel master bond0 state UP group default qlen 1000
link/ether 1a:c2:1a:f9:2b:7f brd ff:ff:ff:ff:ff:ff
3: bond0:  mtu 1500 qdisc noqueue state 
UP group default qlen 1000
link/ether 1a:c2:1a:f9:2b:7f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.29/24 metric 1024 brd 192.168.1.255 scope global dynamic 
bond0
   valid_lft 82760sec preferred_lft 82760sec
inet6 2a02:578:852a:c00:18c2:1aff:fef9:2b7f/64 scope global dynamic 
mngtmpaddr noprefixroute 
   valid_lft 7020sec preferred_lft 3420sec
inet6 fe80::18c2:1aff:fef9:2b7f/64 scope link 
   valid_lft forever preferred_lft forever
5: wlan0:  mtu 1500 qdisc noqueue master 
bond0 state UP group default qlen 1000
link/ether 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 03:16:02PM +0100, Luca Boccassi wrote:
> On Tue, 6 Jun 2023 15:23:35 +0200 Bill Allombert ,
> Luca Boccassi  wrote:
> > On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > > > The diversion system is made precisely to work around other
> packages
> > > behavior,
> > > > this is a feature not a bug. That it should only be used as last
> > > resort, I
> > > > think everyone agree. But when it is, it should not be a RC bug.
> > > 
> > > This is a technical matter, I'm not sure what 'consensus' means in
> this
> > > context? Things _will not work_ as expected by shoe-horning dpkg's
> > > overrides onto systemd mechanisms, they _will_ break in weird and
> > > unexpected ways, and we as maintainers _will not support it_ -
> whether
> > > somebody else agrees or disagrees with this won't change any of it.
> > 
> > Consensus is the way the Debian Policy update process works.
> > But you do not need changes in Policy to report bugs about package
> that breaks
> > others, there is the "grave" severity already.
> 
> That does not help, given currently policy allows it, without changes
> they could just say "policy allows me, so go fix it yourself". What
> then?

That simply not how Policy works.
Policy is for promoting interoperability and documenting current practices.
"Policy is not a stick to beat people with" as Manoj used to say.

If you are suggesting a policy change so that you can report RC bugs on other
packages, you are on the wrong track.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 09:36:31PM +0100, Luca Boccassi wrote:
> On Tue, 6 Jun 2023 20:51:46 +0200 Dominik George
>  wrote:
> > > Ok, how about: "the whole project, minus
> naturesha...@debian.org who
> > > appears to be unfamiliar with the concept of hyperboles, is moving
> > > toward git and Salsa". Better?
> > 
> > No.
> > 
> > Your "hyperbole" very much read as "Come on, minority who cares about
> > the mail workflow, you're weird anachronists, get onto the Salsa
> train already!"
> > 
> > So that's what I am criticizing.
> 
> Sure, and you just coincidentally happened to leave out the part that
> says the exact opposite:

This is beside the point. Your problematic statement was
"The whole project is moving toward git and Salsa ".
This is not conducive of productive interaction.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Tue, 06 Jun 2023 13:07:37 +0100 Luca Boccassi 
wrote:
> Sounds like a good plan to me.

Updated as suggested.

-- 
Kind regards,
Luca Boccassi
From 20a655663c17914699e72e48a74daca03fd42a22 Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Tue, 9 May 2023 01:38:13 +0100
Subject: [PATCH] Define tmpfiles.d interface and usage

---
 policy/ch-files.rst | 37 +
 policy/ch-maintainerscripts.rst |  6 ++
 2 files changed, 43 insertions(+)

diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index b34c183..30ce013 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -722,6 +722,43 @@ The name of the files and directories installed by binary packages
 outside the system PATH must be encoded in UTF-8 and should be
 restricted to ASCII when it is possible to do so.
 
+.. _s-tmpfiles.d:
+
+tmpfiles.d
+--
+
+Packages might need additional files or directories to implement their
+functionality. Directories that are located under ``/var/`` or ``/etc/``, and
+files that are located under ``/var/``, must not be created manually via
+maintainer scripts, but instead be declaratively defined via the `tmpfiles.d
+`_ interface.
+The ``tmpfiles.d`` file format is defined by the ``systemd`` project, and is
+guaranteed to be stable. Ideally, such definitions should be defined upstream
+where applicable, and shipped as they are by Debian packages.
+
+Details about the syntax and installation paths for ``tmpfiles.d`` are defined
+by its `reference implementation's documentation,
+`_ and will
+not be redefined here.
+
+``tmpfiles.d`` snippets should be usable on systems that do not boot (such as a
+very minimal chroot image), and also on systems booting with init systems other
+than ``systemd``.
+
+``tmpfiles.d`` snippets should be detected at package build time by tools such
+as ``debhelper``, packaged, and the appropriate snippet to call them on
+installation, upgrade, removal, purge and other steps as required, should be
+automatically added by helpers such as ``dh_installtmpfiles``. Packages shipping
+``tmpfiles.d`` snippets should depend on the appropriate virtual packages in the
+following order: ``default-systemd-tmpfiles | systemd-tmpfiles``.
+
+Init systems are required to integrate with ``tmpfiles.d`` and run the service
+that applies them on boot, and regularly for cleanup purposes. The documentation
+for the reference implementation, `systemd-tmpfiles,
+`_
+explains how to call the program so that the appropriate ``tmpfiles.d`` snippets
+are applied at the appropriate time.
+
 .. [#]
If you are using GCC, ``-fPIC`` produces code with relocatable
position independent code, which is required for most architectures
diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
index 724074c..320949d 100644
--- a/policy/ch-maintainerscripts.rst
+++ b/policy/ch-maintainerscripts.rst
@@ -50,6 +50,12 @@ absolute pathname. Maintainer scripts should also not reset the
 appending package-specific directories. These considerations really
 apply to all shell scripts.
 
+Maintainer scripts should not be used to create or remove auxiliary files and/or
+directories that packages may need, such as those in ``/var/`` or ``/etc/``.
+Instead, :ref:`s-tmpfiles.d` snippets should be shipped, being ideally provided by
+the upstream sources, if any. For more details about the ``tmpfiles.d``
+interface, see :ref:`s-tmpfiles.d`.
+
 .. _s-idempotency:
 
 Maintainer scripts idempotency
-- 
2.39.2



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

Bug#1013298: O: flycheck -- modern on-the-fly syntax checking for Emacs

[Antoine Beaupré]

On 2023-06-06 23:05:04, Denis Danilov wrote:
> Hi Antoine,
>
> On Tue, Jun 06, 2023 at 12:00:02PM -0400, Antoine Beaupré wrote:
>> I intend to adopt the package. It seems like the next step for the
>> package is to update it to the latest release (32) from May 2022.
>> 
>> Have you tried doing that upgrade or is there any peculiar reason why
>> we're at a git snapshot still?
>
> From a technical perspective there is no reason to stay on the git snapshot
> version. Salsa repo https://salsa.debian.org/emacsen-team/flycheck is already
> updated to latest flycheck release 32.  But I did not manage to find a sponsor
> to upload it. That's one part of the problem. Another part of it: people
> ignore the salsa repo and prefer to stick to git snapshot (for whatever
> reason), see recent versions 32~git.20200527.9c435db3-3 and
> 32~git.20200527.9c435db3-4. Hopefully you will have more luck to sort the
> things out.

Oh. Weird. Looks like the team didn't do its job then, that's
unfortunate.

Thanks for the heads up, I'll make sure to include your good work!

As an aside, do you have any thoughts on flymake in recent Emacs
releases? Is flycheck still relevant?

I've asked upstream to update their comparison to get a better idea:

https://github.com/flycheck/flycheck/issues/2023

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry

Bug#1013298: O: flycheck -- modern on-the-fly syntax checking for Emacs

[Denis Danilov]

Hi Antoine,

On Tue, Jun 06, 2023 at 12:00:02PM -0400, Antoine Beaupré wrote:
> I intend to adopt the package. It seems like the next step for the
> package is to update it to the latest release (32) from May 2022.
> 
> Have you tried doing that upgrade or is there any peculiar reason why
> we're at a git snapshot still?

>From a technical perspective there is no reason to stay on the git snapshot
version. Salsa repo https://salsa.debian.org/emacsen-team/flycheck is already
updated to latest flycheck release 32.  But I did not manage to find a sponsor
to upload it. That's one part of the problem. Another part of it: people
ignore the salsa repo and prefer to stick to git snapshot (for whatever
reason), see recent versions 32~git.20200527.9c435db3-3 and
32~git.20200527.9c435db3-4. Hopefully you will have more luck to sort the
things out.

Thanks and best regards,
Denis

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 at 17:12, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > --- a/policy/ap-pkg-alternatives.rst
> > +++ b/policy/ap-pkg-alternatives.rst
> > @@ -24,3 +24,7 @@ See the :manpage:`update-alternatives(8)` man page for 
> > details.
> >  If ``update-alternatives`` does not seem appropriate you may wish to
> >  consider using diversions instead.
> >
> > +Do not attempt to use alternatives for files belonging or used by 
> > components
> > +that support native overriding mechanisms, such as ``systemd`` unit files. 
> > Read
> > +:doc:`ch-binary` for more information.
>
> "Do not attempt" in US English reads a little weirdly (I know you're
> copying an existing UK English phrasing). I instead suggest:
>
> Do not use alternatives for ``systemd`` configuration files. See
> :doc:`ch-binary` for more information.
>
> (See below for why this is systemd-specific.) This doesn't use our normal
> normative language conventions, which I think is correct since this is a
> non-normative appendix.
>
> > diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst
> > index fe360d1..09367d7 100644
> > --- a/policy/ap-pkg-diversions.rst
> > +++ b/policy/ap-pkg-diversions.rst
> > @@ -81,3 +81,7 @@ when the file does not exist.
> >  Do not attempt to divert a conffile, as ``dpkg`` does not handle it
> >  well.
> >
> > +Do not attempt to divert files belonging or used by components that support
> > +native overriding mechanisms, such as ``systemd`` unit files. Read
> > +:doc:`ch-binary` for more information.
>
> Similarly here:
>
> Do not use diversions for files that have their own native override
> mechanisms, such as ``systemd`` unit files. See :doc:`ch-binary` for
> more information.

Sounds all good to me, applied, I simply had copied the previous
paragraph's style.

> > diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
> > index e517f26..e36d028 100644
> > --- a/policy/ch-binary.rst
> > +++ b/policy/ch-binary.rst
> > @@ -371,6 +371,37 @@ against earlier versions of something that previously 
> > did not use
> >  ``update-alternatives``; this is an exception to the usual rule that
> >  versioned conflicts should be avoided.)
> >
> > +Diversions and alternatives should be used primarily as a tool for local
> > +administrators and local packages to override the behaviour of Debian. Its 
> > use
> > +between Debian packages should be rare, should involve coordination 
> > between the
> > +packages and their maintainers, and must only be used to solve problems 
> > that
> > +cannot be handled through other facilities or native mechanisms.
>
> I think this not correct for alternatives. They are intended for use
> between Debian packages, so we need to distinguish between alternatives
> and diversions here. This might be clearer if we created a subsection for
> alternatives and diversions and added a bit of additional context from the
> appendices (and ideally removed the appendices). That's not something to
> do on this bug, just noting mostly for Sean and future work.

While I disagree on that, because alternatives make a mess of
image-based systems and are a pain to handle (requires moving parts
via maint scripts to be effective), it is also a bit off topic so I
have applied your suggestion as-is.

> I think there's also a bit more justification than we need. The
> justification is useful for discussing the Policy bug, but once we've
> decided on an approach, I think we can just point at the correct
> alternative mechanism.
>
> How about something like this:
>
> Diversions are primarily intended as a tool for local administrators
> or local packages to override the behavior of Debian. While there are
> some circumstances where one Debian package may need to divert a file
> of another Debian package, those circumstances are rare and diversions
> should only be used as a last resort when no other suitable mechanism
> exists. Diversion of a file in one Debian package by another Debian
> package should be coordinated between the maintainers of those
> packages.
>
> Diversions must not be used when a suitable override mechanism that
> accomplishes the same goal is already available.
>
> One specific case of that rule is that configuration files used by
> ``systemd`` components, such as `units,
> 
> `_
> `udev rules,
> 
> `_
> `tmpfiles.d,
> 
> `_
> `modules-load.d,
> 
> `_,
> `sysusers
> 
> `_
> and other such files, 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 06 Jun 2023 09:19:30 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> 
> > Snarks aside, allowing merge requests to be open on Salsa in
_addition_
> > to attachments to the BTS, as the vast majority of other packages
> > already do, doesn't take away anything from you, but would add
quite a
> > lot for the rest of us, who find ourselves very limited and very
much
> > barrier-ized by clunky, old and painful email-based processes.
> 
> Merge requests are useful when the goal is to be able to merge the
merge
> request as-is at the end of some code review process. My guess is
that
> this happens about 20% of the time with Policy. The other 80% of the
time
> I tweak wording or phrasing or formatting when applying the change,
and
> also add an upgrading-checklist entry and other bookkeeping that I
don't
> want to have to explain to everyone proposing new wording.
> 
> Policy is not a program and we're not taking source code changes. The
goal
> of the discussion is to converge on the semantics of what we are
going to
> say, which often requires multi-paragraph discussions where the
normal
> tools of email such as quoting are more useful. I find trying to have
an
> email-style discussion in Salsa to be annoying and tedious. It also
> fragments the record, whereas having it in the bug means I can, at
any
> time, load the entire bug into Gnus and re-read the discussion of how
we
> arrived at the decision in the same tool that I use for reading all
other
> Debian discussions.

It depends on your pain threshold. For me it's much easier and simpler
and less painful to do all of that on Salsa, as opposed to wade through
a bunch of random emails and scrolling up and down through the BTS. I'm
sure there were some suggestions earlier in the thread, that I now have
forgotten about, and they will be lost because there's no way I'm going
back wading through dozens of random replies to figure out what is
applied and what is not. On Salsa, this would be an 'unresolved' review
comment that I can click 'solved' once handled.

I'm not suggesting that you stop using emails to send your changes -
I'm simply asking to reconsider making policy work like the vast
majority of other parts of Debian, and _also_ accepts merge requests on
Salsa, in _addition_ to emails. Then the submitter can choose. I
suspect you are going to get a lot more contributions this way, that is
certainly the experience from other teams that have enabled Salsa from
what I can hear (eg: kernel team).

-- 
Kind regards,
Luca Boccassi


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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 20:51:46 +0200 Dominik George
 wrote:
> > Ok, how about: "the whole project, minus
naturesha...@debian.org who
> > appears to be unfamiliar with the concept of hyperboles, is moving
> > toward git and Salsa". Better?
> 
> No.
> 
> Your "hyperbole" very much read as "Come on, minority who cares about
> the mail workflow, you're weird anachronists, get onto the Salsa
train already!"
> 
> So that's what I am criticizing.

Sure, and you just coincidentally happened to leave out the part that
says the exact opposite:

> Snarks aside, allowing merge requests to be open on Salsa in
> _addition_ to attachments to the BTS, as the vast majority of other
> packages already do, doesn't take away anything from you, but would
> add quite a lot for the rest of us, who find ourselves very limited
> and very much barrier-ized by clunky, old and painful email-based
> processes.

Which means you are actually doing what you accuse me of - you are not
content with being able to keep using mail workflows for yourself, you
want to actively stop everybody from being able to use Salsa too.

-- 
Kind regards,
Luca Boccassi


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

Bug#1034612: freetype: CVE-2023-2004

[Salvatore Bonaccorso]

Control: retitle -1  src/truetype/ttgxvar.c (tt_hvadvance_adjust): Integer 
overflow.  
Control: tags -1 - security

On Wed, Apr 19, 2023 at 09:20:48PM +0200, Salvatore Bonaccorso wrote:
> Source: freetype
> Version: 2.12.1+dfsg-4
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for freetype.
> 
> CVE-2023-2004[0]:
> | An integer overflow vulnerability was discovered in Freetype in
> | tt_hvadvance_adjust() function in src/truetype/ttgxvar.c.

The CVE got rejected by the assigning CNA as further investigation
showed that there is no security issue.

Regards,
Salvatore

Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)

[Olly Betts]

On Tue, Jun 06, 2023 at 02:12:50PM -0400, Maxim Cournoyer wrote:
> I researched the problem and found that the feature I wanted was implemented 
> using XTest, which is detected at wxWidgets' build time [1].  Looking at the 
> Debian
> package dependencies, I found it did *not* depend on the libxtst6 package.
> 
> [1]  https://github.com/wxWidgets/wxWidgets/issues/17530

Have you actually tested a wx build with this enabled?

Comments in that ticket suggest that XTest doesn't work on Wayland and
"Wayland is used by default in Debian 10 and newer" (10 is buster, the
current stable release right now which is about to become oldstable):

https://wiki.debian.org/Wayland

It looks like there isn't a Wayland-specific implementation in the
source and src/unix/uiactionx11.cpp uses X11-specific functions so
building with --with-xtest may not really solve your problem.

Forcing use of X11 for the app may help, e.g.:

  GDK_BACKEND=x11 ./myapp

(The debian wx packages currently effectively do the above automatically
if wxGLCanvas is used as the current support for wxGLCanvas on Wayland
has some problems - hopefully we can eliminate that soon, but it seemed
the least risky fix for the bullseye release.)

>* What was the outcome of this action?
> 
> This bug/wishlist report.

Hilarious, but more useful answers to these questions would be a
short python script to allow us to easily check if wx.UIActionSimulator
is working as you expect or not (e.g. currently this script produces
no output, with working support it should output "...").

> wx.UIActionSimulator from wxPython/wxWidgets should produce key inputs
> instead of nothing.  It should work like it does on Guix System.

I notice that configure --help describes this feature as "experimental":

  --enable-uiactionsimuse wxUIActionSimulator (experimental)

That might be an outdated status though.

Cheers,
Olly

Bug#1036161: postfix: obsolete comment in /etc/postfix/main.cf.proto

[Scott Kitterman]

On Tue, 16 May 2023 11:10:11 +0200 Vincent Lefevre  wrote:
> Package: postfix
> Version: 3.7.5-2
> Severity: minor
> 
> In /etc/postfix/main.cf.proto, I can see
> 
> # On Linux, this works correctly only with interfaces specified
> # with the "ifconfig" command.
> 
> while the "ip" command tends to be preferred nowadays and "ifconfig"
> isn't necessarily available. At least "ip link" should be given.

This was fixed upstream in postfix 3.8 and will be addressed when it is 
uploaded 
to Debian.

Scott K


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

Bug#1037168: libpython3.11-stdlib: missing dependency on tzdata

[Thomas Uhle]

Package: libpython3.11-stdlib
Version: 3.11.0-1
Severity: important

Dear maintainer,

your binary package libpython3.11-stdlib includes the zoneinfo module 
which depends on tzdata which, for instance, can be seen by:


  python3 -c 'from zoneinfo import TZPATH; print(TZPATH)'

Although tzdata might already be installed on the system by packages like 
python3-tz or python3-dateutil, it would be good if libpython3.11-stdlib 
itself would also depend on tzdata.


I know that bookworm is frozen, but could you please add the missing 
dependency to your next version in sid and maybe schedule an update for 
bookworm with Debian's next stable point release.


Thank you in advance!

Best regards,

Thomas Uhle

Bug#712781: src:scilab: please use SLICOT Debian package instead of embedded copy

[Pierre Gruet]

Control: forwarded -1 https://gitlab.com/scilab/scilab/-/issues/13151
Control: tags -1 - moreinfo

Hi Sébastien,

Le 28/05/2023 à 17:46, Sébastien Villemot a écrit :

Hi Pierre,


[...]


The Debian package src:slicot contains a pre-release of version 5.0 of
Slicot, which was the last version distributed by upstream under the
GPL (later versions are proprietary).

However at some point upstream changed their mind and decided to stop
distributing the 5.0 release under the GPL, so they removed it from
their website. The website now has only has version 4.5 under the GPL.
We kept 5.0 in Debian because there is nothing that prevents us from
doing so from a legal point of view. Other projects (e.g. the “control”
package for Octave) do the same.

But it looks like the version of Slicot embedded in Scilab is even
older than 4.5, and corresponds to version 4.0. My guess is that the
missing symbols that you get correspond to functions that were removed
between 4.0 and 5.0.

Unfortunately this probably means that fixing the present bug requires
more work than just patching the build system (i.e. Scilab upstream
needs to move to a more recent Slicot).



Thanks a lot for your help on understand the issue. Admittedly there is 
quite a lot of work to do here :)


I am updating the Forwarded-to URI, this issue is still open upstream.



Best wishes,



Same to you,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Reimar Döffinger]

Hi Fabian!

> On 6 Jun 2023, at 21:14, Fabian Greffrath  wrote:
> 
> I remember that back then, when powerpc was still a release architecture in 
> Debian, we built two flavors of the ffmpeg libraries -- one with altivec and 
> one without:
> 
> https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/master/debian/rules#L184
> 
> That code is still there, so I wonder why your linker doesn't pick up the 
> flavor that matches your processor's instruction set.

Ah, thanks, that is probably just me being dumb since I was testing on a G3 
only!
I guess that only works for libraries though, no such auto-selection for 
executables, right?
Seems ffmpeg and ffplay are built only without altivec (which is kind of ok, 
and as said might be ok for MPlayer but would be nice to check).

Thanks for the hint,
Reimar

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Fabian Greffrath]

Hi Reimar,I remember that back then, when powerpc was still a release 
architecture in Debian, we built two flavors of the ffmpeg libraries -- one 
with altivec and one 
without:https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/master/debian/rules#L184That
 code is still there, so I wonder why your linker doesn't pick up the flavor 
that matches your processor's instruction set.Cheers, - Fabian Von 
meinem/meiner Galaxy gesendet
 Ursprüngliche Nachricht Von: Reimar Döffinger 
 Datum: 06.06.23  20:24  (GMT+01:00) An: Lorenzo 
, 448...@bugs.debian.org Betreff: Bug#448105: mplayer: 
Illegal Instruction in init_audio_codec > On 6 Jun 2023, at 15:17, Reimar 
Döffinger  wrote:> >> Disable altivec for everyone 
doesn't seem a good compromise to me, I'm>> going to build twice on powerpc and 
let the user decide which one to use> > To be clear: as MPlayer has no 
hand-written altivec, I I expect only a maybe 5-10% or so degradation (pure 
guess), the most performance critical stuff in FFmpeg should not be 
affected.So, funny thing. I installed debian-ppc on qemu g3 emulated 
system.What did I find out:- xfce4 crashes with illegal instruction- ffmpeg 
does not crash, but only because it is built with --disable-altivec which makes 
it basically unusably slow on e.g. G4 systems.So there is no winning.So for 
practical purposes, you can just as well compile MPlayer with 
--disable-altivec, since FFmpeg is compiled this way the speed of MPlayer won't 
make a relevant difference.On the details what goes on here (skip if you do not 
like rants):What is the source of all these issues? gccIn the past, -maltivec 
was used to just enable support for altivec intrinsics.However gcc then changed 
and generated Altivec instructions even from plain C code.While that makes 
sense in a way, it meant code everywhere broke on non-altivec systems.This 
includes FFmpeg.For packages important enough/depending on maintainer, the 
"solution" was to disable altivec completely, making these programs vastly 
slower on Altivec enabled computers.Others like xfce4 and MPlayer only work on 
PPC systems with Altivec.Without extensive code and build system changes, this 
seems now an unsolvable situation.Unless someone adds an option like -faltivec 
that Apple had, which allows the intrinsics but not compiler generation of 
altivec instructions (I think gcc maintainers at one point said they could not 
do that).clang has both -faltivec and -maltivec, but neither are properly 
documented, so who knows if they would help here or not.Either way, without 
someone EXTREMELY motivated, this seems not solvable (switching to clang with 
-faltivec if it were to work just MIGHT have a chance).I guess it's a lesson in 
not buying into architectures where the creators don't have their shit together 
enough to get even the basics right - and upstreamed... (I guess it's mostly 
solved by PPC being as good as dead now).(don't get me wrong, I still sometimes 
boot my old MacMini with G4 and update to latest Debian, but I think the ISA is 
just dead at this point, unfortunately).Sorry for the long rant,Reimar

Bug#1037167: kanboard: CVE-2023-33956 CVE-2023-33968 CVE-2023-33969 CVE-2023-33970

[Salvatore Bonaccorso]

Source: kanboard
Version: 1.2.26+ds-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for kanboard.

CVE-2023-33956[0]:
| Kanboard is open source project management software that focuses on
| the Kanban methodology. Versions prior to 1.2.30 are subject to an
| Insecure direct object reference (IDOR) vulnerability present in the
| application's URL parameter. This vulnerability enables any user to
| read files uploaded by any other user, regardless of their privileges
| or restrictions. By Changing the file_id any user can render all the
| files where MimeType is image uploaded under **/files** directory
| regard less of uploaded by any user. This vulnerability poses a
| significant impact and severity to the application's security. By
| manipulating the URL parameter, an attacker can access sensitive files
| that should only be available to authorized users. This includes
| confidential documents or any other type of file stored within the
| application. The ability to read these files can lead to various
| detrimental consequences, such as unauthorized disclosure of sensitive
| information, privacy breaches, intellectual property theft, or
| exposure of trade secrets. Additionally, it could result in legal and
| regulatory implications, reputation damage, financial losses, and
| potential compromise of user trust. Users are advised to upgrade.
| There are no known workarounds for this vulnerability.


CVE-2023-33968[1]:
| Kanboard is open source project management software that focuses on
| the Kanban methodology. Versions prior to 1.2.30 are subject to a
| missing access control vulnerability that allows a user with low
| privileges to create or transfer tasks to any project within the
| software, even if they have not been invited or the project is
| personal. The vulnerable features are `Duplicate to project` and `Move
| to project`, which both utilize the `checkDestinationProjectValues()`
| function to check his values. This issue has been addressed in version
| 1.2.30. Users are advised to upgrade. There are no known workarounds
| for this vulnerability.


CVE-2023-33969[2]:
| Kanboard is open source project management software that focuses on
| the Kanban methodology. A stored Cross site scripting (XSS) allows an
| attacker to execute arbitrary Javascript and any user who views the
| task containing the malicious code will be exposed to the XSS attack.
| Note: The default CSP header configuration blocks this javascript
| attack. This issue has been addressed in version 1.2.30. Users are
| advised to upgrade. Users unable to upgrade should ensure that they
| have a restrictive CSP header config.


CVE-2023-33970[3]:
| Kanboard is open source project management software that focuses on
| the Kanban methodology. A vulnerability related to a `missing access
| control` was found, which allows a User with the lowest privileges to
| leak all the tasks and projects titles within the software, even if
| they are not invited or it's a personal project. This could also lead
| to private/critical information being leaked if such information is in
| the title. This issue has been addressed in version 1.2.30. Users are
| advised to upgrade. There are no known workarounds for this
| vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-33956
https://www.cve.org/CVERecord?id=CVE-2023-33956
[1] https://security-tracker.debian.org/tracker/CVE-2023-33968
https://www.cve.org/CVERecord?id=CVE-2023-33968
[2] https://security-tracker.debian.org/tracker/CVE-2023-33969
https://www.cve.org/CVERecord?id=CVE-2023-33969
[3] https://security-tracker.debian.org/tracker/CVE-2023-33970
https://www.cve.org/CVERecord?id=CVE-2023-33970

Regards,
Salvatore

Bug#1013298: maybe retire?

[Antoine Beaupré]

I'm actually wondering if it's worth working on flycheck at all at the
moment.

reading this post:

https://www.masteringemacs.org/article/spotlight-flycheck-a-flymake-replacement

I found this:

> So why switch away from Flymake? Well, before the advent of Emacs 27
> and the renewed interest in Flymake, I’d argue because Flymake had
> atrophied for a long time. Nowadays the distinction is less clear. If
> running M-x flymake-mode works as you expect – this is doubly true if
> you’re using a Language Server client like eglot or LSP-mode – then
> you can just stick with Flymake. It works well. But, if you’re using
> an older version of Emacs, or if you want a package with nearly a
> decade’s worth of attention lavished on it, you may want to give
> Flycheck a shot.

We're not "using an older version of Emacs", we're pretty good at
keeping up with upstream releases. So why should we bother with
Flycheck?

There's a comparison page that still seem to favor flycheck;

https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html

... but it hasn't been updated in 3 years, so I asked upstream for an
update:

https://github.com/flycheck/flycheck/issues/2023

I might also try to switch back to plain flymake myself.

a.

-- 
There is no power on earth from which we should be prepared to accept
an order to kill.
   - Albert Einstein

Bug#1037166: libelementary-data: versions of libelementary1 and libelementary-data don't match on ia64

[Thomas Uhle]

Package: libelementary-data
Version: 1.26.0-1
Severity: important
Control: affects -1 libelementary1 libefl-all-dev

Dear maintainers,

since the release of version 1.26.0-1, it is no longer possible to install 
the binary package libelementary1:ia64 from the Debian repository because 
of the following reasons:


* libelementary1:ia64 is still at version 1.25.1-1 because src:efl fails
  to build because any gcc > 10 crashes during the build on ia64, cf. [1].

* libelementary-data:all has been built on amd64 and so has always been
  updated for all Debian repositories for sid (incl. ia64), currently
  being at version 1.26.3-1.

* libelementary1:ia64 depends on libelementary-data:all with exactly the
  same source version.

So libelementary1 (version 1.25.1-1) expects to have libelementary-data 
from version 1.25.1-1 as well which is but from version 1.26.3-1 in the 
repositories.  That is why this dependency cannot be fulfilled on i64.


Any other package depending on libelementary1 cannot be installed on ia64, 
most notably libefl-all-dev.  But this package is a build-dependency for 
other packages in Debian that do not need libelementary1 but another 
library from src:efl.  dbus-cpluscplus for instance just depends on 
libecore1 and the library libeina1a that libecore1 depends on.


That is why some packages currently fail to build on Debian's ia64 build 
servers although they would compile if libelementary1 could be installed 
along with libefl-all-dev.  So I see two options: could you please either 
compile src:efl on ia64 using gcc-10 as long as the newer gcc versions 
are crashing, or could you please put back libelementary-data from version 
1.25.1-1 into the ia64 repository.


Thank you in advance!

Best regards,

Thomas Uhle


[1] https://buildd.debian.org/status/packages.php?p=efl=ia64

Bug#1037165: vit: Python TypeError: 'str' object does not support item assignment

[Matthew Lemon]

Package: vit
Version: 2.2.0-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

   Installed vit, ran `vit` to launch program.

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

   Ran `vit` command.

   * What was the outcome of this action?

Traceback (most recent call last):
  File "/usr/bin/vit", line 33, in 
sys.exit(load_entry_point('vit==2.2.0', 'console_scripts', 'vit')())
 ^^
  File "/usr/lib/python3/dist-packages/vit/command_line.py", line 5, in main
Application(options, filters)
  File "/usr/lib/python3/dist-packages/vit/application.py", line 77, in __init__
self.refresh(False)
  File "/usr/lib/python3/dist-packages/vit/application.py", line 920, in refresh
self.bootstrap(load_early_config)
  File "/usr/lib/python3/dist-packages/vit/application.py", line 110, in 
bootstrap
self.load_contexts()
  File "/usr/lib/python3/dist-packages/vit/application.py", line 104, in 
load_contexts
self.contexts = self.task_config.get_contexts()
^^^
  File "/usr/lib/python3/dist-packages/vit/config_parser.py", line 333, in 
get_contexts
subtree = self.subtree('context.')
  
  File "/usr/lib/python3/dist-packages/vit/config_parser.py", line 292, in 
subtree
tree_location[part] = {} if len(parts) else value
~^^
TypeError: 'str' object does not support item assignment

   * What outcome did you expect instead?

Program to launch.



-- 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-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vit depends on:
ii  python3  3.11.2-1+b1
ii  python3-tasklib  2.5.1-3
ii  python3-urwid2.1.2-4+b1

vit recommends no packages.

vit suggests no packages.

-- no debconf information

-- 

Matthew Lemon
Email: m...@matthewlemon.com


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Dominik George]

> Ok, how about: "the whole project, minus naturesha...@debian.org who
> appears to be unfamiliar with the concept of hyperboles, is moving
> toward git and Salsa". Better?

No.

Your "hyperbole" very much read as "Come on, minority who cares about
the mail workflow, you're weird anachronists, get onto the Salsa train already!"

So that's what I am criticizing.

-nik


signature.asc
Description: PGP signature

Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)

[Maxim Cournoyer]

Package: libwxgtk3.0-gtk3-0v5
Version: 3.0.5.1+dfsg-2
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?

Testing a wxPython application on a Raspberry Pi (based on Debian
Bullseye), it was discovered that the wx.UIActionSimulator [0] class
did not produce any input there, as opposed to it working on a Guix
System.

[0]  
https://docs.wxpython.org/wx.UIActionSimulator.html?highlight=uiactionsimulator#wx.UIActionSimulator

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

I researched the problem and found that the feature I wanted was implemented 
using XTest, which is detected at wxWidgets' build time [1].  Looking at the 
Debian
package dependencies, I found it did *not* depend on the libxtst6 package.

[1]  https://github.com/wxWidgets/wxWidgets/issues/17530

   * What was the outcome of this action?

This bug/wishlist report.

   * What outcome did you expect instead?

wx.UIActionSimulator from wxPython/wxWidgets should produce key inputs
instead of nothing.  It should work like it does on Guix System.

-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages libwxgtk3.0-gtk3-0v5 depends on:
ii  libc62.31-13+rpt2+rpi1+deb11u5
ii  libcairo21.16.0-5+rpt1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgl1   1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+rpt12+deb11u3
ii  libjpeg62-turbo  1:2.0.6-4
ii  libnotify4   0.7.9-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  libsm6   2:1.2.3-1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1+deb11u4
pn  libwxbase3.0-0v5 
ii  libx11-6 2:1.7.2-1

libwxgtk3.0-gtk3-0v5 recommends no packages.

libwxgtk3.0-gtk3-0v5 suggests no packages.

Bug#1037163: workrave-gnome: Incompatible with GNOME Shell 44

[Jeremy Bícha]

Package: workrave-gnome
Version: 1.10.50-3
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-44
Forwarded: https://github.com/rcaelers/workrave/issues/487

The workrave extension no longer works with GNOME Shell 44. See the
upstream bug.

Note that you would also need
https://salsa.debian.org/debian/workrave/-/merge_requests/10 if you
want to test this extension with GNOME Shell 44. But the merge request
there is not sufficient to fix this issue now.

If this bug is still not fixed, workrave will need to be removed from
Debian Testing when the Debian GNOME team performs the GNOME Shell 44
transition which could happen as early as next month. A workaround is
to temporarily stop building the workrave-gnome binary package from
the workrave source.

Thank you,
Jeremy Bícha

Bug#1036818: [pkg-lxc-devel] Bug#1036818: Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

[Paul Gevers]

Hi,

On 01-06-2023 13:28, Mathias Gibbens wrote:

   Some other things we can look at -- are there any errors/warnings in
the lxcfs service journal and/or the system's dmesg that is running
lxcfs? It might also be useful to start lxcfs with debugging (`-d`) if
there's nothing being logged about populating /proc/cpuinfo.


This maybe?

Jun 06 17:35:55 ci-worker-armhf-01 lxcfs[686]: ../src/proc_cpuview.c:
1055: proc_cpuinfo_read: Write to cache was truncated

On 06-06-2023 04:06, Mathias Gibbens wrote:
One other thing to double check on ci-worker-armhf-01 would be the 
contents of /var/lib/lxcfs/proc/cpuinfo, so we can see what lxcfs is

 doing from the host side.


debian@ci-worker-armhf-01:~$ cat /var/lib/lxcfs/proc/cpuinfo
processor   : 0
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

processor   : 1
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

[ etc ]

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Reimar Döffinger]

> On 6 Jun 2023, at 15:17, Reimar Döffinger  wrote:
> 
>> Disable altivec for everyone doesn't seem a good compromise to me, I'm
>> going to build twice on powerpc and let the user decide which one to use
> 
> To be clear: as MPlayer has no hand-written altivec, I I expect only a maybe 
> 5-10% or so degradation (pure guess), the most performance critical stuff in 
> FFmpeg should not be affected.

So, funny thing. I installed debian-ppc on qemu g3 emulated system.
What did I find out:
- xfce4 crashes with illegal instruction
- ffmpeg does not crash, but only because it is built with --disable-altivec 
which makes it basically unusably slow on e.g. G4 systems.
So there is no winning.

So for practical purposes, you can just as well compile MPlayer with 
--disable-altivec, since FFmpeg is compiled this way the speed of MPlayer won't 
make a relevant difference.

On the details what goes on here (skip if you do not like rants):
What is the source of all these issues? gcc
In the past, -maltivec was used to just enable support for altivec intrinsics.
However gcc then changed and generated Altivec instructions even from plain C 
code.
While that makes sense in a way, it meant code everywhere broke on non-altivec 
systems.
This includes FFmpeg.
For packages important enough/depending on maintainer, the "solution" was to 
disable altivec completely, making these programs vastly slower on Altivec 
enabled computers.
Others like xfce4 and MPlayer only work on PPC systems with Altivec.
Without extensive code and build system changes, this seems now an unsolvable 
situation.
Unless someone adds an option like -faltivec that Apple had, which allows the 
intrinsics but not compiler generation of altivec instructions (I think gcc 
maintainers at one point said they could not do that).
clang has both -faltivec and -maltivec, but neither are properly documented, so 
who knows if they would help here or not.
Either way, without someone EXTREMELY motivated, this seems not solvable 
(switching to clang with -faltivec if it were to work just MIGHT have a chance).
I guess it's a lesson in not buying into architectures where the creators don't 
have their shit together enough to get even the basics right - and 
upstreamed... (I guess it's mostly solved by PPC being as good as dead now).
(don't get me wrong, I still sometimes boot my old MacMini with G4 and update 
to latest Debian, but I think the ISA is just dead at this point, 
unfortunately).

Sorry for the long rant,
Reimar

Bug#1037162: grub-common: /etc/default/grub overwritten when installing OS updates

[blindcoder]

Package: grub-common
Version: 2.06-13
Severity: normal

Dear Maintainer,

I have edited /etc/default/grub on my system to include the following
line:
GRUB_DISABLE_OS_PROBER=false

When installing OS updates, at least through gnome's "Install updates
before shutting down" option, possibly even through `apt upgrade`, this
line gets commented out (the line start with a # character) and the
dual-boot Windows installation no longer shows up in the grub boot menu.
Editing the file, removing the # character, and running update-grub
makes the Windows entry show up again.

I actually expect this file to not be overwritten by an upgrade if it
has been edited, like most other files.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/victoria--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/nvme0n1p2 /boot ext2 rw,relatime 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod lvm
insmod ext2
set 
root='lvmid/7IC92I-9piw-1VMZ-rezW-IwQt-dBvg-01y43w/ShfFzk-rWsb-VjRV-Lhy2-RNEz-V5h1-fP9eYW'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/7IC92I-9piw-1VMZ-rezW-IwQt-dBvg-01y43w/ShfFzk-rWsb-VjRV-Lhy2-RNEz-V5h1-fP9eYW'
  1558c0ed-75ea-4844-93c2-3a2ee86f0bcc
else
  search --no-floppy --fs-uuid --set=root 1558c0ed-75ea-4844-93c2-3a2ee86f0bcc
fi
font="/usr/share/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod lvm
insmod ext2
set 
root='lvmid/7IC92I-9piw-1VMZ-rezW-IwQt-dBvg-01y43w/ShfFzk-rWsb-VjRV-Lhy2-RNEz-V5h1-fP9eYW'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/7IC92I-9piw-1VMZ-rezW-IwQt-dBvg-01y43w/ShfFzk-rWsb-VjRV-Lhy2-RNEz-V5h1-fP9eYW'
  1558c0ed-75ea-4844-93c2-3a2ee86f0bcc
else
  search --no-floppy --fs-uuid --set=root 1558c0ed-75ea-4844-93c2-3a2ee86f0bcc
fi
insmod png
if background_image /usr/share/desktop-base/emerald-theme/grub/grub-16x9.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-1558c0ed-75ea-4844-93c2-3a2ee86f0bcc' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 
d4ff0e89-93cb-419e-8e91-49ce7b5777d1
echo'Loading Linux 6.1.0-9-amd64 ...'
linux   /vmlinuz-6.1.0-9-amd64 root=/dev/mapper/victoria--vg-root ro  
quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-6.1.0-9-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-1558c0ed-75ea-4844-93c2-3a2ee86f0bcc' {
menuentry 'Debian GNU/Linux, with Linux 6.1.0-9-amd64' --class debian 
--class gnu-linux --class gnu --class os 

Bug#1037161: pelican-quickstart crashes if python3-tzlocal is installed

[Fiona Klute]

Package: pelican
Version: 4.8.0+dfsg-1
Severity: normal
Tags: upstream

Running pelican-quickstart fails with the exception below if
python3-tzlocal is installed. Otherwise the ImportError for tzlocal is
caught and the buggy code avoided.

The buggy code is still present upstream:
https://github.com/getpelican/pelican/blob/1f6b344f7d7b7e8dd0271cc333a257faca566c15/pelican/tools/pelican_quickstart.py#L17-L21

The problem is that zoneinfo.ZoneInfo (part of the standard library)
does not have a "zone" attibute, I assume "key" would be the correct one.

$ pelican-quickstart
Traceback (most recent call last):
  File "/usr/bin/pelican-quickstart", line 33, in 
sys.exit(load_entry_point('pelican==4.8.0', 'console_scripts',
'pelican-quickstart')())

^^^
  File "/usr/bin/pelican-quickstart", line 25, in
importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202,
in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in
_find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in
_call_with_frames_removed
  File
"/usr/lib/python3/dist-packages/pelican/tools/pelican_quickstart.py",
line 19, in 
_DEFAULT_TIMEZONE = tzlocal.get_localzone().zone

AttributeError: 'zoneinfo.ZoneInfo' object has no attribute 'zone'


-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pelican depends on:
ii  python33.11.2-1+b1
ii  python3-blinker1.5-1
ii  python3-dateutil   2.8.2-2
ii  python3-docutils   0.19+dfsg-6
ii  python3-feedgenerator  2.0.0-1
ii  python3-jinja2 3.1.2-1
ii  python3-markdown   3.4.1-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-pygments   2.15.1+dfsg-1
ii  python3-rich   13.3.1-1
ii  python3-tz 2022.7.1-4
ii  python3-unidecode  1.3.6-1

pelican recommends no packages.

Versions of packages pelican suggests:
ii  pandoc   2.17.1.1-1.1
pn  pelican-doc  
ii  python3-bs4  4.11.2-2

-- no debconf information

Bug#1010478: libmutter-10-0: gnome-shell crash to gdm after suspend, libmutter segfault. After relogin monitors.xml is ignored

[Simon McVittie]

Control: tags -1 + moreinfo

On Mon, 02 May 2022 at 11:55:42 +, Krassy Boykinov wrote:
> gnome-shell crashes with a segfault in libmutter after suspend, only
> reproducible when connected to a Lenovo ThinkPad Thunderbolt Dock Gen. 1
> with two external monitors.
> After re-login with gdm the monitors are arranged in a straight line
> (default configuration), monitors.xml is ignored. Some similarity to Bug
> #927275.

On Thu, 27 Apr 2023 at 15:52:42 +0200, Ryan wrote:
> This is probably related to this issue / fix that has just been made against
> gnome 44:
> 
> https://gitlab.gnome.org/GNOME/mutter/-/issues/2570
> 
> https://gitlab.gnome.org/salmanmlk/mutter/-/commit/f39416f45e5f8c46755abb24684a1aeea1b708df

mutter#2570 was reported to Debian as .

The crash that Krassy Boykinov reported as #1010478 doesn't look like
mutter#2570 to me: the kernel message says the segfault was inside
libmutter, whereas in mutter#2570, the segfault seems to be inside
libwayland-server. We should try to keep to one bug per Debian bug number,
otherwise it becomes increasingly difficult to fix anything.

A backtrace from the crash would be very useful information for this or any
other crash. Please see :
usually the easiest way is to use the systemd-coredump package, as described
in .

Ryan: If you are experiencing a crash that closely resembles mutter#2570,
then that's in-scope for #1036268 but out-of-scope for #1010478.
Please see  for more information,
including prerelease packages containing a backport of the upstream fix.
Or, if your backtrace does not resemble mutter#2570, please report it as a
separate bug.

Krassy Boykinov: Is this crash that you reported against gnome-shell/mutter
version 42 still happening in version 43.x? If not, we can close the bug.
If it's still happening, a backtrace would be very useful (we're unlikely
to be able to fix it without that information).

Thanks,
smcv

Bug#856047: locale-gen manpage is not up-to-date

[Andrej Shadura]

On Sat, 25 Feb 2017 01:43:11 +0800 Anthony Wong 
 wrote:

Package: locales
Version: 2.24.9

Manpage of locale-gen does not mention the --keep-existing option. In
the source I see there is locale-gen.8.sgml, which has this option,
but apparently it is not used for generating locale-gen.8, and these
two files are now out-of-sync. If you prefer to keep using
locale-gen.8, I suggest to remove the sgml file from git to avoid
confusion, otherwise we should keep the sgml file up-to-date. I can
send a patch to fix this if you let me know which way is preferred.


This has been fixed in this commit:

commit 87c1627beeb75c18e85ba40c927a46c2ee1fa749
Author: наб 
Date:   Thu May 5 16:35:03 2022 +0200

Rewrite locale-gen.8

It has an SGML source that no-one has regenerated, ever(?) ‒
--keep-existing was missing entirely since its inclusion in /2005/ ‒
and rambles

Re-write it in mdoc(7), instead, which means it doesn't have to be
compiled, and passes mandoc -Tlint

locale.alias(5) was removed from the distribution in 2.3.5-2 (2005)


--
Cheers,
  Andrej

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail  writes:

> Turns out bullseye-backports lintian (2.115.1~bpo11+1) only checks for 4.6.1 
> Standards, therefore a more serious error (depends-on-obsolete-package 
> lsb-base) was reported by sid lintian.
> Upon inspecting the situation (lsb-base is now a transitional empty
> package only here for debootstrap purposes mainly) and reading
> https://lists.debian.org/debian-devel/2023/01/msg00160.html I removed
> the package dependency entirely. This should be entirely safe.

Nice catch, and if someone using OpenRC is affected, I hope that person
will be willing to provide a patch for what sounds like a corner-case.

> I also added Upstream-Contact into debian/copyright and stripped some
> trailing whitelines. Package should be lintian O.K. now.

Thank you.

> Nicholas, my salsa account is verified now, waiting for push permission if 
> that is ok. Is there anything else I should do now about that ?
>

1. What is the purpose of the dh_installsystemd override?  (hint: see the
dh_installsystemd man page about --name).

2. I found an inaccuracy in the upstream sections of debian/changelog;
please fix it.  Plain old grep or manual header check should be enough
to spot this.

3. Do the patches have accurate filenames, subjects, and synopses?
Adopting a package is the perfect time to fix anything misleading.

4. Does everything in your changelog entry still accurately reflect the
package? (ie "not started by default").

Would you please push your work to your personal Salsa namespace (fork
relationship optional), and provide the link to the repo?  This way I
can responsibly grant you permissions, because I will have reviewed how
you work in git :)  I can also review from git, if you prefer

Regards,
Nicholas

P.S. It seems like Debian's copy might be the defacto upstream, as of
eight years ago, when someone wrote we were "doing a good job"
maintaining mini_httpd.


signature.asc
Description: PGP signature

Bug#1036268: gnome-shell: Session crashes, thrown out to login screen, after the session has been idle & screen switched off

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/-/issues/2570
Control: tags -1 + fixed-upstream pending
Control: block -1 by 1036856

On Sat, 03 Jun 2023 at 15:01:10 +, Amr Ibrahim wrote:
> Am Samstag, dem 27.05.2023 um 21:32 +0100 schrieb Simon McVittie:
> > A backtrace from the crash would be very useful information for this or any
> > other crash. Please see 
>
> Thread 1 "gnome-shell" received signal SIGSEGV, Segmentation fault.
> 0x7fed1b2aa963 in wl_closure_invoke (closure=0x55dc1c9283d0, 
> flags=, target=, opcode=0, data= out>) at ../src/connection.c:1021
> Download failed: Das Argument ist ungültig.  Continuing without source file 
> ./build/../src/connection.c.
> 1021  ../src/connection.c: Datei oder Verzeichnis nicht gefunden.
> #0  0x7fed1b2aa963 in wl_closure_invoke (closure=0x55dc1c9283d0, 
> flags=, target=, opcode=0, data= out>) at ../src/connection.c:1021
> count = 0
> cif = {abi = FFI_UNIX64, nargs = 2, arg_types = 0x7ffcf1869ae0, rtype 
> = 0x7fed1a069180 , bytes = 0, flags = 0}
> ffi_types = {0x7fed1a069060 , 0x7fed1a069060 
> , 0x7fed1a0690e0 , 0x7fed19cb6c6d, 
> 0x7fed1a0690e0 , 0x10, 0xc, 0x7ffc000e, 0x55dc1ae55800, 
> 0xd8, 0x55dc220ebe90, 0x10170, 0x7fed19df1c60, 0x0, 0x8, 0x7fed19cb8582 
> , 0x0, 0x0, 0x7ffcf1869ba0, 0x7fed1b2b0cf0 , 
> 0x7fed1b2ac0d1, 0x0}
> ffi_args = {0x7ffcf1869aa0, 0x7ffcf1869aa8, 0x55dc220bb328, 
> 0xd21b64d4776ea700, 0x55dc1ae55830, 0x55dc1ae55800, 0x55dc2114a9a0, 0x0, 
> 0x7fed1b2b0cf0 , 0x7fed1b2aa22b 
> , 0x55dc1c9284a8, 0x55dc215b87a0, 
> 0x55dc220bb3e0, 0x55dc1c9283d0, 0x8f1869c50, 0x55dc220bb3ec, 0x7fed1b2b0cf0 
> , 0x7fed1b2aa696 , 
> 0x7ffcf1869c38, 0x7fed1b2a47b0 , 0x7fed1b2b0cf0 
> , 0x203cde00}
> implementation = 0x0

Thanks, both of the backtraces you provided look like the same issue as
. This was identified
too late to be fixed in the initial release of Debian 12, but I've asked
for permission to include the upstream fix in the Debian 12.1 point release.

Prerelease packages with the backported fix are available at
.

smcv

Bug#1002996: deps

[matthias . geiger1024]

Hi Agathe,

I ran cargo-debstatus against orjson and there's just three rust libs with no 
other dependencies (!) missing:
itoap, compact_str and associative-cache. They should be packaged withing the 
debian rust team [1]. The library itself should probably go into the python 
team; for the build process there's this wiki page [2].

hope this helps,
---
Matthias Geiger (werdahias)

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

[2] https://wiki.debian.org/Gnome/Rust_Packaging-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#999850: clap-complete

[matthias . geiger1024]

Hi Jelmer,

cargo debstatus show the following missing crates for clap-complete-command:

clap_complete_nushell (new package, no rdeps)
clap_complete_fig (in debian, needs an 3.x version split out. You can do it 
like that:

./update.sh clap_complete_fig 3
...
This creates a clap_complete_fig-3 package. Then update the regular 
clap_complete_fig package to 4.x )
hope this helps,

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1037160: udev: fails to rename network interface if more then 9 interfaces are present

[Leibold Stefan (XC-DX/ESC5)]

Package: udev
Version: 245.4-4ubuntu3.20
Severity: important

Dear Maintainer,

in a setup with more then 9 network interfaces, udev net_id fails to properly 
derive the ID_NET_NAME_SLOT.
Due to that, interfaces are listed as "unmanaged" or "disabled" and cannot be 
used.

The error message from syslog:

kernel: i40e :1d:00.0 eno1: renamed from eth0
kernel: i40e :1d:00.1 eno2: renamed from eth1
kernel: i40e :b3:00.0 ens3f0: renamed from eth2
kernel: i40e :b3:00.1 ens3f1: renamed from eth4
kernel: i40e :b3:00.3 ens3f3: renamed from eth6
kernel: i40e :b3:00.2 ens3f2: renamed from eth5
kernel: e1000e :19:00.1 ens1f1: renamed from eth0
kernel: e1000e :19:00.0 ens1f0: renamed from eth3
systemd-udevd[1011]: eth2: Failed to rename network interface 11 from 'eth2' to 
'ens1f1': File exists
systemd-udevd[1030]: eth1: Failed to rename network interface 10 from 'eth1' to 
'ens1f0': File exists

It seems, net_id does not take interface number, but only last digit, to 
generate ID_NET_NAME_SLOT (here it creates ens1f0 for interface 10 and ens1f1 
for interface 11, but they already exist, being prior created for interfaces 0 
and 1).

Output of net_id for interface 10

$ udevadm test-builtin net_id /sys/class/net/eth1
Load module index
Parsed configuration file /usr/lib/systemd/network/99-default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Created link configuration context.
Using default interface naming scheme 'v245'.
ID_NET_NAMING_SCHEME=v245
ID_NET_NAME_MAC=enxe8393510a367
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_PATH=enp26s0f0
ID_NET_NAME_SLOT=ens1f0
Unload module index
Unloaded link configuration context.


-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-149-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages udev depends on:
ii  adduser   3.118ubuntu2
ii  dpkg  1.19.7ubuntu3.2
ii  libacl1   2.2.53-6
ii  libblkid1 2.34-0.1ubuntu9.3
ii  libc6 2.31-0ubuntu9.9
ii  libkmod2  27-1ubuntu2.1
ii  libselinux1   3.0-1build2
ii  libudev1  245.4-4ubuntu3.20
ii  systemd-sysv  245.4-4ubuntu3.20
ii  util-linux2.34-0.1ubuntu9.3

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  245.4-4ubuntu3.20

-- no debconf information
​

Bug#1036824: po4a: Describe how to create/maintain pot file from man page

[Helge Kreutzmann]

Hello Martin,
On Mon, Jun 05, 2023 at 11:32:04PM +0200, Martin Quinson wrote:
> Every po4a-* scripts are deprecated. The right way to go is to use the main
> po4a script, using an adequate config file. I think that this is documented in
> po4a(1), isn't it?

Yes, po4a is documented, but not the work flow we use. The
documentation assumes an intial "run" with a previous translation and
then po4a. (See my report you cite below). 

> Which project are we speaking of? I'm really overwhelmed right now but maybe I
> could find some time to propose a config file for that project in the future.

This is not only a config file. We have several scripts which prepare
the pot files, manage the compendium, deal with upstream files etc. So
this is a large machinery.

The project is manpages-l10n. We have 2319 pot files, 22 languages, 8
distributions we take files from, over 100 projects the man pages come
from 9597 po files, organized nicely by languages, man page section. 

All scripts are written to allow easy additions of new languages (and
indeed, we get more and more of them). 

My intent is to understand the proper way to do things and then to see
if I'm able to migrate our scripts doing just this. This, of course,
is a long term project.

> Sorry, 

No need to be, we are all volunteers; thanks for your work on po4a!

> Mt
> 
> Le samedi 27 mai 2023 à 13:56 +0200, Helge Kreutzmann a écrit :
> > Package: po4a
> > Version: 0.69-1
> > Severity: wishlist
> > 
> > Some time ago several po4a tools started emitting warnings and ceased
> > working as before. I read that "po4a" is the way to go, however, we
> > seriously lack the man power (and knowledge) to rewrite the entire
> > machinery. However, I'm gradully trying to improve the system where
> > and when possible.
> > 
> > For this, I have the follwing question/request:
> > Given that I have a man page (in nroff or mdoc format) and I want to
> > create a pot file from it (not po file, as this page is not yet
> > translated). How is this done best/correctly?
> > 
> > Quite a few explanations in the po4a man pages assume you already have
> > some translated text.
> > 
> > Currently I use something like:
> > 
> > po4a-updatepo -f man \
> >     --option groff_code=verbatim \
> >     --option generated \
> >     --option untranslated="a.RE,\|" \
> >     --option unknown_macros=untranslated \
> >     --master "$upstream_manpage" -M utf-8 \
> >     -p $tmp1 | grep -v "po4a-updatepo is deprecated. The unified po4a(1)
> > program is more convenient and less error prone."
> > 
> > (Until very recently this used po4a-gettextize, but this stopped working)
> > 
> > It would be great if you could document the proper solution in the 
> > very well written and extensive documentation.
> > 
> > 
> > -- System Information:
> > Debian Release: 12.0
> >   APT prefers testing-security
> >   APT policy: (500, 'testing-security'), (500, 'testing')
> > Architecture: amd64 (x86_64)
> > 
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored:
> > LC_ALL set to de_DE.UTF-8), LANGUAGE not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages po4a depends on:
> > ii  gettext 0.21-12
> > ii  libpod-parser-perl  1.65-1
> > ii  libsgmls-perl   1.03ii-38
> > ii  libsyntax-keyword-try-perl  0.28-1
> > ii  libyaml-tiny-perl   1.73-1
> > ii  opensp  1.5.2-13+b2
> > ii  perl    5.36.0-7
> > 
> > Versions of packages po4a recommends:
> > ii  liblocale-gettext-perl 1.07-5
> > ii  libterm-readkey-perl   2.38-2+b1
> > ii  libtext-wrapi18n-perl  0.06-10
> > ii  libunicode-linebreak-perl  0.0.20190101-1+b5
> > 
> > po4a suggests no packages.
> > 
> > -- no debconf information

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1037159: elinks: please make the build reproducible

[Chris Lamb]

Source: elinks
Version: 0.16.1.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
elinks could not be built reproducibly.

This because the manual PDF embeds the current build date:

├── ./usr/share/doc/elinks/manual.pdf.gz
  ├── manual.pdf
├── pdftotext {} -
│ @@ -13,15 +13,15 @@
│
│  WRITTEN BY
│
│  DATE
│
│  SIGNATURE
│
│ -June 5, 2023
│ +July 8, 2024
│

A patch is attached that exports FORCE_SOURCE_DATE in debian/rules,
a LaTeX-specific variable to ensure that LaTeX tools respect the
SOURCE_DATE_EPOCH environment variable.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


--- a/debian/rules  2023-06-06 09:34:21.315523819 -0700
--- b/debian/rules  2023-06-06 09:41:59.679487294 -0700
@@ -2,6 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-z,defs
+export FORCE_SOURCE_DATE = 1
 
 CONF_OPTS= -Dtest=true \
-Dlzma=true \

Bug#907189: busybox-syslogd: Please provide systemd .service files (attached)

[Michael Tokarev]

21.01.2023 19:49, Michael Tokarev wrote:
..

What's the reason to provide these systemd services for busybox-syslogd?

In my view, busybox-syslogd can be used as a minimal syslogging service
on a bare minimal system without much else besides busybox itself.
On a system with systemd, systemd-journald is already running, and provides
far better logging services than busybox-syslogd, including kernel logging
and /dev/log redirection.

I don't really see the point in providing systemd .services for busybox-syslogd.


After some thinking and facing issues with logging on a low-power machine where
systemd-journald is taking just too much time to find journal entries, I think
it is a good idea to provide busybox-syslogd.

In /etc/init.d/busybox-klogd, we have if running_under_systemd; then exit; fi -
added by me, with a comment stating klogd makes no sense under systemd. This
is apparently wrong, - yes, journald does intercept kernel log and logs it to
the journal, but it suffers from the same prob: on a low-power machine these
journal entries takes ages to retrieve. So it makes sense to package klogd
too, and to provide systemd service file for it.

Doing that now.

/mjt

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Luca Boccassi  writes:

> Snarks aside, allowing merge requests to be open on Salsa in _addition_
> to attachments to the BTS, as the vast majority of other packages
> already do, doesn't take away anything from you, but would add quite a
> lot for the rest of us, who find ourselves very limited and very much
> barrier-ized by clunky, old and painful email-based processes.

Merge requests are useful when the goal is to be able to merge the merge
request as-is at the end of some code review process. My guess is that
this happens about 20% of the time with Policy. The other 80% of the time
I tweak wording or phrasing or formatting when applying the change, and
also add an upgrading-checklist entry and other bookkeeping that I don't
want to have to explain to everyone proposing new wording.

Policy is not a program and we're not taking source code changes. The goal
of the discussion is to converge on the semantics of what we are going to
say, which often requires multi-paragraph discussions where the normal
tools of email such as quoting are more useful. I find trying to have an
email-style discussion in Salsa to be annoying and tedious. It also
fragments the record, whereas having it in the bug means I can, at any
time, load the entire bug into Gnus and re-read the discussion of how we
arrived at the decision in the same tool that I use for reading all other
Debian discussions.

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Luca Boccassi  writes:

> --- a/policy/ap-pkg-alternatives.rst
> +++ b/policy/ap-pkg-alternatives.rst
> @@ -24,3 +24,7 @@ See the :manpage:`update-alternatives(8)` man page for 
> details.
>  If ``update-alternatives`` does not seem appropriate you may wish to
>  consider using diversions instead.
>  
> +Do not attempt to use alternatives for files belonging or used by components
> +that support native overriding mechanisms, such as ``systemd`` unit files. 
> Read
> +:doc:`ch-binary` for more information.

"Do not attempt" in US English reads a little weirdly (I know you're
copying an existing UK English phrasing). I instead suggest:

Do not use alternatives for ``systemd`` configuration files. See
:doc:`ch-binary` for more information.

(See below for why this is systemd-specific.) This doesn't use our normal
normative language conventions, which I think is correct since this is a
non-normative appendix.

> diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst
> index fe360d1..09367d7 100644
> --- a/policy/ap-pkg-diversions.rst
> +++ b/policy/ap-pkg-diversions.rst
> @@ -81,3 +81,7 @@ when the file does not exist.
>  Do not attempt to divert a conffile, as ``dpkg`` does not handle it
>  well.
>  
> +Do not attempt to divert files belonging or used by components that support
> +native overriding mechanisms, such as ``systemd`` unit files. Read
> +:doc:`ch-binary` for more information.

Similarly here:

Do not use diversions for files that have their own native override
mechanisms, such as ``systemd`` unit files. See :doc:`ch-binary` for
more information.

> diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
> index e517f26..e36d028 100644
> --- a/policy/ch-binary.rst
> +++ b/policy/ch-binary.rst
> @@ -371,6 +371,37 @@ against earlier versions of something that previously 
> did not use
>  ``update-alternatives``; this is an exception to the usual rule that
>  versioned conflicts should be avoided.)
>  
> +Diversions and alternatives should be used primarily as a tool for local
> +administrators and local packages to override the behaviour of Debian. Its 
> use
> +between Debian packages should be rare, should involve coordination between 
> the
> +packages and their maintainers, and must only be used to solve problems that
> +cannot be handled through other facilities or native mechanisms.

I think this not correct for alternatives. They are intended for use
between Debian packages, so we need to distinguish between alternatives
and diversions here. This might be clearer if we created a subsection for
alternatives and diversions and added a bit of additional context from the
appendices (and ideally removed the appendices). That's not something to
do on this bug, just noting mostly for Sean and future work.

I think there's also a bit more justification than we need. The
justification is useful for discussing the Policy bug, but once we've
decided on an approach, I think we can just point at the correct
alternative mechanism.

How about something like this:

Diversions are primarily intended as a tool for local administrators
or local packages to override the behavior of Debian. While there are
some circumstances where one Debian package may need to divert a file
of another Debian package, those circumstances are rare and diversions
should only be used as a last resort when no other suitable mechanism
exists. Diversion of a file in one Debian package by another Debian
package should be coordinated between the maintainers of those
packages.

Diversions must not be used when a suitable override mechanism that
accomplishes the same goal is already available.

One specific case of that rule is that configuration files used by
``systemd`` components, such as `units,

`_
`udev rules,
`_
`tmpfiles.d,

`_
`modules-load.d,

`_,
`sysusers

`_
and other such files, including those specific to systemd daemons
(e.g.:  `/etc/systemd/system.conf).

`_
must not be diverted by any Debian package. Instead, use masking and
drop-ins.

"masking" and "drop-ins" here should ideally be links to the relevant
documentation.

We then have to figure out what to say about alternatives. I think the
above rule is too strong for alternatives; it's often convenient to use
slave alternatives even in places where there may be a native override
mechanism, 

Bug#1013298: O: flycheck -- modern on-the-fly syntax checking for Emacs

[Antoine Beaupré]

Control: tags -1 +pending
Control: owner -1 anar...@debian.org

On 2022-06-21 07:36:09, Denis Danilov wrote:
> Package: wnpp
> Severity: normal
> Control: affects -1 src:flycheck
>
> I intend to orphan the flycheck package.

I intend to adopt the package. It seems like the next step for the
package is to update it to the latest release (32) from May 2022.

Have you tried doing that upgrade or is there any peculiar reason why
we're at a git snapshot still?

Thanks for maintaining flycheck!

-- 
I prefer the tumult of liberty to the quiet of servitude.
- Thomas Jefferson

Bug#1037158: mozjs102: CVE-2023-34416, update to mozjs 102.12

[Jeremy Bícha]

Package: mozjs102
X-Debbugs-CC: t...@security.debian.org
Severity: important
Version: 102.11.0-1
Tags: security upstream bookworm

[ Reason ]
The new mozjs102 stable point release 102.12.0 includes a security fix for
- CVE-2023-34416: Memory safety bugs

[ Impact ]
mozjs102 is only used by gjs which in turn is used by GNOME Shell and
several GNOME apps written in JavaScript.

[ Tests ]
mozjs102 has build tests
It does not have autopkgtests of its own but triggers gjs autopkgtests.

There are also manual tests:
https://wiki.ubuntu.com/DesktopTeam/TestPlans/gjs

[ Other info ]
mozjs102 is the SpiderMonkey JavaScript engine from the current
Firefox ESR stable branch. There are monthly releases until the end of August.

https://whattrainisitnow.com/calendar/

I am unaware of anyone using Firefox vulnerabilities to attack GNOME
Shell, but I think it's good to be prudent and apply available
security updates. I don't believe the Debian Security Team has
previously done security uploads for mozjs. For instance, mozjs78 is
out of date in Bullseye.

For more info about the commits, see the Github mirror:
https://github.com/mozilla/gecko-dev/commits/esr102/js

This update also updates the GPG key for signing releases (copy stored
in debian/upstream/signing-key.asc and used by gbp import-orig). The
signing key expires every 2 years and the previous one has expired
now.
https://blog.mozilla.org/security/2023/05/11/updated-gpg-key-for-signing-firefox-releases/

Thank you,
Jeremy Bicha

Bug#1037157: ITP: damo -- Data Access Monitoring Operator

[Michel Alexandre Salim]

Package: wnpp
Severity: wishlist
Owner: Michel Alexandre Salim 
X-Debbugs-Cc: debian-de...@lists.debian.org, mic...@michel-slm.name

* Package name: damo
  Version : 1.8.3
  Upstream Contact: SeongJae Park 
* URL : https://damonitor.github.io/
* License : GPL
  Programming Lang: Python
  Description : Data Access Monitoring Operator

damo is a user space tool for DAMON. Using this, you can monitor the data access
patterns of your system or workloads and make data access-aware memory
management optimizations.

 - what it does: https://sjp38.github.io/post/damon/ -- basically you
   can optimize how the kernel manages memory based on how often pages
   are accessed
 - recent LWN article: https://lwn.net/Articles/931769/
 - Will be maintained as part of the Debian Python Team. I am a Debian
   Maintainer so this will need an initial sponsor.

Bug#1037138: linux-image-6.0.0-4-amd64: Linux kernel appears to not be respecting sysctl config value "net.ipv6.conf.all.disable_ipv6=1"

[Salvatore Bonaccorso]

Control: tags -1 + unreproducible moreinfo

Hi Dylan,

On Tue, Jun 06, 2023 at 05:19:38AM -0400, Dylan Morrison wrote:
> Package: src:linux
> Version: 6.0.8-1
> Severity: normal
> Tags: ipv6
> X-Debbugs-Cc: dizzy@domad.science

First a note on the version, 6.0.8-1 is not in testing, please update
to 6.1.27-1. 

> Dear Maintainer,
> 
> I am attempting to disable ipv6 entirely on this machine as it being enabled 
> is causing multiple issues with long connection timeouts etc, and I do not 
> have ipv6 support from my ISP nor do I use it locally. However, the generally 
> given advice to set net.ipv6.conf.all.disable_ipv6 to 1 is having no effect, 
> neither setting it in /etc/sysctl.conf nor using command line sysctl. Setting 
> net.conf.ipv6..disable_ipv6 works, and is what I am currently doing 
> for my primary network interface, but I would like ipv6 disabled globally.
> This appears to be a kernel issue afaict, I'm not 100% up on how the sysctl 
> mechanism works, but yeah.

After updating to 6.1.27, can you elaborate how IPv6 not disabled is
observed? Note that reading net.ipv6.conf.all.disable_ipv6 and getting
1 is not an indicator of IPv6 beeing not disabled, cf.
https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html?highlight=conf/all/disable_ipv6
.

What does 'ip add show' shows, and what does it show after executing
sysctl net.ipv6.conf.all.disable_ipv6=1 ?

ipv6 can as well entirely be disabled by using the disable_ipv6 kernel
parameter, cf. 
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=disable_ipv6=
that is e.g. adding ipv6.disable=1 to the kernel command line. Trough
grub2 you could add 

# cat /etc/default/grub.d/ipv6.cfg 
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX ipv6.disable_ipv6=1"

and run update-grub2.

I would like to understand what makes for you disabling it trough
net.ipv6.conf.all.disable_ipv6 not work.

Regards,
Salvatore

Bug#1037156: nheko: improve audio/video experience: error message or Recommends: gstreamer1.0-plugins-bad

[Helmut Grohne]

Package: nheko
Version: 0.11.3-2
Severity: minor

Hi,

trying to place a video or voice call with nheko failed here with an
error message around missing "webrtcbin". I eventually figured what it
means: Please install gstreamer1.0-plugins-bad and then it works.

Would it be possible to improve the error message to ask the user for
installing that package?

and/or

Can you add gstreamer1.0-plugins-bad to nheko's Recommends?

Thanks for considering

Helmut

Bug#1037078: closed by Paul Gevers (closing still open unblock requests)

[stefanor]

Control: reopen -1
Control: user release.debian@packages.debian.org
Control: usertag -1 pu
Control: retitle -1 bookworm-pu: package dh-python/5.20230130+deb12u1
Control: tag -1 bookworm

> The unblock requests that I'm closing in this message all came in after the
> deadline of 2023-05-28 12:00 UTC. We didn't have time to process them before
> the quiet period that started today.

OK, let's re-target to PU. Updated debdiff atteched.

If you're interested in having this change to ease upgrades, we can get
in in the first point release.

It probably doesn't make sense to carry the patch into trixie.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
diff -Nru dh-python-5.20230130/debian/changelog 
dh-python-5.20230130+deb12u1/debian/changelog
--- dh-python-5.20230130/debian/changelog   2023-01-30 12:30:45.0 
-0400
+++ dh-python-5.20230130+deb12u1/debian/changelog   2023-06-06 
10:59:16.0 -0400
@@ -1,3 +1,10 @@
+dh-python (5.20230130+deb12u1) bookworm; urgency=medium
+
+  * Reintroduce Breaks+Replaces on python2 needed to help apt in some upgrade
+scenarios. (Closes: #1036943)
+
+ -- Stefano Rivera   Tue, 06 Jun 2023 10:59:16 -0400
+
 dh-python (5.20230130) unstable; urgency=medium
 
   * pybuild.pm: Export SETUPTOOLS_SCM_PRETEND_VERSION for packages using
diff -Nru dh-python-5.20230130/debian/control 
dh-python-5.20230130+deb12u1/debian/control
--- dh-python-5.20230130/debian/control 2023-01-30 12:30:45.0 -0400
+++ dh-python-5.20230130+deb12u1/debian/control 2023-06-06 10:59:16.0 
-0400
@@ -29,6 +29,9 @@
 Breaks:
 # due to /usr/bin/dh_python3 and debhelper files
  python3 (<< 3.3.2-4~),
+# due to debhelper files
+ python2 (<< 2.7.18-2)
+Replaces: python2 (<< 2.7.18-2)
 Description: Debian helper tools for packaging Python libraries and 
applications
  This package contains:
   * pybuild - invokes various build systems for requested Python versions in

Bug#1037155: misses dependency on libboost-json1.81-dev

[Pierre Gruet]

Package: libboost1.81-all-dev
Version: 1.81.0-5
Severity: normal

Dear Maintainer,

The version of libboost1.81-all-dev currently in unstable and testing does not
depend on one of the -dev packages, namely libboost-json1.81-dev, although it
should.

Best regards,

-- 
Pierre

Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)

[Nicholas D Steeves]

Antoine Beaupré  writes:

> You seem to have pasted a link to the TPA GitLab wiki here... Did you
> mean to paste some other bug report or link there?

That's confirmation that I tested with the link to the file that you
were noted (in an earlier post) that you were testing with.

> I think I'm okay with the package being removed from bookworm if we
> can't find a quick fix here. The release date is just too close. We can
> always fix this in a point release or get a backport going.
>
> Interestingly, it's not marked as autoremoval here though:
>
> https://tracker.debian.org/pkg/markdown-toc-el

Interesting, maybe someone has faith that we'll fix this in a point
release!

> Alternatively, I wonder if there's a way to make a simpler module that
> would defer the TOC generation to an external command...
>
> Is there something out there that takes a markdown doc as input and
> outputs a TOC?

I saw your note on python3-md-doc, and it made me think about more
generic TOC and endnotes functions that call an external parser.

This one might be a viable alternative, with a slightly more active
upstream than markdown-toc:
https://github.com/snosov1/toc-org#markdown-support

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#50091: perl: Building with profile nodoc fails

[Henry N.]

Package: perl
Version: 5.36.0-7
Followup-For: Bug #50091
Usertags: rebootstrap

Dear Maintainer,

building perl from source with profile nodocs fails.

# mkdir perl
# cd perl
# apt source perl
# apt build-dep perl
# cd perl-5.36.0/
# dpkg-buildpackage -B -Pnodoc,nocheck -uc -us

mv: cannot stat 'debian/libperl5.36/usr/share/man/man1/perl.1': No such file or 
directory
mv: cannot stat 'debian/libperl5.36/usr/share/man/man1/cpan.1': No such file or 
directory
make[1]: *** [debian/rules:291: execute_after_dh_installman-arch] Error 1
make[1]: Leaving directory '/tmp/perl/perl-5.36.0'
make: *** [debian/rules:79: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: unable to detect

Versions of packages perl depends on:
ii  dpkg   1.21.22
ii  libperl5.365.36.0-7
ii  perl-base  5.36.0-7
ii  perl-modules-5.36  5.36.0-7

Versions of packages perl recommends:
ii  netbase  6.4

Versions of packages perl suggests:
pn  libtap-harness-archive-perl 
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.3-4.1
pn  perl-doc

-- no debconf information
--- perl-5.36.0/debian/rules
+++ perl-5.36.0/debian/rules
@@ -287,11 +287,13 @@
 endif
 
 execute_after_dh_installman-arch:
+ifeq (,$(filter nodoc, $(DEB_BUILD_PROFILES)))
# put version+arch -specific manpages in libperl5.xx
for prefix in perl cpan; do \
  mv debian/libperl$(version)/usr/share/man/man1/$$prefix.1 \
 
debian/libperl$(version)/usr/share/man/man1/$${prefix}$(version)-$(archtriplet).1;
 \
done
+endif
 
 override_dh_strip:
dh_strip --no-package=perl-debug --dbg-package=perl-debug

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

El martes, 6 de junio de 2023 02:40:09 -03 Erik Inkinen escribió:
> Hi Lisandro,
> 
> I think I misunderstood the Qt documentation myself. It seems the
> dynamic GLES support is only available on Windows, but the changes in
> qt6 rendering would still minimize the requirements for rebuilt
> packages.
> 
> It seems that it is only necessary to rebuild libqt6gui6 with
> "-DINPUT_opengl=es2". Maybe you could make a new source package for
> Qt6 Base on GLES and make it build libqt6gui6 and only it.
> 
> For reference, you can take a look at
> https://github.com/cutie-shell/qt6-base/tree/feature/bookworm/gles_minimal/debian
> . Note that you would need to use a different package name like
> libqt6gui6-gles and it should provide and conflict with libqt6gui6.

And at that point is where I'll personally say "no". I do not have enough free 
time to handle this, and that is in fact the reason I am maintaining Qt 6 
mostly as team member (I am not listed in Uploaders on purpose).

There are at least two options:

1. Jump in to maintain it yourself. I'll be _more_than_happy_ to help as time 
allows it.
2. Find/Hire someone to do it.

This is specially true if your company uses Debian as a base for the containers 
shipped in your products (Leonardo: hint, hint).

Kinds regards, Lisandro.

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

Bug#1032927: telegram-desktop: QT images management

[Stefano Callegari]

Il Mon, Jun 05, 2023 at 06:17:15PM +0200, To 1032...@bugs.debian.org scrisse:

I hoped but...

This morning, after power-on the PC, I have the same situation.

Upgraded again to last version.

Sorry.

Stefano

> Il Tue, Mar 14, 2023 at 09:42:12AM +0100, To Debian Bug Tracking System 
> scrisse:
> 
> Hi, 
> 
> today I've installed the telegram-desktop_4.5.3+ds-1+b1_amd64.deb, the last
> 4.5.*, and don't have any line in syslog.
> 
> When I've updated with telegram-desktop_4.6.0+ds-1_amd64.deb, the first
> 4.6.*, the syslog has filled of lines.
> 
> So the bug for me is in 4.6 releases.
> 
> Thanks
> 
> Stefano
> 
> > Package: telegram-desktop
> > Version: 4.6.5+ds-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > in my syslog I found a very lot of lines like these:
> > 
> > - when start
> >   2023-03-14T08:51:13.782218+01:00 G5045 telegram-desktop[43979]: qt.svg: 
> > Error
> > while inflating gzip file: SVG format check failed
> > 
> > - every time I focus it
> >   2023-03-14T08:51:31.392459+01:00 G5045 telegram-desktop[43979]:
> > QBuffer::seek: Invalid pos: 669743
> > 
> > Both messages are repeated for tens times in few seconds (the QBuffer with a
> > random number positive or negative).
> > 
> > Maybe the errors are related only with QT
> > (https://bugreports.qt.io/browse/QTBUG-45865), but in my system only 
> > Telegram
> > reports them.
> > 
> > Thanks
> > 
> > Stefano
> > 
> > 
> > -- Package-specific info:
> > 
> > -- System Information:
> > Debian Release: 12.0
> >   APT prefers unstable
> >   APT policy: (903, 'unstable'), (500, 'testing'), (400, 'stable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_US:it
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages telegram-desktop depends on:
> > ii  libabsl20220623   20220623.1-1
> > ii  libavcodec59  7:5.1.2-3
> > ii  libavformat59 7:5.1.2-3
> > ii  libavutil57   7:5.1.2-3
> > ii  libc6 2.36-8
> > ii  libgcc-s1 12.2.0-14
> > ii  libglib2.0-0  2.74.6-1
> > ii  libglibmm-2.68-1  2.74.0-2
> > ii  libhunspell-1.7-0 1.7.2+really1.7.1-2
> > ii  libjpeg62-turbo   1:2.1.5-2
> > ii  libkf5coreaddons5 5.103.0-1
> > ii  liblz4-1  1.9.4-1
> > ii  libminizip1   1.1-8+b1
> > ii  libopenal11:1.19.1-2
> > ii  libopus0  1.3.1-3
> > ii  libqrcodegencpp1  1.8.0-1.1
> > ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-3
> > ii  libqt5gui55.15.8+dfsg-3
> > ii  libqt5network55.15.8+dfsg-3
> > ii  libqt5qml55.15.8+dfsg-3
> > ii  libqt5quickwidgets5   5.15.8+dfsg-3
> > ii  libqt5svg55.15.8-2
> > ii  libqt5waylandcompositor5  5.15.8-2
> > ii  libqt5widgets55.15.8+dfsg-3
> > ii  librlottie0-1 0.1+dfsg-4
> > ii  libsigc++-3.0-0   3.4.0-1
> > ii  libssl3   3.0.8-1
> > ii  libstdc++612.2.0-14
> > ii  libswresample47:5.1.2-3
> > ii  libswscale6   7:5.1.2-3
> > ii  libvpx7   1.12.0-1
> > ii  libwayland-client01.21.0-1
> > ii  libx11-6  2:1.8.4-2
> > ii  libxcb-keysyms1   0.4.0-1+b2
> > ii  libxcb-record01.15-1
> > ii  libxcb-screensaver0   1.15-1
> > ii  libxcb1   1.15-1
> > ii  libxcomposite11:0.4.5-1
> > ii  libxdamage1   1:1.1.6-1
> > ii  libxext6  2:1.3.4-1+b1
> > ii  libxfixes31:6.0.0-2
> > ii  libxrandr22:1.5.2-2+b1
> > ii  libxtst6  2:1.2.3-1.1
> > ii  libxxhash00.8.1-1
> > ii  qt5-image-formats-plugins 5.15.8-2
> > ii  zlib1g1:1.2.13.dfsg-1
> > 
> > Versions of packages telegram-desktop recommends:
> > ii  fonts-open-sans   1.11-2
> > ii  libwebkit2gtk-4.0-37  2.38.5-1
> > ii  libwebkit2gtk-4.1-0   2.38.5-1
> > 
> > telegram-desktop suggests no packages.
> > 
> > Versions of packages telegram-desktop is related to:
> > ii  xdg-desktop-portal   1.16.0-2
> > ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
> > ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.2-1
> > 
> > -- no debconf 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 15:23:35 +0200 Bill Allombert ,
Luca Boccassi  wrote:
> On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > > The diversion system is made precisely to work around other
packages
> > behavior,
> > > this is a feature not a bug. That it should only be used as last
> > resort, I
> > > think everyone agree. But when it is, it should not be a RC bug.
> > 
> > This is a technical matter, I'm not sure what 'consensus' means in
this
> > context? Things _will not work_ as expected by shoe-horning dpkg's
> > overrides onto systemd mechanisms, they _will_ break in weird and
> > unexpected ways, and we as maintainers _will not support it_ -
whether
> > somebody else agrees or disagrees with this won't change any of it.
> 
> Consensus is the way the Debian Policy update process works.
> But you do not need changes in Policy to report bugs about package
that breaks
> others, there is the "grave" severity already.

That does not help, given currently policy allows it, without changes
they could just say "policy allows me, so go fix it yourself". What
then?

-- 
Kind regards,
Luca Boccassi


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

Bug#1037154: ITP: php-fig-log-test -- Test utilities for the psr/log package that backs the PSR-3 specification

[Athos Ribeiro]

Package: wnpp
Severity: wishlist
Owner: Athos Ribeiro 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: php-fig-log-test
  Version : 1.1.0
  Upstream Contact: Anton Ukhanev 
* URL : https://github.com/php-fig/log-test
* License : Expat
  Programming Lang: PHP
  Description : Test utilities for the psr/log package that backs the PSR-3 
specification

Provides a base test class for ensuring compliance with the LoggerInterface
(Psr\Log\Test\LoggerInterfaceTest) and a mock class for testing purposes
(Psr\Log\Test\TestLogger). This package should be used only for tests.

The upstream project for the php-psr-log package extracted the test and
mock classes that were once shipped within php-psr-log to a new project
(log-test) starting from php-psr-log  >= 2.0. Some packages may require
these classes for testing purposes and may FTBFS once php-psr-log 3.x
(now in experimental) is uploaded to unstable.

I have prepared an initial package at
https://salsa.debian.org/athos/php-fig-log-test

This should eventually be moved to salsa's php-team/pear
to be maintained by the php team.

This package Breaks/Replaces php-psr-log < 2 and requires
php-psr-log > 2. Therefore, it should be only uploaded to experimental for
now. Whenever php-psr-log 3 is uploaded to unstable, then this should also
be uploaded there.

I will need a sponsor for this one.

-- 
Athos Ribeiro

Bug#1037153: ITP: autothemer-el -- Emacs library that makes theme creation more convenient

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: block 905755 by -1

* Package name: autothemer-el
  Version : 0.2.17
  Upstream Author : Jason Milkins
* URL : https://github.com/jasonm23/autothemer
* License : GPL-3+
  Programming Lang: elisp
  Description : Emacs library that makes theme creation more convenient

 Autothemer is an Emacs library that makes theme creation more convenient; One
 way that it accomplishes this is by reducing the amount of boilerplate code
 needed to define custom themes.  It also provides the user with interactive
 commands that automatically generate face customisation code using the
 theme's colour palette—as well as other functions that assist with the
 creation of Emacs themes.
 .
 Notable features:
   * Automatic support for multiple display types (24bit, 256 colour, GUI and
 terminal).  Autothemes look good everywhere.
   * Easier configuration of dark and light theme variants.
   * Unified palette management.
   * Simplified face (text styles).
   * Autogeneration of missing specifications.
   * Completing-read-style colour selection using popup of a theme's palette.
   * SVG colour swatch generation, with labels.
   * Theme Variance Architecture (consult documentation for more information).
 .
 The following are some popular Emacs themes that use this autothemer:
 Gruvbox, Kaolin, Darktooth, and Soothe.

Autothemer is a new dependency of the Gruvbox theme for Emacs, and I
am in the process of investigating Autothemer, because I've found some
bugs in my custom theme and am looking for an easy and comprehensive
solution.  I am not aware of another Emacs lib like this one, and I
plan to maintain it on the Emacsen Team.

Comaintainers and mentees who would like to work on themes are both welcome!

Bug#1037152: uglifyjs: by default, emits code that is not compatible with webkit

[Jérémy Lal]

Package: uglifyjs
Version: 3.17.4-2
Severity: wishlist

Hi,

I just realized that uglifyjs --webkit flag needs to be passed to get
code that is compatible with several safari versions (up to 14 at least).

This is something users of this module might want to know, especially,
packages build-depending on it.

Jérémy


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

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

Versions of packages uglifyjs depends on:
ii  node-uglify-js  3.17.4-2
ii  nodejs  18.14.2+dfsg-1

uglifyjs recommends no packages.

Versions of packages uglifyjs suggests:
ii  node-acorn  8.8.1+ds+~cs25.17.7-2

-- no debconf information

Bug#1037116: Debian Edu bookworm not ready

[Mike Gabriel]

Hi Holger, hi all,

On  Mo 05 Jun 2023 10:04:44 CEST, Holger Levsen wrote:


package: release-notes
x-debbugs-cc: debian-...@lists.debian.org

hi,

maybe we should have a release notes entry stating that debian-edu bookworm
is not yet ready?!? :((

https://wiki.debian.org/DebianEdu/Status/Bookworm has the details what
needs doing.


sorry, I could not help with this in a sufficient timely manner. I'll  
see what I can do for Debian 12.1 and/or Debian 12.2. I definitely  
have an interest in seeing Debian Edu 12 becoming available and usable.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgprcY260TwEy.pgp
Description: Digitale PGP-Signatur

Bug#1037151: dbus: denial of service when a monitor is active and a message from the driver cannot be delivered

[Simon McVittie]

Package: dbus
Version: 1.15.4-1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 
Control: found -1 1.14.6-1
Control: found -1 1.12.24-0+deb11u1

If a privileged user with control over the dbus-daemon is using the
org.freedesktop.DBus.Monitoring interface to monitor message bus
traffic, then an unprivileged user with the ability to connect to the
same dbus-daemon can cause a dbus-daemon crash under some circumstances.

When done on the well-known system bus, this is a denial-of-service
vulnerability. Unfortunately, the upstream bug reporter already made
this public information. I'm in the process of releasing dbus 1.15.6,
1.14.8 and 1.12.28 to resolve this; I've also asked MITRE for a CVE ID,
but I have not received one yet.

Mitigation: This can only be done if a monitoring process such
as dbus-monitor or busctl monitor is active on the same dbus-daemon
instance, which is a privileged operation that can only be done by root
or the Unix uid of the message bus. If no monitoring process is active,
then the vulnerable code is not reached.

My guess is that the security team will not want to release DSAs for this
local denial of service, and it's more appropriate to fix in bookworm
and bullseye via their next point releases. Is that assumption correct?

Thanks,
smcv

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > The diversion system is made precisely to work around other packages
> behavior,
> > this is a feature not a bug. That it should only be used as last
> resort, I
> > think everyone agree. But when it is, it should not be a RC bug.
> 
> This is a technical matter, I'm not sure what 'consensus' means in this
> context? Things _will not work_ as expected by shoe-horning dpkg's
> overrides onto systemd mechanisms, they _will_ break in weird and
> unexpected ways, and we as maintainers _will not support it_ - whether
> somebody else agrees or disagrees with this won't change any of it.

Consensus is the way the Debian Policy update process works.
But you do not need changes in Policy to report bugs about package that breaks
others, there is the "grave" severity already.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Reimar Döffinger]

> On 6 Jun 2023, at 14:57, Lorenzo  wrote:
> 
> Thanks for looking at this again
> 
>> So maybe it is possible to get to work now, but probably separate
>> builds would remain the better approach. On the plus side, if FFmpeg
>> works, and since Debian links MPlayer to FFmpeg dynamically,
>> --disable-altivec should be all that is needed - assuming the
>> performance degradation on altivec enabled systems mentioned above is
>> considered acceptable.
> 
> Disable altivec for everyone doesn't seem a good compromise to me, I'm
> going to build twice on powerpc and let the user decide which one to use

To be clear: as MPlayer has no hand-written altivec, I I expect only a maybe 
5-10% or so degradation (pure guess), the most performance critical stuff in 
FFmpeg should not be affected.
So --disable-altivec is not obviously unacceptable, but I do think separate 
builds would be better, as 10% can matter on these systems.
(I am rather mystified how FFmpeg handles this, since as said the runtime check 
code does not look like it would actually work - if it does not work, a 
separate non-altivec MPlayer build will not help as it will still crash for 
~90% of media files, just in FFmpeg codecs now instead of MPlayer itself - is 
there a good way to test any of this?).

Bug#1037150: O: lpctools -- interface to NXP LPC Microcontrollers ISP serial interface

[Sophie Brun]

Package: wnpp
Severity: normal
X-Debbugs-Cc: lpcto...@packages.debian.org, sop...@freexian.com
Control: affects -1 + src:lpctools

I intend to orphan the lpctools package.


The package description is:
 LPCTools is an interface to NXP LPC Microcontrollers ISP (In-System
 Programming) serial interface.
 .
 It provides two programs:
 .
  * lpcisp: this tool gives access to each of the useful isp commands on LPC
devices. It does not provide wrappers for flashing a device.
  * lpcprog: this tool does not give access to each isp command, instead it
provides wrappers for flashing a device. This tool gives access to each of
the useful isp commands on LPC.

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

I've managed to reproduce the bug in virtual machines (even on my laptop), in 
case anyone is curious to see it in action.

The magic configuration is to force the CPU topology to 
multiple-sockets-multiple-cores (the default KVM config is typically 
multiple-socket-single-core). The CPU model doesn't appear to matter. The leak 
obviously grows much more slowly than on my 2-socket-20-core server, but it's 
clearly visible.

From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 12:44
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

I've managed to find a workaround. Not a great workaround, but it seems to let 
me take advantage of all cores for OMP without penalty. I'll be running some 
more tests on that.

The thread needs to call:

#include 
omp_pause_resource_all(omp_pause_soft);

at thread termination (a hard pause seens fine, too). The program needs to 
compiled with -fopenmp.

The call releases the TLS variables, and I believe that's what triggers the 
release of the memory mapped thread arena.

The downsides of that fix are (a) OMP doesn't get to share the thread pool 
across the program but instead blows it away for each thread the finishes, and 
(b) calling programs need to know stuff about the use of OMP at a level they 
really shouldn't need to know about.

It doesn't feel like something that can be shimmed into the GM API in a nice 
place, as IMHO there really isn't much other than Initialize/DestroyMagick() 
that should even care about crossing thread boundaries.

It's not entirely a new class of problem. For example, the issue that led me to 
trying the omp_pause_resource_all() call: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035

I still need to dig deeper as it's not clear to me why my particular machine is 
seeing the problem, but I certainly intend to follow up with gomp. I really 
hope it's a bug; a threading API that itself isn't thread-safe would just be... 
weird.

Bug#1037149: ITP: oauth2token -- oAuth2 token management for cli applications

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Severity: wishlist
Owner: Ying-Chun Liu (PaulLiu) 

* Package name: oauth2token
  Version : 0.0.3
  Upstream Author : VannTen 
* URL : https://github.com/VannTen/oauth2token
* License : GPL-3.0+
  Programming Lang: Python
  Description : oAuth2 token management for cli applications
 oauth2token is a simple cli tool to create and use oauth2 for some
 cli applications.

Binary package names: python3-oauth2token



OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037148: wdm: [INTL:tr] turkish translation of debconf messages

[Atila KOÇ]

Package: wdm
Version: N/A
Severity: wishlist
Tags: l10n patch

Hello,

Find attached the updated Turkish translation of the wdm debconf messages.
It has been submitted for review to the debian-l10n-turkish mailing list.

Regards,
Atila KOÇ
--- YASAL UYARI ---

# Turkish debconf translation of wdm
# This file is distributed under the same license as the wdm package.
# Recai Oktaş , 2004.
# Atila KOÇ , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: wdm\n"
"Report-Msgid-Bugs-To: w...@packages.debian.org\n"
"POT-Creation-Date: 2017-10-08 21:22+0200\n"
"PO-Revision-Date: 2023-04-28 10:12+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language-Team: Debian L10n Turkish \n"
"Language: tr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: select
#. Description
#: ../templates:1001
msgid "Desired default display manager."
msgstr "Yeğlenen öntanımlı ekran yöneticisi:"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"A display manager is a program that provides graphical login capabilities "
"for the X Window System."
msgstr ""
"Ekran yöneticisi programı, X Window Sistemi'ne görsel arayüz ile giriş yapma "
"yeteneği kazandırır."

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"Only one display manager can manage a given X server, but multiple display "
"manager packages are installed.  Please select which display manager should "
"run by default."
msgstr ""
"Sisteminizde birden fazla ekran yöneticisi kurulu durumda; ancak eldeki bir "
"X sunucusunu yalnızca bir ekran yöneticisi yönetebilir. Öntanımlı olarak "
"çalıştırılacak ekran yöneticisini seçin."

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"(Multiple display managers can run simultaneously if they are configured to "
"manage different servers; to achieve this, configure the display managers "
"accordingly, edit each of their init scripts in /etc/init.d, and disable the "
"check for a default display manager.)"
msgstr ""
"Farklı sunucuları yönetecek şekilde yapılandırılmaları koşulu ile birden "
"fazla ekran yöneticisi eş zamanlı çalışabilir. Bunu mümkün kılmak için; "
"ekran yöneticilerini buna göre yapılandırın, hepsinin /etc/init.d "
"dizinindeki başlangıç betiklerini değiştirin ve öntanımlı ekran yöneticisi "
"denetleme işlevini devre dışı bırakın."

Bug#1014124: nomacs: CVE-2020-23884

[andrew]

I think this should be filled against 
https://tracker.debian.org/pkg/qtimageformats-opensource-src


Explanation: 
https://github.com/nomacs/nomacs/issues/516#issuecomment-1578313635

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Lorenzo]

Thanks for looking at this again

On Mon, 5 Jun 2023 20:33:15 +0200 =?utf-8?Q?Reimar_D=C3=B6ffinger?=
 wrote:

> While it's still plenty messy, FFmpeg has runtime detection of
> altivec, and MPlayer itself has no altivec code itself. But I don't
> think it works, the problem is the compiler options:
> [ ... ]
> So maybe it is possible to get to work now, but probably separate
> builds would remain the better approach. On the plus side, if FFmpeg
> works, and since Debian links MPlayer to FFmpeg dynamically,
> --disable-altivec should be all that is needed - assuming the
> performance degradation on altivec enabled systems mentioned above is
> considered acceptable.

Disable altivec for everyone doesn't seem a good compromise to me, I'm
going to build twice on powerpc and let the user decide which one to use

Best,
Lorenzo

> 
> Best regards,
> Reimar
> 
> 
> 

Bug#1037147: gclcvs: fails to install on i386: Unrecoverable error: frame stack overflow.

[Andreas Beckmann]

Package: gclcvs
Version: 2.7.0-101
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: close -1 2.7.0-101+rm

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up gclcvs (2.7.0-101) ...
  Aborted (core dumped)
  Aborted (core dumped)
  gclcvs.sh Uninstalling clc image and purging object cache ...
  rm: cannot remove `Unrecoverable': Is a directory
  rm: cannot remove `error:': Is a directory
  rm: cannot remove `frame': Is a directory
  rm: cannot remove `stack': Is a directory
  rm: cannot remove `overflow.': Is a directory
  gclcvs.sh Installing clc as Unrecoverable error: frame stack overflow. ...
  basename: extra operand `frame'
  Try `basename --help' for more information.

  Unrecoverable error: frame stack overflow.
  Aborted (core dumped)
  Error building send-clc-command
  dpkg: error processing gclcvs (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   gclcvs
  configured to not write apport reports
  E: Sub-process /usr/bin/dpkg returned an error code (1)

After injecting set -x into gclcvs.postinst:

Setting up gclcvs (2.7.0-101) ...
+ CONFIGFILE=/etc/default/gclcvs
+ set -e
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/gclcvs.postinst configure
+ CONFIGFILE=/etc/default/gclcvs
+ set -e
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ [ configure = configure ]
+ [ ! -e /etc/default/gclcvs ]
+ db_get gclcvs/default_gcl_ansi
+ _db_cmd GET gclcvs/default_gcl_ansi
+ IFS=  printf %s\n GET gclcvs/default_gcl_ansi
+ IFS=
 read -r _db_internal_line
+ RET=
+ return 0
+ [  = true ]
+ DEFAULT_GCL_ANSI=
+ db_get gclcvs/default_gcl_prof
+ _db_cmd GET gclcvs/default_gcl_prof
+ IFS=  printf %s\n GET gclcvs/default_gcl_prof
+ IFS=
 read -r _db_internal_line
+ RET=
+ return 0
+ [  = true ]
+ DEFAULT_GCL_PROF=
+ cp -a -f /etc/default/gclcvs /etc/default/gclcvs.tmp
+ test -z
+ test -z
+ sed -e s/^ *DEFAULT_GCL_ANSI=.*/DEFAULT_GCL_ANSI=""/ -e s/^ 
*DEFAULT_GCL_PROF=.*/DEFAULT_GCL_PROF=""/
+ mv -f /etc/default/gclcvs.tmp /etc/default/gclcvs
+ [ -e /usr/lib/common-lisp/bin/gclcvs.sh ]
+ register-common-lisp-implementation gclcvs
Aborted (core dumped)
Aborted (core dumped)
gclcvs.sh Uninstalling clc image and purging object cache ...
rm: cannot remove `Unrecoverable': Is a directory
rm: cannot remove `error:': Is a directory
rm: cannot remove `frame': Is a directory
rm: cannot remove `stack': Is a directory
rm: cannot remove `overflow.': Is a directory
gclcvs.sh Installing clc as Unrecoverable error: frame stack overflow. ...
basename: extra operand `frame'
Try `basename --help' for more information.

Unrecoverable error: frame stack overflow.
Aborted (core dumped)
Error building send-clc-command
dpkg: error processing gclcvs (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 gclcvs


cheers,

Andreas


gclcvs_2.7.0-101.log.gz
Description: application/gzip

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Nightwalker-87]

Hi,

Microchip has updated it's official AVR-toolchain in May 2022 as well 
and provided related technical details.


https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers

Please (at least) port this version into the debian package sources ASAP.
Debian seems to have lost track with recent developments for this 
architecture, resulting in lacking support for newer devices.

This is deeply disappointing to see.

Nightwalker-87

Bug#1037031: gdb: std::length_error with tab-completion on Meson-built Rust program

[Héctor Orón Martínez]

found -1 13.2-1

Hello,

  I have been working on creating the gdb-13.2 package, however, I was
able to reproduce this issue.

Regars

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 14:03:41 +0200 Bill Allombert 
wrote:
> On Tue, Jun 06, 2023 at 12:16:39PM +0100, Luca Boccassi wrote:
> > > > local administrators and local packages to override the
behaviour of
> > > > Debian. Its use between Debian packages should be rare, should
involve
> > > > coordination between the packages and their maintainers, and
must only
> > > > be used to solve problems that cannot be handled through other
> > > > facilities or native mechanisms.  In other words, packages in
Debian
> > > > must not divert a file from another package unless this is
arranged
> > > > cooperatively between the packages to solve some specific and
unusual
> > > > problem.
> > >
> > > How about:
> > >
> > > Diversions and alternatives are primarily tools for local
> > > administrators and local packages to override Debian's
default
> > > behaviour.  Maintainers should prefer to use other, package-
specific
> > > facilities for overriding configuration, such as systemd's
unit file
> > > overrides, wherever possible.
> > >
> > > If diversions and alternatives are to be used, maintainers
should
> > > co-ordinate with the maintainers of all the packages
involved.  For
> > > example, configuration files used by systemd components
should not
> > > be diverted with dpkg-divert or the alternatives system
without
> > > agreement between not only the maintainers of the packages
that ship
> > > the files, but also the maintainers of the relevant systemd
> > > components.
> > 
> > As above, as long as this wording makes any offending package
> > rc-buggy, it's fine by me, but my understanding is that using
'should'
> > doesn't guarantee that. Please correct me if I'm wrong here.
> 
> I do not think there is consensus that this should be a RC bug
outside of
> a case by case basis. It is already awkward to mention systemd
explicitly
> in this paragraph.
> 
> The diversion system is made precisely to work around other packages
behavior,
> this is a feature not a bug. That it should only be used as last
resort, I
> think everyone agree. But when it is, it should not be a RC bug.

This is a technical matter, I'm not sure what 'consensus' means in this
context? Things _will not work_ as expected by shoe-horning dpkg's
overrides onto systemd mechanisms, they _will_ break in weird and
unexpected ways, and we as maintainers _will not support it_ - whether
somebody else agrees or disagrees with this won't change any of it.

It means that, when such bug happens, and it turns out there's a
divert/override in the way, the bug will be an immediate close+wontfix
and the reporter will be told they are on their own. And that's a best
case scenario where it is all apparent, while actually it's more likely
this will be hidden away and require a large waste of time to figure
out. Isn't it better to ensure this cannot happen in the first place?
Once more: there are no such cases as of bookworm in the archive, so
the impact today is nil. Wouldn't it be prudent to ensure it stays that
way in the strictest possible terms?

-- 
Kind regards,
Luca Boccassi


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

Bug#1037146: Booting signed kernel fails because no kernel module can be loaded due to key was rejected by service

[Mayer, Dirk]

Source: linux-signed-amd64

Version: 6.1.27+1

Tags: bookworm


I would like to build the kernel from source and sign it including its 
corresponding modules. Booting my own built and signed kernel fails, and I end 
up in an emergency shell.
If I Install and boot the unsigned kernel, the system starts up fine.
However, booting the signed kernel fails and I end up in the initrd. This is 
because none of the kernel modules can be loaded and therefore the disk where 
Debian is installed is unknown to the system.
Not even a usb keyboard works, I needed to use a legacy ps2 one to get some 
insights.
Loading any of the kernel modules always fails with the same error message:

modprobe - fan
modprobe: INFO: custom logging function 0x40917d registered
insmod /lib/modules/6.1.0-9-amd64/kernel/drivers/acpi/fan.ko
modprobe: INFO: Failed to insert module 
'/lib/modules/6.1.0-9-amd64/kernel/drivers/acpi/fan.ko': Key was rejected by 
service
modprobe: ERROR: could not insert 'fan`: Key was rejected by service
modprobe: INFO: context 0x1c4f440 released

We can replace the fan module with any other module, it is always the same 
error message.
Forcing modprobe manually actually works: modprobe -f fan

modinfo looks like that:
# modinfo fan
filename: /lib/modules/6.1.0-9-amd64/kernel/drivers/acpi/fan.ko
license: GPL
description: ACPI Fan Driver
author: Paul Diefenbaugh
license: GPL
alias: acpi*:PNPOCOB:*
alias: acpi*:INTC10A2:*
alias: acpi*: INTC1063:*
alias: acpi*: INtC1048:*
alias: acpi*:INTC1044:*
alias: acpi*:INT3404:*
depends:
retpoline: Y
intree: Y
name: fan
vermagic : 6.1.0-9-amd64 SMP preempt mod_unload moduersions
sig_id: PKCS#7
signer:
sig_key:
sig_hashalgo: unknown
signature:

# md5sum /lib/modules/6.1.0-9-amd64/kernel/drivers/acpi/fan.ko
af98363b3cab1252f8639c666b090cd9 
/lib/modules/6.1.0-9-amd64/kernel/drivers/acpi/fan.ko

Worth to mention here is, that the modinfo command built-in the busybox 
emergency shell seems to have limited capabilities as the signature part here 
is not populated.
I extracted the module from the initrd and executed a modinfo from a proper 
running system:

# modinfo /tmp/fan.ko
filename:   /tmp/fan.ko
license:GPL
description:ACPI Fan Driver
author: Paul Diefenbaugh
license:GPL
alias:  acpi*:PNP0C0B:*
alias:  acpi*:INTC10A2:*
alias:  acpi*:INTC1063:*
alias:  acpi*:INTC1048:*
alias:  acpi*:INTC1044:*
alias:  acpi*:INT3404:*
depends:
retpoline:  Y
intree: Y
name:   fan
vermagic:   6.1.0-9-amd64 SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Debian Secure Boot CA
sig_key:32:A0:28:7F:84:1A:03:6F:A3:93:C1:E0:65:C4:3A:E6:B2:42:26:43
sig_hashalgo:   sha256
signature:  6F:E8:2C:A1:A8:49:4F:A6:61:83:06:3C:1B:03:6B:EE:84:BB:63:AD:
38:DF:E0:E3:65:1E:02:DC:DE:9E:B4:2A:36:2F:27:E2:15:C2:ED:84:
B9:A8:AE:0E:EC:A5:15:31:2E:A1:68:1F:F8:92:B9:7B:8F:4A:5D:B4:
C4:5C:37:2C:BC:F6:D8:09:98:2F:3F:47:CF:0F:49:06:C4:13:F5:72:
D8:42:BC:90:16:99:94:B8:51:56:52:C8:34:20:F2:10:C5:F1:A9:A2:
B1:5B:16:5D:9B:23:9B:42:24:6F:D1:1A:4B:C6:46:7D:74:3B:68:C4:
16:0F:18:23:52:5D:5D:F2:41:D5:26:E8:E9:F1:E0:5E:D2:0E:0A:B9:
0D:25:1F:C6:11:5F:2D:23:DE:45:7E:03:02:8D:7C:40:81:CE:83:9E:
9F:14:F6:EE:BC:50:63:D9:3B:DD:3C:5A:C0:13:4F:D4:52:51:ED:B1:
99:3A:90:09:51:D9:96:57:65:2F:31:77:36:B3:86:9D:A1:37:DC:24:
7E:AD:0F:F2:18:D1:6D:60:C0:12:30:F6:E3:D6:20:40:6F:C6:48:FF:
AF:2F:B8:76:B6:25:32:57:34:C9:F0:84:7A:09:5F:3A:3F:C4:6E:2D:
   FE:85:FC:F5:F1:D1:B9:8A:70:34:52:8A:1A:40:A0:4C
# md5sum /tmp/fan.ko
af98363b3cab1252f8639c666b090cd9  /tmp/fan.ko


The build environment for the kernel and the signed-kernel was a container 
debian:slim-bookworm with all necessary build dependencies installed.
No sources have been changed. It is 100% Debian source code which is compiled 
here.
At first I compiled the unsigned kernel and put the debs in a local repository.
That local repo was then added to the apt sources.list to ensure that the 
following build of the signed kernel would pull my own debs and use these as 
build deps for the signing process.

# apt update
# apt upgrade
# apt install dpkg-dev devscripts
# apt-get source --only-source linux
# cd linux-6.1.27/
# apt-get build-dep --only-source -y linux
# debuild -F -uc -us
# ls -alh
total 2.6G
drwxr-xr-x  3 1000 1000  4.0K Jun  6 09:40 .
drwxr-xr-x  1 root root  4.0K Jun  6 07:09 ..
-rw-r--r--  1 root root  815K Jun  6 09:30 
bpftool-dbgsym_7.1.0+6.1.27-1_amd64.deb
-rw-r--r--  1 root root  862K Jun  6 09:30 bpftool_7.1.0+6.1.27-1_amd64.deb
-rw-r--r--  1 root root   48K Jun  6 09:31 
hyperv-daemons-dbgsym_6.1.27-1_amd64.deb
-rw-r--r--  1 root root  633K Jun  6 09:31 hyperv-daemons_6.1.27-1_amd64.deb
-rw-r--r--  1 root root  618K Jun  6 09:31 

Bug#1036899: logiops: logid does not work for MX Master 3

[Hendrik Tews]

Hi,

On 2023-06-05 10:22:35, Chow Loong Jin  wrote:

> Could you check if 0.3.1-1 (in unstable) or 0.3.2-1 (in experimental) is
> working for you?

thanks for following up. Both 0.3.1-2 from unstable and 0.3.2-1 from
experimental work. (Unexpected to me, because I reproduced the problem
with the newest upstream version.)

Version 0.3.1-1 is the version from testing, this version does not
work.

Hendrik

Bug#1037145: rtw88_8822ce: connection is very unstable

[Giulio Paci]

Package: src:linux
Version: 6.1.27-1
Severity: important
X-Debbugs-Cc: giuliop...@gmail.com



-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=619d22b9-2257-43b7-9995-1c48e5e89e07 ro reboot=bios

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   18.660669] Key type cifs.idmap registered
[   18.661602] CIFS: No dialect specified on mount. Default has changed to a 
more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use 
the less secure SMB1 dialect to access old servers which do not support 
SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[   18.661714] CIFS: Attempting to mount \\secondary.scanner.local\scanner
[   18.677837] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for 
information.
[   18.678552] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld 
. All Rights Reserved.
[   22.081135] pcieport :00:1d.1: AER: Uncorrected (Non-Fatal) error 
received: :03:00.0
[   22.086224] rtw_8822ce :03:00.0: PCIe Bus Error: severity=Uncorrected 
(Non-Fatal), type=Transaction Layer, (Requester ID)
[   22.088074] rtw_8822ce :03:00.0:   device [10ec:c822] error 
status/mask=4000/0040
[   22.089135] rtw_8822ce :03:00.0:[14] CmpltTO(First)
[   22.090186] rtw_8822ce :03:00.0: AER: can't recover (no error_detected 
callback)
[   22.091271] pcieport :00:1d.1: AER: device recovery failed
[   24.812780] CIFS: VFS: Error connecting to socket. Aborting operation.
[   24.815065] CIFS: VFS: cifs_mount failed w/return code = -113
[   24.817289] CIFS: Attempting to mount \\primary.scanner.local\scanner
[   24.867761] process '/usr/bin/anydesk' started with executable stack
[   25.470440] Bluetooth: RFCOMM TTY layer initialized
[   25.470449] Bluetooth: RFCOMM socket layer initialized
[   25.470468] Bluetooth: RFCOMM ver 1.11
[   30.956641] CIFS: VFS: Error connecting to socket. Aborting operation.
[   30.956679] CIFS: VFS: cifs_mount failed w/return code = -113
[   30.956821] CIFS: Attempting to mount \\tertiary.scanner.local\scanner
[   37.100840] CIFS: VFS: Error connecting to socket. Aborting operation.
[   37.100896] CIFS: VFS: cifs_mount failed w/return code = -113
[  328.416330] rtw_8822ce :03:00.0: firmware failed to report density after 
scan
[  328.972253] rtw_8822ce :03:00.0: failed to get tx report from firmware
[  333.021395] wlo1: authenticate with 1c:5f:2b:cb:90:7c
[  333.344403] wlo1: send auth to 1c:5f:2b:cb:90:7c (try 1/3)
[  333.354471] wlo1: authenticated
[  333.356201] wlo1: associate with 1c:5f:2b:cb:90:7c (try 1/3)
[  333.364348] wlo1: RX AssocResp from 1c:5f:2b:cb:90:7c (capab=0x431 status=0 
aid=1)
[  333.364726] wlo1: associated
[  335.003129] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65455 DF PROTO=UDP 
SPT=37340 DPT=50001 LEN=173 
[  335.004543] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65456 DF PROTO=UDP 
SPT=54049 DPT=50002 LEN=173 
[  335.005539] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65457 DF PROTO=UDP 
SPT=42322 DPT=50003 LEN=173 
[  337.009984] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65474 DF PROTO=UDP 
SPT=52551 DPT=50001 LEN=173 
[  337.011616] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65475 DF PROTO=UDP 
SPT=60442 DPT=50002 LEN=173 
[  337.013004] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=65476 DF PROTO=UDP 
SPT=51910 DPT=50003 LEN=173 
[  338.016468] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=140 DF PROTO=UDP 
SPT=52128 DPT=50001 LEN=173 
[  338.018238] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=141 DF PROTO=UDP 
SPT=35654 DPT=50002 LEN=173 
[  338.019507] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=142 DF PROTO=UDP 
SPT=43360 DPT=50003 LEN=173 
[  339.022375] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=192.168.0.50 
DST=239.255.102.18 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=152 DF PROTO=UDP 
SPT=57966 DPT=50001 LEN=173 
[  653.065118] [UFW BLOCK] IN=wlo1 OUT= 
MAC=01:00:5e:00:00:01:1c:5f:2b:cb:90:7c:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 
TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
[  778.506336] [UFW BLOCK] IN=wlo1 OUT= 
MAC=01:00:5e:00:00:01:1c:5f:2b:cb:90:7c:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 
TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
[  903.952679] [UFW BLOCK] IN=wlo1 OUT= 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 12:16:39PM +0100, Luca Boccassi wrote:
> > > local administrators and local packages to override the behaviour of
> > > Debian. Its use between Debian packages should be rare, should involve
> > > coordination between the packages and their maintainers, and must only
> > > be used to solve problems that cannot be handled through other
> > > facilities or native mechanisms.  In other words, packages in Debian
> > > must not divert a file from another package unless this is arranged
> > > cooperatively between the packages to solve some specific and unusual
> > > problem.
> >
> > How about:
> >
> > Diversions and alternatives are primarily tools for local
> > administrators and local packages to override Debian's default
> > behaviour.  Maintainers should prefer to use other, package-specific
> > facilities for overriding configuration, such as systemd's unit file
> > overrides, wherever possible.
> >
> > If diversions and alternatives are to be used, maintainers should
> > co-ordinate with the maintainers of all the packages involved.  For
> > example, configuration files used by systemd components should not
> > be diverted with dpkg-divert or the alternatives system without
> > agreement between not only the maintainers of the packages that ship
> > the files, but also the maintainers of the relevant systemd
> > components.
> 
> As above, as long as this wording makes any offending package
> rc-buggy, it's fine by me, but my understanding is that using 'should'
> doesn't guarantee that. Please correct me if I'm wrong here.

I do not think there is consensus that this should be a RC bug outside of
a case by case basis. It is already awkward to mention systemd explicitly
in this paragraph.

The diversion system is made precisely to work around other packages behavior,
this is a feature not a bug. That it should only be used as last resort, I
think everyone agree. But when it is, it should not be a RC bug.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Tue, 6 Jun 2023 11:58:07 +0100 Simon McVittie 
wrote:
> On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> > On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > > Another possible mitigation which I haven't previously seen
proposed
> > > is giving *elogind* a Depends or Recommends on systemd-*-
standalone.
> > > I think that would work to mitigate the failure mode with (1.)
and (B.),
> > > and the installed-size argument seems less interesting here
because the
> > > sort of systems that require elogind are already much larger
anyway.
> > > Would the elogind maintainers be willing to consider this? Does
anyone
> > > see a reason why it wouldn't work?
> > 
> > So to confirm, you think that if the elogind maintainers did this,
then
> > default-systemd-tmpfiles could point at systemd rather than
> > systemd-standalone-tmpfiles, which the systemd maintainers prefer,
but
> > in addition, there aren't any scenarios in which people's systems
are
> > likely to be re-arranged when they don't want them to be?
> 
> Exactly. My hope is that if we had:
> 
> Package: systemd
> Architecture: linux-any
> Provides: default-systemd-tmpfiles, systemd-tmpfiles
> Conflicts: systemd-tmpfiles
> Replaces: systemd-tmpfiles
> 
> Package: systemd-standalone-tmpfiles
> Architecture: linux-any
> Provides: systemd-tmpfiles
> Conflicts: systemd-tmpfiles
> Replaces: systemd-tmpfiles
> 
> Package: elogind
> Depends: systemd-standalone-tmpfiles    # or Recommends?
> 
> Package: foo-service # any package that requires
tmpfiles.d(5)
> Depends: default-systemd-tmpfiles | systemd-tmpfiles
> 
> # optionally, if someone does the work
> Package: openrc-tmpfiles    # any other
implementation
> Architecture: hurd-any kfreebsd-any
> Provides: default-systemd-tmpfiles, systemd-tmpfiles
> Conflicts: systemd-tmpfiles
> Replaces: systemd-tmpfiles
> 
> then the right thing (or at least *a* right thing) would happen in
> all cases:
> 
> * install foo-service on a systemd-booted system:
>   systemd is already installed and the dependency is satisfied
> 
> * install foo-service on a sysvinit-booted desktop system with
elogind:
>   elogind is already installed, therefore systemd-standalone-tmpfiles
is
>   already installed and the dependency is satisfied, avoiding
#1016006 etc.
> 
> * install foo-service on a sysvinit-booted headless system with no
elogind:
>   systemd gets installed as a dependency by default, which is what
the
>   systemd maintainers would prefer to happen when there are no
compelling
>   space constraints; but the user can specifically ask for
>   systemd-standalone-tmpfiles if that's what they'd prefer
> 
> * install foo-service in a container with no init system at all:

Sounds like a good plan to me.

-- 
Kind regards,
Luca Boccassi


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

Bug#1037144: release-notes: bookworm add #1037142 into section 5.4 regarding AMD 7900XTX GPU issues with kernel 6.1

[AAF]

Package: release-notes
Severity: important
X-Debbugs-Cc: and...@posteo.net

Dear Maintainer,

Please add bug #1037142 in the "5.4 Known severe bugs" section for the Debian
Bookworm release.

The bug describes several issues observed specific to kernel 6.1 and
having an AMD 7900XTX/XT GPU.

Thanks.
Andrei

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 at 12:25, Dominik George  wrote:
>
> > The whole project is moving toward git and Salsa
>
> Sorry for the noise, but as you are clearly misattributing this to me (I am 
> part of the project, so "the whole project" includes me):
>
> I am not, and do not want to, move bugs and patches to Git and Salsa. I 
> consider it a huge advantage of Debian that I can contribute limitless with 
> something as barrierfree as an e-mail.
>
> If you voice your opinion, please do not impose it on me. Thanks!

Ok, how about: "the whole project, minus naturesha...@debian.org who
appears to be unfamiliar with the concept of hyperboles, is moving
toward git and Salsa". Better?

Snarks aside, allowing merge requests to be open on Salsa in
_addition_ to attachments to the BTS, as the vast majority of other
packages already do, doesn't take away anything from you, but would
add quite a lot for the rest of us, who find ourselves very limited
and very much barrier-ized by clunky, old and painful email-based
processes.

Kind regards,
Luca Boccassi

Bug#1037143: netcat-openbsd: nc -t should quote IAC (i.e. '\xff')

[Uwe Kleine-König]

Package: netcat-openbsd
Version: 1.219-1
Severity: normal
X-Debbugs-Cc: uklei...@debian.org

Hello,

if netcat is talking to a remote peer that implements a telnet-like
protocol (e.g. rfc2217 in my case), IAC should be quoted. That is

printf '01234\xff\xfb\x015678' | nc -t ::1 12345

should actually send

01234\xff\xff\xfb\x015678

because otherwise the stream is interpreted on the other side as a
command. On the receiving side the matching unquoting should happen.

(Look at the effect if the other side happens to be

nc -t -l :: 12345

. The problem is that nc assumes it never sent a WILL request and so
should safely reply to the DONT reply with a WONT. The fix is to quote
the IAC such that the assumption "nc never sent a WILL request" becomes
true. See https://www.rfc-editor.org/rfc/rfc854, GENERAL CONSIDERATIONS
for more details.)

Best regards
Uwe

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Dominik George]

> The whole project is moving toward git and Salsa

Sorry for the noise, but as you are clearly misattributing this to me (I am 
part of the project, so "the whole project" includes me):

I am not, and do not want to, move bugs and patches to Git and Salsa. I 
consider it a huge advantage of Debian that I can contribute limitless with 
something as barrierfree as an e-mail.

If you voice your opinion, please do not impose it on me. Thanks!

-nik

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 at 11:58, Sean Whitton  wrote:
>
> Hello,
>
> On Mon 05 Jun 2023 at 12:59AM +01, Luca Boccassi wrote:
>
> > On Sun, 4 Jun 2023 19:39:49 +0200 Bill Allombert 
> > wrote:
> >> On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
> >> > If you prefer, I can reword the general rule to be stricter, ie:
> >> > "packages must not use diversions where native mechanisms are
> >> > available" or so. Would this be better?
> >>
> >> "native mechanisms" seems to vague.
> >
> > Well, I originally had written precisely what I meant, but was told on
> > this thread to "add normative language for only the general case"
> > instead, so I've done that. That's always going to sound vague. I
> > cannot do both at the same time.
> >
> > As you can see from the latest revision, right now the rule is general
> > but it's immediately followed by a very concrete and documented
> > example. Open to precise suggestions on how to improve it.
>
> I think what's a bit peculiar here is using "must" for a case where
> there might be package-specific exceptions.  In other cases, Policy uses
> "should" for these cases.  Typically "must" rules are simple and
> completely determinate.
>
> Maintainers do take our "should"s seriously -- let's use that here.
> It can always be strengthened later.

My understanding is that "should" is effectively optional, ie: it is
not enough to make a package rc-buggy, and while they are generally
followed, there is no actual hard requirement to do so. That is not
enough for me and for this use case. So again my goal here is to make
an hypothetical future dpkg-divert or alternative of a unit file
(wherever it is shipped from) instantly and unambiguously rc-buggy,
with no leeway (again there are no longer any such cases in the
archive as of bookworm, so nothing is affected). If you can suggest an
alternative appropriate wording that can achieve the same effect, that
would be fine to me - I don't mind how it's written, as long as it
meets this requirement.

> > Diversions and alternatives should be used primarily as a tool for
> > local administrators and local packages to override the behaviour of
> > Debian. Its use between Debian packages should be rare, should involve
> > coordination between the packages and their maintainers, and must only
> > be used to solve problems that cannot be handled through other
> > facilities or native mechanisms.  In other words, packages in Debian
> > must not divert a file from another package unless this is arranged
> > cooperatively between the packages to solve some specific and unusual
> > problem.
>
> How about:
>
> Diversions and alternatives are primarily tools for local
> administrators and local packages to override Debian's default
> behaviour.  Maintainers should prefer to use other, package-specific
> facilities for overriding configuration, such as systemd's unit file
> overrides, wherever possible.
>
> If diversions and alternatives are to be used, maintainers should
> co-ordinate with the maintainers of all the packages involved.  For
> example, configuration files used by systemd components should not
> be diverted with dpkg-divert or the alternatives system without
> agreement between not only the maintainers of the packages that ship
> the files, but also the maintainers of the relevant systemd
> components.

As above, as long as this wording makes any offending package
rc-buggy, it's fine by me, but my understanding is that using 'should'
doesn't guarantee that. Please correct me if I'm wrong here.

> I would also like to suggest "their own mechanisms for overriding parts
> of configuration" over "native overriding mechanisms" in the appendices.

Sure that sounds good.

Kind regards,
Luca Boccassi

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Simon McVittie]

On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > Another possible mitigation which I haven't previously seen proposed
> > is giving *elogind* a Depends or Recommends on systemd-*-standalone.
> > I think that would work to mitigate the failure mode with (1.) and (B.),
> > and the installed-size argument seems less interesting here because the
> > sort of systems that require elogind are already much larger anyway.
> > Would the elogind maintainers be willing to consider this? Does anyone
> > see a reason why it wouldn't work?
> 
> So to confirm, you think that if the elogind maintainers did this, then
> default-systemd-tmpfiles could point at systemd rather than
> systemd-standalone-tmpfiles, which the systemd maintainers prefer, but
> in addition, there aren't any scenarios in which people's systems are
> likely to be re-arranged when they don't want them to be?

Exactly. My hope is that if we had:

Package: systemd
Architecture: linux-any
Provides: default-systemd-tmpfiles, systemd-tmpfiles
Conflicts: systemd-tmpfiles
Replaces: systemd-tmpfiles

Package: systemd-standalone-tmpfiles
Architecture: linux-any
Provides: systemd-tmpfiles
Conflicts: systemd-tmpfiles
Replaces: systemd-tmpfiles

Package: elogind
Depends: systemd-standalone-tmpfiles# or Recommends?

Package: foo-service # any package that requires tmpfiles.d(5)
Depends: default-systemd-tmpfiles | systemd-tmpfiles

# optionally, if someone does the work
Package: openrc-tmpfiles# any other implementation
Architecture: hurd-any kfreebsd-any
Provides: default-systemd-tmpfiles, systemd-tmpfiles
Conflicts: systemd-tmpfiles
Replaces: systemd-tmpfiles

then the right thing (or at least *a* right thing) would happen in
all cases:

* install foo-service on a systemd-booted system:
  systemd is already installed and the dependency is satisfied

* install foo-service on a sysvinit-booted desktop system with elogind:
  elogind is already installed, therefore systemd-standalone-tmpfiles is
  already installed and the dependency is satisfied, avoiding #1016006 etc.

* install foo-service on a sysvinit-booted headless system with no elogind:
  systemd gets installed as a dependency by default, which is what the
  systemd maintainers would prefer to happen when there are no compelling
  space constraints; but the user can specifically ask for
  systemd-standalone-tmpfiles if that's what they'd prefer

* install foo-service in a container with no init system at all:
  systemd gets installed as a dependency by default, which is what the
  systemd maintainers would prefer to happen when there are no compelling
  space constraints; but the user can specifically ask for
  systemd-standalone-tmpfiles if that's what they'd prefer

* (optionally) install foo-service on hurd-i386:
  openrc-tmpfiles (or whatever) gets installed as a dependency

smcv

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello,

On Tue 06 Jun 2023 at 11:51AM +01, Luca Boccassi wrote:

> Well, the README says:
>
> "Please submit a bug to the BTS, either with patches attached, or a
> reference to a git branch that is publically fetchable."
>
> The whole project is moving toward git and Salsa,

Git, certainly, but not all of us love Salsa.

> and it is very annoying to have to do drive-by contributions via
> email, it really sucks as a process for contributors, so please
> consider re-evaluating this in the future. Patch attached.

You are very fast!
I just posted another message with some wording review.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello,

On Mon 05 Jun 2023 at 12:59AM +01, Luca Boccassi wrote:

> On Sun, 4 Jun 2023 19:39:49 +0200 Bill Allombert 
> wrote:
>> On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
>> > If you prefer, I can reword the general rule to be stricter, ie:
>> > "packages must not use diversions where native mechanisms are
>> > available" or so. Would this be better?
>>
>> "native mechanisms" seems to vague.
>
> Well, I originally had written precisely what I meant, but was told on
> this thread to "add normative language for only the general case"
> instead, so I've done that. That's always going to sound vague. I
> cannot do both at the same time.
>
> As you can see from the latest revision, right now the rule is general
> but it's immediately followed by a very concrete and documented
> example. Open to precise suggestions on how to improve it.

I think what's a bit peculiar here is using "must" for a case where
there might be package-specific exceptions.  In other cases, Policy uses
"should" for these cases.  Typically "must" rules are simple and
completely determinate.

Maintainers do take our "should"s seriously -- let's use that here.
It can always be strengthened later.

> Diversions and alternatives should be used primarily as a tool for
> local administrators and local packages to override the behaviour of
> Debian. Its use between Debian packages should be rare, should involve
> coordination between the packages and their maintainers, and must only
> be used to solve problems that cannot be handled through other
> facilities or native mechanisms.  In other words, packages in Debian
> must not divert a file from another package unless this is arranged
> cooperatively between the packages to solve some specific and unusual
> problem.

How about:

Diversions and alternatives are primarily tools for local
administrators and local packages to override Debian's default
behaviour.  Maintainers should prefer to use other, package-specific
facilities for overriding configuration, such as systemd's unit file
overrides, wherever possible.

If diversions and alternatives are to be used, maintainers should
co-ordinate with the maintainers of all the packages involved.  For
example, configuration files used by systemd components should not
be diverted with dpkg-divert or the alternatives system without
agreement between not only the maintainers of the packages that ship
the files, but also the maintainers of the relevant systemd
components.

I would also like to suggest "their own mechanisms for overriding parts
of configuration" over "native overriding mechanisms" in the appendices.

-- 
Sean Whitton


signature.asc
Description: PGP signature