Bug#1017965: telegram-desktop: ftbfs on riscv64 ("undefined reference to `__atomic_compare_exchange_1'")

[Nicholas Guriev]

Control: tag -1 pending

Hello!

On 23.08.2022 04:13:45 MSK you wrote:
> /usr/bin/ld: 
> ../../../lib_crl/CMakeFiles/lib_crl.dir/crl/common/crl_common_queue.cpp.o: in 
> function `std::__atomic_base::compare_exchange_strong(bool&, bool, 
> std::memory_order, std::memory_order)':
> /usr/include/c++/12/bits/atomic_base.h:560: undefined reference to 
> `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> ../../../lib_crl/CMakeFiles/lib_crl.dir/crl/crl_object_on_thread.cpp.o: in 
> function `std::unique_lock::unlock()':
> /usr/include/c++/12/bits/unique_lock.h:193: undefined reference to 
> `__atomic_compare_exchange_1'
> collect2: error: ld returned 1 exit status
> make[3]: *** 
> [Telegram/codegen/codegen/style/CMakeFiles/codegen_style.dir/build.make:268: 
> Telegram/codegen/codegen/style/codegen_style] Error 1

I have written a patch replacing std::atomic with std::atomic_flag that
guaranteed does not require locks and libatomic. This fixes the linking error
in code generators. On final linking, we already have the -latomic flag from
abseil, so it's working for now.

https://salsa.debian.org/debian/telegram-desktop/-/commit/20b50dee4c3f84dcb0385eeac9b538b2fd050546


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

Bug#1020301: mariadb-server-10.3: postinst called with unknown argument 'triggered'

[Tuukka Pasanen]

Upstream MariaDB tracking bug for this is: MDEV-29584 
(https://jira.mariadb.org/browse/MDEV-29584).


--
Tuukka Pasanen
Production Manager
tuukka.pasa...@ilmi.fi
+358 40 7303 216

Bug#999458: zynaddsubfx

[calistonicolas]

Hello

I would like to know if a new GUI will appear for  this program  . 

Thanks 

Nico


ATTENTION : changement d'adresse mail, veuillez me joindre désormais à 
calistonico...@tutanota.com

Bug#1020290: init-system-helpers depends on usrmerge | usr-is-merged

[Helmut Grohne]

Hi Craig,

Speaking with a CTTE hat.

On Wed, Sep 21, 2022 at 10:41:18AM +1000, Craig Sanders wrote:
> Stop closing this bug without fixing it.

The change you are objecting to was planned and presented to various
teams in Debian including the technical committee and the release team.
The change is implementing a technical committee decision and has been
agreed to by the technical committee and the release team. You should be
able to find the rationale in the relevant technical committee bug
reports. If you want to change this, please file your objection with the
technical committee or start a GR instead of reopening this bug over and
over again.

> It is breaking upgrades and dist-upgrades etc.

As others have pointed out, this is breaking on your side, because
usrmerge is somehow prevented from being installable. Please figure out
why that happens. I suppose the most likely cause would be use of
dpkg-fsys-usrunmess. Refer to the new faq entry at
https://wiki.debian.org/UsrMerge on how to revert that.

Helmut

Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures

[fabian]

Hi Markus,

could you please check if replacing the OTF versions of the fonts with 
the TTF ones fixes the issue for you?


https://github.com/ArtifexSoftware/urw-base35-fonts/issues/31#issuecomment-1168348674

Thanks!

 - Fabian

Bug#975631: debian-policy: window manager: remove reference to Debian menu

[Russ Allbery]

Russ Allbery  writes:

> I considered whether instead of starting with a priority of 40, we
> should instead bump the priority if the window manager supports the
> desktop specification, but I think this is a place where the structure
> of X environments has changed over the years.  It used to be that the
> window manager was what handled application menus, but now that's
> normally done by some other component of the desktop environment, or
> even just some toolbar app or other type of plugin that the user has
> chosen, and the window manager may be just a window manager.

> Given that, I don't think there's anything useful we can say here about
> menu management.  Old-school window managers that don't use a desktop
> environment (fvwm2, for instance) may implement support for desktop
> files, or for the Debian menu system for that matter; newer ones are
> likely to not handle menus at all and expect some other component to
> deal with that.

I just found https://bugs.debian.org/838777, which says packages that only
provide a window manager without a mechanism for launching programs should
not register as x-window-manager.  So I'm now not sure that just removing
the mention of the menu system is a complete fix and we may indeed need to
say something about handling *.desktop files, because x-window-manager may
really supposed to be a desktop environment.

I think we can keep this change in the next release because it doesn't
make anything worse, but we should probably also pursue #838777 and try to
document what x-window-manager is really for in the new X world.  (This is
almost certainly going to require advice from the folks who work on
desktop environments, since I have no idea how x-window-manager is used
today.)

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

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Rene Engelhard]

Hi,

[ your HTML mails make quoting hard... ]

Thanks for filing the report.

Am Tue, Sep 20, 2022 at 01:31:14PM -0700 schrieb Soren Stoutner:
> Another option would be to create a separate binary package (for example, 
> qtwebengine-dict-en-us). 

Name makes sense to me, yes.

> The argument for including it in the existing binary package is that the 
> compiled Qt WebEngine dictionary is not very large (691.2 KiB for en_US).

I don't think that is a reason to keep it in hunspell-* per se, so..

> The argument for splitting it into a separate binary package is that most 
> people who install the Hunspell dictionaries don't intent to use a program 
> that does spell checking inside of a Qt WebEngine, so it would be wasted 
> space on their system.

I agree with this one.

> Originally, I had proposed installing the dictionary files directly into 
> /usr/share/qt5/qtwebengine_dictionaries with a symlink from the upcoming 
> /usr/share/qt6/qtwebengine_dictionaries.  However Don Armstrong proposed that 
> they instead be installed in an unversioned directory and then symlinked from 
> all the current versioned Qt directories, which makes it easier to maintain.

Yup. Or patch QtWebEgine to (also) directly look there if they are supposed to
be compatible between Qt5/Qt6 (which a symlink assumes)
and directly install it there (as you propose later to 
usr/share/qtwebengine-dict)? 

CCing the QtWebEgine Maintainers.

> His patch, linked above, places the .bdic files into /usr/share/hunspell with 
> the original Hunspell files they were compiled from. 
> Rene Engelhard  objects to this file location because he 
> feels it should be preserved for files in the canonical Hunspell format.  

Indeed.

> If a different directory is used for the Qt WebEngine .bdic files, I would 
> propose something like /usr/share/qtwebengine-dict.

Sounds good.

> I don't have a particularly strong opinion about either of these two issues, 
> although I do lean slightly towards having separate binary packages and using 
> /usr/share/qtwebengine-dict for the file locations.

Good.

> However, I do think it is important that there is a consensus among all those 
> who maintain the dictionary language packages and that this consensus be 
> documented in a central location.

Indeed.

Regards,

Rene

Bug#1019061: Done

[Anton Gladky]

gnuplot-data is built. Thus closing.

Cheers

Anton

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Russ Allbery]

Guillem Jover  writes:
> On Mon, 2020-06-22 at 18:51:21 -0700, Felix Lechner wrote:

>> Starting with an upcoming release, Lintian will check for the presence
>> of required and recommended fields in various packaging control files.
>> Our methods are probably not perfect, but it was brought to my
>> attention that 'dpkg-buildpackage -S' produces *.changes files without
>> 'Binary' and 'Description' fields.

> This is due to a fix in dpkg 1.19.3 prompted by #818618, which brought up
> an inconsistency in the handling of these fields
> (commit 4a4619831de8b8972f86b489660dc98f187cfa34 in dpkg.git). DAK got
> also fixed to accept these .changes files.

[...]

> The deb-changes(5) and policy state that these fields contain
> information for binary packages being uploaded. On a source-only upload,
> there are no such binaries, so the definition was internally
> inconsistent.  I think the only thing missing is policy clarifying that
> this field is only mandatory on non-source-only uploads.

Here is a patch to fix this wording in Policy.  I think it's ready for
seconds.

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

>From c98654d7effa875c6e11da16159ac3feded8f763 Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 21:17:55 -0700
Subject: [PATCH] Binary and Description optional in .changes

In .changes files for source-only uploads, the Binary and
Description fields are not present.  Document this, and be clearer
in the description of the Description field for .changes files that
only descriptions of binary packages are included.
---
 policy/ch-controlfields.rst | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 428b8a7..f85f75d 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -278,7 +278,7 @@ The fields in this file are:
 
 -  :ref:`Source ` (mandatory)
 
--  :ref:`Binary ` (mandatory)
+-  :ref:`Binary `
 
 -  :ref:`Architecture ` (mandatory)
 
@@ -292,7 +292,7 @@ The fields in this file are:
 
 -  :ref:`Changed-By `
 
--  :ref:`Description ` (mandatory)
+-  :ref:`Description `
 
 -  :ref:`Closes `
 
@@ -809,12 +809,13 @@ See :ref:`s-descriptions` for further information on
 this.
 
 In a ``.changes`` file, the ``Description`` field contains a summary of
-the descriptions for the packages being uploaded. For this case, the
-first line of the field value (the part on the same line as
-``Description:``) is always empty. It is a multiline field, with one
-line per package. Each line is indented by one space and contains the
-name of a binary package, a space, a hyphen (``-``), a space, and the
-short description line from that package.
+the descriptions of the binary packages being uploaded. (``.changes``
+files for uploads containing only source packages will not have this
+field.) For this case, the first line of the field value (the part on the
+same line as ``Description:``) is always empty. It is a multiline field,
+with one line per binary package. Each line is indented by one space and
+contains the name of a binary package, a space, a hyphen (``-``), a space,
+and the short description line from that package.
 
 .. _s-f-Distribution:
 
@@ -924,7 +925,8 @@ every architecture. The source control file doesn't contain details of
 which architectures are appropriate for which of the binary packages.
 
 When it appears in a ``.changes`` file, it lists the names of the binary
-packages being uploaded, separated by whitespace (not commas).
+packages being uploaded, separated by whitespace (not commas). If only
+source packages are being uploaded, this field will not be present.
 
 .. _s-f-Installed-Size:
 
-- 
2.37.2

Bug#944469: Using bash-completion with python-argcomplete

[duck]

Quack Gabriel,

I salvaged python-argcomplete and I'm now looking at loading completions 
when the package is installed but that does not work as planned. Could 
you lend me a hand please?


python-argcomplete ships with a script 
(activate-global-python-argcomplete) which installs completion in 
/etc/bash_completion.d/python-argcomplete. It works very well but does 
required a manual step and also leaves a file that users should not 
modify in /etc.
I updated the package to use dh_bash-completion instead: the file is 
properly installed but completion does not work.


I read on the wiki 
(https://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap) that 
you implemented dynamic load completion and I suspect this is the 
problem here (I could not read the details though as the link is 
broken). If bash-completion expects the config to be named after a 
command then it will not work as python-argcomplete needs to be enabled 
for every python command. Do I understand it well? Any idea how I could 
do this integration?


Regards.
\_o<

--
Marc Dequènes

Bug#1020399: Please add Suggests: openssh-client

[Trent W. Buck]

Package: gvfs-backends
Version: 1.46.2-1
Severity: wishlist

To the best of my knowledge, "gio mount sftp://example.com"; works by running 
"ssh example.com -s sftp".
It cannot use libssh (used by qemu); nor libssh2 (used by curl), nor dropbear 
dbclient[0].

To make this a little more obvious, please add "Suggests: openssh-client" to 
debian/control.

[0] 
https://sources.debian.org/src/gvfs/1.50.2-2/daemon/gvfsbackendsftp.c/#L247-L261

https://sources.debian.org/src/gvfs/1.50.2-2/daemon/gvfsbackendsftp.c/#L480-L520


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

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

Versions of packages gvfs-backends depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gvfs 1.46.2-1
ii  gvfs-common  1.46.2-1
ii  gvfs-daemons 1.46.2-1
ii  gvfs-libs1.46.2-1
ii  libarchive13 3.4.3-2+deb11u1
ii  libavahi-client3 0.8-5+deb11u1
ii  libavahi-common3 0.8-5+deb11u1
ii  libavahi-glib1   0.8-5+deb11u1
ii  libc62.31-13+deb11u4
ii  libcdio-cdda210.2+2.0.0-1+b2
ii  libcdio-paranoia210.2+2.0.0-1+b2
ii  libcdio192.1.0-2
ii  libgcrypt20  1.8.7-6
ii  libgdata22   0.17.13-3
ii  libglib2.0-0 2.66.8-1
ii  libgoa-1.0-0b3.38.0-3
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgudev-1.0-0   234-1
ii  libimobiledevice61.3.0-6
ii  libmtp9  1.1.17-3
ii  libnfs13 4.0.0-1
ii  libplist32.2.0-6
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libsmbclient 2:4.16.1+dfsg-8~bpo11+1
ii  libsoup2.4-1 2.72.0-2
ii  libusb-1.0-0 2:1.0.24-3
ii  libxml2  2.9.10+dfsg-6.7+deb11u2
ii  psmisc   23.4-2

Versions of packages gvfs-backends recommends:
ii  gnome-keyring  3.36.0-1

Versions of packages gvfs-backends suggests:
ii  bluez-obexd   5.55-3.1
ii  samba-common  2:4.16.1+dfsg-8~bpo11+1

-- no debconf information

Bug#970234: consider dropping "No hard links in source packages"

[Russ Allbery]

Helmut Grohne  writes:

> Jakub stumbled into the "No hard links in source packages" requirement
> added around 1996 and couldn't make sense of it. Neither could Christoph
> nor myself. tar does support hard links just fine. lintian does not
> check this property. sugar-log-activity/38 is an example package
> violating the property. It is shipped in buster and technically rc-buggy
> though no bug is filed about it.

> I believe that the requriement needs a rationale. Failing that, it
> should be dropped.

I'm inclined to agree with you on this, but it's probably worth mentioning
somewhere in this bug that the AFS file system is still used and still, so
far as I know, does not support cross-directory hard links because of its
per-directory ACL system.  I'm not sure what tar does in this situation:
whether it fails or whether it just silently duplicates the file.

I'm not sure that we care, but that sort of concern (along with a general
dislike of hard links) is probably the original rationale.

The fact that this has gone unnoticed in a source package in an existing
release makes a pretty strong argument that nothing in Debian cares and we
should just remove the constraint.

Sam Hartman  writes:

> I think that hard links in a source package are fine provided that
> breaking the hard links would not either break the build or provide an
> unreasonable space multiplier.

I agree with you that those would be undesirable properties, but are they
likely and important enough to have it be worth retaining a section
talking about this, as opposed to using the "not every bug is a Policy
violation" rule?  We do pay a (small) complexity cost for each additional
requirement we put in Policy, so I'm tempted to just drop this entirely
and bank the complexity reduction.

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

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Russ Allbery]

Felix Lechner  writes:

> The installable stanzas in d/control (called "binary package paragraphs"
> in policy) inherit the Section field from the source paragraph. There is
> no reason to provide inheritance the other way around.

Huh, this pointed out to me that I don't know what the current behavior
is.  I think I've always put a Section field in the first stanza and then
overridden it as necessary, or at least I don't remember thinking about
this before.

The current Policy description of the Section field is rather cryptic:

This field specifies an application area into which the package has
been classified. See Sections.

When it appears in the debian/control file, it gives the value for the
subfield of the same name in the Files field of the .changes file. It
also gives the default for the same field in the binary packages.

I understand what it's trying to say, but that's a very mechanical
definition that isn't clear about the relationship between the Section
field in the source stanza and the Section field in the binary stanzas.
(It also claims Section is about an "application area," a term that I
don't think we use anywhere else in Policy.)

So, what happens today if you put Section in a binary stanza but not in
the source stanza?  Is it inherited from the binary stanza by the source
stanza (I agree that seems weird)?  If so, from which binary stanza is it
inherited, if there are several?  The definition of the Files field
implies that the section may just be - in some cases.

The current documentation certainly seems inadequate, although I'd like to
understand what the behavior of Debian software is before proposing
alternative wording.

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

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Russ Allbery]

Wouter Verhelst  writes:
> On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
>> Wouter Verhelst  writes:

>>> -policy: this is a question that has come up before
>>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is
>>> another example that springs to mind, but I'm pretty sure there are
>>> more), so I think we should document in Policy that a) buildd only
>>> looks at the first dependency in alternative build-dependencies, and
>>> b) why this is the case.

>> Policy already says:

>> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch
>> permit the use of alternative dependencies, these are not normally
>> used by the Debian autobuilders. To avoid inconsistency between
>> repeated builds of a package, the autobuilders will default to
>> selecting the first alternative, after reducing any
>> architecture-specific restrictions for the build architecture in
>> question. While this may limit the usefulness of alternatives in a
>> single release, they can still be used to provide flexibility in
>> building the same package across multiple distributions or
>> releases, where a particular dependency is met by differently named
>> packages.

>> in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
>> more prominant (and make it clear that it's normative), and tweak the
>> wording.

> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
> (probably after debconf though)

Here, a couple of years later, is a patch that does this, and which I
think is ready for seconds.

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

>From dd30c5455f13086dd0ef90bf6890c20729a1ac0b Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 19:11:54 -0700
Subject: [PATCH] Improve alternative build dependency discussion

Alternatives in build dependencies are normally (except for
backports) handled specially by autobuilders to try to maintain
consistent builds.  This was documented in Policy, but in a
footnote that people often didn't see.

Move this text into the main body of the discussion of build
dependencies and reword it for additional clarity.  Add a pointer
to this discussion where alternative dependencies are introduced.
---
 policy/ch-relationships.rst | 41 ++---
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 5074428..f177885 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other
 packages, the package names listed may also include lists of alternative
 package names, separated by vertical bar (pipe) symbols ``|``. In such a
 case, that part of the dependency can be satisfied by any one of the
-alternative packages.  [#]_
+alternative packages. (Alternative dependencies in ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` are normally used in a
+restricted way. See :ref:`Relationships between source and binary packages
+` for more details.)
 
 All of the fields may restrict their applicability to particular versions
 of each named package. This is done in parentheses after each individual
@@ -620,6 +623,27 @@ earlier for binary packages) in order to invoke the targets in
 ``Build-Conflicts-Arch`` fields must be satisfied when these targets
 are invoked.
 
+Alternative dependencies are allowed in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's
+autobuilders normally interpret them in a restricted way. After
+dependencies that do not apply to the current architecture are removed,
+all alternatives specifying different package names than the first
+alternative are dropped. (Alternatives specifying the same package name
+are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.)
+The effect, therefore, is to use only the first alternative that is valid
+on the relevant architecture. This is done to reduce the risk of
+inconsistencies between repeated builds.
+
+The autobuilders for the Debian backports suite do not perform this
+transformation and instead use the full alternatives list to resolve
+dependencies.
+
+While this rule for build dependencies may limit the usefulness of
+alternatives, they can still be used to provide flexibility when building
+the package outside of Debian's autobuilders, or when building it across
+multiple distributions or releases where a particular dependency is met by
+differently named packages.
+
 .. _s-built-using:
 
 Additional source packages used to build the binary - ``Built-Using``
@@ -666,21 +690,6 @@ requirements to retain the referenced source packages.  It should not
 be added solely as a way to locate packages that need to be rebuilt
 against newer versions of their build dependencies.
 
-.. [#]
-   While ``Build-Depends``

Bug#1020398: ITP: jqp -- A TUI playground to experiment with jq

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: jqp
  Version : 0.1.0-1
  Upstream Author : Noah Gorstein
* URL : https://github.com/noahgorstein/jqp
* License : Expat
  Programming Lang: Go
  Description : A TUI playground to experiment with jq

 A TUI tool that allows for experimentation with jq with fast iteration. This
 application utilizes itchny's (https://github.com/itchyny) implementation of
 jq written in Go, gojq (https://github.com/itchyny/gojq).

This package will be team maintained by the go team.

Bug#1020341: RFS: fast-float/3.5.1-1 [ITP] -- Implementation of the C from_chars functions for float and double types

[Adam Borowski]

On Wed, Sep 21, 2022 at 12:31:11AM +0900, Daichi Fukui wrote:
>  * Package name : fast-float
>Version  : 3.5.1-1
>  * URL  : https://github.com/fastfloat/fast_float

>   fast-float - Implementation of the C++ from_chars functions for float and
> double types

Hi!
The package looks good so far, but C/C++ development header packages are
supposed to be named libXXX-dev.  Strictly speaking, the Policy demands
that only for headers of shared libraries, but I wouldn't go different
for a header-only lib.

Eg:
source package: plf-colony
binary package: libplf-colony-dev

(Of course, some other sponsor may think different...)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ How to squander your resources: those silly Swedes have a sauce
⢿⡄⠘⠷⠚⠋⠀ named "hovmästarsås", the best thing ever to put on cheese, yet
⠈⠳⣄ they waste it solely on mere salmon.

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Russ Allbery]

Guillem Jover  writes:

> Starting with dpkg 1.18.5, several maintainer script actions involving a
> new package version, get that version as an argument after the old
> version, because they could not get it in any other easy way. The new
> version was only available in the new package somewhere in the
> filesystem.

> One previous way to workaround this limitation was to inject the new
> version at build time into those maintainer scripts, which is rather
> cumbersome, when dpkg already knows at run-time which new version it is
> handling.

> This was proposed and discussed some time ago in the debian-dpkg mailing
> list.

> The list of the actions and their new arguments, from the dpkg changelog
> entry are:

>   -  failed-upgrade  
>   -  abort-install  
>   -  abort-upgrade  
>   -  install  
>   -  upgrade  
>   -  failed-upgrade  

> Please, update the relevant section to mention those new arguments.

Here is a patch that I believe implements that, and which I think is ready
for seconds.

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

>From 2260f7a3aafe93282860aad07b7d8c1544bcf0ce Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 18:49:04 -0700
Subject: [PATCH] new-version now passed to more maintainer scripts

Starting with dpkg 1.18.5, several maintainer script actions
involving a new package version get that version as an argument
after the old version. Update Policy's maintainer script
documentation accordingly.
---
 policy/ch-maintainerscripts.rst | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
index 709aabf..724074c 100644
--- a/policy/ch-maintainerscripts.rst
+++ b/policy/ch-maintainerscripts.rst
@@ -107,8 +107,8 @@ old version of a package that is being upgraded from or downgraded from.
 The ``preinst`` script may be called in the following ways:
 
 | ``new-preinst`` install
-| ``new-preinst`` install *old-version*
-| ``new-preinst`` upgrade *old-version*
+| ``new-preinst`` install *old-version* *new-version*
+| ``new-preinst`` upgrade *old-version* *new-version*
 
 The package will not yet be unpacked, so the ``preinst`` script
 cannot rely on any files included in its package. Only essential
@@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following ways:
 where dependencies are only "Half-Installed" due to a partial
 upgrade.
 
-``new-prerm`` failed-upgrade *old-version*
-Called during error handling when ``prerm upgrade`` fails. The new package will not yet be
-unpacked, and all the same constraints as for ``preinst upgrade``
-apply.
+``new-prerm`` failed-upgrade *old-version* *new-version*
+Called during error handling when ``prerm upgrade`` fails. The new
+package will not yet be unpacked, and all the same constraints as for
+``preinst upgrade`` apply.
 
 The ``postrm`` script may be called in the following ways:
 
@@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways:
 the package's dependencies if those dependencies are unavailable.
 [#]_
 
-``new-postrm`` failed-upgrade *old-version*
+``new-postrm`` failed-upgrade *old-version* *new-version*
 Called when the old ``postrm upgrade`` action fails. The new package
 will be unpacked, but only essential packages and pre-dependencies
 can be relied on. Pre-dependencies will either be configured or will
@@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways:
 configured and was never removed.
 
 | ``new-postrm`` abort-install
-| ``new-postrm`` abort-install *old-version*
-| ``new-postrm`` abort-upgrade *old-version*
+| ``new-postrm`` abort-install *old-version* *new-version*
+| ``new-postrm`` abort-upgrade *old-version* *new-version*
 
 Called before unpacking the new package as part of the error
 handling of ``preinst`` failures. May assume the same state as
@@ -229,7 +229,7 @@ These are the "error unwind" calls listed below.
 
.. parsed-literal::
 
-   new-prerm failed-upgrade *old-version*
+   new-prerm failed-upgrade *old-version* *new-version*
 
If this works, the upgrade continues. If this does not work, the
error unwind:
@@ -305,13 +305,13 @@ These are the "error unwind" calls listed below.
 
.. parsed-literal::
 
-   *new-preinst* upgrade *old-version*
+   *new-preinst* upgrade *old-version* *new-version*
 
If this fails, we call:
 
.. parsed-literal::
 
-   *new-postrm* abort-upgrade *old-version*
+   *new-postrm* abort-upgrade *old-version* *new-version*
 
i.  If that works, then
 
@@ -331,13 +331,13 @@ These are the "error unwind" calls listed below.
 
.. parsed-literal::
 
-   *new-preinst* install *old-version*
+   *new-preinst* install *old-version* *new-version*
 
Error unwind:
 
.. 

Bug#1020397: RM: qtav -- ROM; Package is abandoned upstream

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1004...@bugs.debian.org

See https://github.com/wang-
bin/QtAV/commit/fdc613dc99304f208cff0bb25b3ded14bb993237

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Russ Allbery]

Cyril Brulebois  writes:
> Russ Allbery  (2022-09-19):

>> but I suspect that, to the extent that this is a Policy issue, the problem
>> was that a source package is not itself a udeb and therefore it wasn't clear
>> whether Policy applies to source packages that only produce udebs.  My gut
>> feeling is that it should not: the whole point of udebs is that they get to
>> break the rules.
>> 
>> So, in addition to saying that Standards-Version is generally not used for
>> udebs or for source packages that only build udebs (I would use wording
>> like that rather than "required" since Policy puts no requirements on
>> udebs at all), maybe we should add to this paragraph in 1.1 (Scopes):
>> 
>> udebs (stripped-down binary packages used by the Debian Installer) do
>> not comply with all of the requirements discussed here. See the Debian
>> Installer internals manual for more information about them.
>> 
>> That could be as simple as saying "udebs (...) and source packages that
>> produce only udebs do not comply"

> Looks good to me, thanks!

Here is proposed wording that I think is ready for seconds.

From: Russ Allbery 
Date: Tue, 20 Sep 2022 18:35:55 -0700
Subject: [PATCH] Clarify udeb-only source packages are out of scope

Note that source packages that only produce udebs are, like udebs,
out of scope and may not follow all of the requirements of Policy.

Say explicitly in the Standards-Version description that udebs and
source packages that only produce udebs do not use Standards-Version.
---
 policy/ch-controlfields.rst |  3 +++
 policy/ch-scope.rst | 10 +-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 428b8a7..ea8f4a3 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -540,6 +540,9 @@ Thus only the first three components of the policy version 
are
 significant in the *Standards-Version* control field, and so either
 these three components or all four components may be specified. [#]_
 
+udebs and source packages that only produce udebs do not use
+``Standards-Version``.
+
 .. _s-f-Version:
 
 ``Version``
diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
index 289c9a9..a279c26 100644
--- a/policy/ch-scope.rst
+++ b/policy/ch-scope.rst
@@ -71,11 +71,11 @@ Much of the information presented in this manual will be 
useful even
 when building a package which is to be distributed in some other way or
 is intended for local use only.
 
-udebs (stripped-down binary packages used by the Debian Installer) do
-not comply with all of the requirements discussed here. See the `Debian
-Installer internals
-manual `_ for
-more information about them.
+udebs (stripped-down binary packages used by the Debian Installer) and
+source packages that produce only udebs do not comply with all of the
+requirements discussed here. See the `Debian Installer internals manual
+`_ for more information
+about them.
 
 .. [#]
Informally, the criteria used for inclusion is that the material meet

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

Bug#1011716: libbluray: continue to FTBFS and VLC crash in stable

[Christian Barcenas]

reopen 1011716
tags 1011716 bullseye patch
thanks

Re-opening because I still see FTBFS on Bullseye 11.5 (stable), and
this library causes a crash in VLC when certain Blu-rays are opened.

I think an upload to stable-updates is necessary. Backporting the
following patch from the packaging repository's master branch onto
the current source package in bullseye seemed to fix both issues.

https://salsa.debian.org/multimedia-team/libbluray/-/blob/8c62a5c355ab7b68eacaced9ae245a88059924db/debian/patches/0002-Fix-build-failure-after-Oracle-Java-CPU-for-April-20.patch

Thanks.

Bug#1020396: systemd-boot: kernel installation/initrd update hooks double the initrd like #970213 since #826045

[наб]

Package: systemd-boot
Version: 251.4-3
Severity: normal
Tags: patch

Dear Maintainer,

In the default installation, both a bare initrd and a versioned one are
installed:
  /boot/efi/HASH/5.16.0-1-amd64/initrd.img-5.16.0-1-amd64
  /boot/efi/HASH/5.16.0-1-amd64/linux
  /boot/efi/HASH/5.16.0-1-amd64/initrd

In #970213, I worked around this by only installing the generated
as the standard "initrd" fallback if none was passed;
I've been using a simple 
  #!/bin/sh
  bootctl is-installed > /dev/null || exit 0
  exec kernel-install add "$1" "/boot/vmlinuz-$1" "/boot/initrd.img-$1"
/etc/kernel/postinst.d/kernel-install (and analogous remove),
so this works for that case perfectly.

In #826045, upstream hooks were added:
  debian/extra/kernel/post{inst,rm}.d/systemd-boot
  (74127387dacf23f037f3a55a808951fae93024c6)
and
  debian/extra/initramfs/post-update.d/systemd-boot
  (9a6d87f1c6f7fbde8ff8e7beab30973944221244)
to integrate with bootctl out-of-box. This is great!

However, /etc/kernel/postinst.d/systemd-boot runs:
  kernel-install add "$1" "$2"
and /etc/initramfs/post-update.d/systemd-boot runs:
  kernel-install add "$1" "/boot/vmlinuz-$1" "$2"

And the former installs:
  /boot/efi/HASH/5.16.0-1-amd64/linux
  /boot/efi/HASH/5.16.0-1-amd64/initrd
but the latter installs:
  /boot/efi/HASH/5.16.0-1-amd64/initrd.img-5.16.0-1-amd64
  /boot/efi/HASH/5.16.0-1-amd64/linux
hence the situation at the top I wanted to avoid in #970213;
ESPs tend to be really small!

I've opened MR 169 on Salsa:
  https://salsa.debian.org/systemd-team/systemd/-/merge_requests/169
and am attaching a patch for this that makes it so
/etc/kernel/postinst.d/systemd-boot calls 
  kernel-install add "$1" "$2" "/boot/initrd.img-$1"
if the latter exists, and the previous
  kernel-install add "$1" "$2"
otherwise, which always installs the versioned initrd,
as well as one that will order this bootloader hook
with the other bootloader hooks at the end (cf. message).


Installation logs that demonstrate this follow.

Implicit image:
  root@zoot2:~# kernel-install -v add $(uname -r) /boot/vmlinuz-5.16.0-1-amd64
  Reading /usr/lib/kernel/install.conf…
  BOOT_ROOT=/tmp/br set via environment or install.conf
  machine-id d42f27f4670847aeae24b01bd283a4e0 acquired from /etc/machine-id
  Entry-token candidates: d42f27f4670847aeae24b01bd283a4e0 debian Default
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0 exists, using BOOT_ROOT=/tmp/br, 
ENTRY_TOKEN=d42f27f4670847aeae24b01bd283a4e0
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0 exists, using layout=bls
  Using ENTRY_DIR_ABS=/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64
  Plugin files:
  /usr/lib/kernel/install.d/50-depmod.install
  /usr/lib/kernel/install.d/85-initrd.install
  /usr/lib/kernel/install.d/90-loaderentry.install
  +mkdir -v -p /tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64
  mkdir: created directory 
'/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64'
  +/usr/lib/kernel/install.d/50-depmod.install add 5.16.0-1-amd64 
/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64 
/boot/vmlinuz-5.16.0-1-amd64
  +depmod -a 5.16.0-1-amd64
  +/usr/lib/kernel/install.d/85-initrd.install add 5.16.0-1-amd64 
/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64 
/boot/vmlinuz-5.16.0-1-amd64
  Installing '/boot/initrd.img-5.16.0-1-amd64' as 
'/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64/initrd'
  +/usr/lib/kernel/install.d/90-loaderentry.install add 5.16.0-1-amd64 
/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64 
/boot/vmlinuz-5.16.0-1-amd64
  Creating 
/tmp/br/loader/entries/d42f27f4670847aeae24b01bd283a4e0-5.16.0-1-amd64.conf
  root@zoot2:~# find /tmp/br/
  /tmp/br/
  /tmp/br/loader
  /tmp/br/loader/entries
  /tmp/br/loader/entries/d42f27f4670847aeae24b01bd283a4e0-5.16.0-1-amd64.conf
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64/linux
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64/initrd

Explicit image:
  root@zoot2:~# kernel-install -v add $(uname -r) /boot/vmlinuz-5.16.0-1-amd64 
/boot/initrd.img-5.16.0-1-amd64
  Reading /usr/lib/kernel/install.conf…
  BOOT_ROOT=/tmp/br set via environment or install.conf
  machine-id d42f27f4670847aeae24b01bd283a4e0 acquired from /etc/machine-id
  Entry-token candidates: d42f27f4670847aeae24b01bd283a4e0 debian Default
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0 exists, using BOOT_ROOT=/tmp/br, 
ENTRY_TOKEN=d42f27f4670847aeae24b01bd283a4e0
  /tmp/br/d42f27f4670847aeae24b01bd283a4e0 exists, using layout=bls
  Using ENTRY_DIR_ABS=/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64
  Plugin files:
  /usr/lib/kernel/install.d/50-depmod.install
  /usr/lib/kernel/install.d/85-initrd.install
  /usr/lib/kernel/install.d/90-loaderentry.install
  +mkdir -v -p /tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64
  mkdir: created directory 
'/tmp/br/d42f27f4670847aeae24b01bd283a4e0/5.16.0-1-amd64'
  +/usr/lib/kernel/insta

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Russ Allbery]

Charles Plessy  writes:

> I disagree with this point of view.  In my own case I had to take a
> dictionary to learn what a stanza is, while the word paragraph is surely
> know at least to anybody who studied English in a classroom.

> In my own field, (molecular biology) we (or at least some of us) are
> putting some effort to eliminate jargon and use simple words that makes
> written documents more accessible to the public.  This is why I prefered
> paragraph to stanza when working on the specification.

This is a very valid point, and I appreciate you bringing this up!

My personal opinion is that I don't think jargon is necessarily good or
bad.  It has advantages and drawbacks.

One drawback that you're correctly pointing out is accessibility: jargon
can make things that would otherwise be comprehensible harder to
understand.  It can also be off-putting and alienating to people, and thus
make it harder for them to get involved in a shared project.

The advantage of jargon, and the reason why jargon exists and why humans
keep inventing it, is that it's precise.  You don't need as much context
to disambiguate what a sentence may be talking about.  I do find the use
of paragraph the way we were previously using it to be confusing,
particularly given that the paragraphs contain fields which in turn
contain actual paragraphs in the normal sense of the term.  In some
contexts, precision doesn't matter, but Debian Policy is one place where
we should try to be precise.

Stanza has the significant drawback that it's dictionary definition is
specific to poetry.  In poetry, it's a close analog to how we're using it,
but that does make it somewhat obscure.  It does have the minor advantage
of being terminology that was already in use for exactly this construction
in deb822 files.

I don't want to keep using paragraph, but I'd be open to some other term
that Guillem was also open to (I think matching the terminology in dpkg is
very important).  Section or block are commonly used for things like this,
but aren't very precise, so I'm not that enthused by them.

> If I were to redo such a specification from scratch, I would ask
> non-European language speakers their opinion too.

I'm definitely interested in that opinion from anyone who is listening in!

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

Bug#998097: [DRE-maint] Bug#998097: ruby-eventmachine FTBFS on IPV6-only buildds and accesses the internet during the build

[Adrian Bunk]

Control: reopen -1

On Wed, Nov 03, 2021 at 09:50:32AM -0300, Antonio Terceiro wrote:
> On Sat, Oct 30, 2021 at 11:53:46AM +0300, Adrian Bunk wrote:
> > Source: ruby-eventmachine
> > Severity: serious
> > Tags: ftbfs
> > 
> > FTBFS on IPV6-only buildds:
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine&arch=amd64&ver=1.3~pre20201020-b50c135-3&stamp=1633500476&raw=0
> > https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine&arch=i386&ver=1.3~pre20201020-b50c135-4%2Bb1&stamp=1635578996&raw=0
> > 
> > FTBFS due to attempted DNS:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-eventmachine.html
> > 
> > ...
> > ===
> > Failure: test_nameserver(TestResolver):
> >was expected to be kind_of?
> >but was
> >   .
> > /build/1st/ruby-eventmachine-1.3~pre20201020-b50c135/tests/test_resolver.rb:19:in
> >  `test_nameserver'
> >  16:   end
> >  17: 
> >  18:   def test_nameserver
> >   => 19: assert_kind_of(String, EM::DNS::Resolver.nameserver)
> >  20:   end
> >  21: 
> >  22:   def test_nameservers
> > ===
> > ...
> 
> The ipv6-only thing is already worked around in
> 1.3~pre20201020-b50c135-4 by skipping the tests in those setups.
>...

Something still seems to fail on IPV-6 only buildds:
https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine&arch=amd64&ver=1.3~pre20201020-b50c135-6%2Bb1&stamp=1663720780&raw=0

cu
Adrian

Bug#1020290: init-system-helpers depends on usrmerge | usr-is-merged

[Craig Sanders]

reopen 1020290
severity 1020290 critical
stop

> Given you have made usrmerge uninstallable in your system as you
> admitted (probably running one of dpkg's unsupported scripts that
> installs a local blocking package, I'd imagine) then it is entirely on
> you to fix that, it cannot be done remotely. Please stop spewing abuse
> and playing games with the BTS, it is not going to achieve anything.

I did not do that.  And I stated very clearly that I didn't.

You asked, and I replied:

> > did you block it locally somehow?
> Nope.  I had no idea this stealth-mandatory change was being forced.

stop twisting my words to avoid fixing your bug.

I said that I probably *would* (note: future tense, an indication of intent)
do something to block usrmerge on my systems somehow.

And I also said that it wasn't necessary to do so because your package was
broken.

I then gave another example of the problem occuring on a minimalist standard
sid VM.



Stop closing this bug without fixing it.

It is breaking upgrades and dist-upgrades etc.

Bug#1020395: ruby-sdbm FTBFS with more than one supported Ruby version

[Adrian Bunk]

Source: ruby-sdbm
Version: 1.0.0-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ruby-sdbm&ver=1.0.0-4%2Bb1

...
   dh_gencontrol -a -O--buildsystem=ruby
dpkg-gencontrol: warning: can't parse dependency lib lib
dpkg-gencontrol: error: parsing package 'ruby-sdbm' Depends field: ,
,
libc6 (>= 2.33), libruby3.0 (>= 3.0.0~preview1) | libruby3.1 (>= 
3.1.2), lib | lib lib
dh_gencontrol: error: dpkg-gencontrol -pruby-sdbm -ldebian/changelog 
-Tdebian/ruby-sdbm.substvars -Pdebian/.debhelper/ruby-sdbm/dbgsym-root 
-UPre-Depends -URecommends -USuggests -UEnhances -UProvides -UEssential 
-UConflicts -DPriority=optional -UHomepage -UImportant -UBuilt-Using 
-DAuto-Built-Package=debug-symbols -UProtected -DPackage=ruby-sdbm-dbgsym 
"-DDepends=ruby-sdbm (= \${binary:Version})" "-DDescription=debug symbols for 
ruby-sdbm" "-DBuild-Ids=4fef3beede0c69a9a14602656f4dfbd945ea5163 
8f82f5a95abaf8b82874576873c2885577570001" -DSection=debug -UReplaces -UBreaks 
returned exit code 25
dh_gencontrol: error: Aborting due to earlier error
make: *** [debian/rules:7: binary-arch] Error 25

Bug#1020394: rustc: Please upload 1.61.0 to unstable

[Mike Hommey]

Package: rustc
Severity: wishlist

Firefox 105 requires rustc 1.61.0. Please update the version in
unstable.

Mike

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi all,

while I do not want to pull the handbrake I would like to add my
minority opinion to that change:

Le Tue, Sep 20, 2022 at 04:11:43PM +, Russ Allbery (@rra) a écrit :
> 
> The «stanza» name is a commonly used and understood term when referring
> to deb822 blocks. Although «paragraph» is commonly used it has the
> problem of being confusing as it then makes it hard to distinguish
> actual text paragraphs in prose, while «stanza» is a very specific
> term that is not applied anywhere else in the deb822 context, so it's
> always more clear and specific.

I disagree with this point of view.  In my own case I had to take a
dictionary to learn what a stanza is, while the word paragraph is surely
know at least to anybody who studied English in a classroom.

In my own field, (molecular biology) we (or at least some of us) are
putting some effort to eliminate jargon and use simple words that makes
written documents more accessible to the public.  This is why I prefered
paragraph to stanza when working on the specification.

If I were to redo such a specification from scratch, I would ask
non-European language speakers their opinion too.

Have a nice day,

-- 
Charles

Bug#1020393: emacs-gtk: Emacs created a strange symlink "o the meta-stack pointed by sp + 1."

[Vincent Lefevre]

On 2022-09-21 02:00:24 +0200, Vincent Lefevre wrote:
> In one of my directory, a strange symbolic link was created:
> 
> lrwxrwxrwx 1 vinc17 vinc1730 2022-09-20 16:55:29 'o the meta-stack 
> pointed by sp + 1.' -> vinc17@zira.1525584:1662328575
> 
> After a web search, I've found that this is a part of a string from
> "comp.el":
> 
> https://github.com/emacs-mirror/emacs/blob/master/lisp/emacs-lisp/comp.el
> 
> contains:
> 
> (defsubst comp-slot+1 ()
>   "Slot into the meta-stack pointed by sp + 1."
>   (comp-slot-n (1+ (comp-sp
> 
> So I suppose that it was created by Emacs.

The 1525584 in the symlink value seems to be a PID, and according to
the atop logs at 17:00:01, there was:

PID  SYSCPU  USRCPU   RDELAY   VGROWRGROW   RDDSKWRDSK  RUID  
EUID   ST  EXCTHR  S   CPUNR   CPU   CMD1/1
1525584   0.22s   8.67s0.05s  627.6M97.7M   26.5M   400.0K  vinc17
vinc17 N--  4  S   61%   emacs

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1020393: emacs-gtk: Emacs created a strange symlink "o the meta-stack pointed by sp + 1."

[Vincent Lefevre]

Package: emacs-gtk
Version: 1:28.1+1-3
Severity: normal

In one of my directory, a strange symbolic link was created:

lrwxrwxrwx 1 vinc17 vinc1730 2022-09-20 16:55:29 'o the meta-stack pointed 
by sp + 1.' -> vinc17@zira.1525584:1662328575

After a web search, I've found that this is a part of a string from
"comp.el":

https://github.com/emacs-mirror/emacs/blob/master/lisp/emacs-lisp/comp.el

contains:

(defsubst comp-slot+1 ()
  "Slot into the meta-stack pointed by sp + 1."
  (comp-slot-n (1+ (comp-sp

So I suppose that it was created by Emacs.

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:28.1+1-3
ii  emacs-common 1:28.1+1-3
ii  libacl1  2.3.1-1
ii  libasound2   1.2.7.2-1
ii  libc62.34-8
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-2
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgccjit0   12.2.0-2
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.74.0-1
ii  libgmp10 2:6.2.1+dfsg1-1
ii  libgnutls30  3.7.7-2
ii  libgpm2  1.20.7-10
ii  libgtk-3-0   3.24.34-3
ii  libharfbuzz0b2.7.4-1+b1
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  liblcms2-2   2.13.1-1
ii  libm17n-01.8.0-4
ii  libotf1  0.9.16-3+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpng16-16  1.6.37-5
ii  librsvg2-2   2.54.4+dfsg-1
ii  libselinux1  3.4-1+b1
ii  libsm6   2:1.2.3-1
ii  libsystemd0  251.4-3
ii  libtiff5 4.4.0-4
ii  libtinfo66.3+20220423-2
ii  libx11-6 2:1.8.1-2
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  libxrender1  1:0.9.10-1.1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages emacs-gtk recommends:
ii  fonts-noto-color-emoji  2.038-1

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:28.1+1-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1020316: liferea: Missing depends on python3-gi-cairo breaks unread trayicon

[Matt Horan]

On 19-09-2022 22:35, Matt Horan wrote:

This package is missing a dependency on python3-gi-cairo. This is not a
major issue but does cause the unread icon to not work. I backported
this package to bullseye but I presume it's an issue in unstable. I
think this is due to a change back in ~2020 to fix some trayicon issues.


trayicon is a plugin, shall we make that a recommends?


Sounds good to me. Though if the trayicon is enabled by default, it's 
somewhat confusing behavior.



And,  I only see "import cairo". We do depend on python3-cairo. Can
you show how it doesn't work? (Maybe starting liferea from the command
line and hope we see messages).


Here is the traceback I get without the python3-gi-cairo package 
installed:


Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/liferea/plugins/trayicon.py", line 256, in 
feedlist_new_items_cb
pix = self.show_new_count(double_figure)
  File "/usr/lib/x86_64-linux-gnu/liferea/plugins/trayicon.py", line 243, in 
show_new_count
pix = pixbuf_text(pix_size, pix_size,
  File "/usr/lib/x86_64-linux-gnu/liferea/plugins/trayicon.py", line 63, in 
pixbuf_text
Gdk.cairo_set_source_pixbuf(context, bg_pix,
KeyError: 'could not find foreign type Context'

Then the icon remains the globe instead of the newspaper with a count.

Thanks,
Matt


signature.asc
Description: PGP signature

Bug#1019743: u-boot-menu: u-boot-update should read kernel parameters from /etc/kernel/cmdline

[Vagrant Cascadian]

On 2022-09-20, Arnaud Ferraris wrote:
> From 03db7668f3c371a5a2d564ca14c9e671c6a754b3 Mon Sep 17 00:00:00 2001
> From: Arnaud Ferraris 
> Date: Tue, 14 Sep 2021 20:36:54 +0200
> Subject: [PATCH] u-boot-update: honor /etc/kernel/cmdline

Does anything else use /etc/kernel/cmdline? Is it documented somewhere?

It seems a bit inconsistent with the rest of u-boot-menu
configuration... I recall patches to support files in a .d
directory... is that still in progress?

All that aside, the patch seems fine to me to implement the requested
behavior (although has a little extraneous whitespace removal), if that
behavior is deemed desirable. :)


> diff --git a/u-boot-update b/u-boot-update
> index 69da211..41fd0de 100755
> --- a/u-boot-update
> +++ b/u-boot-update
> @@ -90,12 +90,21 @@ U_BOOT_DEFAULT="${U_BOOT_DEFAULT:-l0}"
>  U_BOOT_ENTRIES="${U_BOOT_ENTRIES:-all}"
>  U_BOOT_TIMEOUT="${U_BOOT_TIMEOUT:-50}"
>  U_BOOT_MENU_LABEL="${U_BOOT_MENU_LABEL:-${PRETTY_NAME:-Debian GNU/Linux 
> kernel}}"
> -U_BOOT_PARAMETERS="${U_BOOT_PARAMETERS:-ro quiet}"
>  U_BOOT_FDT_DIR="${U_BOOT_FDT_DIR:-/usr/lib/linux-image-}"
>  U_BOOT_FDT_OVERLAYS="${U_BOOT_FDT_OVERLAYS:-}"
>  U_BOOT_FDT_OVERLAYS_DIR="${U_BOOT_FDT_OVERLAYS_DIR:-/boot/dtbo}"
>  U_BOOT_INITRD="${U_BOOT_INITRD:-initrd.img}"
>  
> +if [ -z "${U_BOOT_PARAMETERS}" ] && [ -f /etc/kernel/cmdline ]
> +then
> + U_BOOT_PARAMETERS="$(cat /etc/kernel/cmdline | sed -e 
> 's/root=[^[:space:]]*//' -e 's/^[[:space:]]*//')"
> + if [ -z "${U_BOOT_ROOT}" ]
> + then
> + U_BOOT_ROOT="$(cat /etc/kernel/cmdline | sed -re 
> 's/.*(root=[^[:space:]]*).*/\1/')"
> + fi
> +fi
> +U_BOOT_PARAMETERS="${U_BOOT_PARAMETERS:-ro quiet}"
> +
>  # Find parameter for root from fstab
>  if [ -z "${U_BOOT_ROOT}" ]
>  then
> @@ -267,4 +276,3 @@ done
>  _NUMBER=""
>  
>  Update "${_U_BOOT_DIRECTORY}/extlinux.conf" "${_CONFIG}"
> -
> diff --git a/u-boot-update.8 b/u-boot-update.8
> index dfc3cd7..6536c6e 100644
> --- a/u-boot-update.8
> +++ b/u-boot-update.8
> @@ -78,9 +78,10 @@ Otherwise, it defaults to 'Debian GNU/Linux, kernel'.
>  .IP "U_BOOT_PARAMETERS=""\fBro quiet\fR""" 4
>  This variable specifies additional boot parameters
>  that are appended to each kernel entry.
> -Value is an arbitrary string,
> -default is 'ro quiet'
> -(except for recovery entries, where quiet is avoided).
> +Value is an arbitrary string, default is the content
> +of /etc/kernel/cmdline, or 'ro quiet'
> +(except for recovery entries, where quiet is avoided) if
> +this file is not present or empty.
>  
>  .IP "U_BOOT_ROOT=""\fBroot\fR=\fIDEVICE\fR""" 4
>  This variable specifies the root partition.
> -- 
> 2.35.1


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020392: gnome-control-center: Night Light Filter stop working after 43~rc-2 update on Testing

[zezamoral]

Package: gnome-control-center
Version: 1:43~rc-2
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * When control-center was updated some weeks ago to 43-rc-2 version.
   * Update the package.
   * The night light start at the scheluded time, but no effect on screen, only
shows active, but not working.
   * As in the previous version in addition to activating, the selected color
temperature was applied.


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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-1
ii  desktop-base  11.0.3
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:43~rc-2
ii  gnome-desktop3-data   43~rc-1
ii  gnome-settings-daemon 43~rc-1
ii  gsettings-desktop-schemas 43~rc.1-1
ii  libaccountsservice0   22.08.8-1
ii  libadwaita-1-01.2~rc-1
ii  libc6 2.34-7
ii  libcairo2 1.16.0-6
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1+b1
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libgcr-base-3-1   3.41.1-1
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libglib2.0-0  2.73.3-3
ii  libgnome-bg-4-2   43~rc-1
ii  libgnome-bluetooth-ui-3.0-13  42.4-1
ii  libgnome-desktop-4-2  43~rc-1
ii  libgnome-rr-4-2   43~rc-1
ii  libgnutls30   3.7.7-2
ii  libgoa-1.0-0b 3.45.2-2
ii  libgoa-backend-1.0-1  3.45.2-2
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.34-3
ii  libgtk-4-14.7.2+ds-3
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.27-2
ii  libkrb5-3 1.20-1
ii  libmalcontent-0-0 0.10.5-1
ii  libmm-glib0   1.18.10-2
ii  libnm01.40.0-1
ii  libnma-gtk4-0 1.10.2-1
ii  libpango-1.0-01.50.9+ds-1
ii  libpangocairo-1.0-0   1.50.9+ds-1
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   15.0+dfsg1-4+b1
ii  libpulse0 15.0+dfsg1-4+b1
ii  libpwquality1 1.4.4-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libsmbclient  2:4.16.5+dfsg-1
ii  libsnapd-glib11.60-1
ii  libudisks2-0  2.9.4-3
ii  libupower-glib3   0.99.20-1
ii  libwacom9 2.4.0-3
ii  libx11-6  2:1.8.1-2
ii  libxi62:1.8-1
ii  libxml2   2.9.14+dfsg-1+b1
ii  webp-pixbuf-loader0.0.5-5

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-4+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.28.1-1
ii  gnome-bluetooth-sendto42.4-1
ii  gnome-online-accounts 3.45.2-2
ii  gnome-remote-desktop  42.4-1
ii  gnome-user-docs   42.0-1
ii  gnome-user-share  43~alpha-1
ii  iso-codes 4.11.0-1
ii  libcanberra-pulse 0.30-10
ii  libnss-myhostname 251.4-3
ii  malcontent-gui0.10.5-1
ii  network-manager-gnome 1.28.0-1
ii  policykit-1   0.105-33
ii  power-profiles-daemon 0.12-1
ii  pulseaudio-module-bluetooth   15.0+dfsg1-4+b1
ii  realmd0.17.0-2
ii  rygel 0.40.4-1
ii  rygel-tracker 0.40.4-1
ii  system-config-printer-common  1.5.16-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   43~rc-2
ii  gstreamer1.0-pulseaudio  1.20.3-1
ii  x11-xserver-utils7.7+9+b1

-- no debconf information

Bug#1020391: mesa: Updates to 22.2 RCs cause blank screen on some VirtIO graphics

[Ben Westover]

Source: mesa
X-Debbugs-Cc: m...@benthetechguy.net
Version: 22.2.0~rc1-1
Severity: important

Dear Maintainer,

After updating to mesa 22.2.0~rc1-1 on my UTM virtual machine on macOS
(which uses VirtIO graphics), LightDM and anything else using Mesa is
just completely black except for a cursor. This is still present in the
latest version. The default graphics option of UTM is virtio-ramfb-gl,
which is GPU accelerated; I tested virtio-ramfb, and it doesn't have
this issue, though it's not ideal as I can't resize the window and it's
not GPU accelerated. I tested all of the *-gl accelerated graphics
options, and they all have this issue. I also tested a normal
virt-manager VM on Linux, and it doesn't have this issue.

--
Ben Westover

P.S. Also reported in #1017499, but turned out to be a separate issue.

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

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


OpenPGP_signature
Description: PGP signature

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

[Todd C. Miller]

I believe this is fixed by:
https://www.sudo.ws/repos/sudo/rev/ebf9a6477d5d

I was able to reproduce the issue by running "make check" and
checking syslog.

 - todd

Bug#1009760: libssh2-1: cannot authenticate against openssh-server from bookworm (ssh-rsa not enabled server side)

[Bastian Germann]

On Sat, 16 Apr 2022 22:39:15 +0200 Alban Browaeys  wrote:

The issue is fixed by either adding to sshd 9 sshd_config:
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa


The sshd_config man page documents that ssh-rsa is not included in these 
options' defaults.
So this behaviour is expected. Alternatively you can also generate new server 
keys that fit the default.

Bug#1020390: sa-exim: frequent local_scan() signal 11 mesages in logs

[peterc]

Package: sa-exim
Version: 4.2.1-20+b1
Severity: normal

Dear Maintainer,

I see lots of 'local_scan() function crashed with signal 11' in my exim4 logs.
Example:
2022-09-21 07:54:26 1oalCD-0001cS-0x local_scan() function crashed with signal 
11 - message temporarily rejected (size 6054)
2022-09-21 07:54:32 1oalCI-0001cU-32 SA: Debug: SAEximRunCond expand returned: 
'1'
2022-09-21 07:54:32 1oalCI-0001cU-32 SA: Debug: check succeeded, running spamc
2022-09-21 07:54:32 1oalCI-0001cU-32 SA: Debug: SARewriteBody == 1, rewriting 
message body
2022-09-21 07:54:32 1oalCI-0001cU-32 SA: Debug: SAEximRejCond expand returned: 
'1'
2022-09-21 07:54:32 1oalCI-0001cU-32 SA: Debug: Writing message to 
/var/spool/sa-exim/SAteergrube/new/mje3mty1.mzg2nzy0oq.52577809180449202207327546...@strato.net
2022-09-21 07:54:32 1oalCI-0001cU-32 local_scan() function crashed with signal 
11 - message temporarily rejected (size 2245)


The messages stopped (so far) are always spam.


-- System Information:
Debian Release: 11.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.10.0-1127.18.2.vz7.163.46 (SMP w/4 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sa-exim depends on:
ii  debconf [debconf-2.0]1.5.77
ii  exim4-daemon-heavy [exim4-localscanapi-6.0]  4.96-4
ii  libc62.34-7
ii  libnetaddr-ip-perl   4.079+dfsg-2
ii  spamc3.4.6-1

Versions of packages sa-exim recommends:
ii  perl  5.34.0-5

Versions of packages sa-exim suggests:
ii  spamassassin  3.4.6-1

-- Configuration Files:
/etc/exim4/sa-exim.conf changed:
SAEximDebug: 1
SAspamcpath: /usr/bin/spamc
SAspamcHost: 127.0.0.1
SAspamcPort: 783
SAspamcUser: debian-spamd
SAEximRunCond: ${if and {{def:sender_host_address} {!eq 
{$sender_host_address}{127.0.0.1}}  {!eq {$h_X-SA-Do-Not-Run:}{Yes}} } {1}{0}}
SAEximRejCond: ${if and {{def:sender_host_address}{!eq 
{$sender_host_address}{103.230.158.80}}{!eq 
{$sender_host_address}{112.213.36.175}}{!eq {$h_X-SA-Do-Not-Rej:}{Yes}}} {1}{0}}
SAmaxbody: 256000
SATruncBodyCond: 1
SARewriteBody: 1
SAPrependArchiveWithFrom: 1
SAmaxarchivebody: 20971520
SAerrmaxarchivebody: 1073741824
SAmaxrcptlistlength: 8000
SAaddSAEheaderBeforeSA: 1
SAtimeout: 240
SAtimeoutsave: /var/spool/sa-exim/SAtimeoutsave
SAtimeoutSavCond: 1
SAerrorsave: /var/spool/sa-exim/SAerrorsave
SAerrorSavCond: 1
SAtemprejectonerror: 1
SAteergrube: ${if  and { {!eq {$sender_host_address}{129.94.242.59}}{!eq 
{$sender_host_address}{129.94.242.24}}{!eq {$sender_host_address}{127.0.0.1}} 
{!eq {$sender_host_address}{203.143.174.143}} }{20}{1048576}}
SAteergrubetime: 30
SAteergrubeSavCond: 1
SAteergrubesave: /var/spool/sa-exim/SAteergrube
SAteergrubeoverwrite: 1
SAdevnull: 20.0
SAdevnullSavCond: 1
SAdevnullsave: /var/spool/sa-exim/SAdevnull
SApermreject: 12.0
SApermrejectSavCond: 1
SApermrejectsave: /var/spool/sa-exim/SApermreject
SAtempreject: ${if and { {!eq {$sender_host_address}{127.0.0.1}} {!eq 
{$sender_host_address}{127.0.0.2}} } {5}{1}}
SAtemprejectSavCond: 1
SAtemprejectsave: /var/spool/sa-exim/SAtempreject
SAtemprejectoverwrite: 1
SAgreylistiswhitestr: GREYLIST_ISWHITE
SAgreylistraisetempreject: 5.0
SAspamacceptsave: /var/spool/sa-exim/SAspamaccept
SAspamacceptSavCond: 0
SAnotspamsave: /var/spool/sa-exim/SAnotspam
SAnotspamSavCond: 0
SAmsgteergrubewait: Wait for more output
SAmsgteergruberej: Please try again later
SAmsgpermrej: Rejected
SAmsgtemprej: Please try again later
SAmsgerror: Temporary local error while processing message, please contact 
postmaster.


-- debconf information:
  sa-exim/purge_spool: false

Bug#1000373: libssh2: drop the advertisement clause in BSD license

[Bastian Germann]

forwarded -1 https://github.com/libssh2/libssh2/pull/747

This does not mean a change in d/copyright as the advertisement clause was 
never included there.
I have created a patch and handed it in at upstream.

Bug#1020389: init-system-helpers: block migration waiting for #926699 #1020312 #1019985 #1019506

[Luca Boccassi]

Package: init-system-helpers
Version: 1.65
Severity: grave
Justification: waiting for usrmerge fixes to migrate

Temporarily block migration until the following fixes have migrated to
testing:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020312
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019985
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019506

-- 
Kind regards,
Luca Boccassi


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

Bug#589913: generic host argument support

[dann frazier]

Would you consider adding host argument support without providing a
[ppa] implementation? Users could then opt-in by adding a [ppa]
section to their /etc/dput.cf (or ~/.dput.cf). Here's just that piece
of the Ubuntu delta:

diff -urpN dput-1.1.2.orig/doc/man/dput.1 dput-1.1.2/doc/man/dput.1
--- dput-1.1.2.orig/doc/man/dput.1  2022-07-01 16:15:28.0 -0600
+++ dput-1.1.2/doc/man/dput.1   2022-09-20 15:28:47.064454572 -0600
@@ -15,7 +15,7 @@
 .OP \-DPUVdflosu
 .OP \-c CONFIGFILE
 .OP \-e DAYS
-.RI [ HOSTNAME ]
+.RI [ HOSTNAME [:ARGUMENT] ]
 .I CHANGESFILE
 \f[R].\|.\|.\f[]
 .YS
@@ -65,6 +65,10 @@ can perform on each package.
 configuration. If not specified, \f[I]HOSTNAME\f[] defaults to the
 value of the \f[B]default_host_main\f[] configuration parameter.
 .
+You also can
+pass an argument to the host by appending the hostname with a colon followed
+by the argument.
+.
 .P
 The file transfer method is determined by the \f[B]method\f[]
 configuration parameter for the specified host. See
diff -urpN dput-1.1.2.orig/doc/man/dput.cf.5 dput-1.1.2/doc/man/dput.cf.5
--- dput-1.1.2.orig/doc/man/dput.cf.5   2022-07-01 16:15:28.0 -0600
+++ dput-1.1.2/doc/man/dput.cf.52022-09-20 15:27:07.403817539 -0600
@@ -340,6 +340,14 @@ for packages that are allowed to be uplo
 This variable is used when guessing the host to upload to.
 .
 .\" ==
+.SH HOST ARGUMENT
+.P
+If a user passes an argument to a host by appending the hostname with a colon,
+.B %(HOSTNAME)s
+will be replaced with the specified argument. Otherwise, it will be replaced
+with an empty string.
+.
+.\" ==
 .SH FILES
 .
 .TP
diff -urpN dput-1.1.2.orig/dput/dput.py dput-1.1.2/dput/dput.py
--- dput-1.1.2.orig/dput/dput.py2022-07-01 16:15:28.0 -0600
+++ dput-1.1.2/dput/dput.py 2022-09-20 15:31:00.221305900 -0600
@@ -979,6 +979,19 @@ def main():
 if len(args) == 1 and not options.check_only:
 changes_file_paths = args[0:]
 else:
+if ':' in args[0]:
+sys.stdout.write("D: Splitting host argument out of  %s.\n" % 
args[0])
+args[0], host_argument = args[0].split(":", 1)
+else:
+host_argument = ""
+
+if config.has_section(args[0]):
+sys.stdout.write("D: Setting host argument.\n")
+config.set(args[0], args[0], host_argument)
+else:
+# Let the code below handle this as it is sometimes okay (ie. -o)
+pass
+
 if not options.check_only:
 if options.debug:
 sys.stdout.write(

Bug#1020367: mgp: transition gsfonts/gsfonts-x11 --> fonts-urw-base35

[Thorsten Glaser]

severity 1020367 minor
thanks

fab...@debian.org dixit:

>you are receiving this bug report, because your package declares a
>relationship with the gsfonts and/or gsfonts-x11 packages. Both
>packages have been replaced by fonts-urw-base35 since version
>20200910-2 and are now merely transitional dummy packages. In order
>to make it possible to remove these transitional packages, please
>adjust the relationships for your package accordingly.

Will do, but it’s not pressing, these are Suggests only, for extra
fonts for the presentations.

Bug#1015887: debian-installer: Adding https repo doesn't work without manually installing ca-certificates

[Philip Hands]

Control: reassign -1 apt-setup-udeb
Control: fixed -1 1:0.169

Hi,

I just had a look at this, and it seems to me that this was fixed in
apt-setup-udeb 0.169, but the version in the released (Debian 11)
installer is only at 0.166, so does not include the fix.

Looking at the syslog in this bug, one can see:

  apt-setup-udeb 1:0.166

which is the version in the release, and is from 2021-07-23.

The thing that fixes the bug is:

  https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/4

which was merged on 2022-01-29, then released as part of 1:0.169.

I've reproduced the failure with the release version of D-I, and failed
to reproduce it with yesterday's daily image (where one sees the
installation of the c-certificates package go past just after selecting
the mirror), so it really looks to have been fixed already.

If you want to try that for yourself, the daily images can be found
here:

  
https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso

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

Bug#1020388: RFS: dia/0.97.3+git20220525-4 -- Diagram editor

[Philippe SWARTVAGHER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : dia
   Version  : 0.97.3+git20220525-4
 * URL  : https://wiki.gnome.org/Apps/Dia/
 * License  : GPL-2, GPL-2+, GFDL-NIV-1.1+
 * Vcs  : https://salsa.debian.org/debian/dia
   Section  : graphics

The source builds the following binary packages:

  dia-common - Diagram editor (common files)
  dia - Diagram editor

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/dia/dia_0.97.3+git20220525-4.dsc

Changes since the last upload:

 dia (0.97.3+git20220525-4) unstable; urgency=medium
 .
   * control: recommends fonts-urw-base35 instead of removed gsfonts-x11.
 Closes: #1020354

Regards,
--
  Philippe.

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[Aurelien Jarno]

Hi,

Have you been able to progress on that? Do you need some help for a
specific step?

Regards
Aurelien

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

Bug#959881: libssh2-1: memory leaks in ver. 1.9.0 may be fixed in 1.10.0

[Bastian Germann]

On Tue, 26 Apr 2022 12:59:48 +0200 albrecht.dr...@netcologne.de wrote:

As the bug makes libssh2 more or less unusable for long-running processes 
(where the leaks accumulate for each handshake), IMHO it might be worth to 
provide v. 1.10.0 for Bullseye.


I suggest providing 1.9.0-3 (which has the gcrypt->openssl switch) for a 
bullseye point release.

Bug#1019806: Patch for sooperlooper & wxWidgets 3.2

[Scott Talbert]

Merge request sent:
https://salsa.debian.org/multimedia-team/sooperlooper/-/merge_requests/1

Regards,
Scott

Bug#1017646: Discussion on dictionaries-common

[Soren Stoutner]

As Rene Engelhard  objects to the placement of the .bdic files 
in /usr/share/hunspell, and because it would generally be a good idea to 
include as 
many Hunspell maintainers as possible and document the consensus in a central 
location as to how these dictionaries should be packaged, I have created a bug 
report against dictionaries-common at https://bugs.debian.org/cgi-bin/
bugreport.cgi?bug=1020387[1] .  It would probably be a good idea to hold off on 
uploading these changes until that consensus is reached.

-- 
Soren Stoutner
623-262-6169
so...@stoutner.com


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387


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

Bug#639537:

[c . buhtz]

Thanks for the report.
Can you reproduce that problem with current "stable" Debian version?

Bug#607758:

[c . buhtz]

Thanks for the report.

This is a feature request not a bug.

And BIT does offer other ways (SSH, user-callback, ...) to access such 
devices.


smb:// urls wont be supported in the future. Access that machine via SSH 
or mount the smb share via an user-callback script.


Please close that report because it is not a bug.

Bug#991533: Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Sean Whitton]

Hello,

On Mon 19 Sep 2022 at 09:29PM -07, Russ Allbery wrote:

> So, in addition to saying that Standards-Version is generally not used for
> udebs or for source packages that only build udebs (I would use wording
> like that rather than "required" since Policy puts no requirements on
> udebs at all), maybe we should add to this paragraph in 1.1 (Scopes):
>
> udebs (stripped-down binary packages used by the Debian Installer) do
> not comply with all of the requirements discussed here. See the Debian
> Installer internals manual for more information about them.
>
> That could be as simple as saying "udebs (...) and source packages that
> produce only udebs do not comply"

Sounds good to me.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#985257:

[c . buhtz]

Thank you very much for your report and your idea.

We will take this into account at upstream. Currently there is no open 
Issue for that but it is on our internal TODO list.
Please feel free to open an Issue for that: 
https://github.com/bit-team/backintime/issues


I would suggest to close this Debian report because it is not highly 
related to Debian.

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

Package: dictionaries-common
Version: 1.28.18
Severity: wishlist
Tags: l10n

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking 
with the WebEngine, but for some reason they require that the dictionary files 
be converted to a special binary format (.bdic).  This conversion can be done 
using qwebengine_convert_dict from the qtwebengine5-dev-tools package.  The 
upstream documentation regarding this is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes Qt WebEngine.

The purpose of this bug report is to create a central location for discussion 
about the best way to package these dictionaries.

There are two general questions that should be standardized:

1.  What should be the policy regarding the binary packages?
2.  Where should the dictionaries be placed on the file system?

1.  The binary packages can be built without much difficulty from the same 
source as existing Hunspell dictionaries.  For an example of how this can be 
done, see the following commit by Don Armstrong  to the scowl 
sorce package which builds the English Hunspell dictionary binary packages:

https://git.donarmstrong.com/?p=deb_pkgs/scowl.git;a=commitdiff;h=4510f7fed66204384fe8c39fc875e24fd874229b

In this example patch, the compiled Qt WebEngine binary dictionary is shipped 
as part of the existing Hunspell binary packages (for example, hunspell-en-us). 
 Another option would be to create a separate binary package (for example, 
qtwebengine-dict-en-us).  The argument for including it in the existing binary 
package is that the compiled Qt WebEngine dictionary is not very large (691.2 
KiB for en_US).  The argument for splitting it into a separate binary package 
is that most people who install the Hunspell dictionaries don't intent to use a 
program that does spell checking inside of a Qt WebEngine, so it would be 
wasted space on their system.

2.  Qt WebEngine searches for these binary dictionary packages in a number of 
places described in the upstream link above.  One of them is in the system-wide 
QT_INSTALL_PREFIX/qtwebengine_dictionaries.  The current QT_INSTALL_PREFIX can 
be determined by running the following command (assuming qmake is installed):

~$ qmake -query | grep QT_INSTALL_DATA
QT_INSTALL_DATA:/usr/share/qt5

Originally, I had proposed installing the dictionary files directly into 
/usr/share/qt5/qtwebengine_dictionaries with a symlink from the upcoming 
/usr/share/qt6/qtwebengine_dictionaries.  However Don Armstrong proposed that 
they instead be installed in an unversioned directory and then symlinked from 
all the current versioned Qt directories, which makes it easier to maintain.  
His patch, linked above, places the .bdic files into /usr/share/hunspell with 
the original Hunspell files they were compiled from.  Rene Engelhard 
 objects to this file location because he feels it should be 
preserved for files in the canonical Hunspell format.  If a different directory 
is used for the Qt WebEngine .bdic files, I would propose something like 
/usr/share/qtwebengine-dict.

There is some discussion about this topic that already exists in the bug report 
for scowl and on the Debian-KDE mailing list.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017646
https://lists.debian.org/debian-kde/2022/09/msg00011.html

I don't have a particularly strong opinion about either of these two issues, 
although I do lean slightly towards having separate binary packages and using 
/usr/share/qtwebengine-dict for the file locations.  However, I do think it is 
important that there is a consensus among all those who maintain the dictionary 
language packages and that this consensus be documented in a central location.

Bug#1010289: audit: FTBFS: error: cast specifies array type

[Paul Gevers]

Hi

On 20-09-2022 22:20, Graham Inggs wrote:

I think we should follow Ubuntu here.


I have uploaded the same and pushed the changes to the salsa repository 
of audit.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#985631:

[c . buhtz]

Not exactly the same but maybe related Issue on upstream:
https://github.com/bit-team/backintime/issues/977

Bug#1010289: audit: FTBFS: error: cast specifies array type

[Graham Inggs]

Hi Paul

On Tue, 20 Sept 2022 at 21:30, Paul Gevers  wrote:
> I'm not sure how to pick either solution. (At least one member of)
> Upstream seems to think that the Fedora way is better. What do you think?

Upstream wrote "The function that is failing to build looks like it
was never used because the code is completely wrong" [1]
and later they mention the PR #253 (which Ubuntu used) alongside a
link to the mailing list [2].

I think we should follow Ubuntu here.

Regards
Graham


[1] 
https://github.com/linux-audit/audit-userspace/issues/252#issuecomment-1078595249
[2] 
https://github.com/linux-audit/audit-userspace/issues/265#issuecomment-1146603552

Bug#985355:

[c . buhtz]

Reported on a "testing" Debian with a now outdated BIT version.

I also can't see something helpfull in the traceback. Sorry.

Can you reproduce the problem with a current "stable" Debian?

Bug#985260:

[c . buhtz]

Thanks for the report.

But I'm sorry I don't understand all details. What does the 
user-callbacks have to do with cron?


Maybe the bug is related to cron and not to BIT?

Bug#983616:

[c . buhtz]

Thank you very much for the report.

This is fixed upstream.
https://github.com/bit-team/backintime/pull/1246

But not yet released.

Bug#985256:

[c . buhtz]

This was reported with a "testing" Debian with a now outdated BIT 
version.


Can you reproduce the problem with the current "stable" Debian?

Bug#1020386: mesa: FTBFS on x32

[Laurent Bigonville]

Source: mesa
Version: 21.0.0-1
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

mesa currently FTBFS on x32, with the following errors:

dh_install -a
dh_install: warning: Cannot find (any matches for) 
"usr/share/drirc.d/00-radv-defaults.conf" (tried in ., debian/tmp)

dh_install: warning: mesa-vulkan-drivers missing files: 
usr/share/drirc.d/00-radv-defaults.conf
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:228: override_dh_install] Error 25

That's probably happening because the amd vulkan driver is not built

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#978735:

[c . buhtz]

This was reported with a "testing" Debian.

Can you reproduce the problem with the current "stable" Debian?

Bug#1020385: sysdig: upstream site

[Matt Taggart]

Package: sysdig
Version: 0.29.3-1
Severity: minor

Homepage:
It appears the http server for the domain sysdig.org now redirects to 
sysdig.com. That host is not listening on https, so browsers attempting 
to go direct to https won't get the redirect.


Also the page https://sysdig.com/opensource/ points to the following:
  https://github.com/draios/sysdig

So maybe:
* update the Homepage in debian/control to https://sysdig.com
* adjust Source in debian/copyright to https://github.com/draios/sysdig

Thanks,

--
Matt Taggart
m...@lackof.org

Bug#866741:

[c . buhtz]

Thank you for the report.
Can you reproduce the problem with the current version 1.3.2 from 
"stable" Debian?

Bug#1020384: libnet: Please drop manual libnet1-dbg package

[Boyuan Yang]

Source: libnet
Version: 1.1.6+dfsg-3.2
Tags: sid
Severity: normal
X-Debbugs-CC: v...@v13.gr

Dear Debian libnet package maintainer,

The package libnet you maintain in Debian
https://tracker.debian.org/pkg/libnet still manually builds a -dbg binary
package. Please consider switching to the fully-automatic dbgsym mechanism
as described in https://wiki.debian.org/AutomaticDebugPackages .

Thanks,
Boyuan Yang


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

Bug#1020383: osk-sdl: [INTL:fr] French templates translation

[Jean-Pierre Giraud]

Package: osk-sdl
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

Jean-Pierre Giraud


fr.po.xz
Description: application/xz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#859115:

[c . buhtz]

Outdated. Please close.

Bug#816197:

[c . buhtz]

Fixed now and can be closed. Thanks.

Bug#1020381: RFP: jpilot -- GUI app to view & edit your old Palm device's data

[Ludovic Rousseau]

Le 20/09/2022 à 21:20, unforgettableid a écrit :

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

* Package name: jpilot
   Version : 2.0.1
   Upstream Author : multiple authors
* URL : http://www.jpilot.org/
* License : GPLv2
   Programming Lang: GTK+
   Description : GUI app to view & edit your old Palm device's data

jpilot was part of Debian until a few years ago.  It was removed from
unstable at the request of then-maintainer Ludovic Rousseau, back when
upstream maintenance had slowed and/or stopped.  (Please see:
https://bugs.debian.org/938958).

jpilot is now maintained upstream again, in a non-default branch of
its official GitHub repository.  The newest version is 2.0.1, which
now supports GTK+ 3.  I myself, as well as some other people, still
use old Palm OS devices.  It would be good if you could please package
jpilot again, so that we can enjoy the high-quality packages which the
Debian developers are known to produce.

jpilot depends on pilot-link, which is now maintained at
.  pilot-link was removed from
Debian a few years ago as well (https://bugs.debian.org/938957).
pilot-link is mature and stable, but please expect at least one bug
fix every few years.  The pilot-link Readme file is very outdated;
I've recently submitted a pull request which fixes that.

Thank you for reading this!


The Debian files are still available

https://sources.debian.org/src/jpilot/ (latest update in 2017)
https://sources.debian.org/src/pilot-link/ (latest update in 2015)

Maybe I have the CVS (or SVN?) repository somewhere, but I am not sure.
If someone is interested I can have a look.

Bye

--
Dr. Ludovic Rousseau

Bug#1010289: audit: FTBFS: error: cast specifies array type

[Paul Gevers]

Hi all,

On 20-09-2022 10:34, Graham Inggs wrote:

fwiw, Ubuntu went with a different solution, see diff at:

https://launchpad.net/ubuntu/+source/audit/1:3.0.7-1ubuntu1


I'm not sure how to pick either solution. (At least one member of) 
Upstream seems to think that the Fedora way is better. What do you think?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020381: RFP: jpilot -- GUI app to view & edit your old Palm device's data

[unforgettableid]

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

* Package name: jpilot
  Version : 2.0.1
  Upstream Author : multiple authors
* URL : http://www.jpilot.org/
* License : GPLv2
  Programming Lang: GTK+
  Description : GUI app to view & edit your old Palm device's data

jpilot was part of Debian until a few years ago.  It was removed from
unstable at the request of then-maintainer Ludovic Rousseau, back when
upstream maintenance had slowed and/or stopped.  (Please see:
https://bugs.debian.org/938958).

jpilot is now maintained upstream again, in a non-default branch of
its official GitHub repository.  The newest version is 2.0.1, which
now supports GTK+ 3.  I myself, as well as some other people, still
use old Palm OS devices.  It would be good if you could please package
jpilot again, so that we can enjoy the high-quality packages which the
Debian developers are known to produce.

jpilot depends on pilot-link, which is now maintained at
.  pilot-link was removed from
Debian a few years ago as well (https://bugs.debian.org/938957).
pilot-link is mature and stable, but please expect at least one bug
fix every few years.  The pilot-link Readme file is very outdated;
I've recently submitted a pull request which fixes that.

Thank you for reading this!

Bug#1019554: Stamp files are not updated

[Helge Kreutzmann]

Hello Lance,
On Tue, Sep 13, 2022 at 12:22:07PM +, Lance Lin wrote:
> Thank you for your report. I'm happy to work on this.
> 
> > So cron.weekly is now overdue and cron.daily did not get touched since
> > the 5th, consistent with the update of the package.
> > 
> 
> > Cron itself works, cron.hourly (which is not managed by anacron)
> > works.
> > 
> 
> > I'm continuing to investigate, but I'm inclined to raise the severity.
> 
> Can you check to see if the anacron service is running? Richard Newton replied
> in the thread and said the service was not running after the upgrade and it 
> worked
> after manually starting it.
> 
> The change I made was very small, adding 'TimeoutStopSec=infinity' to the 
> service
> based on an improvement that a user provided. I don't think this caused the 
> issue
> you are seeing.
> 
> I was able to verify that if I manually start the service, the 
> cron.weekly/cron.daily
> are updated with the current time. The upgrade went fine on my end but I 
> would like 
> 
> to track this down.
> 
> Perhaps the issue is that the service was already running when the upgrade 
> happens 
> 
> that the "new" service doesn't start? If so, I could add a preinst script to 
> stop
> the anacron service if it is running.

I started it on Sonday and the monthly stamp file was updated (I had
manully run the weekly jobs including updating the stamp file).
However, after several reboots, anacron gets not restartet:
◈ anacron.service - Run anacron jobs
 Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: 
enabled)
 Active: inactive (dead)
   Docs: man:anacron
 man:anacrontab

helge@twentytwo:~$ ls -tlr /var/spool/anacron/
insgesamt 12
-rw--- 1 root root 9 18. Sep 06:22 cron.daily
-rw--- 1 root root 9 18. Sep 06:32 cron.weekly
-rw--- 1 root root 9 18. Sep 08:11 cron.monthly

As you can see, cron.daily is still on Sunday.

So something prevents anacron from starting.

Please tell me what helps tracing this down.

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#255271: nethack-common: creatures vanquished list should include self, if necessary

[Tobias Frost]

Control: close -1
Control: archive -1

This has "moreinfo" since 2004, and only attacts spam, so lets close and 
archive that bug.
if needed, it can be reopened.

Bug#1020085: python-astor: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Tianon Gravi]

forwarded 1020085 https://github.com/berkerpeksag/astor/issues/212
thanks

On Sat, 17 Sept 2022 at 23:45, Lucas Nussbaum  wrote:
> > p = <[ValueError('Exceeds the limit (4300) for integer string conversion') 
> > raised in repr()] int object at 0x556a03b67200>
> > imaginary = False
> >
> > def part(p, imaginary):
> > # Represent infinity as 1e1000 and NaN as 1e1000-1e1000.
> > s = 'j' if imaginary else ''
> > try:
> > if math.isinf(p):
> > if p < 0:
> > return '-1e1000' + s
> > return '1e1000' + s
> > if math.isnan(p):
> > return '(1e1000%s-1e1000%s)' % (s, s)
> > except OverflowError:
> > # math.isinf will raise this when given an integer
> > # that's too large to convert to a float.
> > pass
> > >   return repr(p) + s
> > E   ValueError: Exceeds the limit (4300) for integer string conversion

Looks like this is known upstream (see forwarded URL above), but there
isn't a fix yet. :(

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1020265: ITP: postgresql-pgml -- PostgresML is an end-to-end machine learning platform installed and operated as a PostgreSQL extension.

[Lev Kokotov]

My salsa account name is: levkk (https://salsa.debian.org/levkk)

Just got my account this morning.

Best,
Lev

On Mon, Sep 19, 2022 at 1:27 PM Christoph Berg  wrote:

> Re: Lev Kokotov
> > Hi Christoph,
> >
> > Yes, that looks like the right place for it.
>
> What's your salsa account name?
>
> Christoph
>

Bug#1012654: systemd timers?

[Ola Lundqvist]

Hi Marc

Sorry again for the late reply. Yes such a patch can be considered.
It must be clear on how the cron-fallback would work though.

// Ola

On Sat, 11 Jun 2022 at 08:51, Marc Haber 
wrote:

> Package: cron-apt
> Version: 0.13.0.1
> Severity: wishlist
>
> Hi,
>
> would you be open to a patch that adds the possibility to use systemd
> timers? Quite some packages in Debian have adopted a way to run through
> systemd timers and systemd units on systems that have systemd, falling
> back to the "old" cron job configuration if there is no systemd. for
> example, apt is doing it this way.
>
> I am attaching the four preliminary systemd units I am using on a test
> system without problems. You might notice that they're using systemd's
> RandomizedDelaySec feature and call cron-apt -i instead. I find that
> more elegant.
>
> The systemd units would also make it easier to run with reduced
> privileges, having parts of the file system read-only and have other
> nice security features. My preliminary units don't do that yet, but I
> would be willing to do that if there is a chance to get the work into
> the package.
>
> Let me know what you think.
>
> Greetings
> Marc
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'unstable'), (500,
> 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.3-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cron-apt depends on:
> ii  apt  2.5.0
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon] 3.0pl1-142
> ii  exim4-daemon-light [mail-transport-agent]  4.95-6
> ii  liblockfile1   1.17-1+b1
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/config changed [not included]
> /etc/cron.d/cron-apt changed [not included]
> /etc/logrotate.d/cron-apt changed [not included]
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1012692: missing dotlockfile warning not included in e-mail

[Ola Lundqvist]

Hi Marc

Sorry for the late reply. Interesting report. I wonder what the problem
is...

// Ola

On Sat, 11 Jun 2022 at 23:03, Marc Haber 
wrote:

> Package: cron-apt
> Version: 0.13.0+nmu1
> Severity: normal
>
> Hi,
>
> cron-apt correctly detects if the dotlockfile package is missing and
> generates an error message. This causes the e-mail message to be
> subjected as "CRON-APT error", but the actual error message does not
> seem to end up in the message.
>
> Greetings
> Marc
>
>
> -- System Information:
> Debian Release: 11.3
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-14-amd64 (SMP w/2 CPU threads)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages cron-apt depends on:
> ii  apt  2.2.4
>
> Versions of packages cron-apt recommends:
> ii  cron [cron-daemon] 3.0pl1-137
> ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
> pn  liblockfile1   
>
> cron-apt suggests no packages.
>
> -- Configuration Files:
> /etc/cron-apt/config changed [not included]
> /etc/cron.d/cron-apt changed [not included]
> /etc/logrotate.d/cron-apt changed [not included]
>
> -- no debconf information
>
> -- debsums errors found:
> debsums: changed file /usr/share/cron-apt/functions (from cron-apt package)
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1020379: src:markdown-it-py: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: markdown-it-py
Version: 2.1.0-2
Severity: serious
Control: close -1 2.1.0-3
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020378: src:fast-histogram: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: fast-histogram
Version: 0.9-2
Severity: serious
Control: close -1 0.11-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1015929

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020377: src:bnfc: fails to migrate to testing for too long: part of unfinshed ghc transition

[Paul Gevers]

Source: bnfc
Version: 2.8.3-1
Severity: serious
Control: close -1 2.9.4-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020316: liferea: Missing depends on python3-gi-cairo breaks unread trayicon

[Paul Gevers]

Hi,

Thanks for your report.

On 19-09-2022 22:35, Matt Horan wrote:

This package is missing a dependency on python3-gi-cairo. This is not a
major issue but does cause the unread icon to not work. I backported
this package to bullseye but I presume it's an issue in unstable. I
think this is due to a change back in ~2020 to fix some trayicon issues.


trayicon is a plugin, shall we make that a recommends?

And,  I only see "import cairo". We do depend on python3-cairo. Can 
you show how it doesn't work? (Maybe starting liferea from the command 
line and hope we see messages).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: openscenegraph: FTBFS with ffmpeg 5.0

[Ying-Chun Liu (PaulLiu)]

Hi all,

I've patched the audio part. But not completed. The video part needs 
more changes. But I don't have enough time now.


Just attach the partial patch I made so that when someone has time or I 
have time then we can continue it.


Yours,
Paul
Index: openscenegraph-3.6.5+dfsg1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
===
--- openscenegraph-3.6.5+dfsg1.orig/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
+++ openscenegraph-3.6.5+dfsg1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
@@ -45,12 +45,19 @@ static int decode_audio(AVCodecContext *
 if (!frame)
 return AVERROR(ENOMEM);
 
-ret = avcodec_decode_audio4(avctx, frame, &got_frame, &avpkt);
+ret = avcodec_send_packet(avctx, &avpkt);
+if (ret >= 0) {
+  ret = avcodec_receive_frame(avctx, frame);
+  if (ret == 0) {
+	got_frame = 1;
+  }
+}
+  
 
 #ifdef USE_AVRESAMPLE// libav's AVFrame structure does not contain a 'channels' field
 if (ret >= 0 && got_frame) {
 #else
-if (ret >= 0 && got_frame && av_frame_get_channels(frame)>0) {
+if (ret >= 0 && got_frame && frame->ch_layout.nb_channels>0) {
 #endif
 int ch, plane_size;
 int planar = av_sample_fmt_is_planar(avctx->sample_fmt);
@@ -151,11 +158,13 @@ void FFmpegDecoderAudio::open(AVStream *
 return;
 
 m_stream = stream;
-m_context = stream->codec;
-
-m_in_sample_rate = m_context->sample_rate;
-m_in_nb_channels = m_context->channels;
-m_in_sample_format = m_context->sample_fmt;
+	AVCodecParameters* avp = stream->codecpar;
+const AVCodec * p_codec = avcodec_find_decoder(avp->codec_id);
+	m_context = avcodec_alloc_context3(p_codec);	  
+
+m_in_sample_rate = avp->sample_rate;
+m_in_nb_channels = avp->channels;
+m_in_sample_format = ((AVSampleFormat)(avp->format));
 
 AVDictionaryEntry *opt_out_sample_rate = av_dict_get( *parameters->getOptions(), "out_sample_rate", NULL, 0 );
 if ( opt_out_sample_rate )
@@ -210,11 +219,10 @@ printf("### CONVERTING from sample forma
 }
 
 // Check stream sanity
-if (m_context->codec_id == AV_CODEC_ID_NONE)
+if (avp->codec_id == AV_CODEC_ID_NONE)
 throw std::runtime_error("invalid audio codec");;
 
 // Find the decoder for the audio stream
-AVCodec * const p_codec = avcodec_find_decoder(m_context->codec_id);
 
 if (p_codec == 0)
 throw std::runtime_error("avcodec_find_decoder() failed");
Index: openscenegraph-3.6.5+dfsg1/src/osgPlugins/ffmpeg/FFmpegPacket.hpp
===
--- openscenegraph-3.6.5+dfsg1.orig/src/osgPlugins/ffmpeg/FFmpegPacket.hpp
+++ openscenegraph-3.6.5+dfsg1/src/osgPlugins/ffmpeg/FFmpegPacket.hpp
@@ -42,7 +42,7 @@ namespace osgFFmpeg
 void clear()
 {
 if (packet.data != 0)
-av_free_packet(&packet);
+av_packet_unref(&packet);
 
 release();
 }


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25

[GCS]

On Tue, Sep 20, 2022 at 7:26 PM Bill Deegan  wrote:
> Not sure I entirely understand.
> Are you saying that SCons 4.4.0 is installing something in /usr/local/bin 
> instead of /usr/bin/ ?
 Yes, all executables go to /usr/local/bin directory.

> What command are you using to install SCons which is causing this?
 I downloaded the Git tag 4.4.0 from GitHub. Then:
$ tar zxf 4.4.0.tar.gz
$ cd scons-4.4.0/
$ touch scons.1 sconsign.1 scons-time.1
$ mkdir out/
$ python3 setup.py install --prefix=/usr
--install-data=/usr/share/man/man1/ --root=out/

Output ends with:
reating out/usr/share
creating out/usr/share/man
creating out/usr/share/man/man1
copying scons.1 -> out/usr/share/man/man1/.
copying scons-time.1 -> out/usr/share/man/man1/.
copying sconsign.1 -> out/usr/share/man/man1/.
running install_egg_info
Copying SCons.egg-info to
out/usr/local/lib/python3.10/dist-packages/SCons-4.4.0-py3.10.egg-info
running install_scripts
Installing scons script to out/usr/local/bin
Installing scons-configure-cache script to out/usr/local/bin
Installing sconsign script to out/usr/local/bin

Additional info: python3 --version
Python 3.10.7

Currently I don't know where the additional local subdirectory comes from.

Regards,
Laszlo/GCS

Bug#1019744: khal: Can't create an event without specifying the timezone

[Martin Dosch]

Package: khal
Version: 1:0.10.4~ds-3
Followup-For: Bug #1019744
X-Debbugs-Cc: mar...@mdosch.de

Dear Maintainer,

while I can easily work around by specifying the timezone when adding events on
the CLI the TUI interface ikhal fails when saving an event:

ikhal
/usr/lib/python3/dist-packages/khal/khalendar/khalendar.py:153:
PytzUsageWarning: The localize method is no longer necessary, as this time zone
supports the fold attribute (PEP 495). For more details on migrating to a PEP
495-compliant implementation, see https://pytz-deprecation-
shim.readthedocs.io/en/latest/migration.html
  localized_events = self.get_localized(localize(start), localize(end))
/usr/lib/python3/dist-packages/khal/khalendar/event.py:541: PytzUsageWarning:
The localize method is no longer necessary, as this time zone supports the fold
attribute (PEP 495). For more details on migrating to a PEP 495-compliant
implementation, see https://pytz-deprecation-
shim.readthedocs.io/en/latest/migration.html
  start_local_datetime = self._locale['local_timezone'].localize(
/usr/lib/python3/dist-packages/khal/khalendar/event.py:543: PytzUsageWarning:
The localize method is no longer necessary, as this time zone supports the fold
attribute (PEP 495). For more details on migrating to a PEP 495-compliant
implementation, see https://pytz-deprecation-
shim.readthedocs.io/en/latest/migration.html
  end_local_datetime = self._locale['local_timezone'].localize(
/usr/lib/python3/dist-packages/khal/khalendar/event.py:546: PytzUsageWarning:
The localize method is no longer necessary, as this time zone supports the fold
attribute (PEP 495). For more details on migrating to a PEP 495-compliant
implementation, see https://pytz-deprecation-
shim.readthedocs.io/en/latest/migration.html
  day_start = self._locale['local_timezone'].localize(
/usr/lib/python3/dist-packages/khal/khalendar/event.py:549: PytzUsageWarning:
The localize method is no longer necessary, as this time zone supports the fold
attribute (PEP 495). For more details on migrating to a PEP 495-compliant
implementation, see https://pytz-deprecation-
shim.readthedocs.io/en/latest/migration.html
  day_end = self._locale['local_timezone'].localize(
/usr/lib/python3/dist-packages/khal/khalendar/khalendar.py:162:
PytzUsageWarning: The localize method is no longer necessary, as this time zone
supports the fold attribute (PEP 495). For more details on migrating to a PEP
495-compliant implementation, see https://pytz-deprecation-
shim.readthedocs.io/en/latest/migration.html
  self._backend.get_localized_calendars(localize(start), localize(end)),
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/khal/ui/__init__.py", line 1358, in
start_pane
loop.run()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 287, in run
self._run()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 385, in _run
self.event_loop.run()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 790, in run
self._loop()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 827, in _loop
self._watch_files[fd]()
  File "/usr/lib/python3/dist-packages/urwid/raw_display.py", line 416, in

wrapper = lambda: self.parse_input(
  File "/usr/lib/python3/dist-packages/urwid/raw_display.py", line 515, in
parse_input
callback(processed, processed_codes)
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 412, in
_update
self.process_input(keys)
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 513, in
process_input
k = self._topmost_widget.keypress(self.screen_size, k)
  File "/usr/lib/python3/dist-packages/urwid/wimp.py", line 651, in keypress
return self._current_widget.keypress(size, key)
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 1135, in
keypress
return self.body.keypress( (maxcol, remaining), key )
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 2316, in
keypress
key = w.keypress((mc,) + size[1:], key)
  File "/usr/lib/python3/dist-packages/khal/ui/editor.py", line 530, in
keypress
return super().keypress(size, key)
  File "/usr/lib/python3/dist-packages/khal/ui/widgets.py", line 376, in
keypress
key = super().keypress(size, key)
  File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 968, in keypress
key = focus_widget.keypress((maxcol,),key)
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 2316, in
keypress
key = w.keypress((mc,) + size[1:], key)
  File "/usr/lib/python3/dist-packages/urwid/wimp.py", line 543, in keypress
self._emit('click')
  File "/usr/lib/python3/dist-packages/urwid/widget.py", line 461, in _emit
signals.emit_signal(self, name, self, *args)
  File "/usr/lib/python3/dist-packages/urwid/signals.py", line 265, in emit
result |= self._call_callback(callback, user_arg, user_args, args)
  File "/usr/lib/python3/dist-packages/urwid/signals.py", line 295, in
_call_callback
return bool(callback(

Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25

[Bill Deegan]

Not sure I entirely understand.
Are you saying that SCons 4.4.0 is installing something in /usr/local/bin
instead of /usr/bin/ ?
What command are you using to install SCons which is causing this?

On Tue, Sep 20, 2022 at 9:41 AM László Böszörményi (GCS) 
wrote:

> On Sun, Sep 18, 2022 at 6:42 PM Bill Deegan 
> wrote:
> > SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python
> 3.10.
> > The latest SCons 4.4.0 is available and works fine with Python 3.10
>  Actually it's not a compatibility issue, but a behaviour change with
> Python 3.10 as I know. It (or some module) now installs binaries into
> /usr/local/bin instead of the normal /usr/bin path.
> Packaged SCons 4.4.0 and it fails the same way due to installing
> binaries under /usr/local/bin directory. For the moment I don't know
> how to skip 'local' from the installation path, but will move back
> binaries directly after installation.
>
> Regards,
> Laszlo/GCS
>

Bug#1020376: Please update to latest upstream version

[Michael Biebl]

Source: glibmm2.4
Version: 2.66.5-1
Severity: wishlist

Hi,

the upcoming eiciel 0.10.0 which will be compatible with nautilus 43,
requires not only gtkmm4 (which is in NEW, thanks!), but also a newer
glibmm. From meson.build:

giomm = dependency('giomm-2.68', version: '>= 2.68')

The latest version in Debian is 2.66.5, the latest upstream version
2.74.0.

Would be great to have a newer glibmm available so I can start
preparing eiciel 0.10.0.

Regards,
Michael



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

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

Bug#1020375: opengv: binary-all FTBFS

[Adrian Bunk]

Source: opengv
Version: 1.0+1git91f4b1-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=opengv&arch=all&ver=1.0%2B1git91f4b1-3&stamp=1661457294&raw=0

...
0% tests passed, 18 tests failed out of 18

Total Test time (real) =   0.03 sec

The following tests FAILED:
  1 - test_absolute_pose (Not Run)
  2 - test_absolute_pose_sac (Not Run)
  3 - test_noncentral_absolute_pose (Not Run)
  4 - test_noncentral_absolute_pose_sac (Not Run)
  5 - test_multi_noncentral_absolute_pose_sac (Not Run)
  6 - test_relative_pose (Not Run)
  7 - test_relative_pose_rotationOnly (Not Run)
  8 - test_relative_pose_rotationOnly_sac (Not Run)
  9 - test_relative_pose_sac (Not Run)
 10 - test_noncentral_relative_pose (Not Run)
 11 - test_noncentral_relative_pose_sac (Not Run)
 12 - test_multi_noncentral_relative_pose_sac (Not Run)
 13 - test_eigensolver_sac (Not Run)
 14 - test_triangulation (Not Run)
 15 - test_eigensolver (Not Run)
 16 - test_point_cloud (Not Run)
 17 - test_point_cloud_sac (Not Run)
 18 - test_Sturm (Not Run)
Errors while running CTest
make[1]: *** [Makefile:74: test] Error 8

Bug#1019334: Fwd: Bug#1019334: Webkit2gtk - Bug Report

[Henning Sprang]

On Thu, Sep 15, 2022 at 10:34 AM Alberto Garcia  wrote:

>
> On Wed, Sep 07, 2022 at 04:14:20PM +0200, Henning Sprang wrote:
>
> > I have massive problems with Webbrowsers constantly crashing as soon
> > as I do anything serious on webpages with JavaSCript in them.
>
> Does it happen with all of them?
>

At least all those I tried so far, that is Firefox, Chrome plus the
crashing of the gnome-shell that I didn't report before but is something I
noticed after looking a bit more into it.

Firefox seems to be crashing faster... e.g. when running in Gnome, I just
tried to get a saved password from it to try the same site in epiphany as
you suggest belos, and it was a challenge to get that far before it crashed
again.

Then I switched to LXDE, here it didn't happen that fast, but after some
"casual browsing" on JS heavy sites like Mattermost and Jira/Confluence it
also crashed after less then 5 minutes.



>
> What exact CPU model do you have? (see 'model name' in /proc/cpuinfo).
>

It's in a virtualBox VM. The line in cpuinfo is this:

model name : Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz


>
> Try also running epiphany from a terminal like this:
>
> $ JavaScriptCoreUseJIT=0 epiphany
>

> Does it also crash?
>

Yes, but it shows a bit different behaviour then Firefox - at first it
doesnt directly crash, but the Screen freezes, so it shows only the
rendered website, but I cannot interact with it, the mouse pointer doesnT
change anymore when going over links, and clicking also has no effect,
and after a while the tabs are crashing. But different than Firefox not the
whole application, only the tabs.

That was the behaviour on LXDE.

When running in Gnome, after a minute the gnome shell seems to restart
again (there is some flickering that looks the same as when I do resatrt it
intentionally) and then right now in my recent test even the whole gnome
session crashed and logged me out.

I also installed a recent bunch of updates and had some hope it would
improve the situation but It might even be a bit worse today than a week
ago...

I'm also going to update the machine to testing now and see if that changes
anything. (I have a saved state that I can revert to if you need more info!)
Please let me know if I can provide any further info about the system, logs
etc.

Bug#1018882: ruby-vcr: build times out after 150 minutes

[Adrian Bunk]

Control: retitle -1 ruby-vcr FTBFS on IPV6-only buildds

On Thu, Sep 01, 2022 at 02:08:36PM +0200, Paul Gevers wrote:
> Source: ruby-vcr
> Version: 6.0.0+really5.0.0-2
> Severity: serious
> Tags: ftbfs
> Justification: ftbfs
> 
> Dear maintainers,
> 
> The last upload failed to build from source.
> 
> https://buildd.debian.org/status/fetch.php?pkg=ruby-vcr&arch=all&ver=6.0.0%2Breally5.0.0-3&stamp=1661725468&raw=0
> 
>   when VCR.real_http_connections_allowed? is returning false
> does not allow real HTTP requests or record them
> when ignore_hosts is configured to "127.0.0.1", "localhost"
> E: Build killed with signal TERM after 150 minutes of inactivity

This was on x86-conova-01, which is IPV6-only.
Looking at the "127.0.0.1" above, this is likely relevant.

> Paul

cu
Adrian

Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25

[GCS]

On Sun, Sep 18, 2022 at 6:42 PM Bill Deegan  wrote:
> SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python 3.10.
> The latest SCons 4.4.0 is available and works fine with Python 3.10
 Actually it's not a compatibility issue, but a behaviour change with
Python 3.10 as I know. It (or some module) now installs binaries into
/usr/local/bin instead of the normal /usr/bin path.
Packaged SCons 4.4.0 and it fails the same way due to installing
binaries under /usr/local/bin directory. For the moment I don't know
how to skip 'local' from the installation path, but will move back
binaries directly after installation.

Regards,
Laszlo/GCS

Bug#1020374: RM: solvespace [s390x] -- ANAIS; Removed from source package due to test failure

[Ryan Pavlik]

Package: ftp.debian.org
Severity: normal

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

[Richard Lewis]

Not sure this will help you, but no-one else replied so: i have previously
looked at the logcheck code and i didnt see any way for there to be a bug
where a rule matches but have output be sent anyway - (the way the paranoid
level is implemented is less clear, but that does not apply here as far as
i can see): the relevent code in logcheck just uses grep and emails
anything not matched.

So this will be an issue in your rules somehow - although i dont see
anything wrong either.

Can you rule out a timing issue where the rule was added after the cron job
started, eg because the file was sitting unsaved in an editor? - logcheck
copies all the rules when it starts. i have done this myself many times.

The one small thing that jumped out to me is that the rule in question is
not terminated by a $  - Could there be some whitespace issues here?
(logcheck doesnt care what the rule looks like. but it does do some
pre-processing to remove trailing whitespace - i dont recall but i suspect
logcheck-test does not do that, and it definitely does not understand the
(bizarre) exclusions and counter exclusions of paranoid rules that logcheck
uses - i would not rely on logcheck-test).

the other thing is that the . are not escaped. (i dont see why that should
matter here)

i'd recommend copying the syslog file and testing the rule matches with grep

sorry for not being more helpful

On Sun, 4 Sep 2022, 16:32 James Graves, 
wrote:

> Package: logcheck
> Version: 1.3.23
> Severity: normal
>
> I received an email for some chatter from systemd:
>
> System Events
> =-=-=-=-=-=-=
> Aug 30 14:00:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
>
> And indeed this line does exist in /var/log/syslog:
>
>
> However, this is already matched by a rule:
>
> # cd /etc/logcheck/ignore.d.server/
> # grep Cleanup local-systemd
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Starting
> Cleanup of Temporary Directories...$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Started
> Cleanup of Temporary Directories.$
> ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Finished
> Cleanup of Temporary Directories.
>
> And the rule _does_ work:
>
> # logcheck-test -l /var/log/syslog -r local-systemd | grep Cleanup
> Aug 28 13:58:24 lxc2 systemd[1]: Starting Cleanup of Temporary
> Directories...
> Aug 28 13:58:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
> Aug 29 13:59:24 lxc2 systemd[1]: Starting Cleanup of Temporary
> Directories...
> Aug 29 13:59:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
> Aug 30 14:00:24 lxc2 systemd[1]: Starting Cleanup of Temporary
> Directories...
> Aug 30 14:00:24 lxc2 systemd[1]: Finished Cleanup of Temporary Directories.
>
> So the rule to ignore the 'Finished' line on August 30th, 14:00:24 does
> work,
> and yet the email was sent anyway.
>
> This is not the only occurence, I've also seen the same thing with the line
> "Starting Daily man-db regeneration..." from systemd on the same system.
> But in
> general, the hundreds of other rules I've created work fine.
>
> I haven't altered how logcheck is run via cron or changed the
> configuration files
> from the default installed by Debian.
>
> Thanks for looking at this!
>
>
> -- System Information:
> Debian Release: 11.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-17-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages logcheck depends on:
> ii  adduser   3.118
> ii  cron [cron-daemon]3.0pl1-137
> ii  lockfile-progs0.1.18
> ii  logtail   1.3.23
> ii  mime-construct1.11+nmu3
> ii  rsyslog [system-log-daemon]   8.2102.0-2+deb11u1
> ii  ssmtp [mail-transport-agent]  2.64-10
>
> Versions of packages logcheck recommends:
> ii  logcheck-database  1.3.23
>
> Versions of packages logcheck suggests:
> pn  syslog-summary  
>
> -- no debconf information
>
> --
>
>
> This
>  transmission contains information from Delta Mobile Systems, Inc.,
> that
>  may be confidential and/or privileged.  The information is intended
> for
>  the exclusive use of the planned recipient.  If you are not the
> intended recipient, be advised that any disclosure, copying,
> distribution
> or other use of this information is strictly
> prohibited.  If you have
> received this transmission in error, please
> notify the sender immediately
> and delete this communication and any
> attachments without making any
> copies thereof.
>
>

Bug#1019743: u-boot-menu: u-boot-update should read kernel parameters from /etc/kernel/cmdline

[Christopher Obbard]

Hi Arnaud,

> That sounds like an interesting thing to have indeed, I actually
> started 
> working on this a while ago but didn't have the time/incentive to
> push 
> it further.
> 
> Attaching the (draft) patch I came up with in case it can help moving
> forward.

Thanks for the patch, I cleaned it up a little and pushed it to
https://salsa.debian.org/debian/u-boot-menu/-/merge_requests/9

Let's hope for some feedback there.

Cheers!
Chris

Bug#1017015: [Debian-on-mobile-maintainers] Bug#1017015: gnome-console: bugs after switch to GTK4

[Jeremy Bicha]

On Tue, Sep 20, 2022 at 12:26 PM Arnaud Ferraris  wrote:
> That sounds good, thanks for tracking those issues! IIUC the workaround
> for the remaining issue is using middle-click-paste, is that right?

Yeah, that's probably the easiest workaround. There are a few other
ideas on the upstream bug.

Thank you,
Jeremy Bicha

Bug#1017015: [Debian-on-mobile-maintainers] Bug#1017015: gnome-console: bugs after switch to GTK4

[Arnaud Ferraris]

Hi Jeremy,

Le 20/09/2022 à 00:45, Jeremy Bicha a écrit :

Control: retitle -1 gnome-console: copying won't work if end of line is selected

I intend to lower the severity of this bug to Important once gtk4
migrates to Testing

The Ctrl+Shift bug is fixed in gtk4; the open link bug was fixed in
vte2.91. That only leaves one significant known issue which can be
worked around.


That sounds good, thanks for tracking those issues! IIUC the workaround 
for the remaining issue is using middle-click-paste, is that right?


Cheers,
Arnaud



Thank you,
Jeremy Bicha

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

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Russ Allbery]

Guillem Jover  writes:

> Ok, I've prepared the attached incremental patch, which only switches
> from paragraph(s) to stanza(s) all over the place.

Thanks, applied.

> I've updated all the specs for consistency. I've updated the footnote to
> swap the preference and to mention paragraph is now discouraged
> nomenclature. I've also updated all «id»s out of consistency, which
> might break links, so I can revert that if you'd prefer.

It looks like it was primarily in the copyright-format specification.  I
think that's fine; we haven't historically tried hard to preserve anchors,
and if we ever did, we should probably use some scheme to assign stable
anchors rather than using the text of the heading.

> And I've preserved the (upper) casing for one of the titles
> (“Stand-alone License Stanza”, although that was not consistent with the
> other titles, such as “Files stanza”, I'm happy to lower case that one).

I personally have been convinced by a co-worker who did the research that
one should stop using title-casing in technical documents, since it's
mostly a US convention, US readers don't mind lowercase, and title-casing
can look weird to European readers.  But that's a fix for another day.

> I've gone one by one, but please review carefully as I might have
> perhaps switched in excess!

Reviewed, and also checked for remaining uses of "paragraph."  Everything
looked good.

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

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Alberto Garcia]

On Fri, Sep 16, 2022 at 10:18:32AM +0900, Dominique MARTINET wrote:

> Alberto Garcia wrote on Wed, Aug 17, 2022 at 10:31:22AM +:
> > Thanks, I just forwarded the bug upstream, I'll try to reproduce it
> > myself this or next week.
> 
> I've also been observing similar crashes on aarch64 bullseye package
> and using bookworm is not an option for me (thanks to proprietary
> drivers...)
> 
> 
> The traces are slightly different:

Sorry for the late reply, and thanks! I think the traces are useful,
I added them to the upstream bug report and I'll try to discuss them
with the development team.

By the way 2.38.0 just came out, it'll probably be backported soon to
bullseye.

Berto

Bug#1020342: autopkgtest's own tests fail if current git commit contains the word "stderr"

[Simon McVittie]

Package: autopkgtest
Version: 5.25
Severity: normal

While trying to get 5.26 released:

14:37:47 O: 
==
14:37:47 O: FAIL: test_apt_source (__main__.DockerRunner)
14:37:47 O: apt source
14:37:47 O: 
--
14:37:47 O: Traceback (most recent call last):
14:37:47 O:   File "/builds/smcv/autopkgtest/./tests/autopkgtest", line 3085, 
in test_apt_source
14:37:47 O: self.assertNotIn(' stderr ', err)
14:37:47 O: AssertionError: ' stderr ' unexpectedly found in '[ huge string 
redacted ]'

where the offending output is something like this:

14:21:10 E: # autopkgtest [14:19:55]: starting date: 2022-09-20
14:21:10 E: # autopkgtest [14:19:55]: git checkout: f2bc0dd tests: Avoid 
polluting stderr with sudo output

(from https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/202)

This is silly. We should have a better way to get information out of
autopkgtest than screen-scraping its stdout and stderr, which as you can
see here is prone to false-positives.

smcv

Bug#1019743: u-boot-menu: u-boot-update should read kernel parameters from /etc/kernel/cmdline

[Arnaud Ferraris]

On Tue, 20 Sep 2022 16:28:38 +0200 Arnaud Ferraris 
 wrote:

Hi,

That sounds like an interesting thing to have indeed, I actually started 
working on this a while ago but didn't have the time/incentive to push 
it further.


Attaching the (draft) patch I came up with in case it can help moving 
forward.


Hmm, since this patch is about 1 year old, attaching the rebased version 
so it applies seamlessly on current master.


Cheers,
Arnaud



Cheers,
ArnaudFrom 03db7668f3c371a5a2d564ca14c9e671c6a754b3 Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris 
Date: Tue, 14 Sep 2021 20:36:54 +0200
Subject: [PATCH] u-boot-update: honor /etc/kernel/cmdline

---
 u-boot-update   | 12 ++--
 u-boot-update.8 |  7 ---
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/u-boot-update b/u-boot-update
index 69da211..41fd0de 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -90,12 +90,21 @@ U_BOOT_DEFAULT="${U_BOOT_DEFAULT:-l0}"
 U_BOOT_ENTRIES="${U_BOOT_ENTRIES:-all}"
 U_BOOT_TIMEOUT="${U_BOOT_TIMEOUT:-50}"
 U_BOOT_MENU_LABEL="${U_BOOT_MENU_LABEL:-${PRETTY_NAME:-Debian GNU/Linux kernel}}"
-U_BOOT_PARAMETERS="${U_BOOT_PARAMETERS:-ro quiet}"
 U_BOOT_FDT_DIR="${U_BOOT_FDT_DIR:-/usr/lib/linux-image-}"
 U_BOOT_FDT_OVERLAYS="${U_BOOT_FDT_OVERLAYS:-}"
 U_BOOT_FDT_OVERLAYS_DIR="${U_BOOT_FDT_OVERLAYS_DIR:-/boot/dtbo}"
 U_BOOT_INITRD="${U_BOOT_INITRD:-initrd.img}"
 
+if [ -z "${U_BOOT_PARAMETERS}" ] && [ -f /etc/kernel/cmdline ]
+then
+	U_BOOT_PARAMETERS="$(cat /etc/kernel/cmdline | sed -e 's/root=[^[:space:]]*//' -e 's/^[[:space:]]*//')"
+	if [ -z "${U_BOOT_ROOT}" ]
+	then
+		U_BOOT_ROOT="$(cat /etc/kernel/cmdline | sed -re 's/.*(root=[^[:space:]]*).*/\1/')"
+	fi
+fi
+U_BOOT_PARAMETERS="${U_BOOT_PARAMETERS:-ro quiet}"
+
 # Find parameter for root from fstab
 if [ -z "${U_BOOT_ROOT}" ]
 then
@@ -267,4 +276,3 @@ done
 _NUMBER=""
 
 Update "${_U_BOOT_DIRECTORY}/extlinux.conf" "${_CONFIG}"
-
diff --git a/u-boot-update.8 b/u-boot-update.8
index dfc3cd7..6536c6e 100644
--- a/u-boot-update.8
+++ b/u-boot-update.8
@@ -78,9 +78,10 @@ Otherwise, it defaults to 'Debian GNU/Linux, kernel'.
 .IP "U_BOOT_PARAMETERS=""\fBro quiet\fR""" 4
 This variable specifies additional boot parameters
 that are appended to each kernel entry.
-Value is an arbitrary string,
-default is 'ro quiet'
-(except for recovery entries, where quiet is avoided).
+Value is an arbitrary string, default is the content
+of /etc/kernel/cmdline, or 'ro quiet'
+(except for recovery entries, where quiet is avoided) if
+this file is not present or empty.
 
 .IP "U_BOOT_ROOT=""\fBroot\fR=\fIDEVICE\fR""" 4
 This variable specifies the root partition.
-- 
2.35.1

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Russ Allbery]

Holger Levsen  writes:
> On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote:

>> I'm fine with this change, but as Sam points out, the deeper point here
>> is that Policy doesn't apply to udebs.  This is the whole point of
>> udebs.

> When you say it like this, it sounds to strong to me, if it were written in
> -policy.

> .udebs are allowed to break some rules, but not all. it's not ok to put
> Microsoft Word in an udeb in main. there are many other rules .debs need to
> comply to.

Yeah, apologies, this is just shorthand for "udebs are allowed to ignore
the technical bits of Policy that don't work for them."  Not that they can
do absolutely anything they want.  :)

>> udebs (stripped-down binary packages used by the Debian Installer) do
>> not comply with all of the requirements discussed here. See the Debian
>> Installer internals manual for more information about them.
>  
> this sounds good to me.

Okay, great, thanks.  I'll try to put together a proposed patch soon.

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

Bug#1020341: RFS: fast-float/3.5.1-1 [ITP] -- Implementation of the C from_chars functions for float and double types

[Daichi Fukui]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fast-float":

 * Package name : fast-float
   Version  : 3.5.1-1
   Upstream contact : Daniel Lemire 
 * URL  : https://github.com/fastfloat/fast_float
 * License  : Expat or Apache
 * Vcs  : [TBD]
   Section  : devel

Rationale for this ITP:

c4core depends on fast-float [0].
rapidyaml [1] depends on c4core.
Moreover, jsonnet [2] depends on rapidyaml.

[0] https://github.com/biojppm/c4core/blob/v0.1.9/.gitmodules
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
[2] https://tracker.debian.org/pkg/jsonnet

See #1019961 for details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019961

---

The source builds the following binary packages:

  fast-float - Implementation of the C++ from_chars functions for float and
double types

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

  https://mentors.debian.net/package/fast-float/

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/fast-float/fast-float_3.5.1-1.dsc

Changes for the initial release:

 fast-float (3.5.1-1) unstable; urgency=low
 .
   * Initial release. Closes: #1019961

Regards,

Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged

[Gabriel Filion]

Hi Alexey,

On 2022-09-17 15 h 44, Alexey Vazhnov wrote:

I've tested Smokeping 2.8.2 in `Devuan GNU/Linux 5 (daedalus/ceres)` (based on 
Debian testing 12 bookworm), it works
without errors.

How to:

I created a .deb package in `Debian GNU/Linux 11 (bullseye)` by commands like 
these:

```
sudo apt-get -V --no-install-recommends install devscripts git-buildpackage 
equivs
gbp clone 'https://salsa.debian.org/debian/smokeping.git'
cd ./smokeping
mk-build-deps --install --root-cmd sudo --remove
git status
# Remove new untracked files:
rm smokeping-build-deps_2.8.2-1_amd64.buildinfo 
smokeping-build-deps_2.8.2-1_amd64.changes
gbp buildpackage
```


>
> No `libobject-result-perl` installed, but Smokeping works!

Very nice, thanks for the test!  also TIL mk-build-deps :)


and installed `smokeping_2.8.2-1_all.deb` together with Nginx, I took 
configuration from
https://gitlab.com/vazhnov/smokeping_nginx


ah, we don't have an example configuration for nginx in the package, 
which is a shame.
maybe we should add one from there if it works directly with debian? the 
best.conf file looks like a good example candidate. what do you think?