Bug#980489: cal originally had highlighting on

[Stephane Chazelas]

Colour highlighting was intentionally removed when ncal is
invoked as cal, as per
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904839
cal being there only for historical purposes to give the old
style output and with the same API (see also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867995)

I agree the man page could be improved to make it clear
highlighting is not enabled when invoked as cal or that ncal
should be the preferred command.

When invoked as ncal, the current day is highlighted, and you
can use ncal -C to get the same layout as with cal and
highlighting.

See also GNU cal (gcal) which highlights the current day and
has many (insanely) more features (the one I use personally is
gcal .. or gcal .+ to get a three month calendar; similar to
ncal -bB1 -A1 and ncal -bA2 respectively).

Its output is similar to that of ncal -b with Monday first as
is more natural in most parts of the world.

-- 
Stephane

Bug#992122: golang-github-prometheus-client-golang-dev: new "collectors" package needed for packaging

[Peymaneh Nejad]

Package: golang-github-prometheus-client-golang-dev
Version: 1.9.0-2
Severity: wishlist

Dear maintainers,

I am working on packaging the Caddy web server[1] which requires the
package github.com/prometheus/client_golang/prometheus/collectors that
was added recently in these commits[2] and is included in v1.11.0

Are you planning to update the package anytime soon? 

If not: would you consider backporting this module and uploading a new revision?
I could also prepare a patch for that.

Of course since we're in freeze anyway there is no hurry.

kind regards,
Peymaneh

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890
[2] 
https://github.com/prometheus/client_golang/commits/master/prometheus/collectors

Bug#923974: packages.debian.org filelist incorrect (for some archs)

[Felix Lechner]

Hi,

> The file list is not correct
>   - eg. /usr/sbin/service et.al. are not in the package (anymore since
>   several years).

The condition described here will potentially be fixed by the second
commit ("Test for link on suite level") in my recent merge request.
[1] My testing there confirmed a suspicion that the file lists were
not being updated at all. For a longer explanation, please have a look
at Bug#977006 or Bug#977743.

This bug should be evaluated when the MR [1] has been accepted. Thanks!

Kind regards
Felix Lechner

[1] https://salsa.debian.org/webmaster-team/packages/-/merge_requests/20

Bug#992121: linux-image-5.10.0-8-amd64: kernel oops and subsequent hard crash in bluetooth bt_sock_poll, regression, upstream patch

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Tim,

On Thu, Aug 12, 2021 at 02:32:52PM +1000, Tim Connors wrote:
> Package: src:linux
> Version: 5.10.46-4
> Severity: important
> Tags: patch
> 
> Looks like debian stable is going to get a kernel that crashes a few
> minutes after you start using bluetooth for audio streaming to
> headphones!
> 
> Happened a couple of times, within a few minutes of starting to use
> bluetooth.  First time, didn't get any syslogs.  Machine was hard
> locked for 30 minutes, only responded to alt-sysrq-s,u,b (sysrq didn't
> otherwise log anything).
> 
> Second time, got a crash in bt_sock_poll, plenty of things still got
> logged to syslog until I rebooted, but the machine was otherwise
> unusable - X deadlocked, and ssh not responding.  If it's the same
> crash every time, that pretty much makes bluetooth audio streaming
> unusable on this machine.
> 
> https://www.spinics.net/lists/linux-bluetooth/msg88356.html
> 
> points to a patch that has supposedly already been applied to
> bluetooth-next, but is definitely not in linux-source-5.10 5.10.46-4
> (testing).
> 
> Current code still reads:
> 
> /* cleanup runtime environment */
> remove_wait_queue(sk_sleep(session->intr_sock->sk), &intr_wait);
> remove_wait_queue(sk_sleep(session->intr_sock->sk), &ctrl_wait);
> wake_up_interruptible(&session->report_queue);
> hidp_del_timer(session);
> 
> Second remove_wait_queue should be: ctrl_sock->sk

Would it be possible that you check if the upstream commit
https://git.kernel.org/linus/cca342d98bef68151a80b024f7bf5f388d1fbdea
fixes the issue?

It was not yet queued for the 5.10.y series, but if yes, this should
go to stable@ so that we then can pick it up for either cherry-picking
for the next bullseye upload (or a rebase to the latest 5.10.y in a
point release).

Regards,
Salvatore

Bug#992119: virt-install --cloud-init doesn't work with Debian genericcloud images

[David Mandelberg]

Package: virtinst
Version: 1:3.2.0-3

I tried to use virt-install's --cloud-init option with a genericcloud 
image[0], and cloud-init in the image didn't seem to find the ISO that 
virt-install set up. From the XML, it looks like virt-install made a 
SATA drive:



  
  file='/var/lib/libvirt/boot/virtinst-5wk0hc7u-cloudinit.iso' index='1'/>

  
  
  
  
  


https://cloud.debian.org/images/cloud/ says that genericcloud "is 
smaller than `generic` by excluding drivers for physical hardware", so 
I'm guessing the reason cloud-init couldn't find the ISO is that 
genericcloud images don't include SATA drivers? I tried a generic image 
instead, and it worked.


Would it make sense to change virt-install to use virtio for the ISO 
file? (Or some other way of providing the ISO that genericcloud has 
drivers for?)


 [0] 
https://cloud.debian.org/images/cloud/bullseye/daily/20210808-728/debian-11-genericcloud-amd64-daily-20210808-728.raw 

Bug#990674: s2-geometry-library: The Homepage is wrong in metadata

[tony mancill]

On Sun, Jul 04, 2021 at 10:17:22AM -0300, Emmanuel Arias wrote:
> Source: s2-geometry-library
> Version: 1.0.1-2
> Severity: normal
> X-Debbugs-Cc: eam...@yaerobi.com
> 
> Dear Maintainer,
> 
> s2-geometry-library is pointing to [0] and that's wrong. The
> correct homepage should be [1].
> 
> [0] https://s2geometry.io/
> [1] https://github.com/google/s2-geometry-library-java

Hello Emmanuel,

Thank you for the bug report.  At the time the package was created, we
used the fork here [2], but there is very recent activity, including a
new release at the repo you suggest [1].  I will check with Sudip to be
sure, but I think we should probably update the debian/watch file to use
[1] as well.

Cheers,
tony

[2] https://github.com/io-sgr/s2-geometry-library-java

Bug#977743: packages.debian.org: file list broken for some packages

[Felix Lechner]

Control: tags -1 + patch

Hi Rebecca,
Hi Louis-Philippe,

> On the packages.d.o pages of arch:all packages from sid, bullseye or
> experimental, the "list of files" link gives the error message "No such
> package in this suite on this architecture."

First of all, thank you both for the excellent detective work! The
issue was caused by commit 81824d23 in daklib [1] in which the archive
started to provide—on Oct 25, 2020 7:08am PDT and for releases past
buster—separate Contents files containing the file paths in Arch:all
packages.

>From what I can tell, the code generating the web pages for
packages.d.o did not read those files for releases post buster.

I filed a merge request that I believe solves the issue. [2] It was
tested on the Debian node that generates the web pages
(picconi.debian.org). It comes with two caveats:

(1) Due to insufficient permissions I created an improvised
environment, described further below, that may not fully mimic
production runs.

(2) The second commit addresses a condition that should have prevented
the code from performing at all, although apparently it didn't. That
opens up the possibility that I misunderstood the existing code and,
for my tests, created a runtime environment that differed appreciably
from production.

To test the MR, I cloned my feature branch into my home directory on
picconi.debian.org. I then applied the local patch below this message.

Next I ran the command './bin/setup-site /home/lechner/packages
packages.debian.org' as suggested in ./INSTALL and started the test
with '/home/lechner/packages/cron.d/200process_archive'. (I also
created the folders './files/db' and './tmp' in the base directory of
the Git repo, which was my working directory.) The run finished
without errors and produced the attached log.

Now the databases are more even in size across architectures. Here is
a partial listing of the relevant folder ./files/db: (The full listing
for *.db is attached.)

   0 filelists_sid_all.db
129M filelists_sid_alpha.db
132M filelists_sid_amd64.db
208M filelists_sid_arm64.db
126M filelists_sid_armel.db
128M filelists_sid_armhf.db
128M filelists_sid_hppa.db
131M filelists_sid_i386.db
128M filelists_sid_m68k.db
127M filelists_sid_mips64el.db
127M filelists_sid_mipsel.db
123M filelists_sid_powerpcspe.db
132M filelists_sid_ppc64.db
129M filelists_sid_ppc64el.db
130M filelists_sid_riscv64.db
127M filelists_sid_s390x.db
125M filelists_sid_sh4.db
129M filelists_sid_sparc64.db
130M filelists_sid_x32.db

All packages for Arch:all are symbolic links (human size zero). I am
not sure why arm64 is so large.

Perhaps someone with the appropriate user privileges could pull my
feature branch from the merge request [2] into
/srv/packages.debian.org and test it on the live system. The cron run
can be triggered by hand.

A better long-term solution would be to produce separate transfer
files for Arch:all, but that may not work until buster is being
dropped from the archive. Thank you both for your hard work!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/ftp-team/dak/-/commit/81824d2326f5cc50fdcb95c81f9f26864aebaa15
[2] https://salsa.debian.org/webmaster-team/packages/-/merge_requests/20

* * *

[local patch]

lechner@picconi:~/packages$ git diff
diff --git a/bin/parse-contents b/bin/parse-contents
index a1bfc35..7c5f166 100755
--- a/bin/parse-contents
+++ b/bin/parse-contents
@@ -51,6 +51,9 @@ my @sections = @SECTIONS;
 # Add empty section, need to search Contents directly at dist root,
for debports compat
 push(@sections, "");

+$DBDIR = "/home/lechner/packages/files/db";
+my $TMPDIR = "/home/lechner/packages/tmp";
+
 my %debports_hash;
 # copy from config.sh ${arch_debports}
 @debports_hash{qw( alpha hppa ia64 m68k powerpcspe ppc64 riscv64 sh4
sparc64 x32 )} = ();
@@ -166,9 +169,9 @@ for my $suite (@suites) {

 # Piping from sort's output doesn't really scale with 16 GB worth
 # of input, so let's store in a temporary file:
-my $rev_path_file = "$TOPDIR/tmp/${suite}.sorted";
+my $rev_path_file = "$TMPDIR/${suite}.sorted";
 print "Merging reverse path lists for ${suite}...\n";
-system("sort -T $TOPDIR/tmp -m $DBDIR/reverse_${suite}_*.txt -o
${rev_path_file}") == 0
+system("sort -T $TMPDIR -m $DBDIR/reverse_${suite}_*.txt -o
${rev_path_file}") == 0
or die "Failed to build merged list";
 my $rev_path_size = stat($rev_path_file)->size;

diff --git a/cron.d/200process_archive b/cron.d/200process_archive
index 29a7385..eecd412 100755
--- a/cron.d/200process_archive
+++ b/cron.d/200process_archive
@@ -5,13 +5,13 @@
 cd "$topdir"

 date
-./bin/parse-translations --english-only
-date
-./bin/parse-packages
-date
-./bin/parse-sources
-date
-./bin/parse-translations
-date
-./bin/parse-contents
+#./bin/parse-translations --english-only
+#date
+#./bin/parse-packages
+#date
+#./bin/parse-sources
+#date
+#./bin/parse-translations
+#date
+/home/lechner/packages/bin/parse-contents
 date

* * *


parse-contents.log.xz
Description: B

Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers

[Ross Vandegrift]

Control: severity -1 serious

On Wed, Aug 11, 2021 at 03:12:37PM -0700, Noah Meyerhans wrote:
> On Wed, Aug 11, 2021 at 02:05:39PM -0700, Noah Meyerhans wrote:
> > 2. I will implement a temporary change to our bullseye images to revert the
> >sudoers file to use the old syntax that cloud-init will detect.
> 
> This is implemented by
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/263

Great, thanks - adjusting severity per today's discussion.

Ross

Bug#988911: regression: claims that udebs require a Standards-Version header

[Felix Lechner]

Hi,

On Wed, Aug 11, 2021 at 6:02 PM Sean Whitton  wrote:
>
> Having an S-V field makes it possible for maintainers

Enabling people is great! My remark was imprecise: I merely wish the
field were optional once again, and not required.

Lintian would drop the warning right away.

Kind regards
Felix Lechner

Bug#988911: regression: claims that udebs require a Standards-Version header

[Sean Whitton]

Hello Felix,

On Fri 21 May 2021 at 04:04AM -07, Felix Lechner wrote:

> On a side note, I am personally not convinced that a declaration of
> the Standards-Version solves more problems than it creates. For most
> packages, it is perpetually out of date, and Lintian's other packaging
> hints are more helpful. I already made efforts to reduce its impact on
> contributors [2] and would prefer if the field were dropped from our
> package specifications.

Having an S-V field makes it possible for maintainers to allow their
package to fall behind Policy in a controlled way.  Maintainers can
prioritise working on other things without losing track of how far
behind Policy the package has got.  When it does become time to update,
that update can be done efficiently.  This gives maintainers more
control over the time they spend on maintaining the package.

Lintian is useful for ensuring Policy compliance, but its role in
maintainer workflows is more amorphous than the upgrading checklist's.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#992120: network-manager-gnome: nm-connection-editor does not have a checkbox to enable 802.1x security

[dolphin oracle]

Package: network-manager-gnome
Version: 1.20.0-3
Severity: normal
X-Debbugs-Cc: dolphinora...@gmail.com

Dear Maintainer,

   * What led up to the situation?

 Running the debian bullseye RC3 live Xfce medium.

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

 opened the Edit connections dialog and selected 802.1x Security tab

   * What was the outcome of this action?

 dialog form was disabled/inactive.  options are not selectable, and the 
enable checkbox is missing

   * What outcome did you expect instead?

 that options could be set up.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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 network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  libatk1.0-0   2.36.0-2
ii  libayatana-appindicator3-10.5.5-2
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libjansson4   2.13.1-1.1
ii  libmm-glib0   1.14.12-0.2
ii  libnm01.30.0-2
ii  libnma0   1.8.30-1
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libsecret-1-0 0.20.4-2
ii  libselinux1   3.1-3
ii  network-manager   1.30.0-2
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.36.0-1
ii  iso-codes4.6.0-1
ii  mobile-broadband-provider-info   20201225-1
ii  notification-daemon  3.20.0-4
ii  xfce4-notifyd [notification-daemon]  0.6.2-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#982122: redis: experimental package OOMs s390x buildds

[Chris Lamb]

Julien Cristau wrote:

> It'd be appreciated if you could make fixing this a priority, and
> refrained from uploading further versions until then.

Sure. Just to say though, your message was rather unfortunate to
receive given this latest upload was, in part, an attempt to resolve
this very issue.


Regards,

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

Bug#992118: squid3-dbg: uninstallable cruft package from src:squid3 in jessie-elts

[Andreas Beckmann]

Package: squid3-dbg
Version: 3.4.8-6+deb8u9
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: close -1

jessie-elts has squid3-dbg 3.4.8-6+deb8u9, but src:squid3 (and therefore
the squid3 binary package, too) is already at 3.5.23-5+deb8u4 in
jessie-elts, rendering the -dbg package uninstallable. The -dbg package
is no longer built by the newer source package, leaving around some
uninstallable cruft packages.

This is probably not an actionable bug.
Its primary intention is to mark the corresponding piuparts failures as
known bugs.

Andreas

Bug#992117: buster-pu: package node-tar/4.4.6+ds1-3+deb10u1

[Yadd]

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

[ Reason ]
node-tar is vulnerable to 2 CVE:
 * #992110, CVE-2021-32803: arbitrary File Creation/Overwrite
   vulnerability via insufficient symlink protection
 * #992111, CVE-2021-32804: arbitrary File Creation/Overwrite
   vulnerability due to insufficient absolute path sanitization

[ Impact ]
2 medium vulnerabilities

[ Tests ]
Test not launched in Buster

[ Risks ]
Low risk: test passed and upstream patch applied with minor changes

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

[ Changes ]
Add new checks

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 83bacd9..8b3a42d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+node-tar (4.4.6+ds1-3+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Remove paths from dirCache when no longer dirs
+(Closes: #992110, CVE-2021-32803)
+  * Strip absolute paths more comprehensively
+(Closes: #992111, CVE-2021-32804)
+
+ -- Yadd   Thu, 12 Aug 2021 00:06:36 +0200
+
 node-tar (4.4.6+ds1-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2021-32803.patch 
b/debian/patches/CVE-2021-32803.patch
new file mode 100644
index 000..44e29a4
--- /dev/null
+++ b/debian/patches/CVE-2021-32803.patch
@@ -0,0 +1,106 @@
+Description: Remove paths from dirCache when no longer dirs
+Author: isaacs 
+Origin: upstream, https://github.com/npm/node-tar/commit/46fe3508
+Bug: https://github.com/npm/node-tar/security/advisories/GHSA-r628-mhmh-qjhw
+Bug-Debian: https://bugs.debian.org/992110
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-08-11
+
+--- a/lib/unpack.js
 b/lib/unpack.js
+@@ -407,6 +407,20 @@
+   // check if a thing is there, and if so, try to clobber it
+   [CHECKFS] (entry) {
+ this[PEND]()
++
++// if we are not creating a directory, and the path is in the dirCache,
++// then that means we are about to delete the directory we created
++// previously, and it is no longer going to be a directory, and neither
++// is any of its children.
++if (entry.type !== 'Directory') {
++  for (const path of this.dirCache.keys()) {
++if (path === entry.absolute ||
++path.indexOf(entry.absolute + '/') === 0 ||
++path.indexOf(entry.absolute + '\\') === 0)
++  this.dirCache.delete(path)
++  }
++}
++
+ this[MKDIR](path.dirname(entry.absolute), this.dmode, er => {
+   if (er)
+ return this[ONERROR](er, entry)
+@@ -468,6 +482,15 @@
+   }
+ 
+   [CHECKFS] (entry) {
++if (entry.type !== 'Directory') {
++  for (const path of this.dirCache.keys()) {
++if (path === entry.absolute ||
++path.indexOf(entry.absolute + '/') === 0 ||
++path.indexOf(entry.absolute + '\\') === 0)
++  this.dirCache.delete(path)
++  }
++}
++
+ const er = this[MKDIR](path.dirname(entry.absolute), this.dmode)
+ if (er)
+   return this[ONERROR](er, entry)
+--- a/test/unpack.js
 b/test/unpack.js
+@@ -2417,3 +2417,55 @@
+ 
+   t.end()
+ })
++
++t.test('drop entry from dirCache if no longer a directory', t => {
++  const dir = path.resolve(unpackdir, 'dir-cache-error')
++  mkdirp.sync(dir + '/sync/y')
++  mkdirp.sync(dir + '/async/y')
++  const data = makeTar([
++{
++  path: 'x',
++  type: 'Directory',
++},
++{
++  path: 'x',
++  type: 'SymbolicLink',
++  linkpath: './y',
++},
++{
++  path: 'x/ginkoid',
++  type: 'File',
++  size: 'ginkoid'.length,
++},
++'ginkoid',
++'',
++'',
++  ])
++  t.plan(2)
++  const WARNINGS = {}
++  const check = (t, path) => {
++t.equal(fs.statSync(path + '/x').isDirectory(), true)
++t.equal(fs.lstatSync(path + '/x').isSymbolicLink(), true)
++t.equal(fs.statSync(path + '/y').isDirectory(), true)
++t.strictSame(fs.readdirSync(path + '/y'), [])
++t.throws(() => fs.readFileSync(path + '/x/ginkoid'), { code: 'ENOENT' })
++t.strictSame(WARNINGS[path], [
++  'Cannot extract through symbolic link',
++])
++t.end()
++  }
++  t.test('async', t => {
++const path = dir + '/async'
++new Unpack({ cwd: path })
++  .on('warn', (msg) => WARNINGS[path] = [msg])
++  .on('end', () => check(t, path))
++  .end(data)
++  })
++  t.test('sync', t => {
++const path = dir + '/sync'
++new UnpackSync({ cwd: path })
++  .on('warn', (msg) => WARNINGS[path] = [msg])
++  .end(data)
++check(t, path)
++  })
++})
diff --git a/debian/patches/CVE-2021-32804.patch 
b/debian/patches/CVE-2021-32804.patch
new file mode 100644
index 000..d8b23f4
--- /dev/null
+++ b/debian/patches/CVE-2021-32804.patch
@@ -0,0 +1,150 @@
+Description: strip absolute paths more com

Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers

[Noah Meyerhans]

On Wed, Aug 11, 2021 at 02:05:39PM -0700, Noah Meyerhans wrote:
> 2. I will implement a temporary change to our bullseye images to revert the
>sudoers file to use the old syntax that cloud-init will detect.

This is implemented by
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/263

Bug#992116: release-notes: Add breakage from merged-/usr-via-aliased-dirs

[Guillem Jover]

Package: release-notes
Severity: important

Hi,

While this breakage is apparently not going to be reverted, the users
deserve to know what they are getting into, to avoid hard to track
bugs and misbehavior.

To me this would be worth mentioning on its own in addition to the
note I added to the "deprecation" entry, but repetition is not ideal
and I can see push back on that too, so I'd rather have it listed
just once than not at all.

Thanks,
Guillem
From 134021b9dff9ad4e52a7446ce57dbfc0339b4754 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 11 Aug 2021 21:24:59 +0200
Subject: [PATCH] issues.dbk: Add breakage from merged-/usr-via-aliased-dirs

While this breakage is apparently not going to be reverted, the users
deserve to know what they are getting into, to avoid hard to track
bugs and misbehavior. In particular dpkg has *never* supported this
layout.
---
 en/issues.dbk | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index d3321953..bbd772ad 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -893,6 +893,25 @@ Environment=SYSTEMD_SULOGIN_FORCE=1
 role="package">usrmerge package exists to do
 the conversion if desired.
   
+  
+Take into account that this layout has never been supported by
+the dpkg suite and breaks several of its core assumptions. Included
+among these are: not being able to notice file conflicts thus
+causing silent overwrites, disappearing pathnames on upgrades,
+failing to apply stat-overrides, missed trigger activations, failing
+to find pathnames on search queries, etc.
+For more information see the https://wiki.debian.org/Teams/Dpkg/FAQ#unsupported-merged-usr-via-aliased-dirs";>
+dpkg FAQ entry.
+  
+  
+It can also cause problems with any other software or subsystem
+that tracks filesystem objects, and might be doing string-wise
+comparisons. An example of such interfaces is
+/etc/shells, where the entries need to be
+duplicated or programs using that file directly or indirectly
+might fail to match them.
+  
 	
 
 
-- 
2.32.0

Bug#992102: ifenslave: Bond interfaces are not deleted

[Oleander Reis]

Package: ifenslave
Version: 2.12
Severity: important
Tags: patch

The if-post-down hook does not delete the bonding interface.
Therefore e.g. „ifdown -a; ifup -a“ does not work without manually
removing it using „ip link dev“ or „rmmod bonding“ in between.

The attached patch should fix that.
diff --git a/debian/ifenslave.if-post-down b/debian/ifenslave.if-post-down
index 0113fd4..177a06c 100755
--- a/debian/ifenslave.if-post-down
+++ b/debian/ifenslave.if-post-down
@@ -56,10 +56,13 @@ sysfs_remove_all arp_ip_target
 read -r slaves < "$BOND_PARAMS/slaves"
 for slave in $slaves ; do
 	# This is supposed to have the side effect of freeing the interface.
-	ifquery --state "$slave" && ifdown $v "$slave"
+	ifquery --state "$slave" >/dev/null 2>&1 && ifdown $v "$slave"
 
 	# Anyway, ensure $slave is free.
 	if [ -f "/sys/class/net/$slave/master/bonding/slaves" ] ; then
 		echo "-$slave" > "$BOND_PARAMS/slaves" 2> /dev/null
 	fi
 done
+
+# Delete the bond interface
+ip link del dev "$IFACE"

Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers

[Noah Meyerhans]

On Sat, Aug 07, 2021 at 08:30:17PM -0600, Ross Vandegrift wrote:
> > > > In the sudoers file there is a duplicate includedir
> > > > statement; at the end of the file you will find the following contents:
> > > > 
> > > > """
> > > > # See sudoers(5) for more information on "@include" directives:
> > > > 
> > > > @includedir /etc/sudoers.d
> > > > 
> > > > # Added by cloud-init v. 20.4.1 on Wed, 28 Jul 2021 20:40:05 +
> > > > #includedir /etc/sudoers.d
> > >^
> > > 
> > > Is this a copy/paste mistake?  It looks commented out.
> > 
> > It's isn't a copy/paste mistake, nor is it commented out. This was the
> > syntax used up to Buster, but from Bullseye the new @includedir syntax is
> > preferred (but sudo accepts both). That's presumably why it was changed in
> > sudo.
> 
> 👍, thanks.
> 
> This is fixed upstream in 21.1, though many other changes are included.  I
> didn't look through the list carefully.  The fix for this particular bug is
> trivial, I staged it here:
>  https://salsa.debian.org/rvandegrift/cloud-init/-/tree/debian/bullseye
> 
> Either a targeted fix or a new upstream release will need to wait for a stable
> update at this point.

Summarizing the path forward based on the discussion from today's cloud
team meeting:

1. I will upload new cloud-init packages to unstable containing the fix.
2. I will implement a temporary change to our bullseye images to revert the
   sudoers file to use the old syntax that cloud-init will detect.
3. The cloud team will work with the stable release managers to get updated
   packages containing this fix accepted for the first bullseye point
   release.
4. Once bullseye includes a fixed version of cloud-init, we will revert
   (2) from our image build configuration.

noah

Bug#992115: Stop using the NVD severity

[Moritz Muehlenhoff]

Package: security-tracker
Severity: normal

We should stop using/displaying the NVD severity in the Security Tracker. Anyone
is free to look up whatever external data source they want, but we should not
give NVD legitimacy by showing in the Security Tracker.

Bug#990428: ifenslave: Bonding not working on bullseye (using bond-slaves config)

[Oleander Reis]

Tags: patch

This regression is currently up for release in the next stable release
of Debian this week! We think this is supposed to be fixed in #987842
but it is not.

In your case you could simply remove the stanzas for enp4s0f0
and enp4s0f1 which would leave you with just the stanza for bond1:

iface bond1 inet static
  bond-slaves enp4s0f0 enp4s0f1

That should work but it is still a regression as it breaks
configuration which worked before.
Therefore and also for more complex scenarios where configuration
specific for children (or s-word) interfaces is needed see the attached
patch which kind of restores the old behaviour.
It ensures that only already up interfaces with bonding configuration
are skipped.

That new / broken behaviour was introduced with the following commit
which had multiple issues. Most of them are already fixed.

commit 326c2b142943cc98798bab653ee96ade91ae58af
Author: Guus Sliepen 
Date:   Tue May 8 21:02:30 2018 +0200

Make a clear distinction between configuring masters and slaves.

In particular, don't configure a master interface from a slave
stanza. Instead, require that a stanza for the master exists, and
call ifup recursively on it if necessary.
diff --git a/debian/ifenslave.if-pre-up b/debian/ifenslave.if-pre-up
index 7579d68..97a13e5 100755
--- a/debian/ifenslave.if-pre-up
+++ b/debian/ifenslave.if-pre-up
@@ -83,8 +83,8 @@ enslave_slaves()
 		export IFENSLAVE_ENV_NAME="IFUPDOWN_$slave"
 		IFUPDOWN_IFACE="$(printenv "$IFENSLAVE_ENV_NAME")"
 		unset IFENSLAVE_ENV_NAME
-		if ifquery --state "$slave" 2>/dev/null || [ -n "$IFUPDOWN_IFACE" ] ; then
-			# Skipping interface that's already up or being configured
+		if ($(ifquery --state "$slave" >/dev/null 2>&1) && $(ifquery "$slave" | grep -q bond-master)) || [ -n "$IFUPDOWN_IFACE" ] ; then
+			# Skipping interface that's already up or being configured and has bonding configuration
 			continue
 		else
 			# Ensure $slave is down.

Bug#992114: bullseye-pu: package node-tar/6.0.5+ds1+~cs11.3.9-1+deb11u1

[Yadd]

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

[ Reason ]
node-tar is vulnerable to 2 CVE:
 * #992110, CVE-2021-32803: arbitrary File Creation/Overwrite
   vulnerability via insufficient symlink protection
 * #992111, CVE-2021-32804: arbitrary File Creation/Overwrite
   vulnerability due to insufficient absolute path sanitization

[ Impact ]
2 medium vulnerabilities

[ Tests ]
Test updated (not fully launched because it needs a newer node-tap)

[ Risks ]
Low risk: test passed and upstream patch applied with minor changes

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

[ Changes ]
Add new checks

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index f8f5426..e16bf2f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+node-tar (6.0.5+ds1+~cs11.3.9-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Remove paths from dirCache when no longer dirs
+(Closes: #992110, CVE-2021-32803)
+  * Strip absolute paths more comprehensively
+(Closes: #992111, CVE-2021-32804)
+
+ -- Yadd   Wed, 11 Aug 2021 21:50:15 +0200
+
 node-tar (6.0.5+ds1+~cs11.3.9-1) unstable; urgency=medium
 
   [ Xavier Guimard ]
diff --git a/debian/patches/CVE-2021-32803.patch 
b/debian/patches/CVE-2021-32803.patch
new file mode 100644
index 000..5328879
--- /dev/null
+++ b/debian/patches/CVE-2021-32803.patch
@@ -0,0 +1,106 @@
+Description: Remove paths from dirCache when no longer dirs
+Author: isaacs 
+Origin: upstream, https://github.com/npm/node-tar/commit/9dbdeb6
+Bug: https://github.com/npm/node-tar/security/advisories/GHSA-r628-mhmh-qjhw
+Bug-Debian: https://bugs.debian.org/992110
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-08-11
+
+--- a/lib/unpack.js
 b/lib/unpack.js
+@@ -461,6 +461,19 @@
+ this.reservations.reserve(paths, done => this[CHECKFS2](entry, done))
+   }
+   [CHECKFS2] (entry, done) {
++// if we are not creating a directory, and the path is in the dirCache,
++// then that means we are about to delete the directory we created
++// previously, and it is no longer going to be a directory, and neither
++// is any of its children.
++if (entry.type !== 'Directory') {
++  for (const path of this.dirCache.keys()) {
++if (path === entry.absolute ||
++path.indexOf(entry.absolute + '/') === 0 ||
++path.indexOf(entry.absolute + '\\') === 0)
++  this.dirCache.delete(path)
++  }
++}
++
+ this[MKDIR](path.dirname(entry.absolute), this.dmode, er => {
+   if (er) {
+ done()
+@@ -528,6 +541,15 @@
+   }
+ 
+   [CHECKFS] (entry) {
++if (entry.type !== 'Directory') {
++  for (const path of this.dirCache.keys()) {
++if (path === entry.absolute ||
++path.indexOf(entry.absolute + '/') === 0 ||
++path.indexOf(entry.absolute + '\\') === 0)
++  this.dirCache.delete(path)
++  }
++}
++
+ const er = this[MKDIR](path.dirname(entry.absolute), this.dmode, 
neverCalled)
+ if (er)
+   return this[ONERROR](er, entry)
+--- a/test/unpack.js
 b/test/unpack.js
+@@ -2577,3 +2577,56 @@
+ cwd: dir + '/sync', strict: true,
+   }).end(data), poop, 'sync')
+ })
++
++t.test('drop entry from dirCache if no longer a directory', t => {
++  const dir = path.resolve(unpackdir, 'dir-cache-error')
++  mkdirp.sync(dir + '/sync/y')
++  mkdirp.sync(dir + '/async/y')
++  const data = makeTar([
++{
++  path: 'x',
++  type: 'Directory',
++},
++{
++  path: 'x',
++  type: 'SymbolicLink',
++  linkpath: './y',
++},
++{
++  path: 'x/ginkoid',
++  type: 'File',
++  size: 'ginkoid'.length,
++},
++'ginkoid',
++'',
++'',
++  ])
++  t.plan(2)
++  const WARNINGS = {}
++  const check = (t, path) => {
++t.equal(fs.statSync(path + '/x').isDirectory(), true)
++t.equal(fs.lstatSync(path + '/x').isSymbolicLink(), true)
++t.equal(fs.statSync(path + '/y').isDirectory(), true)
++t.strictSame(fs.readdirSync(path + '/y'), [])
++t.throws(() => fs.readFileSync(path + '/x/ginkoid'), { code: 'ENOENT' })
++t.strictSame(WARNINGS[path], [
++  'TAR_ENTRY_ERROR',
++  'Cannot extract through symbolic link',
++])
++t.end()
++  }
++  t.test('async', t => {
++const path = dir + '/async'
++new Unpack({ cwd: path })
++  .on('warn', (code, msg) => WARNINGS[path] = [code, msg])
++  .on('end', () => check(t, path))
++  .end(data)
++  })
++  t.test('sync', t => {
++const path = dir + '/sync'
++new UnpackSync({ cwd: path })
++  .on('warn', (code, msg) => WARNINGS[path] = [code, msg])
++  .end(data)
++check(t, path)
++  })
++})
diff --git a/debian/patches/CVE-2021-32804.patch 
b/debian/patches/CVE-2021-32

Bug#968368: ifenslave: Option bond-master fails to add interface to bond

[Oleander Reis]

This regression is currently up for release in the next stable release
this week!

Thanks for your patch Sami.
We've found a small issue with it as the order of redirections is
significant. „2>&1 >/dev/null“ does only redirect the standard output
to /dev/null. Please find attached a modified version of the patch
which fixes this order („>/dev/null 2>&1“) and redirects also stderr
as desired.
Furthermore it passes -v to to subsequent calls of ifup when needed.

Best regards
Oleander
diff --git a/debian/ifenslave.if-pre-up b/debian/ifenslave.if-pre-up
index 7579d68..ce8b161 100755
--- a/debian/ifenslave.if-pre-up
+++ b/debian/ifenslave.if-pre-up
@@ -151,13 +151,14 @@ setup_master()
 	# active_slave must be set after mode and after enslavement.
 	# The slave must be up and the underlying link must be up too.
 	# FIXME: We should have a way to write an empty string to active_slave, to set the active_slave to none.
+	[ "$VERBOSITY" = 1 ] && v=-v
 	if [ -n "$IF_BOND_ACTIVE_SLAVE" ] ; then
 		if [ "$IF_BOND_ACTIVE_SLAVE" = "none" ] ; then
 			sysfs active_slave ""
 		else
 			# Need to force interface up before. Bonding will refuse to activate a down interface.
-			if ifquery -l "$IF_BOND_ACTIVE_SLAVE" 2>/dev/null ; then
-ifup "$IF_BOND_ACTIVE_SLAVE"
+			if ifquery -l "$IF_BOND_ACTIVE_SLAVE" >/dev/null 2>&1; then
+ifup $v "$IF_BOND_ACTIVE_SLAVE"
 			else
 ip link set "$IF_BOND_ACTIVE_SLAVE" up
 			fi
@@ -194,7 +195,7 @@ setup_master_device() {
 
 setup_slave_device() {
 	# Require the bond master to have an iface stanza
-	if ! ifstate -l "$IF_BOND_MASTER" 2>/dev/null ; then
+	if ! ifquery -l "$IF_BOND_MASTER" >/dev/null 2>&1; then
 		echo "No iface stanza found for master $IF_BOND_MASTER" >&2
 		exit 1
 	fi
@@ -203,14 +204,15 @@ setup_slave_device() {
 	export IFENSLAVE_ENV_NAME="IFUPDOWN_$IF_BOND_MASTER"
 	IFUPDOWN_IF_BOND_MASTER="$(printenv "$IFENSLAVE_ENV_NAME")"
 	unset IFENSLAVE_ENV_NAME
+	[ "$VERBOSITY" = 1 ] && v=-v
 	if [ -z "$IFUPDOWN_IF_BOND_MASTER" ] ; then
-		ifquery --state "$IF_BOND_MASTER" 2>/dev/null || ifup "$IF_BOND_MASTER"
+		ifquery --state "$IF_BOND_MASTER" >/dev/null 2>&1 || ifup $v "$IF_BOND_MASTER"
 	fi
 
 	# Enslave it to the master
-	ip link set "$slave" down 2>/dev/null
-	if ! sysfs_add slaves "$slave" 2>/dev/null ; then
-		echo "Failed to enslave $slave to $BOND_MASTER." >&2
+	ip link set "$1" down 2>/dev/null
+	if ! sysfs_add slaves "$1" 2>/dev/null ; then
+		echo "Failed to enslave $1 to $BOND_MASTER." >&2
 	fi
 
 	setup_primary

Bug#992087: libfonts-java: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Hi Tony,

Thanks for looking at this!

Le 11/08/2021 à 20:40, tony mancill a écrit :

On Wed, Aug 11, 2021 at 02:25:45PM +0200, Pierre Gruet wrote:

Source: libfonts-java
Version: 1.1.6.dfsg-3
Severity: serious
Tags: bullseye sid stretch buster
Justification: Policy 2.2.1

Dear Maintainer,

The file patches/itext-1.5.2.patch incorporates a non-free license, stating

Sun Microsystems grants you ("Licensee") a non-exclusive, royalty free, license
to use, modify and redistribute this software in source and binary code form,
provided that i) this copyright notice and license appear on all copies of the
software; and ii) Licensee does not utilize the software in a manner which is
disparaging to Sun Microsystems.

This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause.


Hi Pierre,

A couple of comments:

1)  In that patch file, I see:


Some classes in iText are based on code samples provided by SUN.
A copyright notice is always included in the source code of the specific class.
The license is either SUN's samples license (1), or the license marked with (2)
...


The non-DFSG phrase referring to "disparaging" is from SUN's samples
license (1).  License (2) (again, merely quoting that sun.txt file)
includes the problematic clause:


You acknowledge that Software is not designed,licensed or intended for use in
the design, construction, operation or maintenance of any nuclear facility.


However, when I search the patch, the Java source files included don't
refer to either of those licenses explicitly.  The only file that does
include a copyright and license statement is DFSG-free, but I'm not sure
about the other files.


I must say I submitted a batch of 6 bugs with this "disparaging to Sun" 
clause and did not go that much into details for each package. Arguably 
neither of those licenses is suitable for us... yet I just attempted a 
build of libfonts-java while repacking to remove the patches/ directory, 
and it succeeded. Of course this is not enough, but I think it might be 
worth looking at it more carefully to check this directory can be safely 
removed.


In any case, we will have to rely on a point release of Bullseye to fix 
this in stable, so I guess we have a bit of time.




2) I'm wondering what such a clause would mean anyway now that "Sun
Microsystems" is defunct since 2010.  How would a licensee disparage a
non-existent entity?

My second question is more just wondering what happens...  I guess we
will have to figure out the files that are (presumably) licensed under
the problematic licenses.


I also don't know, but who knows who holds the assets now?
Presumably the risk is low, but still...
I share your concerns.



Cheers,
tony



Best regards,

--
Pierre

Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution

[Paul Gevers]

Hi Roman,

On 11-08-2021 19:38, Roman Mamedov wrote:
> It does not feel great to now have a version selection with such dire
> consequences to rely on "the undocumented feature of APT".

The suggestion was from one of the maintainers of APT, so I think we can
trust the feature to be properly supported. To be more correct, similar
support is documented in apt_preferences, just not in the context of
Default-Release.

> It appears they meant "-updates" there, instead of typoed "-upgrades" in their
> suggested config line, unless I'm missing something.

Thanks for this. It was indeed a very stupid mistake. I fixed it.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992027: ITP: openqa-client -- Python API to access openQA server

[Sudip Mukherjee]

Hi Philip,

On Tue, Aug 10, 2021 at 10:39 PM Philip Hands  wrote:
>
> Sudip Mukherjee  writes:
>
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sudip Mukherjee 
> > X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com, 
> > Philip Hands 
> >
> > * Package name: openqa-client
> >   Version : 4.1.2
> > * URL : https://github.com/os-autoinst/openQA-python-client
> > * License : GPL-2.0
> >   Programming Lang: Python
> >   Description : Python API to access openQA server
> >



> >
> > Added Cc to Philip Hands also and if he is planning to add Python API
> > as part of his implementation then I can close this and wait for him.
>
> At present my packaging of openqa (which I hope to get into a state fit
> to upload very soon -- a few lintian warnings need addressing) already
> produces a package called openqa-client, which includes the scripts such
> as openqa-cli and openqa-client.
>
> BTW You can see the current state of play here:
>
>   https://salsa.debian.org/philh/openqa

Yes, I have seen that. Please do let me know if you need any help with
that. Though I have zero perl knowledge. :(

>
> The openqa-client script is obsolescent, so renaming that package to
> be openqa-cli would make sense anyway, since that is the script to use
> these days, but I think calling what seems to be a python library simply
> 'openqa-client' would be a bit confusing.

Yes, I agree.

>
> Wouldn't it make sense to put a 'python' in the package name?

Will rename this to python-openqa-client.

>
> I'm not really a python programmer, so probably not the person to
> package this, but would be pleased to see it available in Debian, and am
> very happy help where I can.

And I started using the python client after seeing that the
openqa-client is based on perl. :)
Dont worry, I can package it and maintain it under the umbrella of
Debian Python team.

Thanks for your work in packaging openqa and for openqa.debian.net.

Regards
Sudip

Bug#992113: release-notes: Initial availability of Bazel build system in Debian

[Olek Wojnar]

Package: release-notes
Severity: normal

Dear Release Team,

If possible, please include the following in section 2.2 (What's new in the
distribution?) of the release notes for the following architectures:
amd64, arm64, ppc64el, s390x, ppc64, riscv64



2.2.x Initial availability of the Bazel build system
The [Bazel](https://bazel.build/) build system is available in Debian starting 
with this release. This is a bootstrap variant that will not include local 
versions of the extended Bazel ecosystem. However, the current package **does** 
provide identical functionality to core upstream Bazel, with the advantage of 
convenient Debian package management for the installation. While building 
Debian packages is not currently recommended, any software that supports Bazel 
builds should build normally using this Debian-native Bazel package. This 
includes build-time downloads of required dependencies.

The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working to 
package an extensible version of Bazel for future Debian releases. This 
extensible version will allow additional components of the Bazel ecosystem to 
be included as native Debian packages. More importantly, this version will 
allow Debian packages to be built using Bazel. Contributions to the team are 
welcome!



Please let me know if you have any questions. Feel free to make minor edits
if you think it will improve readability for users. I did NOT wrap the text
above at 80 columns since I hope that will make it easier to copy/paste it
into the release notes.

Thank you!

-Olek
(On behalf of the Bazel packaging team)

Bug#980230: fonts-allerta is proposing 2 font files but LibreOffice is proposing only one

[Serge Pouliquen]

Hi,

I took time to make some tests with files from official website.
The problem is still present with libreoffice.
Is there a debian page about stuff to check when a font is not appearing 
in font list ?


Debian files looks not up to date.
md5sum for debian files
b0b0b4e19b80cf1efe2074ac45066130 
/usr/share/fonts/opentype/allerta/allerta_medium.otf
46019393b8fc0cc3a55684c18ab36f4e 
/usr/share/fonts/opentype/allerta/allerta_stencil.otf

md5sum for official website
5c452f83f43801f04eff595b0e8a8835  allerta_medium.otf
5ded992908f415149c9de35c73adbf70  allerta_stencil.otf

I tried to open official otf files with font forge, I got a warning message:
This font contains both a kern table and a GPOS table.
  The kern table will only be read if there is no kern feature in GPOS
Warning: Mac and Windows entries in the name table differ for the
  Fullname string in the language English (US)
  Mac String: Allerta Medium
  Windows String: Allerta-Medium

I'm not a font specialist. Is it possible that there is any relation ?

Regards,
Serge

On 20/01/2021 21:01, Matt McInerney wrote:
I'm not familiar with this issue, but you can try downloading the 
original files here: http://pixelspread.com/allerta/ 


There are two weights in a few different file types you can try

Bug#992112: nodejs FTBFS: ares_nameser.h: No such file or directory

[Adrian Bunk]

Source: nodejs
Version: 12.22.5~dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=nodejs

...
../src/cares_wrap.cc:42:11: fatal error: ares_nameser.h: No such file or 
directory
   42 | # include 
  |   ^~~~
compilation terminated.
make[3]: *** [libnode.target.mk:316: 
/<>/out/Release/obj.target/libnode/src/cares_wrap.o] Error 1

Bug#992111: node-tar: CVE-2021-32804

[Salvatore Bonaccorso]

Source: node-tar
Version: 6.0.5+ds1+~cs11.3.9-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-tar.

CVE-2021-32804[0]:
| The npm package "tar" (aka node-tar) before versions 6.1.1, 5.0.6,
| 4.4.14, and 3.3.2 has a arbitrary File Creation/Overwrite
| vulnerability due to insufficient absolute path sanitization. node-tar
| aims to prevent extraction of absolute file paths by turning absolute
| paths into relative paths when the `preservePaths` flag is not set to
| `true`. This is achieved by stripping the absolute path root from any
| absolute file paths contained in a tar file. For example
| `/home/user/.bashrc` would turn into `home/user/.bashrc`. This logic
| was insufficient when file paths contained repeated path roots such as
| `home/user/.bashrc`. `node-tar` would only strip a single path
| root from such paths. When given an absolute file path with repeating
| path roots, the resulting path (e.g. `///home/user/.bashrc`) would
| still resolve to an absolute path, thus allowing arbitrary file
| creation and overwrite. This issue was addressed in releases 3.2.2,
| 4.4.14, 5.0.6 and 6.1.1. Users may work around this vulnerability
| without upgrading by creating a custom `onentry` method which
| sanitizes the `entry.path` or a `filter` method which removes entries
| with absolute paths. See referenced GitHub Advisory for details. Be
| aware of CVE-2021-32803 which fixes a similar bug in later versions of
| tar.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32804
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32804
[1] https://github.com/npm/node-tar/security/advisories/GHSA-3jfq-g458-7qm9

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992110: node-tar: CVE-2021-32803

[Salvatore Bonaccorso]

Source: node-tar
Version: 6.0.5+ds1+~cs11.3.9-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-tar.

CVE-2021-32803[0]:
| The npm package "tar" (aka node-tar) before versions 6.1.2, 5.0.7,
| 4.4.15, and 3.2.3 has an arbitrary File Creation/Overwrite
| vulnerability via insufficient symlink protection. `node-tar` aims to
| guarantee that any file whose location would be modified by a symbolic
| link is not extracted. This is, in part, achieved by ensuring that
| extracted directories are not symlinks. Additionally, in order to
| prevent unnecessary `stat` calls to determine whether a given path is
| a directory, paths are cached when directories are created. This logic
| was insufficient when extracting tar files that contained both a
| directory and a symlink with the same name as the directory. This
| order of operations resulted in the directory being created and added
| to the `node-tar` directory cache. When a directory is present in the
| directory cache, subsequent calls to mkdir for that directory are
| skipped. However, this is also where `node-tar` checks for symlinks
| occur. By first creating a directory, and then replacing that
| directory with a symlink, it was thus possible to bypass `node-tar`
| symlink checks on directories, essentially allowing an untrusted tar
| file to symlink into an arbitrary location and subsequently extracting
| arbitrary files into that location, thus allowing arbitrary file
| creation and overwrite. This issue was addressed in releases 3.2.3,
| 4.4.15, 5.0.7 and 6.1.2.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32803
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32803
[1] https://github.com/npm/node-tar/security/advisories/GHSA-r628-mhmh-qjhw

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992109: gimp: save/export window doesn't popup

[shy]

Package: gimp
Version: 2.10.8-2
Severity: important

Dear Maintainer,

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

(gimp:1583): Gtk-WARNING **: 13:39:40.578: Attempting to add a widget with type 
GtkLabel to a GimpFrame, but as a GtkBin subclass a GimpFrame can only contain 
one widget at a time; it already contains a widget of type GtkLabel

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.4.109-26094-g381754fbb430 (SMP w/2 CPU cores; PREEMPT)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgs9   9.27~dfsg-2+deb10u4
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.3.1-1
ii  libheif1 1.3.2-2~deb10u1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1
ii  libopenexr23 2.2.1-4.1+deb10u1
ii  libopenjp2-7 2.3.0-2+deb10u2
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpoppler-glib8 0.71.0-5
ii  librsvg2-2   2.44.10-2.1
ii  libstdc++6   8.3.0-6
ii  libtiff5 4.1.0+git191117-2~deb10u1
ii  libwebp6 0.6.1-2+deb10u1
ii  libwebpdemux20.6.1-2+deb10u1
ii  libwebpmux3  0.6.1-2+deb10u1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1+deb10u2
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-2+deb10u4

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gimp-python   
pn  gvfs-backends 
ii  libasound21.1.8-1

-- no debconf information

Bug#992087: libfonts-java: contains a file with a non-free "disparaging to Sun" license

[tony mancill]

On Wed, Aug 11, 2021 at 02:25:45PM +0200, Pierre Gruet wrote:
> Source: libfonts-java
> Version: 1.1.6.dfsg-3
> Severity: serious
> Tags: bullseye sid stretch buster
> Justification: Policy 2.2.1
> 
> Dear Maintainer,
> 
> The file patches/itext-1.5.2.patch incorporates a non-free license, stating 
> 
> Sun Microsystems grants you ("Licensee") a non-exclusive, royalty free, 
> license
> to use, modify and redistribute this software in source and binary code form,
> provided that i) this copyright notice and license appear on all copies of the
> software; and ii) Licensee does not utilize the software in a manner which is
> disparaging to Sun Microsystems.
> 
> This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
> clause.

Hi Pierre,

A couple of comments:

1)  In that patch file, I see:

> Some classes in iText are based on code samples provided by SUN.
> A copyright notice is always included in the source code of the specific 
> class.
> The license is either SUN's samples license (1), or the license marked with 
> (2)
> ...

The non-DFSG phrase referring to "disparaging" is from SUN's samples
license (1).  License (2) (again, merely quoting that sun.txt file)
includes the problematic clause:

> You acknowledge that Software is not designed,licensed or intended for use in
> the design, construction, operation or maintenance of any nuclear facility.

However, when I search the patch, the Java source files included don't
refer to either of those licenses explicitly.  The only file that does
include a copyright and license statement is DFSG-free, but I'm not sure
about the other files. 

2) I'm wondering what such a clause would mean anyway now that "Sun
Microsystems" is defunct since 2010.  How would a licensee disparage a
non-existent entity?

My second question is more just wondering what happens...  I guess we
will have to figure out the files that are (presumably) licensed under
the problematic licenses.

Cheers,
tony

Bug#981341: bup split does not honor the -q flag

[Joey Hess]

This bug affects git-annex, which runs bup split -q, possibly multiple
of them concurrently, and so gets its output messed up by the undesired
output.

Note that the output goes to stderr, so it cannot even be safely piped
to /dev/null without potentally swallowing error messages.

I'm fairly sure this is a reversion in bup.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#992108: ITP: ansible-pygments -- tools for building the ansible distribution

[Sakirnth Nagarasa]

Package: wnpp
Severity: wishlist
Owner: Sakirnth Nagarasa 

* Package name: ansible-pygments
Upstream Author   : Felix Fontein
* URL : https://github.com/ansible-community/ansible-pygments
* License : BSD-2-Clause
Description   : tools for building the ansible distribution

 This project provides a Pygments lexer that is able to handle Ansible
It may be used anywhere Pygments is integrated.

Greetings
Sakirnth

Bug#992107: ansible: Patch to code-smell/shebang.py has issues.

[Chris Francy]

Package: ansible
Version: 2.10.7+merged+base+2.10.8+dfsg-1
Severity: minor
X-Debbugs-Cc: zoreda...@gmail.com

Dear Maintainer,

The patch 0005_use_py3.patch changes code-smell/shebang.py in a way that
breaks it.

This should probably be python3, not python33

@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python33
 from __future__ import (absolute_import, division, print_function)
 __metaclass__ = type

The `@@ -16,14 +16,14 @@` section also probably isn't correct. The
ansible-test is sometimes used by 3rd party code and module development.
Code that might have the python shebang.  Adding the `#!/usr/bin/env
python3` as an additional shebang to check should be fine, but I can't
imagine there is a good reason to remove the check for code that has
`#!/usr/bin/env python`. Third party code that has that as a shebang, and
should get a warning.

@@ -16,14 +16,14 @@
 b'#!/usr/bin/env bash',
 b'#!/usr/bin/env fish',
 b'#!/usr/bin/env pwsh',
 b'#!/usr/bin/env python',
+b'#!/usr/bin/env python3',
 b'#!/usr/bin/make -f',
 ])

 integration_shebangs = set([
 b'#!/bin/sh',
 b'#!/usr/bin/env bash',
 b'#!/usr/bin/env python',
+b'#!/usr/bin/env python3',
 ])

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

Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages ansible depends on:
ii  openssh-client1:8.4p1-5
ii  python3   3.9.2-3
ii  python3-cryptography  3.3.2-1
ii  python3-distutils 3.9.2-1
ii  python3-dnspython 2.0.0-1
ii  python3-httplib2  0.18.1-3
ii  python3-jinja22.11.3-1
ii  python3-netaddr   0.7.19-5
ii  python3-packaging 20.9-2
ii  python3-pycryptodome  3.9.7+dfsg1-1+b2
ii  python3-yaml  5.3.1-5

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1.5
ii  python3-jmespath 0.10.0-1
ii  python3-kerberos 1.1.14-3.1+b3
ii  python3-libcloud 3.2.0-2
ii  python3-selinux  3.1-3
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.12.0-2

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

-- no debconf information

Bug#992106: ITP: sphinx-ansible-theme -- ansible sphinx theme

[Sakirnth Nagarasa]

Package: wnpp
Severity: wishlist
Owner: Sakirnth Nagarasa 

* Package name: sphinx-ansible-theme
Upstream Author   : Ansible by Red Hat
* URL :
https://github.com/ansible-community/sphinx_ansible_theme
* License : MIT
Description   : ansible sphinx theme

 This is a Spinx Theme created for Ansible. This Theme can be reused in
different Sphinx documentations.

Greetings
Sakirnh

Bug#992105: ITP: sphinx-notfound-page -- sphinx extension to build a 404 page with absolute urls

[Sakirnth Nagarasa]

Package: wnpp
Severity: wishlist
Owner: Sakirnth Nagarasa 

* Package name: sphinx-notfound-page
Upstream Author   : Manuel Kaufmann
* URL : https://github.com/readthedocs/sphinx-notfound-page
* License : MIT
Description   : sphinx extension to build a 404 page with absolute urls

 With the aid of this module one can create a custom 404 page with
absolute URLs hardcoded.

Greetings
Sakirnth

Bug#992104: ITP: q2-diversity-lib -- QIIME2 plugin to expose diversity metrics/measures as actions

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: q2-diversity-lib -- QIIME2 plugin to expose diversity 
metrics/measures as actions
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: q2-diversity-lib
  Version : 2020.11.1
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME2 plugin to expose diversity metrics/measures as 
actions
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis pipeline.
 New functionality will regularly become available through QIIME 2 plugins. You
 can view a list of plugins that are currently available on the QIIME 2 plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-diversity-lib

Bug#991949: xuxen-eu-spell: New upstream version 5.1

[Agustin Martin]

El vie, 6 ago 2021 a las 16:30, Dimitrij Mijoski () escribió:
>
> Source: xuxen-eu-spell
> Version: 0.5.20151110-5
> Severity: normal
>
> Dear Maintainer,
>
> New uptream version is avaliable, see here http://xuxen.eus/eu/deskargatu .
> Direct link: http://xuxen.eus/static/hunspell/xuxen_5.1_hunspell.zip

Thanks for the info.

I am splitting old myspell2 part, used only to create aspell dict, to
a new separate xuxen-eu-myspell source package. Since it contains a
new tarball it will stay some time in the NEW queue until accepted. I
will then handle this new version of xuxen-eu-spell, to avoid aspell
dict being missing from sid for some days.

Regards,

-- 
Agustin

Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution

[Roman Mamedov]

On Tue, 10 Aug 2021 20:20:23 +0200
Paul Gevers  wrote:

> I learned yesterday that people that use APT pinning or
> APT::Default-Release may be missing out -updates if they pin to buster
> only. See the latest entry to the release notes [1, last paragraph] to
> cover the issue for bullseye-security. I'm obviously not sure if that
> happened here, but if the issue is the same on ci.d.n infrastructure, it
> would explain the failure there (the logs from yesterday there mention
> "Setting up shim-signed:arm64 (1.36~1+deb10u1+15.4-5~deb10u1)".

I have regained access to some cloud instances with that setup today.

Created them from an older backup, and I see that I do have in my apt.conf:

  APT::Default-Release "buster";
  APT::Install-Recommends "false";

And:

# apt-cache policy shim-signed
shim-signed:
  Installed: 1.33+15+1533136590.3beb971-7
  Candidate: 1.36~1+deb10u1+15.4-5~deb10u1
  Version table:
 1.36~1+deb10u2+15.4-5~deb10u1 500
500 https://deb.debian.org/debian buster-updates/main arm64 Packages
 1.36~1+deb10u1+15.4-5~deb10u1 990
990 https://deb.debian.org/debian buster/main arm64 Packages
 *** 1.33+15+1533136590.3beb971-7 100
100 /var/lib/dpkg/status

Indeed the "Candidate" to be installed is what is supposedly the broken
version.

After changing the config line to

  APT::Default-Release "/^buster(|-security|-updates)$/";

the updated version is selected correctly.

It does not feel great to now have a version selection with such dire
consequences to rely on "the undocumented feature of APT".

(So I just chose to "aptitude hold" the old one for now instead).

> [1]
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

It appears they meant "-updates" there, instead of typoed "-upgrades" in their
suggested config line, unless I'm missing something.

-- 
With respect,
Roman

Bug#982122: redis: experimental package OOMs s390x buildds

[Julien Cristau]

On Sat, Feb 06, 2021 at 04:58:09PM +, Adam D. Barratt wrote:
> Source: redis
> Version: 5:6.2~rc3-1
> Severity: serious
> Tags: ftbfs
> 
> Hi,
> 
> Both s390x buildds hit OOM conditions while attempting to build redis
> 6.2 in experimental.
> 
> The log from zani ends with:
> 
> [33/63 done]: integration/rdb (10 seconds)
> Testing integration/corrupt-dump
> [ok]: corrupt payload: #7445 - with sanitize
> [...]
> [ok]: corrupt payload: fuzzer findings - hash convert asserts on RESTORE with 
> shallow sanitization
> [ok]: corrupt payload: OOM in rdbGenericLoadStringObject
> [TIMEOUT]: clients state report follows.
> sock2aa3bc1aa00 => (SPAWNED SERVER) pid:45952
> Killing still running Redis server 41748
> 
> 
Today's redis upload to experimental OOMed on the s390x buildd again.
It'd be appreciated if you could make fixing this a priority, and
refrained from uploading further versions until then.

Thanks,
Julien

Bug#697039: Info received (Quote)

[James Charlinton]

Hello,

Thank you for your mail and apologies for the late reply, I was out of office 
for schedules

Kindly find below our shared online OneDrive excel file as the company has a 
policy which we adhere to, for you to receive detailed specification for the 
brand required.

DOWNLOAD online Microsoft OneDrive below;

https://www.onlinemicrosoft/Onedrive-/sharedfile/PO367459/excel/22466


Advised to ensure the detailed specification of this order and inform us about 
your lead time and payment terms. The encrypted storage period of this order is 
10 days from enquiry.

FOB Port of loading.

I look forward to your productive mail revert due to brand urgency.

Thanks again.

From: Debian Bug Tracking System 
Sent: Tuesday, July 6, 2021 6:12 PM
To: BDO | 
Subject: Bug#697039: Info received (Quote)

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Policy Editors 

If you wish to submit further information on this problem, please
send it to 697...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
697039: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D697039&data=04%7C01%7C%7Cd1c7299672de4bb694d008d940e43cb5%7C84df9e7fe9f640afb435%7C1%7C0%7C637612171272723908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q7jKpimqRSRPm%2BiWkOSeYhpsDNEeEi8p4rCSZ0zwckI%3D&reserved=0
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#992103: ocfs2-tools: Missing upstream o2cb init.d script actions

[Athos Ribeiro]

Package: ocfs2-tools
Severity: normal

Dear Maintainer,

As initially reported in Ubuntu [1] and then upstream [2], the  o2cb
init.d script currently shipped does not include some of the upstream
actions such as "online" and "offline".

It seems that this [3] is the point where the package stopped providing
the upstream actions.

Were these actions removed on purpose (e.g., to comply with the
capabilities provided by systemd)?

Otherwise, would you be willing to accept a patch to re-introduce those
actions here?

Regards,

Athos

[1] https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1939406
[2] https://github.com/markfasheh/ocfs2-tools/issues/50
[3] 
https://salsa.debian.org/ha-team/ocfs2-tools/-/commit/68e48fcc3469e7d5def42746be24137fd786bfc9

Bug#992075: gitlab: download button for 2fa recovery codes does not work (coping works)

[Pirate Praveen]

On Wed, 11 Aug 2021 10:44:19 +0530 Akshay S Dinesh 
 wrote:

> Upstream issue:
> https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2271
>
> Can be fixed with this commit:
> 
https://gitlab.com/gitlab-org/gitlab-ui/-/commit/3a4de98fecfe8e7808e3e83cd84a0639c1e6f33b

>

Thanks for finding these, unfortunately this patch don't apply cleanly 
to 13.12 branch. I think updating gitlab to 14.x would be easier and 
more worthwhile option.

Bug#992091: python3.9: Add arc-linux-gnu triplet

[Alexey Brodkin]

Source: python3.9
Severity: normal
Tags: patch upstream

Dear Maintainer,

There's a new triplet for ARCv2 processors "arc-linux-gnu"
defined here https://wiki.debian.org/Multiarch/Tuples.

With addition of this triplet to Python3 it becomes buildable for ARC.
Attaching a simple diff that implements proposed change.

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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff --git a/configure b/configure
index 1252335472..7f735e99c7 100755
--- a/configure
+++ b/configure
@@ -5231,6 +5231,8 @@ cat >> conftest.c <

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Simon McVittie]

Control: tags -1 + pending
Control: forwarded -1 https://ftp-master.debian.org/new.html

On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
> "libdecor" is a library that can be used by Wayland clients to implement
> client-side window decorations.

Initial package uploaded to NEW, now waiting for ftp team processing.

I made some more packaging improvements before uploading:
https://salsa.debian.org/sdl-team/libdecor-0/-/commits/debian/latest/

smcv

Bug#765740: Hope support for multiple ESPs can be upstreamed from Ubuntu -> Debian

[Frank Myhr]

I ran into this yesterday while installing Bullseye on a UEFI system 
with multiple drives and ESPs. Here are a couple of links describing how 
Ubuntu's multi-ESP works:


https://unix.stackexchange.com/questions/621942/mirroring-efi-system-partition-esp-on-ubuntu

https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1466150

I tried running
dpkg-reconfigure grub-efi-amd64
on my multi-ESP Bullseye system in the hope that the Ubuntu support may 
have been upstreamed, but alas it has not yet happened. I'll ask on 
Ubuntu list as well whether someone is working on upstreaming.

Bug#992094: e2fsprogs: mke2fs fails to create file system

[Theodore Ts'o]

tags 992094 +pending
thanks

On Wed, Aug 11, 2021 at 02:56:06PM +0200, Heinrich Schuchardt wrote:
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/e/e2fsprogs/14285096/log.gz
> 
> shows the following errors for debian/tests/fuse2fs:
> 
> mke2fs:
> No such file or directory while trying to determine filesystem size

Thanks for the bug report.  This bug is already fixed upstream in
commit 53464654bd33 ("mke2fs: fix creating a file system image w/o a
pre-existing file") and will be in the upcoming 1.46.4 release, which
is currently considered mostly complete pending updates from the
Translation Project.

Feel free to take a look at / test the "maint" branch at

https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

and if you see any poitential problems, please let me know!

   - Ted

Bug#992089: xemacs21-packages: contains a file with a non-free "disparaging to Sun" license

[Mark Brown]

On Wed, Aug 11, 2021 at 02:38:48PM +0200, Pierre Gruet wrote:

> Source: xemacs21-packages
> Version: 2009.02.17.dfsg.2-4
> Severity: serious
> Tags: stretch buster bullseye sid

...

> The file
> xemacs-packages/jde/java/src/jde/debugger/expr/LValue.java
> incorporates a non-free license, stating 

This bug has been present for several decades now, it is *extremely*
late for the buster release at this point and fixing this will require
an upload of a new source version to pull out the file.  I therefore
propose that we ignore this bug for the upcoming release to avoid the
minor but still present risk of disruption at this point in the cycle.


signature.asc
Description: PGP signature

Bug#992100: FTBFS with gcc-11

[dann frazier]

Source: edk2
Severity: normal

Once the default gcc becomes gcc-11, edk2 will begin to FTBFS:

"arm-linux-gnueabihf-gcc" -MMD -MF 
/<>/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/Arm/ashldi3.obj.deps
 -mthumb -march=armv7-a -E -x assembler-with-cpp -include AutoGen.h 
-DOPENSBI_EXTERNAL_SBI_TYPES=OpensbiTypes.h 
-I/<>/ArmPkg/Library/CompilerIntrinsicsLib/Arm 
-I/<>/ArmPkg/Library/CompilerIntrinsicsLib 
-I/<>/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/DEBUG
 -I/<>/MdePkg -I/<>/MdePkg/Include 
-I/<>/MdePkg/Test/UnitTest/Include 
-I/<>/MdePkg/Include/Arm -I/<>/ArmPkg 
-I/<>/ArmPkg/Include 
/<>/ArmPkg/Library/CompilerIntrinsicsLib/Arm/ashldi3.S > 
/<>/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/Arm/ashldi3.ii
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU

I'm guessing - but haven't tested - that this is fallout from the following
change in gcc-11:

gcc-11 (11.1.0-2) experimental; urgency=medium
[...]
  * For armhf configure --with-arch=+fp, dropping the --with-fpu= option.
[...]


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
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

Bug#970673: nspr: Some tests are not run due to a bug in debian/rules

[Laurent Bigonville]

On Mon, 21 Sep 2020 11:07:34 +0200 Svante Signell 
 wrote:


> Hello,
>
> In debian/rules the runtests.sh script is not run properly. The line
>
> cd nspr/pr/tests && grep -v
> '^\(fdcach\|gethost\|getproto\|nblayer\|peek\|socket\|vercheck\)$$'
> ./runtests.sh | sh - $(CURDIR)/nspr/dist
>
> needs to change to
>
> cd nspr/pr/tests && grep -v
> '^\(fdcach\|gethost\|getproto\|nblayer\|peek\|socket\|vercheck\)' 
./runtests.sh

> | sh -s - $(CURDIR)/nspr/dist
>
> Note that only fdcach and peek tests are activated in runtests.sh, 
all other

> tests are already commented out in that file, so the above line can be
> significantly reduced.
>
> Attached is a patch to fix this together with the tests for GNU/Hurd, 
reported

> in #970659: debian_rules.diff.
>

Can this patch (or similar) be applied?

This is also fixing the FTBFS on kfreebsd

Bug#992099: Please update package to most recent release (20210117)

[Ryan Kavanagh]

Package: mlton
Version: 20130715-3
Severity: wishlist

The most recent installable version of the mlton packages is over 8
years old. Please consider updating it to a recent release, e.g., to
version 20210117:

http://mlton.org/Release20210117

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 mlton depends on:
ii  mlton-compiler  20130715-3
ii  mlton-doc   20130715-3
ii  mlton-tools 20130715-3

mlton recommends no packages.

mlton suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#992098: cpio: Regression form CVE-2021-38185 fix: cpio hangs when target path passed with 128 characters

[Salvatore Bonaccorso]

Source: cpio
Version: 2.13+dfsg-5
Severity: serious
Tags: upstream
Justification: regression, has influences to other programs, partially FTBFS of 
packages, and other impact
X-Debbugs-Cc: car...@debian.org

Hi

It looks that the fix for CVE-2021-38185 applied in 2.13+dfsg-5 causes
a regression. I noticed it initally doing a kernel build, where we
have the invocation 

cut-cut-cut-cut-cut-cut-
dh_prep
set -o pipefail; \
cd debian/build/source_none; \
( \
echo Makefile; \
for arch in alpha arm arm64 ia64 m68k mips parisc powerpc riscv s390 sh 
sparc x86; do \
find arch/$arch -maxdepth 1 -name 'Makefile*' -print; \
find arch/$arch \( -name 'Kbuild.platforms' -o -name 'Platform' 
\) -print; \
find $(find arch/$arch \( -name include -o -name scripts \) 
-type d -print) -print; \
done; \
find include -print; \
) \
| \
cpio -pd --preserve-modification-time 
'/home/build/linux-5.13.9/debian/linux-headers-5.13.0-trunk-common//usr/src/linux-headers-5.13.0-trunk-common'
cpio: h: Cannot stat: No such file or directory
cpio: int.h: Cannot stat: No such file or directory
cpio: .h: Cannot stat: No such file or directory
cpio: ander.h: Cannot stat: No such file or directory
cpio: .h: Cannot stat: No such file or directory
cpio: -clock.h: Cannot stat: No such file or directory
94174 blocks
cut-cut-cut-cut-cut-cut-

but this was not a problem with 2.13+dfsg-4.

Trying to track this down it looks that with 2.13+dfsg-4 works, while
hangs with the new version:

root@sid:~# cd $(mktemp -d) ; touch foo ; echo foo | cpio -pd $(python3 -c 
'print("A" * 128)')
0 blocks

Now updating cpio:

root@sid:/tmp/tmp.1Q1sQ1UmJ3# apt-get install cpio
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  libarchive1
The following packages will be upgraded:
  cpio
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/244 kB of archives.
After this operation, 8192 B of additional disk space will be used.
(Reading database ... 78465 files and directories currently installed.)
Preparing to unpack .../cpio_2.13+dfsg-5_amd64.deb ...
Unpacking cpio (2.13+dfsg-5) over (2.13+dfsg-4) ...
Setting up cpio (2.13+dfsg-5) ...
Processing triggers for man-db (2.9.4-2) ...

and doing the same again:

root@sid:/tmp/tmp.1Q1sQ1UmJ3# cd $(mktemp -d) ; touch foo ; echo foo | cpio -pd 
$(python3 -c 'print("A" * 128)')
^C
root@sid:/tmp/tmp.1FBtWOr0jO#

Regards,
Salvatore

Bug#992097: mlton-compiler is not installable

[Ryan Kavanagh]

Package: mlton-compiler
Version: 20180207-1
Severity: grave

mlton-compiler is not installable

rak@zeta:~$ sudo apt-get install mlton-compiler
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
a mlton-compiler : Depends: mlton-basis (= 20180207-1) but 20130715-3 is to be 
installed
E: Unable to correct problems, you have held broken packages.
rak@zeta:~$ apt-cache show mlton-compiler
Package: mlton-compiler
Source: mlton
Version: 20180207-1
Installed-Size: 19501
Maintainer: Wesley W. Terpstra 
Architecture: amd64
Replaces: mlton (<< 20100608-3)
Depends: libc6 (>= 2.27), libgmp10, gcc, libc6-dev, libgmp-dev, mlton-basis (= 
20180207-1), mlton-runtime-native (= 20180207-1) | mlton-runtime
Breaks: mlton (<< 20100608-3)
Description-en: Optimizing compiler for Standard ML - compiler
 MLton is a whole-program optimizing compiler
 for Standard ML.  MLton generates standalone
 executables with excellent runtime performance,
 is SML 97 compliant, and has a complete basis
 library.  MLton has source-level profiling,
 a fast C FFI, an interface to the GNU
 multiprecision library, and lots of useful
 libraries.
 .
 This package includes the compiler itself.
Description-md5: 4d2747f6a7ae5685bdb914296a9ee48a
Multi-Arch: foreign
Homepage: http://mlton.org/
Section: devel
Priority: optional
Filename: pool/main/m/mlton/mlton-compiler_20180207-1_amd64.deb
Size: 3070708
MD5sum: f3e1ee979627decb83d0ed45a2d71eb0
SHA256: 8c9bc43cb7f8304edee95857c1ec914e0605604b2b1864f8096776b70dfe3b40

Package: mlton-compiler
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 17750
Maintainer: Wesley W. Terpstra 
Architecture: amd64
Multi-Arch: foreign
Source: mlton
Version: 20130715-3
Replaces: mlton (<< 20100608-3)
Depends: libc6 (>= 2.14), libgmp10, gcc, libc6-dev, libgmp-dev, mlton-basis (= 
20130715-3), mlton-runtime-native (= 20130715-3) | mlton-runtime
Breaks: mlton (<< 20100608-3)
Description-en: Optimizing compiler for Standard ML - compiler
 MLton is a whole-program optimizing compiler
 for Standard ML.  MLton generates standalone
 executables with excellent runtime performance,
 is SML 97 compliant, and has a complete basis
 library.  MLton has source-level profiling,
 a fast C FFI, an interface to the GNU
 multiprecision library, and lots of useful
 libraries.
 .
 This package includes the compiler itself.
Description-md5: 4d2747f6a7ae5685bdb914296a9ee48a
Homepage: http://mlton.org/

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 mlton-compiler depends on:
ii  gcc 4:10.2.1-1
ii  libc6   2.31-13
ii  libc6-dev   2.31-13
ii  libgmp-dev  2:6.2.1+dfsg-1
ii  libgmp102:6.2.1+dfsg-1
ii  mlton-basis 20130715-3
ii  mlton-runtime-native20130715-3
ii  mlton-runtime-x86-64-linux-gnu [mlton-runtime]  20130715-3

mlton-compiler recommends no packages.

mlton-compiler suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#992096: RFP: emulationstation-de -- Emulator Front-end

[Leon Styhre]

Package: wnpp
Severity: wishlist

* Package name: emulationstation-de
  Version : 1.1.0
  Upstream Author : Leon Styhre 
* URL :https://gitlab.com/leonstyhre/emulationstation-de  

* License : MIT
  Programming Lang: C++
  Description : EmulationStation Desktop Edition (ES-DE) is a front-end for 
browsing and launching games from your multi-platform game collection

This is a fork of the RetroPie version of EmulationStation that has been 
heavily modified and improved.
It's cross-platform and runs on Linux, BSD Unix, macOS and Windows.
The application ships complete with a comprehensive theme set and system 
configuration files, and with support for well over a 100 different game 
systems out of the box.
It's primarily using RetroArch cores for the emulators, but can also launch 
source ports, Lutris games, Steam games etc.

There is very detailed documentation available for both application usage and 
for building and configuring:
https://gitlab.com/leonstyhre/emulationstation-de/-/blob/master/INSTALL.md
https://gitlab.com/leonstyhre/emulationstation-de/-/blob/master/USERGUIDE.md

Git can be used to clone the repository, or there is a software package 
available for download:
https://gitlab.com/leonstyhre/emulationstation-de/-/archive/v1.1.0/emulationstation-de-v1.1.0.tar.gz

The website is:
https://es-de.org

--
Leon Styhre
l...@leonstyhre.com

Bug#992038: debug logs + severity

[Axel Scheepers]

Hello, 
 
I've enabled systemd-netword debug logging, here are the logs from when 
it happens: 
 
Aug 11 15:51:38 nuc systemd-networkd[10068]: wlp2s0: State changed: configured -> configuring

Aug 11 15:51:38 nuc systemd-networkd[10068]: Sent message type=signal sender=n/a 
destination=n/a path=/org/freedesktop/network1/link/_33 
interface=org.freedesktop.DBus.Properties member=Prop>
Aug 11 15:51:38 nuc systemd-networkd[10068]: wlp2s0: Could not set NDisc 
address: Invalid argument
Aug 11 15:51:38 nuc systemd-networkd[10068]: wlp2s0: Failed
Aug 11 15:51:38 nuc systemd-networkd[10068]: wlp2s0: State changed: configuring 
-> failed
Aug 11 15:51:38 nuc systemd-networkd[10068]: Sent message type=signal sender=n/a 
destination=n/a path=/org/freedesktop/network1/link/_33 
interface=org.freedesktop.DBus.Properties member=Prop>
Aug 11 15:51:38 nuc systemd-networkd[10068]: DHCP CLIENT (0x475755a3): STOPPED
 
 
After which both ipv4 and ipv6 stop working. I can still reach the box 
due to the kernel dhcp configuration done, wired fails also but keeps 
it's pre systemd-networkd configured address. 
 
Kind regards, 
 
Axel Scheepers 
 

Bug#992068: libhdf5-mpich-dev: please bump libmpich-dev dependency to (>= 3.3-3~)

[Gilles Filippini]

Andreas Beckmann a écrit le 10/08/2021 à 17:54 :

Package: libhdf5-mpich-dev
Version: 1.10.6+repack-4
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

During an piuparts upgrade test of libhdf5-mpich-dev on the upgrade path
   squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye
I observed this failure:

   Setting up libhdf5-mpich-dev (1.10.6+repack-4) ...
   update-alternatives: priority must be an integer

   Use 'update-alternatives --help' for program usage information.
   dpkg: error processing package libhdf5-mpich-dev (--configure):
installed libhdf5-mpich-dev package post-installation script subprocess 
returned error exit status 2

At the time of the failure the libmpich1.0-dev package which
   Provides: libmpich-dev
was still installed, but that uses an ancient mpi alternative scheme
the postinst cannot parse.
Making the libmpich-dev versioned (buster shipped with 3.3-3 which uses
the new alternatives scheme) ensures that libmpich-dev gets upgraded
(or rather installed, kicking out the ancient libmpich1.0-dev from
squeeze).

This fix needs to get backported to bullseye-pu.

This needs an update of mpich as well, since there is an unhandled
file conflict between libmpich1.0-dev and mpich, #992065.

I've verified that using the two updated packages fixes the problematic
upgrade path.

Andreas

PS: it took me quite some time to understand what was going on here
so the fix wasn't ready before the bullseye deadline.


Thank you Andreas. I'll prepare an upload asap.

Best,

_g.

Bug#992095: Acknowledgement (amanda-server: amsamba error deprecated messages)

[Tobias Köck]

Hi,

I solved the problem by using the newest smb.conf. It can be closed. Thanks.

Greetings
Tobias

On 8/11/21 3:21 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 992095: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992095.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Jose M Calhariz 

If you wish to submit further information on this problem, please
send it to 992...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#992095: Problem solved

[Tobias Köck]

Hi,

I solved the problem by using the newest smb.conf. It can be closed. 
Thanks. :-)


Greetings
Tobias

Bug#992095: amanda-server: amsamba error deprecated messages

[tkoeck]

Package: amanda-server
Version: 1:3.5.1-7
Severity: normal

Dear Maintainer,

I just upgraded to Debian Bullseye and amsamba seems to make some
serious problems.

I used 'amcheck a2g-2' to verify and the following problems occur.

---
HOST localhost ERROR: //monster.qudosoft.de/dev: Application 'amsamba':
exited with status 1
HOST localhost ERROR: smbclient: lpcfg_do_global_parameter: WARNING: The
"syslog" option is deprecated
HOST localhost ERROR: smbclient: lpcfg_do_global_parameter: WARNING: The
"encrypt passwords" option is deprecated
HOST localhost ERROR: smbclient: lpcfg_do_global_parameter: WARNING: The
"client ntlmv2 auth" option is deprecated
HOST localhost ERROR: smbclient: lpcfg_do_global_parameter: WARNING: The
"client plaintext auth" option is deprecated
---

Needless to say that the amcheck fails. How can I 'overwrite' or fix it'
-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages amanda-server depends on:
ii  amanda-common  1:3.5.1-7
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-2
ii  libc6  2.31-13
ii  libcurl4   7.74.0-1.3+b1
ii  libglib2.0-0   2.66.8-1
ii  libjson-perl   4.03000-1
ii  mailutils [mailx]  1:3.10-3+b1
ii  perl   5.32.1-4

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
ii  amanda-client 1:3.5.1-7
ii  cpio  2.13+dfsg-4
ii  gnuplot   5.2.6+dfsg1-1+deb10u1
ii  gnuplot-qt [gnuplot]  5.2.6+dfsg1-1+deb10u1

-- no debconf information

Bug#991943: klibc: please consider including machine-readable copyright file

[maximilian attems]

On Wed, Aug 11, 2021 at 02:40:20PM +0200, Andrej Shadura wrote:
> On 11/08/2021 14:30, Andrej Shadura wrote:
> > On Fri, 06 Aug 2021 14:31:26 +0200 Andrej Shadura 
> > wrote:
> >> Please consider including the attached machine-readable copyright file.
> >> I tried to make it as precise as I can based on the information in the
> >> source and accompanying text files; improve it as you see fit.
> > 
> > I’ve noticed a few issues with the proposed copyright file. I have fixed
> > them; please find the attached patch to the packaging.
> 
> Of course, once again I’ve forgotten something:
> 
> Files: debian/*
> Copyright:
>  2005  Jeff Bailey 
>  2005-2014 maximilian attems 
>  2015-2021 Ben Hutchings 
> 
> I’m not sure what the license of the packaging is.

please use whatever is canonical, I'm fine with GPL as well as BSD,
as it is mostly glue to just bring things to the enduser.

please use this email adress of mine, thank you.

also the patch should be submitted to klibc upstream ;)

Bug#992094: e2fsprogs: mke2fs fails to create file system

[Heinrich Schuchardt]

Package: e2fsprogs
Version: 1.46.3-1
Severity: normal

https://ci.debian.net/data/autopkgtest/unstable/amd64/e/e2fsprogs/14285096/log.gz

shows the following errors for debian/tests/fuse2fs:

mke2fs:
No such file or directory while trying to determine filesystem size
/sbin/e2label:
No such file or directory while trying to open 
/tmp/autopkgtest-lxc.xu4_8zmj/downtmp/autopkgtest_tmp/test-image.img


Somehow mke2fs cannot interpret the size argument 8M.

The debian/tests/ directory is unchanged relative to release 1.46.2. 
Hence this is a regression which needs to be fixed.


Best regards

Heinrich

Bug#992093: cccc: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Package: 
Version: 1:3.1.4-9
Severity: serious
Tags: stretch buster bullseye sid
Justification: Policy 2.2.1

Dear Maintainer,

The file test/prn14.java incorporates a non-free license, stating 

Sun grants you ("Licensee") a non-exclusive, royalty free, license to use,
modify and redistribute this software in source and binary code form,
provided that i) this copyright notice and license appear on all copies of
the software; and ii) Licensee does not utilize the software in a manner
which is disparaging to Sun.

This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause.

There is also another clause restricting the field of endeavor.

Best regards,

-- 
Pierre Gruet

Bug#990409: ca-cacert: should this package be removed?

[Axel Beckert]

Hi,

Timo Röhling wrote:
> * Axel Beckert  [2021-08-11 13:27]:
> > I strongly disagree. CAcert offers way more types of certificates than
> > Let's Encrypt. For example does Let's Encrypt not provide any
> > certificates suitable for use as personal S/MIME e-mail certificates.
>
> Have you tried creating a personal S/MIME e-mail certificate lately?

Nope.

> Because I tried, and neither IE nor Edge nor Firefox nor Chrome nor Opera
> support the required HTML  tag any more.

That's the same for sso.debian.org. So should we close down that one,
too?

>From my point of view that's a failure of the browser makers and not
of CAcert or sso.debian.org. So users now need to call manually
openssl themselves.

> > But instead it offers longer living certificates for hosts not
> > directly reachable from the internet — which is a hell to achieve with
> > Let's Encrypt.
>
> Private hosts are usually managed with a private CA, which gives you
> much more control and versatility.

Not everyone is capable of running their own CA. Have you every tried
"easyrsa"? It's anything but easy. (And I personally rather run an
internal CA based on CAcert's scripts — which I actually do — than on
easyrsa. Tried easyrsa mostly for OpenVPN and nearly ditched OpenVPN
just because they recommend this crap.)

> Many companies do this,

Yeah, and often with worse outcome than with CAcert...

> and CAcert offers no advantage, since you'd still have to distribute
> their root certificates to all your clients.

If it's available as a Debian package, that's a clear advantage from
my point of view. :-)

> > Again, I strongly disagree. I rather hope that Dmitry gets it back
> > into shape and then also offers it via bullseye-backports.
>
> Well, if you, Dmitry, or anyone else feels that their time is well
> spent on this package, by all means, go ahead. I just happen to
> think that your contributions would be more valuable elsewhere.

I already have too many packages, so yes, I agree here. This though
does not change my opinion on this package (or on a lot of other
packages in Debian which I don't maintain, but consider important for
myself as well as the community in general).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#992092: king: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Package: king
Version: 2.23.161103+dfsg1-1
Severity: serious
Tags: stretch buster bullseye sid
Justification: Policy 2.2.1


Dear Maintainer,

The file king/doc/LICENSE-SUN features a non-free license, stating 

Sun grants you ("Licensee") a non-exclusive, royalty free, license to use, and
redistribute this software graphics artwork, as individual graphics or as a
collection, as part of software code or programs that you develop, provided
that i) this copyright notice and license accompany the software graphics
artwork; and ii) you do not utilize the software graphics artwork in a manner
which is disparaging to Sun. Unless enforcement is prohibited by applicable
law, you may not modify the graphics, and must use them true to color and
unmodified in every way.


This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause, and DFSG-3 as it forbids modification of the artwork.

Best regards,

-- 
Pierre Gruet

Bug#992090: libskinlf-java: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Package: libskinlf-java
Version: 6.7-9
Severity: serious
Tags: stretch buster bullseye sid
Justification: Policy 2.2.1

Dear Maintainer,

The file src/examples/Clock.java incorporates a non-free license, stating 

Sun grants you ("Licensee") a non-exclusive, royalty free, license to use,
modify and redistribute this software in source and binary code form,
provided that i) this copyright notice and license appear on all copies of
the software; and ii) Licensee does not utilize the software in a manner
which is disparaging to Sun.

This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause.

Best regards,

-- 
Pierre Gruet

Bug#991943: klibc: please consider including machine-readable copyright file

[Andrej Shadura]

On 11/08/2021 14:30, Andrej Shadura wrote:
> On Fri, 06 Aug 2021 14:31:26 +0200 Andrej Shadura 
> wrote:
>> Please consider including the attached machine-readable copyright file.
>> I tried to make it as precise as I can based on the information in the
>> source and accompanying text files; improve it as you see fit.
> 
> I’ve noticed a few issues with the proposed copyright file. I have fixed
> them; please find the attached patch to the packaging.

Of course, once again I’ve forgotten something:

Files: debian/*
Copyright:
 2005  Jeff Bailey 
 2005-2014 maximilian attems 
 2015-2021 Ben Hutchings 

I’m not sure what the license of the packaging is.

-- 
Cheers,
  Andrej

Bug#992089: xemacs21-packages: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Source: xemacs21-packages
Version: 2009.02.17.dfsg.2-4
Severity: serious
Tags: stretch buster bullseye sid
Justification: Policy 2.2.1

Dear Maintainer,

The file
xemacs-packages/jde/java/src/jde/debugger/expr/LValue.java
incorporates a non-free license, stating 

Sun grants you ("Licensee") a non-exclusive, royalty free, license to use,
modify and redistribute this software in source and binary code form,
provided that i) this copyright notice and license appear on all copies of
the software; and ii) Licensee does not utilize the software in a manner
which is disparaging to Sun.

This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause.

Best regards,

-- 
Pierre Gruet

Bug#992088: wims: contains two files with a non-free "disparaging to Sun" license

[Pierre Gruet]

Package: wims
Version: 1:4.13c~dfsg1-2
Severity: serious
Tags: stretch buster bullseye sid
Justification: Policy 2.2.1

Dear Maintainer,

The files
wims/src/Misc/applets/Lattice/src/LatticeViewer.java
and
wims/src/Misc/applets/Lattice/src/Matrix3D.java
have a non-free license, stating

Sun grants you ("Licensee") a non-exclusive, royalty free, license to use,
modify and redistribute this software in source and binary code form,
provided that i) this copyright notice and license appear on all copies of
the software; and ii) Licensee does not utilize the software in a manner
which is disparaging to Sun.

This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause.

Best regards,

-- 
Pierre Gruet

Bug#991943: klibc: please consider including machine-readable copyright file

[Andrej Shadura]

Hi,

On Fri, 06 Aug 2021 14:31:26 +0200 Andrej Shadura 
wrote:
> Please consider including the attached machine-readable copyright file.
> I tried to make it as precise as I can based on the information in the
> source and accompanying text files; improve it as you see fit.

I’ve noticed a few issues with the proposed copyright file. I have fixed
them; please find the attached patch to the packaging.

-- 
Cheers,
  Andrej
>From 317a7494fd2faea9a75f9d7556bc48d2691be706 Mon Sep 17 00:00:00 2001
From: Andrej Shadura 
Date: Wed, 11 Aug 2021 14:24:29 +0200
Subject: [PATCH] Rewrite debian/copyright in the machine-readable format

Signed-off-by: Andrej Shadura 
---
 debian/copyright | 246 ---
 1 file changed, 191 insertions(+), 55 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index 7b60024..ce50305 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,56 +1,192 @@
-This package was debianized by Jeff Bailey  on
-Sun, 23 Jan 2005 21:11:50 -0500.
-
-It was downloaded from http://www.kernel.org/pub/linux/libs/klibc/
-
-Copyright 2004-2006 H. Peter Anvin 
-
-License:
-
-BSD/GPL
-
-On Debian GNU/Linux systems, the complete text of the GNU General Public
-License v2 can be found in `/usr/share/common-licenses/GPL-2'.
-
--- BSD license text
-
-Some files are derived from files copyrighted by the Regents of The
-University of California, and are available under the following
-license:
-
-Note: The advertising clause in the license appearing on BSD Unix
-files was officially rescinded by the Director of the Office of
-Technology Licensing of the University of California on July 22
-1999. He states that clause 3 is "hereby deleted in its entirety."
-
- * Copyright (c)
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 
+Files: *
+Copyright: 2004-2021, H. Peter Anvin and klibc contributors
+License: BSD-3-clause and/or GPL-2 and/or Expat
+
+Files: klcc/*
+License: Expat
+
+Files: contrib/klibc.m4
+Copyright: 1995-2003, Free Software Foundation, Inc.
+License: GPL-2-with-Autoconf-exception
+
+Files: scripts/basic/fixdep.c
+Copyright: 2002, Kai Germaschewski 
+License: GPL-2
+
+Files: usr/dash/*
+Copyright:
+ 1989-1994, The Regents of the University of California
+ 1997, Christos Zoulas
+ 1997-2012, Herbert Xu 
+Comment:
+ This code is derived from software contributed to Berkeley by Kenneth Almquist.
+License: BSD-3-Clause
+
+Files: usr/dash/TOUR
+Copyright: 1989, Kenneth Almquist.
+License: BSD-3-Clause
+
+Files: usr/dash/src/bltin/test.c
+Copyright: Erik Baalbergen, Eric Gisin, Arnold Robbins, J.T. Conklin
+License: public-domain
+
+Files: usr/gzip/*
+Copyright:
+ 1992-1993 Jean-loup Gailly
+License: GPL-2+
+
+Files: usr/gzip/inflate.c
+Copyright: 1992, Mark Adler
+License: public-domain
+
+Files: usr/include/arch/*
+Copyright: 2004-2006, H. Peter Anvin
+License: Expat
+
+Files:
+ usr/include/arch/sparc/*
+ usr/klibc/arch/sparc/*
+Copyright:
+ 1994, Allen Briggs
+ 1993, Adam Glass
+ 1988, University of Utah.
+ 1982, 1990, 1992, 1993, The Regents of the University of California.
+License: BSD-4-Clause-UC
+
+Files: usr/include/sys/md.h
+Copyrigh

Bug#990409: ca-cacert: should this package be removed?

[Timo Röhling]

* Axel Beckert  [2021-08-11 13:27]:

I strongly disagree. CAcert offers way more types of certificates than
Let's Encrypt. For example does Let's Encrypt not provide any
certificates suitable for use as personal S/MIME e-mail certificates.

Have you tried creating a personal S/MIME e-mail certificate lately?
Because I tried, and neither IE nor Edge nor Firefox nor Chrome nor Opera
support the required HTML  tag any more. It has been this way for at
least two years. Apparently nobody noticed.


But instead it offers longer living certificates for hosts not
directly reachable from the internet — which is a hell to achieve with
Let's Encrypt.

Private hosts are usually managed with a private CA, which gives you
much more control and versatility. Many companies do this, and
CAcert offers no advantage, since you'd still have to distribute
their root certificates to all your clients.


Again, I strongly disagree. I rather hope that Dmitry gets it back
into shape and then also offers it via bullseye-backports.

Well, if you, Dmitry, or anyone else feels that their time is well
spent on this package, by all means, go ahead. I just happen to
think that your contributions would be more valuable elsewhere.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#992087: libfonts-java: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Source: libfonts-java
Version: 1.1.6.dfsg-3
Severity: serious
Tags: bullseye sid stretch buster
Justification: Policy 2.2.1

Dear Maintainer,

The file patches/itext-1.5.2.patch incorporates a non-free license, stating 

Sun Microsystems grants you ("Licensee") a non-exclusive, royalty free, license
to use, modify and redistribute this software in source and binary code form,
provided that i) this copyright notice and license appear on all copies of the
software; and ii) Licensee does not utilize the software in a manner which is
disparaging to Sun Microsystems.

This breaks at least DFSG-6, due to the "disparaging to Sun Microsystems"
clause.

Best regards,

-- 
Pierre Gruet

Bug#992086: Mozilla Certificate not included

[Trenta sis]

Package: otrs
Version: 6.0.32-5

I'm having this error:

Perl Modules

Not all required Perl modules are correctly installed.

Mozilla::CA..Not installed! (required )

How to reproduce

Steps to reproduce the behavior:

1 Recently Installed, OTRS shows a problem in AdminSupportDataCollector.

Additional information

I have debian 11, and otrs is just installed with apt. Everything
works well but can't find the CA. I also have installed
ca-certificates package.

Bug#992084: nss: FTBFS on kfreebsd

[Laurent Bigonville]

Source: nss
Version: 2:3.68-1
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: kfreebsd
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1725142

Hello,

NSS FTBFS on debian kfreebsd architecture with error regarding redefined
ethods (htole32, le32toh...)

See: 
https://buildd.debian.org/status/fetch.php?pkg=nss&arch=kfreebsd-amd64&ver=2%3A3.68-1&stamp=1626648189&raw=0

The attached patch fixed the build on my test machine

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Index: 
nss-3.68/nss/lib/freebl/verified/kremlin/include/kremlin/lowstar_endianness.h
===
--- 
nss-3.68.orig/nss/lib/freebl/verified/kremlin/include/kremlin/lowstar_endianness.h
+++ 
nss-3.68/nss/lib/freebl/verified/kremlin/include/kremlin/lowstar_endianness.h
@@ -52,7 +52,7 @@
 #define be32toh(x) BE_32(x)

 /* ... for the BSDs */
-#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__DragonFly__)
+#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__DragonFly__) || 
defined(__FreeBSD_kernel__)
 #include 
 #elif defined(__OpenBSD__)
 #include 

Bug#992085: ifupdown: Documentation does not mention --read-environment option to ifup

[Alain D D Williams]

Package: ifupdown
Version: 0.8.35
Severity: normal

Dear Maintainer,

I notice that the file: 
/etc/systemd/system/network-online.target.wants/networking.service
contains the lines:
ExecStart=/sbin/ifup -a --read-environment
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo

I cannot find a description of the --read-environment option in the man page or
by using --help.

Many thanks for your work on this package.

Regards

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

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

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2+deb10u1
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2+deb10u1

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-2+4.1+deb10u1
pn  rdnssd  

-- no debconf information

Bug#990409: ca-cacert: should this package be removed?

[Axel Beckert]

Control: tag -1 + fixed-upstream

Hi,

Timo Röhling wrote:
> CAcert is pretty much made obsolete by LetsEncrypt,

I strongly disagree. CAcert offers way more types of certificates than
Let's Encrypt. For example does Let's Encrypt not provide any
certificates suitable for use as personal S/MIME e-mail certificates.

> and unlike LetsEncrypt, it has never been part of the Mozilla
> truststore.

But instead it offers longer living certificates for hosts not
directly reachable from the internet — which is a hell to achieve with
Let's Encrypt.

> Furthermore, the ca-cacert package has become virtually useless with
> the expiry of the shipped intermediate certificate [1],

Yes, it should be updated. Here I agree.

> and not even CAcert seems to bother enough to link the newly
> generated certificate from their official website [2].

They did in the meanwhile, citing from
http://www.cacert.org/certs/CAcert_Class3Root_x14E228.txt linked on
http://www.cacert.org/index.php?id=3:

Validity
Not Before: Apr 19 12:18:30 2021 GMT
Not After : Apr 17 12:18:30 2031 GMT

> Therefore, I believe it is time to acknowledge the facts and remove
> the package from Debian altogether.

Again, I strongly disagree. I rather hope that Dmitry gets it back
into shape and then also offers it via bullseye-backports.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#990628: (no subject)

[Joris]

I second this request, people upgrading the device firmware without 
having access to the matching package versions are stuck with a 
disfunctional device.


Tested building a version 2021.03.01 deb package of hackrf and 
libhackrf0 on amd64 on bullseye (as of writing still testing) and that 
went very smoothly.


A few quick functional tests show this works fine with the 2021.03.1 
firmware - as is expected. If I encounter grave functional bugs I'll 
amend this bug.



Not-well-considered thought: maybe the firmware itself (both the 
firmware.bin, cpld and dfu) could be offered in (a) package too?

Bug#989705: Suspend to RAM hangs computer with nouveau driver

[Computer Enthusiastic]

Hello,

This is an update of the reported issue for different kernel versions.

The column 'STATUS" shows if suspend to ram/suspend to disk fails (FAIL) or 
succeeds (OK).

The kernel versions linux-image-4.19.0-11-amd64, linux-image-5.10.0-8-amd64 and 
linux-image-5.10.0-8-amd64 are from official 
Debian repositories. The other kernel versions are compiled by me from upstream 
(git://git.kernel.org/pub/scm/linux/kernel/gi
t/stable/linux.git).

STATUS  KERNEL VERSION   VERSION
===  ===
OK  ii  linux-image-4.19.0-11-amd64  4.19.146-1
FAILii  linux-image-5.10.0-8-amd64   5.10.46-3
FAILii  linux-image-5.10.0-8-amd64   5.10.46-4
OK  ii  linux-image-5.10.46  5.10.46
OK  ii  linux-image-5.10.47  5.10.47
OK  ii  linux-image-5.10.48  5.10.48
OK  ii  linux-image-5.10.49  5.10.49
OK  ii  linux-image-5.10.50  5.10.50
OK  ii  linux-image-5.10.51  5.10.51
OK  ii  linux-image-5.10.52  5.10.52
OK  ii  linux-image-5.10.53  5.10.53
FAILii  linux-image-5.13.5   5.13.5

As you an see, the actual candidate for the next Debian stable version 
(5.10.46-4) fails suspend to ram and suspend to disk w
ith the specific reported hardware.

Bug#992083: Mod tidy should ignore missing standard library packages (fixed in go >= 1.15.10)

[Rodrigo Campos]

Package: golang-1.15
Version: 1.15.9-6
Severity: normal

Hi!

I'm currently trying to run go mod tidy on runc master[1] 
(16027b814d59403b71bb369a0ba064da47dd302b) and fails with this error:


io/fs: package io/fs is not in GOROOT 
(/usr/lib/go-1.15/src/io/fs)

Googling a little bit about it, it seems this a bug in go that should 
ignore the package that were introduced in go 1.16 (it is properly 
guarded with build tags in the runc repo).


This comment on viper has pointers to the bugs in go upstream:
https://github.com/spf13/viper/issues/1161#issuecomment-869702237

This bugfix was backported to go 1.10[2] that was released in March 
2021[3]. It will be great if the fix can be included on debian packaged 
version.


Let me know if I can help in any way


Best,
Rodrigo

[1]: https://github.com/opencontainers/runc/
[2]: https://github.com/golang/go/issues/44792
[3]: https://golang.org/doc/devel/release#go1.15.minor

Bug#868949: libapache2-mod-auth-openidc: It happens for 2.4.9-1

[Sorin Manolache]

Package: libapache2-mod-auth-openidc
Version: 2.4.9-1
Followup-For: Bug #868949
X-Debbugs-Cc: sor...@gmail.com

Dear Maintainer,

The bug reported in 2017 for 2.1.6 happens again for 2.4.9-1.

systemctl start apache2
systemctl reload apache2 => child segfaults

I don't even make any request to the server. I just start the server then 
reload it.

Initially I thought there's a problem with the module's interaction with 
mod_ssl. But the problem persists with mod_ssl disabled. Here's my list of 
enabled modules:

 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 alias_module (shared)
 auth_basic_module (shared)
 auth_openidc_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 headers_module (shared)
 include_module (shared)
 info_module (shared)
 mime_module (shared)
 mpm_worker_module (shared)
 negotiation_module (shared)
 proxy_module (shared)
 proxy_connect_module (shared)
 proxy_http_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 status_module (shared)
 unique_id_module (shared)

Then I've gone so far as to remove even more modules. I still have the segfault 
even for this list of modules:

 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 auth_basic_module (shared)
 auth_openidc_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 mpm_worker_module (shared)

Here's gdb's report upon inspecting the core file:

(gdb) thread apply all bt

Thread 1 (Thread 0x7f364f5add40 (LWP 3237729)):
#0  0x7f364f82c995 in apr_atomic_dec32 () from 
/usr/lib/x86_64-linux-gnu/libapr-1.so.0
#1  0x7f364f831301 in ?? () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
#2  0x7f364f83365e in apr_pool_destroy () from 
/usr/lib/x86_64-linux-gnu/libapr-1.so.0
#3  0x7f364f4e4f45 in ?? () from /usr/lib/apache2/modules/mod_mpm_worker.so
#4  0x7f364f4e5741 in ?? () from /usr/lib/apache2/modules/mod_mpm_worker.so
#5  0x7f364f4e5b95 in ?? () from /usr/lib/apache2/modules/mod_mpm_worker.so
#6  0x7f364f4e5c41 in ?? () from /usr/lib/apache2/modules/mod_mpm_worker.so
#7  0x7f364f4e6b27 in ?? () from /usr/lib/apache2/modules/mod_mpm_worker.so
#8  0x560b96ca8220 in ap_run_mpm ()
#9  0x560b96ca0008 in main ()


Best regards,
Sorin


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

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

Versions of packages libapache2-mod-auth-openidc depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.48-3.1
ii  libc6   2.31-13
ii  libcjose0   0.6.1+dfsg1-1
ii  libcurl47.74.0-1.3+b1
ii  libhiredis0.14  0.14.1-1
ii  libjansson4 2.13.1-1.1
ii  libpcre32:8.39-13
ii  libssl1.1   1.1.1k-1

libapache2-mod-auth-openidc recommends no packages.

libapache2-mod-auth-openidc suggests no packages.

-- no debconf information

Bug#991059: diffoscope: out-of-memory

[Roland Clobus]

On 15/07/2021 18:41, Mattia Rizzolo wrote:
> On Wed, Jul 14, 2021 at 08:31:48PM +0200, Roland Clobus wrote:

>> The difference between these two files is located inside a squashfs
>> file, which is inside the iso file.
>> During the invocation of diffoscope, diffoscope needs lots of memory
>> (>32GB) and free space on /tmp (>32GB but <48GB).

I've got the 2 ISO files that were used in a Jenkins run now, each 2.6GB.

In attempting to reproduce the case, I've mounted /tmp to a file instead
of using tmpfs and I've booted with 'single'. My computer has 32GB
memory, about 200MB is in use by the OS.

When I'm running diffoscope as root, I get the following metrics
(obtained by polling every 5 seconds):

21935816 1k blocks on /tmp (about 22GB)
1010 MiB memory at the peak
Needed time: 120 minutes +/ 10

However, when I run the same command as a regular user, I get an OOM
after about 5 minutes. At that time, the first squashfs image (2.3GB) is
completely decompressed to disc (8.0GB), and xxd is running.

The output of diffoscope with --debug:

2021-08-11 09:15:48 D: diffoscope.comparators.utils.file: Instantiating
a squashfs.SquashfsContainer for live/filesystem.squashfs
2021-08-11 09:15:48 D: diffoscope.comparators.squashfs: Extracting
/tmp/diffoscope_wzbylzvt_/tmpz60gl4slLibarchiveContainerWithFilelist/0/887.squashfs
to /tmp/diffoscope_wzbylzvt_/tmpg2r8zivtsquashfs
2021-08-11 09:15:48 D: diffoscope.comparators.utils.command: Calling
external command: unsquashfs -n -f -no -li -d .
/tmp/diffoscope_wzbylzvt_/tmpz60gl4slLibarchiveContainerWithFilelist/0/887.squashfs
2021-08-11 09:16:55 D: diffoscope.comparators.utils.command: Executing
xxd {}
2021-08-11 09:18:40 D: diffoscope.comparators.utils.command: Executing
xxd {}
Killed

So it appears to me that different code is activated for regular users
and root.
I hope this report helps in finding/fixing the issue.

With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992082: debian/rules: Filter packages and platforms without build profiles

[Nicolas Boulenguez]

Source: u-boot
Severity: wishlist
Tags: patch

Hello.

This idea has been discussed since #979296, but the initial
implementation was incompatible with dpkg-buildpackage.

These variants should now work:
debian/rules package_filter=u-boot/%rockchip/%sunxi 
platform_filter=%-rk3399/a64-olinuxino%
dpkg-buildpackage '--rules-file=debian/rules package_filter=...'
sbuild '--debbuildopt=--rules-file=debian/rules package_filter=...'
>From fa78cf47855518b2a45fb6000c7694a1eae69c35 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 8 Jul 2021 17:11:19 +0200
Subject: [PATCH] debian/rules: Filter packages and platforms without build
 profiles

This idea has been discussed since #979296, but the initial
implementation was incompatible with dpkg-buildpackage.

These variants should now work:
debian/rules package_filter=u-boot/%rockchip/%sunxi platform_filter=%-rk3399/a64-olinuxino%
dpkg-buildpackage '--rules-file=debian/rules package_filter=...'
sbuild '--debbuildopt=--rules-file=debian/rules package_filter=...'
---
 debian/rules | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/debian/rules b/debian/rules
index 244956f6cc..e14e2cafb3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,22 +28,20 @@ notools := $(filter pkg.uboot.notools,$(DEB_BUILD_PROFILES))
 
 subarchs := $(shell dh_listpackages --arch --no-package=u-boot-tools)
 
-# Each .deb P in subarch contains $(P_platforms).
-# These profiles remove values from $(P_platforms) for debugging.
-
-# DEB_BUILD_PROFILES='pkg.uboot.subarch.P1 pkg.uboot.subarch.P2'
-# removes all platforms but in packages u-boot-P1 u-boot-P2.
-only_subarchs := $(patsubst pkg.uboot.subarch.%,u-boot-%,\
-   $(filter pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES)))
+# For debugging purposes, some filters may restrict the actually built
+# platforms.  The expected contents are Make patterns (with at most
+# one % wildcard), separated by / (because spaces are difficult to
+# escape from dpkg-buildpackage --rules-file).
+#   package_filter=u-boot/%amlogic/%mvebu
+#   platform_filter=khadas-vim%
+
+only_subarchs := $(subst /, ,$(package_filter))
 ifneq (,$(only_subarchs))
   $(foreach pkg,$(filter-out $(only_subarchs),$(subarchs)),$(eval \
 $(pkg)_platforms :=))
 endif
 
-# DEB_BUILD_PROFILES='pkg.uboot.platform.P1 pkg.uboot.platform.P2'
-# removes all platforms but P1 P2.
-only_platforms := $(patsubst pkg.uboot.platform.%,%,\
-$(filter pkg.uboot.platform.%,$(DEB_BUILD_PROFILES)))
+only_platforms := $(subst /, ,$(platform_filter))
 ifneq (,$(only_platforms))
   $(foreach pkg,$(subarchs),$(eval \
 $(pkg)_platforms := $(filter $(only_platforms),$($(pkg)_platforms
-- 
2.30.2

Bug#991982: nano does not work with TERM unset

[Benno Schulenberg]

>> For me, 'TERM=dumb nano somefile' does not work, not on a console, not
>> on an xterm, not on Xfce Terminal -- it shows something, but is totally
>> unusable: the user cannot see what he or she is doing.  What terminal
>> are you using?
> 
> Yes but it run, it is unusable but it run. The problem is the behvior is not 
> consistant. You have only two sane choice:
> 1 allow to run in every terminal. It is user choice and it could shot it own 
> foot

Nano will "run" in any terminal, but the user (or rather: the system) /must/
specify the terminal.  There does not seem to be a way for a program to probe
which terminal is being used.

> 2 filter the bad terminal and return with an unambigous error code

Emacs filters out 'dumb' because a dumb terminal cannot position the cursor
and emacs (and nano) need to be able to position the cursor.  But how can
nano in general determine whether a given terminal is able to position the
cursor?  Lacking that, I do not see any reason to try and filter out "bad"
terminals.  If the user wants to be dumb and set TERM to 'dumb', they will
get what they asked for.  Vim does not filter out 'dumb' either, and becomes
unusable too in that case.

> You do not implement a consistant behavior.

Are you accusing me?  Please watch your language.


>> May I ask what the scenario is?  How can it happen that TERM is unset?
>> What disaster can leave TERM unset?

You didn't answer the question.

> posix said about vi that the behavior for empty term should be consistant 
> and documented. If nano want to be a vi replacement it should be consistant.

Who says that nano wants to be a replacement for vi?

Benno



OpenPGP_signature
Description: OpenPGP digital signature