Bug#983494: arch-test breaks debootstrap into empty chroot

[Arnaud R]

Also struggling with something similar, I thought I hit this bug, but 
actually no. Let me bring more details.


> arch-test looks for its test files *inside* the chroot;

That's not how I read the code. It copies the helper in the chroot, and 
then it runs it with chroot:


https://github.com/kilobyte/arch-test/blob/28f25fef25cdb09805a20986414bf3435c67d47f/arch-test#L56

And here's a corresponding trace, while running it with '-x':

||

|++ basename /usr/lib/arch-test/arm64|
|||
+ HELPER_F=arm64
||
+ cp -p /usr/lib/arch-test/arm64 
/builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling/arm64

||
+ trap 'rm 
'\''/builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling/arm64'\''' 
0

||
++ chroot /builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling 
/arm64

||
+ MSG=
||
+ '[' 127 -eq 0 -a x = xok ']'
||
+ echo 'arm64: not supported on this machine/kernel'
||
arm64: not supported on this machine/kernel
||+ exit 1|

|Cheers,|

|  Arnaud
|

Bug#971876: Potential memory corruption bug in Chromium uncovered by hardened_malloc

[pseudonym23538]

The issue is still not fixed.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#985423: [Pkg-javascript-devel] Bug#985423: eslint needs to depend on node-text-table (or change default formatter)

[Marco Trevisan]

Hi Jonas,

> eslint does not depend on but recommends node-text-table, and does so  
> because it is needed only in "all but unusual installations" as
> covered by Debian Policy § 7.2:  

I'm a bit confused by this as launching in a clean schroot where I've
only eslint installed I get:

 eslint -h

Output:
  -f, --format StringUse a specific output format - default: stylish

So, the stylish module is the default one and as such, it isn't exactly
required by unusual installations, but by all unless you don't use
another `--format`, isn't it?

Cheers

Bug#985426: aux.c: calculate the size of NBUF to accommodate two arrays and a string

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From ced49aa3205279d9e3ea678de129a3326c13f9fb Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 18 Mar 2021 03:51:31 +
>Subject: [PATCH] aux.c: calculate the size of NBUF to accommodate two arrays
> and a string

  The compiler issues warnings about the needed length in several uses
of "snprintf()".

Signed-off-by: Bjarni Ingi Gislason 
---
 aux.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/aux.c b/aux.c
index f5c3a87..72f3b6f 100644
--- a/aux.c
+++ b/aux.c
@@ -298,7 +298,9 @@ aux_sh(article_header * ah, char *script, char *prog, char 
*action, char *record
 charroute[512], *poster = NULL;
 int goodsigntype = 0;
 int loop = 1, prmpt = 0;
-#define NBUF  80
+/* 53 is the length of the string "awk ..." in the line number about 589 */
+/* NBUF = sizeof(bdy) + sizeof(sgn) + 53 + strlen(NUL) */
+#define NBUF  2 * FILENAME + 54
 #define NBUF2 10
 charcc[256], pr[80], pr1[80], fname[FILENAME], buf[NBUF];
 charbuf2[NBUF2];
-- 
2.30.2



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

Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983365: [PATCH] Re: Bug#983365: linphone-desktop: chat messages

[David Pirotte]

Hello Bernard,
Dennis,

> > Please make sure you also test a file transfer, which is part of the
> > chat message interface [I couldn't try since the chat msgs itself
> > didn't work ...], The file transfer functionality is absolutely
> > essential as well, afaic at least   

> soci 4.0.1-5 has migrated to testing yesterday. The bug should be
> fixed now for a fully up-to-date Bullseye system.

Indeed:

ii  libsoci-core4.0:amd64   4.0.1-5  ...
ii  libsoci-sqlite3-4.0:amd64   4.0.1-5  ...

solved the problem: I now see the chat msgs history when I launch the
app. I didn't have a chance to send a new msg yet, because it's the
middle of the night for nearly all my contacts, and I don't want to
inadvertently 'awake' someone, but I am pretty sure its ok, will try
tomorrow ...

Thanks to both of you!
David


pgpcqgLatuS7U.pgp
Description: OpenPGP digital signature

Bug#985425: sylpheed: email attachment send problem

[Shui Qucheng]

Package: sylpheed
Version: 3.7.0-6ubuntu1
Severity: important
Tags: patch

When sending an email with an email format file as an attachment, the
attachment is empty after successful sending.

Repeat steps:

1. Click the "Compose" button to write an email.

2. After you have filled in the right recipient, subject line and body of the
email, click the "Attach File "button and the Attach file window will pop up.

3. In the Attachment file selection window, select a file in email format.

4. Click the send button. After successful sending, check the sent and received
messages in the mail client.

I have fixed this bug. The attachment is the patch.
https://salsa.debian.org/sylpheed-team/sylpheed/-/merge_requests/6



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

Kernel: Linux 5.8.0-44-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sylpheed depends on:
ii  libc62.31-0ubuntu9.2
ii  libcairo21.16.0-4ubuntu1
ii  libcompfaceg11:1.5.2-5build1
ii  libenchant-2-2   2.2.8-1ubuntu0.20.04.1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3ubuntu0.2
it  libglib2.0-0 2.64.6-1~ubuntu20.04.2
ii  libgpgme11   1.13.1-7ubuntu2
ii  libgtk2.0-0  2.24.32-4ubuntu4
ii  libgtkspell0 2.0.16-1.3
ii  libldap-2.4-22.4.49+dfsg-2ubuntu1.7
ii  libonig5 6.9.4-1
ii  libpango-1.0-0   1.44.7-2ubuntu4
ii  libpangocairo-1.0-0  1.44.7-2ubuntu4
ii  libssl1.11.1.1f-1ubuntu2.2
ii  pinentry-gtk21.1.0-3build1
ii  sensible-utils   0.0.12+nmu1

Versions of packages sylpheed recommends:
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  ca-certificates20210119~20.04.1
ii  sylfilter  0.8-7
ii  sylpheed-i18n  3.7.0-6ubuntu1

Versions of packages sylpheed suggests:
pn  claws-mail-tools  
pn  curl  
pn  sylpheed-doc  
pn  sylpheed-plugins  

-- no debconf information
From: Shui Qucheng 
Date: Thu, 11 Mar 2021 11:23:30 +0800
Subject: Fixed the problem that when sending e-mail with e-mail format file as 
attachment, the attachment was empty after successful sending.
 https://sylpheed.sraoss.jp/redmine/issues/327

---
 src/compose.c | 10 ++-
 1 file changed, 8 insertions(+), 2 deletion(-)

Index: src/compose.c
===
--- a/src/compose.c
+++ b/src/compose.c
@@ -4571,7 +4571,7 @@
 {
GtkTreeModel *model = GTK_TREE_MODEL(compose->attach_store);
GtkTreeIter iter;
-   gboolean valid;
+   gboolean valid,bmail;
AttachInfo *ainfo;
FILE *attach_fp;
gint len;
@@ -4604,7 +4604,13 @@
 
encoding = ainfo->encoding;
 
-   if (!g_ascii_strncasecmp(ainfo->content_type, "message/", 8)) {
+if (!g_ascii_strncasecmp(ainfo->content_type, "message/rfc822", 14)) {
+   bmail=TRUE;
+ainfo->encoding = ENC_BASE64;
+   }else{
+   bmail=FALSE;
+   } 
+   if (!bmail&&!g_ascii_strncasecmp(ainfo->content_type, 
"message/", 8)) {
fprintf(fp, "Content-Type: %s\n", ainfo->content_type);
fprintf(fp, "Content-Disposition: inline\n");
 

Bug#892058: Your Debian key is expiring

[Aaron M. Ucko]

(Bcc: Felix)

Felix Lechner  writes:

> If you like this service, please leave a favorable comment here [2].

Please count me among those who found these reminders helpful.  Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#947860: release-notes: Sec 4.3 preparing sources.list omits explicit statement of key change

[Holger Wansing]

Hi,

Paul Gevers  wrote (Wed, 17 Mar 2021 22:14:42 +0100):
> Hi,
> 
> On 17-03-2021 22:10, Paul Gevers wrote:
> > I intend to commit the attached patch.
> 
> By the way, I noticed that here we're inconsistent. In most other places
> we talk about "APT source-list", but here it's "APT's source-list". I
> recall we did that latter on purpose in buster. Shall I make it consistent?

Why not say something with the correct filename? 
Like "APT's sources.list"


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#984488: [SECURITY PATCH 114/117] kern/misc: Add function to check printf() format against expected format

[Colin Watson]

On Tue, Mar 02, 2021 at 07:02:01PM +0100, Daniel Kiper wrote:
> @@ -1121,6 +1159,42 @@ grub_xasprintf (const char *fmt, ...)
>return ret;
>  }
>  
> +grub_err_t
> +grub_printf_fmt_check (const char *fmt, const char *fmt_expected)
> +{
> +  struct printf_args args_expected, args_fmt;
> +  grub_err_t ret;
> +  grub_size_t n;
> +
> +  if (fmt == NULL || fmt_expected == NULL)
> +return grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid format");
> +
> +  ret = parse_printf_arg_fmt (fmt_expected, _expected, 1, 
> GRUB_SIZE_MAX);
> +  if (ret != GRUB_ERR_NONE)
> +return ret;
> +
> +  /* Limit parsing to the number of expected arguments. */
> +  ret = parse_printf_arg_fmt (fmt, _fmt, 1, args_expected.count);
> +  if (ret != GRUB_ERR_NONE)
> +{
> +  free_printf_args (_expected);
> +  return ret;
> +}
> +
> +  for (n = 0; n < args_fmt.count; n++)
> +if (args_fmt.ptr[n].type != args_expected.ptr[n].type)
> + {
> + ret = grub_error (GRUB_ERR_BAD_ARGUMENT, "arguments types do not 
> match");
> + break;
> + }
> +
> +  free_printf_args (_expected);
> +  free_printf_args (_fmt);
> +
> +  return ret;
> +}
> +
> +
>  /* Abort GRUB. This function does not return.  */
>  static void __attribute__ ((noreturn))
>  grub_abort (void)

This function is only used by gfxmenu.  Could it please be moved out of
the kernel and into a module, perhaps just gfxmenu itself?

As shown in the report from the other mail I just sent to this thread,
this patch costs an additional 273 bytes on i386-pc, where core image
size is at an extreme premium on some systems with limited space between
the MBR and the first partition; a plausible RAID setup used by some
Debian users is currently 316 bytes over the limit, so reclaiming this
space would be valuable.

Reclaiming all of those 273 bytes would probably involve duplicating
parse_printf_arg_fmt rather than having the fmt_check and max_args
arguments there, but I'm sure that even just moving the top-level
format-checking function would help.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#962921: Please fix spam for bullseye

[Tiago Bortoletto Vaz]

Hi again, I just noticed I had said I'd be working on it 'this weekend', but in
fact I meant the next one, during our local sprint session from Debian-quebec.

Bests,

On Tue, Mar 09, 2021 at 09:30:27AM -0800, Felix Lechner wrote:
> Dear maintainer,
> 
> The release team will accept this patch for bullseye. They raised the
> bug status to "serious" after I asked on your behalf. Please upload a
> patched version and ask for unblocking in a bug against release.d.o.
> 
> Thanks for your contributions to Debian!
> 
> Kind regards
> Felix Lechner

Bug#985374: [SECURITY PATCH 001/117] verifiers: Move verifiers API to kernel image

[Colin Watson]

On Tue, Mar 02, 2021 at 07:00:08PM +0100, Daniel Kiper wrote:
> From: Marco A Benatto 
> 
> Move verifiers API from a module to the kernel image, so it can be
> used there as well. There are no functional changes in this patch.

I've had reports in Debian that the i386-pc image no longer fits in the
MBR in some configurations (e.g. https://bugs.debian.org/984488,
https://bugs.debian.org/985374).

(Yes, I know, MBR is awful and even people who have to use it should put
the first partition at more like 1MiB rather than 63 sectors, but it
isn't practical for non-experts to fix up existing systems without a
complete reinstallation, so breaking this in a security update is pretty
bad.)

Since I suspected that a lot of this was due to organic growth of the
image as the security patch series made various bits of code more
careful, I wrote a script to build each revision along the upstream
changes from Debian version 2.04-15 to 2.04-16 and build an image with
the following modules, extracted from one of those bug reports: ext2
part_msdos diskfilter mdraid09 biosdisk.  Here's a report of the
resulting image sizes and commits:

  30884 2bd6855d2 grub-install: Fix inverted test for NLS enabled when copying 
locales
  31427 0d324ad1b verifiers: Move verifiers API to kernel image
  31446 6e14c57c6 kern: Add lockdown support
  31446 f1d70c97b kern/lockdown: Set a variable if the GRUB is locked down
  31446 71b48a193 efi: Lockdown the GRUB when the UEFI Secure Boot is enabled
  31446 3d8afd579 efi: Use grub_is_lockdown() instead of hardcoding a disabled 
modules list
  31446 c3037730d acpi: Don't register the acpi command when locked down
  31446 5d58cce5c mmap: Don't register cutmem and badram commands when lockdown 
is enforced
  31446 22f08600d commands: Restrict commands that can load BIOS or DT blobs 
when locked down
  31446 bf939ef4e commands/setpci: Restrict setpci command when locked down
  31446 ad9d55e50 commands/hdparm: Restrict hdparm command when locked down
  31446 13a1fa9c1 gdb: Restrict GDB access when locked down
  31446 b1e1dd471 loader/xnu: Don't allow loading extension and packages when 
locked down
  31446 9042c1bc8 docs: Document the cutmem command
  31452 9e6b789fa dl: Only allow unloading modules that are not dependencies
  31452 d26f10df9 usb: Avoid possible out-of-bound accesses caused by malicious 
devices
  31452 a993a2006 mmap: Fix memory leak when iterating over mapped memory
  31452 60709e32e net/net: Fix possible dereference to of a NULL pointer
  31452 118fe4df3 net/tftp: Fix dangling memory pointer
  31473 967b95c4e kern/parser: Fix resource leak if argc == 0
  31473 42b46cb07 kern/efi: Fix memory leak on failure
  31473 10f42aeff kern/efi/mm: Fix possible NULL pointer dereference
  31473 ad3b3b125 gnulib/regexec: Resolve unused variable
  31473 a0b08bad3 gnulib/regcomp: Fix uninitialized token structure
  31473 3131d3ff8 gnulib/argp-help: Fix dereference of a possibly NULL state
  31473 dc28cd75d gnulib/regexec: Fix possible null-dereference
  31473 711dd9d97 gnulib/regcomp: Fix uninitialized re_token
  31473 28314f6c1 io/lzopio: Resolve unnecessary self-assignment errors
  31473 f4eb2c3dd zstd: Initialize seq_t structure fully
  31482 6d368ec03 kern/partition: Check for NULL before dereferencing input 
string
  31482 e743b06fc disk/ldm: Make sure comp data is freed before exiting from 
make_vg()
  31482 af94bf626 disk/ldm: If failed then free vg variable too
  31482 8e43b154c disk/ldm: Fix memory leak on uninserted lv references
  31482 0beb60002 disk/cryptodisk: Fix potential integer overflow
  31482 20ddfae56 hfsplus: Check that the volume name length is valid
  31482 d8fa680fe zfs: Fix possible negative shift operation
  31482 1b80d2dde zfs: Fix resource leaks while constructing path
  31482 2b07acad0 zfs: Fix possible integer overflows
  31482 0283863c7 zfsinfo: Correct a check for error allocating memory
  31482 ad663e4ea affs: Fix memory leaks
  31482 8d9e05f24 libgcrypt/mpi: Fix possible unintended sign extension
  31482 3120a6835 libgcrypt/mpi: Fix possible NULL dereference
  31482 6d38008dd syslinux: Fix memory leak while parsing
  31482 06f86bc0d normal/completion: Fix leaking of memory when processing a 
completion
  31482 e31e8ecbc commands/hashsum: Fix a memory leak
  31482 74d544182 video/efi_gop: Remove unnecessary return value of 
grub_video_gop_fill_mode_info()
  31482 e07f13cfa video/fb/fbfill: Fix potential integer overflow
  31482 fffc476df video/fb/video_fb: Fix multiple integer overflows
  31482 786656dc8 video/fb/video_fb: Fix possible integer overflow
  31482 bf3df4eeb video/readers/jpeg: Test for an invalid next marker reference 
from a jpeg file
  31482 f9b9c56e2 gfxmenu/gui_list: Remove code that coverity is flagging as 
dead
  31482 11cf998c2 loader/bsd: Check for NULL arg up-front
  31482 d311599e4 loader/xnu: Fix memory leak
  31482 986de6735 loader/xnu: Free driverkey data when an error is detected in 
grub_xnu_writetree_toheap()
  31482 f851813cd 

Bug#657401: dpkg-buildpackage: support output directory other than ..

[Guillem Jover]

On Mon, 2020-03-15 at 19:26:14 +, Nicholas Brown wrote:
> I could imagine the patch below, which I started looking at some time ago
> but never
> got around to coming back to, could form a start at implementing this.

This is pretty close to what I initially did, and mentioned on my first
reply to the bug.

  


> It was just the obvious paths within the script itself, but the various
> calls to dpkg-source,
> dpkg-genbuildinfo, dpkg-genchanges, that all accept output options, still
> need to be
> modified to pass this new argument.

The actual problem are none of these, but the dpkg-deb calls performed
from within debian/rules, directly or indirectly via debhelper. Where
even if debhelper would handle this as Philipp Hahn suggested, dpkg
could not rely on that as this is a package-specific implementation
detail.

Until and iff dpkg-buildpackage starts handling the dpkg-deb calls by
itself, this bug cannot be solved. I didn't feel like marking as
wontfix because I think the request make sense, it's just that I don't
see how to implement it as things stand right now.

Thanks,
Guillem

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

[Guillem Jover]

On Wed, 2021-03-17 at 12:21:24 -0700, Jonathan Nieder wrote:
> Guillem Jover wrote:
> > The latest version in sid, breaks user code sourcing the git-sh-prompt
> > shell library as it moved from /usr/lib/ to /usr/libexec, even though
> > I see the comment there says to copy it, but that means no automatic
> > upgrades. :/
> >
> > Could you perhaps add a backwards compatibility symlink for the time
> > being? Or when using bash, perhaps even a warning based on the
> > “caller” builtin if using the old pathname?
> 
> Yeah, I don't advocate copying.  Probably we should patch those
> instructions at installation time to recommend sourcing in place
> instead.

That'd be great yes.

> The git-sh-setup(1) manpage recommends
> 
>   . "$(git --exec-path)/git-sh-setup"

Ah! I've adapted my code to use that, thanks!

> but there is no corresponding git-sh-prompt(1) manpage --- yikes.

Having one, eventually, would be nice too.

> Ideas:
> 
>  a. We could add a NEWS.Debian entry to help people see that the path
> changed and recommend using the $(git --exec-path) based incantation

If the move stays, this seems desirable, yes.

>  b. We could move $(git --exec-path) back to /usr/lib/git-core.  After
> all, while the FHS _allows_ libexec nowadays, it does not require
> it.

As Sven has mentioned, given that this breaks other packages, even if
they are doing it wrong, breaking them at this point in the release
might not be ideal.

>  c. As you suggest, we could have a compatibility forwarding script
> that warns to help people update their prompt configuration.
> 
> I think I prefer (a) over (c), and that (b) might be best of all.
> What do you think?

While I like the libexec stuff in general, I think that indeed
(b) > (a) > (c), given the current timing.

Thanks,
Guillem

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

[Guillem Jover]

On Wed, 2021-03-17 at 09:48:35 +0100, Sven Joachim wrote:
> On 2021-03-16 13:47 +0100, Guillem Jover wrote:
> > Could you perhaps add a backwards compatibility symlink for the time
> > being? Or when using bash, perhaps even a warning based on the
> > “caller” builtin if using the old pathname?
> 
> Adding a compatibility symlink seems to be a non-starter with packages
> installing files there.  I think for now the change needs to be
> reverted, and a transition plan worked out if moving git's libexecdir is
> still desired.

Just to clarify, I meant compatibility symlinks for the script, not
for the directory, either that or a wrapper could do too. But if this
is affecting other stuff then reverting might be more prudent now.

Thanks,
Guillem
 

Bug#985424: vorta: "Backup successful" notification even if return code is 1

[Sandro Tosi]

Package: vorta
Version: 0.7.5-1
Severity: normal

Hello,
i have a few unaccessible files, so vorta during the backup records that, and
the backup itself finished with a return code of 1.

but the notification says "backup successful" -- that's rather confusing

- does the return code of the backup not indicate the success or not of the
  backup?
- will the backup end up not being succesful only if a specific list of return
  codes are returned?

Regards,
Sandro

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

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

Versions of packages vorta depends on:
ii  python33.9.2-2
ii  python3-appdirs1.4.3-1
ii  python3-apscheduler3.6.3-1
ii  python3-dateutil   2.7.3-3
ii  python3-paramiko   2.7.1-2
ii  python3-peewee 3.13.1+dfsg-1+b3
ii  python3-pkg-resources  46.1.3-1
ii  python3-psutil 5.7.3-1
ii  python3-pyqt5  5.15.2+dfsg-1+b1
ii  python3-pyqt5.qsci 2.11.6+dfsg-1
ii  python3-secretstorage  2.3.1-2

Versions of packages vorta recommends:
ii  borgbackup  1.1.14-3

vorta suggests no packages.

-- no debconf information

Bug#966373: Please stop reopening bugs that maintainers have closed

[Javier Serrano Polo]

On Wed, 17 Mar 2021 16:12:37 -0700 Don Armstrong 
wrote:
> Please stop reopening bugs which have been closed by Debian
Maintainers.

Please, Don, could you guide me on this matter?
The bug focus has changed, thus I retitled the bug and I thought
wontfix was not valid now. Should I open a new report instead?
What should I do when maintainers are unresponsive or do not explain
their actions?
Should I never reopen a report?

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

Bug#985423: eslint needs to depend on node-text-table (or change default formatter)

[Marco Trevisan]

Package: eslint
Version: 5.16.0~dfsg-8
Severity: serious
Justification: Missing runtime dependency

Dear Maintainer,

Using eslint from repository fails as per missing dependency on
node-text-table that is used by the default formatter (stylish).

When using other formatters everything works fine.

There was a problem loading formatter: ./formatters/stylish
Error: Cannot find module 'text-table'
Require stack:
- /usr/share/nodejs/eslint/lib/formatters/stylish.js
- /usr/share/nodejs/eslint/lib/cli-engine.js
- /usr/share/nodejs/eslint/lib/cli.js
- /usr/share/nodejs/eslint/bin/eslint.js

Bug#985422: syslog-ng-core: fails to capture all systemd-journal entries

[Matthew Pounsett]

Package: syslog-ng-core
Version: 3.19.1-5
Severity: important

Dear Maintainer,

The Debian syslog-ng package is not collecting all systemd-journal messages.  

The use case that caused me to track this down is an inconsistency between the
Debian syslog-ng and rsyslog packages when logging Knot DNS activity (using
the 'knot' package from upstream https://deb.knot-dns.cz/knot-latest/).  

A default install of rsyslog captures Knot's logging activity to 
/var/log/user.log, while a default install of syslog-ng does not capture its
activity at all.  The default syslog-ng configuration should log the same
messages to /var/log/user.log, but it seems syslog-ng doesn't even see the
log messages.

Digging a bit deeper .. journald.conf(5) indicates that syslog messages are
written to /run/systemd/journal/syslog.  I noted that syslog-ng does not
create this socket, while rsyslog does.

There is a comment in syslog.socket which indicates a syslog daemon is
expected to include "Alias=syslog.service" in its [install] section in order
to pull in this dependency.  The rsyslog package does this, but the syslog-ng
package does not.  It seems likely this is related to the issues with
capturing syslog messages.


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

Kernel: Linux 4.19.0-14-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages syslog-ng-core depends on:
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libcurl4   7.64.0-4+deb10u1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libivykis0 0.42.3-1
ii  libjson-c3 0.12.1+ds-2+deb10u1
ii  libnet11.1.6+dfsg-3.1
ii  libpcre3   2:8.39-12
ii  libssl1.1  1.1.1d-0+deb10u5
ii  libsystemd0241-7~deb10u6
ii  libuuid1   2.33.1-0.1
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  syslog-ng-mod-journal  3.19.1-5
ii  util-linux 2.33.1-0.1

Versions of packages syslog-ng-core recommends:
ii  logrotate  3.14.0-4

Versions of packages syslog-ng-core suggests:
ii  syslog-ng-mod-add-contextual-data  3.19.1-5
ii  syslog-ng-mod-amqp 3.19.1-5
ii  syslog-ng-mod-examples 3.19.1-5
ii  syslog-ng-mod-extra3.19.1-5
ii  syslog-ng-mod-geoip3.19.1-5
ii  syslog-ng-mod-geoip2   3.19.1-5
ii  syslog-ng-mod-getent   3.19.1-5
ii  syslog-ng-mod-graphite 3.19.1-5
ii  syslog-ng-mod-map-value-pairs  3.19.1-5
ii  syslog-ng-mod-mongodb  3.19.1-5
ii  syslog-ng-mod-pacctformat  3.19.1-5
ii  syslog-ng-mod-python   3.19.1-5
ii  syslog-ng-mod-redis3.19.1-5
ii  syslog-ng-mod-riemann  3.19.1-5
ii  syslog-ng-mod-smtp 3.19.1-5
ii  syslog-ng-mod-snmptrapd-parser 3.19.1-5
ii  syslog-ng-mod-sql  3.19.1-5
ii  syslog-ng-mod-stardate 3.19.1-5
ii  syslog-ng-mod-stomp3.19.1-5
ii  syslog-ng-mod-tag-parser   3.19.1-5
ii  syslog-ng-mod-xml-parser   3.19.1-5

-- no debconf information

Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

[Guillem Jover]

Control: reassign -1 libreoffice-common 1:7.0.4-3

[ Leaving all context for the reassign. ]

Hi!

On Wed, 2021-03-17 at 12:13:52 +0100, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: block 985297 with -1
> 
>   Preparing to unpack .../0-ure_1%3a7.0.4-3_amd64.deb ...
>   Unpacking ure (1:7.0.4-3) over (6.1.5-3+deb10u7) ...
>   Preparing to unpack .../1-libreoffice-style-colibre_1%3a7.0.4-3_all.deb ...
>   Unpacking libreoffice-style-colibre (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering deconfiguration of libreoffice-writer, which would be 
> broken by installation of libreoffice-core ...
>   dpkg: yes, will deconfigure libreoffice-writer (broken by libreoffice-core)
>   Preparing to unpack .../2-libreoffice-core_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-writer (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...

The libreoffice-core package has finished unpacking. Next, dpkg starts
with libreoffice-common.

>   dpkg: considering removing libreoffice-writer in favour of 
> libreoffice-common ...
> * dpkg: libreoffice-writer is not properly installed; ignoring any 
> dependencies on it ***
> * dpkg: yes, will remove libreoffice-writer in favour of libreoffice-common   
> ***

dpkg detects there's a Conflicts involved during the unpack and queues
it for later removal. (Although that removal is then silent anyway, which
seems confusing, so ideally dpkg should probably print something like we
do with the de-configuring.)

>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> libreoffice-common:all, cannot switch to symlink
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
> (--unpack):
>new libreoffice-common package pre-installation script subprocess returned 
> error exit status 1
>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
> directory
>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory

The libreoffice-common preinst maintainer script fails, so I'd expect
the installation for the package gets aborted and the conflictor does
not get removed after this, and before processing the next archive.

>   Selecting previously unselected package libreoffice-writer.
>   dpkg: considering deconfiguration of libreoffice-common, which would be 
> broken by installation of libreoffice-writer ...
>   dpkg: yes, will deconfigure libreoffice-common (broken by 
> libreoffice-writer)
>   Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ...
>   Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ...
>   Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ...
>   Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb
> 
> So is dpkg going to remove libreoffice-writer or not?

It would if the maintscript would not have failed.

> It says both and does 
> not remove it, causing dpkg-maintscript-helper to fail since
> /usr/lib/libreoffice/share/registry is not empty before dir_to_symlink
> is run. There should be enough Conflicts to ensure all packages previously
> shipping files there are removed or upgraded.

This would be an incorrect assumption from the package, policy
describes how Conflicts interact during upgrades in §6.6. Notice
there the conflictors are only removed in step 13, the last one.

Thanks,
Guillem

Bug#924352: Fixed upstream in 3.2.0

[Alberto Gonzalez Iniesta]

Version: 3.2.0-1

Hi, the fix for this issue [1] was included upstream in 3.2.0.
Closing accordingly. Thanks Moritz for the heads up.


[1] https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1167

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#949973: firmware-realtek: kernel error caught

[maximilian attems]

tags 949973 moreinfo
stop


> Version: 20190114-2

Can you still reproduce with newest testing?


Sorry for the late reply and thank you for your report.


-- 
maks

Bug#942173: firmware-amd-graphics: seg fault with ati picasso grafic card and libqt5 software

[maximilian attems]

tags 942173 moreinfo
stop

> Version: 20190717-2~bpo10+1


This should have seen quite some updates since, is this still
reproducible?

Sorry for the late reply, thank you for your report!

Bug#787080: Bug#894119: libreoffice: Please add libreoffice-online to the debian repository.

[Rene Engelhard]

Hi,

Am 16.03.21 um 22:02 schrieb Adi Kriegisch:
> thank you very much for the hard work you've put in packaging libreoffice
> online. Starting from your salsa repo[1] I was able to successfully build
> loolwsd and loleaflet packages with the libreoffice packages from
> buster-backports. There were, however, some issues with the unit tests.
> After trying to investigate some of the issues, I decided to skip the test
> by adding an empty override_dh_auto_test target.

Yeah, that one is a mess upstream:

- unit tests need debug

- tests need write permissions in the LO directory (which they of course
don't have in /usr/lib/libreoffice)

...


> Is there any reason why you use loolwsd's init script to configure it
> instead of setting the defaults in /etc/loolwsd/loolwsd.xml? With the
> current init script this does not work.

That part wasn't updated for some time, I wouldn't be surprised if it broke.

/etc/default is a well-known location for environment variables needed
by init scripts, though.


That said, for init script I'd stay as close as with upstream as
possible since maintaining an initi script is a PITA.

(People ideally should use systemd and the systemd unit anyway but init
scripts still should be shipped if feasible.)


But MRs (or patches if you don't have an account on salsa) welcome.

> I very much hope, you're going to continue your excellent work and
> libreoffice online hits the debian archive any time in a not too distant
> future! ;-)

If someone sorts out the JS mess and packages the modules (and keeps the
chain uptodate) ;-)

Then we just need to figure out the test mess (maybe not run them during
the build at all indeed and make it a

"needs-root breaks-testbed" autopkgtest. One should probably add a
autopkgtest anyway.)


Regards,


Rene

Bug#947860: release-notes: Sec 4.3 preparing sources.list omits explicit statement of key change

[Paul Gevers]

Hi,

On 17-03-2021 22:10, Paul Gevers wrote:
> I intend to commit the attached patch.

By the way, I noticed that here we're inconsistent. In most other places
we talk about "APT source-list", but here it's "APT's source-list". I
recall we did that latter on purpose in buster. Shall I make it consistent?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#947860: release-notes: Sec 4.3 preparing sources.list omits explicit statement of key change

[Paul Gevers]

Control: tags -1 patch pending

Hi,

On Tue, 31 Dec 2019 13:56:02 -0800 Ted Anderson  wrote:
> Perhaps changing the first sentence of 4.3 to:
> 
> Before starting the upgrade you must reconfigure APT's source-list
> files (/etc/apt/sources.list and files under /etc/apt/sources.list.d/)
> to add sources for stretch  and remove sources for jessie 
> .

I intend to commit the attached patch.

Paul
From fa0a227c1baac8fe08019c3466fcc2349e97e954 Mon Sep 17 00:00:00 2001
From: Ted Anderson 
Date: Wed, 17 Mar 2021 22:07:25 +0100
Subject: [PATCH] upgrading.dbk: clarify further what we're going to start

Closes: #947860
---
 en/upgrading.dbk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 3eeedd9f..7d0865da 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -465,7 +465,9 @@ $ apt-forktracer | sort
   
 Before starting the upgrade you must reconfigure APT's source-list
 files (/etc/apt/sources.list and files under
-/etc/apt/sources.list.d/).
+/etc/apt/sources.list.d/) to add sources for
+ and typically to remove sources
+for .
   
   
 APT will consider all packages that can be found via any configured
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Vincent Blut]

Le 2021-03-17 19:24, Wookey a écrit :
> On 2021-03-17 19:43 +0100, Vincent Blut wrote:
> > Le 2021-03-17 15:49, Wookey a écrit :
> > > On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> > > > Le 2021-01-27 12:57, Wookey a écrit :
> > > > > Version: Please enable ARM CMN-600 power management on arm64
> > > > >
> > > > > This requires CONFIG_ARM_CMN=y
> > > >
> > > > Does it really have to be built-in instead of being provided as a 
> > > > module? Last I
> > > > checked, Fedora and Ubuntu provide it as a module.
> > > 
> > > No it should really be a module. Perf is driven from userspace so you
> > > never need to use it before modules can be loaded.
> > 
> > Agreed.
> 
> > > I see that
> > > CONFIG_THUNDERX2_PMU=y
> > > CONFIG_ARM_SMMU_V3_PMU=y
> > > are also set as builtins. That's probably wrong too.
> > 
> > It seems your arm64 kernel config deviates from the one we provide in 
> > Debian.
> > CONFIG_THUNDERX2_PMU is compiled as a module while CONFIG_ARM_SMMU_V3_PMU is
> > not set, at least in linux 5.10.19-1.
> 
> Hmm. I was looking at the (built, with CONFIG_ARM_CMN=y) sources for
> 5.10.9-1 and the (unbuilt) sources for 5.10.19-1. So yes, slightly
> different and the built version is not up to date any more.
> 
> If we already have CONFIG_THUNDERX2_PMU=m already then that's great
> (Ah yes - that's the upstream default).  Adding
> CONFIG_ARM_SMMU_V3_PMU=m would be good too. Adding it as a module
> should be pretty harmless then at least it's available? I'll set off a
> build now to check it works.

Enabling ARM_SMMU_V3_PMU as a module should be harmless, indeed.

> > > […]
> > 
> > > I also checked the state of the other perf configs with the arm kernel 
> > > team
> > > and got feedback that we have all the ones that should sensibly be set 
> > > set once
> > > CONFIG_ARM_CMN=m
> > > and
> > > CONFIG_THUNDERX2_PMU=m
> > > is added
> > 
> > This means updating the arm64 kernel config to only include ARM_CMN as a 
> > module.
> > To me it is acceptable for Bullseye as this seems uncontroversial, but note 
> > that
> > I can't speak for the kernel team.
> 
> Will you ask them, or should I?

I can send merge requests to enable ARM_CMN and ARM_SMMU_V3_PMU if you wish.

> It seems like prodding someone would be good as this was filed back on 27th
> jan and there have been uploads since, so I guess no-one has noticed till now.

I have been contributing for some time to help the kernel team, but I must admit
I didn't notice this one (and probably many others).

> > > Upstream enables
> > > CONFIG_FSL_IMX8_DDR_PMU=m
> > > by default too. IMX8 hardware is available so we should probably turn 
> > > this on too
>
> > Contrary to Ubuntu, we do not provide support for the i.MX8M SoC family,
> > so enabling this option in the arm64 kernel config is not an option, right?
> 
> Ah OK. I didn't realise IMX8 was not enabled in the debian kernel (A
> subject for a different bug). In that case, no this is not
> appropriate.

I wanted to work on this a few months ago, but sadly I was unable to obtain a
i.MX8 SBC.

> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#985421: Adding DEP8 tests for at package

[Utkarsh Gupta]

Source: at
Version: 3.1.23-1.1
Severity: normal
Tags: patch

Hello,

Since at is missing DEP8 tests, I'd like to add them. I wanted to
propose an MR on salsa but the git history isn't in sync with what's
uploaded to the archive, so asking here.

I've prepared the basic testing script to ensure that there's no
regression. I initially submitted this in Ubuntu but want to get it
merged and uploaded here.

Attaching the debdiff here for your review. Let me know what you think
about this. Can I proceed with the upload?


- u


at-dep8.debdiff
Description: Binary data

Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)

[Justin B Rye]

Paul Gevers wrote:
> On Wed, 10 Jul 2019 13:16:27 +0200 Ansgar Burchardt 
> wrote:
>> For bullseye, the security suite is now named bullseye-security
>> instead of buster/updates and users should adapt their sources.list
>> accordingly when upgrading.
>> 
>> People should probably use something like
>> 
>>   deb http://security.debian.org/debian-security bullseye-security main
>> 
[...]
> 
> Proposed patch attached.

It looks good, but I'd just made a note to myself that we might also
want to mention this in upgrading.dbk where it discusses editing APT
sources.  Hoping to send in some patches tomorrow.

Incidentally, the deb lines in our recipes are all http:// rather than
https://, because this is the first dist-upgrade where users have
started with apt-transport-https already guaranteed available.  We
might want to upgrade them all to https now.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#985420: split.c: add the header file "split.h" for a prototype

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 979f308b1dd871bcf51dc9f7bdda7a752710491d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 17 Mar 2021 20:40:51 +
>Subject: [PATCH] split.c: add the header file "split.h" for a prototype

Signed-off-by: Bjarni Ingi Gislason 
---
 split.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/split.c b/split.c
index 8ca2164..d8eb06d 100644
--- a/split.c
+++ b/split.c
@@ -47,6 +47,7 @@ a fair bit of unused code.
  */
 
 #include "config.h"
+#include "split.h" /* added */
 
 /*
  * split - divide a string into fields, like awk split()
-- 
2.30.2



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

Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables

[wferi]

Moritz Muehlenhoff  writes:

> debdiff looks fine, please upload when you had a chance to test it

The updated packages work fine in our infrastructure.
I uploaded the full source package.
-- 
Thanks,
Feri

Bug#945568: release-notes: Mention isdn4linux removal

[Paul Gevers]

Control: tags -1 patch

Hi,

On Wed, 27 Nov 2019 08:21:52 +0100 Christoph Biedl
 wrote:
> for the Debian 11 (bullseye) release notes, please consider mentioning
> the removal of the i4l subsystem. Something like:
> 
> # isdn4linux support removed
> 
> The Linux kernel no longer provides isdn4linux (i4l) support.
> Subsequently, the related userland packages have been removed from the
> archives.
> 
> Regards,
> 
> Christoph
> 
> PS: In case you want to include that as well, RMs are:
> 
> #945512 RM: isdnutils
> #945513 RM: isdnactivecards
> #945514 RM: drdsl
> #945515 RM: ibod

Attached my intended commit.

Paul
From 5431c28525de9a9c25b8a839e8ba8216cada8331 Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Wed, 17 Mar 2021 21:48:03 +0100
Subject: [PATCH] issues.dbk: removal of isdn4linux

Closes: #945568
---
 en/issues.dbk | 12 
 1 file changed, 12 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 219aa89b..c9c5fbbf 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -113,6 +113,18 @@ information mentioned in .
 migration documentation. 
   
 
+	
+	  
+	The Linux kernel no longer provides
+	isdn4linux (i4l) support.
+	Subsequently, the related userland packages isdnutils, isdnactivecards, drdsl and ibod have been removed from
+	the archives.
+	  
+	
   
 
   
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#932580: Fwd: file(1) now with seccomp support enabled

[Paul Gevers]

Control: tags -1 moreinfo

Hi Christoph,

On Sun, 21 Jul 2019 00:26:07 +0200 Christoph Biedl
 wrote:
> Paul Gevers wrote...
> 
> > In order to not forget this. We should check what happened by the time
> > we release bullseye.
> 
> Thanks for taking care of that. As far as I'm concerned, I'd like to
> revisit the situation in a year from now, in other words: If there is no
> update by the end of July 2020 yet, feel free to gently ping me.

Ping. Should we indeed add something to the release notes?

Paul




OpenPGP_signature
Description: OpenPGP digital signature

Bug#979877: openmpi FTBFS on architecture without java or stage1

[John David Anglin]

Hello,

This change shows what I had to change to get openmpi to build on hppa:

--- /dev/null    2021-03-16 01:11:58.37000 +
+++ libopenmpi-dev.docs.hppa    2021-03-17 13:16:30.268660259 +
@@ -0,0 +1,2 @@
+# No JS docs on hppa.
+# usr/share/doc/openmpi/javadoc-openmpi
--- /dev/null    2021-03-16 01:11:58.37000 +
+++ openmpi-bin.install.hppa    2021-03-17 17:18:26.210268097 +
@@ -0,0 +1,42 @@
+## Configuration files
+etc/openmpi/*
+## Executables
+usr/bin/aggregate_profile
+usr/bin/profile2mat
+usr/bin/ompi-clean
+usr/bin/ompi_info
+usr/bin/ompi-server
+usr/bin/orte-server
+usr/bin/orte-clean
+usr/bin/orted
+usr/bin/orterun
+usr/bin/orte-info
+usr/bin/ortecc
+usr/bin/mpiexec.openmpi
+usr/bin/mpirun.openmpi
+# usr/bin/mpijavac.pl
+## Compiler wrappers (symlinks) and man pages
+usr/bin/mpic++.openmpi
+usr/share/man/man1/mpic++.openmpi.1
+usr/bin/mpicc.openmpi
+usr/share/man/man1/mpicc.openmpi.1
+usr/bin/mpiCC.openmpi
+# NOTE: mpiCC.openmpi.1 is installed as symlink
+usr/bin/mpicxx.openmpi
+usr/share/man/man1/mpicxx.openmpi.1
+usr/bin/mpif77.openmpi
+usr/share/man/man1/mpif77.openmpi.1
+usr/bin/mpif90.openmpi
+usr/share/man/man1/mpif90.openmpi.1
+usr/bin/mpifort.openmpi
+usr/share/man/man1/mpifort.openmpi.1
+usr/bin/opalc++
+usr/share/man/man1/opalc++.1
+usr/bin/opalcc
+usr/share/man/man1/opalcc.1
+## Wrappers and man pages
+usr/bin/opal_wrapper
+usr/share/man/man1/opal_wrapper.1
+# NOTE: There's no man page for opal_wrapper_script (upstream, lintian warning)
+usr/share/man/man1/ompi-server.1
+usr/share/man/man1/orte-info.1
--- rules.save    2021-03-17 13:12:44.916458199 +
+++ rules    2021-03-17 13:13:00.466610226 +
@@ -314,9 +314,3 @@
 
 override_dh_installdocs:
 dh_installdocs --all NEWS README
-    dh_link -p libopenmpi-dev /usr/share/javascript/jquery/jquery.js           
/usr/share/doc/libopenmpi-dev/javadoc-openmpi/jquery/external/jquery/jquery.js
-    dh_link -p libopenmpi-dev /usr/share/javascript/jquery/jquery.js           
/usr/share/doc/libopenmpi-dev/javadoc-openmpi/jquery/jquery-3.5.1.js
-    dh_link -p libopenmpi-dev 
/usr/share/javascript/jquery-ui/themes/base/jquery-ui.css 
/usr/share/doc/libopenmpi-dev/javadoc-openmpi/jquery/jquery-ui.css
-    dh_link -p libopenmpi-dev /usr/share/javascript/jquery-ui/jquery-ui.js     
    
/usr/share/doc/libopenmpi-dev/javadoc-openmpi/jquery/jquery-ui.js
-    dh_link -p libopenmpi-dev 
/usr/share/javascript/jquery-ui/themes/base/jquery-ui.min.css
/usr/share/doc/libopenmpi-dev/javadoc-openmpi/jquery/jquery-ui.min.css
-    dh_link -p libopenmpi-dev /usr/share/javascript/jquery-ui/jquery-ui.min.js 
   
/usr/share/doc/libopenmpi-dev/javadoc-openmpi/jquery/jquery-ui.min.js

We need to avoid installing stuff that isn't built when java is missing.
 
Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#985419: libnov.c: add the header file "libnov.h" for prototypes

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 3e65dc9ae432c8613665a61c3787a402b4a24f81 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 17 Mar 2021 20:27:24 +
>Subject: [PATCH] libnov.c: add the header file "libnov.h" for prototypes

Signed-off-by: Bjarni Ingi Gislason 
---
 libnov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libnov.c b/libnov.c
index d0a3d16..7ec2355 100644
--- a/libnov.c
+++ b/libnov.c
@@ -59,6 +59,7 @@ a fair bit of unused code.
 #include "awksplit.h"
 #include "digest.h"
 #include "hash.h"
+#include "libnov.h"
 #include "newsoverview.h"
 #include "nntp.h"
 #include "split.h"
-- 
2.30.2



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

Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)

[Paul Gevers]

Control: tags -1 patch

Hi,

On Wed, 10 Jul 2019 13:16:27 +0200 Ansgar Burchardt 
wrote:
> For bullseye, the security suite is now named bullseye-security
> instead of buster/updates and users should adapt their sources.list
> accordingly when upgrading.
> 
> People should probably use something like
> 
>   deb http://security.debian.org/debian-security bullseye-security main
> 
> (adding /debian-security was proposed in [1]).
> 
> See [2][3][4] for some more information.
> 
> I should probably also sent a mail to d-d-a@ or so about this in the
> near future...
> 
> Ansgar
> 
>   [1] https://lists.debian.org/debian-devel/2015/12/msg00333.html
>   [2] https://bugs.debian.org/614204
>   [3] https://lists.debian.org/debian-devel/2015/12/msg00254.html
>   [4] https://lists.debian.org/debian-security/2019/06/msg00015.html

Proposed patch attached.

Paul
From 7f7113422f15aae8526521dde0d869e4af343a2f Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Wed, 17 Mar 2021 21:27:50 +0100
Subject: [PATCH] issues.dbk: security archive layout

Closes: #931785
---
 en/issues.dbk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 219aa89b..7e46bf40 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -67,6 +67,21 @@ information mentioned in .
 
   
 
+  
+
+Changed security archive layout
+
+  For bullseye, the security suite is now named
+  bullseye-security instead of
+  buster/updates and users should adapt their
+  APT source-list files accordingly when upgrading.
+
+
+  The security line in your APT configuration may look like:
+  deb https://deb.debian.org/debian-security testing-security main contrib
+
+  
+
   
 Noteworthy obsolete packages
 
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983366: linphone-desktop: Settings popup menu

[Dennis Filder]

On Wed, Mar 17, 2021 at 04:11:56PM -0300, David Pirotte wrote:

> > QT_QPA_PLATFORMTHEME=qt5ct linphone
>
> That does not solve the problem, fwiw.
>
> > GDK_BACKEND=x11 linphone
>
> That solves the problem.

Ideally Qt would detect that the platform theme needs that backend and
perform the configuration automatically, but apparently that is not
yet implemented.

I cleaned your output up a bit and diffed it with "diff -U0 debian.env
appimage.env" which gives:

--- debian.env  2021-03-17 20:34:13.187385487 +0100
+++ appimage.env2021-03-17 20:41:24.519376882 +0100
@@ -1,0 +2,3 @@
+APPDIR=/tmp/.mount_LinphoATI0bC
+APPIMAGE=/opt/linphone/bin/Linphone-4.2.5.AppImage
+ARGV0=./Linphone-4.2.5.AppImage
@@ -8 +10,0 @@
-GDK_BACKEND=x11
@@ -31,0 +34 @@
+OWD=/opt/linphone/bin
@@ -38,2 +40,0 @@
-PS1=\u@\h:\w \# $
-PS2=>
@@ -42,0 +44 @@
+QT_QPA_PLATFORMTHEME=gtk2
@@ -45 +47 @@
-SHLVL=1
+SHLVL=2
@@ -53 +54,0 @@
-_=/usr/bin/linphone

This tells us that the appimage uses the GTK2 platform theme.  You
could install the package qt5-gtk2-platformtheme and invoke linphone
like so:

   GDK_BACKEND=x11 QT_QPA_PLATFORMTHEME=gtk2 linphone

Then it should look and behave almost identical to the appimage
variant.

> Although, fwiw, (a) the window 'shape is different (the AppImage has
> square corners - the debian window rounded corners, and (b) the font
> family and font size are diff as well (musch smaller for the debian
> version... no problem at all, big deal, just mentioning ...

Any other differences will probably be due to missing fonts which
you'd have to install/copy over from the appimage, though I can't find
any font files on the appimage.  If you find a way to make it look
like the appimage, tell us how, so we can maybe tune the defaults.

Regards,
Dennis

Bug#984831: bugs.debian.org: should not emit semicolon as query param separator

[Adam D. Barratt]

On Mon, 2021-03-08 at 20:42 +, Phil Morrell wrote:
> As reported on #debian-til, python can no longer parse bugs.d.o URLs
> correctly out of the box. The change was backported as a security
> update
> to 3.6+ so also affects buster.

fwiw, that seems to be a non-sequitur. Yes, it's been backported
upstream, but there's been no corresponding upload to buster of any
Python version that incorporates the change that I can see.

Regards,

Adam

Bug#985417: hdbm.c: add an attribute for a fall through in case statements

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 627ef28748d3ff1c9edfd92d7bfb3a314edd0e62 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 17 Mar 2021 19:53:36 +
>Subject: [PATCH] hdbm.c: add an attribute for a fall through in case
> statements

Signed-off-by: Bjarni Ingi Gislason 
---
 hdbm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hdbm.c b/hdbm.c
index 1b47644..b5bbf22 100644
--- a/hdbm.c
+++ b/hdbm.c
@@ -91,18 +91,25 @@ hdbmdef(register HDBMDATUM key)
case 0:
do {/* All fall throughs */
HASHC;
+   __attribute__ ((fallthrough));
case 7:
HASHC;
+   __attribute__ ((fallthrough));
case 6:
HASHC;
+   __attribute__ ((fallthrough));
case 5:
HASHC;
+   __attribute__ ((fallthrough));
case 4:
HASHC;
+   __attribute__ ((fallthrough));
case 3:
HASHC;
+   __attribute__ ((fallthrough));
case 2:
HASHC;
+   __attribute__ ((fallthrough));
case 1:
HASHC;
} while (--loop);
-- 
2.30.2



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

Kernel: Linux 5.10.19-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985418: libgtk-4-bin,libgtk-4-1: broken symlink: /usr/share/doc/libgtk-4-{bin,1}/NEWS -> ../libgtk-4-common/NEWS

[Andreas Beckmann]

Package: libgtk-4-bin,libgtk-4-1
Version: 4.0.3-4
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libgtk-4-common

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m28.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libgtk-4-bin/NEWS -> ../libgtk-4-common/NEWS (libgtk-4-bin)
  /usr/share/doc/libgtk-4-1/NEWS -> ../libgtk-4-common/NEWS (libgtk-4-1:amd64)

There is only /usr/share/doc/libgtk-4-common/NEWS.gz


cheers,

Andreas


libgtk-4-common_4.0.3-4.log.gz
Description: application/gzip

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

[Jonathan Nieder]

clone 985351 -1
retitle -1 changing gitexecdir breaks packages that install commands there
severity -1 serious
quit

Hi,

Sven Joachim wrote:

> It also breaks various add-on packages installing files into
> /usr/lib/git-core, as seen in the gitbrute autopkgtest[1]:
>
> ,
> | git: 'brute' is not a git command. See 'git --help'.
> `

This seems like a different issue from the one Guillem reported,
though it has the same proximate cause.

> The following packages install one or more files below /usr/lib/git-core
> and are likely broken now:
>
> ,
> | $ apt-file search /usr/lib/git-core | cut -d : -f1 | sort -u
> | brz
> | git-absorb
> | git-crecord
> | git-flow
> | git-quick-stats
> | git-restore-mtime
> | gitbrute
> | imediff
> `

I suspect these should install to /usr/bin/ instead.  The exact
location where git stores its commands is an implementation detail
that packages are not meant to rely on.

Thanks,
Jonathan

Bug#985115: buster-pu: package iputils/3:20180629-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-03-12 at 15:13 -0800, Noah Meyerhans wrote:
> I'd like to update iputils in buster to address important bugs in the
> iputils-ping and iputils-tracepath binary packages:
> 
> * #976277: iputils-tracepath: destination address of ipv6 probes is
> cut
>   off after the first 64 bits.  This basically makes tracepath
> useless for
>   IPv6.
> 
> * #920434: ping does not round correctly.  This causing ping to
> report
>   incorrect timing results in some cases.
> 

Please go ahead.

Regards,

Adam

Bug#984896: buster-pu: package jquery/3.3.1~dfsg-3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-03-09 at 18:08 -0500, Roberto C. Sanchez wrote:
> I would like to fix CVE-2020-11022 and CVE-2020-11023.  The same fix
> has
> been prepared for stretch and will be uploaded concurrently with the
> buster fix.  The security team has marked these issues as no-dsa.
> 

Please go ahead.

Regards,

Adam

Bug#985375: vmdb2: add option to 'apt' step for not installing recommends

[Gunnar Wolf]

tags -1 + pending,patch
thanks

I have submitted a merge request to the upstream author. I have _not_
yet tested this -- So, Andres, if you can try my proposed patch,
everybody will be happier ;-)

https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/73/diffs

diff --git a/vmdb/plugins/apt.mdwn b/vmdb/plugins/apt.mdwn
index a05922a..e66454c 100644
--- a/vmdb/plugins/apt.mdwn
+++ b/vmdb/plugins/apt.mdwn
@@ -12,6 +12,10 @@ Step keys:
 
 * `packages`  REQUIRED; value is a list of packages to install.
 
+* `recommends`  OPTIONAL; defaults to true. Setting value to a
+  false (i.e. `0`, `null`, `false`) asks apt-get to run with the
+  `--no-install-recommends` option set.
+
 Example (in the .vmdb file):
 
 - apt: install
diff --git a/vmdb/plugins/apt_plugin.py b/vmdb/plugins/apt_plugin.py
index 09b8902..5f11855 100644
--- a/vmdb/plugins/apt_plugin.py
+++ b/vmdb/plugins/apt_plugin.py
@@ -28,7 +28,7 @@ class AptPlugin(vmdb.Plugin):
 
 class AptStepRunner(vmdb.StepRunnerInterface):
 def get_key_spec(self):
-return {"apt": str, "packages": [], "tag": "", "fs-tag": "", "clean": 
True}
+return {"apt": str, "packages": [], "tag": "", "fs-tag": "", "clean": 
True, "recommends": True}
 
 def run(self, values, settings, state):
 operation = values["apt"]
@@ -36,15 +36,16 @@ class AptStepRunner(vmdb.StepRunnerInterface):
 raise Exception('"apt" must always have value "install"')
 
 packages = values["packages"]
+recommends = values["recommends"]
 tag = values.get("tag") or None
 if tag is None:
 tag = values["fs-tag"]
 mount_point = state.tags.get_builder_mount_point(tag)
 
 if not self.got_eatmydata(state):
-self.install_packages(mount_point, [], ["eatmydata"])
+self.install_packages(mount_point, [], recommends, ["eatmydata"])
 state.got_eatmydata = True
-self.install_packages(mount_point, ["eatmydata"], packages)
+self.install_packages(mount_point, ["eatmydata"], recommends, packages)
 
 if values["clean"]:
 self.clean_cache(mount_point)
@@ -52,15 +53,19 @@ class AptStepRunner(vmdb.StepRunnerInterface):
 def got_eatmydata(self, state):
 return hasattr(state, "got_eatmydata") and getattr(state, 
"got_eatmydata")
 
-def install_packages(self, mount_point, argv_prefix, packages):
+def install_packages(self, mount_point, argv_prefix, recommends, packages):
 env = os.environ.copy()
 env["DEBIAN_FRONTEND"] = "noninteractive"
 
 vmdb.runcmd_chroot(mount_point, argv_prefix + ["apt-get", "update"], 
env=env)
 
+rec = ''
+if recommends:
+rec = '--no-install-recommends'
+
 vmdb.runcmd_chroot(
 mount_point,
-argv_prefix + ["apt-get", "-y", "--no-show-progress", "install"] + 
packages,
+argv_prefix + ["apt-get", "-y", "--no-show-progress", rec, 
"install"] + packages,
 env=env,
 )
 

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Wookey]

On 2021-03-17 19:43 +0100, Vincent Blut wrote:
> Le 2021-03-17 15:49, Wookey a écrit :
> > On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> > > Le 2021-01-27 12:57, Wookey a écrit :
> > > > Version: Please enable ARM CMN-600 power management on arm64
> > > >
> > > > This requires CONFIG_ARM_CMN=y
> > >
> > > Does it really have to be built-in instead of being provided as a module? 
> > > Last I
> > > checked, Fedora and Ubuntu provide it as a module.
> > 
> > No it should really be a module. Perf is driven from userspace so you
> > never need to use it before modules can be loaded.
> 
> Agreed.

> > I see that
> > CONFIG_THUNDERX2_PMU=y
> > CONFIG_ARM_SMMU_V3_PMU=y
> > are also set as builtins. That's probably wrong too.
> 
> It seems your arm64 kernel config deviates from the one we provide in Debian.
> CONFIG_THUNDERX2_PMU is compiled as a module while CONFIG_ARM_SMMU_V3_PMU is
> not set, at least in linux 5.10.19-1.

Hmm. I was looking at the (built, with CONFIG_ARM_CMN=y) sources for
5.10.9-1 and the (unbuilt) sources for 5.10.19-1. So yes, slightly
different and the built version is not up to date any more.

If we already have CONFIG_THUNDERX2_PMU=m already then that's great
(Ah yes - that's the upstream default).  Adding
CONFIG_ARM_SMMU_V3_PMU=m would be good too. Adding it as a module
should be pretty harmless then at least it's available? I'll set off a
build now to check it works.

> > […]
> 
> > I also checked the state of the other perf configs with the arm kernel team
> > and got feedback that we have all the ones that should sensibly be set set 
> > once
> > CONFIG_ARM_CMN=m
> > and
> > CONFIG_THUNDERX2_PMU=m
> > is added
> 
> This means updating the arm64 kernel config to only include ARM_CMN as a 
> module.
> To me it is acceptable for Bullseye as this seems uncontroversial, but note 
> that
> I can't speak for the kernel team.

Will you ask them, or should I? 

It seems like prodding someone would be good as this was filed back on 27th
jan and there have been uploads since, so I guess no-one has noticed till now.

> > Upstream enables
> > CONFIG_FSL_IMX8_DDR_PMU=m
> > by default too. IMX8 hardware is available so we should probably turn this 
> > on too
> 
> Contrary to Ubuntu, we do not provide support for the i.MX8M SoC family,
> so enabling this option in the arm64 kernel config is not an option, right?

Ah OK. I didn't realise IMX8 was not enabled in the debian kernel (A
subject for a different bug). In that case, no this is not
appropriate.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

[Jonathan Nieder]

Hi!

Guillem Jover wrote:

> The latest version in sid, breaks user code sourcing the git-sh-prompt
> shell library as it moved from /usr/lib/ to /usr/libexec, even though
> I see the comment there says to copy it, but that means no automatic
> upgrades. :/
>
> Could you perhaps add a backwards compatibility symlink for the time
> being? Or when using bash, perhaps even a warning based on the
> “caller” builtin if using the old pathname?

Yeah, I don't advocate copying.  Probably we should patch those
instructions at installation time to recommend sourcing in place
instead.

The git-sh-setup(1) manpage recommends

. "$(git --exec-path)/git-sh-setup"

but there is no corresponding git-sh-prompt(1) manpage --- yikes.
Ideas:

 a. We could add a NEWS.Debian entry to help people see that the path
changed and recommend using the $(git --exec-path) based incantation

 b. We could move $(git --exec-path) back to /usr/lib/git-core.  After
all, while the FHS _allows_ libexec nowadays, it does not require
it.

 c. As you suggest, we could have a compatibility forwarding script
that warns to help people update their prompt configuration.

I think I prefer (a) over (c), and that (b) might be best of all.
What do you think?

Thanks,
Jonathan

Bug#983526: buster-pu: package python-django/1:1.11.29-1+deb10u1

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Feb 25, 2021 at 04:42:55PM +, Chris Lamb wrote:
> Please consider python-django (1:1.11.29-1+deb10u1) for buster:
>   
>   python-django (1:1.11.29-1+deb10u1) buster; urgency=high
>   .
> * CVE-2021-23336: Prevent a web cache poisoning attack via "parameter
>   cloaking". Django contains a copy of urllib.parse.parse_qsl() which was
>   added to backport some security fixes. A further security fix has been
>   issued recently such that parse_qsl() no longer allows using ";" as a
>   query parameter separator by default. (Closes: #983090)
>   .
>   For more information, please see:
>   .
> https://www.djangoproject.com/weblog/2021/feb/19/security-releases/
> 
Hi Chris,

I'm not convinced the regression risk here, of changing the longstanding
behaviour, is worth it.  People using a caching reverse proxy with a
different config wrt query strings can just as well fix the issue on
that end.

Cheers,
Julien

Bug#983366: linphone-desktop: Settings popup menu

[David Pirotte]

Hello Dennis,

> GDK_BACKEND=x11 linphone

That solves the problem.

Although, fwiw, (a) the window 'shape is different (the AppImage has
square corners - the debian window rounded corners, and (b) the font
family and font size are diff as well (musch smaller for the debian
version... no problem at all, big deal, just mentioning ...

> QT_QPA_PLATFORMTHEME=qt5ct linphone

That does not solve the problem, fwiw.

David
 
> If that doesn't fix it you need to compare the output of the above
> command to the output of the same command with the appimage linphone
> running.  Also you should compare for both versions the output of
> 
> tr '\0' '\n' < /proc/$(pidof linphone)/environ | \
> grep -v '^[[:space:]]\+'|sort
> 
> Provide the outputs if you want me to take a look.

Here is the AppImage output:

david@aicha:~ 7 $ tr '\0' '\n' < /proc/$(pidof AppRun.wrapped)/environ | grep 
-v '^[[:space:]]\+'|sort
ACLOCAL_FLAGS=-I /opt2/share/aclocal -I /opt/share/aclocal
APPDIR=/tmp/.mount_LinphoATI0bC
APPIMAGE=/opt/linphone/bin/Linphone-4.2.5.AppImage
ARGV0=./Linphone-4.2.5.AppImage
COLORTERM=truecolor
CVSROOT=rcvs:/usr/alto/cvs
CVS_RSH=ssh
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/500/bus
DESKTOP_SESSION=gnome
DISPLAY=:0
GDM_LANG=en_US.UTF-8
GDMSESSION=gnome
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
GNOME_SETUP_DISPLAY=:1
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/15ee8f1e_2b8f_4a4f_ad4d_24482e79bef5
GNOME_TERMINAL_SERVICE=:1.106
GTK_MODULES=gail:atk-bridge
GUILE_WARN_DEPRECATED=detailed
HOME=/home/david
IM_CONFIG_CHECK_ENV=1
IM_CONFIG_PHASE=1
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_MEASUREMENT=en_US.utf8
LC_MONETARY=en_US.utf8
LC_NUMERIC=en_US.utf8
LC_PAPER=en_US.utf8
LC_TIME=en_US.utf8
LOGNAME=david
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
LSHOST=139.82.89.222
MANPATH=/opt/share/man:/opt/toxic/share/man:/usr/man:/usr/share/man:/usr/X11R6/man
OLDPWD=/opt/linphone
OWD=/opt/linphone/bin
PATH=/home/david/bin:/opt2/bin:/opt/bin:/opt/vigra/bin:/opt/linphone/bin:/opt/utox/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/alto/bin:/usr/lpdi/bin:/usr/dema/bin:/usr/tfases/bin:/usr/cmh/bin
PGCLIENTENCODING=UNICODE
PGDATA=/usr/local/pgsql/data
PGDATESTYLE=German
PGLIB=/usr/local/pgsql/lib
PKG_CONFIG_PATH=/opt2/lib/pkgconfig:/opt/lib/pkgconfig:/usr/lib/pkgconfig
PWD=/opt/linphone/bin
QT_ACCESSIBILITY=1
QT_IM_MODULE=ibus
QT_QPA_PLATFORMTHEME=gtk2
SESSION_MANAGER=local/aicha:@/tmp/.ICE-unix/1751,unix/aicha:/tmp/.ICE-unix/1751
SHELL=/bin/bash
SHLVL=2
SSH_AGENT_LAUNCHER=openssh
SSH_AUTH_SOCK=/run/user/500/keyring/ssh
TC51_HOME=/usr/local/Thermo-Calc/2015b
TERM=xterm-256color
TEXINPUTS=:./:/usr/alto/tex/styles:/usr/alto/tex/logos:/usr/lpdi/tex/styles/ThesisPUC:/usr/lpdi/tex/styles:/usr/lpdi/tex/logos:/usr/tpalm/tex/styles:/usr/tpalm/tex/logos:/usr/tpalm/projects/tactus/winterp/donnees:/usr/tpalm/projects/tactus/manuals:/usr/tpalm/projects/tactus/screenshots:/usr/local/share/guile/alto/help/images:./:/usr/alto/tex/styles:/usr/alto/tex/logos:/usr/lpdi/tex/styles/ThesisPUC:/usr/lpdi/tex/styles:/usr/lpdi/tex/logos:/usr/tpalm/tex/styles:/usr/tpalm/tex/logos:/usr/tpalm/projects/tactus/winterp/donnees:/usr/tpalm/projects/tactus/manuals:/usr/tpalm/projects/tactus/screenshots:/usr/local/share/guile/alto/help/images
USER=david
USERNAME=david
VTE_VERSION=6203
WAYLAND_DISPLAY=wayland-0
XAUTHORITY=/run/user/500/.mutter-Xwaylandauth.GUFUZ0
XDG_CURRENT_DESKTOP=GNOME
XDG_MENU_PREFIX=gnome-
XDG_RUNTIME_DIR=/run/user/500
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=gnome

Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables

[Moritz Muehlenhoff]

On Wed, Mar 17, 2021 at 06:19:07PM +0100, wf...@niif.hu wrote:
> Dear Security Team,
> 
> Please review the debdiff below for a buster-security upload.
> The advisory text changed a little meanwhile, adding credits to Toni
> Huttunen, Fraktal Oy for discovering the problem, mentioning the style
> sheet spoofing and adding some mitigation tips.
> 
> I haven't got a concrete exploit on hand, but I'll start testing the
> updated package shortly.

debdiff looks fine, please upload when you had a chance to test it
(and remember to build with -sa, since shib-sp is new in buster-security,
ftp-master and security-master don't share tarballs)

Cheers,
Moritz

Bug#985397: /usr/share/texlive/texmf-dist/tex/latex/tikzposter/tikzposter.cls: tikzposter.cls: licensed under non-existing version 2.0 of LPPL

[Hilmar Preuße]

Am 17.03.2021 um 11:15 teilte Braun Gábor mit:

Hi,


File: /usr/share/texlive/texmf-dist/tex/latex/tikzposter/tikzposter.cls

Dear Maintainer,

Here is a snippet of the beginning of
  /usr/share/texlive/texmf-dist/tex/latex/tikzposter/tikzposter.cls
containing the license information:

We don't care about upstream bugs, b/c of missing man power. Please be 
so kind to report directly to the authors of tikzposter.


Thanks,
  Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983110: buster-pu: package ipmitool/1.8.18-6 (CVE-2020-5208)

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-02-20 at 22:43 +0100, Thomas Goirand wrote:
> On 2/19/21 8:38 PM, Salvatore Bonaccorso wrote:
> > Thanks for preparing this update! For the buster update, please
> > adjust
> > the target distribution to 'buster'.
> > 
> > Regards,
> > Salvatore
> 
> Sure. I just attached the debdiff that I prepared for buster-
> security,
> without rebuilding. I'll rebuild accordingly when I get the go-head
> from
> Adam or Julien.

Please go ahead (with the distribution changed as noted).

Regards,

Adam

Bug#984854: fixed in seqsero 1.0.1+dfsg-3

[Nilesh Patra]

Pinging the bug in case the autoremoval warning causes a problem

Bug#983527: buster-pu: package redis/5:5.0.3-4+deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-02-25 at 17:50 +, Chris Lamb wrote:
>   redis (5:5.0.3-4+deb10u3) buster; urgency=medium
>   .
> * CVE-2021-21309: Fix a series of integer overflow issues on 32-
> bit systems.
>   (Closes: #983446)
> 

Please go ahead.

Regards,

Adam

Bug#985415: smartmontools: Please add Multi-Arch: foreign

[Elrond]

Package: smartmontools
Version: 7.2-1
Severity: wishlist
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch


Hi,

It looks like smartmontools offers an architecture
independent (process/cli level) interface to its users.
Would you mind setting it to Multi-Arch: foreign?
It's usually a matter of adding one line to debian/control.

This would improve install options for different
architectures.  Like for example using the x32 variant on a
mixed amd64/x32 system.


Cheers

Elrond

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Vincent Blut]

Le 2021-03-17 15:49, Wookey a écrit :
> On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> > Control: tags -1 moreinfo
> >
> > Hi Wookey,
> >
> > Le 2021-01-27 12:57, Wookey a écrit :
> > > Source: linux
> > > Version: Please enable ARM CMN-600 power management on arm64
> > > Severity: normal
> > > Tags: patch
> > >
> > > Current arm hardware such as graviton2 (AWS arm64 hardware) has
> > > 'Coherent Mesh Network' interconnect (between components in a
> > > soc). It's important that support for this is built in the kernel so
> > > it can be used.
> > >
> > > This requires CONFIG_ARM_CMN=y
> >
> > Does it really have to be built-in instead of being provided as a module? 
> > Last I
> > checked, Fedora and Ubuntu provide it as a module.
> 
> No it should really be a module. Perf is driven from userspace so you
> never need to use it before modules can be loaded.

Agreed.

> I just did it like this because the other settings here are set as
> built-ins too and this seemed less disruptive. (If we make it a module
> we'll need to make sure it gets included in the right module package -
> I'm not sure if that need tweaking somewhere else in the build system)
> 
> I see that
> CONFIG_THUNDERX2_PMU=y
> CONFIG_ARM_SMMU_V3_PMU=y
> are also set as builtins. That's probably wrong too.

It seems your arm64 kernel config deviates from the one we provide in Debian.
CONFIG_THUNDERX2_PMU is compiled as a module while CONFIG_ARM_SMMU_V3_PMU is
not set, at least in linux 5.10.19-1.

> […]

> I also checked the state of the other perf configs with the arm kernel team
> and got feedback that we have all the ones that should sensibly be set set 
> once
> CONFIG_ARM_CMN=m
> and
> CONFIG_THUNDERX2_PMU=m
> is added

This means updating the arm64 kernel config to only include ARM_CMN as a module.
To me it is acceptable for Bullseye as this seems uncontroversial, but note that
I can't speak for the kernel team.

> Upstream enables
> CONFIG_FSL_IMX8_DDR_PMU=m
> by default too. IMX8 hardware is available so we should probably turn this on 
> too

Contrary to Ubuntu, we do not provide support for the i.MX8M SoC family,
so enabling this option in the arm64 kernel config is not an option, right?


signature.asc
Description: PGP signature

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Samuel Thibault]

Paul Gevers, le mer. 17 mars 2021 19:38:16 +0100, a ecrit:
> > "apt upgrade --without-new-pkgs"
> 
> Looking into history, I see we did this because of
> https://bugs.debian.org/931637. I guess your suggestion is a better
> alternative?

It would probably fill both the objective of upgrading without new
packages, and letting users have a progression bar, yes.

Samuel

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Paul Gevers]

Hi Samuel

On 16-03-2021 22:17, Samuel Thibault wrote:
> Paul Gevers, le mar. 16 mars 2021 22:08:51 +0100, a ecrit:
>>  wrote:
>>> So we'd rather make release-notes document using apt instead of
>>> apt-get? I'm fine with that but we *ALSO* need to make sure that debian
>>> developers actually *test* that path, and not the apt-get path.
>>
>> Already the buster release notes talk about using apt instead of apt-get
> 
> Mmm, actually no, it tells to use "apt-get upgrade"
> 
> https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade
> 
> Possibly this should be turned to 
> 
> "apt upgrade --without-new-pkgs"
> 
> ?

Looking into history, I see we did this because of
https://bugs.debian.org/931637. I guess your suggestion is a better
alternative?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983841: buster-pu: package libvirt-php/0.5.4-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2021-03-02 at 08:47 +0100, Ondřej Surý wrote:
> [ Reason ]
> The package update fixes segmentation fault caused by incomplete PHP
> 7.3 support
> in the upstream package.
> 
> [ Impact ]
> The PHP crashes when calling libvirt_node_get_cpu_stats (See #982804)

The metadata for that bug implies that it affects the package in
unstable, and is not yet fixed there. Is that correct?

Regards,

Adam

Bug#985414: Connman fails to overwrite /etc/resolv.conf

[Paweł Starzyński]

Package: connman
Version: 1.36-2.1~deb10u1
Severity: important

Dear Maintainer,

Recently I've made minimal install of Debian. Due to limited resources, I
decided to try connman + iwd, despite the fact, that I experienced the same
problem earlier on.

What is happening?- PC can't connect to any other network than the one used
during install.

At first I thought that it can be caused by early state of development of
iwd package in Buster. But it turned out that the problem persists with
wpasupplicant.

I found that I'm obtaing ip, but not dns name. My /etc/resolv.conf wasn't
changed by connman and sticked to ip of gateway used during install.

After some more effort, as last resort I decided to delete file
/etc/resolv.conf, hoping that network manager will create it anew with
proper setup.

This happened indeed and solved the issue, but it definitely isn't nice
welcome to Debian with connman .


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

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

Versions of packages connman depends on:
ii  dbus  1.12.20-0+deb10u1
ii  iptables  1.8.2-4
ii  libc6 2.28-10
ii  libdbus-1-3   1.12.20-0+deb10u1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgnutls30   3.6.7-4+deb10u6
ii  libreadline7  7.0-5
ii  libxtables12  1.8.2-4
ii  lsb-base  10.2019051400

Versions of packages connman recommends:
ii  bluez  5.50-1.2~deb10u1
ii  iwd0.14-2
ii  ofono  1.21-1

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#985413: unblock: xdffileio/0.3-4

[Étienne Mollier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package xdffileio

[ Reason ]
xdffileio 0.3-3 in Testing is affected by #985290, which is
fixed by version 0.3-4 in Sid.

[ Impact ]
Removal of xdffileio from Testing would reduce functionalities
of eegdev libraries by rendering the eegdev-plugins-free package
uninstallable in Bullseye.

[ Tests ]
I ran passes of piuparts against all binary packages of
xdffileio in order to make sure the package upgrades properly
from Buster version 0.3-2.1, and upgrades properly from Testing
version 0.3-3.  The package went through the recommended Salsa
CI pipeline successfully.

[ Risks ]
The change fixing upgrade issues seems minor to me.  The only
reverse dependency, eegdev-plugin-free, depends on libxdffileio0
which should not be affected by the change.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing

[ Other info ]
No peculiarities were noted.

unblock xdffileio/0.3-4

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/7, please excuse my verbosity.
diff -Nru xdffileio-0.3/debian/changelog xdffileio-0.3/debian/changelog
--- xdffileio-0.3/debian/changelog  2020-12-19 19:14:04.0 +0100
+++ xdffileio-0.3/debian/changelog  2021-03-17 13:51:56.0 +0100
@@ -1,3 +1,12 @@
+xdffileio (0.3-4) unstable; urgency=medium
+
+  * Team upload.
+  * Add d/libxdffileio-dev.maintscript to move /usr/share/doc/libxdffileio-dev
+from symbolic link toward libxdffileio0, to a separate directory.
+Closes: #985290
+
+ -- Étienne Mollier   Wed, 17 Mar 2021 13:51:56 
+0100
+
 xdffileio (0.3-3) unstable; urgency=medium
 
   [ Andreas Tille ]
diff -Nru xdffileio-0.3/debian/libxdffileio-dev.maintscript 
xdffileio-0.3/debian/libxdffileio-dev.maintscript
--- xdffileio-0.3/debian/libxdffileio-dev.maintscript   1970-01-01 
01:00:00.0 +0100
+++ xdffileio-0.3/debian/libxdffileio-dev.maintscript   2021-03-17 
13:51:53.0 +0100
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/libxdffileio-dev libxdffileio0 0.3-4~


signature.asc
Description: PGP signature

Bug#985410: bioawk FTCBFS -- execute maketab during build

[Helmut Grohne]

Hi Nilesh,

On Wed, Mar 17, 2021 at 10:31:37PM +0530, Nilesh Patra wrote:
> +--- a/Makefile
>  b/Makefile
> +@@ -53,7 +53,7 @@
> + ./maketab >proctab.c
> + 
> + maketab:ytab.h maketab.c
> +-$(CC) $(CFLAGS) $(CPPFLAGS) maketab.c -o maketab $(LDFLAGS)
> ++$(CC_FOR_BUILD) $(CFLAGS) $(CPPFLAGS) maketab.c -o maketab $(LDFLAGS)

This change breaks the upstream build as CC_FOR_BUILD is never
initialized. You should add

CC_FOR_BUILD ?= $(CC)

to make the patch upstreamable.

Helmut

Bug#985343: libvigraimpex-doc: unhandled symlink to directory conversion: /usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html

[Andreas Metzler]

On 2021-03-16 Andreas Beckmann  wrote:
> Package: libvigraimpex-doc
> Version: 1.11.1+dfsg-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts

> Hi,

> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.
[...]


We have

ametzler@argenau:~/GIT/writing/vigra-debian$ head -n5 
debian/libvigraimpex-doc.maintscript
# 1.11.1+dfsg-2 shipped the symlink, -3 did not.
symlink_to_dir /usr/share/doc/libvigraimpex-dev/html 
/usr/share/doc/libvigraimpex-doc/html 1.11.1+dfsg-3~ libvigraimpex-doc

while old libvigraimpex-doc has:

ametzler@argenau:~/GIT/writing/vigra-debian$ dpkg --contents 
/tmp/libvigraimpex-doc_1.11.1+dfsg-2_all.deb | grep 
/usr/share/doc/libvigraimpex-dev/html
lrwxrwxrwx root/root 0 2019-03-10 20:07 
./usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html

This used to work. It tested this when doing the switch. Now it looks
like I have to use
# 1.11.1+dfsg-2 shipped the symlink, -3 did not.
symlink_to_dir /usr/share/doc/libvigraimpex-dev/html ../libvigraimpex-doc/html 
1.11.1+dfsg-3~ libvigraimpex-doc

But /usr/share/doc/libvigraimpex-doc/html and 
/usr/share/doc/libvigraimpex-dev/../libvigraimpex-doc/html

Earlier versions of dpkg-maintscript-helper(1) worked with the
debian/libvigraimpex-doc.maintscript we have (verified with dpkg 1.19.7).

cu Andreas

Bug#981190: sudo-ldap: Users files sudoers nopasswd stop working after update to 1.8.27-1+deb10u3

[Dennis Filder]

Control: tag -1 unreproducible moreinfo

I tried looking into this, but I can only reproduce this by changing
the line

sudoers:files ldap

in /etc/nsswitch.conf to

sudoers:ldap

This makes /etc/sudoers ineffective, but that's not a bug.

On Wed, Jan 27, 2021 at 02:13:21PM +0100, Eric Brun wrote:

> I done an update from 1.8.27-1+deb10u2 to 1.8.27-1+deb10u3
> so my user nagios sudoers declared in /etc/sudoers stop access
> I try to downgrade to 1.8.27-1+deb10u2 but not change.
> I tried on some others server. When I update this package then
> nagios user can't do what it can do before.
>
> In the /var/log/auth.log :
>
> pam_unix(sudo:auth): conversation failed
> sudo: pam_unix(sudo:auth): auth could not identify password for [nagios]
> sudo: pam_ldap(sudo:auth): failed to get password: Authentication failure

I must say that what you present here is very strange, esp. that a
downgrade does not restore the previous working state, but you don't
give us very much to work with.  If you want us to keep looking into
this you have to give more information.

These error messages indicate that sudo tries to resort to using PAMs
to ask for a password which only works when connected to a terminal.
It would be more helpful to show what happens when you call it
interactively.

> -- Configuration Files:
> /etc/sudoers changed:
> Defaults  env_reset
> Defaults  mail_badpass
> Defaults  
> secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
> root  ALL=(ALL:ALL) ALL
> nagiosALL=(ALL) NOPASSWD: /usr/sbin/smartctl,/usr/lib/nagios/plugins/
> %sudo ALL=(ALL:ALL) ALL

This is missing the #inludedir entry for /etc/sudoers.d/.  Is that
intentional?  Why are you using /etc/sudoers with sudo-ldap anyway?
As a fallback mechanism?

Please add the following lines to /etc/sudo-ldap.conf:

sudoers_debug 2
debug 13

Then provide us with the output of these commands (the first one must
run as root):

su -s /bin/sh - nagios -c "sudo /usr/sbin/smartctl" \
|& grep -v '^\(ber\|ldap_get\|ldap_msgfree\)'
grep -H sudoers: /etc/nsswitch.conf
ls -la /etc/sudoers
grep -H -v '^[[:space:]]*#' /etc/sudo.conf /etc/sudo-ldap.conf
grep -H nagios /etc/passwd

Compress files larger than 4 kb, please.

Bug#746811: Bug #746811: Should build against and link with system's libtrio

[Bastian Germann]

Control: tags 746811 - wontfix

On Wed, 9 Jul 2014 06:29:10 +0800 Aron Xu  wrote:

Control: tags 746811 + wontfix

Yes but this cannot be done, src:libtrio is not in testing, nor any
previous stable releases, also the code are changed quite a lot. If we
really make libxml2 depend on it then I'm afraid we are risking to not
have any new version of libxml2 migrate into testing.
libtrio is in Debian releases for a long time now, so this might be 
worth another look.

Bug#985412: sudo: Re-defined aliases result in incorrect error message

[Chris Boot]

Package: sudo
Version: 1.9.5p2-3
Severity: normal

Dear Maintainer,

If a Cmnd_Alias (others may also be affected) is defined twice, the
error message produced is misleading:

$ cat >test < Cmnd_Alias BUG_TEST = /bin/true
> Cmnd_Alias BUG_TEST = /bin/true
> EOF
$ visudo -c -f test
test:2:32: Alias "en_GB.UTF-8" already defined
Cmnd_Alias BUG_TEST = /bin/true
   ^

The message appears to include the contents of the $LANG environment
variable, rather than the name of the alias in question. That said, if I
set LANG explicitly I get a blank alias name instead:

$ LANG=en_GB.C visudo -c -f test
test:2:32: Alias "" already defined
Cmnd_Alias BUG_TEST = /bin/true
   ^

I can reproduce this on multiple very different systems, so I'm
confident that this isn't local weirdness.

Thanks,
Chris

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

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

Versions of packages sudo depends on:
ii  libaudit1   1:3.0-2
ii  libc6   2.31-9
ii  libpam-modules  1.4.0-6
ii  libpam0g1.4.0-6
ii  libselinux1 3.1-3
ii  lsb-base11.1.0
ii  zlib1g  1:1.2.11.dfsg-2

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/pam.d/sudo changed [not included]
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 unreproducible moreinfo

Hi!

On Wed, 17 Mar 2021 at 13:54, Helge Kreutzmann  wrote:
>
> Hello Bernhard,
> On Wed, Mar 17, 2021 at 02:25:12PM +0100, Bernhard Übelacker wrote:
> > do you still see these messages in your logging?
>
> Yes.
>
> > If yes could you maybe add the surrounding logging
> > of one such fault? E.g. by something like this:
> > journalctl | grep "traps:" -C20
>
> As soon as it appears (last time was yesterday).

The weird things here are that it does not always happens and so far
we have only seen your bug report. May I suggest you to check the
binary with debsums?

  debsums libqt5qml5

If that is ok then I would run memtest to check the RAM.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2

[Bernhard Übelacker]

Hello Helge,
do you still see these messages in your logging?
If yes could you maybe add the surrounding logging
of one such fault? E.g. by something like this:
    journalctl | grep "traps:" -C20

Kind regards,
Bernhard

Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2

[Bernhard Übelacker]

Hello Helge,
do you still see these messages in your logging?
If yes could you maybe add the surrounding logging
of one such fault? E.g. by something like this:
   journalctl | grep "traps:" -C20

Kind regards,
Bernhard

Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables

[wferi]

Dear Security Team,

Please review the debdiff below for a buster-security upload.
The advisory text changed a little meanwhile, adding credits to Toni
Huttunen, Fraktal Oy for discovering the problem, mentioning the style
sheet spoofing and adding some mitigation tips.

I haven't got a concrete exploit on hand, but I'll start testing the
updated package shortly.

diff -Nru shibboleth-sp-3.0.4+dfsg1/debian/changelog 
shibboleth-sp-3.0.4+dfsg1/debian/changelog
--- shibboleth-sp-3.0.4+dfsg1/debian/changelog  2019-03-16 20:51:16.0 
+0100
+++ shibboleth-sp-3.0.4+dfsg1/debian/changelog  2021-03-17 16:55:49.0 
+0100
@@ -1,3 +1,26 @@
+shibboleth-sp (3.0.4+dfsg1-1+deb10u1) buster-security; urgency=high
+
+  * [594074b] New patch: SSPCPP-922 - Add externalParameters option to Errors
+element.
+Fix a phishing vulnerability: Template generation allows external
+parameters to override placeholders
+The primitive template engine used to render error pages allows
+replacement via query parameters also, though this is not a typical
+need. Because of this feature, it's possible to cause the SP to
+display some templates containing values supplied externally by URL
+manipulation. Though the values are encoded to prevent script
+injection, the content nevertheless appears to come from the server
+and so would be interpreted as trustworthy, allowing email addresses,
+logos, or support URLs to be manipulated by an attacker.
+This update adds a new  setting to the configuration called
+externalParameters, which defaults to false. When false, support for
+this "feature" is disabled.
+https://shibboleth.net/community/advisories/secadv_20210317.txt
+https://issues.shibboleth.net/jira/browse/SSPCPP-922
+Thanks to Scott Cantor (Closes: #985405)
+
+ -- Ferenc Wágner   Wed, 17 Mar 2021 16:55:49 +0100
+
 shibboleth-sp (3.0.4+dfsg1-1) unstable; urgency=medium
 
   * [f284741] New upstream release: 3.0.4
diff -Nru shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf 
shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf
--- shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf   2019-03-13 20:06:54.0 
+0100
+++ shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf   2021-03-17 16:21:54.0 
+0100
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/buster
 upstream-branch = upstream/latest
 pristine-tar = True
 
diff -Nru shibboleth-sp-3.0.4+dfsg1/debian/patches/series 
shibboleth-sp-3.0.4+dfsg1/debian/patches/series
--- shibboleth-sp-3.0.4+dfsg1/debian/patches/series 2019-03-16 
20:48:54.0 +0100
+++ shibboleth-sp-3.0.4+dfsg1/debian/patches/series 2021-03-17 
16:54:46.0 +0100
@@ -3,3 +3,4 @@
 Debianize-the-systemd-service-file-of-shibd.patch
 seckeygen-defaults-for-Debian.patch
 Use-runstatedir-from-future-Autoconf-2.70.patch
+SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
diff -Nru 
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
 
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
--- 
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
1970-01-01 01:00:00.0 +0100
+++ 
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
2021-03-17 16:54:46.0 +0100
@@ -0,0 +1,125 @@
+From: Scott Cantor 
+Date: Tue, 16 Mar 2021 10:56:22 -0400
+Subject: SSPCPP-922 - Add externalParameters option to Errors element
+
+https://issues.shibboleth.net/jira/browse/SSPCPP-922
+
+Closes: #985405
+---
+ schemas/shibboleth-3.0-native-sp-config.xsd |  1 +
+ shibsp/ServiceProvider.cpp  | 11 +--
+ shibsp/handler/impl/AttributeCheckerHandler.cpp | 12 ++--
+ shibsp/handler/impl/FormSessionInitiator.cpp| 12 +++-
+ shibsp/handler/impl/LogoutHandler.cpp   | 10 +-
+ 5 files changed, 40 insertions(+), 6 deletions(-)
+
+diff --git a/schemas/shibboleth-3.0-native-sp-config.xsd 
b/schemas/shibboleth-3.0-native-sp-config.xsd
+index 5bfa3a2..3b1a664 100644
+--- a/schemas/shibboleth-3.0-native-sp-config.xsd
 b/schemas/shibboleth-3.0-native-sp-config.xsd
+@@ -732,6 +732,7 @@
+ 
+ 
+ 
++
+ 
+   
+ 
+diff --git a/shibsp/ServiceProvider.cpp b/shibsp/ServiceProvider.cpp
+index aacbba1..b9f6e4c 100644
+--- a/shibsp/ServiceProvider.cpp
 b/shibsp/ServiceProvider.cpp
+@@ -71,9 +71,16 @@ namespace shibsp {
+ if (!app)
+ app = request.getServiceProvider().getApplication(nullptr);
+ 
+-const PropertySet* props=app->getPropertySet("Errors");
++const PropertySet* props = app->getPropertySet("Errors");
+ 
+-// First look for settings in the request map of the form pageError.
++// If the externalParameters option isn't set, clear out the request 
field.
++pair externalParameters =
++ 

Bug#985343: libvigraimpex-doc: unhandled symlink to directory conversion: /usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html

[Andreas Metzler]

On 2021-03-16 Andreas Beckmann  wrote:
> Package: libvigraimpex-doc
> Version: 1.11.1+dfsg-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts

> Hi,

> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.

Humpf. We have
ametzler@argenau:~/GIT/writing/vigra-debian$ head -n5 
debian/libvigraimpex-doc.maintscript
# 1.11.1+dfsg-2 shipped the symlink, -3 did not.
symlink_to_dir /usr/share/doc/libvigraimpex-dev/html 
/usr/share/doc/libvigraimpex-doc/html 1.11.1+dfsg-3~ libvigraimpex-doc

But dh_installdeb does not seem to have used it.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#975075: Closing as this has been resolved without the TC needing to intervene

[Margarita Manterola]

Hi,

It's been a while since this bug was dealt with and I was tasked with 
closing

it, I'm sorry that it took so long to write this reply.

The technical committee declines to overrule the NetworkManager and 
udisks2

maintainer on this matter.

Instead, by working together with the maintainer of the affected 
packages, we
managed to achieve a compromise solution: the dependency on 
libpam-systemd was
lowered to a recommends so that it's still possible to install the 
package
without it, while a separate package was introduced to carry the removed 
init

scripts.

This compromise solution allows users of other init systems to still use
network-manager and udisks2, without imposing additional work on the 
maintainer

to support those other systems.

As has been mentioned in the bug, this compromise was achieved through 
private
discussions between the technical committee and the maintainer. We 
recognize

that these kind of private discussions are not ideal and can lead to
frustration on the side of those that just hear about the results of the
discussions without being able to participate in them. On the other 
hand, we
also recognize that some maintainers have been burned out by some 
particularly

contentious issues, and would rather not discuss them publicly.

In the general case, the Technical Committee urges users and maintainers 
to

communicate openly and try to find compromise solutions like this one.

Thanks,
Marga on behalf of the Technical Committee

Bug#981413: age: New upstream version (1.0.0~beta6)

[Shengjing Zhu]

On Thu, Mar 18, 2021 at 12:53 AM Filippo Valsorda  wrote:
>
> 2021-03-17 17:33 GMT+01:00 Shengjing Zhu :
>
> On Thu, Mar 18, 2021 at 12:06 AM Filippo Valsorda  
> wrote:
> >
> > 2021-03-17 16:19 GMT+01:00 nicoo :
> > > This is currently blocked on golang-filippo-edwards25519 getting into
> > > testing, which didn't happen because of the whole issue with NEW requiring
> > > binary uploads and transition requiring source-only ones.
> >
> > Thank you for packaging age and for picking up this upload!
> >
> > I dropped the golang-filippo-edwards25519 dependency in v1.0.0-rc.1 to
> > make it easier to get that version into Bullseye.
> >
> > Let me know if it's fine to add it back in a later v1.0, or if it would
> > block bugfixes from making it into Bullseye during the cycle, and I
> > should wait for v1.1.
> >
>
> It depends on what version of age wants to be included in Bullseye.
> As per Bullseye freeze policy[1], golang-filippo-edwards25519 is out
> of luck to be included in Bullseye(No new package since 2/12). But it
> will be included in the next release of cause.
> Currently age v1.0.0-rc1 seems fine for Bullseye, it will migrated
> from Unstable to Bullseye after 20 days.
>
>
> v1.0.0-rc.1 is definitely ok for the Bullseye release.
>
> I was wondering if I should delay the golang-filippo-edwards25519
> dependency to v1.1.0 to allow v1.0.x bugfixes into later Bullseye point
> releases, or if the bar for those is so high that it doesn't matter
> anyway.

IMO, it doesn't matter too much.
But if you can maintain a stable branch which has minimal diff to
v1.0.0-rc1(no new dependency, only backporting important patches),
that would be best for Bullseye.
Otherwise, we can cherry-pick patches for Bullseye ourselves. An usual
life cycle for Debian release is about 5 years(with LTS), so it's sure
much easier if upstream can maintain a stable branch.

-- 
Shengjing Zhu

Bug#966373: general: Version for derivatives between binNMU and stable update

[Javier Serrano Polo]

On Thu, 15 Oct 2020 21:25:51 +0200 Javier Serrano Polo  wrote:
> Thus, there are three choices:
> 
>1. Before binNMU (case 1.0-1deriv1).
>2. After stable update (case 1.0-1+deriv1).
>3. Between binNMU and stable update. This is what I am asking for.
> 
> Would you agree to preserve this third choice if it is currently
> feasible?

Dear Paul Wise,

Package linux parses the Debian version. Could we settle on a version
pattern for derivatives that lies between binNMU and stable update?

smime.p7s
Description: S/MIME cryptographic signature

Bug#985411: xdg-desktop-portal FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: xdg-desktop-portal
Version: 1.7.2-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xdg-desktop-portal fails to cross build from source, because
configure.ac hard codes the build architecture pkg-config in one
occasion. The relevant occasion is indeed entirely unnecessary as the
version check can be fused in an earlier access of the relevant package
with the right pkg-config. Doing so makes xdg-desktop-portal cross
buildable. Please consider applying the attached patch.

Helmut
--- xdg-desktop-portal-1.8.1.orig/configure.ac
+++ xdg-desktop-portal-1.8.1/configure.ac
@@ -50,10 +50,7 @@
 AC_ARG_WITH(flatpak_interfaces_dir,
 AS_HELP_STRING([--with-flatpak-interfaces-dir=PATH],[choose directory for Flatpak interface files, [default=PREFIX/share/dbus-1/interfaces]]),
 [[FLATPAK_INTERFACES_DIR="$withval"]],
-	[PKG_CHECK_VAR([FLATPAK_INTERFACES_DIR], [flatpak], [interfaces_dir])])
-if ! pkg-config --atleast-version "1.5.0" flatpak; then
-FLATPAK_INTERFACES_DIR=""
-fi
+	[PKG_CHECK_VAR([FLATPAK_INTERFACES_DIR], [flatpak >= 1.5.0], [interfaces_dir])])
 AC_SUBST(FLATPAK_INTERFACES_DIR)
 
 AC_ARG_WITH([systemduserunitdir],

Bug#985410: bioawk FTCBFS -- execute maketab during build

[Nilesh Patra]

Package: bioawk
Version: 1.0-3
Severity: normal
Tags: patch
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

Since bioawk seems to execute maketab to generate proctab.c which is not 
allowed during cross build
it could be simply built with build compiler to generate proctab.c

Since maketab binary is not being installed, such a compilation would
not give any exec format problems. I compared the output of ./maketab
i.e. proctab.c across amd64, i386 and arm64 as well as skimmed through
the code. Compiling this particular file with build compiler does not
seem like a problem.

I'm attaching my patch along, and will commit to salsa if it looks good.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index e2280a3..f74bbe9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+bioawk (1.0-4) UNRELEASED; urgency=medium
+
+  * d/p/cross.patch: Fix non-cross buildability
+  * Use dpkg buildtools to set CC and CC_FOR_BUILD
+
+ -- Nilesh Patra   Wed, 17 Mar 2021 22:23:42 +0530
+
 bioawk (1.0-3) unstable; urgency=medium
 
   * Change test dependency from swarm to
diff --git a/debian/patches/cross.patch b/debian/patches/cross.patch
new file mode 100644
index 000..1b56827
--- /dev/null
+++ b/debian/patches/cross.patch
@@ -0,0 +1,14 @@
+Description: Compile maketab with build compiler, since it executes during 
build time - the generated proctab.c does not seem to vary across arches
+Author: Nilesh Patra 
+Last-Update: 2021-03-17
+--- a/Makefile
 b/Makefile
+@@ -53,7 +53,7 @@
+   ./maketab >proctab.c
+ 
+ maketab:  ytab.h maketab.c
+-  $(CC) $(CFLAGS) $(CPPFLAGS) maketab.c -o maketab $(LDFLAGS)
++  $(CC_FOR_BUILD) $(CFLAGS) $(CPPFLAGS) maketab.c -o maketab $(LDFLAGS)
+ 
+ names:
+   @echo $(LISTING)
diff --git a/debian/patches/series b/debian/patches/series
index a17d1e6..dea1943 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 Makefile.patch
 hardening.patch
+cross.patch
diff --git a/debian/rules b/debian/rules
index dd4dd7e..fd7fd8d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 export DH_VERBOSE = 1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+DPKG_EXPORT_BUILDTOOLS = nonempty
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@

Bug#985228: unblock: petsc/3.14.5+dfsg1-2

[Drew Parsons]

On 2021-03-16 17:32, Ivo De Decker wrote:

Control: tags -1 moreinfo

...

On Sun, Mar 14, 2021 at 09:01:26PM +0100, Drew Parsons wrote:

upstream released petsc 3.14.5 with bug fixes only.
This will help improve the stability of the package over the lifetime
of the bullseye release.


I'm not convinced this complies with the freeze policy (but see below).


...

  [ ] attach debdiff against the package in testing


We ask these this for a reason. The current diff between the version in
testing and unstable is very large and unreviewable. It certainly isn't 
going
to get unblocked like this. If you can provide a filtered diff, with 
only the
'real' changes, and not the noise generated by the new upstream 
release,

there's at least a chance we could look at them. Note that this doesn't
guarantee it will be unblocked. There's still a decent chance that the 
changes

will be too big.



Hi Ivo, I'm attaching the essential debdiff, omitting changes to docs, 
TAGS and html files and trivial whitespace reformatting. I also omitted 
the diff to src/ts/trajectory/impls/memory/trajmemory.c, involving the 
conditional "#if defined(PETSC_HAVE_REVOLVE)", since we do not build 
against revolve.


My argument is that this patch makes petsc and therefore bullseye a 
little more robust.


Drew
diff -Nru --exclude '*.html' --exclude '*docs*' petsc-3.14.4+dfsg1/debian/changelog petsc-3.14.5+dfsg1/debian/changelog
--- petsc-3.14.4+dfsg1/debian/changelog	2021-02-11 16:51:02.0 +0100
+++ petsc-3.14.5+dfsg1/debian/changelog	2021-03-10 12:21:59.0 +0100
@@ -1,3 +1,22 @@
+petsc (3.14.5+dfsg1-2) unstable; urgency=medium
+
+  * upload new bugfix release to unstable
+
+ -- Drew Parsons   Wed, 10 Mar 2021 12:21:59 +0100
+
+petsc (3.14.5+dfsg1-1) experimental; urgency=medium
+
+  * New upstream release (bugfixes)
+
+ -- Drew Parsons   Mon, 08 Mar 2021 18:37:39 +0100
+
+petsc (3.14.4+dfsg1-2) unstable; urgency=medium
+
+  * fix PETSC64_NAME in libpetsc64-complex3.14-dev.prerm to enable a
+clean uninstall of libpetsc64-complex3.14-dev. Closes: #983892.
+
+ -- Drew Parsons   Mon, 08 Mar 2021 18:27:40 +0100
+
 petsc (3.14.4+dfsg1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru --exclude '*.html' --exclude '*docs*' petsc-3.14.4+dfsg1/debian/libpetsc64-complex3.14-dev.prerm petsc-3.14.5+dfsg1/debian/libpetsc64-complex3.14-dev.prerm
--- petsc-3.14.4+dfsg1/debian/libpetsc64-complex3.14-dev.prerm	2021-02-11 16:51:02.0 +0100
+++ petsc-3.14.5+dfsg1/debian/libpetsc64-complex3.14-dev.prerm	2021-03-10 12:21:59.0 +0100
@@ -8,7 +8,7 @@
 PETSC_ARCH=${DEB_HOST_MULTIARCH}
 PETSC_COMPLEX_ARCH=${PETSC_ARCH}-complex
 PETSC_SONAME_VERSION=__PETSC_SONAME_VERSION__
-PETSC64_NAME=petsc${PETSC_SONAME_VERSION}
+PETSC64_NAME=petsc64-${PETSC_SONAME_VERSION}
 
 PETSC64_DIR_COMPLEX=/usr/lib/petscdir/${PETSC64_NAME}/${PETSC_COMPLEX_ARCH}
 
diff -Nru --exclude '*.html' --exclude '*docs*' petsc-3.14.4+dfsg1/include/petsc/private/petschpddm.h petsc-3.14.5+dfsg1/include/petsc/private/petschpddm.h
--- petsc-3.14.4+dfsg1/include/petsc/private/petschpddm.h	2020-11-03 19:01:59.0 +0100
+++ petsc-3.14.5+dfsg1/include/petsc/private/petschpddm.h	2021-03-03 23:13:43.0 +0100
@@ -31,6 +31,7 @@
   PC_HPDDM_Level  **levels;   /* array of shells */
   Mat aux;/* local auxiliary matrix defined at the finest level on PETSC_COMM_SELF */
   Mat B;  /* right-hand side matrix defined at the finest level on PETSC_COMM_SELF */
+  Vec normal; /* temporary Vec when preconditioning the normal equations with KSPLSQR */
   IS  is; /* global numbering of the auxiliary matrix */
   PetscIntN;  /* number of levels */
   PCHPDDMCoarseCorrectionType correction; /* type of coarse correction */
diff -Nru --exclude '*.html' --exclude '*docs*' petsc-3.14.4+dfsg1/src/dm/dt/fe/interface/ftn-custom/zfef.c petsc-3.14.5+dfsg1/src/dm/dt/fe/interface/ftn-custom/zfef.c
--- petsc-3.14.4+dfsg1/src/dm/dt/fe/interface/ftn-custom/zfef.c	2020-11-03 19:01:59.0 +0100
+++ petsc-3.14.5+dfsg1/src/dm/dt/fe/interface/ftn-custom/zfef.c	2021-03-03 23:09:50.0 +0100
@@ -17,6 +17,7 @@
   char *t;
 
   FIXCHAR(type,len,t);
+  CHKFORTRANNULLOBJECT(obj);
   *ierr = PetscSpaceViewFromOptions(*ao,obj,t);if (*ierr) return;
   FREECHAR(type,t);
 }
@@ -26,6 +27,7 @@
   char *t;
 
   FIXCHAR(type,len,t);
+  CHKFORTRANNULLOBJECT(obj);
   *ierr = PetscDualSpaceViewFromOptions(*ao,obj,t);if (*ierr) return;
   FREECHAR(type,t);
 }
@@ -35,6 +37,7 @@
   char *t;
 
   FIXCHAR(type,len,t);
+  CHKFORTRANNULLOBJECT(obj);
   *ierr = PetscFEViewFromOptions(*ao,obj,t);if (*ierr) return;
   FREECHAR(type,t);
 }
diff -Nru --exclude '*.html' --exclude '*docs*' petsc-3.14.4+dfsg1/src/dm/dt/fv/interface/ftn-custom/zfvf.c petsc-3.14.5+dfsg1/src/dm/dt/fv/interface/ftn-custom/zfvf.c
--- 

Bug#985028: Bug#981413: age: New upstream version (1.0.0~beta6)

[Filippo Valsorda]

2021-03-17 17:33 GMT+01:00 Shengjing Zhu mailto:zhsj%40debian.org>>:
> On Thu, Mar 18, 2021 at 12:06 AM Filippo Valsorda  > wrote:
> >
> > 2021-03-17 16:19 GMT+01:00 nicoo  > >:
> > > This is currently blocked on golang-filippo-edwards25519 getting into
> > > testing, which didn't happen because of the whole issue with NEW requiring
> > > binary uploads and transition requiring source-only ones.
> >
> > Thank you for packaging age and for picking up this upload!
> >
> > I dropped the golang-filippo-edwards25519 dependency in v1.0.0-rc.1 to
> > make it easier to get that version into Bullseye.
> >
> > Let me know if it's fine to add it back in a later v1.0, or if it would
> > block bugfixes from making it into Bullseye during the cycle, and I
> > should wait for v1.1.
> >
> 
> It depends on what version of age wants to be included in Bullseye.
> As per Bullseye freeze policy[1], golang-filippo-edwards25519 is out
> of luck to be included in Bullseye(No new package since 2/12). But it
> will be included in the next release of cause.
> Currently age v1.0.0-rc1 seems fine for Bullseye, it will migrated
> from Unstable to Bullseye after 20 days.

v1.0.0-rc.1 is definitely ok for the Bullseye release.

I was wondering if I should delay the golang-filippo-edwards25519
dependency to v1.1.0 to allow v1.0.x bugfixes into later Bullseye point
releases, or if the bar for those is so high that it doesn't matter
anyway.

Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2

[Helge Kreutzmann]

Hello Bernhard,
On Wed, Mar 17, 2021 at 02:25:12PM +0100, Bernhard Übelacker wrote:
> do you still see these messages in your logging?

Yes.

> If yes could you maybe add the surrounding logging
> of one such fault? E.g. by something like this:
>     journalctl | grep "traps:" -C20

As soon as it appears (last time was yesterday).

Greetings

 Helge

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


signature.asc
Description: PGP signature

Bug#976462: debian bug 976462

[Sean Whitton]

Hello,

On Wed 10 Mar 2021 at 04:54PM +01, Mark Wielaard wrote:

> For reference, this is the dwz bug for [dwz] Support compressed debug
> sections: https://sourceware.org/bugzilla/show_bug.cgi?id=24725
>
> It has low priority because it has a simple workaround:
> you could use eu-elfcompress before/after the dwz run
>
> $ eu-elfcompress --type=none ./a.out
> $ dwz ./a.out
> $ eu-elfcompress --type=zlib ./a.out

Thanks for the input.  In any case in which the reason not to use
compressed debug symbols is something to do with package builds, a
workaround of this form could be used.

Then, the only tool compatibility reasons not to use compressed debug
symbols are (i) tools that users who have the symbols installed want to
run; and (ii) complicated debhelper order-of-operation issues which make
it difficult to use the above workaround.

Given that the debhelper maintainer said that he doesn't mind whether or
not compression is turned on, I think we can eliminate (ii).

Looking back through the thread, the closest thing we have to (i) is two
bugs in Valgrind.  However, those bugs are both marked as resolved.

So, I conclude that we still haven't seen concrete tooling problems
which would give us good reasons to disable compression.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#981413: age: New upstream version (1.0.0~beta6)

[Shengjing Zhu]

On Thu, Mar 18, 2021 at 12:06 AM Filippo Valsorda  wrote:
>
> 2021-03-17 16:19 GMT+01:00 nicoo :
> > This is currently blocked on golang-filippo-edwards25519 getting into
> > testing, which didn't happen because of the whole issue with NEW requiring
> > binary uploads and transition requiring source-only ones.
>
> Thank you for packaging age and for picking up this upload!
>
> I dropped the golang-filippo-edwards25519 dependency in v1.0.0-rc.1 to
> make it easier to get that version into Bullseye.
>
> Let me know if it's fine to add it back in a later v1.0, or if it would
> block bugfixes from making it into Bullseye during the cycle, and I
> should wait for v1.1.
>

It depends on what version of age wants to be included in Bullseye.
As per Bullseye freeze policy[1], golang-filippo-edwards25519 is out
of luck to be included in Bullseye(No new package since 2/12). But it
will be included in the next release of cause.
Currently age v1.0.0-rc1 seems fine for Bullseye, it will migrated
from Unstable to Bullseye after 20 days.
Bullseye hard freeze has already started on 3/12, which means Bullseye
will be released soon. So I'm not sure age v1.0 can catch up the
deadline.

[1] https://release.debian.org/bullseye/freeze_policy.html

-- 
Shengjing Zhu

Bug#962464: Remove ICU dependency

[Bastian Germann]

On Mon, 8 Jun 2020 14:54:42 +0200 Nick Wellnhofer  
wrote:

Package: libxml2

Bug #776254 requested that libxml2 uses ICU for character set conversion 
because of some unspecified issues with Chromium. This adds an otherwise 
useless, multi-megabyte dependency (larger than libxml2 itself). I propose to 
revert that change. This means that libxml2 will use iconv for character 
conversion as before.


I'm sure that the Chromium issues can be worked around in another way. I'm 
also disappointed that the Chromium developers never reached out to the 
libxml2 maintainers.


I second this request. Alternatively, it would be great to have a build 
profile that excludes ICU.

Bug#985409: RM: gnucobol/4.0~early~20200606-3

[Al Stone]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

ROM: the wrong upstream version was packaged; I made a mistake.
This version completely breaks any backwards compatibility and
should not have been used.  It is not recommended by upstream
because it breaks compatibility.  If this version of the package
stays in Debian at all, it should be in experimental, at best.

Bug#985404: qa.debian.org: Packages overview VCS field doesn't consider a debian/experimental branch

[Sebastiaan Couwenberg]

On 3/17/21 5:07 PM, Mattia Rizzolo wrote:
> On Wed, Mar 17, 2021 at 05:05:15PM +0100, Andreas Ronnquist wrote:
>> Ah, thanks. I was looking at python-cartopy but didn't notice that
>> there gbp.conf is also updated with proper branch info for each branch.
>> I guess that is why that package don't report a problem, and mine does.
> 
> It's not about gbp.conf.  src:python-cartopy has this in d/control:
> Vcs-Git: https://salsa.debian.org/debian-gis-team/python-cartopy.git -b 
> experimental
> note the "-b experimental".

We update both when switching away from the master branch:

 
https://salsa.debian.org/debian-gis-team/python-cartopy/-/commit/e8131f281c67a1e9b348051e06c654a91d4f3bdc

And those commits get reverted when switching back.

Kind Regards,

Bas

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

Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy

[Santiago Ruano Rincón]

Hi Michael,

El 17/03/21 a las 15:01, Michael Biebl escribió:
> Hi Santiago
> 
> On Fri, 12 Mar 2021 21:33:05 +0100 Santiago Ruano =?iso-8859-
> 1?Q?Rinc=F3n?=  wrote:
> 
> > Dear maintainers of the packages that would be removed by the removal
> of
> > libcgroup,
> 
> 
> Checking reverse dependencies...
> # Broken Depends:
> cinder: cinder-common → cgroup-tools
> clsync: clsync → libcgroup1
> condor: htcondor → libcgroup1
> mininet: mininet → cgroup-tools
> nova: nova-compute → cgroup-tools
> vzctl: vzctl [amd64 i386] → libcgroup1
> 
> # Broken Build-Depends:
> clsync: libcgroup-dev
> condor: libcgroup-dev
> vzctl: libcgroup-dev
> 
> 
>  
> > I am taking a look at the above mentioned new version of libcgroup,
> that
> > partially supports cgroup2. Would it make sense for your packages to
> > have in Debian that version of libcgroup (the current git HEAD)?
> 
> While I appreciate the effort, I feel a bit uneasy about shipping
> something half-baked like this. Does such an updated libcgroup package
> actually ensure, that rdeps continue to work?

Yeah, answering that was actually the main purpose of my question!

> 
> Maybe the packages above need to check, whether they actually need the
> libcgroup / cgroup-tools dependency.

Yes, indeed. I have been only able to take a look at mininet, that I use
personally a little bit. In a basic use as mine, mininet works (so I
could drop the dependency).
But it is broken if you need to do stuff that relies on cgroups:
e.g. running `python3 /usr/share/doc/mininet/examples/limit.py`
fails:
Traceback (most recent call last):
  File "/usr/share/doc/mininet/examples/limit.py", line 61, in 
limit()
  File "/usr/share/doc/mininet/examples/limit.py", line 37, in limit
net = Mininet( topo=myTopo, intf=intf, host=host, waitConnected=True )
  File "/usr/lib/python3/dist-packages/mininet/net.py", line 178, in __init__
self.build()
  File "/usr/lib/python3/dist-packages/mininet/net.py", line 508, in build
self.buildFromTopo( self.topo )
  File "/usr/lib/python3/dist-packages/mininet/net.py", line 479, in 
buildFromTopo
self.addHost( hostName, **topo.nodeInfo( hostName ) )
  File "/usr/lib/python3/dist-packages/mininet/net.py", line 232, in addHost
h = cls( name, **defaults )
  File "/usr/lib/python3/dist-packages/mininet/util.py", line 587, in customized
return cls( *args, **kwargs )
  File "/usr/lib/python3/dist-packages/mininet/node.py", line 692, in __init__
CPULimitedHost.init()
  File "/usr/lib/python3/dist-packages/mininet/node.py", line 871, in init
mountCgroups()
  File "/usr/lib/python3/dist-packages/mininet/util.py", line 548, in 
mountCgroups
raise Exception( "cgroups not mounted on " + cgdir )
Exception: cgroups not mounted on /sys/fs/cgroup

mininet code that relies on cgroupv1, e.g.:
https://sources.debian.org/src/mininet/2.3.0-1/mininet/node.py/#L695
https://sources.debian.org/src/mininet/2.3.0-1/mininet/util.py/#L541
should have to be patched to be able to run with cgroupv2. A priori, the
upgraded cgroup-tools would make that easier.


I have no idea about cinder and nova, I let the maintainers give their input.

> 
> If this was broken for such a long time with noone noticing, maybe
> dropping that dependency is the better alternative. At least the
> cgroup-tools dependency looks like something that could be dropped.

Maybe. It is maybe difficult to notice since some tools don't have a
significant number of users that run testing or unstable (that's my case
with mininet).

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#985404: qa.debian.org: Packages overview VCS field doesn't consider a debian/experimental branch

[Mattia Rizzolo]

On Wed, Mar 17, 2021 at 05:05:15PM +0100, Andreas Ronnquist wrote:
> >> or even those where
> >> the experimental branch is called simply experimental (and not
> >> debian/experimental) also not showing the version as problematic.  
> >
> >This sounds weird, do you have an example?
> 
> Ah, thanks. I was looking at python-cartopy but didn't notice that
> there gbp.conf is also updated with proper branch info for each branch.
> I guess that is why that package don't report a problem, and mine does.

It's not about gbp.conf.  src:python-cartopy has this in d/control:
Vcs-Git: https://salsa.debian.org/debian-gis-team/python-cartopy.git -b 
experimental
note the "-b experimental".

Also read
file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#version-control-system-vcs-fields

-- 
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#985404: qa.debian.org: Packages overview VCS field doesn't consider a debian/experimental branch

[Andreas Ronnquist]

On Wed, 17 Mar 2021 16:47:02 +0100
Mattia Rizzolo  wrote:

>On Wed, Mar 17, 2021 at 03:59:43PM +0100, Andreas Rönnquist wrote:
>> The VCS field on developer Packages overview doesn't seem to
>> consider a debian/experimental branch.  
>
>How would DDPO (actually, vcswatch is the component you are interested
>in) go about knowing that.
>
>> The Package overview shows Git - 4.4.5-2 (with the version in red as
>> if there's a problem with it) as if that is the latest in Git.  
>
>The problem is in your packages.
>The branch vcswatch is using the one pointed by HEAD.  If that doesn't
>contain the version it is expecting, that's marked as an error.
>
>In your case, you should be specifying the branch in Vcs-Git, using the
>-b flag, as documented in Policy.
>
>> I can see other packages that have experimental packaging in the
>> debian/master branch not showing this as a problem,  
>
>Yes, that's correct, because HEAD points to the branch containing the
>most up-to-date packaging.
>
>> or even those where
>> the experimental branch is called simply experimental (and not
>> debian/experimental) also not showing the version as problematic.  
>
>This sounds weird, do you have an example?
>


Ah, thanks. I was looking at python-cartopy but didn't notice that
there gbp.conf is also updated with proper branch info for each branch.
I guess that is why that package don't report a problem, and mine does.

Sorry for the noise, and thanks for the education! 

best
/Andreas
gus...@debian.org

Bug#985408: unblock: mutter/3.38.4-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Wed, Mar 17, 2021 at 03:44:33PM +, Simon McVittie wrote:
> I would like to update mutter from our current heavily-patched 3.38.3
> (effectively 3.38.4~git20210309) to the upstream 3.38.4 release.

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the builds for the new version are done.

Thanks,

Ivo

Bug#981413: age: New upstream version (1.0.0~beta6)

[Filippo Valsorda]

2021-03-17 16:19 GMT+01:00 nicoo :
> This is currently blocked on golang-filippo-edwards25519 getting into
> testing, which didn't happen because of the whole issue with NEW requiring
> binary uploads and transition requiring source-only ones.

Thank you for packaging age and for picking up this upload!

I dropped the golang-filippo-edwards25519 dependency in v1.0.0-rc.1 to
make it easier to get that version into Bullseye.

Let me know if it's fine to add it back in a later v1.0, or if it would
block bugfixes from making it into Bullseye during the cycle, and I
should wait for v1.1.

Bug#985407: unblock: gnome-shell/3.38.4-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Wed, Mar 17, 2021 at 03:44:31PM +, Simon McVittie wrote:
> I would like to update gnome-shell from our current heavily-patched 3.38.3
> (effectively 3.38.4~git20210306) to the upstream 3.38.4 release.

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the builds for the new version are done.

Cheers,

Ivo

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Wookey]

On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> Control: tags -1 moreinfo
>
> Hi Wookey,
>
> Le 2021-01-27 12:57, Wookey a écrit :
> > Source: linux
> > Version: Please enable ARM CMN-600 power management on arm64
> > Severity: normal
> > Tags: patch
> >
> > Current arm hardware such as graviton2 (AWS arm64 hardware) has
> > 'Coherent Mesh Network' interconnect (between components in a
> > soc). It's important that support for this is built in the kernel so
> > it can be used.
> >
> > This requires CONFIG_ARM_CMN=y
>
> Does it really have to be built-in instead of being provided as a module? 
> Last I
> checked, Fedora and Ubuntu provide it as a module.

No it should really be a module. Perf is driven from userspace so you
never need to use it before modules can be loaded.

I just did it like this because the other settings here are set as
built-ins too and this seemed less disruptive. (If we make it a module
we'll need to make sure it gets included in the right module package -
I'm not sure if that need tweaking somewhere else in the build system)

I see that
CONFIG_THUNDERX2_PMU=y
CONFIG_ARM_SMMU_V3_PMU=y
are also set as builtins. That's probably wrong too.
This should be a module (whic is the upstream default - I'm not sure why
it's coming out as a built-in in the debian build):
CONFIG_THUNDERX2_PMU=m

I'm not sure about CONFIG_ARM_SMMU_V3_PMU=y as it's an architectureal
feature. Best to leave it as a built-in for now.

I also checked the state of the other perf configs with the arm kernel team
and got feedback that we have all the ones that should sensibly be set set once
CONFIG_ARM_CMN=m
and
CONFIG_THUNDERX2_PMU=m
is added

Upstream enables
CONFIG_FSL_IMX8_DDR_PMU=m
by default too. IMX8 hardware is available so we should probably turn this on 
too

Do you want me to knock up a patch for this or is that enough info?

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#985408: unblock: mutter/3.38.4-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

I would like to update mutter from our current heavily-patched 3.38.3
(effectively 3.38.4~git20210309) to the upstream 3.38.4 release.

[ Reason ]
* Fix a Wayland spec compliance issue that caused incorrect compositing
  (content displayed outside the intended window) during development of
  future Firefox optimizations
* Ship a real upstream release instead of what's effectively a git snapshot

[ Impact ]
If future Firefox versions make use of Wayland subsurfaces for WebRender,
Debian users will not be able to rely on web content being clipped to the
intended window unless we fix the mutter bug. This seems like something we
might need in a firefox-esr update during the bullseye cycle.

Shipping 3.38.4 instead of 3.38.4~git20210309 is more supportable by
upstream.

[ Tests ]
Manual testing: I use GNOME daily. I've installed this on multiple
systems including Intel/Mesa, AMD/Mesa and NVIDIA/proprietary.

[ Risks ]
It's a key package and regressions here would be highly visible (but
upstream are generally good about limiting the changes they'll make to
their stable-branches, and fixing any regressions promptly).

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing
  (because we dropped lots of patches, this is a diff between the
  patched trees, excluding d/patches/*.patch; I upload with dgit,
  so what's in git is guaranteed to match what's uploaded)

unblock mutter/3.38.4-1
git diff archive/debian/3.38.3-5..patch-queue/debian/master \
| filterdiff -p1 --exclude='debian/patches/*.patch'

diff --git a/NEWS b/NEWS
index 13038b284..79d5dd6f1 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,21 @@
+3.38.4
+==
+* Do not ping unmanaging windows [Florian; gnome-shell#2467]
+* Handle monitor changes during screencasts [Jonas Å.; !1691]
+* Improve freezes when switching workspace [Jonas Å.; !1616]
+* Fix newly opened X11 windows being invisible in overview [Olivier; !1678]
+* Fix drag cancel animation when using geometry scaling [Robert; !1683]
+* Fix stuck icon in DND operation between X11 and wayland [Carlos; !1720]
+* Fix restoring focus to windows using globally active input [Olivier; !1716]
+* Disable double-buffered shadow buffering [Jonas Å.; !1743]
+* Fix frame timings causing X11 clients to get stuck  [Jonas Å.; !1754]
+* Fix order in which subsurface placement operations are handled [Robert; !1768]
+* Fixed crashes [Thomas, Jonas Å., Sebastian; !1694, !1719, !1748]
+
+Contributors:
+  Jonas Ådahl, Olivier Fourdan, Carlos Garnacho, Sebastian Keller, Robert Mader,
+  Thomas Mühlbacher, Florian Müllner
+
 3.38.3
 ==
 * xwayland: Set xrandr primary output [Aleksandr; !1638]
diff --git a/debian/changelog b/debian/changelog
index 19af0d134..aad563754 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+mutter (3.38.4-1) unstable; urgency=medium
+
+  * Team upload
+  * New upstream release
+- Fix Wayland spec compliance when reordering subsurfaces.
+  This is likely to be required by future Firefox versions in native
+  Wayland mode.
+- Many other fixes that we already had via debian/patches
+  * Drop most patches, included in the new upstream release
+
+ -- Simon McVittie   Wed, 17 Mar 2021 09:52:33 +
+
 mutter (3.38.3-5) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/series b/debian/patches/series
index e6cba7d38..18311933a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,29 +1,3 @@
-window-Do-not-handle-ungrabbed-events-when-unmanaging.patch
-window-Guard-can_ping-against-unmanaging-windows.patch
-monitor-config-store-Properly-escape-monitor-spec.patch
-monitor-config-Free-meta_monitor_spec-safely.patch
-tests-monitor-config-Improve-debugging-output.patch
-workspace-Downgrade-assert-to-warning-when-adding-window.patch
-screen-cast-stream-Add-getter-for-stream-src.patch
-screen-cast-monitor-stream-Don-t-fall-apart-when-monitor-.patch
-screen-cast-area-src-Handle-monitors-changes-here-too.patch
-window-Freeze-stack-when-calculating-showing-state.patch
-window-actor-Add-a-new-can_freeze_commits-API.patch
-window-x11-Check-before-freezing-commits.patch
-feedback-actor-Add-API-to-set-and-get-geometry-scale.patch
-wayland-dnd-surface-Use-new-API-to-set-geometry-scale-of-.patch
-compositor-dnd-actor-Take-geometry-scale-into-account-on-.patch
-clutter-timeline-Clear-stage-view-listener-when-actor-des.patch
-wayland-Make-XDnD-grab-unlink-source-offer-manually.patch
-wayland-Plug-XDnD-drag-source-leak.patch
-wayland-Manually-detach-source-offer-on-failure-paths.patch
-wayland-Avoid-automatically-decoupling-source-offer-after.patch
-window-Add-is_focus_async-API.patch
-core-Account-for-the-globally-active-input-case.patch

Bug#985407: unblock: gnome-shell/3.38.4-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

I would like to update gnome-shell from our current heavily-patched 3.38.3
(effectively 3.38.4~git20210306) to the upstream 3.38.4 release.

[ Reason ]
* Multiple bug fixes around X11 windows' fallback icons:
  - a Shell crash that might have been a regression in our 3.38.3-3
  - missing icons for some programs that should have had them, particularly
in programs that are not installed system-wide (such as Steam games),
a regression since buster
  - a memory leak
  - a possible (although unlikely?) use-after-free
* Avoid repositioning of unrelated windows when a window is dragged onto
  the workspace switcher
* Make sure the blur effect shader compiles successfully by changing an
  integer literal to a floating-point literal
* Ship a real upstream release instead of what's effectively a git snapshot

[ Impact ]
The fixes for fallback icons include fixing a Shell crash. Because the Shell
acts as a Wayland compositor, crashes are extremely disruptive (ending the
session immediately, with no opportunity to save unsaved documents etc.)

The window positioning change is mostly cosmetic, but it seems better to
have it than to revert it. I think the blur effect change is similar.

Shipping 3.38.4 instead of 3.38.4~git20210306 is more supportable by
upstream.

[ Tests ]
Manual testing: I use GNOME daily. I've installed this on multiple
systems including Intel/Mesa, AMD/Mesa and NVIDIA/proprietary.

[ Risks ]
It's a key package and regressions here would be highly visible (but
upstream are generally good about limiting the changes they'll make to
their stable-branches, and fixing any regressions promptly).

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing
  (because we dropped lots of patches, this is a diff between the
  patched trees, excluding d/patches/*.patch; I upload with dgit,
  so what's in git is guaranteed to match what's uploaded)

unblock gnome-shell/3.38.4-1
git diff archive/debian/3.38.3-4..patch-queue/debian/master \
| filterdiff -p1 --exclude='debian/patches/*.patch'

diff --git a/NEWS b/NEWS
index e541e2b2f..5841acd71 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,24 @@
+3.38.4
+==
+* Fix stuck grab after failed area screenshots [Sebastian; !1600]
+* Prefer image-data hint over app-icon in notifications [Guilherme; !1616]
+* Make sure fullscreen apps can't block the workspace switch animation
+  [Razze; #3636]
+* Fix stuck polkit dialog when using non-password auth [Florian; !1662]
+* Fix glitch after dragging window preview from second monitor [Ivan; !1727]
+* Fix missing X11 fallback icons [Florian; !1761]
+* Fixed crashes [Jonas D., Carlos, Sebastian; !1673, !1672, !1718]
+* Misc. bug fixes and cleanups [Florian, Marco, Abderrahim, Frederic; !1595,
+  !1598, !1635, !1725, !1750]
+
+Contributors:
+  Frederic Crozat, Jonas Dreßler, Carlos Garnacho, Sebastian Keller,
+  Abderrahim Kitouni, Ivan Molodetskikh, Florian Müllner, Razze,
+  Guilherme Silva, Marco Trevisan (Treviño)
+
+Translators:
+  Philipp Kiemle [de]
+
 3.38.3
 ==
 * Fix disappearing app grid [Georges; !1532]
diff --git a/debian/changelog b/debian/changelog
index 92d15a9d9..9af941dd9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+gnome-shell (3.38.4-1) unstable; urgency=medium
+
+  * Team upload
+  * New upstream release
+- Fix missing X11 fallback icons (particularly for games and other
+  programs not installed system-wide), a regression in 3.37.3
+- Fix a Shell crash when an X11 window with an invalid/empty icon
+  is closed, possibly a regression in 3.38.3-3
+- Fix a memory leak when getting the icon from the texture cache
+- Fix a possible use-after-free when removing a window
+- Don't reposition unrelated windows when dragging a window onto the
+  workspace switcher
+- Make sure the blur effect shader can be compiled successfully
+- Many other fixes that we already had via debian/patches
+  * Drop all patches, applied upstream
+
+ -- Simon McVittie   Wed, 17 Mar 2021 09:52:47 +
+
 gnome-shell (3.38.3-4) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index 8e6a9d6c1..0
--- a/debian/patches/series
+++ /dev/null
@@ -1,11 +0,0 @@
-extensionSystem-Fix-opening-Extensions-app-from-notificat.patch
-workspacesView-Fix-off-by-one-error.patch
-screenshot-Still-remove-select-pick-actor-if-grab-promise.patch
-notificationDaemon-Fix-icon-choosing-logic.patch
-workspaceAnimation-Disable-unredirection-during-the-gestu.patch
-appDisplay-Do-not-bind-popdown-call-to-grabHelper-onUngra.patch
-polkitAgent-Ensure-cleanup-if-dialog-wasn-t-shown.patch

Bug#985028: RFS: age/1.0.0~rc1-1 -- simple, modern and secure encryption tool

[Christoph Egger]

On Wednesday 17 March 2021 15:32:06 CET Christoph Egger wrote:
> Should say `unstable` I guess?
> Looks good otherwise

Please fix it in the VCS ;-)

Christoph

Bug#983365: [PATCH] Re: Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Dear David,

>>> I finally found the bug: ...
> 
> Excellent!
> 
> Please make sure you also test a file transfer, which is part of the
> chat message interface [I couldn't try since the chat msgs itself
> didn't work ...], The file transfer functionality is absolutely
> essential as well, afaic at least 

soci 4.0.1-5 has migrated to testing yesterday. The bug should be fixed
now for a fully up-to-date Bullseye system.

Bernhard

Bug#981413: age: New upstream version (1.0.0~beta6)

[nicoo]

Control: retitle 981413 age: New upstream version (1.0.0~rc1)
Control: severity 981413 serious
Control: block 981413 by 985028

Hi,

Apologies for letting this wait so long; it was blocked on clearing NEW for
a while, and once it finally did I was too broken to “do the needful.”

This is currently blocked on golang-filippo-edwards25519 getting into
testing, which didn't happen because of the whole issue with NEW requiring
binary uploads and transition requiring source-only ones.


I'm bumping the severity to serious, as the currently-packaged version of
age is IMO unfit for release:
- there are API-breaking and CLI changes compared to 1.0.0~rc1 ;
- having interfaces being slightly-different than expected would confuse
  Bullseye users, esp. if trying to use 3rd-party scripts etc. ;
- upstream does not want to maintain for years utilities etc. that have to
  deal with both versions of the interface (API & CLI)

I will do what I can ASAP to get this resolved.


@Johan: Sorry, again, for letting this sit around; FYI, I'm much more
responsive if poked over IRC, esp. given how broken I've been.
I will be reviewing your package shortly.


Best,

  nicoo

On Sat, Jan 30, 2021 at 09:53:17PM +0100, nicoo wrote:
> Control: tag -1 + patch
> 
> On Sat, Jan 30, 2021 at 08:20:37PM +0100, nicoo wrote:
> > However, it has a new dependency (filippo.io/edwards25519) which isn't 
> > packaged
> > yet; I will create the WNPP bug shortly, and possibly start packaging it.  
> > If I
> > do start, I'll grant you access to the repository  :)
> 
> Packaged [golang-filippo-edwards25519], uploaded to [NEW], and packaged
> age/1.0.0~beta6 : 
> https://salsa.debian.org/go-team/packages/age/-/merge_requests/2
> 
> [golang-filippo-edwards25519]: 
> https://salsa.debian.org/go-team/packages/filippo.io-edwards25519/
> [NEW]: 
> https://ftp-master.debian.org/new/golang-filippo-edwards25519_1.0.0~beta.2-1.html




signature.asc
Description: PGP signature

Bug#985406: apt-cacher-ng: Please rotate maint_*.log.html files as well

[Shengjing Zhu]

Package: apt-cacher-ng
Version: 3.6-1
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

Dear Maintainer,

It seems /var/log/apt-cacher-ng/maint_*.log.html files are not rotated.
Could you add it to logrotate configuration too?

Thanks

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.75
ii  dpkg 1.20.7.1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-1.0
ii  libssl1.11.1.1j-1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-1
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-5
pn  doc-base  
ii  libfuse2  2.9.9-5

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/tunnelenable: true
  apt-cacher-ng/port: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/cachedir: keep

Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables

[Ferenc Wágner]

Package: src:shibboleth-sp
Version: 3.0.2+dfsg1-1
Severity: important
Tags: upstream patch security
Forwarded: https://issues.shibboleth.net/jira/browse/SSPCPP-922

Shibboleth Service Provider Security Advisory [17 March 2021]

An updated version of the Service Provider software is available
which fixes a phishing vulnerability.

Template generation allows external parameters to override placeholders
==
The SP includes a primitive template engine used to render error pages
and various other status or transition pages, and it supports a syntax
for embedding placeholders that are replaced by internally supplied
values or configuration settings.

For reasons that are unclear in the code history, it was extended to
allow replacement via query parameters also, though this is not a
typical need. Because of this feature, it's possible to cause the SP
to display some templates containing values supplied externally by
URL manipulation. Though the values are encoded to prevent script
injection, the content nevertheless appears to come from the server
and so would be interpreted as trustworthy, allowing email addresses,
logos, or support URLs to be manipulated by an attacker.

All platforms are impacted by this issue.


Recommendations
===
Update to V3.2.1 or later of the Service Provider software, which
is now available.

The update adds a new  setting to the configuration called
externalParameters, which defaults to false. When false, support for
this "feature" is disabled. In the unlikely event that a valid need
for this exists, the setting can be enabled temporarily to maintain
function until the use case requiring it is addressed in some other
way.


Other Notes
===
The cpp-sp git commit containing the fix for this issue is
d1dbebfadc1bdb824fea63843c4c38fa69e54379


URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20210317.txt

Bug#985404: qa.debian.org: Packages overview VCS field doesn't consider a debian/experimental branch

[Andreas Rönnquist]

Package: qa.debian.org
Severity: wishlist

The VCS field on developer Packages overview doesn't seem to consider a
debian/experimental branch.

In my example, the package scite, where unstable has version 4.4.5-2,
and salsa has the tag debian/4.4.5-2 on the debian/master branch, and
it has 5.0.0-1~exp1 in experimental, and the tag debian/5.0.0-1_exp1 on
the debian/experimental branch.

The Package overview shows Git - 4.4.5-2 (with the version in red as if
there's a problem with it) as if that is the latest in Git.

My package overview where the problem is visible at
https://qa.debian.org/developer.php?login=gusnan%40debian.org

I can see other packages that have experimental packaging in the
debian/master branch not showing this as a problem, or even those where
the experimental branch is called simply experimental (and not
debian/experimental) also not showing the version as problematic.

DEP-14 mentions debian/experimental and debian/unstable, but it
shouldn't be an error to use debian/experimental as branch name even if
using debian/master, right?

Please inform me if it is simply user error.

-- Andreas Rönnquist
gus...@debian.org

Bug#985028: RFS: age/1.0.0~rc1-1 -- simple, modern and secure encryption tool

[Christoph Egger]

Hi!

On Thursday 11 March 2021 22:30:01 CET Johan Fleury wrote:
>
>  age (1.0.0~rc1-1) UNRELEASED; urgency=medium

Should say `unstable` I guess?
Looks good otherwise

Christoph

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

Bug#985403: bam FTCBFS -- multiple reasons

[Nilesh Patra]

On Wed, 17 Mar 2021 at 19:42, Helmut Grohne  wrote:

> Hi Nilesh,
>
> On Wed, Mar 17, 2021 at 07:09:28PM +0530, Nilesh Patra wrote:
> > --- /dev/null
> > +++ b/debian/patches/cross.patch
> > @@ -0,0 +1,15 @@
> > +Description: Do not hardcode pkg-config, build the needed file with
> build arch compiler
> > +Author: Nilesh Patra 
> > +Last-Update: 2021-03-17
> > +--- a/make_unix.sh
> >  b/make_unix.sh
> > +@@ -25,7 +25,7 @@
> > +
> > + # the actual compile
> > + echo "compiling using $CC..." >&2
> > +-$CC -Wall -pedantic $CFLAGS $CPPFLAGS $LDFLAGS src/tools/txt2c.c
> `pkg-config --cflags lua5.3` -o src/tools/txt2c
> > ++$CC_FOR_BUILD -Wall -pedantic $CFLAGS $CPPFLAGS $LDFLAGS
> src/tools/txt2c.c `$PKG_CONFIG --cflags lua5.3` -o src/tools/txt2c
>
> Here, you are mixing build and host tools.


Yes, because that is needed to run a generated file, for example as done in
#948477
The outputs of generated file for host arch looks good


> Given that this apparently
> works for you, it seems like lua isn't necessary at all.


Yes, forgot removing that one, thanks


> Can you try
> dropping the lua5.3 cflags? Failing that, you should likely use
> PKG_CONFIG_FOR_BUILD here.
>

Righty.

>  override_dh_auto_build:
> > - sh make_unix.sh
> > + CC_FOR_BUILD=$(CC_FOR_BUILD) CC=$(CC) PKG_CONFIG=$(PKG_CONFIG) sh
> make_unix.sh
>
> If you set the variable DPKG_EXPORT_BUILDTOOLS=nonempty before including
> buildtools.mk, you can drop these assignments.
>

Didn't know about this, thanks! Incorporated and pushed to salsa.

Nilesh

Bug#946791: io.weight cannot be enabled in recent Debian kernel package

[Michael Biebl]

Control: retitle -1 Please enable CONFIG_IOSCHED_BFQ=y

On Thu, 26 Dec 2019 23:17:13 +0900 Ryutaroh Matsumoto
 wrote:
> Source: linux
> Followup-For: Bug #946791
> Control: tags -1 + patch
> 
> Dear Maintainer,
> 
> I reported that IOWeight config item in systemd has no effect
> on recent Debian kernels. I found the root cause.
> io.weight was changed to io.bfq.weight, and recent systemd sets
> values of IOWeight to io.bfq.weight as
> 
>
https://github.com/systemd/systemd/commit/2dbc45aea747f25cc1c3848fded2ec0062f96bcf
> 
> For io.bfq.weight to appear in cgroup v2 filesystem, the bfq kernel
> module must be loaded. Addition of "bfq" to /etc/initramfs-
tools/modules
> solved this issue. Since the systemd needs bfq module to be loaded,
> changing CONFIG_IOSCHED_BFQ=m to CONFIG_IOSCHED_BFQ=y in kernel
config
> seems suitable.
> 
> If the Debian kernel team considers this issue to be handled by
another
> package, e.g. initramfs-tools or systemd, please reassign this.
> If this issue is considered not being a bug, please close this.
> 

Fwiw, the fedora kernel in F33 uses

# grep CONFIG_IOSCHED_BFQ /boot/config-5.10.22-200.fc33.x86_64 
CONFIG_IOSCHED_BFQ=y

I think using CONFIG_IOSCHED_BFQ=y instead of loading it via initramfs-
tools makes more sense (assuming it is safe to enable).


Regards,
Michael


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