Bug#1005234: libreoffice: prepare for poppler 22.02 transition

[Rene Engelhard]

Am 10.02.22 um 07:42 schrieb Rene Engelhard:

Am 09.02.22 um 19:42 schrieb Jeremy Bicha:

Source: libreoffice
Version: 1:7.3.0-1
Severity: important


erm, no. There's no bug at all since it doesn't build.


Fpr avoidance of aoubt: I of course meant something along
"since there is no sign/evidence it doesn't build".

(As was confirmed later.)

Regards,

Rene

Bug#1002541: libio-async-perl: autopkgtest regression on ppc64el: Parse errors: No plan found in TAP output

[Niko Tyni]

(Paul: this is just FYI for now; tested patches will follow eventually
 in a proper bug report.
 See https://bugs.debian.org/1002541 for more context.)

On Fri, Jan 21, 2022 at 06:12:51PM +0100, gregor herrmann wrote:

> > So t/70future-io.t fails consistently since it is run (0.800-2 and
> > 0.801-1). But only on ppc64el.
> 
> And libfuture-io-perl has the same problem: The tests fail on
> ppc64el:

Both of these issues are a test-only wrong expectation on stdio buffer
sizes, which seem to differ on the ppc64el architecture.

The attached test program (pardon my C) makes a pair of nonblocking
pipes, writes to one end until it's full and then reads from the other
end until writes don't block anymore.

The output (see below) indicates that on my amd64 host it takes 64kB
to fill the pipe, and reading 4kB out is enough to unblock it. This
(particularly the 4kB part) is what the tests in libio-async-perl and
libfuture-io-perl are expecting.

However, on ppc64el it takes 1MB to fill the pipe, and 64kB to unblock it.
The tests fail because they only read 4kB out and expect writes to
work again.

Patches need to go around

 
https://sources.debian.org/src/libfuture-io-perl/0.11-1/lib/Test/Future/IO/Impl.pm/#L302

 https://sources.debian.org/src/libio-async-perl/0.801-1/t/70future-io.t/#L59

but I don't have anything finished atm and I'm out of time for now.

Note that the test in libio-async-perl also uses the one in 
Test::Future::IO::Impl,
so both fixes are needed to make libio-async-perl pass.

amd64:
   PIPE_BUF: 4096
   making nonblocking pipes
   writing until it blocks
   wrote 16 * 4096 bytes
   reading out until write no longer blocks
   read 1 * 4096 bytes
   
ppc64el (plummer.debian.org):
   PIPE_BUF: 4096
   making nonblocking pipes
   writing until it blocks
   wrote 256 * 4096 bytes
   reading out until write no longer blocks
   read 16 * 4096 bytes

-- 
Niko Tyni   nt...@debian.org
#include 
#include 
#include 
#include 
#include 
#include 

int main(void) {
	int fds[2];
	int i;
	char r_buf[PIPE_BUF];
	char w_buf[PIPE_BUF];

	memset(w_buf, 'X', PIPE_BUF);
	printf("PIPE_BUF: %d\n", PIPE_BUF);
	printf("making nonblocking pipes\n");
	if (pipe(fds)) {
		perror("pipe");
	}
	if (fcntl(fds[0], F_SETFL, O_NONBLOCK))
		perror("fcntl for read handle");
	if (fcntl(fds[1], F_SETFL, O_NONBLOCK))
		perror("fcntl for write handle");
	printf("writing until it blocks\n");
	i = 0;
	while (write(fds[1], w_buf, PIPE_BUF) > 0) {
		i++;
	}
	if (errno != EAGAIN)
		perror("unexpected write error");
	printf("wrote %d * %d bytes\n", i, PIPE_BUF);

	printf("reading out until write no longer blocks\n");
	i = 0;
	while (write(fds[1], w_buf, PIPE_BUF) < 0) {
		read(fds[0], r_buf, PIPE_BUF);
		i++;
	}
	printf("read %d * %d bytes\n", i, PIPE_BUF);
}

Bug#1005313: telegram-desktop: DRM in channels, preventing to download medias

[Alexandre Garreau]

The 2022-02-11, 05:54:46 CET Alexandre François Garreau wrote:
> In the last release of telegram, support were added for a new kind of
> channels (they were unjoinable before) that implements DRM, by
> preventing from transfering, copying or downloading material on them.
> 
> Look at this example: https://t.me/THE_QUEENS_GAMBIT_SY/39
> 
> When opening videos there, there is no download button, and the message
> cannot be transferred.

> What I expect is the ability to get those medias outside of telegram

I think I found the relevant commit to revert, see attached.

I have yet to try after having reverted and compiled with it.commit 3623fb1f9ab6213db8b7d73eb8eb2185015e750d
Author: John Preston 
Date:   Thu Dec 30 14:58:34 2021 +0300

Disable saveAs in media viewer if restricted.

diff --git a/Telegram/SourceFiles/media/view/media_view_overlay_widget.cpp b/Telegram/SourceFiles/media/view/media_view_overlay_widget.cpp
index 21fb4d690..a63f49839 100644
--- a/Telegram/SourceFiles/media/view/media_view_overlay_widget.cpp
+++ b/Telegram/SourceFiles/media/view/media_view_overlay_widget.cpp
@@ -1515,6 +1515,9 @@ void OverlayWidget::notifyFileDialogShown(bool shown) {
 }
 
 void OverlayWidget::saveAs() {
+	if (showCopyRestriction()) {
+		return;
+	}
 	QString file;
 	if (_document) {
 		const auto &location = _document->location(true);

Bug#1005317: git-buildpackage: Make it easier to support an extra packaging branch (for derivatives)

[Arnaud Rebillout]

Package: git-buildpackage
Version: 0.9.25
Severity: normal
User: de...@kali.org
Usertags: origin-kali

  Dear Maintainer, dear Guido,

At Kali Linux we use gbp to maintain our packages. We have around 500
packages total, among which 40 are forked from Debian. Kali Linux being
a rolling distribution, those 40 packages are kept in sync with their
counterpart in Debian testing, meaning that we update them often.

We use the same workflow for pretty much all of our packages: 3 git
branches (packaging, upstream and pristine-tar), and no upstream git
history. We use "gbp import-orig" for all the Kali specific packages,
and "gbp import-dsc" for all the Debian forks.

All in all, gbp works great for us, but nothing is never perfect :)


THE PROBLEM

For our Debian forks, we actually have 4 branches (or 2 when it's a
native package): we have the packaging branch (named "kali/master"), the
usual upstream and pristine-tar branches, but we also have the "upstream
distro" branch (named "debian") that contains the unmodified source from
Debian, as imported by "gbp import-dsc".

Just to clarify, let me describe how we maintain such a 4-branches git
repo:

* Step 1.  $ gbp import-dsc --debian-branch=debian
  -> ie. update the 3 branches upstream, pristine-tar and debian.

* Step 2.  $ git merge debian
  -> ie. merge the debian branch into the kali/master branch. This is
 when we resolve our merge conflicts, since the Kali changes live
 on the kali/master branch.

(Note: this workflow was mentioned in https://bugs.debian.org/670612)

This workflow works very well, and keeping our Debian forks in sync with
Debian is fairly straightforward.

Our issue is that the 4th branch (the "debian" branch) lives out of the
realm of gbp. Therefore it's ignored by the gbp commands that deal with
git branches, and we always need additional steps to handle this branch.
In particular:

* gbp clone: Won't setup this branch, one has to do it manually:

gbp clone
cd 
git branch debian origin/debian

* gbp pull: Won't pull it, one has to do it manually:

gbp pull
git checkout debian
git merge
git checkout -

  (or: pull all branches)

gbp pull --all

* gbp push: Won't push it, one has to do it manually:

gbp push
git checkout debian
git push
git checkout -

  (or: push with git)

git push origin : --follow-tags

  (or: if the --tips option in #908204 was implemented, we could do:)

gbp push --tips

These additional steps are trivial, but they are also easy to forget.
One thing that keeps biting me is that I often forget to pull the
"debian" branch. So I work on the package, update it, make it ready for
upload, and at the last moment, when I want to push all the git
branches, git refuses, because I worked with an outdated branch and my
modifications are not fast-forwardable. So I have to restart from zero,
or force push, or whatever.


THE TENTATIVE IMPROVEMENTS

So I've been thinking hard about ways to prevent that to happen, and
more generally, about how I could get gbp to clone/pull/push this 4th
branch automatically, so that there's no need for additional steps.

Here are some ideas, starting with the worst one:

  1) the "upstream distro" concept

An ambitious and complicated way could be to teach gbp about the concept
of an "upstream distro" (meaningful only for Debian derivatives), and
define in the gbp.conf what is the "upstream-distro-branch", the
"upstream-distro-tag", and more if needed. And then let gbp do the right
thing (TM). In other words, hammer a new concept into gbp.

IMO: way too complicated.

  2) the "extra branche(s)" idea

Instead, a lighter approach could be to teach gbp about "extra
branches", without defining what those branches are for. "gbp clone"
would setup those branches, and "gbp pull" would pull it. That's super
easy to implement. The complicated part is that "gbp push", as far as I
can see, would not know what to do with this branch, due to the way it
works. And therefore it wouldn't push it. Unless the option "--tips"
mentioned in #908204 is implemented, and in such case we could document
that gbp will push the extra branches only when --tips is enabled.

It's not super elegant (and maybe not super useful) to introduce an
option for extra branches, and then say that it's only supported by
clone and pull, but not supported by push. So I'm not super convinced
myself...

  3) more hooks

I've noticed that some gbp actions have a "--postxxx" argument, to allow
users to run hooks. That could help!

There's already a "--postclone" option. I can add this snippet in
debian/gbp.conf, and it works:

[clone]
postclone = git branch debian origin/debian

If I had a "--postpull" option, I could make sure that the "debian"
branch is automatically pulled. This is something I'd configure in the
debian/gbp.conf for all of Kali's Debian forks.

Same with a "--postpush" option.

And while we're at it, a "--postimport" for the "gbp import-dsc" command

Bug#1004710: Please pass "-r" to useradd when needed

[Johannes Schauer Marin Rodrigues]

Hi Jason,

Quoting Jason Franklin (2022-02-11 03:14:23)
> I have been helping Marc Haber with some of the issues in adduser, so I
> suppose it is appropriate for me to chime in here.
> 
> Thanks so much for the report and for the investigative work so far!
> 
> Here are my thoughts...
> 
> The "good" chroot has version 1:4.8.1-2 of passwd, and the "bad" chroot
> has version 1:4.11.1+dfsg1-1 of passwd. The changes between these two
> versions were substantial.
> 
> > Quoting Bálint Réczey (2022-02-10 22:46:50)
> > > Apparently useradd correctly guessed system user ranges in the past,
> > > but this is not something to rely on.
> 
> I do not think "useradd" ever attempted to guess whether a UID being
> added was in the system user range. Instead, it looks like hardcoded
> settings in the source code changed between the two versions above. To
> see this, you may reference the upstream shadow repository...
> 
> Commit: 
> https://github.com/shadow-maint/shadow/commit/bbf4b79bc49fd1826eb41f6629669ef0b647267b
> 
> The key part of that change was this:
> 
> - static const char *def_create_mail_spool = "no";
> + static const char *def_create_mail_spool = "yes";
> 
> The "adduser" command never set the "-r" option previously, but the
> default in the upstream source was to not create the mail spool
> directories.  Thus, this problem never surfaced.
> 
> > the recent upload of shadow 1:4.11.1+dfsg1-1 made above patch necessary as
> > otherwise useradd will create empty directories in /var/mail and
> > /var/spool/mail for the system users _apt, systemd-network and 
> > systemd-resolve.
> > This in turn breaks the testsuite of my package mmdebstrap.
> 
> I think setting the "-r" option is the right approach, but we need to
> make sure that the new option doesn't do anything else that we do not
> expect for it to do. I can see that it does more than just omit creating
> the mail spool by default.
> 
> The "passwd" package could be patched temporarily to undo the change
> from "no" to "yes" above. That would put us back at the old behavior for
> the time being. This patch could be removed in the not-to-far future, as
> I am committed to helping with supporting adduser and with fixing bugs
> new and old, including this one. :)
> 
> Looking forward to hearing what Marc and others think on this one.

thank you for chiming in and putting more details on the table!

The change you found indeed seems like the creation of the spool directories is
intentional.

I can also see how setting the -r option might have unintended side-effects.

But the information you found already helps me to work around this problem from
the side of my package mmdebstrap. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Mihai Moldovan]

* On 2/2/22 6:05 PM, Enrico Zini wrote:
> I'm trying to use dnf to bootstrap rpm-based chroots, which seems to
> work, but the rpm package database on the resulting distribution is
> empty, as in, `rpm -qa` returns no output, and `rpm -q` on any package
> complains that it is not installed. The actual files that are supposed
> to be in the package are indeed present in the chroot.

This is, AFAIR, an issue caused by Debian's patching of the RPM tools (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794495 )

While Debian's rpm utility uses a homedir-based RPMDB, nothing else, especially
not Fedora, expects that and, since dnf uses the system-version of RPM to
bootstrap, you'll run into exactly such issues.

I can't do anything about that, other than try to NMU a version of RPM that has
this patch removed, but that might break tools like alien and I'm not very
interested in spending a lot of time on that.

Another issue is that I'm still using my rather old dnf/mock packages on Debian
Stretch and have never upgraded to anything newer yet.

I've had to specifically patch dnf to support this weird 'rpmdb-in-homedir'
construct, but packages installed as part of the bootstrapping procedure will
NEVER be seen by the bootstrapped system, since their RPM version uses the
usual, global RPMDB path of /var/lib/rpm.


Sorry to shift the blame in such a fashion.



Mihai



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

Johannes:

I took a bit of time to look at this further.

I think that adding "-r" to the useradd call found in adduser will not
break anything. It's the best way to go ahead and fix this, and it is
the most forward-looking solution.

To Marc: I would like to implement this with a proper autopkgtest in
adduser that proves that "/var/mail/foo" is not created by default when
system user "foo" is added. This will integrate nicely with the other
work I'm doing.

I could branch off of the 3.118 tag in the Debian/adduser repository and
submit a PR with the fix to master. Then, the new package with this fix
could be built off of the feature branch before the merge (the hotfix
branch). We can then merge with master (resolving conflicts) to
integrate with the changes we don't want to release yet.

Does this all sound reasonable?

-- 
Jason Franklin

Bug#1004111: unattended-upgrades: regression: packages with conffile prompts are no longer skipped, leading to upgrade failures

[Paul Wise]

Control: close 1004111

On Thu, 2022-02-10 at 11:38 -0600, Judah Richardson wrote:

> Yeah I haven't had any error messages for a couple weeks now so
> apparently whatever the issue is has been cleared up.

OK, closing the bug with this mail.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001261: Another fix requested: v1.54.1

[Matthew Darwin]

It would also be great to have this fix: 
https://forum.rclone.org/t/rclone-lsjson-invalid-json-produced-no-at-the-end/22046

Bug#817042: Adapter Manufacturer,

[top top]

Hello,
How are u!
We are a manufacturer of ADAPTER from China, if you need to buy it,
And inform us of the item/s and quantities required, including your details and 
we will be more then willing to quote you.

We look forward to a wonderful relationship together and success for all 
concerned.
Best regards,
Andy

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

Greetings:

I have been helping Marc Haber with some of the issues in adduser, so I
suppose it is appropriate for me to chime in here.

Thanks so much for the report and for the investigative work so far!

Here are my thoughts...

The "good" chroot has version 1:4.8.1-2 of passwd, and the "bad" chroot
has version 1:4.11.1+dfsg1-1 of passwd. The changes between these two
versions were substantial.

> Quoting Bálint Réczey (2022-02-10 22:46:50)
> > Apparently useradd correctly guessed system user ranges in the past,
> > but this is not something to rely on.

I do not think "useradd" ever attempted to guess whether a UID being
added was in the system user range. Instead, it looks like hardcoded
settings in the source code changed between the two versions above. To
see this, you may reference the upstream shadow repository...

Commit: 
https://github.com/shadow-maint/shadow/commit/bbf4b79bc49fd1826eb41f6629669ef0b647267b

The key part of that change was this:

- static const char *def_create_mail_spool = "no";
+ static const char *def_create_mail_spool = "yes";

The "adduser" command never set the "-r" option previously, but the
default in the upstream source was to not create the mail spool
directories.  Thus, this problem never surfaced.

> the recent upload of shadow 1:4.11.1+dfsg1-1 made above patch necessary as
> otherwise useradd will create empty directories in /var/mail and
> /var/spool/mail for the system users _apt, systemd-network and 
> systemd-resolve.
> This in turn breaks the testsuite of my package mmdebstrap.

I think setting the "-r" option is the right approach, but we need to
make sure that the new option doesn't do anything else that we do not
expect for it to do. I can see that it does more than just omit creating
the mail spool by default.

The "passwd" package could be patched temporarily to undo the change
from "no" to "yes" above. That would put us back at the old behavior for
the time being. This patch could be removed in the not-to-far future, as
I am committed to helping with supporting adduser and with fixing bugs
new and old, including this one. :)

Looking forward to hearing what Marc and others think on this one.

Thanks!

-- Jason Franklin

Bug#1005310: RFS: ukui-notebook/3.1.1-1 [ITP] -- Notebook for UKUI desktop environment

[handsome_feng]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: jianfen...@ubuntukylin.com

Dear mentors,

I am looking for a sponsor for my package "ukui-notebook":

 * Package name: ukui-notebook
   Version : 3.1.1-1
   Upstream Author : li...@kylinos.cn
 * URL : https://github.com/ukui/
 * License : GPL-3+
 * Vcs : https://github.com/ukui/ukui-notebook
   Section : x11

It builds those binary packages:

  ukui-notebook - Notebook for UKUI desktop environment

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

  https://mentors.debian.net/package/ukui-notebook/

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

  dget -x https://mentors.debian.net/debian/pool/main/u/ukui-notebook/ukui-
notebook_3.1.1-1.dsc

Changes for the initial release:

 ukui-notebook (3.1.1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: 1005182)

Regards,
handsome_feng

Bug#1002508: readline: Please provide a udeb

[Samuel Thibault]

Hello,

Is there any news on this?  Perhaps I can just NMU?

Samuel

Samuel Thibault, le sam. 08 janv. 2022 18:21:28 +0100, a ecrit:
> Hello,
> 
> I see that a newer upload of readline was done but without the proposed
> patch. Is there any problem with it? (attached here again)
> 
> Having readline available would really make the installer a *lot* easier
> to handle for blind users.
> 
> Samuel
> 
> Samuel Thibault, le jeu. 23 déc. 2021 15:31:17 +0100, a ecrit:
> > So as to provide better support for the text installer for speakup-based
> > accessibility, we need libreadline in d-i. Here is a patch to add the
> > udeb build, could you apply it?
> > 
> > Thanks,
> > Samuel

> --- debian/control.original   2021-12-23 14:14:29.494489058 +0100
> +++ debian/control2021-12-23 15:03:01.596025090 +0100
> @@ -23,6 +23,21 @@
>   The GNU history library provides a consistent user interface for
>   recalling lines of previously typed input.
>  
> +Package: libreadline8-udeb
> +Architecture: any
> +Depends: readline-common-udeb, ${shlibs:Depends}, ${misc:Depends}
> +Pre-Depends: ${misc:Pre-Depends}
> +Package-Type: udeb
> +Build-Profiles: 
> +Section: debian-installer
> +Description: GNU readline and history libraries, run-time libraries (d-i)
> + The GNU readline library aids in the consistency of user interface
> + across discrete programs that need to provide a command line
> + interface.
> + .
> + The GNU history library provides a consistent user interface for
> + recalling lines of previously typed input.
> +
>  Package: lib64readline8
>  Architecture: i386 powerpc s390 sparc
>  Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
> @@ -47,6 +62,21 @@
>   The GNU readline library aids in the consistency of user interface
>   across discrete programs that need to provide a command line
>   interface.
> + .
> + The GNU history library provides a consistent user interface for
> + recalling lines of previously typed input.
> +
> +Package: readline-common-udeb
> +Architecture: all
> +Multi-Arch: foreign
> +Depends: ${misc:Depends}
> +Package-Type: udeb
> +Build-Profiles: 
> +Section: debian-installer
> +Description: GNU readline and history libraries, common files (d-i)
> + The GNU readline library aids in the consistency of user interface
> + across discrete programs that need to provide a command line
> + interface.
>   .
>   The GNU history library provides a consistent user interface for
>   recalling lines of previously typed input.
> --- debian/rules.original 2021-12-23 14:14:33.018490312 +0100
> +++ debian/rules  2021-12-23 15:08:20.460279596 +0100
> @@ -17,6 +17,10 @@
>  CROSS=gcc
>  endif
>  
> +ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
> +  buildudeb = yes
> +endif
> +
>  ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/i386/powerpc/sparc/s390/))
>build64 = yes
>CC64 = $(CROSS) -m64
> @@ -69,9 +73,11 @@
>  SHELL= bash
>  
>  p_rl = libreadline$(soversion)
> +p_rlu= libreadline$(soversion)-udeb
>  p_rl32   = lib32readline$(soversion)
>  p_rl64   = lib64readline$(soversion)
>  p_comm   = readline-common
> +p_commu  = readline-common-udeb
>  p_rld= libreadline-dev
>  p_rld32  = lib32readline-dev
>  p_rld64  = lib64readline-dev
> @@ -79,12 +85,15 @@
>  p_rlfe   = rlfe
>  
>  d= debian/tmp
> +du   = debian/tmp-udeb
>  d32  = debian/tmp32
>  d64  = debian/tmp64
>  d_rl = debian/$(p_rl)
> +d_rlu= debian/$(p_rlu)
>  d_rl32   = debian/$(p_rl32)
>  d_rl64   = debian/$(p_rl64)
>  d_comm   = debian/$(p_comm)
> +d_commu  = debian/$(p_commu)
>  d_rld= debian/$(p_rld)
>  d_rld32  = debian/$(p_rld32)
>  d_rld64  = debian/$(p_rld64)
> @@ -93,6 +102,7 @@
>  
>  srcdir   = $(CURDIR)
>  builddir = $(CURDIR)/build
> +builddiru= $(CURDIR)/buildudeb
>  builddir32   = $(CURDIR)/build32
>  builddir64   = $(CURDIR)/build64
>  
> @@ -111,6 +121,16 @@
>   --host=$(DEB_HOST_GNU_TYPE) \
>   --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
>  
> +ifneq ($(buildudeb),)
> + rm -rf $(builddiru)
> + mkdir $(builddiru)
> + cd $(builddiru) && \
> +   CFLAGS="$(CFLAGS) -Os" CPPFLAGS="$(CPPFLAGS)" $(srcdir)/configure \
> + --prefix=/usr\
> + --host=$(DEB_HOST_GNU_TYPE) \
> + --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
> +endif
> +
>  ifneq ($(build32),)
>   rm -rf $(builddir32)
>   mkdir $(builddir32)
> @@ -141,6 +161,14 @@
>   SHOBJ_LDFLAGS='$(LDFLAGS) -shared' \
>   SHLIB_LIBS="-ltinfo"
>  
> +ifneq ($(buildudeb),)
> + $(MAKE) -C $(builddiru) \
> + CFLAGS="$(CFLAGS) -Os" CPPFLAGS="$(CPPFLAGS)" \
> + SHOBJ_CFLAGS="-fPIC -D_REENTRANT" \
> + SHOBJ_LDFLAGS='$(LDFLAGS) -shared' \
> + SHLIB_LIBS="-ltinfo"
> +endif
> +
>  ifneq ($(build32),)
>   $(MAKE) -C $(builddir32) \
>   CC="$(CC32)" \
> @@ -277,6 +305,34 @@
>   cp -p debian/rlfe.1 $(d_rlfe)/usr/share/man/man1/.
>  endif

Bug#1005197: pcmemtest: please make the build partly reproducible

[Chris Lamb]

Hi Thomas,

>> Have you had a look at the diffoscope output after this patch is
>> applied?
>
> Where can a curious bystander get that look ?

I was referring to a hypothetical diff that you might generate
locally; updating the result on tests.reproducible-builds.org would
require a new upload. :)

> i see in the isoinfo output only differences of user id, group id,
> and timestamps of /boot and /boot/floppy.img.
[...]
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1005197;filename=pcmemtest.diff.txt;msg=5
> should fix both.

It perhaps should, but alas it does not. When I apply my patch, the
user ID, group ID and timestamp differences do disappear for me too,
but that is not the only difference I see. I mean, hence why I said
that my patch "does not make the ISOs entirely reproducible; there is
another part or parts of the image that elude me right now". :)

I wouldn't jump to the conclusion that it is a bug in xorriso just
yet. It might be reproducible for you locally, but it is likely I am
varying more things between my two builds. And even more on
tests.reproducible-builds.org.

The next step might be to upload with this patch so we can both work
with the same output on tests.reproducible-builds.org.

>   --set_all_file_dates "=$SOURCE_DATE_EPOCH"

Ah, neat. :)  Yes, of course, feel free to use this over touch(1).


Regards,

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

Bug#692765: Weird table rendering in translated page

[David Prévot]

Hi,

Le 30/01/2022 à 12:14, Colin Watson a écrit :

On Thu, Nov 08, 2012 at 12:37:39PM -0400, David Prévot wrote:

The last table (decimal) rendering of ascii(7) is weird

[…]

Only nine years later, I finally got round to investigating this.


Thanks a lot Colin, I came across this issue recently and it looked like 
déjà-vu ;). Thanks also for the detailed explanations and proposed fixes!


Regards

David

Bug#1004710: Please pass "-r" to useradd when needed

[Johannes Schauer Marin Rodrigues]

Hi Marc,

Quoting Bálint Réczey (2022-02-10 22:46:50)
> Sorry for the delay, I tried bumping the severity to buy myself some time.
> 
> It seems this is an adduser bug and the following patch fixes it:
> --- adduser.orig2018-09-15 21:12:39.0 +0200
> +++ adduser2022-02-10 22:27:05.759922091 +0100
> @@ -434,7 +434,7 @@
>  $shell = $special_shell || '/usr/sbin/nologin';
>  $undouser = $new_name;
>  my $useradd = &which('useradd');
> -&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
> +&systemcall($useradd, '-r', '-d', $home_dir, '-g', $ingroup_name, '-s',
>  $shell, '-u', $new_uid, $new_name);
>  if(!$disabled_login) {
>  my $usermod = &which('usermod');
> 
> Apparently useradd correctly guessed system user ranges in the past,
> but this is not something to rely on.

the recent upload of shadow 1:4.11.1+dfsg1-1 made above patch necessary as
otherwise useradd will create empty directories in /var/mail and
/var/spool/mail for the system users _apt, systemd-network and systemd-resolve.
This in turn breaks the testsuite of my package mmdebstrap.

Are you available to upload another version of adduser in the next few days?

Otherwise, I can also NMU it if you want because this is breaking one of my
packages.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#985661: libboostM.mm-dev no .pc file

[Valerio Messina]

as now I had the package "libboost1.67-dev" installed, I'm on Debian 10.

I checked in package installed files, no .pc is there.

I also checked all other libboost1.xx-dev packages (are 1.71 and 1.74),
no one has a .pc files.

Does the libboostM.mm-dev package supplied with Debian 11, 12 or Sid has 
a .pc file?


Or you are saying the libboost was completely removed from Debian repo?

thank you
--
Valerio

Bug#1005283: ITP:php-maximebf-debugbar - debug bar in the browser with information from php

[Andreas Beckmann]

Control: reassign -1 wnpp

Dear Katharina,

please make sure your ITP bugs are assigned to the 'wnpp' pseudopackage 
(work needed and prospective packages) and not the intended source 
package name.


https://www.debian.org/devel/wnpp/

On Thu, 10 Feb 2022 14:20:32 +0100 Katharina Drexel 
 wrote:

Package: php-maximebf-debugbar

^^^ this should have been Package: wnpp


* Package name: php-maximebf-debugbar

...

Andreas

Bug#481468: memtest86+: Should not run update-grub unconditionally in postinst

[Fabio Fantoni]

Il 10/02/2022 21:35, Olaf Buddenhagen ha scritto:

Hi,

On Tue, Feb 08, 2022 at 01:39:58PM +0100, Fabio Fantoni wrote:


Hi, /etc/kernel-img.conf seems specific options related to kernel so I don't
think is good do some additional condition based on it, I don't know other
similar option that can be used out of this.

Well, first of all, I'm using update-grub nowadays -- so I don't
personally care any more... To be honest, I didn't even remember filing
this issue back then :-)

Fundamentally, memtest behaves largely like a kernel image for most
intents and purposes -- so using options from /etc/kernel-img.conf would
make sense in principle... However, the options in question for
disabling update-grub etc. seem to have been dropped altogether: which I
guess is the source of the confusion here -- best I can tell, this bug
is simply obsolete at this point...

-antrik-


Thanks for your reply, I recently become the new maintainer and am 
reviewing all open bugs.


This bug report even if is near 14 years old and the proposed 
modification did not seem optimal to me it still seemed good to ask to 
be sure if the problem persisted.


Since the proposed option has been dropped and the problem is no longer 
relevant, I close the bug.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005307: libnbd: CVE-2022-0485

[Salvatore Bonaccorso]

Source: libnbd
Version: 1.10.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.6.1-1

Hi,

The following vulnerability was published for libnbd.

CVE-2022-0485[0]:
| nbdcopy: missing error handling may create corrupted destination
| image

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0485
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0485
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2050324
[2] https://listman.redhat.com/archives/libguestfs/2022-February/msg00104.html

Regards,
Salvatore

Bug#997818: Still present in 0.4.8-2 and other packaging issues

[Diederik de Haas]

On Thursday, 10 February 2022 22:37:51 CET Diederik de Haas wrote:
> That turned out to be an incorrect expectation as the previous purge didn't
> clean up things in /etc/systemd/user/

Turns out there's more that I've now manually removed, namely in 
default.target.wants and sockets.target.wants in /etc/systemd/user:

root@cs03:/etc/systemd/user# ls -lh
total 12K
drwxr-xr-x 2 root root 4.0K Feb 10 21:43 default.target.wants
lrwxrwxrwx 1 root root9 Feb 10 02:12 pipewire-media-session.service -> 
/dev/null
lrwxrwxrwx 1 root root9 Feb 10 21:43 pipewire-pulse.service -> /dev/null
lrwxrwxrwx 1 root root9 Feb 10 21:43 pipewire-pulse.socket -> /dev/null
drwxr-xr-x 2 root root 4.0K Feb 10 02:12 pipewire.service.wants
lrwxrwxrwx 1 root root   52 Jan 27 00:38 pipewire-session-manager.service -> 
/usr/lib/systemd/user/pipewire-media-session.service
drwxr-xr-x 2 root root 4.0K Feb 10 21:43 sockets.target.wants
root@cs03:/etc/systemd/user# rm -rf pipewire*
root@cs03:/etc/systemd/user# ls -lh
total 8.0K
drwxr-xr-x 2 root root 4.0K Feb 10 21:43 default.target.wants
drwxr-xr-x 2 root root 4.0K Feb 10 21:43 sockets.target.wants
root@cs03:/etc/systemd/user# ls -lh default.target.wants/
total 0
lrwxrwxrwx 1 root root 44 Feb 10 21:42 pipewire-pulse.service -> 
/usr/lib/systemd/user/pipewire-pulse.service
root@cs03:/etc/systemd/user# rm -rf default.target.wants/
root@cs03:/etc/systemd/user# ls -lh sockets.target.wants/
total 0
lrwxrwxrwx 1 root root 36 Feb 10 02:17 dirmngr.socket -> 
/usr/lib/systemd/user/dirmngr.socket
lrwxrwxrwx 1 root root 46 Feb 10 02:17 gpg-agent-browser.socket -> 
/usr/lib/systemd/user/gpg-agent-browser.socket
lrwxrwxrwx 1 root root 44 Feb 10 02:17 gpg-agent-extra.socket -> 
/usr/lib/systemd/user/gpg-agent-extra.socket
lrwxrwxrwx 1 root root 38 Feb 10 02:17 gpg-agent.socket -> 
/usr/lib/systemd/user/gpg-agent.socket
lrwxrwxrwx 1 root root 42 Feb 10 02:17 gpg-agent-ssh.socket -> 
/usr/lib/systemd/user/gpg-agent-ssh.socket
lrwxrwxrwx 1 root root 43 Feb 10 21:42 pipewire-pulse.socket -> 
/usr/lib/systemd/user/pipewire-pulse.socket
root@cs03:/etc/systemd/user# rm sockets.target.wants/pipewire-pulse.socket 
root@cs03:/etc/systemd/user#

Hopefully it is now actually back to a clean state ...

Cheers,
  Diederik

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

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Guillem Jover]

Hi!

On Thu, 2022-02-10 at 21:53:59 +0100, Nicolas Boulenguez wrote:
> Package: dpkg-dev
> Followup-For: Bug #872381

> The --in-place sed option ([1]) may simplify scripts/mk/Makefile.am
> much more than the do_make_subst variable provided by
> build-aux/subst.am does. It is for now the only Makefile using
> do_make_subst.

I'm aware of -i, the problem is that this is unfortunately not portable,
see the comment f.ex. in scripts/Makefile.am, should perhaps add a
similar one in the new subst.am. Will also probably fix the few
instances in the test suites.

> If you select this option, I suggest to rename
> scripts/mk/{default,buildtools}.mk to scripts/mk/*.mk.sed or similar
> (for example, .sed.mk in order to keep syntax highlighting).  Distinct
> source and object files would also simplify scripts/mk/Makefile a lot.

Yeah, that would be more convenient, the problem is that these files
need to have specific pathnames during tests, which are different from
the ones at run-time. Those could be set from the environment, but that
would miss the case where the variable is completely missing from the
file. :)

> More generally, I would really appreciate the opinion of a dpkg
> maintainer about the changes suggested in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872381.  Rebasing
> and testing them again and again is an ungrateful work.  Even "these
> changes seem interesting but require a careful review that we cannot
> afford now" would be more motivating than no answer at all.

Right, sorry, I keep seeing the mails, and concoct the replies in my
head, and either then think I've already replied or miss doing that
entirely. :/

The main issue I see is that this trades performance depending on the
mode of operation. Some of these variables are (currently) not
expected to be set by the driver calling debian/rules (in Debian we
still have to support that being any thing :/), but then most of our
tools do go through dpkg-buildpackage. So the various «.mk» cannot
expect these variables to be previously set, but should assume that
the common case is them being executed through dpkg-buildpackage, and
that one setting some of those, which means unconditionally setting
some of them will make the package builds somewhat slower. The other
variables should then not be set if not used, as that would slow down
packages that do not need them.

Ideally, most of this would not be needed at all, because we could
rely on dpkg-buildpackage having exported all of these, which it
already needs to compute in most cases anyway, but this is something
we cannot have in Debian for now. I'm pondering adding a mode, not to
be used by Debian, which could be used by local packages or other
distros though.

In any case, thanks for the work here, and sorry for the repeated
rebasing. I'll go over these in the coming days.

Thanks,
Guillem

Bug#1005306: fuse: failed to exec fusermount3: No such file or directory

[Ludovic Rousseau]

Package: flatpak-builder
Version: 1.2.2-2
Severity: normal

Hello,

I think the package should Depends: on fuse3.

If fuse3 is not installed I get an error when using the Hello World
example:
$ flatpak-builder --force-clean build-dir org.flatpak.Hello.yml
Emptying app dir 'build-dir'
Downloading sources
Starting build of org.flatpak.Hello
Cache miss, checking out last cache hit
fuse: failed to exec fusermount3: No such file or directory

Building module hello in 
/home/rousseau/Documents/flatpak/test1/.flatpak-builder/build/hello-2

Running: install -D hello.sh /app/bin/hello.sh
error: Build directory 
/home/rousseau/Documents/flatpak/test1/.flatpak-builder/rofiles/rofiles-l2iLXI 
not initialized, use flatpak build-init
Error: module hello: Le processus fils s’est terminé avec le code 1


After I installed fuse3 I get no error:
$ flatpak-builder --force-clean build-dir org.flatpak.Hello.yml
Emptying app dir 'build-dir'
Downloading sources
Starting build of org.flatpak.Hello
Cache miss, checking out last cache hit

Building module hello in 
/home/rousseau/Documents/flatpak/test1/.flatpak-builder/build/hello-3

Running: install -D hello.sh /app/bin/hello.sh
Committing stage build-hello to cache
Cleaning up
Committing stage cleanup to cache
Finishing app
Please review the exported files and the metadata
Committing stage finish to cache
Pruning cache



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

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

Versions of packages flatpak-builder depends on:
ii  debugedit   1:5.0-4
ii  flatpak 1.12.4-1
ii  gir1.2-flatpak-1.0  1.12.4-1
ii  libc6   2.33-5
ii  libcurl3-gnutls 7.81.0-1
ii  libelf1 0.186-1
ii  libglib2.0-02.70.3-1
ii  libjson-glib-1.0-0  1.6.6-1
ii  libostree-1-1   2022.1-3+b1
ii  libsoup2.4-12.74.2-3
ii  libxml2 2.9.12+dfsg-5+b1
ii  libyaml-0-2 0.2.2-1
ii  ostree  2022.1-3+b1

Versions of packages flatpak-builder recommends:
ii  binutils  2.37.90.20220207-1
ii  elfutils  0.186-1
ii  git   1:2.34.1-1
ii  patch 2.7.6-7
ii  unzip 6.0-26
ii  xz-utils  5.2.5-2
ii  zstd  1.4.8+dfsg-3

Versions of packages flatpak-builder suggests:
pn  brz 
ii  p7zip-full  16.02+dfsg-8
ii  subversion  1.14.1-3+b2

-- no debconf information

Bug#1004710: [Pkg-shadow-devel] Bug#1004710: passwd: 4.11.1 breaks mmdebstrap testsuite by empty directories in /var/mail and /var/spool/mail

[Bálint Réczey]

Control: reassign -1 adduser 3.118
Control: retitle -1 adduser: Please pass "-r" to useradd when creating
system users
Control: tags -1 patch

Hi Johannes,

Johannes Schauer Marin Rodrigues  ezt írta (időpont:
2022. febr. 10., Cs, 8:39):
>
> Hi Bálint,
>
> Quoting Bálint Réczey (2022-02-02 00:10:00)
> > > Is the creation of these empty directories intended?
> >
> > I'm not sure yet.
> >
> > > Do you have an explanation why they are only created with debootstrap?
> >
> > Not yet, but thank you for the bug report.
>
> thank you for looking into it! Did you already find out something? The
> mmdebstrap autopkgtests have now been broken for 10 days.

Sorry for the delay, I tried bumping the severity to buy myself some time.

It seems this is an adduser bug and the following patch fixes it:
--- adduser.orig2018-09-15 21:12:39.0 +0200
+++ adduser2022-02-10 22:27:05.759922091 +0100
@@ -434,7 +434,7 @@
 $shell = $special_shell || '/usr/sbin/nologin';
 $undouser = $new_name;
 my $useradd = &which('useradd');
-&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
+&systemcall($useradd, '-r', '-d', $home_dir, '-g', $ingroup_name, '-s',
 $shell, '-u', $new_uid, $new_name);
 if(!$disabled_login) {
 my $usermod = &which('usermod');

Apparently useradd correctly guessed system user ranges in the past,
but this is not something to rely on.

Cheers,
Balint

Bug#1001995: libcrypto++: ftbfs on armhf

[Jeffrey Walton]

Hi Everyone,

I think this is a GCC or Debian bug. Here is my reasoning.

Developers are responsible to declare the ISA they are using through
options. In our case, we are using armv4 and armv7, so we let the
compiler know via -march=armv7-a. That's where a developer's
responsibility ends. We are not using fp or neon, so we don't declare
it.

This could be GCC's bug because GCC knows a fp unit is used, and knows
it is hardfloat ABI, but it fails to compile/assemble the source
because we did not specify an option we are not using. If GCC knows
the ABI, then it should use that knowledge. And it makes no sense to
me to declare options we are not using. I'm not getting into that
business.

This could be a Debian bug because the compiler configuration could be
incomplete. Apparently an ABI is specified, but a fp is not. Debian
should supply both or neither. Supplying half of the configuration
seems like a mistake because it is confusing the compiler. For what
it's worth, I sympathize with Debian here. How can you have an
architecture with a hardfloat ABI but not have a fp unit? It makes no
sense to me.

Maybe Debian will have better luck helping the GCC folks to sort out
their twisted logic.

Jeff

Bug#997818: Still present in 0.4.8-2 and other packaging issues

[Diederik de Haas]

Control: found -1 0.4.8-2

First I'll describe what I tried to do and I'll attach the console output (as 
it's rather long), so you can see what exactly I did.

I'm setting up a Rock64 device (arm64) cleanly with pipewire (so no PA which 
my 'soundserver' device was previously running), so I installed that and with 
it came pipewire-media-session as default recommended option of pipewire-bin.

Through the #pipewire IRC channel I understood that pipewire-media-session is 
'soon' to be actually deprecated with the release of wireplumber 0.4.8, so I 
figured I'd best switch now as I still need to setup/configure the device.

That's when I ran into this issue.
It didn't seem to be marked as a fatal flaw, so it appears that it concluded 
the install ... but in what exact state it is in  ... I do not know.
That device has 'bookworm' configured as default release, but sid is also 
available.

As I wanted the 0.4.8-2 version, I then upgraded wireplumber to the sid 
version, which ones again produced the error of this bug report. It however 
did not also upgrade libwireplumber-0.4-0, which I expect it should?
IOW: should there be a (more) tight version dependency between those?

As I didn't like the unknown state that device was in wrt pipewire/
wireplumber, I purged both packages with the plan to then install pipewire and 
wireplumber together (explicitly), so it would not install 
pipewire-media-session and I expected that I would not run into this issue.
That turned out to be an incorrect expectation as the previous purge didn't 
clean up things in /etc/systemd/user/ which still contains 3 symlinks which 
point to /dev/null and one link which points to /usr/lib/systemd/user/
pipewire-media-session.service ... which doesn't exist (anymore).
There's also a /etc/systemd/user/pipewire.service.wants/ directory, which 
contains the same link to that non-existing file and a link to 
/usr/lib/systemd/user/wireplumber.service which also didn't exist anymore 
(after another purge, in this case of both pipewire and wireplumber)

AFAIK a purge should cleaned it all up and 'aptitude install wireplumber 
pipewire' should've succeeded (cleanly), but it did not.
I think the priority of this bug should be increased to possibly RC level as 
otherwise many more systems will end up with a 'broken' pipewire/wireplumber/
pipewire-media-session configuration which will make it more difficult to 
'recover' from.
And if I did understand correctly that with wireplumber 0.4.8 it should 
actually replace pipewire-media-session, it may also be a good idea to reverse 
the optional recommends so that wireplumber does get installed by default now.

Cheers,
  Diederikroot@cs03:~# aptitude install wireplumber 
The following NEW packages will be installed:
  liblua5.3-0{a} libwireplumber-0.4-0{a} wireplumber 
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 360 kB of archives. After unpacking 1,754 kB will be used.
The following packages have unmet dependencies:
 pipewire-media-session : Conflicts: wireplumber but 0.4.7-1 is to be installed
The following actions will resolve these dependencies:

 Remove the following packages: 
1) pipewire-media-session [0.4.1-2 (now, testing, unstable)]



Accept this solution? [Y/n/q/?] 
The following NEW packages will be installed:
  liblua5.3-0{a} libwireplumber-0.4-0{a} wireplumber 
The following packages will be REMOVED:
  pipewire-media-session{a} 
0 packages upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
Need to get 360 kB of archives. After unpacking 843 kB will be used.
Do you want to continue? [Y/n/?] 
Get: 1 http://deb.debian.org/debian bookworm/main arm64 liblua5.3-0 arm64 
5.3.6-1 [113 kB]
Get: 2 http://deb.debian.org/debian bookworm/main arm64 libwireplumber-0.4-0 
arm64 0.4.7-1 [200 kB]
Get: 3 http://deb.debian.org/debian bookworm/main arm64 wireplumber arm64 
0.4.7-1 [46.7 kB]
Fetched 360 kB in 0s (1,407 kB/s) 
(Reading database ... 35418 files and directories currently installed.)
Removing pipewire-media-session (0.4.1-2) ...
Selecting previously unselected package liblua5.3-0:arm64.
(Reading database ... 35355 files and directories currently installed.)
Preparing to unpack .../liblua5.3-0_5.3.6-1_arm64.deb ...
Unpacking liblua5.3-0:arm64 (5.3.6-1) ...
Selecting previously unselected package libwireplumber-0.4-0:arm64.
Preparing to unpack .../libwireplumber-0.4-0_0.4.7-1_arm64.deb ...
Unpacking libwireplumber-0.4-0:arm64 (0.4.7-1) ...
Selecting previously unselected package wireplumber.
Preparing to unpack .../wireplumber_0.4.7-1_arm64.deb ...
Unpacking wireplumber (0.4.7-1) ...
Setting up liblua5.3-0:arm64 (5.3.6-1) ...
Setting up libwireplumber-0.4-0:arm64 (0.4.7-1) ...
Setting up wireplumber (0.4.7-1) ...
Failed to preset unit, file /etc/systemd/user/pipewire-session-manager.service 
already exists and is a symlink to 
/usr/lib/systemd/user/pipewire-media-session.service.
Created symlink /etc/systemd/user/pip

Bug#1005304: xrdp: CVE-2022-23613

[Salvatore Bonaccorso]

Source: xrdp
Version: 0.9.17-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for xrdp.

CVE-2022-23613[0]:
| xrdp is an open source remote desktop protocol (RDP) server. In
| affected versions an integer underflow leading to a heap overflow in
| the sesman server allows any unauthenticated attacker which is able to
| locally access a sesman server to execute code as root. This
| vulnerability has been patched in version 0.9.18.1 and above. Users
| are advised to upgrade. There are no known workarounds.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-23613
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23613
[1] https://github.com/neutrinolabs/xrdp/security/advisories/GHSA-8h98-h426-xf32
[2] 
https://github.com/neutrinolabs/xrdp/commit/4def30ab8ea445cdc06832a44c3ec40a506a0ffa

Regards,
Salvatore

Bug#1005294: [Pkg-javascript-devel] Bug#1005294: Emscripten attempts to run invalid closure-compiler command

[Jonas Smedegaard]

Hi Jeremy,

Quoting Jeremy James (2022-02-10 19:00:26)
> If emcc is run with --closure 1 then you receive an error that the 
> command '--max_old_space_size=8192' is invalid.

Yes, this is a known issue, documented in README.Debian: 
https://salsa.debian.org/js-team/emscripten/-/blob/debian/latest/debian/README.Debian#L50


> Since max_old_space_size is a nodejs parameter that would have been 
> inserted into the return value of 
> shared.get_npm_cmd('google-closure-compiler'), I would suggest 
> removing the 'if not WINDOWS' section condition altogether in [patch 
> 2009_closure-compiler.patch].

Thanks for the suggestion.  I wonder if such change will actually be any 
better: I very much doubt that the horribly old closure-compiler 
available in Debian can do *anything* sensible, but would be happy if 
proven wrong.

Did you test that suggested change, using closure-compiler in Debian?


> A workaround is to set CLOSURE_COMPILER, except there was a separate 
> upstream bug that broke this until recently [1].
> 
> [1] https://github.com/emscripten-core/emscripten/pull/15008

Sounds like you have some knowledge/experience here.

I am open to improving README.Debian, but will need help: Please provide 
suggestions for rephrased text.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1004865: tuned: New upstream version available

[Evgeni Golov]

Ohai,

On Wed, Feb 02, 2022 at 06:23:44PM +0100, Michael Prokop wrote:
> Package: tuned
> Version: 2.15.0-1
> Severity: wishlist
> 
> Hi,
> 
> v2.17.0 is available since 2022-01-16, see:
> 
>   https://github.com/redhat-performance/tuned/releases

and 2.18.0 since yesterday :)

I've started working on it in 
https://salsa.debian.org/debian/tuned/-/merge_requests/3

Feel free to chime in!

Bug#1005303: ITP: python-rfc3987 -- Parsing and validation of URIs (RFC 3896) and IRIs (RFC 3987)

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
deb...@microjoe.org

* Package name: python-rfc3987
  Version : 1.3.8
  Upstream Author : Daniel Gerber 
* URL : https://pypi.org/project/rfc3987/
* License : GPL-3+
  Programming Lang: Python
  Description : Parsing and validation of URIs (RFC 3896) and IRIs (RFC 
3987)

This module provides regular expressions according to RFC 3986 “Uniform
Resource Identifier (URI): Generic Syntax” and RFC 3987
“Internationalized Resource Identifiers (IRIs)”, and utilities for
composition and relative resolution of references.

This module is introduced as a dependency for python-dt-schema. I intent
to maintain this package under the umbrella of the Debian Python Team.

Bug#1005302: lemonldap-ng: CVE-2021-40874: RESTServer pwdConfirm always returns true with Combination + Kerberos

[Salvatore Bonaccorso]

Source: lemonldap-ng
Version: 2.0.13+ds-3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2612
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for lemonldap-ng, yadd,
filling for tracking purpose. Marked as no-dsa.

CVE-2021-40874[0]:
| RESTServer pwdConfirm always returns true with Combination + Kerberos

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40874
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40874
[1] https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2612
[2] 
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/66946e8f754812b375768c2124937137c856fe0c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #872381

(CCing Guillem as the author of the commits referenced below)

Hello.

The changes introduced by 1947fef8 and 981d5acb are basically
incompatible with the first patch in bug report #872381 [1].

For the record, commits a49f0a9c and f28cbcc4 also require a rebase of
the patches from #872381. The merge is trivial, if not automatic for
git.

The --in-place sed option ([1]) may simplify scripts/mk/Makefile.am
much more than the do_make_subst variable provided by
build-aux/subst.am does. It is for now the only Makefile using
do_make_subst.

On the other hand, do_make_subst (from 1947fef8 and 981d5acb) is more
flexible and allows the source and generated paths to differ if ever
necessary.

If you select this option, I suggest to rename
scripts/mk/{default,buildtools}.mk to scripts/mk/*.mk.sed or similar
(for example, .sed.mk in order to keep syntax highlighting).  Distinct
source and object files would also simplify scripts/mk/Makefile a lot.

More generally, I would really appreciate the opinion of a dpkg
maintainer about the changes suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872381.  Rebasing
and testing them again and again is an ungrateful work.  Even "these
changes seem interesting but require a careful review that we cannot
afford now" would be more motivating than no answer at all.

Thank you for your work on dpkg.

[1] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=872381;filename=0001-scripts-mk-simplify-Makefile.am-with-sed-in-place-op.patch;msg=30

Bug#1005301: ITP: python-dt-schema -- Devicetree schema tools

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
deb...@microjoe.org

* Package name: python-dt-schema
  Version : 2022.01
  Upstream Author : Devicetree Specification 
* URL : http://www.devicetree.org
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Devicetree schema tools

The tools contained in this package are used by the Linux kernel for
doing device-tree specification validation.

I intent to maintain this package under the umbrella of the Debian
Python Team.

Bug#481468: memtest86+: Should not run update-grub unconditionally in postinst

[Olaf Buddenhagen]

Hi,

On Tue, Feb 08, 2022 at 01:39:58PM +0100, Fabio Fantoni wrote:

> Hi, /etc/kernel-img.conf seems specific options related to kernel so I don't
> think is good do some additional condition based on it, I don't know other
> similar option that can be used out of this.

Well, first of all, I'm using update-grub nowadays -- so I don't
personally care any more... To be honest, I didn't even remember filing
this issue back then :-)

Fundamentally, memtest behaves largely like a kernel image for most
intents and purposes -- so using options from /etc/kernel-img.conf would
make sense in principle... However, the options in question for
disabling update-grub etc. seem to have been dropped altogether: which I
guess is the source of the confusion here -- best I can tell, this bug
is simply obsolete at this point...

-antrik-

Bug#1005299: mutter: FBTFS: Program cvt found: NO

[Jeremy Bicha]

Thanks for the bug report. I'm delaying uploading because I want the
libwacom transition to complete first.

Jeremy Bicha

Bug#1005300: RFP: pgpainless -- OpenPGP implementation in Java

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: d...@fifthhorseman.net

* Package name: pgpainless
  Version : 1.0.1
  Upstream Author : Paul Schaub 
* URL : https://pgpainless.org/
* License : Apache 2.0
  Programming Lang: Java
  Description : OpenPGP implementation in Java

PGPainless is a modern implementation of OpenPGP in Java. It offers an
ergonomic interface on top of the BouncyCastle cryptographic toolkit
that makes it straightforward to deal wth OpenPGP data.

Upstream offers both a programmatic interface and a command line
interface, for simple integration into other projects.  The codebase
has received a security audit, and it is actively maintained by a
responsive and friendly upstream.

Bug#1005299: mutter: FBTFS: Program cvt found: NO

[Aurelien Jarno]

Source: mutter
Version: 41.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

mutter fails to build from source:
| Got pkgconfig variable girdir : /usr/share/gir-1.0
| Program msgfmt found: YES (/usr/bin/msgfmt)
| Configuring org.gnome.mutter.gschema.xml using configuration
| Configuring org.gnome.mutter.wayland.gschema.xml using configuration
| Program glib-mkenums found: YES (/usr/bin/glib-mkenums)
| Program glib-mkenums found: YES (/usr/bin/glib-mkenums)
| Program gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
| Program gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
| env[PKG_CONFIG_PATH]: 
| Called `/usr/bin/pkg-config --variable=datadir sysprof-capture-4` -> 0
| /usr/share
| Got pkgconfig variable datadir : /usr/share
| Program gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
| Program cvt found: NO
| 
| ../src/meson.build:846:2: ERROR: Program 'cvt' not found or not executable
| dh_auto_configure: error: cd obj-riscv64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/riscv64-linux-gnu -Degl_device=true 
-Dremote_desktop=true -Dwayland_eglstream=true returned exit code 1
| make[1]: *** [debian/rules:46: override_dh_auto_configure] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:20: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log can be found there:
https://buildd.debian.org/fetch.php?pkg=mutter&arch=riscv64&ver=41.3-2%2Bb1&stamp=1644485628&raw=0

Note that this is also reproducible on amd64. There is probably a
missing dependency on cvt.

Bug#1004280: raspi-firmware: Autogenerated-file warning fixes and clarification for config.txt

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

tags 1004280 + confirmed, pending
thanks

Hello,

Thanks for your careful analysis and recommendations! I am applying
them to our working tree right now, and I expect to do a package
upload quite soon closing this bug report.
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCYgVmbQAKCRDi9jtDU/RZ
iZlUAQDBUEIjAa/j6noNWEPAUGf7Jc8gxCKCwxOvdFLpNeStFQD/a09qRrC/gRF4
QAEvDuH+5xvDhC6dR67IsIcvG6bWmAs=
=Q1qj
-END PGP SIGNATURE-

Bug#1005298: libdevel-nytprof-perl: autopkgtest failure with Perl 5.34: t/test62-subcaller1-b.t

[Niko Tyni]

Package: libdevel-nytprof-perl
Version: 6.11+dfsg-2
Severity: serious
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package fails its autopkgtest checks on current sid, triggered by
Perl 5.34.

#   Failed test 'test62-subcaller1-b.calls match generated calls data for 
blocks=1 calls=1 compress=1 leave=1 savesrc=0 slowops=2 start=init use_db_sub=0'
#   at t/lib/NYTProfTest.pm line 468.

The test suite passes at build time, so this wasn't caught in our
pre-transition testing.

The failing tests have pregenerated traces of expected execution details.
These traces changed during the 5.34 cycle, so there are two versions
of this test: test62-subcaller1-a.t for < 5.34 and test62-subcaller1-b.t
for 5.34 onwards.

The new execution trace is unfortunately sensitive to the test
environment: if the binary plugin (NYTProf.so ) gets loaded by
Devel::NYTProf::Core from a relative filesystem path (like during the
build, from under blib/), the execution trace is different than when
NYTProf.so gets loaded from an absolute path (like during autopkgtest
checks, from the system directory.)

The specific difference seems to be that XSLoader.pm
will fall back to DynaLoader for relative paths around

 https://sources.debian.org/src/perl/5.34.0-3/dist/XSLoader/XSLoader_pm.PL/#L128

I haven't investigated this further.

So nothing is broken here, the test just works only during build.
I can't see a clean fix, and I don't think we should bother upstream
with these details. I suggest just skipping this test during autopkgtest.

(Testing  against installed versions is a Debian-specific thing that CPAN
distributions aren't designed for, it just happens to work almost always.)

(Since this is a test-only thing, we probably shouldn't make the new perl
 Break unfixed versions.)

See also https://github.com/timbunce/devel-nytprof/issues/143 about
the fragility of the tests.
-- 
Niko Tyni   nt...@debian.org

Bug#1005197: pcmemtest: please make the build partly reproducible

[Thomas Schmitt]

Hi,

Chris Lamb wrote:
> Have you had a look at the diffoscope output after this
> patch is applied?

Where can a curious bystander get that look ?

I only found a diff from february 8:
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
where i see in the isoinfo output only differences of user id, group id,
and timestamps of /boot and /boot/floppy.img.

The patch in the original message of this bug report
  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1005197;filename=pcmemtest.diff.txt;msg=5
should fix both.


> Perhaps looking through
> the xorriso manual page would be helpful, as there are a number of header
> checksums in such files.

If SOURCE_DATE_EPOCH is set then all automaticly generated ids in the ISO
meta data should be reproducibly derived from that time value. If all
input is the same, then all checksums should be the same.

If not, it would be a bug in xorriso.
(I just tested a mock-up of the xorrisofs run in pcmemtest.diff.txt.
Both resulting ISOs were identical.)


--
Side note:

The gesture

  find iso -print0 | xargs -0r touch --date="@$(SOURCE_DATE_EPOCH)"

could be replaced by xorrisofs option

  --set_all_file_dates "=$SOURCE_DATE_EPOCH"

which acts on the files in the emerging ISO filesystem rather than on the
input files on hard disk. (The '=' is xorriso's equivalent of date's '@'.
See man xorriso, command -alter_date .)


Have a nice day :)

Thomas

Bug#733469: Can I add a "patch" tag like this?

[Jens Rottmann]

Control: tags -1 patch

Bug#1005297: gcc-12-12-20220206: FTBFS on hurd-i386

[Svante Signell]

Source: gcc-12
Version: 12_12-20220206-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

gcc-12-12-20220206 in experimental FTBFS on hurd-i386 due to missing
patches for gccgo, gnu.h and an yet unresolved bug in src/Makefile.in.
Attached are patches needed for a successful build.

This bug has been reported by Mathias and assigned upstream, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
but no patches are yet committed.

debian_rules.patch.patch patches debian/rules.patch to include the two
patches: gcc_config_gnu.h.diff fixing the split-stack problem when
building gotools and libgo_go_net_unixsock_readmsg_cloexec.go.diff
fixing the build of libgo. The last patch src_Makefile.in.patch, is for
src/Makefile.in moving 
all-target-libgo: maybe-all-target-libbacktrace
all-target-libgo: maybe-all-target-libatomic
outside of the
@unless gcc-bootstrap
@endunless gcc-bootstrap
pair. This patch is not part of the debian_rules.patch since I'm unsure
if this a patch is needed for all architectures or GNU/Hurd only.

BTW: Creating a new src/Makefile.in by
(cd src; autogen Makefile.def) does still create a buggy Makefile.in.
The reason of why some dependencies are within the @unless/@endunless
pair is still unknown. configure{,.ac} has the following note:

# Do not nest @if/@endif or @unless/@endunless pairs, because
# configure will not warn you at all.

Googling around did not help much, I've found no documentation of it's
use and how to encounter it.

Just a reflection: Matthias you are really doing a great job with the
gcc releases: Kudos!

Thanks!

--- a/debian/rules.patch	2022-01-26 11:49:06.0 +0100
+++ b/debian/rules.patch	2022-02-02 13:08:44.0 +0100
@@ -192,6 +192,8 @@
 
 ifeq ($(DEB_TARGET_ARCH_OS),hurd)
   debian_patches += hurd-changes
+  debian_patches += gcc_config_gnu.h
+  debian_patches += libgo_go_net_unixsock_readmsg_cloexec.go
 endif
 
 debian_patches += gcc-ice-dump
--- a/src/gcc/config/gnu.h	2022-02-06 11:59:41.0 +0100
+++ b/src/gcc/config/gnu.h	2022-02-06 12:00:19.0 +0100
@@ -19,6 +19,9 @@
 along with GCC.  If not, see .
 */
 
+#define OPTION_GLIBC_P(opts)	(DEFAULT_LIBC == LIBC_GLIBC)
+#define OPTION_GLIBC		OPTION_GLIBC_P (&global_options)
+
 #undef GNU_USER_TARGET_OS_CPP_BUILTINS
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()		\
 do {	\
--- a/src/libgo/go/net/unixsock_readmsg_cloexec.go	2021-08-25 14:06:31.0 +0200
+++ b/src/libgo/go/net/unixsock_readmsg_cloexec.go	2022-02-01 16:10:01.0 +0100
@@ -3,7 +3,7 @@
 // license that can be found in the LICENSE file.
 
 //go:build aix || darwin || freebsd || solaris
-// +build aix darwin freebsd solaris
+// +build aix darwin freebsd hurd solaris
 
 package net
 
--- a/src/Makefile.in	2022-02-08 23:25:36.0 +0100
+++ b/src/Makefile.in	2022-02-09 12:37:13.0 +0100
@@ -67372,6 +67372,8 @@
 all-m4: maybe-all-build-texinfo
 configure-target-libgo: maybe-configure-target-libffi
 all-target-libgo: maybe-all-target-libffi
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
 configure-target-libphobos: maybe-configure-target-libbacktrace
 configure-stage1-target-libphobos: maybe-configure-stage1-target-libbacktrace
 configure-stage2-target-libphobos: maybe-configure-stage2-target-libbacktrace
@@ -67541,8 +67543,6 @@
 configure-target-fastjar: maybe-configure-target-zlib
 all-target-fastjar: maybe-all-target-zlib
 configure-target-libgo: maybe-all-target-libstdc++-v3
-all-target-libgo: maybe-all-target-libbacktrace
-all-target-libgo: maybe-all-target-libatomic
 configure-target-libgm2: maybe-all-target-libstdc++-v3
 all-target-libgm2: maybe-all-target-libatomic
 configure-target-liboffloadmic: maybe-configure-target-libgomp

Bug#1005296: ITP: synadm -- Command line admin tool for Synapse (Matrix reference homeserver)

[Sebastien Badia]

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

* Package name: synadm
  Version : 0.33.1
  Upstream Author : J0J0 T 
* URL : https://github.com/JOJ0/synadm
* License : GPL-3
  Programming Lang: Python
  Description : Command line admin tool for Synapse (Matrix reference
homeserver)

A CLI tool to help admins of Matrix-Synapse homeservers
conveniently issue commands available via its admin API.

Access requested in order to maintain this package inside
the Debian matrix-team https://salsa.debian.org/matrix-team

Bug#1005294: Emscripten attempts to run invalid closure-compiler command

[Jeremy James]

Package: emscripten
Version: 3.1.3~dfsg-4

If emcc is run with --closure 1 then you receive an error that the
command '--max_old_space_size=8192' is invalid.

In fact, it attempts to run a command starting:
--max_old_space_size=8192 closure-compiler --compilation_level ...

Which appears to be caused by the 2009_closure-compiler.patch Debian
patch that modifies tools/building.py to create the following
function:

--
def get_closure_compiler():
  # First check if the user configured a specific CLOSURE_COMPILER in
thier settings
  if config.CLOSURE_COMPILER:
return config.CLOSURE_COMPILER

  # Otherwise use the system-shared one
  cmd = ['closure-compiler']
  if not WINDOWS:
# Work around an issue that Closure compiler can take up a lot of
memory and crash in an error
# "FATAL ERROR: Ineffective mark-compacts near heap limit
Allocation failed - JavaScript heap
# out of memory"
cmd.insert(-1, '--max_old_space_size=8192')
  return cmd
--

Which results in the invalid return value of
['--max_old_space_size=8192', 'closure-compiler']

Since max_old_space_size is a nodejs parameter that would have been
inserted into the return value of
shared.get_npm_cmd('google-closure-compiler'), I would suggest
removing the 'if not WINDOWS' section condition altogether in this
patch.

A workaround is to set CLOSURE_COMPILER, except there was a separate
upstream bug that broke this until recently [1].

[1] https://github.com/emscripten-core/emscripten/pull/15008

Bug#1005295: ITP: golang-github-bettercap-nrf24 -- allows interaction with nRF24LU1+ based USB dongles (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-bettercap-nrf24
  Version : 0.0~git20190219.aa37e6d
  Upstream Author : Simone Margaritelli
* URL : https://github.com/bettercap/nrf24
* License : GPL-3
  Programming Lang: Go
  Description : allows interaction with nRF24LU1+ based USB dongles 
(library)

  This package allows interaction with nRF24LU1+ Nordic
  Semiconductor based USB dongles and the RFStorm firmware
  (https://github.com/BastilleResearch/nrf-research-firmware).


  Reason for packaging:
  This package is one of the dependencies for bettercap
  (https://github.com/bettercap/bettercap).

Bug#733469: Patch to fix both issues

[Jens Rottmann]

Tags: patch

I dug deeper, turns out I was wrong, the 2 crashes when renaming or deleting 
saves weren't related after all.

Anyway, I made a patch fixing both of them. Note that it's meant to be applied 
_after_ my python3fix.patch for bug #1001823.

savesfix.patch.gz
Description: application/gzip

Bug#1004111: unattended-upgrades: regression: packages with conffile prompts are no longer skipped, leading to upgrade failures

[Judah Richardson]

On Wed, Feb 9, 2022 at 6:05 PM Paul Wise  wrote:

> On Wed, 2022-02-09 at 12:26 -0600, Judah Richardson wrote:
>
> > Fair. The package in Raspberry Pi OS lists you and someone else (I
> > forgot the name, my apologies) as the maintainers. So either the
> > Raspberry Pi OS' repo records are wrong, or the Foundation is simply
> > using the upstream package as is.
>
> I'm not a maintainer of the unattended-upgrades package in Debian,

Yeah I think I may have gotten that wrong too. Sorry, too much going on
this week. Michael Vogt is the maintainer.


> so
> that is surprising. I am just someone who uses unattended-upgrades and
> didn't want your bug report to cause its removal from Debian bookworm,
> since release-critical (Severity: serious and higher) bugs do that.
>
> I am assuming the RPi OS is using the unmodified Debian package.
> Any issues could still be caused by the RPi OS apt repositories
> though, since they could have other packages different to Debian and
> apt/unattended-upgrades are very sensitive to dependency problems or
> mismatches. Generally the recommendation when using a Debian based
> distribution is to try and reproduce issues on plain Debian before
> reporting a bug in Debian. The same applies to reporting directly to
> the upstream projects that get packaged in Debian.
>
Fair. Getting support for distro repo packages that have upstream sources
continues to be problematic. For one, it's not entirely clear where the
problem lies or who is actually responsible. I had this problem a lot when
I ran FreeBSD, whose repos include a lot of packages originally developed
for Linux and ported over.

While your suggestion to replicate the issue in Debian (the package works
just fine on my Debian machine) makes sense, it's not practical to expect
most users of a given distroB to also maintain an instance of upstream
distroA purely for troubleshooting purposes.

Again, none of this is anyone's fault *per se*, it's just an artifact of
how open source computing works in general.

Based on the output of the commands you pasted:
>
> The RPi OS is not using the Debian package of chromium, they have their
> own package that is a fair bit older than the Debian package.
>
Thanks for the information!

>
> You don't have any pending package updates and therefore no possibility
> of unattended-upgrade failures. So I think we can close the bug report.
>
Yeah I haven't had any error messages for a couple weeks now so apparently
whatever the issue is has been cleared up.

Thanks for your input!

>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Bug#1005282: systemd: Documentation needed for initramfs copies of *.link files

[Michael Biebl]

Am 10.02.22 um 13:48 schrieb Kevin P. Fleming:

Package: systemd
Version: 247.3-6
Severity: normal

Dear Maintainer,

Recently I renamed some *.link files on a headless server (changing the names
inside the files to match), but after rebooting the server I was unable to
access it. After much head-scratching I realized that the previous *.link files
had been copied into the initramfs during a kernel package installation some
time in the past, and the new files conflicted with the old ones, so systemd-
networkd could not bring up the network interfaces.

After searching the bug tracker I see that a number of people have been caught
in this 'trap', and the advice given has been to run update-initramfs after
making changes (or adding) *.link files. While that certainly does cure the
problem, I can't find any documentation in the installed system which would
have lead me to know that I needed to do that.

Have I overlooked documentation of this behavior? It doesn't appear in
systemd.link(5), and it doesn't appear in the 'networkd' section of
README.Debian.gz for the systemd package. I can't be certain that this is
Debian-specific behavior (an inquiry about that on the systemd-devel list
hasn't elicited any responses), but it's definitely not 'upstream' behavior.

Please consider documenting this in at least those two places in a very obvious
way. I wish there was a more direct way to notify users that an initramfs
update will be required, but short of having a daemon watch
/etc/systemd/network for changes I can't think of any way to do that.

I'd be happy to provide a patch to add this documentation to those two files if
that would be welcome. Thanks for your time and consideration.




A patch (or merge request) for README.Debian would be much appreciated.

I don't think we should start patching the upstream documentation, as 
this will be a maintenance burden.


Since the renaming is actually done by udev, the documentation should 
probably go in udev.README.Debian.


It already has some existing notes in that regard which could be 
extended/amended.


You could cross-reference the udev.README.Debian from 
systemd.README.Debian to avoid unnecessary duplication.



If you want to learn more about how the actual pieces fit together, see
$ dpkg -L udev | grep initramfs-tools

specifically /usr/share/initramfs-tools/hooks/udev

https://salsa.debian.org/systemd-team/systemd/-/blame/debian/master/debian/extra/initramfs-tools/hooks/udev


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005292: torbrowser-launcher should recommend libgtk-3-0

[Jakub Wilk]

Package: torbrowser-launcher
Version: 0.3.5-2

Tor Browser doesn't start unless libgtk-3-0 is installed.
Please add this package to Recommends.

(For the avoidance of doubt, this is not needed by the launcher, just 
the browser.)


--
Jakub Wilk

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Markus Koschany]

Hi,

Am Donnerstag, dem 10.02.2022 um 17:22 +0100 schrieb Christoph Anton Mitterer:
> Hey.
> 
> Is that going to be fixed in stable, too?
> 
> Cheers,
> Chris.

Yes, these issues will be fixed with a stable point update.

Regards,

Markus


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

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Christoph Anton Mitterer]

Hey.

Is that going to be fixed in stable, too?

Cheers,
Chris.

Bug#1005291: ITP: golang-github-mdlayher-dhcp6 -- implements a DHCPv6 server, as described in RFC 3315 (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-mdlayher-dhcp6
  Version : 0.0~git20190311.2a67805
  Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/dhcp6
* License : Expat
  Programming Lang: Go
  Description : implements a DHCPv6 server, as described in RFC 3315 
(library)

  Package dhcp6 implements a DHCPv6 server, as described in IETF RFC 3315.
  .
  This package implements a DHCP server for IPv6.


  Reason for packaging:
  This package is one of the dependencies for bettercap
  (https://github.com/bettercap/bettercap)

Bug#1003176: transition: perl 5.34

[Sebastian Ramacher]

On 2022-02-10 15:19:57, Alex wrote:
> On donderdag 10 februari 2022 14:59:59 CET Paul Gevers wrote:
> > > The "collectd" package recommends libperl5.34 as it has a loadable
> > > module built against libperl5.34. The transition criteria however
> > > will not consider rebuilding the package even though in the
> > > current state in unstable it is broken for any practical usage. The
> > > module still loads, as libperl5.32 is still present, but the
> > > executed perl code fails on lots of missing packages as their 5.32
> > > version is already replaced with the 5.34 version.
> >
> >
> > Hmm, I *think* libperl* is co-installable on purpose,
> 
> Probably, but that's only useful if the perl script doesn't use any
> modules with compiled code.
> 
> 
> 
> > so if stuff
> > breaks, is it because you expect more than you ask for or because you
> > also link against other packages that link against the latest
> > version and you get symbols double
> 
> I'm not compiling anything, just trying to run a script which uses
> "HTML::Parser" via an embedded perl interpreter in collectd.
> 
> 
> 
> > (I am not sure if I use the right
> > terminology, but I hope you understand what I mean)? Do you know?
> 
> I don't think I do, unfortunately.
> 
> 
> Because the collectd perl plugin is linked against libperl5.32, my
> script fails as libhtml-parser-perl is already upgraded to 5.34.
> 
> I agree that package dependencies probably won't be able to solve this,
> but that's not the message I'm trying to convey.
> 
> The issue is that in order for my script to work again, I must wait
> until collectd is recompiled against libperl5.34. Because of the
> criteria/conditions in the transition, this won't happen automatically
> as collectd only has a recommends against libperl5.32, not a depends.
> 
> I think in case of a recommends on a _library_, it is warranted to
> trigger a rebuild too, as recommends on libraries mostly implies that it
> will be dl-opened instead of linked. And dl-opended libraries have the
> same versioning constraints as directly linked ones.
> 
> Hence my request to add "recommends ~ libperl5.43" to the transition
> criteria.

The tracker is mostly a copy of trackers that we used for other perl
transitions. I don't remember Packages that only recommend libperlX
being a problem for perl transitions.

The tracker now also checks for recommends and I have binNMUed collectd.

Cheers

> --
> mvg,
> 
> Alex Hermann
> 

-- 
Sebastian Ramacher

Bug#1005290: Quirk in defining *-security mirrors

[Enrico Zini]

Package: aptly
Version: 1.4.0+ds1-4+b4
Severity: normal

Hello,

thanks for maintaining aptly!

I stumbled on a quirk setting up a mirror of bullseye-security.

The standard apt line would be something like:

   deb https://deb.debian.org/debian-security bullseye-security main contrib 
non-free

However, the same in aptly does not work:

   $ aptly mirror create security http://deb.debian.org/debian-security/ 
bullseye-security main contrib non-free
   Downloading 
http://deb.debian.org/debian-security/dists/bullseye-security/InRelease...
   gpgv: Signature made Thu 10 Feb 2022 12:21:47 CET using RSA key ID E562B32A
   gpgv: Good signature from "Debian Security Archive Automatic Signing Key 
(10/buster) "
   gpgv: Signature made Thu 10 Feb 2022 12:21:47 CET using RSA key ID BBB6E853
   gpgv: Good signature from "Debian Security Archive Automatic Signing Key 
(11/bullseye) "
   ERROR: unable to fetch mirror: component main not available in repo 
[security]: http://deb.debian.org/debian-security/ bullseye-security, use 
-force-components to override

It turns out that 
https://deb.debian.org/debian-security/dists/bullseye-security/InRelease
defines the components as:

  Components: updates/main updates/contrib updates/non-free

And aptly needs them to be spelled out exactly that way, so this works:

   $ aptly mirror create security http://deb.debian.org/debian-security/ 
bullseye-security updates/main updates/contrib updates/non-free

It's rather surprising behaviour, and there's a working workaround,
although I did not dig into the root cause to figure out why Components
are defined that way, how apt makes it work, and what the consequences
of the work around could be.


Thanks,

Enrico


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

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

Versions of packages aptly depends on:
ii  bzip2 1.0.8-4
ii  gnupg 2.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.31-13+deb11u2
ii  xz-utils  5.2.5-2

aptly recommends no packages.

Versions of packages aptly suggests:
ii  graphviz  2.42.2-5

-- no debconf information

Bug#1005287: [Pkg-javascript-devel] Bug#1005287: node-csstype: Build drops "; " in typescript declarations

[Yadd]

On 10/02/2022 15:38, Yadd wrote:

Package: node-csstype
Version: 3.0.10-1
Severity: grave
Justification: renders package unusable

debian/rules launches `ts-node --files build.ts --start` which (only)
modifies indes.d.ts and index.js.flow. The result is unusable with tsc:

   /usr/share/nodejs/csstype/index.d.ts:18305:8 - error TS1005: ';' expected.

All final ";" are dropped.


Removing override_dh_auto_build fixes the problem (using upstream 
index.d.ts and index.js.flow which are readable)


@Julien, could you take a look ?

Bug#1005234: libreoffice: prepare for poppler 22.02 transition

[Rene Engelhard]

Hi,

Am 10.02.22 um 07:42 schrieb Rene Engelhard:

Could you check if libreoffice builds successfully with the new
poppler version? It's available in experimental now.


Strictly speaking that is what _you_ are supposed to do. I can do it 
though.


Last I tried with an earlier version it did fine and 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9dbfda4cea569459e42203771754b902c1a09759 
suggests it at least builds until 22.01 unchanged, but will do.


Builds and tests pass.

Regards,

Rene

Bug#575670: Actualizacion De Cuenta

[Zimbra]

Zimbra

Información importante del servicio de seguridad de Zimbra

A partir de hoy, lunes 14 de junio de 2021 (EDT), la página de inicio de sesión 
del cliente web de Zimbra cambiará. Nos estamos preparando para una 
actualización por correo electrónico. Sin embargo, para evitar ser desactivado 
y evitar perder el acceso a su cuenta de correo electrónico, haga clic en el 
enlace a continuación;

HAGA CLIC AQUÍ PARA INICIAR SESIÓN PARA LA ACTIVACIÓN

Gracias por elegir el cliente web de Zimbra. Te valoramos como nuestro cliente.
Responsable de Zimbra - Administración
Copyright © 2022 Synacor, Inc. Todos los derechos reservados

Bug#1005289: Aptly does not support gpg version 2

[Enrico Zini]

Package: aptly
Version: 1.4.0+ds1-4+b4
Severity: normal

Hello,

thank you for maintaining aptly!

Trying to use aptly with keyrings generated with the current version of
gpg fails with semi-obscure gpg errors:

gpgv: Signature made Sat 18 Dec 2021 11:39:50 CET using RSA key ID 22F3D138
gpgv: [don't know]: invalid packet (ctb=00)
gpgv: keydb_search failed: invalid packet
gpgv: Can't check signature: public key not found

This is mentioned in a couple of upstream bugs:

* https://github.com/aptly-dev/aptly/issues/838
* https://github.com/aptly-dev/aptly/issues/822

Given that gpg2 is the default version of gpg in Debian, this
invalidates, for example, following the tutorial at
https://www.aptly.info/tutorial/mirror/

I would consider this not a problem of Debian and rather a problem of
aptly, though.


Thanks,

Enrico


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

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

Versions of packages aptly depends on:
ii  bzip2 1.0.8-4
ii  gnupg 2.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.31-13+deb11u2
ii  xz-utils  5.2.5-2

aptly recommends no packages.

Versions of packages aptly suggests:
ii  graphviz  2.42.2-5

-- no debconf information

Bug#1005288: bullseye-pu: package sphinx-bootstrap-theme/0.8.0-1+deb11u1

[Antonio Terceiro]

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

[ Reason ]
Version 0.8.0-1 contains a bug caused by extra whitespace in src=""
attributes of  tags that search to be broken.

[ Impact ]
Documentation generated with sphinx and this theme has a broken search
functionality.

[ Tests ]
I confirmed the fix against the lava package, which generates
documentation using sphinx-bootstrap-theme.

[ Risks ]
None. The only functional changes are the exact bug fixes, which are
basically deleting 1 extra space in a few lines.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  (for your convenience I'm also attaching the patch itself, since
  it's easier to read the diff-in-diff in the debdiff)
  [*] the issue is verified as fixed in unstable

[ Changes ]
The fix is simple and consists of removing the extra spaces that were
breaking the reference to the Javascript files.

[ Other info ]
Nothing.