Bug#998779: bs1770gain: bashism in configure script

[Peter Belkner]

Hi Petter,

thank you for the clarification!

Best regards

Peter



On 20.09.2022 07:11, Petter Reinholdtsen wrote:

[Peter Belkner]

is the intention of your patch to substitute all single comparison
singes ('=') by double comparison singes ('==')?

My intention with the patch was the other way, to replace 'test x == y'
with 'test x = y', as he latter is POSIX notation, while the former is
bash notation.  See
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html >


I'm asking because on my site 'configure' is derived an hence
unfortunately I cannot simply apply your patch.

Note, my patch was for configure.ac, the source of configure.

Bug#998779: bs1770gain: bashism in configure script

[Petter Reinholdtsen]

[Peter Belkner]
> is the intention of your patch to substitute all single comparison 
> singes ('=') by double comparison singes ('==')?

My intention with the patch was the other way, to replace 'test x == y'
with 'test x = y', as he latter is POSIX notation, while the former is
bash notation.  See
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html >

> I'm asking because on my site 'configure' is derived an hence 
> unfortunately I cannot simply apply your patch.

Note, my patch was for configure.ac, the source of configure.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

https://github.com/systemd/systemd/issues/24758

Done,  I hope I did it right.

Have a nice day.

El 12/9/22 a las 05:19, Michael Biebl escribió:
In this case, can you please try with the latest systemd version v251 
and if the problem persists, raise it at

https://github.com/systemd/systemd/issues

Regards,
Michael

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

[Russ Allbery]

Sean Whitton  writes:
> On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote:
>> Sean Whitton  (2021-08-12):
>>> On Tue 27 Jul 2021 at 08:41AM -06, Sam Hartman wrote:

 So, it seems fairly obvious to me that Standards-Version is important
 for packages that produce both debs and udebs.
 I'm assuming the focus of our discussion then is on source packages that
 only produce udebs.
 Have I got that right?

 By definition, most of the policy that affects binary packages does
 not inherently apply to udebs.  As I understand it, that's kind of
 the point of udebs.

>>> Would you agree with this?  You're only asking to stop seeing warnings
>>> about S-V for source packages which produce only udebs?

>> Yes, that looks good to me: source packages (also) producing debs would
>> deserve a rightful nag.

> I believe that we failed to consider udebs when we made the change which
> made S-V mandatory.  I propose we remove the requirement for S-V in
> udebs and source packages producing only udebs, until and unless someone
> provides a positive argument why S-V ought to be mandatory in these
> cases too.

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.

I didn't go back and read the history of this bug, 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"

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

Bug#1020326: RFS: libfilezilla/0.39.1-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : libfilezilla
   Version  : 0.39.1-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla31 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.39.1-1.dsc

Changes since the last upload:

 libfilezilla (0.39.1-1) unstable; urgency=medium
 .
   * New upstream version 0.39.1
   * Soname bump rename package to libfilezilla31

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

[Russ Allbery]

Guillem Jover  writes:

> This was brought up on debian-devel, and I think it needs to be
> updated/corrected in the policy manual:

> On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote:
>> On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote:

>>> Policy states:
>>> "Removing a required package may cause your system to become totally
>>> broken and you may not even be able to use dpkg to put things back, so
>>> only do so if you know what you are doing."

>> That seems wrong, or inaccurate at best. dpkg should never depend on
>> anything that is not part of the pseudo-essential set (strictly
>> speaking only Essential:yes + awk-virtual), or that it depends on
>> explicitly. So as long as a package has not been forced out, dpkg must
>> work.

>> Removing a required package (that is not Essential:yes) might indeed
>> render your system broken, but what broken means or in what context is
>> not qualified there. This could apply to systems that get booted for
>> example, but not to chroots. A package that relies on another package
>> that is Priority:required and not Essential:yes, and that it does not
>> depend on, is just broken.

I agree with this analysis, and we shouldn't be saying things about dpkg
that aren't true.

What Policy says right now is:

Packages which are necessary for the proper functioning of the system
(usually, this means that dpkg functionality depends on these
packages). Removing a required package may cause your system to become
totally broken and you may not even be able to use dpkg to put things
back, so only do so if you know what you are doing.

Systems with only the required packages installed have at least enough
functionality for the sysadmin to boot the system and install more
software.

The second paragraph seems roughly correct.  The first paragraph is
clearly at least partially false.  What should it say instead?  I'm not
sure the second paragraph is enough.  I feel like we should stress that
you may put your system into a surprising state by removing required
packages, and may have difficulties recovering because standard tools are
missing, even though dpkg should continue to wrok.

Do you have any suggestions for what an accurate statement would be?

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

Bug#1020323: debian-policy: document DPKG_ROOT

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

>  * where to document this? Other variables set for maintainer scripts
>like DPKG_MAINTSCRIPT_PACKAGE or DPKG_MAINTSCRIPT_ARCH do not seem to
>be documented either even though (according to codesearch.d.n) they
>are used in hundreds of places

In general, Policy doesn't need to be a copy of dpkg's documentation, so I
don't think we need to list everything that dpkg makes available.

The important thing that Policy is adding isn't to catalog the facilities
available.  It's to tell you *when* to use those facilities.  In the case
of some of those variables, that's the obvious "whenever it's convenient
to get that information from an environment variable for whatever you're
trying to do," and Policy doesn't need to say anything about it.  But
here, some packages *have* to use this environment variable or they will
be buggy.  That's the sort of thing Policy should describe.

I would tend to add a section on bootstrapping support (since that's what
this is for) to chapter 6 at the end.  It could just talk about DPKG_ROOT
for now and we can add any other maintainer script considerations that
come up there in the future.

>  * what about scope? The Essential:yes and build-essential package set
>are certainly a *must*. We need these to start building natively on a
>new architecture. But do we need more than those? Having apt would be
>handy but not strictly necessary (dpkg -i can always be used
>instead). Having an init system would be handy but not strictly
>necessary (can always boot with init=/bin/bash).

I think this is up to you to define, but we need to be able to describe
it.  Starting with essential and build-essential packages sounds great,
and Policy already defines both of those terms, so that's easy.  If you
need to add more packages, we will need to figure out how to describe them
without special-case listings of package names.

>  * what can maintainer scripts supporting DPKG_ROOT expect from the
>system on the outside? Are its package versions the same as the
>system inside the chroot? Is it even Debian? Right now we do all our
>tests such that the system on the outside is identical to the one we
>want to create the chroot for except that it is of the native
>architecture. But should such a restriction be placed in policy?

It sounds like you're not imposing any restrictions on the *package* here,
so there's no need to say anything unless at some point you need to do so.

The point of putting this in Policy is to provide guidance to the
packagers, not to the bootstrappers.  Presumably you already have other
documentation that you maintain about how to bootstrap Debian that spells
out what to do in what order; that's outside of Policy's remit.  What
Policy is trying to do is to define for packagers what interface they have
to implement, and DPKG_ROOT is now part of that interface.

So in other words, you can just say something like:

Maintainer scripts in essential or build-essential packages must
preface all paths they act on in maintainer scripts with an expansion
of the DPKG_ROOT environment variable.  This will normally be empty
(and thus normally will not change anything), but in some situations
it may be set to a bootstrapping path to tell packages to act under
that path instead of on the root file system.

That wording probably isn't quite right, but I think that's the general
idea.

>  * what about upgrades? We only want to create a chroot and some of our
>patches are made much simpler because we ignore upgrades. If newer
>package versions are required, the bootstrapper can just create a new
>chroot without upgrading anything.

If maintainers don't have to worry about this for upgrades, you can just
say so.  I think it's up to you whether you think that is important or
not.  I would be inclined to say that it's *safe* to add DPKG_ROOT to
paths even on upgrade actions, but you only *must* do so for maintainer
script actions that run during initial installation.

Thank you very much for starting this discussion!

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

Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532

[Russ Allbery]

Ansgar  writes:

> There is an updated version (RFC 5322) that should be used instead. 
> Notably RFC 5322 is more restrictive on the local part (whitespace and
> escape sequences are no longer allowed except as obsolete syntax).

> Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in
> local parts (and other places).  That should probably be allowed as
> well.

> So, Policy should probably:
>  - Refer to RFC 5322.
>  - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax").
>  - Allow the extensions from RFC 6532.

I agree with this as a general direction.  I think we could probably just
make the first and third changes without much trouble; my recollection
that not much was dropped between RFC 822 and RFC 5322 and the stuff that
was is highly, highly unlikely to be in use.

We're also quite safe in dropping the obsolete syntax in RFC 5322.  No one
is using source routing in email any more (I don't think it's worked on a
running mail system in decades), and I very much doubt anyone is using
CFWS in debian/control files in that way.  The only time I used to see
that was with people mangling addresses for dubious spam protection, which
we don't allow in Debian anyway.  I understand Bill's concern, but I'm not
worried about it here; the obsolete constructs are quite obsolete.

So, wording implementing the above three points is welcome.

As for your follow-up message to this bug, for better or worse Debian
pretty strongly assumes the "Full Name " syntax and I'm not
sure we should expect people to allow the full RFC 5322 syntax.  In
particular, you suggested name-addr, which is:

name-addr   =   [display-name] angle-addr

angle-addr  =   [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr

but we absolutely do not support CFWS (for those not familiar with RFC
5322, this is comment folding whitespace), only FWS.

display-name has a more obscure problem, which is that it allows quoted
strings, but I'm fairly sure that Debian software would break if we tried
to allow all the things that RFC 5322 allows inside quoted strings, and we
also would prefer people not use quotes if they're avoidable because not
all of our software deal with them correctly (and they're usually
unnecessary).  The main exception is if a person's name contains a comma,
which we deal with quite poorly and which we probably should fix, and
allowing quotes in that case is probably the right fix, but it's also
probably a difficult fix for a lot of deb822 parsers.

In other words, I'm in general on board with aligning with the latest
email standards, but I don't want to take that so far as to allow
unnecessary and rather baroque constructs we don't currently permit in
practice just because they're allowed in email headers.  We should go
stricter if anything, not more lenient.  Similarly for Uploaders, in
practice it should be a comma-separated list of the same syntax as
Maintainer, and we don't want to use constructs that introduce the
possibility of comments.

We certainly don't want to support groups, which we've never allowed and
which are quite obscure even in RFC 5322.  For those who have never seen
them, a group looks like:

Some Name:r...@debian.org,ea...@eyrie.org;

This has been formally supported in email since the beginning even though
essentially no one ever uses it.  About the only time you ever see a group
in practice is the empty group in:

Undisclosed Recipients:;

which shows up from time to time.

There is some definite merit to using the ABNF productions in RFC 5322,
but it's tricky to do because RFC 5322 allows comments almost everywhere,
and we allow comments basically only in display-name (and in display-name
don't even treat it as a comment, but instead as part of the person's
name).

So, in short, definitely open to patches here, and I agree that the
current Policy specification for Maintainer is both underspecified and
somewhat obsolete, but I think the patches should be conservative and not
introduce the stuff that RFC 5322 allows in headers but that we currently
don't support.

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

Bug#1020324: ITP: domdf-python-tools -- Helpful functions for Python

[Josenilson Ferreira da Silva]

Package: wnpp
Version: wnpp
Severity: wishlist
File: bug
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: domdf-python-tools
  Version : 3.4.0
  Upstream Author : Dominic Davis-Foste 
* URL : https://github.com/domdfcoding/domdf_python_tools
* License : MIT/X
  Programming Lang: Python
  Description : Helpful functions for Python

  Note:package is a dependency of this module: 
https://github.com/repo-helper/whey 

Bug#1020323: debian-policy: document DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Source: debian-policy
Version: 4.6.1.1
Severity: wishlist
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: jo...@debian.org, debian-cr...@lists.debian.org

Hi,

in [1] Russ asked us to submit a policy bug about DPKG_ROOT so here it
goes. :)

[1] https://lists.debian.org/874jx3yq8s@hope.eyrie.org

Here is one description of DPKG_ROOT from the dpkg man page:

DPKG_ROOT
Defined by dpkg on the maintainer script environment to indicate
which installation to act on (since dpkg 1.18.5).  The value is
intended to be prepended to any path maintainer scripts operate on.
During normal operation, this variable is empty.  When installing
packages into a different instdir, dpkg normally invokes maintainer
scripts using chroot(2) and leaves this variable empty, but if
--force-script-chrootless is specified then the chroot(2) call is
skipped and instdir is non-empty.

In practice this means that if (and only if) dpkg is called with
--root=X --force-script-chrootless then all maintainer scripts will be
called with the DPKG_ROOT variable set to X.

Why is this useful? In the very early days of a new architecture,
emulation support is either not available at all or too buggy to be
useful for any practical purposes.  After having cross-built the initial
package set, these packages need to be installed to create a chroot that
can then be used to continue building packages natively on the new
architecture, completing the early bootstrap process. But creating that
chroot requires package maintainer scripts to be run but we cannot
emulate the new architecture to run any of its binaries.

By installing packages with --force-script-chrootless, maintainer
scripts are called without being inside the chroot and thus they will
call the native binaries from the outside. To be able to know the chroot
directory they are supposed to operate on, the DPKG_ROOT variable is set
to the chroot directory. In practice, this means that if a maintainer
script ran this before:

chmod root:root "/path/to/file"

Then it now has to run

chmod root:root "$DPKG_ROOT/path/to/file"

More information about DPKG_ROOT can be found here:

 * 
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap#Proposal:_chrootless_maintscripts
 * https://debconf22.debconf.org/talks/23-what-is-dpkg_root-and-what-is-it-not/
 * https://lists.debian.org/166289720850.2390.3729551131862514967@localhost

I think there is no problem with letting policy describe what the
DPKG_ROOT variable being set to a non-empty string means for a
maintainer script. There is also no problem in documenting what the
whole point of this exercise is.

But there are also a lot of open questions for which I do not have any
answers yet:

 * where to document this? Other variables set for maintainer scripts
   like DPKG_MAINTSCRIPT_PACKAGE or DPKG_MAINTSCRIPT_ARCH do not seem to be
   documented either even though (according to codesearch.d.n) they are used in
   hundreds of places
 * what about scope? The Essential:yes and build-essential package set are
   certainly a *must*. We need these to start building natively on a new
   architecture. But do we need more than those? Having apt would be handy
   but not strictly necessary (dpkg -i can always be used instead). Having an
   init system would be handy but not strictly necessary (can always boot with
   init=/bin/bash).
 * what can maintainer scripts supporting DPKG_ROOT expect from the system on
   the outside? Are its package versions the same as the system inside the
   chroot? Is it even Debian? Right now we do all our tests such that the
   system on the outside is identical to the one we want to create the
   chroot for except that it is of the native architecture. But should such a
   restriction be placed in policy?
 * what about upgrades? We only want to create a chroot and some of our patches
   are made much simpler because we ignore upgrades. If newer package versions
   are required, the bootstrapper can just create a new chroot without
   upgrading anything.

Thank you for your consideration!

cheers, josch

Bug#1020312: usrmerge: systemd file disappearing

[Marco d'Itri]

On Sep 20, Vincent Danjean  wrote:

> Now that you point out this, it recalls me that years ago,
> I moved /lib/systemd/system/ to /etc/conffiles-out-etc/lib/systemd/system
> (so that the systemd configuration files are correctly tracked by etckeeper)
> and I put a /lib/systemd/system -> /etc/conffiles-out-etc/lib/systemd/system
> symlink.
> 
> So, I'm downgrading the severity. But as it is allowed
> to create symlinks to other part of the disk for directory,
> usrmerge should handle this case (or, at least, give a
> preeminent message about a strange situation)
Indeed, this should be handled. Let's have a look at the code:

# both source and dest are directories
if (-d $n and -d "/usr$n") {
# so they have to be merged recursively
my $rule = File::Find::Rule->mindepth(1)->maxdepth(1)->start($n);
while (defined (my $name = $rule->match)) {
convert_file($name, $later);
}
return;
}

# both source and dest are links
if (-l $n and -l "/usr$n") {
...
}

# the source is a link
if (-l $n) {
my $l = readlink($n);
return if $l eq "/usr$n";   # and it points to dest
fatal("Both $n and /usr$n exist");
}

# the destination is a link
if (-l "/usr$n") {
...
}

But -d is true also for a symlink which points to a directory, so the 
latter blocks are never reached!

And running File::Find::Rule this way on a symlink without a trailing 
/ returns no matches:

my $rule = File::Find::Rule->mindepth(1)->maxdepth(1)->start('/var/lock');
while (defined (my $name = $rule->match)) {
say $name;
}

So the content of the link target was not moved to /usr, and then
the link (/lib/systemd/system/) was just deleted during the final 
cleanup because at that point only valid links to their counterparts
in /usr are supposed to be left in the source directories.

In your case the expected outcome should have been a failure instead, 
because /lib/systemd/system/ was a link which did not point to 
/usr/lib/systemd/system/ :

fatal("Both $n and /usr$n exist");

(Also see the "CONFLICTS RESOLUTION MATRIX" section in the man page.)

While this bug is annoying and needs to be fixed, we had not noticed it 
in many years so apparently it is an highly unusual case.
And thankfully no files are lost and they can just be moved manually to 
the new directory.

Now I just need to figure out if the safest solution would be to move 
the "both source and dest are directories" block at the end or leave it 
there and make it ignore directories which are links.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1019660: console-setup: grep: warning: stray \ before #

[Vincent Lefevre]

Control: tags -1 patch

On 2022-09-13 12:42:11 +0200, Jakub Wilk wrote:
> With grep (>= 3.8), I'm getting this warning:
> 
>   # setupcon
>   grep: warning: stray \ before #

I've attached a patch to fix this issue and other grep usage issues.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Fix setupcon grep usage (for grep 3.8+).
Bug-Debian: https://bugs.debian.org/1019660
Author: Vincent Lefevre 
Last-Update: 2022-09-20

--- setupcon~	2022-05-26 22:47:37.0 +0200
+++ setupcon	2022-09-20 02:48:26.914726411 +0200
@@ -489,7 +489,7 @@
 for tty in \
 $(cat /etc/inittab /etc/init/* /etc/ttys 2>/dev/null \
 	| grep getty \
-| egrep '([[:blank:]]|^)tty([1-9][0-9]*|v[0-9a-f])([[:blank:]]|$)' \
+| grep -E '([[:blank:]]|^)tty([1-9][0-9]*|v[0-9a-f])([[:blank:]]|$)' \
 | sed -e '/^ *#/d' \
   -e 's/.*[[:blank:]]\(tty[1-9][0-9]*\).*/\1/' \
   -e 's/.*[[:blank:]]\(ttyv[0-9a-f]\).*/\1/')
@@ -775,7 +775,7 @@
 esac
 case \
 "`(stty -a \
-  | egrep '(^| )erase *=' \
+  | grep -E '(^| )erase *=' \
   | sed -e 's/.* erase *= *//' -e 's/^erase *= *//' -e 's/[; ].*//') \
   2>/dev/null`"
 in
@@ -1094,8 +1094,8 @@
 # Copyright © 2001 Alcove http://www.alcove.fr/
 if [ "$do_kbd" = linux ]; then
 if [ -x /sbin/sysctl -a -r /etc/sysctl.conf ]; then
-	if grep -v '^\#' /etc/sysctl.conf | grep -q keycodes ; then
-	grep keycodes /etc/sysctl.conf | grep -v "^#" \
+	if grep -v '^#' /etc/sysctl.conf | grep -q keycodes ; then
+	grep keycodes /etc/sysctl.conf | grep -v '^#' \
 		| while read -r d ; do
 /sbin/sysctl -w $d 2> /dev/null || true
 done

Bug#1010760: closed by Debian FTP Masters (reply to Tobias Frost ) (Bug#1010760: fixed in minetest 5.6.0+dfsg+~1.9.0mt7+dfsg-1)

[Nils Dagsson Moskopp]

 says:
> upstream requires SSE3 to function properly, depend on sse3-support

The commit message seems to be wrong: Minetest uses SSE2, not SSE3.


signature.asc
Description: PGP signature

Bug#1020322: devscripts: current directory rename by dch makes build fail

[Vincent Lefevre]

Package: devscripts
Version: 2.22.2
Severity: important

The use of dch may rename the current directory:

  If  the directory name of the source tree has the form package-version,
  then debchange will also attempt to rename it if the (upstream) version
  number  changes.  This can be prevented by using the --preserve command
  line or configuration file option as described below.

This is documented, but this is silly as it can make builds fail:

zira:/tmp> apt source console-setup
[...]
zira:/tmp> cd ./console-setup-1.210
zira:...nsole-setup-1.210> dch -l +local foo
dch warning: your current directory has been renamed to:
../console-setup-1.210+local1
zira:...nsole-setup-1.210> debuild -i -us -uc -b
[...]
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
make: *** [Fonts/Makefile:338: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-Fixed15.psf] Error 2
make: *** Waiting for unfinished jobs
make: *** [Fonts/Makefile:338: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-Fixed16.psf] Error 2
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
make: *** [Fonts/Makefile:338: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-VGA14.psf] Error 2
make: *** [Fonts/Makefile:342: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-VGA28x16.psf] Error 2
make: *** [Fonts/Makefile:338: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-VGA16.psf] Error 2
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
make: *** [Fonts/Makefile:342: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-VGA32x16.psf] Error 2
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
make: *** [Fonts/Makefile:338: 
/tmp/console-setup-1.210+local1/Fonts/Armenian-Fixed13.psf] Error 2
/tmp/console-setup-1.210+local1/Fonts/bdf2psf: /tmp/console-setup-1.210: No 
such file or directory
make: *** [Fonts/Makefile:338: 
/tmp/console-setup-1.210+local1/Fonts/Arabic-VGA8.psf] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed

-- Package-specific info:

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

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

-- 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 devscripts depends on:
ii  dpkg-dev  1.21.9
ii  fakeroot  1.29-1
ii  file  1:5.41-4+local3
ii  gnupg 2.2.39-1
ii  gpgv  2.2.39-1
ii  libc6 2.34-8
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.27-1
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.34.0-5
ii  python3   3.10.6-1
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.5.2
ii  curl7.85.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.08.11
ii  dput1.1.2
ii  equivs  2.3.1
ii  libdistro-info-perl 1.1
ii  libdpkg-perl1.21.9
ii  libencode-locale-perl   1.05-2
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-2
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-2
ii  libtry-tiny-perl0.31-1
ii  liburi-perl 5.12-1
ii  licensecheck3.3.0-1
ii  lintian 2.115.3
ii  man-db  2.10.2-3
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.3.0+b2
ii  python3-debian  0.1.47
ii  python3-magic   2:0.4.26-2
ii  python3-requests2.27.1+dfsg-1
ii  python3-unidiff 0.7.3-1

Bug#1020321: glib2.0: FTBFS on hppa - test simple-construction1 fails

[John David Anglin]

Source: glib2.0
Version: 2.66.8-1
Severity: normal

Dear Maintainer,

Test fails as follows:

Running test simple-construction1

(performance:11828): GLib-ERROR **: 23:07:39.938: ../../../glib/gmem.c:430: over
flow allocating 2147483647*4 bytes
<80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95>
119/302 glib:gobject+performance / performance  FAIL
 7.18s   killed by signal 5 SIGTRAP

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=glib2.0=hppa=2.74.0-1=1663629476=0

#define SIZE_OVERFLOWS(a,b) (G_UNLIKELY ((b) > 0 && (a) > G_MAXSIZE / (b)))

/**
 * g_realloc_n:
 * @mem: (nullable): the memory to reallocate
 * @n_blocks: the number of blocks to allocate
 * @n_block_bytes: the size of each block in bytes
 *
 * This function is similar to g_realloc(), allocating (@n_blocks * 
@n_block_bytes) bytes,
 * but care is taken to detect possible overflow during multiplication.
 *
 * If the allocation fails (because the system is out of memory),
 * the program is terminated.
 *
 * Since: 2.24
 * Returns: the new address of the allocated memory
 */
gpointer
g_realloc_n (gpointer mem,
 gsizen_blocks,
 gsizen_block_bytes)
{
  if (SIZE_OVERFLOWS (n_blocks, n_block_bytes))
{
  g_error ("%s: overflow allocating %"G_GSIZE_FORMAT"*%"G_GSIZE_FORMAT" 
bytes",
   G_STRLOC, n_blocks, n_block_bytes);
}

  return g_realloc (mem, n_blocks * n_block_bytes);
}

The 32-bit hppa runtime definitely can't handle an allocation of 8 GB.

Not sure why the test attempts to allocate this much. This test doesn't
fail on qemu buildds.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
merged-usr: no
Architecture: hppa (parisc64)

Kernel: Linux 5.19.9+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Le 20/09/2022 à 01:39, Luca Boccassi a écrit :

Thanks for the logs, it looks like it's only file under
/lib/systemd/system/ that went missing - can you find them anywhere
else on the system?


Now that you point out this, it recalls me that years ago,
I moved /lib/systemd/system/ to /etc/conffiles-out-etc/lib/systemd/system
(so that the systemd configuration files are correctly tracked by etckeeper)
and I put a /lib/systemd/system -> /etc/conffiles-out-etc/lib/systemd/system
symlink.

So, I'm downgrading the severity. But as it is allowed
to create symlinks to other part of the disk for directory,
usrmerge should handle this case (or, at least, give a
preeminent message about a strange situation)



vdanjean@eyak:~$ diff -r /etc/conffiles-out-etc/lib/systemd/system/ 
/lib/systemd/system/
Only in /etc/conffiles-out-etc/lib/systemd/system/: cgroupfs-mount.service
Only in /lib/systemd/system/: drkonqi-coredump-processor@.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
gitlab-ci-multi-runner.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: osspd.service
Only in /lib/systemd/system/: pam_namespace.service
Only in /lib/systemd/system/: pcscd.service
Only in /lib/systemd/system/: pcscd.socket
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
pulseaudio-enable-autospawn.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: screen-cleanup.service
diff -r /etc/conffiles-out-etc/lib/systemd/system/speech-dispatcherd.service 
/lib/systemd/system/speech-dispatcherd.service
1c1
< # Copyright (C) 2018 Samuel Thibault 
---
> # Copyright (C) 2018, 2022 Samuel Thibault 
23c23
< ExecStart=/usr/bin/speech-dispatcher -d --pid-file 
/run/speech-dispatcher/speech-dispatcher.pid
---
> ExecStart=/usr/bin/speech-dispatcher -d -t 0 --pid-file 
/run/speech-dispatcher/speech-dispatcher.pid
Only in /etc/conffiles-out-etc/lib/systemd/system/: sudo.service
vdanjean@eyak:~$ ls /etc/conffiles-out-etc/lib/systemd/system/ | wc -l
468
vdanjean@eyak:~$ ls /lib/systemd/system/ | wc -l
466
vdanjean@eyak:~$

I try to explain the difference:

Files previously in /usr/lib/...
Only in /lib/systemd/system/: drkonqi-coredump-processor@.service
Only in /lib/systemd/system/: pam_namespace.service
Only in /lib/systemd/system/: pcscd.service
Only in /lib/systemd/system/: pcscd.socket

Package not reinstalled
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
gitlab-ci-multi-runner.service

Removed packages
Only in /etc/conffiles-out-etc/lib/systemd/system/: osspd.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
pulseaudio-enable-autospawn.service

Files not removed on package upgrade?
Only in /etc/conffiles-out-etc/lib/systemd/system/: cgroupfs-mount.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: screen-cleanup.service




Directories are merged recursively if they exist in both hierarchies,
so I guess you had something that installs files in
/usr/lib/systemd/system/ and something went horribly wrong somewhere.
We don't delete files, so I'm thinking they might have been moved to
the wrong place.

We can add debsums -c before/after the conversion, so that if this
happens again there's a clear message immediately. But this is very
strange, I've never seen this reported in Debian or Ubuntu in ~5 years.


  If I understand, the bug occurs when a directory exists
in both / and /usr and the directory in / is in fact a
symlink to another directory elsewhere. Not a classical
situation indeed, but it can exists...

  Regards,
Vincent

Bug#1020320: dpkg-repack: usability tweak: show command to build .deb when using --generate option

[Paul Wise]

Package: dpkg-repack
Version: 1.50
Severity: wishlist
Tags: patch
Usertags: usability

People currently unfamiliar with the dpkg-deb interface might get
confounded when using the --generate option, since they need to run
dpkg-deb after modifying the generated directory, but they don't know
the dpkg-deb interface or forgot how to use it. They might look at the
dpkg-repack --help output, but that is missing the relevant command.
They might look at the manual page, but that requires a context switch.

The most useful place would be the --generate output, but they might
appreciate knowing about the command up-front from the --help output.

The attached patch implements both of these two suggestions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 86b65c6119e617c6750d00a0d9c43d770fef8fb7 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Tue, 20 Sep 2022 07:12:28 +0800
Subject: [dpkg-repack] [PATCH] Show the command to rebuild the .deb in more
 places

Currently it is documented in the manual page, so add hints to
the help output and the output from the --generate option.

Users who are unfamiliar with dpkg-deb will appreciate the hints.
---
 dpkg-repack.pl | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/dpkg-repack.pl b/dpkg-repack.pl
index 5fd2877..f001779 100755
--- a/dpkg-repack.pl
+++ b/dpkg-repack.pl
@@ -51,6 +51,7 @@ Options:
   --root=  Take package from filesystem rooted on .
   --arch= Force the package to be built for architecture .
   --generateGenerate build directory but do not build deb.
+Build with: dpkg-deb --build dpkg-repack.../ .
   --tag=  Tag the package as being repackaged.
   Types: none, description, version, all.
   -d, --deb-option=
@@ -313,11 +314,13 @@ sub Archive_Package {
 Install_DEBIAN($pkgname, $build_dir, $inst, @conffiles);
 
 # Do we need to create the binary packages?
+my @cmd = ('dpkg-deb', @deb_options, '--build', $build_dir, '.');
 if ($generate) {
 info("created $build_dir for $pkgname");
+info("build with: @cmd");
 } else {
 # Let dpkg-deb do its magic.
-SafeSystem('dpkg-deb', @deb_options, '--build', $build_dir, '.');
+SafeSystem(@cmd);
 }
 }
 
-- 
2.37.2



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

Bug#568230: bugs.debian.org: "forwarded" tags should gracefully ignore line breaks

[Don Armstrong]

On Mon, 19 Sep 2022, fab...@greffrath.com wrote:
> On Wed, 3 Feb 2010 11:09:22 -0800 Don Armstrong wrote:
> > > On Wed, 03 Feb 2010, Fabian Greffrath wrote:
> > > The reason is that my mail client breaks lines if they are longer
> > > than 70 characters.
> > 
> > If your mail client is unable to send messages with long lines, your
> > mail client is fundamentally broken.
> > 
> > If you don't want to fix your MUA, use the bts command line tools
> > instead.
> 
> Could this sentiment probably get reconsidered?

The problem is that there is no easy way for the bug tracking system to
reliably know whether the next line is part of the previous line or a
new line.

For example if you wanted to retitle a bug like so:

retitle 1234 this bug demonstrates broken forwarded data: forwarded 1235 
https://foo

should that look like this:

retitle 1234 this bug demonstrates broken forwarded data:
forwarded 1235 https://foo

We probably could support a line continuation escape (like \), but that
would require a bit of a change management process to enable.

Eventually we'll get around to supporting modifying things using a UI to
generate mail, which will fix this problem. [Maybe in another 10 years
at this rate?]

-- 
Don Armstrong  https://www.donarmstrong.com

But if, after all, we are on the wrong track, what then? Only
disappointed human hopes, nothing more. And even if we perish, what
will it matter in the endless cycles of eternity?
 -- Fridtjof Nansen _Farthest North_ p152

Bug#1020312: usrmerge: systemd file disappearing

[Luca Boccassi]

On Tue, 20 Sep 2022 01:11:43 +0200 Vincent Danjean
 wrote:
>    Hi,
> 
> Le 19/09/2022 à 23:49, Luca Boccassi a écrit :
> > On Mon, 2022-09-19 at 22:29 +0100, Luca Boccassi wrote:
> >> On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean
> >>  wrote:
> >>> Package: usrmerge
> >>> Version: 30+nmu2
> >>> Severity: serious
> >>> Justification: break other packages upgrades
> >>>
> >>> When I upgraded my system to current unstable, usrmerge has
> >>> been pulled-in due to the init-system-helpers dependency.
> >>> But one package fails to upgrade (fetchmail) due to
> >>> /lib/systemd/system/sysinit.target missing.
> >>> Reinstalling the systemd package fixes the problem.
> >>>
> >>> Feel free to reassign to systemd if you think the problem
> >>> comes from it but usrmerge is my first guess (without any
> >>> specific evidence)
> >>>
> >>> Note that systemd does *not* upgrade today (see at the end
> >>> of the commands)
> >>
> >> What was the order of upgrades? Can you share the full apt log?
> >> Are you sure the problem was not there beforehand?
> > 
> > Also can you run 'debsums -c' and paste the output?
> 
>   Oh yes. I'm back online after having rebooted after the upgrade.
> It took me several hours to get a bootable system again (hence,
> I will upgrade the severity to serious juste after this mail).
> 
>    So, first, at reboot, I got the emergency shell of systemd.
> It reports timeout when waiting for most (all?) devices.
> Once in the shell, all /dev/... files reported by systemd were
> there. And "mount -a" correctly mounts all filesystems that
> systemd was enable to.
>    I "fixed" this by booting on a debian rescue disk and
> running (from memory):
> apt install --reinstall systemd-container systemd-sysv systemd-ui
udev cryptsetup cryptsetup-bin cryptsetup-initramfs basefiles
> 
>    After this, I've been able to boot to a text-mode only system.
> No gdm3 graphical prompt.
>    So, I've run deb5sums. Here is the result of
> debsums  |& cat > /tmp/debsum2.txt  &
> cat /tmp/debsum2.txt | grep -v ' OK$' > /tmp/debsum2-missing.txt
> The 3 FAILED lines are "correct" (I manually modified these files
long before)
> But lots of /lib/* files was missing.
> 
>    I used sed/grep/... to reinstall all cited packages.
> Then, with a reboot, I'm back again.
> 
>    I will re-run debsums (it seems that the "|&" polute the output
> a litle bit, I want to be sure I reinstalled all required packages)

Thanks for the logs, it looks like it's only file under
/lib/systemd/system/ that went missing - can you find them anywhere
else on the system?

Directories are merged recursively if they exist in both hierarchies,
so I guess you had something that installs files in
/usr/lib/systemd/system/ and something went horribly wrong somewhere.
We don't delete files, so I'm thinking they might have been moved to
the wrong place.

We can add debsums -c before/after the conversion, so that if this
happens again there's a clear message immediately. But this is very
strange, I've never seen this reported in Debian or Ubuntu in ~5 years.

-- 
Kind regards,
Luca Boccassi


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

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Le 20/09/2022 à 01:11, Vincent Danjean a écrit :

   Hi,

Le 19/09/2022 à 23:49, Luca Boccassi a écrit :

Are you sure the problem was not there beforehand?


Yes. Due to the numerous missing files, I'm sure the problem
comes from the apt upgrade. The FS is in a good state (no
corruption) with nearly 9GB free (so no out-of-space problem).
  My system was perfectly booting and working before.

  Note that usrmerge has really run: I see this package that
would be newly installed before starting the upgrade (and
I read its bug page and the links to the TC decisions because
initially I did not want to merge my /usr).
  So, I run 'ls /' in a terminal before and after the upgrade
and I saw the changes. Now:
vdanjean@eyak:~$ ls -l / | grep -- '->'
lrwxrwxrwx   1 root root  7 19 sept. 21:34 bin -> usr/bin
lrwxrwxrwx   1 root root 30 12 sept. 18:44 initrd.img -> 
boot/initrd.img-5.19.0-1-amd64
lrwxrwxrwx   1 root root 30 12 sept. 18:44 initrd.img.old -> 
boot/initrd.img-5.18.0-4-amd64
lrwxrwxrwx   1 root root  7 19 sept. 21:34 lib -> usr/lib
lrwxrwxrwx   1 root root  9 19 sept. 21:34 lib32 -> usr/lib32
lrwxrwxrwx   1 root root  9 19 sept. 21:34 lib64 -> usr/lib64
lrwxrwxrwx   1 root root 10 19 sept. 21:34 libx32 -> usr/libx32
lrwxrwxrwx   1 root root  8 19 sept. 21:34 sbin -> usr/sbin
lrwxrwxrwx   1 root root 27 12 sept. 18:44 vmlinuz -> 
boot/vmlinuz-5.19.0-1-amd64
lrwxrwxrwx   1 root root 27 12 sept. 18:44 vmlinuz.old -> 
boot/vmlinuz-5.18.0-4-amd64
vdanjean@eyak:~$


   I will re-run debsums (it seems that the "|&" polute the output
a litle bit, I want to be sure I reinstalled all required packages)


Missing files are sent to stderr by debsums, hence the mess
in my initial log.
After a rerun of debsums, I will have to reinstall
gitlab-ci-multi-runner but I need to manually download it
(it is not a package from Debian). All the others seem now
correct.

  Regards
Vincent



   I also put in attachement the dpkg log file (I do not see anything
special when I've done the initial "apt upgrade")
First is my "apt upgrade"
At 21:56, there is my "apt install --reinstall systemd"
At 22:19, I upgraded pipewire (not done before because this requires the 
removal of pulseaudio)
At 23:52, I reinstalled some package from the rescue system
At 00:18, I installed debsums
At 00:46, I reinstalled all problematic packages

   Regards,
     Vincent

Bug#1017646: Interest in a Possible Patch

[Don Armstrong]

Control: tag -1 patch pending

On Mon, 19 Sep 2022, Soren Stoutner wrote:
> I recently posted in the debian-kde list about packaging the Qt WebEngine 
> dictionaries to 
> see if there was any preference about how they should be named or where the 
> files should 
> be located.  So far there have not been any comments.
> 
> https://lists.debian.org/debian-kde/2022/09/msg00011.html[1]
> 
> If you would like I could attempt to create a patch to enable the building of 
> these files.  I 
> am new to Debian packaging, but I have been reading over the documentation 
> and have 
> some idea of how to put it together.

Since the files in question are small, I think just including them and
appropriate symlinks should be sufficient.

Here's the patch which does that.

-- 
Don Armstrong  https://www.donarmstrong.com

If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier
diff --git a/debian/changelog b/debian/changelog
index 2ed6c73..6da3cfc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+scowl (2020.12.07-3) unstable; urgency=medium
+
+  * Include hunspell .bdic files (for qtwebengine and others). (Closes:
+#1017646) Thanks to Soren Stoutner.
+
+ -- Don Armstrong   Mon, 19 Sep 2022 16:19:57 -0700
+
 scowl (2020.12.07-2) unstable; urgency=medium
 
   * Separate uniqifying from sort; users (and other plurals with
diff --git a/debian/control b/debian/control
index 89ad062..58aa8ac 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Section: text
 Priority: standard
 Standards-Version: 4.1.4
 Build-Depends: debhelper (>= 12)
-Build-Depends-Indep: dictionaries-common-dev, dos2unix, aspell
+Build-Depends-Indep: dictionaries-common-dev, dos2unix, aspell, qtwebengine5-dev-tools, libqt5webengine-data
 Homepage: http://wordlist.sourceforge.net/
 Vcs-Browser: https://git.donarmstrong.com/deb_pkgs/scowl.git
 Vcs-Git: https://git.donarmstrong.com/deb_pkgs/scowl.git
diff --git a/debian/hunspell-en-au.install b/debian/hunspell-en-au.install
index 2431636..00d9a6a 100644
--- a/debian/hunspell-en-au.install
+++ b/debian/hunspell-en-au.install
@@ -1,3 +1,4 @@
 ./speller/en_AU.aff usr/share/hunspell
 ./speller/en_AU.dic usr/share/hunspell
+./speller/en_AU.bdic usr/share/hunspell
 
diff --git a/debian/hunspell-en-au.links b/debian/hunspell-en-au.links
new file mode 100644
index 000..80f3a6e
--- /dev/null
+++ b/debian/hunspell-en-au.links
@@ -0,0 +1,2 @@
+usr/share/hunspell/en_AU.bdic usr/share/qt5/qtwebengine_dictionaries/en_AU.bdic
+usr/share/hunspell/en_AU.bdic usr/share/qt6/qtwebengine_dictionaries/en_AU.bdic
diff --git a/debian/hunspell-en-ca.install b/debian/hunspell-en-ca.install
index b564b3c..f645db0 100644
--- a/debian/hunspell-en-ca.install
+++ b/debian/hunspell-en-ca.install
@@ -1,3 +1,4 @@
 ./speller/en_CA.aff usr/share/hunspell
 ./speller/en_CA.dic usr/share/hunspell
+./speller/en_CA.bdic usr/share/hunspell
 
diff --git a/debian/hunspell-en-ca.links b/debian/hunspell-en-ca.links
new file mode 100644
index 000..be369a0
--- /dev/null
+++ b/debian/hunspell-en-ca.links
@@ -0,0 +1,2 @@
+usr/share/hunspell/en_CA.bdic usr/share/qt5/qtwebengine_dictionaries/en_CA.bdic
+usr/share/hunspell/en_CA.bdic usr/share/qt6/qtwebengine_dictionaries/en_CA.bdic
diff --git a/debian/hunspell-en-us.install b/debian/hunspell-en-us.install
index 54f004b..b0b0a2c 100644
--- a/debian/hunspell-en-us.install
+++ b/debian/hunspell-en-us.install
@@ -1,3 +1,4 @@
 ./speller/en_US.aff usr/share/hunspell
 ./speller/en_US.dic usr/share/hunspell
+./speller/en_US.bdic usr/share/hunspell
 
diff --git a/debian/hunspell-en-us.links b/debian/hunspell-en-us.links
new file mode 100644
index 000..68e537e
--- /dev/null
+++ b/debian/hunspell-en-us.links
@@ -0,0 +1,2 @@
+usr/share/hunspell/en_US.bdic usr/share/qt5/qtwebengine_dictionaries/en_US.bdic
+usr/share/hunspell/en_US.bdic usr/share/qt6/qtwebengine_dictionaries/en_US.bdic
diff --git a/debian/patches/ignore_bdic b/debian/patches/ignore_bdic
new file mode 100644
index 000..10e7da2
--- /dev/null
+++ b/debian/patches/ignore_bdic
@@ -0,0 +1,7 @@
+--- a/speller/.gitignore
 b/speller/.gitignore
+@@ -19,3 +19,4 @@
+ aspell/Copyright
+ aspell/doc/SCOWL-README
+ *.txt
++*.bdic
diff --git a/debian/patches/series b/debian/patches/series
index 6c3365e..7fe8864 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ move_sangs_to_insane
 deprecate_reprized
 hunspell_size_70
 fix_hunspell_affix
+ignore_bdic
diff --git a/debian/rules b/debian/rules
index a72a41e..a9e36b7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -59,6 +59,10 @@ override_dh_auto_build:
 	  done;\
 	done
 	

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

[Sean Whitton]

control: tag -1 + pending

Hello,

On Sun 18 Sep 2022 at 07:53PM -07, Russ Allbery wrote:

> Ansgar  writes:
>
>> Section 11.8.4 "Packages providing a window manager" still references
>> the Debian menu.  But the Debian menu is deprecated.
>
>> I suggest to remove the reference, for example with the patch below.
>
>> --- a/policy/ch-customized-programs.rst
>> +++ b/policy/ch-customized-programs.rst
>> @@ -345,13 +345,7 @@ Packages that provide a window manager should declare 
>> in their
>>  alternative for ``/usr/bin/x-window-manager``, with a priority
>>  calculated as follows:
>>
>> --  Start with a priority of 20.
>> -
>> --  If the window manager supports the Debian menu system, add 20 points
>> -   if this support is available in the package's default configuration
>> -   (i.e., no configuration files belonging to the system or user have to
>> -   be edited to activate the feature); if configuration files must be
>> -   modified, add only 10 points.
>> +-  Start with a priority of 40.
>>
>>  -  If the window manager complies with `The Window Manager Specification
>> Project `_,
>
> Yes, this looks right to me.  Seconded.

Likewise seconded, and applied.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017015: gnome-console: bugs after switch to GTK4

[Jeremy Bicha]

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.

Thank you,
Jeremy Bicha

Bug#1017646: Interest in a Possible Patch

[Soren Stoutner]

I recently posted in the debian-kde list about packaging the Qt WebEngine 
dictionaries to 
see if there was any preference about how they should be named or where the 
files should 
be located.  So far there have not been any comments.

https://lists.debian.org/debian-kde/2022/09/msg00011.html[1]

If you would like I could attempt to create a patch to enable the building of 
these files.  I 
am new to Debian packaging, but I have been reading over the documentation and 
have 
some idea of how to put it together.

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


[1] https://lists.debian.org/debian-kde/2022/09/msg00011.html


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

Bug#1012340: Please consider offering debian-debug via rsync

[Sergio Durigan Junior]

Control: severity -1 grave

On Saturday, June 04 2022, I wrote:

> I am the maintainer of the debuginfod.debian.net service, which provides
> debug information over HTTPS to debuginfo consumers such as GDB.
>
> It would be extremely helpful if the debian-debug repository offered
> rsync access like the other repositories do.  The debuginfod service
> needs to download the entire repository in order to index everything in
> it, and doing so via rsync would be a no-brainer.
>
> Currently, I use aptly to do the local mirroring.  It works great, but
> has its limitations.
>
> I would like to ask you to please consider enabling rsync access to the
> debian-debug repository.  I understand that you might not have the time
> to work on this, so I would like to volunteer to do it (under your
> guidance, of course).  I'm a DD, btw.

Given the current situation, having an rsync mirror for our debuginfod
service has become essential.  The service was using rclone as a
replacement but unfortunately it has been blocked from contacting the
debian-debug mirror.

One more time, I am offering my help here.  I would like to have a good
solution for this problem that can make everybody as happy as possible.
I have been very understanding about the limitations of the Debian
Mirrors team, but I need *some* cooperation in order to make progress on
this.

Thank you.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1020312: usrmerge: systemd file disappearing

[Luca Boccassi]

Control: tags -1 moreinfo

On Mon, 2022-09-19 at 22:29 +0100, Luca Boccassi wrote:
> On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean
>  wrote:
> > Package: usrmerge
> > Version: 30+nmu2
> > Severity: serious
> > Justification: break other packages upgrades
> > 
> > When I upgraded my system to current unstable, usrmerge has
> > been pulled-in due to the init-system-helpers dependency.
> > But one package fails to upgrade (fetchmail) due to
> > /lib/systemd/system/sysinit.target missing.
> > Reinstalling the systemd package fixes the problem.
> > 
> > Feel free to reassign to systemd if you think the problem
> > comes from it but usrmerge is my first guess (without any
> > specific evidence)
> > 
> > Note that systemd does *not* upgrade today (see at the end
> > of the commands)
> 
> What was the order of upgrades? Can you share the full apt log?
> Are you sure the problem was not there beforehand?

Tried in a sid chroot, cannot reproduce:

# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  usrmerge
The following packages will be upgraded:
  fetchmail init-system-helpers
2 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 412 kB/475 kB of archives.
After this operation, 39.9 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 file:/tmp/repo ./ usrmerge 31+nmu1 [13.0 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 fetchmail amd64 6.4.33-2 [412 
kB]
Fetched 412 kB in 0s (4957 kB/s)
Selecting previously unselected package usrmerge.
(Reading database ... 104605 files and directories currently installed.)
Preparing to unpack ..././usrmerge_31+nmu1_all.deb ...
Unpacking usrmerge (31+nmu1) ...
Setting up usrmerge (31+nmu1) ...
The system has been successfully converted.
(Reading database ... 104612 files and directories currently installed.)
Preparing to unpack .../init-system-helpers_1.65.2_all.deb ...
Unpacking init-system-helpers (1.65.2) over (1.64) ...
Setting up init-system-helpers (1.65.2) ...
(Reading database ... 104612 files and directories currently installed.)
Preparing to unpack .../fetchmail_6.4.33-2_amd64.deb ...
Unpacking fetchmail (6.4.33-2) over (6.4.33-1) ...
Setting up fetchmail (6.4.33-2) ...
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of restart.
Processing triggers for man-db (2.10.2-3) ...
# ls /lib/systemd/system/sysinit.target
/lib/systemd/system/sysinit.target
# debsums -c
#

-- 
Kind regards,
Luca Boccassi


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

Bug#1020319: openldap: FTBFS on sparc64 due to unaligned access in testsuite

[John Paul Adrian Glaubitz]

Source: openldap
Version: 2.5.13+dfsg-1
Severity: normal
Tags: ftbfs upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

openldap FTBFS on sparc64 due to an unaligned access in the testsuite:

> Test succeeded
> test000-rootdse completed OK for mdb after 1 seconds.

> Starting test001-slapadd for mdb...
running defines.sh
Running slapadd to build slapd database...
Bus error
slapadd failed (138)!
> test001-slapadd failed for mdb after 0 seconds
(exit 138)

Building openldap from git and running the slapd through GDB yields the
following backtrace:

(gdb) bt
#0  0x010cc36c in mdb_node_add (mc=0x14316e8, indx=, 
key=0x7fee570, data=0x7fee560, pgno=0, flags=0)
at ./../../../libraries/liblmdb/mdb.c:7358
#1  0x010d0894 in mdb_cursor_put (mc=0x14316e8, key=0x7fee570, 
data=0x7fee560, flags=16) at ./../../../libraries/liblmdb/mdb.c:6960
#2  0x010d1224 in mdb_cursor_put (mc=0x1431560, key=0x7fee6b0, 
data=0x7fee6c0, flags=36) at ./../../../libraries/liblmdb/mdb.c:7007
#3  0x010f0d24 in mdb_dn2id_add (op=0x7feea28, mcp=0x1431560, 
mcd=0x14267a0, pid=, nsubs=, 
upsub=, e=0x144c6b8) at dn2id.c:141
...
(gdb)

Since this issue is present in the upstream code, I have reported it there [1].

Thanks,
Adrian

> [1] https://bugs.openldap.org/show_bug.cgi?id=9916

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1020310: lists.debian.org: missing msgid-search link

[Paul Wise]

On Mon, 19 Sep 2022 21:56:35 +0200 Jakub Wilk wrote:

> https://lists.debian.org/debian-devel-announce/2022/04/msg7.html 
> doesn't have the msgid-search link.
> 
> Maybe the software is confused because the message-id contains "/"? It's 
> a bit unusual, but valid AFAICT.

That is the issue. In addition, passing the message-id doesn't work:

https://lists.debian.org/msgid-search/YmFsKzO/jl3xt...@roeckx.be

There is a workaround, you can use a URL query parameter instead:

https://lists.debian.org/msgid-search/?m=YmFsKzO/jl3xt...@roeckx.be

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1020318: syslog-ng: binary-all FTBFS

[Adrian Bunk]

Source: syslog-ng
Version: 3.38.1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=syslog-ng=all

...
   dh_install -i
dh_install: warning: Cannot find (any matches for) 
"usr/share/syslog-ng/include/scl/*" (tried in ., debian/tmp)

dh_install: warning: syslog-ng-scl missing files: 
usr/share/syslog-ng/include/scl/*
dh_install: error: missing files, aborting
make: *** [debian/rules:211: binary-indep] Error 25

Bug#919652: ath10k - QCA6174 - Surface Go - missing board data - fix .bin included extracted form official .msi

[David Kalnischkies]

Control: tags -1 + fixed-upstream

On Tue, 19 Jul 2022 23:46:17 +0300 Dmitry Baryshkov  
wrote:
> I'd suggest submitting the board files to the ath10k-firmware repo,
> which will then find it's way into linux-firmware.

fwiw this (or, well an update of the existing one) actually happened
already at the end of 2021 [0], but Debian hasn't seen an update so far.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=4d74f4dec175363fa24c95702dd86f477cef232c


With that board file wlan works even through the kernel (at least on
bullseye, not tested others) still complains about missing firmware:

ath10k_pci :01:00.0: firmware: failed to load 
ath10k/pre-cal-pci-:01:00.0.bin (-2)
fimeware_class: See https://wiki.debian.org/Firmware for information about 
missing firmware
ath10k_pci :01:00.0: firmware: failed to load 
ath10k/cal-pci-:01:00.0.bin (-2)
(followed by messages about successfully loading firmware-6.bin and board-2.bin)

The internet says these files are optional, which is somewhat confirmed
by having working wlan even without them, and I fail to find them – but
find some references to them in Debian forums as e.g. also d-i shows its
missing firmware message for those files (even if you have the firmware
cd variant, which is both annoying and confusing).

Not well versed in kernel code, but while [1] claims (at least for the
cal file) that it is optional and should print no warning it happily
still does anyhow? Or perhaps its ath10k_fetch_fw_file() doing a
firmware_request_nowarn() to then go on and ERR_PTR() on its own… [2]
Anyway, not really the point of this bugreport, just at the off chance
someone has an idea how to proceed on this somewhat related front.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath10k/core.c#n1227
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath10k/core.c#n882


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1020312: usrmerge: systemd file disappearing

[Luca Boccassi]

On Mon, 2022-09-19 at 22:29 +0100, Luca Boccassi wrote:
> On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean
>  wrote:
> > Package: usrmerge
> > Version: 30+nmu2
> > Severity: serious
> > Justification: break other packages upgrades
> > 
> > When I upgraded my system to current unstable, usrmerge has
> > been pulled-in due to the init-system-helpers dependency.
> > But one package fails to upgrade (fetchmail) due to
> > /lib/systemd/system/sysinit.target missing.
> > Reinstalling the systemd package fixes the problem.
> > 
> > Feel free to reassign to systemd if you think the problem
> > comes from it but usrmerge is my first guess (without any
> > specific evidence)
> > 
> > Note that systemd does *not* upgrade today (see at the end
> > of the commands)
> 
> What was the order of upgrades? Can you share the full apt log?
> Are you sure the problem was not there beforehand?

Also can you run 'debsums -c' and paste the output?

-- 
Kind regards,
Luca Boccassi


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

Bug#1020312: usrmerge: systemd file disappearing

[Luca Boccassi]

On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean
 wrote:
> Package: usrmerge
> Version: 30+nmu2
> Severity: serious
> Justification: break other packages upgrades
> 
> When I upgraded my system to current unstable, usrmerge has
> been pulled-in due to the init-system-helpers dependency.
> But one package fails to upgrade (fetchmail) due to
> /lib/systemd/system/sysinit.target missing.
> Reinstalling the systemd package fixes the problem.
> 
> Feel free to reassign to systemd if you think the problem
> comes from it but usrmerge is my first guess (without any
> specific evidence)
> 
> Note that systemd does *not* upgrade today (see at the end
> of the commands)

What was the order of upgrades? Can you share the full apt log?
Are you sure the problem was not there beforehand?

-- 
Kind regards,
Luca Boccassi


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

Bug#1019554: Stamp files are not updated

[Mike Gerow]

On Mon, 19 Sep 2022 12:59:59 + Lance Lin  wrote:
>
> Thank you for tracking this down. I did make the change in -33.
>
> Yes, I made the change to remove dangling symlinks on uninstall. I
>
> didn't realize this was called on upgrades, so I've moved the logic
>
> inside the "purge" case.
>
> I propose to make the following change to anacron.postrm:
>
> #!/bin/sh
>
> set -e
>
> if [ "$1" = "purge" ]; then
> # here for historical reasons
> rm -f /var/log/anacron /var/log/anacron.[0-9]*
> rm -rf /var/spool/anacron
>
> # Close bug #993348
> rm /etc/systemd/system/multi-user.target.wants/anacron.service
> rm /etc/systemd/system/timers.target.wants/anacron.timer
> fi
>
> #DEBHELPER#
>
> Do you agree with this change?

Yes, that seems like it should prevent future upgrades from disabling
the service and the timer. Users that upgraded from -33 or -34 will
still need to manually re-enable the service and the timer, of course.
I'm capable of doing that with my systems, but I'll leave whether
that's acceptable in general up to you.

Bug#985957: usrmerge has 47.3MB of dependencies

[Luca Boccassi]

Now that we have the usr-is-merged metapackage, that
debootstrap/mmdebstrap install, can we close this?

-- 
Kind regards,
Luca Boccassi


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

Bug#926699: Transition to usrmerge has started

[Luca Boccassi]

Control: tags -1 patch

On Mon, 2022-09-19 at 13:35 +0200, Andreas Beckmann wrote:
> On 19/09/2022 12.07, Marco d'Itri wrote:
> > The main issue can only be fixed in the libc packages (which would
> > be
> > wonderful, because then we could stop creating the biarch links and
> > directories on all systems).
> 
> on amd64:
> 
> # apt-file search -x '^/lib32' | cut -d: -f1 | sort -u
> lib32ncurses6
> lib32ncursesw6
> lib32readline8
> lib32tinfo6
> libc6-i386
> 
> # apt-file search -x '^/libx32' | cut -d: -f1 | sort -u
> libc6-x32
> 
> # apt-file search -x '^/lib64' | cut -d: -f1 | sort -u
> libc6
> 
> # apt-cache show lib32ncurses6 lib32ncursesw6 lib32readline8
> lib32tinfo6 
> > grep -E 'Package|Depends'
> Package: lib32ncurses6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32ncursesw6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32readline8
> Depends: readline-common, lib32tinfo6 (>= 6), libc6-i386 (>= 2.33)
> Package: lib32tinfo6
> Depends: libc6-i386 (>= 2.33)
> 
> Just brainstorming:
> If we declare libc6-i386 as the "owner" of /lib32, lib32* as "users"
> of 
> /lib32 and add libc6-i386.preinst that
> * handles the creation of /lib32 if missing, either as directory or 
> symlink, depending of the state of /lib
> * errors out (or converts) if /lib32 is a directory but /lib is a
> symlink
> and then have all "users" of /lib32 Pre-Depends: libc6-i386 (>= xxx)
> (might need a debhelper patch to populate ${misc:Pre-Depends})
> and lintian check for such a pre-depends ...
> (I'm not sure if a plain Depends is sufficient to ensure 
> libc6-i386.preinst gets run in all cases before some lib32* gets 
> unpacked ...)
> Same for /libx32, except that there are no users that might need
> updating.
> 
> How likely is it that a user of /lib32 gets unpacked during the early
> bootstrapping phase? If that is not going to happen, the symlink 
> creation for /libxx could be deferred to the installation of 
> libc6-{i386,x32} and no "unowned" /libxx symlinks would be lingering 
> around after boostrapping.
> 
> On i386 we have
> 
> # apt-file search -x ^/lib64 | cut -d: -f1 | sort -u
> lib64gcc-s1
> lib64ncurses6
> lib64ncursesw6
> lib64readline8
> lib64tinfo6
> libc6-amd64
> 
> # apt-file search -x ^/libx32 | cut -d: -f1 | sort -u
> libc6-x32
> 
> (and no /lib32)
> 
> Didn't check other architectures.
> 
> Interesting could also be the installation of libc6:amd64 on a i386 
> system as that will create /lib64 ... yes, that will leave you with a
> /lib64 directory if no symlink pre-exists.

This MR implements the suggestion from Marco from earlier in this
thread [0]:

https://salsa.debian.org/glibc-team/glibc/-/merge_requests/11

Tested with libc6-i386, seems to do the expected thing. We can remove
it then after everything has moved to install only to /usr, hopefully
in Trixie.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699#77

-- 
Kind regards,
Luca Boccassi


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

Bug#1012912: diagnostics: diff for NMU version 0.3.3-12.3

[Sudip Mukherjee]

Control: tags 1012912 + patch
Control: tags 1012912 + pending
--

Dear maintainer,

I've prepared an NMU for diagnostics (versioned as 0.3.3-12.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

-- 
Regards
Sudip

diff -Nru diagnostics-0.3.3/debian/changelog diagnostics-0.3.3/debian/changelog
--- diagnostics-0.3.3/debian/changelog  2022-02-07 18:37:08.0 +
+++ diagnostics-0.3.3/debian/changelog  2022-09-19 21:46:06.0 +0100
@@ -1,3 +1,11 @@
+diagnostics (0.3.3-12.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-12. (Closes: #1012912)
+- Thanks Adnan from Codethink for helping with the fix.
+
+ -- Sudip Mukherjee   Mon, 19 Sep 2022 21:46:06 
+0100
+
 diagnostics (0.3.3-12.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru diagnostics-0.3.3/debian/patches/fix-ftbfs.patch 
diagnostics-0.3.3/debian/patches/fix-ftbfs.patch
--- diagnostics-0.3.3/debian/patches/fix-ftbfs.patch1970-01-01 
01:00:00.0 +0100
+++ diagnostics-0.3.3/debian/patches/fix-ftbfs.patch2022-09-19 
21:45:20.0 +0100
@@ -0,0 +1,40 @@
+Description: Fix FTBFS with GCC-12.
+ Thanks Adnan for finding out the header file fix.
+
+Author: Sudip Mukherjee 
+
+---
+
+Bug-Debian: https://bugs.debian.org/1012912
+Forwarded: no
+
+--- diagnostics-0.3.3.orig/diagnostics/util/marshaling.cpp
 diagnostics-0.3.3/diagnostics/util/marshaling.cpp
+@@ -74,13 +74,13 @@ bool read(::std::istream & stream, ::std
+ char * const target_buffer(new char[length]);
+ stream.read(target_buffer,length);
+ if(!stream.good()) {
+-  delete target_buffer;
++  delete[] target_buffer;
+   return false;
+ }
+ 
+ // convert
+ target= ::std::string(target_buffer,length);
+-delete target_buffer;
++delete[] target_buffer;
+ return true;
+ }
+ 
+--- diagnostics-0.3.3.orig/diagnostics/util/to_string.hpp
 diagnostics-0.3.3/diagnostics/util/to_string.hpp
+@@ -45,6 +45,9 @@
+ #define DIAGNOSTICS__UTIL__TO_STRING_HPP__INCLUDE_GUARD
+ 
+ #include 
++#include 
++#include 
++#include 
+ 
+ // used in the implementation by value
+ #include 
diff -Nru diagnostics-0.3.3/debian/patches/series 
diagnostics-0.3.3/debian/patches/series
--- diagnostics-0.3.3/debian/patches/series 2022-02-07 17:57:51.0 
+
+++ diagnostics-0.3.3/debian/patches/series 2022-09-19 21:45:37.0 
+0100
@@ -6,3 +6,4 @@
 test-run-cleanup
 no-ltdl-convenience.patch
 remove-dynamic-exception.patch
+fix-ftbfs.patch

Bug#1020317: nmu: filezilla_3.60.2-1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: Phil Wyett 

nmu filezilla_3.60.2-1 . ANY . unstable . -m "Rebuild against libfilezilla30"

Bug#1012704: libmath-bigint-perl: busy loop with bignum bitwise operations

[Niko Tyni]

retitle 1012704 libmath-bigint-perl: busy loop with bignum bitwise operations
severity 1012704 serious
reassign 1012704 libmath-bigint-perl 1.999835-1
found 1012704 1.999837-1
tag 1012704 upstream
thanks

On Sun, Sep 18, 2022 at 12:14:06PM +0100, Klaus Ethgen wrote:
> I was able to fix that bug by taking Math::BigInt and Math::BigFloat
> from perl 5.36. They work seamless.
> 
> I will reassign the bug to perl-modules.

Thanks for the report.

This boils down to

  % perl -Mbignum -e '1 | (1 >> 1)'
  Deep recursion on subroutine "Math::BigInt::bior" at 
/usr/share/perl5/Math/BigFloat.pm line 3883.
  Deep recursion on subroutine "Math::BigFloat::bior" at 
/usr/share/perl5/Math/BigInt.pm line 3513.

Also happens with other bitwise operations like & and ^ .

The bug is not specific to any Perl versions but seems to be fully
contained in Math::BigInt / Math::BigFloat.  The versions of those
modules that ship with Perl 5.34.0 (Math::BigInt 1.999818) and Perl
5.36.0 (Math::BigInt 1.999830) are not affected by the bug, but you
have the newer separate libmath-bigint-perl package installed where the
bug triggers.

It seems to have regressed upstream around 1.999832 (where it started
to spit errors) and 1.999834 (where the errors became infinite recursion.)
The first version in Debian that had the bug was 1.999835-1, which
fits your upgrade timeline.

So I'm reassigning this once more. Also raising the severity as this looks
rather Bad.

Would be great if (other) pkg-perl maintainers can pick this up from
here and forward upstream etc. Otherwise I'll get to it eventually :)
-- 
Niko Tyni   nt...@debian.org

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

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 17:34:57 -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> > On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote:
> >> So, personally, I'd be happy to fully switch to stanza TBH, because it
> >> seems more specific to our use, probably easier to search for, and
> >> it's shorter.
> 
> > I think this is fine for Policy to do.
> 
> I vote for switching to stanza.  Paragraph is going to be confusing when
> talking about package descriptions, which often have multiple paragraphs
> in the normal English meaning of the term.

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

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. 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've gone one by one, but please review carefully as I might have
perhaps switched in excess!

Thanks,
Guillem
From 6d02f28eb1f0cd2f7afa75b04691265425122366 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 19 Sep 2022 22:33:40 +0200
Subject: [PATCH] Use stanza to refer to deb822 parts instead of paragraph
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.

In addition «stanza» is shorter, which is always a nice attribute
on code for example.

The references in dpkg documentation and code, will be updated shortly,
so that there is uniform nomenclature used.

Fixes: #1020248
---
 autopkgtest.md |   2 +-
 copyright-format-1.0.xml   | 116 -
 policy/ch-controlfields.rst|  46 ++---
 policy/upgrading-checklist.rst |   8 +--
 4 files changed, 87 insertions(+), 85 deletions(-)

diff --git a/autopkgtest.md b/autopkgtest.md
index bc7bdaf..74d6885 100644
--- a/autopkgtest.md
+++ b/autopkgtest.md
@@ -219,7 +219,7 @@ debian/control by adding
 
 XS-Testsuite: autopkgtest
 
-in the `Source:` paragraph.
+in the `Source:` stanza.
 
 Implicit test control file for known package types
 --
diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index d5d2bbe..954a65b 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -115,17 +115,17 @@
   The syntax of the file is the same as for other Debian control files, as
   specified in the Debian Policy Manual.  See its https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax;>section
-  5.1 for details. Extra fields can be added to any paragraph.  No
+  5.1 for details. Extra fields can be added to any stanza.  No
   prefixing is necessary or desired, but please avoid names similar to
   standard ones so that mistakes are easier to catch.  Future versions of
   the debian/copyright specification will attempt to
   avoid conflicting specifications for widely used extra fields.
 
 
-  The file consists of two or more paragraphs.  At minimum, the file
-  must include one header
-  paragraph and one Files
-  paragraph.
+  The file consists of two or more stanzas.  At minimum, the file
+  must include one header
+  stanza and one Files
+  stanza.
 
 
   There are four types of fields.  The definition for each field in this
@@ -184,22 +184,22 @@
 
   
 
-  
-Paragraphs
+  
+Stanzas
 
-  There are three kinds of paragraphs.  The first paragraph in the file
-  is called the header paragraph.
-  Every other paragraph is either a Files paragraph or a stand-alone License
-  paragraph.  This is similar to source and binary package
-  paragraphs in debian/control files.
+  There are three kinds of stanzas.  The first stanza in the file
+  is called the header stanza.
+  Every other stanza is either a Files stanza or a stand-alone License
+  stanza.  This is similar to source and binary package
+  stanzas in debian/control files.
 
 
-
-  Header paragraph (once)
+
+  Header stanza (once)
   
-The following fields may be present in a header paragraph.
+The following fields may be present in a header stanza.
   
   
 
@@ -249,9 +249,9 @@
   
   
 The Copyright and License
-fields in 

Bug#1019724: bug#57604: Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Paul Eggert]

On 9/19/22 05:32, Santiago Ruano Rincón wrote:


as you can read below, there are 4235 packages including the
warning in their build logs. Funnily, grep is also in the list :-)


Grep is on the list because Debian indirectly requires ucf to build 
Grep, and ucf issues the warning about stray \ because ucf mistakenly 
uses a Perlism in a grep regular expression 
. This particular warning doesn't break 
anything; it merely alerts installers of a screwup that happens to work 
but relies on undefined results.


We're thinking about adding a configure-time option to Grep to disable 
warnings about egrep/fgrep, to address the original Grep bug report 
. I'm not so sure about disabling warnings 
about bad escapes, as these warnings are so often a win and so rarely a 
loss, as is the case with ucf. Of course there is a tradeoff here 
between (a) having to wade through a bunch of annoying warnings, and (b) 
fixing packages so that they don't rely on undefined results.


Since the main issue here seems to be libtool-related test failures, how 
about patching libtool and letting the affected packages use the patched 
libtool? You can find a patch here:


https://savannah.gnu.org/patch/index.php?10282
https://savannah.gnu.org/patch/download.php?file_id=53720

The libtool test failures are false alarms, so another option would be 
to ignore the failures until libtool gets fixed.



For more on this thorny topic, please see:

https://www.gnu.org/software/grep/manual/html_node/Problematic-Expressions.html

The stray \ issue is the 19th bullet.

Bug#1020315: bind9: Spams /var/log/syslog with appramor DENIED /sys/kernel/mm/transparent_hugepage/enabled

[Debian bugreport]

Package: bind9
Version: 1:9.18.6-2
Severity: normal
Tags: patch
X-Debbugs-Cc: pkg-apparmor-t...@lists.alioth.debian.org

With apparmor enabled for named, the /var/log/syslog file ends up with 
allot of unnecessary DENIED messages,
as the as read access to/sys/kernel/mm/transparent_hugepage/enabled 
seems to have accidentally excluded by the hardening.

Restoring the read access seems to resolve the issue, see attached patch.


Examples:
/var/log/syslog:Sep 18 00:45:12 pippi kernel: [568935.135647] audit: 
type=1400 audit(1663454712.445:191): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=234038 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 01:54:18 pippi kernel: [573081.399636] audit: 
type=1400 audit(1663458858.813:192): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=235380 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 03:26:40 pippi kernel: [578622.720520] audit: 
type=1400 audit(1663464400.273:193): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=236920 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 04:42:21 pippi kernel: [583163.451230] audit: 
type=1400 audit(1663468941.119:194): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=237915 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 05:50:00 pippi kernel: [587222.657447] audit: 
type=1400 audit(1663473000.425:195): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=239109 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 07:15:15 pippi kernel: [592337.151577] audit: 
type=1400 audit(1663478115.049:196): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=243061 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 08:42:55 pippi kernel: [597597.185578] audit: 
type=1400 audit(1663483375.213:197): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=247004 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 09:52:30 pippi kernel: [601772.451830] audit: 
type=1400 audit(1663487550.586:198): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=248343 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 11:12:27 pippi kernel: [606569.547243] audit: 
type=1400 audit(1663492347.802:199): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=252396 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 12:25:25 pippi kernel: [610946.891663] audit: 
type=1400 audit(1663496725.256:200): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=254642 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 13:50:03 pippi kernel: [616024.685028] audit: 
type=1400 audit(1663501803.180:201): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=257604 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 15:05:34 pippi kernel: [620555.410211] audit: 
type=1400 audit(1663506334.014:202): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=260179 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 16:37:47 pippi kernel: [626088.694992] audit: 
type=1400 audit(1663511867.436:203): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=262246 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 18:00:21 pippi kernel: [631042.827598] audit: 
type=1400 audit(1663516821.692:204): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=264295 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 19:15:41 pippi kernel: [635562.798692] audit: 
type=1400 audit(1663521341.781:205): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=267350 comm="named" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
/var/log/syslog:Sep 18 20:43:37 pippi kernel: [640838.555665] audit: 
type=1400 audit(1663526617.670:206): apparmor="DENIED" operation="open" 
profile="named" name="/sys/kernel
/mm/transparent_hugepage/enabled" pid=268844 comm="named" 
requested_mask="r" 

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

[Christoph Berg]

Re: Lev Kokotov
> Hi Christoph,
> 
> Yes, that looks like the right place for it.

What's your salsa account name?

Christoph

Bug#1020314: osmo-bts: Stale build dependency on openbsc-dev

[Adrian Bunk]

Source: osmo-bts
Version: 1.4.1+dfsg1-1
Severity: serious
Control: block 1020313 by -1

osmo-bts has a build dependency on openbsc-dev that seems to be unused.

Bug#1020313: Should openbsc be shipped in bookworm?

[Adrian Bunk]

Source: openbsc
Severity: serious
Tags: bookworm sid

https://osmocom.org/projects/openbsc

This is a legacy all-in-one implementation of the Osmocom BSC + MSC + HLR,
instead refer to OsmoBSC, OsmoMSC, OsmoHLR.


The new implementation seems to already be packaged.

Bug#1016365: WebKitNetworkProcess messages logged

[Paul Gevers]

Hi,

On Sat, 30 Jul 2022 21:11:21 +0200 Paul Gevers  wrote:

Hi,

On 30-07-2022 18:27, Camaleón wrote:
>> It looks wrong indeed, but it also doesn't happen on my system.
> 
> Try by setting «Open links in Lifea's window» and click on a feed to

> load. This way I always get the above mesages.

This doesn't show any messages in my journal.

> Not sure if this helps. Should you need more info kindy ask.

I'll forward the bug to upstream, with the note that I can't reproduce. 
Let's see if they have smart ideas.


Upstream wrote this [1]:
"""
I can reproduce those crashes when running on Wayland. When I open the 
websites/resources causing them with Epiphany I get the same crashes. 
Usually they are highly reproducible both in Liferea and Webkit. Rarely 
retrying the load helps.


When running with an XOrg session both Epiphany and Liferea successfully 
load the pages.


I fear the combination of WebkitGTK+Wayland is the root cause here.
"""

Paul

[1] https://github.com/lwindolf/liferea/issues/1130#issuecomment-1250340671


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Package: usrmerge
Version: 30+nmu2
Severity: serious
Justification: break other packages upgrades

When I upgraded my system to current unstable, usrmerge has
been pulled-in due to the init-system-helpers dependency.
But one package fails to upgrade (fetchmail) due to
/lib/systemd/system/sysinit.target missing.
Reinstalling the systemd package fixes the problem.

Feel free to reassign to systemd if you think the problem
comes from it but usrmerge is my first guess (without any
specific evidence)

Note that systemd does *not* upgrade today (see at the end
of the commands)

vdanjean@eyak:~$ sudo apt upgrade
[...]
Paramétrage de fetchmail (6.4.33-2) ...
insserv: warning: current stop runlevel(s) (empty) of script `fetchmail' 
overrides LSB defaults (0 1 6).
Failed to restart fetchmail.service: Unit sysinit.target not found.
invoke-rc.d: initscript fetchmail, action "restart" failed.
○ fetchmail.service - LSB: init-Script for system wide fetchmail daemon
 Loaded: loaded (/etc/init.d/fetchmail; generated)
 Active: inactive (dead)
   Docs: man:systemd-sysv-generator(8)

sept. 19 20:27:35 eyak systemd[1]: Starting LSB: init-Script for system wide 
fetchmail daemon...
sept. 19 20:27:35 eyak fetchmail[2556]: Not starting fetchmail daemon, disabled 
via /etc/default/fetchmail.
sept. 19 20:27:35 eyak systemd[1]: Started LSB: init-Script for system wide 
fetchmail daemon.
sept. 19 21:35:02 eyak systemd[1]: Stopping LSB: init-Script for system wide 
fetchmail daemon...
sept. 19 21:35:02 eyak fetchmail[22013]: Not starting fetchmail daemon, 
disabled via /etc/default/fetchmail.
sept. 19 21:35:02 eyak systemd[1]: fetchmail.service: Deactivated successfully.
sept. 19 21:35:02 eyak systemd[1]: Stopped LSB: init-Script for system wide 
fetchmail daemon.
dpkg: erreur de traitement du paquet fetchmail (--configure) :
 installed fetchmail package post-installation script subprocess returned error 
exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 fetchmail
vdanjean@eyak:~$ sudo systemctl cat fetchmail
# /run/systemd/generator.late/fetchmail.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fetchmail
Description=LSB: init-Script for system wide fetchmail daemon
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=network-online.target
After=remote-fs.target
After=mail-transport-agent.target
After=postfix.service
After=exim4.service
After=nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fetchmail start
ExecStop=/etc/init.d/fetchmail stop
vdanjean@eyak:~$ sudo systemctl restart fetchmail
Failed to restart fetchmail.service: Unit sysinit.target not found.
vdanjean@eyak:~$ sudo systemctl status sysinit.target
● sysinit.target
 Loaded: not-found (Reason: Unit sysinit.target not found.)
 Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 16min ago
  Until: Mon 2022-09-19 20:27:32 CEST; 1h 16min ago

sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization.
vdanjean@eyak:~$ sudo systemctl daemon-reexec 
vdanjean@eyak:~$ sudo systemctl status sysinit.target
● sysinit.target
 Loaded: not-found (Reason: Unit sysinit.target not found.)
 Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 17min ago
  Until: Mon 2022-09-19 20:27:32 CEST; 1h 17min ago

sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization.
vdanjean@eyak:~$ dpkg -S sysinit.target
udev: /lib/systemd/system/sysinit.target.wants/systemd-udevd.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysctl.service
systemd: /lib/systemd/system/sysinit.target.wants/dev-hugepages.mount
systemd: /lib/systemd/system/sysinit.target.wants/systemd-random-seed.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysusers.service
systemd: /lib/systemd/system/sysinit.target.wants/veritysetup.target
systemd: 
/lib/systemd/system/sysinit.target.wants/systemd-machine-id-commit.service
udev, systemd: /lib/systemd/system/sysinit.target.wants
udev: /lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-journald.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-update-utmp.service
systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount
systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount
systemd: /lib/systemd/system/sysinit.target
systemd: /lib/systemd/system/sysinit.target.wants/dev-mqueue.mount
systemd: /lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
systemd: 
/lib/systemd/system/sysinit.target.wants/systemd-ask-password-console.path
systemd: /lib/systemd/system/sysinit.target.wants/systemd-binfmt.service
systemd: 

Bug#1020311: sysprof: GNOME Builder needs sysprof-3 service

[Jeremy Bicha]

Source: sysprof
Version: 3.45.1-2
Severity: important

When I run GNOME Builder from the command line without the sysprof
package installed, I get this warning:

gbp-sysprof-workbench-addin[ 708235]:  WARNING: Sysprof-3 is not
supported, will not enable profiler:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.Sysprof3 was not provided by any .service files

/usr/libexec/sysprof is architecture-dependent so maybe we should do
something like this:

sysprofd arch: any package
---
lib/systemd
usr/libexec
usr/share/dbus-1
usr/share/polkit-1

sysprof-common arch:all package
-
usr/share/help
usr/share/icons
usr/share/locale

Have libsysprof-4 depend on sysprof-common. Maybe have it recommend
sysprofd too.

Thank you,
Jeremy Bicha

Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

[Robin Jarry]

Paul Gevers, Sep 19, 2022 at 21:52:
> Architecture: !armel !armhf
> is supported.

Awesome. I'll upload a new version with that fix then.

Thanks!

Bug#1020310: lists.debian.org: missing msgid-search link

[Jakub Wilk]

Package: lists.debian.org

https://lists.debian.org/debian-devel-announce/2022/04/msg7.html 
doesn't have the msgid-search link.


Maybe the software is confused because the message-id contains "/"? It's 
a bit unusual, but valid AFAICT.


--
Jakub Wilk

Bug#808940: Getting an executable

[Geert Stappers]

Hi,


Here my summary and notes on 
https://github.com/hashicorp/terraform/blob/main/.github/CONTRIBUTING.md#terraform-clicore-development-environment

Having `git` and `golang-go` installed.
Have "hello world" for go compiled and run, so you know that it works.

Copy and paste this in your command line terminal:


git clone https://github.com/hashicorp/terraform.git
cd terraform/
go install .
ls -lh $(go env GOPATH)/bin/terraform
$(go env GOPATH)/bin/terraform version
 

This what you can expect as output

stappers@myhost:/usr/src/github
$ git clone https://github.com/hashicorp/terraform.git
Cloning into 'terraform'...
remote: Enumerating objects: 264828, done.
remote: Counting objects: 100% (244/244), done.
remote: Compressing objects: 100% (146/146), done.
remote: Total 264828 (delta 139), reused 174 (delta 94), pack-reused 264584
Receiving objects: 100% (264828/264828), 231.55 MiB | 1.74 MiB/s, done.
Resolving deltas: 100% (164863/164863), done.
stappers@myhost:/usr/src/github
$ cd terraform/
stappers@myhost:/usr/src/github/terraform
$ go install .
   most likely several lines of "downloading something"
   and no additional output
stappers@myhost:/usr/src/github/terraform
$ ls -lh $(go env GOPATH)/bin/terraform
-rwxr-xr-x 1 gs0604 gs0604 82M 19 sep 20:49 /home/stappers/go/bin/terraform
stappers@myhost:/usr/src/github/terraform
$ $(go env GOPATH)/bin/terraform version
Terraform v1.3.0-dev
on linux_amd64
stappers@myhost:/usr/src/github/terraform
$ 


What me did surprise, was how quick / fast the compile is
after the download. I was wondering "Already now a succesfull build?"
In doubt I did another `go install .` which was immediatly finished.
Yes, that build went again fast.

To get the executable "installed" I did:

   
   sudo ln -s /home/stappers/go/bin/terraform /usr/bin/


That symlink will help to be up to date with what is build.



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1020309: ufoai-server: Server is not reading debian_server.cfg

[Jarno van der Kolk]

Package: ufoai-server
Version: 2.5-6
Severity: normal
X-Debbugs-Cc: silvercana...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation?
 * I installed ufoai-server through apt. Starting the server showed an 
error in journalctl
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 * I tried setting configuration options in 
/usr/lib/ufoai-server/debian-server.cfg which
   is a symlink to /etc/ufoai-server/server.cfg.
   * What was the outcome of this action?
 * None of the options were applied
   * What outcome did you expect instead?
 * That the options would be used by the server

I found a workaround for this (or perhaps the actual solution). The issue seems 
to have to do
with the WorkingDirectory in the SystemD unit. If I add this to the SystemD 
unit, then
ufoai-server will successfully read the config file

  WorkingDirectory=/usr/lib/ufoai-server

That solved my issue.

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

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

Versions of packages ufoai-server depends on:
ii  adduser  3.118
ii  libc62.31-13+deb11u4
ii  libcurl3-gnutls  7.74.0-1.3+deb11u3
ii  libgcc-s110.2.1-6
ii  libsdl2-2.0-02.0.14+dfsg2-3+deb11u1
ii  libstdc++6   10.2.1-6
ii  ufoai-common 2.5-6
ii  ufoai-maps   2.5-2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

ufoai-server recommends no packages.

Versions of packages ufoai-server suggests:
pn  ufoai  

-- Configuration Files:
/etc/ufoai-server/server.cfg changed [not included]

-- no debconf information

Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

[Paul Gevers]

Hi Robin,

On 19-09-2022 21:17, Robin Jarry wrote:

Paul Gevers, Sep 19, 2022 at 21:13:

I consider tests marked flaky as not so useful. Obviously if you'll
look at it from time to time it's OK, but if no human is going to
inspect it, it's smarter to just skip those architectures. Doing the
latter is also easier than the former as we have the "Architecture"
field for that, while flaky per arch you'd need to implement yourself.


I can live with disabling these tests on armel and armhf. If
I understood correctly, the Architecture field in d/t/control does not
support exclusions and it requires to set what arch is supported. I did
not found any explicit docs on that matter. Is there a way to list
multiple architectures?


Architecture: !armel !armhf
is supported.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020308: openssl: Test 90-test_threads.t fails randomly.

[Sebastian Andrzej Siewior]

Package: openssl
Version: 3.0.5-3
Severity: serious
control: forwarded -1 https://github.com/openssl/openssl/issues/19243

After touching test/default.cnf in the last upload, the
90-test_threads.t test fails randomly on the last step
(test_lib_ctx_load_config()). Sometimes
"malloc(): unaligned tcache chunk detected"
is visible. On amd64 it just segfaulted on the buildd, the retry
succeeded.

Sebastian

Bug#1011511:

[Limonciello, Mario]

[Public]

https://github.com/fwupd/fwupd/pull/5041 may help your problem, can you try 
that?

Bug#1020307: src:qtfeedback-opensource-src: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: qtfeedback-opensource-src
Version: 5.0~git20180903.a14bd0b-3
Severity: serious
Control: close -1 5.0~git20180903.a14bd0b-4
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:qtfeedback-opensource-src 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=qtfeedback-opensource-src



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

[Robin Jarry]

Paul Gevers, Sep 19, 2022 at 21:13:
> I consider tests marked flaky as not so useful. Obviously if you'll
> look at it from time to time it's OK, but if no human is going to
> inspect it, it's smarter to just skip those architectures. Doing the
> latter is also easier than the former as we have the "Architecture"
> field for that, while flaky per arch you'd need to implement yourself.

I can live with disabling these tests on armel and armhf. If
I understood correctly, the Architecture field in d/t/control does not
support exclusions and it requires to set what arch is supported. I did
not found any explicit docs on that matter. Is there a way to list
multiple architectures?

Bug#1020218: vcmi: luajit got removed on ppc64el, please either drop vcmi on ppc64el or switch to lua

[Paul Gevers]

Hi,

On 19-09-2022 11:09, Stephen Kitt wrote:
I don’t think Paul was necessarily asking to remove ppc64el from the 
list of architectures in debian/control, but rather asking to remove the 
ppc64el binary package if we can’t get it working with liblua.


Exactly. And as the Build-Depends aren't available, the package will not 
be build again until somebody provides (hopefully working) libluajit 
binaries again.


The best course of action IMO is to file a RM bug for vcmi on ppc64el so 
that the package can migrate to testing, and then if someone fixes the 
Lua situation (either on pcc64el globally, or by switching vcmi to 
liblua) the package will become available on ppc64el again.


Exactly.

[To answer the question in the other mail, no, I have absolutely no 
knowledge about lua at all. I know the name, and I know luajit is broken 
on ppc64el.]


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?

[Paul Gevers]

Hi Robin,

On 19-09-2022 10:41, Robin Jarry wrote:

Would it be acceptable to mark these tests as flaky only on armel and
armhf?


I consider tests marked flaky as not so useful. Obviously if you'll look 
at it from time to time it's OK, but if no human is going to inspect it, 
it's smarter to just skip those architectures. Doing the latter is also 
easier than the former as we have the "Architecture" field for that, 
while flaky per arch you'd need to implement yourself.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020306: src:neurodebian: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: neurodebian
Version: 0.41.0
Severity: serious
Control: close -1 0.41.1
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:neurodebian 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=neurodebian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020305: src:emmax: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: emmax
Version: 0~beta.20100307-1
Severity: serious
Control: close -1 0~beta.20100307-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:emmax has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. The latest upload added an 
autopkgtest (which I always applaud), but if fails everywhere except 
amd64  and i386.


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019869: systemtap of debian testing not work with the default testing kernel 5.19

[Frank Ch. Eigler]

Hi -

>  WARNING: nginx pid 3525 target 3525
>  ERROR: read fault [man error::fault] at 0x561c9d23e380 near operator
>  '@var' at samples/openresty.stp:18:17
>  WARNING: Number of errors: 1, skipped probes: 0
>  WARNING: /usr/bin/staprun exited with status: 1
>  Pass 5: run completed in 0usr/70sys/569real ms.
>  Pass 5: run failed.  [man error::pass5]
>  Tip: /usr/share/doc/systemtap/README.Debian should help you get
>  started.
> 
>However, not all global var access will fail, if I build luajit from
>source code, and get a global var named globalL, it will success.

Please raise this with the openresty folks instead of debian.  A
robust stap script must be prepared for intermittent access errors of
@var() type expressions, via constructs such as try/catch.

- FChE

Bug#1020060: statsmodels: FTBFS: make[1]: *** [debian/rules:105: override_dh_auto_test] Error 1

[Rebecca N. Palmer]

This is the same test as #1014278 / upstream 8341, but now on amd64. 
From the upstream discussion, it may be a numerically unstable test.


It doesn't fail everywhere: a test build on Salsa CI passed, as did the 
last debci runs.  (reproducible-builds FTBFS on the second build, on 
amd64/sid only, but on a _different_ test.)

Bug#998779: bs1770gain: bashism in configure script

[Andrej Shadura]

Hi,

On Mon, 19 Sep 2022, at 19:11, Petter Reinholdtsen wrote:
> [Andrej Shadura]
>> Your package uses configure script with bash features not present in
>> POSIX without explicitly declaring the need to bash shell; this
>> currently works as configure scripts select bash, but when dash enables
>> LINENO support, your configure script will start failing:
>
> Can you confirm that this patch solve the problem.  It seem to work for
> me:

Thanks, I think this should fix the issue.

-- 
Cheers,
  Andrej

Bug#1017354: coreutils: New upstream releases

[Samuel Henrique]

CC'ing Michael,

Hello Michael, somebody was asking on IRC about coreutils and I
noticed that you're still active, so this might just be a miss or you
might be looking for help maintaining coreutils.

Would you be willing to take people as co-maintainers, or people to
work in the newer upstsream releases?

Thank you,

-- 
Samuel Henrique 

Bug#1020304: pygobject: please backport to bullseye

[Martin]

Source: pygobject
Version: 3.42.2-2
Severity: wishlist

The next version of Gajim will depend on a newer python3-gi than is
available in Debian 11, because of:

> 3.42.0 - 2021-09-19
> * Expose GObject.Object.run_dispose() :issue:`470`

Therefore, I like to backport pygobject to be able to continue the
line of backports of Gajim for users of Debian stable.

The backport seems to be trivial, no further dependencies nor patches
are needed. If nobody objects, I'll upload to bpo soon.

Bug#1019586: gnome-shell-extension-weather: Extension not compatible with libsoup3

[Jeremy Bicha]

On Mon, Sep 19, 2022 at 12:01 PM Brandon Snider
 wrote:
>
> Hi, the repo is now public. I don't see anywhere that I can apply for group 
> membership, but I'm sure you can now figure out a way to merge my repo with 
> the team.

https://wiki.debian.org/Salsa/Doc

I saw that you pushed a debian/master branch. We use git-buildpackage
and therefore we also need the pristine-tar and upstream/latest
branches updated. If your local repo doesn't have those branches, you
can revert back to the commit before you imported the new version and
then run

gbp import-orig --uscan

And it should handle updating all 3 branches. Then (force-) push the 3
branches and the git tag upstream/0_git20220918.gitdc4a165

Also, please git rm the Debian patches you remove from debian/patches/series

Thank you for all your work here!


Jeremy Bicha

Bug#1008296: Workaround for my machine

[Alban Browaeys]

About modeset, ie Kernel Mode Setting being required or not I found
this about https://wiki.archlinux.org/title/Wayland#Requirements 5.1
that "Enabling DRM KMS is required.". THe next link points to
https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html
which tells that:
"
Requirements

The following are necessary to enable accelerated rendering on Xwayland
with the NVIDIA driver:

   - DRM KMS must be enabled. See Chapter 36, Direct Rendering Manager
Kernel Modesetting (DRM KMS) for details.

   - The installed copy of Xwayland should be a build from the master
branch of https://gitlab.freedesktop.org/xorg/xserver at least as
recent as commit c468d34c. Note that if this requirement is not
satisfied, the NVIDIA GPU can still be used for rendering, however it
will fall back to a suboptimal path for presentation resulting in
degraded performance.

   - libxcb version 1.13 or later must be present.

   - egl-wayland version 1.1.7 or later must be present (if installed
separately from the the NVIDIA driver).

   - If using the GNOME desktop environment, kms-modifiers must be
enabled through gsettings. This can be done with the following command
gsettings set org.gnome.mutter experimental-features [\"kms-
modifiers\"]

"

So currently, once logged in gnome wayland without modeset enabled, you
should not have Xwayland application (most games) running hardware
accelerated.
To not end up on software acceleration you have to enable KMS (by the
settings I sent you previously) and also setting an experimental
feature in the gnome session:
gsettings set org.gnome.mutter experimental-features [\"kms-modifiers\"]

maybe you can check if you are on software acceleration on Xwayland
with glxgears/glxinfo . Maybe you can send your glxinfo output without
nvidia modeset set and logged in a wayland session?


Kind regards,

Alban

Bug#1020303: bullseye-pu: package modsecurity-apache/2.9.3-3+deb11u2

[Alberto Gonzalez Iniesta]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: airw...@gmail.com, christian.fol...@netnea.com


[ Reason ]

modsecurity-crs has been released today [1]. It fixes a security issue,
here is the announcement:

CVE-2022-39956 - Content-Type or Content-Transfer-Encoding MIME header fields
abuse

The OWASP ModSecurity Core Rule Set (CRS) is affected by a partial rule set
bypass for HTTP multipart requests by submitting a payload that uses a
character encoding scheme via the Content-Type or the deprecated
Content-Transfer-Encoding multipart MIME header fields that will not be
decoded and inspected by the web application firewall engine and the rule set.
The multipart payload will therefore bypass detection. A vulnerable backend
that supports these encoding schemes can potentially be exploited. The legacy
CRS versions 3.0.x and 3.1.x are affected, as well as the currently supported
versions 3.2.1 and 3.3.2. Integrators and users are advised to upgrade to
3.2.2 and 3.3.3 respectively.

Important: The mitigation against these vulnerabilities depends on the
installation of the latest ModSecurity version (v2.9.6/v3.0.8) or an updated
version with backports of the security fixes in these versions.
If you fail to update ModSecurity, the webserver / engine will refuse to start
with the following error message: "Error creating rule: Unknown variable:
MULTIPART_PART_HEADERS".
You can disable / remove the rule file REQUEST-922-MULTIPART-ATTACK.conf from
the release in order to allow you to run the latest CRS without a fix to
CVE-2022-39956, however we advise against this workaround.
--

As you may see in [1] a newer modsecurity is needed in other to apply
this fix. We, modsecurity packaging team, are preparing a patched
version of both modsecurity-apache (this bug report) and libmodsecurity3
(coming up). After that we'll upload the updated modsecurity-crs.


[ Impact ]
No support for the fixed version of modsecurity-crs.

[ Risks ]
Patch is not big. It has been tested. No risks should be expected.


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

[ Changes ]
Added patch to support new required variable "MULTIPART_PART_HEADERS".


Will wait for your OK before uploading.

Thanks.

[1] https://github.com/coreruleset/coreruleset/releases
diff -Nru modsecurity-apache-2.9.3/debian/changelog 
modsecurity-apache-2.9.3/debian/changelog
--- modsecurity-apache-2.9.3/debian/changelog   2021-12-01 16:04:02.0 
+0100
+++ modsecurity-apache-2.9.3/debian/changelog   2022-09-08 23:59:34.0 
+0200
@@ -1,3 +1,9 @@
+modsecurity-apache (2.9.3-3+deb11u2) bullseye; urgency=medium
+
+  * Added multipart_part_headers.patch
+
+ -- Ervin Hegedus   Thu, 08 Sep 2022 23:59:34 +0200
+
 modsecurity-apache (2.9.3-3+deb11u1) bullseye-security; urgency=high
 
   * Added json_depth_limit.patch
diff -Nru modsecurity-apache-2.9.3/debian/patches/multipart_part_headers.patch 
modsecurity-apache-2.9.3/debian/patches/multipart_part_headers.patch
--- modsecurity-apache-2.9.3/debian/patches/multipart_part_headers.patch
1970-01-01 01:00:00.0 +0100
+++ modsecurity-apache-2.9.3/debian/patches/multipart_part_headers.patch
2022-09-08 23:59:34.0 +0200
@@ -0,0 +1,410 @@
+Description: This patch adds MULTIPART_PART_HEADERS variable
+ ModSecurity creates from now a new variable: MULTIPART_PART_HEADERS
+ This needs for some special CoreRuleSet rules, which has allocated CVE's.
+Author: Ervin Hegedus 
+
+---
+Origin: other
+Bug: not published yet
+Last-Update: 2022-09-08
+
+--- modsecurity-apache-2.9.3.orig/apache2/msc_multipart.c
 modsecurity-apache-2.9.3/apache2/msc_multipart.c
+@@ -318,7 +318,14 @@ static int multipart_process_part_header
+ }
+ 
+ msr->mpd->mpp_state = 1;
++msr->mpd->mpp_substate_part_data_read = 0;
+ msr->mpd->mpp->last_header_name = NULL;
++
++/* Record the last part header line in the collection */
++if (msr->mpd->mpp->last_header_line != NULL) {
++*(char **)apr_array_push(msr->mpd->mpp->header_lines) = 
msr->mpd->mpp->last_header_line;
++msr_log(msr, 9, "Multipart: Added part header line \"%s\"", 
msr->mpd->mpp->last_header_line);
++}
+ } else {
+ /* Header line. */
+ 
+@@ -372,12 +379,28 @@ static int multipart_process_part_header
+ *error_msg = apr_psprintf(msr->mp, "Multipart: Part header 
too long.");
+ return -1;
+ }
++if ((msr->mpd->mpp->last_header_line != NULL) && 
(msr->mpd->mpp->last_header_name != NULL)
++&& (new_value != NULL)) {
++msr->mpd->mpp->last_header_line = apr_psprintf(msr->mp,
++"%s: %s", 

Bug#1018770: llvm-14-dev: misspelling in headers gets compiled into other binaries

[Andreas Beckmann]

Another one:

/usr/include/llvm-14/llvm/Support/CommandLine.h:   "cl::Grouping can only 
apply to single charater Options.");

s/charater/character/


Andreas

Bug#942734: bs1770gain does not escape file names properly in XML output

[Petter Reinholdtsen]

[Etienne Dechamps 2019-10-20]
> Version: 0.6.5-1
> 
> Steps to reproduce:
> 
> $ sox -n '1 & 2.wav' synth 1 sine 1000
> $ bs1770gain --xml --suppress-progress . | xmllint -
> -:3: parser error : xmlParseEntityRef: no name
> 
>  ^
> 
> Correct escaping would be "1  2.wav".
> 
> This is a regression from bs1770gain 0.5.2-2, which did escape file names.

There is a non-fatal test for this in debian/tests/ now, and I see from
the latest run on amd64 that it is still a problem.  From
https://ci.debian.net/data/autopkgtest/unstable/amd64/b/bs1770gain/26130724/log.gz
 >:

-:2: parser error : xmlParseEntityRef: no name
  
   ^
error: xmllint rejected XML output with ampersant in filename

Peter, any chance to have proper escaping in the XML output?
-- 
Happy hacking
Petter Reinholdtsen

Bug#998779: bs1770gain: bashism in configure script

[Petter Reinholdtsen]

[Andrej Shadura]
> Your package uses configure script with bash features not present in
> POSIX without explicitly declaring the need to bash shell; this
> currently works as configure scripts select bash, but when dash enables
> LINENO support, your configure script will start failing:

Can you confirm that this patch solve the problem.  It seem to work for
me:

diff --git a/configure.ac b/configure.ac
index 411da35..1a99ae5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,7 +132,7 @@ if test "x$ffmpeg" != "xno"; then # [
 AC_CHECK_LIB(avfilter, avfilter_version, [ffmpeg=yes LIBS="${LIBS} 
-lavfilter"], ffmpeg=no),
 ffmpeg=no)
 fi # ]
-if test "x$ffmpeg" == "xno" ; then # [
+if test "x$ffmpeg" = "xno" ; then # [
   AC_MSG_ERROR([FFmpeg not found])
 fi # ]
 # test for FFmpeg ]
@@ -312,7 +312,7 @@ if test "x$dynload" = "xyes"; then # [
 AC_CHECK_LIB(dl, dlopen, [dl=yes LIBS="${LIBS} -ldl"], dl=no),
 dl=no)
 fi # ]
-if test "x$dl" == "xno" ; then # [
+if test "x$dl" = "xno" ; then # [
   AC_MSG_ERROR([libdl not found])
 fi # ]
   fi # ]
@@ -373,7 +373,7 @@ else # ] [
 AC_CHECK_HEADER(libproc.h, AC_CHECK_LIB(proc, proc_pidpath,
   [proc=yes LIBS="${LIBS} -lproc"], proc=no), proc=no)
 
-if test "x$proc" == "xno" ; then # [
+if test "x$proc" = "xno" ; then # [
   AC_MSG_ERROR([libproc not found])
 else # ] [
   AC_DEFINE([HAVE_LIBPROC], [1], [Define to 1 if you have libproc.])
@@ -390,7 +390,7 @@ else # ] [
   AC_CHECK_HEADER(pthread.h,
 AC_CHECK_LIB(pthread, pthread_create, [pthread=yes LIBS="${LIBS} 
-pthread"], pthread=no),
 pthread=no)
-  if test "x$pthread" == "xno" ; then # [
+  if test "x$pthread" = "xno" ; then # [
 
AC_MSG_NOTICE([***])
 AC_MSG_NOTICE([* pthread not found.
  *])
 AC_MSG_NOTICE([* bs10gain will be build without support for parallel 
processing. *])

CC to upstream.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Russ Allbery  writes:

> The killer features of YAML for the purposes of the copyright format are
> the > and | symbols after a key, which let you write paragraphs of text
> afterwards with normal structural indentation and full editor support
> for wrapping and the like, and you can choose whether you want
> significant whitespace.

I said I wasn't going to get into this, but of course now I can't stop
thinking about it.  For those who haven't done very much with YAML, an
example may help illustrate what I'm talking about.

Here's the copyright file for libpgp-sign-perl, which is fairly simple,
converted to a hypothetical YAML syntax.  I moved the Expat license to a
separate license stanza to illustrate how that would work, and I also made
up some structure to represent a bunch of the things we put into a
copyright-format file as plain text right now that we could turn into less
ambiguous fields.  The latter we can of course do in the current syntax,
so that's not the interesting part; the interesting part is to look at
what's required to represent the structure, how much nested structure you
can add, and how the text blocks are handled in the format.  There is also
an illustration of how to handle long copyright lines in here.

Note that YAML syntax and schema checkers are also quite common, so we
can easily provide tools to validate these files without writing bespoke
parsers the way that I did for Lintian with the current syntax.

I'm erring on the side of very unambiguous nested structure here and
avoiding any implicit semantics, which may be overkill; we could tone that
down quite a bit if we wanted in the name of making the file less complex.
(Or we could go a step further and split the years from the holder in
copyright statements, but that feels like overkill even to me.)

Also try saving this as a file ending in .yaml in your favorite editor, if
you haven't done a lot of YAML work before, and see how well it handles it
for syntax highlighting, editing, etc.  Emacs handles it extremely well
with elpa-yaml-mode installed.  vim, at least without any add-ons
installed, does some syntax highlighting but is still a bit confused by
the text blocks and thinks colons are significant in them.  (There's
apparently a vim-yaml plugin that I don't have installed that might help
there.)


format: https://www.debian.org/doc/packaging-manuals/copyright-format/x.x/
upstream:
  contact: Russ Allbery 
  source:
urls:
  - https://www.eyrie.org/~eagle/software/pgp-sign/

files:
  - paths: [*]
copyrights:
  - 1997-2002, 2004, 2007, 2018, 2020 Russ Allbery 
license:
  identifier: Perl
  grant: |
This program is free software; you may redistribute it and/or
modify it under the same terms as Perl itself.  This means that
you may choose between the two licenses that Perl is released
under:  the GNU GPL and the Artistic License.  Please see your
Perl distribution for the details and copies of the licenses.
  pointers:
- /usr/share/common-licenses/GPL-1
- /usr/share/common-licenses/Artistic

  - paths:
  - t/data/perlcriticrc
  - t/docs/pod-coverage.t
  - t/docs/pod-spelling.t
  - t/docs/pod.t
  - t/docs/spdx-license.t
  - t/docs/synopsis.t
  - t/lib/Test/RRA.pm
  - t/lib/Test/RRA/Config.pm
  - t/style/coverage.t
  - t/style/critic.t
  - t/style/minimum-version.t
  - t/style/obsolete-strings.t
  - t/style/strict.t
copyrights:
  - >-
2011-2014 The Board of Trustees of the Leland Stanford Junior
University
  - 2015-2016, 2018-2020 Russ Allbery 
license:
  identifier: Expat

  - paths: [t/data/perltidyrc]
copyrights:
  - >-
2012-2013 The Board of Trustees of the Leland Stanford Junior
University
license:
  identifier: all-permissive
  text: |
Copying and distribution of this file, with or without
modification, are permitted in any medium without royalty provided
the copyright notice and this notice are preserved.  This file is
offered as-is, without any warranty.

licenses:
  - identifier: Expat
text: |
  Permission is hereby granted, free of charge, to any person
  obtaining a copy of this software and associated documentation files
  (the "Software"), to deal in the Software without restriction,
  including without limitation the rights to use, copy, modify, merge,
  publish, distribute, sublicense, and/or sell copies of the Software,
  and to permit persons to whom the Software is furnished to do so,
  subject to the following conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A 

Bug#1008296: Workaround for my machine

[alban . browaeys]

On Thu, 8 Sep 2022 17:22:00 -0300 =?UTF-8?Q?Sebasti=C3=A1n_Lacuesta?=
 wrote:
> Hi Alban,
> 
> My nvidia driver version: 510.85.02-1
> 
> cat /sys/module/nvidia_drm/parameters/modeset
> N


the gdm udev rules work how they ought to, ie:
/lib/udev/rules.d/61-gdm.rules "
# disable wayland if nvidia-drm modeset is not enabled
ATTR{parameters/modeset}!="Y", GOTO="gdm_disable_wayland"
"

a way around is
https://wiki.archlinux.org/title/GDM#Wayland_and_the_proprietary_NVIDIA_driver
ie https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting,
that is, add in /etc/default/grub to "GRUB_CMDLINE_LINUX_DEFAULT":
"nvidia_drm.modeset=1"
the run update-grub as root.

> 
> grep nomodeset /proc/cmdline
> 
> 
> Cheers,
> 
> Sebastián
> 
> El sáb, 27 ago 2022 a las 3:20,  escribió:
> 
> > On Fri, 8 Apr 2022 18:19:06 -0300 =?UTF-
8?Q?Sebasti=C3=A1n_Lacuesta?=
> >  wrote:
> > > Overwritting 61-gdm.rules with
> > >
> > > ln -s /dev/null /etc/udev/rules.d/61-gdm.rules
> > >
> > > solves the issue for me.
> >


About drm modeset
https://ubuntuforums.org/showthread.php?t=1613132  "
The newest kernels have moved the video mode setting into the kernel.
So all the programming of the hardware specific clock rates and
registers on the video card happen in the kernel rather than in the X
driver when the X server starts.. This makes it possible to have high
resolution nice looking splash (boot) screens and flicker free
transitions from boot splash to login screen. Unfortunately, on some
cards this doesnt work properly and you end up with a black screen.
Adding the nomodeset parameter instructs the kernel to not load video
drivers and use BIOS modes instead until X is loaded.
"
So enabling Kernel Mode Setting might lead to a black screen before the
nvidia driver is loaded (gdm start) if the nvidia driver is broken (or
not loaded).



>From https://wiki.archlinux.org/title/Wayland#XWayland 5.1 tells
enabling DRM KMS is required (for XWayland application only ?, ie most
games).



For early loading (console with optional "high resolution nice looking
splash (boot) screens and flicker free transitions from boot splash to
login screen") add in /etc/initramfs-tools/modules:
"nvidia nvidia_modeset nvidia_uvm nvidia_drm"
then run:
update-initramfs -u
(this only update the latest installed kernel), or for all kernels:
update-initramfs -u -k all
This if you want o try plymouth or want to set "GRUB_GFXMODE=" in
/etc/default/grub.

https://wiki.archlinux.org/title/kernel_mode_setting 2.1 tells that
NVIDIA kms has to be manually enabled (what we saw above).

All in all I do not believe this is software gdm bug that you cannot
start gdm in wayland mode with nvidia modesetting disabled (even if it
is disabled by default).

Can you confirm that with nvidia modeset enabled you do not need any
hack to start GDM in wayland mode (ie as i GDM shows gnome xorg and
wayland options)?
This is still an issue but a note on 
/usr/share/doc/gdm3/README.Debian might be enough to clarify that on
nvidia setups one has to enable modeset on grub?

Kind regards,

Alban


PS: I still do not know if current NVIDIA driver default to not enable
modeset is really an issue for gnome wayland or if only helps with
screen flickers when switching from wyaland to console and helps with
advanced graphics on boot console.
Maybe this requirement could be removed, and in this case this bug
should be forwarded upstream.

Bug#808940: https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251244275

[Geert Stappers]

Hello,

Core of this Debian bug tracking system update
is https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251244275

- Forwarded message from Martin Atkins  -

Date: Mon, 19 Sep 2022 09:20:23 -0700
From: Martin Atkins 
To: hashicorp/terraform 
Cc: Geert Stappers , Comment 
Subject: Re: [hashicorp/terraform] Publish arm64 Terraform packages in the 
HashiCorp "apt" repository (Debian/Ubuntu packages) (#27378)

It seems that this Debian RFP originally started in 2015 while Terraform
v0.6 was the current version, and consequently it got bogged down in
the fact that Terraform v0.6 still had all of the HashiCorp-distributed
providers directly in the main distribution and therefore the package
would need to depend on the union of all dependencies of all of the
providers.

Thankfully that hasn't been true since Terraform v0.10, and
also with Terraform v1.0 establishing [the v1.x compatibility
promises](https://www.terraform.io/language/v1-compatibility-promises)
the rate of change to Terraform is slower now and so probably a more
appropriate speed for Debian's process such that the version available
in Debian Stable is likely to remain useful for longer than Terraform
v0.6 would've.

With all of that said: we unfortunately don't have the resources to
participate directly in the packaging processes for Debian and other
distributions. While we certainly would not object to Terraform being
packaged in Debian (nor should we!), I think it would be necessary for
someone in the Debian developer community to manage that particular
packaging. In particular, I don't think our methodology for building
APT packages would be acceptable for the main Debian repository: we take
literally the `terraform` executable from the official `.zip` packages and
copy it into a Debian binary package, whereas the main Debian repository
must always be buildable from source code. That is technically possible
to do but not how our own in-house packaging processes are built.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251244275
You are receiving this because you commented.

Message ID: 

- End forwarded message -

I triggered that response
with https://github.com/hashicorp/terraform/issues/27378#issuecomment-1251224003
which boils down to "cross reference link to Debian BTS issue,
have Terraform in Debian means have it available for release
architectures"

-- 
Silence is hard to parse

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Guillem Jover  writes:

> I think Disclaimer and Comment do not seem as problematic because they
> tend to contain descriptive prose. For Source it's true that it's weird
> as it seems to indeed want to have two different semantics depending on
> the content, and considering the current deb822 format, perhaps having
> used two different field names might have been better as you alluded
> with your YAML example, say Source-Urls (line-based list), and
> Source-Comment (formatted text). Such split still seems feasible and
> backwards compatible right now though.

Yes, good point.

> Just to try to clarify to make sure we are on the same page (if we are,
> sorry for the obvious!). What I find confusing is that the semantics of
> the field imply different line-wrapping semantics depending on leading
> spaces, and because there's no synopsis, the first line is supposed to
> act just like the rest, but if spaces are ignored, then how do you
> select either of the line-wrapping behaviors for the first line? Also
> because adding such spaces after the colon look like typographic errors
> to me somehow.

Ah, I see what you're getting at.  I was distinguishing between spaces on
the first line and spaces on subsequent lines and assuming that if you
wanted to mark the first line as verbatim you would have to have a newline
first.  Now that you point it out, it's clear that my brain has a fairly
complicated assumed semantic model here that isn't at all clear from the
description of the field and may not even be the right thing to do.

> So I think what seems most confusing to me is that for formatted-text
> fields with no synopsis, the first line is being used at all, because
> that messes with the intuition on how the Description field operates.

Yes, this makes sense.  Maybe we should encourage people to not use the
first line?  (Prohibiting it is presumably too much of a compatibility
break to be worth it.)

> I was thinking that perhaps an easy way out, might be to say that if the
> field contains an empty first line (nothing after the colon), then it's
> line based, otherwise it's considered formatted text. Which makes things
> more complex (perhaps "only" for a transition period), but might be
> considered backwards compat?

This sounded promising but unfortunately I think Wouter identified the
issue, which is that if we're defining extra leading whitespace as
indicating a continuation line (which is a somewhat natural thing to do in
a format based on RFC 822 header fields), this changes the semantics of
any existing Copyright fields that happen to have skipped the first line
but are using extra indentation to indicate verbatim lines.

I think I'm talking myself into introducing a new Copyright-Lines header
as the best theoretical fix, although that will be quite annoying for
Lintian and any other tool that currently parses the file, since any file
in the new format is going to look entirely invalid.

I knew the backward compatibility issues were going to be a whole can of
worms.

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

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Wouter Verhelst  writes:
> On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:

>> Yes, we should distinguish between formatted text with synopsis and
>> formatted text without synopsis more clearly.  Or, you know, just
>> propose a new YAML format which would make it trivial to clean up all
>> of these problems *and* would provide first-class editor support and
>> easy parsing in every major programming language.  :)  But that's WAY
>> bigger than this bug.

> If we're going to do that, it might make sense to explicitly allow JSON
> and/or TOML as alternative representations, because there are some
> really weird edge cases in YAML.

I don't want to get too far into this since I don't think we're
realistically ready to propose such a thing, but I spent a bunch of time
researching this for my static web site generator, and YAML is the best of
a bunch of bad options for precisely the kind of structured data we want
to put in the copyright file.  While I agree that most of the YAML
specification was a mistake and I really wish someone would produce a
reduced spec, there's a sad shortage of other widely-implemented syntaxes
that are usable for files intended to be read and written directly by
humans, particularly ones containing large blocks of text.

JSON is definitely not it; JSON is a great computer interchange format,
but I tried to use it for something complex and human-editable and I would
never do that again.  Too much fiddling around with quotes and commas and
escaping, and for the copyright format, the obvious problem that JSON has
no way of representing blocks of text that isn't horrible.  (That said, if
the file is YAML, you are allowing JSON, because all JSON is valid YAML
since YAML allows JSON as alternative syntax.  Yes, yes, the specification
is a sprawling mess.)

TOML looked for a while like it was going to be the format I was hoping
for, but they implemented nested dictionaries in a way that makes the
format incredibly annoying to use for anything that has nested structure.
More relevant to the copyright file, while it at least has multiline
literal strings, they're awkward to read and write, particularly in nested
structure, compared to YAML.  If you don't want the leading whitespace of
indentation to be significant, you have to put a backslash at the end of
every line, which is really not okay.  And unfortunately TOML is
incompatible with YAML, unlike JSON, so to support both you have to embed
both libraries and select which one to use, which is annoying.

The killer features of YAML for the purposes of the copyright format are
the > and | symbols after a key, which let you write paragraphs of text
afterwards with normal structural indentation and full editor support for
wrapping and the like, and you can choose whether you want significant
whitespace.

YAML also has excellent implementations for basically every programming
language and editor, which is mostly true of JSON and kind of true of TOML
and stops being true after that.  Yes, the spec is a disaster, but since
other people have already implemented it for you, including with
protections against the more dubious stuff, you don't have to care as long
as you don't creep into the dark corners when writing files.

I understand Guillem's desire to not make dpkg depend on a YAML library,
and we should stick with deb822 with anything that is required at that
level, but the copyright format is optional and from dpkg's perspective is
just an opaque file, so that's probably not a blocker.

> I think semantic versioning would require you make this a major version
> bump, since like you say it's not backwards compatible.

Yup.

> Ah yes, but then if you do that, the old examples in policy that were
> being patched away here (usage of which might exist in the wild) would
> now have different semantics...

Yeah, it's a mess.

Maybe the right solution is to introduce a new Copyright-Lines field with
the semantics we want and deprecate Copyright.

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

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

[Lev Kokotov]

Hi Christoph,

Yes, that looks like the right place for it.

Best,
Lev

On Mon, Sep 19, 2022 at 2:51 AM Christoph Berg  wrote:

> Re: Lev Kokotov
> > * Package name: postgresql-pgml
>
> Hi Lev,
>
> would you like to maintain this within the PostgreSQL team on Salsa?
>
> Christoph
>

Bug#1019586: gnome-shell-extension-weather: Extension not compatible with libsoup3

[Brandon Snider]

Hi, the repo is now public. I don't see anywhere that I can apply for group
membership, but I'm sure you can now figure out a way to merge my repo with
the team.

 -- Brandon J. Snider


On Mon, Sep 19, 2022 at 11:32 AM Jeremy Bicha 
wrote:

> On Mon, Sep 19, 2022 at 11:12 AM Brandon Snider
>  wrote:
> > The extension's author has abandoned the project, and it was forked. The
> newer version includes libsoup3 support. I have created a gitlab repo with
> updated debian packaging as well as the updated upstream files. My update
> can be merged into the salsa version, although, not being a team member, I
> can't create a merge request. The updates I created are right here:
>
> Please do apply for a Salsa account. Once that account is approved,
> you can submit merge requests.
>
> > https://gitlab.com/bjsnider/gnome-shell-extension-weather
>
> Your gitlab.com profile is private so I can't access that repo.
>
> > I installed this version from a deb and it works on testing. I imagine
> it will work with the dev version of Ubuntu as well.
>
> Ubuntu removed most GNOME Shell extension from their repository:
> https://discourse.ubuntu.com/t/removal-of-gnome-shell-extensions/18437/9
>
> Thank you,
> Jeremy Bicha
>

Bug#1020302: squashfs-tools-ng: multiarch support

[Luca Boccassi]

Source: squashfs-tools-ng
Version: 1.0.4-1

Dear Maintainer,

Could you please mark libsquashfs1 and libsquashfs-dev as "Multi-Arch:
same"? Everything seems to be built and installed in the right
directories already, so it should be just a matter of adding the fields
to debian/control.

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#841301: Comment booster votre chiffre d'affaires !

[Click'Art zone]

[image: logo-]
Comment booster votre chiffre d'affaires !
‌
‌

Avec la concurrence grandissante et les clients de plus en plus rares,
imaginez-vous obtenir chaque jour de nouveaux clients, être contacté par
des gens qui recherchent vos produits ou services, voir vos ventes exploser
et votre chiffre d’affaires croitre de façon exponentielle !

Bien entendu tout cela sans dépenser une grosse fortune ni en communication
ni en commission, sans passer par des intermédiaires et surtout en faisant
connaitre votre entreprise à travers tout le pays et même le monde.
[image: 6030259]

Voilà ce que nous réaliserons pour votre entreprise à travers la mise en
place et la gestion d’une stratégie de marketing digital très performante.

Avec plus de 5 millions de personnes y ayant accès rien qu’au Burkina Faso,
internet est le lieu idéal pour faire connaitre votre entreprise et pour
obtenir en un temps record des dizaines, voire des centaines de clients.
[image: social stats]
‌

Notre principale mission est d’insuffler une croissance accélérée aux
entreprises et si votre plus grand désir est d’avoir des clients de façon
croissante et régulière alors contactez-nous immédiatement et mettons en
place votre des stratégies pour faire de vos rêves une réalité.
L'agence,

Click’Art zone a accompagné des petites, grandes et très grandes
entreprises dans ce sens et vous pouvez découvrir nos domaines de
compétences sur notre site web à l’adresse : clickartzone.com

Contactez-nous !

‌
‌
‌

‌

You have received this email because you have subscribed to Clickartzone

as 841...@bugs.debian.org. If you no longer wish to receive emails please
désinscription

.
© 2022 Clickartzone, All rights reserved.
‌

Bug#1019586: gnome-shell-extension-weather: Extension not compatible with libsoup3

[Jeremy Bicha]

On Mon, Sep 19, 2022 at 11:12 AM Brandon Snider
 wrote:
> The extension's author has abandoned the project, and it was forked. The 
> newer version includes libsoup3 support. I have created a gitlab repo with 
> updated debian packaging as well as the updated upstream files. My update can 
> be merged into the salsa version, although, not being a team member, I can't 
> create a merge request. The updates I created are right here:

Please do apply for a Salsa account. Once that account is approved,
you can submit merge requests.

> https://gitlab.com/bjsnider/gnome-shell-extension-weather

Your gitlab.com profile is private so I can't access that repo.

> I installed this version from a deb and it works on testing. I imagine it 
> will work with the dev version of Ubuntu as well.

Ubuntu removed most GNOME Shell extension from their repository:
https://discourse.ubuntu.com/t/removal-of-gnome-shell-extensions/18437/9

Thank you,
Jeremy Bicha

Bug#1019944: wireplumber: Upgradeing to 0.4.11-5 breaks restoring the target of a stream if it is not the default stream

[Dylan Aïssi]

H,

Le ven. 16 sept. 2022 à 19:51, Matthias Heinz  a écrit 
:
>
> after upgrade wireplumber from 0.4.11-3 to 0.4.11-5 it fails to somehow 
> realize
> what the target of the last stream was, if it was not the default device.
> pavucontrol just reports it as "Unknown output" then.
>

In Wireplumber 0.4.11-4, a systemd service alias has been removed as a
workaround to a systemd bug. But, this was not reflected on the pipewire-pulse
service.

A new version of pipewire will be uploaded to solve that. See:
https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/16

Best,
Dylan

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

[Philipp Hahn]

Package: mariadb-server-10.3
Version: 1:10.3.36-0+deb10u
Severity: important

Dear Maintainer,

I'm working for Univention GmbH and we're running our own piuparts
tests; while doing this I noticed the following error, which is similar
for all plugin packages connect, cracklib-password-check, gssapi-server,
mroongga, opgraph, rocksdb, spider, tokudb:

> Preparing to unpack 
> .../mariadb-plugin-gssapi-server_10.3.36-0+deb10u1_amd64.deb ...
> Unpacking mariadb-plugin-gssapi-server:amd64 (1:10.3.36-0+deb10u1) ...
> Setting up mariadb-plugin-gssapi-server:amd64 (1:10.3.36-0+deb10u1) ...
> Processing triggers for mariadb-server-10.3 (1:10.3.36-0+deb10u1) ...
> postinst called with unknown argument 'triggered'
> dpkg: error processing package mariadb-server-10.3 (--configure):
>  installed mariadb-server-10.3 package post-installation script subprocess 
> returned error exit status 1
> Errors were encountered while processing:
>  mariadb-server-10.3
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Looking at the installed package itself I find this:

> # cat /var/lib/dpkg/info/mariadb-server-10.3.triggers
> interest-noawait /etc/mysql
> interest-noawait /etc/systemd/system/mariadb.service.d

but `triggered` is not handled by `mariadb-server-10.3.postinst`: 
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/buster/debian/mariadb-server-10.3.postinst#L148

> case "$1" in
>   configure)
…
>   ;;
>   abort-upgrade|abort-remove|abort-configure)
  ^ Add "|trigger" here
>   ;;
>   *)
> echo "postinst called with unknown argument '$1'" 1>&2
> exit 1
>   ;;
> esac

I do not (yet) know which debhelper generated `mariadb-server-10.3.triggers`
but the `debian/mariadb-server-10.3.postinst` template shipped in the Debian
source package should not block "$1 = triggered" but shold allow other
debhelper generated fragments inserted at #DEBHELPER# to handle this argument.

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

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

Bug#1019586: gnome-shell-extension-weather: Extension not compatible with libsoup3

[Brandon Snider]

The extension's author has abandoned the project, and it was forked. The
newer version includes libsoup3 support. I have created a gitlab repo with
updated debian packaging as well as the updated upstream files. My update
can be merged into the salsa version, although, not being a team member, I
can't create a merge request. The updates I created are right here:
https://gitlab.com/bjsnider/gnome-shell-extension-weather

I installed this version from a deb and it works on testing. I imagine it
will work with the dev version of Ubuntu as well.

 -- Brandon J. Snider

Bug#1020300: popt: non-source popt.pdf file

[Bastian Germann]

Source: popt
Version: 1.18-3
Severity: serious

The popt.pdf file is non-source and probably not DFSG-free licensed, so please 
remove it.
When repacking, please add a repacksuffix to the version number.

Bug#1019971: pipewire: please mention installing pipewire-alsa package in README.Debian

[Dylan Aïssi]

Hi,

Le sam. 17 sept. 2022 à 18:57, Dmitry Nezhevenko  a écrit :
>
> Btw is there any reason to do this copy manually? Maybe just put
> /etc/alsa/conf.d/99-pipewire-default.conf to pipewire-alsa?
>

Since pipewire-alsa has been split from the previous
pipewire-audio-client-libraries package, it would be useful indeed to directly
copy this file in the right location.

But, people upgrading their pipewire-audio-client-libraries package will
have pipewire-alsa installed and that will enable pipewire-alsa on their system
even if it was not enabled before the upgrade.

Then, I will wait at least until Bookworm is released to do it.

Best,
Dylan

Bug#1015833: sbuild: would be helpful to be able to override the autopkgtest options

[Johannes Schauer Marin Rodrigues]

Quoting Julian Gilbey (2022-09-19 16:55:11)
> > That is correct. But letting sbuild run autopkgtest is also a bad design
> > choice. Since the $autopkgtest_opts are a list of options, it would also be
> > bad to let the command line options just replace what was already set. So
> > then you need some sort of interface that lets you add or remove arbitrary
> > stuff. This can become very complicated very fast. We can also not change
> > this now because sbuild is also heavily used from scripts that now rely on
> > the existing functionality.
> 
> Another good point (about the bad design).  I wasn't suggesting changing the
> existing behaviour for exactly the reason you indicate, rather I was
> suggesting a new option to mean "clear all existing $autopkgtest_opts and
> start with an empty list".  But that also feels a bit clunky.

Yes, that could be done. But before I add another option to the already endless
list:

   sbuild [-h|--help | -V|--version] [-v|--verbose | -q|--quiet] [-D|--de‐
   bug]   [-A|--arch-all]   [--archive=archive]   [-d|--dist=distribution]
   [-c|--chroot=chroot]   [--chroot-mode=schroot|sudo|autopkgtest|unshare]
   [--arch=architecture] [--arch-any |  --no-arch-any]  [--build=architec‐
   ture]  [--host=architecture]  [--profiles=profile[,...]]  [-s|--source]
   [--force-orig-source]  [--make-binNMU=changelog-entry]   [--binNMU=NMU-
   version]   [--append-to-version=string]  [--binNMU-timestamp=timestamp]
   [--binNMU-changelog=changelog][--build-dir=directory][--add-de‐
   pends=dependency]  [--add-conflicts=dependency] [--add-depends-arch=de‐
   pendency] [--add-conflicts-arch=dependency] [--add-depends-indep=depen‐
   dency]  [--add-conflicts-indep=dependency] [-m|--maintainer=maintainer]
   [-e|--uploader=uploader]  [-k|--keyid=key-id]   [--source-only-changes]
   [--no-source-only-changes] [-j|--jobs=n] [--debbuildopt=option] [--deb‐
   buildopts=options] [--dpkg-source-opt=options]  [--dpkg-source-opts=op‐
   tions][--dpkg-file-suffix=suffix]   [-p|--purge=purge-mode]
   [--purge-build=purge-mode]   [--purge-deps=purge-mode][--purge-ses‐
   sion=purge-mode] [-b|--batch] [-n|--nolog] [--clean-source]
   [--no-clean-source][--run-lintian][--no-run-lintian][--lin‐
   tian-opt=options]   [--lintian-opts=options]   [--run-piuparts]
   [--no-run-piuparts] [--piuparts-opt=options]  [--piuparts-opts=options]
   [--piuparts-root-arg=options] [--piuparts-root-args=options] [--run-au‐
   topkgtest] [--no-run-autopkgtest] [--autopkgtest-opt=options] [--autop‐
   kgtest-opts=options] [--autopkgtest-root-arg=options] [--autop‐
   kgtest-root-args=options] [--pre-build-commands=string]  [--ch‐
   root-setup-commands=string][--chroot-update-failed-commands=string]
   [--build-deps-failed-commands=string][--starting-build-com‐
   mands=string]  [--finished-build-commands=string]  [--build-failed-com‐
   mands=string]   [--chroot-cleanup-commands=string]   [--post-build-com‐
   mands=string]   [--post-build-failed-commands=string]   [--any‐
   thing-failed-commands=string]   [--log-external-command-output]
   [--log-external-command-error]   [--setup-hook=hook-script]
   [--build-dep-resolver=resolver][--resolve-alternatives|--no-re‐
   solve-alternatives][--extra-package=package.deb]   [--extra-reposi‐
   tory=spec]   [--extra-repository-key=file.asc][--build-path=string]
   [--autopkgtest-virt-server=schroot|lxc|chroot|qemu|ssh]   [--autop‐
   kgtest-virt-server-opt=string] [--autopkgtest-virt-server-opts=options]
   [--purge-extra-packages]  [--bd-uninstallable-explainer=dose3|apt|none]
   [PACKAGE[.dsc]]

Before I do that, I would need a concrete use-case justifying it. If the %r
percent escape works for you, then I guess that's it.

Please close this bug if you think that there is nothing else to discuss.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#837336: ITP: gawkextlib -- Dynamically loaded extension libraries for GNU Awk

[Raul]

The source packages I was using are the individual tarballs available 
in the sourceforge website. But maybe I could use the git repository 
and from that single source build the multiple packages, including a 
metapackage to install all the libs, libgawkextlib included.

Bug#1019965: pydevd: FTBFS in sid (failed tests)

[Julian Gilbey]

On Sat, Sep 17, 2022 at 02:41:29PM +0200, Gianfranco Costamagna wrote:
> Source: pydevd
> Version: 2.8.0+git20220826.8ee4065+ds-1
> Severity: serious
> 
> Hello, please have a look at the build log, some tests are now failing.
> 
> Can also be seed in Debian CI
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/pydevd.html
> 
> Thanks for having a look.

Hi Gianfranco,

That's weird, as it built OK just two weeks ago.  Upstream's tests
succeed on this test, which is a little weird, so it might be a
version thing.  I'll report it upstream.

Best wishes,

   Julian

Bug#1020299: equinox-p2: wrong information in the manifest files

[Sudip Mukherjee]

Source: equinox-p2
Version: 4.21-1
Severity: important
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

The manifest file of equinox-p2 mentions that it needs bouncycastle 
version="1.65.0" but in Debian we have bouncycastle 1.71 and as a result any 
eclipse based application is not able to use equinox-p2 and it gives the errors 
like:

org.eclipse.equinox.p2.engine [130]
Unresolved requirement: Import-Package: org.bouncycastle.openpgp; 
version="1.65.0"

org.eclipse.equinox.p2.core [131]
Unresolved requirement: Import-Package: org.bouncycastle.bcpg; 
version="1.65.0"

-- 
Regards
Sudip

Bug#1020298: eclipse-platform-runtime: wrong information in the manifest files

[Sudip Mukherjee]

Source: eclipse-platform-runtime
Version: 4.19-1
Severity: important
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

eclipse-platform-runtime needs javax.annotation.PostConstruct and 
javax.annotation.PreDestroy and the MANIFEST.MF file mentions:

 Import-Package: javax.annotation;version="1.3.5" and also mentions
 javax.annotation;bundle-version="[1.3.5,2.0.0)" in Require-Bundle.
 
But in Debian these are provided by libgeronimo-annotation-1.3-spec-java which 
has a version of 1.3, also the bundle name of this package is not 
"javax.annotation", and so as a result any eclipse based application is not 
able to use eclipse-platform-runtime and gives the error:

org.eclipse.e4.core.services [83]
Unresolved requirement: Import-Package: javax.annotation; 
version="1.3.5"
  
org.eclipse.e4.core.di [81]
Unresolved requirement: Require-Bundle: javax.annotation; 
bundle-version="[1.3.5,2.0.0)"

org.eclipse.e4.core.services [83]
Unresolved requirement: Import-Package: javax.annotation; 
version="1.3.5"


-- 
Regards
Sudip

Bug#1015833: sbuild: would be helpful to be able to override the autopkgtest options

[Julian Gilbey]

On Sun, Sep 18, 2022 at 08:27:53PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi,
> 
> Quoting Julian Gilbey (2022-09-18 18:54:10)
> > On Wed, Sep 14, 2022 at 08:13:08AM +0200, Johannes Schauer Marin Rodrigues
> > wrote:
> > > Hi,
> > > > [...]
> > > > The same applies for all of the autopkgtest related options, such as
> > > > --autopkgtest-virt-server-opt.
> > > 
> > > which options are different if you are building for a stable update?
> > 
> > I have in my .sbuildrc:
> > 
> > $autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 
> > 'autopkgtest-testing'];
> > [...]
> 
> did you try putting the following into your ~/.sbuildrc:
> 
> $autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 'autopkgtest-%r'];

That's a good point; I hadn't spotted that substitution variable.

> > But in general, the idea that it is impossible to override settings from a
> > configuration file seems an unfortunate design choice.
> 
> That is correct. But letting sbuild run autopkgtest is also a bad design
> choice. Since the $autopkgtest_opts are a list of options, it would also be 
> bad
> to let the command line options just replace what was already set. So then you
> need some sort of interface that lets you add or remove arbitrary stuff. This
> can become very complicated very fast. We can also not change this now because
> sbuild is also heavily used from scripts that now rely on the existing
> functionality.

Another good point (about the bad design).  I wasn't suggesting
changing the existing behaviour for exactly the reason you indicate,
rather I was suggesting a new option to mean "clear all existing
$autopkgtest_opts and start with an empty list".  But that also feels
a bit clunky.

> [...]
> If you want to do more complex stuff, consider using the SBUILD_CONFIG
> environment variable.

That would work too.

Best wishes,

   Julian

Bug#1020276: linux-image-5.19.0-1-amd64: NFC device not detected

[Diederik de Haas]

On maandag 19 september 2022 15:55:13 CEST Diederik de Haas wrote:
> What is needed is finding out which NFC chip(s/set) is being used in your
> device. Assuming it is supported on Linux, it could be as simple as enabling
> a kernel config option.

Right after sending that I found https://wiki.archlinux.org/title/
Lenovo_ThinkPad_X1_Yoga_(Gen_4)#NFC which points to 
https://github.com/nfc-tools/libnfc/issues/455 and from that it seems highly 
likely that the chip that is used is a NXP NCP300 and is likely/probably using 
an I2C interface.

In drivers/nfc/nxp-nci/Kconfig there are 2 options:
- NFC_NXP_NCI which mentions NPC300 explicitly
- NFC_NXP_NCI_I2C which is needed when an I2C interface is used.

If you know how to build a Debian kernel, you can add those 2 options and 
verify whether that indeed makes your NFC device available (and working).

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

Bug#1020276: linux-image-5.19.0-1-amd64: NFC device not detected

[Diederik de Haas]

On maandag 19 september 2022 09:46:41 CEST Oliver Sander wrote:
> I have a ThinkPad X1 Yoga (4th gen).  It has an NFC device built in.
> The NFC device appears in the BIOS, and it is enabled there.
> However, I cannot see it from Debian at all.  Neither lsusb nor
> lspci show anything ressembling an NFC device.  I would gladly help
> to debug this, but I don't know what to do in such a situation.

What is needed is finding out which NFC chip(s/set) is being used in your 
device. Assuming it is supported on Linux, it could be as simple as enabling a 
kernel config option.

I'm guessing the device came initially with Windows and if you still have 
that, it could be that it can tell you which NFC hardware is being used.
Another option is asking Lenovo directly.

You could also try "modprobe nfc" and see whether dmesg (f.e.) outputs 
something which would give a clue as to the NFC hardware.

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

Bug#1020297: reportbug: replace "upstream author" with "upstream contact" in RFS template

[Mattia Rizzolo]

Package: reportbug
Version: 11.5.1
Severity: wishlist

Hi,

in https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/148
we have been made aware that "Upstream Author" is kind of a tricky thing
to ask, as the original author of a program can be somewhat hard to
pick.

Also, what in fact people are interested about, is who is the current
upstream.  In this regard, we believe that the wording "Upstream
Contact" make that much more sense, the same way this datapoint is
called in d/copyright.

In mentors.d.n we are updating our template to do the same change.


Cheers! o/

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1020296: RFS: popt/1.19-1~exp1 [ITA] -- lib for parsing cmdline parameters

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: popt
   Version : 1.19-1~exp1
   Upstream Author : rpm-ma...@lists.rpm.org
 * URL : https://github.com/rpm-software-management/popt
 * License : expat
 * Vcs : https://salsa.debian.org/debian/popt
   Section : devel

The source builds the following binary packages:

  libpopt0 - lib for parsing cmdline parameters
  libpopt-dev - lib for parsing cmdline parameters - development files
  libpopt0-udeb - lib for parsing cmdline parameters

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/popt/popt_1.19-1~exp1.dsc

Changes since the last upload:

 popt (1.19-1~exp1) experimental; urgency=medium
 .
   * New upstream release.
 - Fixes memory leak. Closes: #941814
   * Drop all patches, included upstream.
   * Adopt package. Closes: #995268
   * d/copyright:
 - Add myself under Debian paragraph.
 - Upstream changed license to MIT/expat.
   * Update Standards-Version to 4.6.1
   * Remove no longer needed package conflicts.
   * wrap-and-sort -at


It would be nice if I could have access to the repo in salsa as well.

Regards,
Håvard

Bug#1020287: vcmi: new vcmi provides files conflicting with existing game-data-packager recipe

[Johannes Schauer Marin Rodrigues]

Control: forwarded -1 https://github.com/vcmi/vcmi/issues/951

Hi,

Quoting Alexandre Detiste (2022-09-19 12:57:29)
> The new vcmi tries to overwrite files previously provided by G-D-P generated
> homm3-en-data local package.  Which should be fixed ?
> 
> Is this VCMI_Tests_2011b.h3m file even free ?
> (then it would remain in G-D-P recipe)

I need some input from upstream on this matter. I forwarded the bug
accordingly.

> There might be other duplicated files.

can you send the output of `dpkg-deb -c` or similar so that we can check if
there are possibly other conflicts?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#568230: bugs.debian.org: "forwarded" tags should gracefully ignore line breaks

[fabian]

On Wed, 3 Feb 2010 11:09:22 -0800 Don Armstrong wrote:

On Wed, 03 Feb 2010, Fabian Greffrath wrote:

> The reason is that my mail client breaks lines if they are longer
> than 70 characters.

If your mail client is unable to send messages with long lines, your
mail client is fundamentally broken.

If you don't want to fix your MUA, use the bts command line tools
instead.


Could this sentiment probably get reconsidered?

I filed this bug more than 12 years ago, and just today I got bitten by 
this again when I sent a mail to the Debian BTS containing a "forwarded" 
control command. I have sent this from a Windows PC using the roundcube 
webmail client, which apparently also insists to add line breaks to keep 
a certain line length in text-only mails. So, this time I had no chance 
to use the "bts" command lne tool, and I find it anachronistic to refer 
people to use such tools in times when e-mails are sent via webmailers 
or mobile phones.


Thanks,

 - Fabian

Bug#1020295: ITP: dh-puredata -- debhelper addon for building Pd externals

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dh-puredata
  Version : 1
  Upstream Author : IOhannes m zmölnig 
* URL : * https://salsa.debian.org/multimedia-team/pd/dh-puredata
* License : GPL3+
  Programming Lang: Perl
  Description : debhelper addon for building Pd externals

This package provides the 'pd-lib-builder' Debhelper-sequence for
streamlining the process of creating Debian packages of pd-lib-builder
based externals for the Pure Data computer music language.


I intend to maintain this under the multimedia-team umbrella, along with
the other Pure Data related packages.

Bug#1020290: Your behavior on Debian lists

[Ansgar]

Hi Craig,

I think your behavior on Debian lists is not acceptable. This isn't the
first time either.

You are free to leave the project (and Debian lists) if you want to
behave like that.

Ansgar

On Mon, 2022-09-19 at 22:53 +1000, Craig Sanders wrote:
> That's a particularly specious and disingenuous statement.
[...]
> Perhaps you haven't planned this insane, unwanted transition as well as you
> thought you had?  Maybe you should step back and think again before you
> arbitrarily break other people's systems for pointless cosmetic reasons?
[...]
> Why?  I mean, apart from worshipping the sun shining out of Saint Poettering's
> arse, why? What actual, practical, non-theological benefit is there?
> 
> It was a mistake for debian to stop supporting a separate /usr, and this only
> cements that mistake by making it impossible to ever revert and impossible
> even for local system admins to DIY.