Bug#962949: ITS: libxsmm

[Michael Banck]

Hi,

On Tue, Jun 16, 2020 at 09:48:56AM -0400, Boyuan Yang wrote:
> Source: libxsmm
> Version: 1.9-1
> Tags: sid
> X-Debbugs-CC: mba...@debian.org
> Severity: important
> 
> Dear Debian libxsmm package maintainer,

Uhm, I'm just the uploader, not the maintainer. The maintainer is the
science-team, which you are part of, so why don't you just go ahead and
upload your proposed fixes, adding yourself as an additional uploader?


Michael

Bug#962902: [debian-mysql] Bug#962902: Bug#962902: server does not start

[Olaf van der Spek]

On Tue, Jun 16, 2020 at 1:33 PM Toni Mueller  wrote:
>
>
> Hi Otto,
>
> On Tue, Jun 16, 2020 at 12:27:53PM +0300, Otto Kekäläinen wrote:
> > Can you provide us enough information about your environment so we
> > could try to reproduce this error?
>
> I'm not sure what you are after. The machine in question is a laptop
> with Buster (latest), and all sorts of stiff.

http://thedjbway.b0llix.net/djbdns/dnsroots.html :

> The file /etc/dnsroots.global is created when you install the djbdns package 
> itself.

Is djbdns installed? Was it installed previously?

Greetings,

Olaf

Bug#586413: RFA: a lot of packages

[Mike Gabriel]

Hi Sven,

On  Di 16 Jun 2020 23:07:27 CEST, Sven Geuer wrote:


Hi Mike,
Hi Ola,

I would be interested in maintaining tightvnc as a new member of the
Debian Remote Maintainers Team. I already started some work on it in a
private repository on salsa [1]. 'FTBFS with gcc-10' is already fixed.

Being a DM, I currently maintain two packages under the umbrella of the
Debian Security Tools Packaging Team, and had contributed to other
packages of this team [2].

@Mike: May I ask you to accept me as team member to debian-remote?
@Ola: Would you want to stay listed as uploader with moving tightvnc to
the team?

Please let me know, if you accept my application.

Best,
Sven

[1] https://salsa.debian.org/sven-geuer-guest/tightvnc
[2] https://qa.debian.org/developer.php?email=debmaint%40g-e-u-e-r.de


Awesome! Regarding your Debian Remote Team applications: Welcome in!

I'll wait for Ola's response, then I'll give you permissions on the  
tightvnc.git repo.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpkeY5bw_WS5.pgp
Description: Digitale PGP-Signatur

Bug#962982: buster-pu: package jigdo/0.7.3-5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-06-16 at 22:15 +0100, Steve McIntyre wrote:
> I'd like to push a tiny update into buster for jigdo please. The
> existing version in buster doesn't support https, and this is causing
> issues for users (e.g. #962776). The changes are tiny, backported
> from upstream changes already shipping in sid/bullseye.
> 

Please go ahead.

Regards,

Adam

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Adam D. Barratt]

On Wed, 2020-06-17 at 00:14 +0200, Lucas Nussbaum wrote:
> On 16/06/20 at 21:07 +0100, Adam D. Barratt wrote:
> > On Tue, 2020-06-16 at 16:40 +0200, Julien Cristau wrote:
> > > On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> > > > Control: severity -1 serious
> > > > 
> > > > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > > > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum
> > > > > wrote:
> > > > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > > > > something in udd seems to extract entire source packages
> > > > > > > to
> > > > > > > /tmp/getwatch.*.  This fills up the disk.  Please make it
> > > > > > > not
> > > > > > > do that.
> > [...]
> > > > This happened again.  If it won't get fixed I'll go ahead and
> > > > disable that job.
> > > > 
> > > Done now, removed the "upstream" importer from the config file.
> > > 
> > 
> > It looks like that wasn't enough, as ullmann filled its disk again.
> > 
> > I've now also updated rudd.conf to disable the importer there.

As a quick note on that, the "disable" key in the configuration doesn't
appear to actually disable anything; from
/srv/udd.debian.org/udd/rlibs/udd-daemon.rb:

def run_importer(imp)
  raise 'bugs importer is special' if imp == 'bugs'
  if imp.has_key?('disabled')
puts "Not running #{imp['name']}: disabled"
  end
  init_log if not defined?($log)
  $log.debug "Running #{imp['name']}"

So RUDD seems to log that the importer was marked as disabled, and then
run it anyway.

> I emptied the 'upstream' UDD table (no data is better than wrong
> data).
> 
> In a previous message, it was proposed to use temporary space under
> /srv, but /srv only has 3.1 GB left. Could you maybe create a
> /srv/udd.debian.org/tmp with maybe 10G ?
> 
> Also, does DSA offer the service to send icinga notifications to
> service
> owners? Apparently the condition where this happens is quite rare
> occurences on 08/2019, 12/2019, 06/2020), so notifying me after the
> files were cleaned up from /tmp makes it hard to identify which
> packages cause this issue. If I could get notified when a warning
> limit is reached, it would be much easier to debug.

I'm not sure what the usual policy on that is, but I didn't clean up
/tmp after disabling the importer last night:

drwx-- 3 udd uddadm  4096 Jun 16 20:20 getwatch.qmapshack.n13QHA
drwx-- 3 udd uddadm  4096 Jun 16 20:20 getwatch.picard-tools.Zg0jud
drwx-- 3 udd uddadm  4096 Jun 16 20:50 getwatch.qmapshack.aH184l
drwx-- 3 udd uddadm  4096 Jun 16 20:50 getwatch.picard-tools.SqIkjD
drwx-- 3 udd uddadm  4096 Jun 16 21:20 getwatch.qmapshack.1pIg10
drwx-- 3 udd uddadm  4096 Jun 16 21:20 getwatch.picard-tools.g3weib
drwx-- 3 udd uddadm  4096 Jun 16 21:50 getwatch.qmapshack.oklPSa
drwx-- 3 udd uddadm  4096 Jun 16 21:50 getwatch.picard-tools.Lo3UhJ

So it looks like it's the same couple of packages over and over.

Regards,

Adam

Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596

[Sébastien Delafond]

On 15/06 10:49, Chris Lamb wrote:
> > The full debdiffs are attached. Can you especially check the
> > versioning scheme and distribution fields for me? I often get this
> > wrong and end up confusing myself. Really appreciated.
> 
> They are now attached.

They look fine, please upload to security-master.

Cheers,

-- 
Seb

Bug#962974: t-coffee: fills RAM after reporting PID too high

[merkys]

Hello,

My suggestion would be to set MAX_N_PID to the value of
/proc/sys/kernel/pid_max during the build of the package. Of course this
solution assumes that machine used in buildd uses the same kernel as the
users of the binary package, and I am not completely sure we can rely on
this.

Andrius

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Olek Wojnar]

Hi tony,

On Wed, Jun 17, 2020 at 12:39 AM tony mancill  wrote:

>
> I've pushed a "tmancill" branch to the Salsa repo that gets us further
>

Thanks!


> along.  At this point, the build is failing with this error:
>
>package com.google.api.client.util does not exist
>
> This Java package should be part of the google-http-java-client package.
> I'm looking into why it's missing now.
>

Strange. I don't think that's part of g-h-j-c but I could be wrong. In
related news, I just pushed oauth-client to NEW. Bootleg version available
on Salsa [1] in the meantime for your favorite local repos. :) I believe
that was the last api-client dependency [2] we were missing. ...until we
find the next one... ;)

Bedtime for me but I'll take a look at that missing .util in the morning if
you haven't figured it out by then. :)

Oh, just realized a potential problem! We need to package version 1.27.0,
not 1.30.9. Due to the dependency hell we're working with, that's the
version that lets us get everything to work "well enough." Once
opencensus and grpc-java are in, I think we'll be able to go through and
update many of these packages to newer versions. I'll bet this problem will
go away with the lower version.

-Olek

[1] https://salsa.debian.org/java-team/google-oauth-client-java
[2]
https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1#3-package-dependencies

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 16, 2020 at 08:58:49PM -0400, J. Bruce Fields wrote:
> On Tue, Jun 16, 2020 at 06:16:58PM +0200, Salvatore Bonaccorso wrote:
> > This might be unneeded to test but as additional datapoint which
> > confirms the suspect: I tried check the commit around 47057abde515
> > ("nfsd: add support for the umask attribute") in 4.10-rc1
> > 
> > A kernel built with 47057abde515~1, and mounting from an enough recent
> > client which has at least dff25ddb4808 ("nfs: add support for the
> > umask attribute") does not show the observed behaviour, the server
> > built with 47057abde515 does.
> 
> Thanks for the confirmation!
> 
> I think I'll send the following upstream.
> 
> --b.
> 
> commit 595ccdca9321
> Author: J. Bruce Fields 
> Date:   Tue Jun 16 16:43:18 2020 -0400
> 
> nfsd: apply umask on fs without ACL support
> 
> The server is failing to apply the umask when creating new objects on
> filesystems without ACL support.
> 
> To reproduce this, you need to use NFSv4.2 and a client and server
> recent enough to support umask, and you need to export a filesystem that
> lacks ACL support (for example, ext4 with the "noacl" mount option).
> 
> Filesystems with ACL support are expected to take care of the umask
> themselves (usually by calling posix_acl_create).
> 
> For filesystems without ACL support, this is up to the caller of
> vfs_create(), vfs_mknod(), or vfs_mkdir().
> 
> Reported-by: Elliott Mitchell 
> Reported-by: Salvatore Bonaccorso 
> Fixes: 47057abde515 ("nfsd: add support for the umask attribute")
> Signed-off-by: J. Bruce Fields 
> 
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 0aa02eb18bd3..8fa3e0ff3671 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1225,6 +1225,9 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct 
> svc_fh *fhp,
>   iap->ia_mode = 0;
>   iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type;
>  
> + if (!IS_POSIXACL(dirp))
> + iap->ia_mode &= ~current_umask();
> +
>   err = 0;
>   host_err = 0;
>   switch (type) {
> @@ -1457,6 +1460,9 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh 
> *fhp,
>   goto out;
>   }
>  
> + if (!IS_POSIXACL(dirp))
> + iap->ia_mode &= ~current_umask();
> +
>   host_err = vfs_create(dirp, dchild, iap->ia_mode, true);
>   if (host_err < 0) {
>   fh_drop_write(fhp);

Thank you, could test this on my test setup and seem to work properly.

Should it also be CC'ed to sta...@vger.kernel.org so it is picked up
by the current supported stable series?

Regards,
Salvatore

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[tony mancill]

On Tue, Jun 16, 2020 at 11:19:45AM +0200, Andreas Tille wrote:
> Hi Olek,
> 
> On Tue, Jun 16, 2020 at 05:01:37AM -0400, Olek Wojnar wrote:
> > 
> > Good question! Due to some dependency issues, the bom artifacts are not
> > packaged.
> 
> OK, that explains the issue ...
> 
> > But you should be able to just depend on the non-bom pom files.
> 
> ... but I'm to uneducated to implement your suggested solution.
> (Feel free to push and I keep on testing).

Hi Andreas,

I've pushed a "tmancill" branch to the Salsa repo that gets us further
along.  At this point, the build is failing with this error:

   package com.google.api.client.util does not exist

This Java package should be part of the google-http-java-client package.
I'm looking into why it's missing now.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#962973: haskell-readline: Removal notice: broken and unmaintained

[Sean Whitton]

Hello,

On Tue 16 Jun 2020 at 07:55PM +03, Ilias Tsitsimpis wrote:

> Source: haskell-readline
> Version: 1.0.3.0-9
> Severity: grave
> Justification: renders package unusable
>
> This package seems to be unmaintained (last upstream upload in 2013).
> Does not build with GHC 8.8, is not part of Stackage and has no rev
> dependencies.
>
> I intend to remove this package.

keysafe, in experimental, depends on haskell-readline.

CCing upstream: Joey, do you think it would be possible for keysafe to
migrate to use something maintained?

-- 
Sean Whitton

Bug#936227: boost1.67: Python2 removal in sid/bullseye

[Sandro Tosi]

On Mon, Jun 1, 2020 at 2:11 PM Giovanni Mascellani
 wrote:
>
> Hi,
>
> Il 01/06/20 09:04, Sandro Tosi ha scritto:
> > where are we with the python2 removal for boost1.67? i see the bag was
> > marked as closed in 1.71 but 1.67 is still the default in unstable,
> > and there's no transition bug open on release.d.o
>
> I just requested a transition for Boost. My understanding is that
> release team should give the go quite soon[1].
>
>  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960193#99

great! I see the transition is almost completed - i'm wondering when
it's going to be the time we can remove src:boost1.67 from unstable:
it is now the only remaining rdep of cython, which in turn it's the
only remaining rdep of src:python-numpy which i'd like to remove soon

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#962987: xserver-xorg-core: should not map files from /root

[Russell Coker]

Package: xserver-xorg-core
Version: 2:1.20.4-1
Severity: normal

# ps aux|grep Xorg
root   582  0.3  0.8 340884 50468 tty7 Ssl+ Jun01  82:02 
/usr/lib/xorg/Xorg -nolisten tcp -auth 
/var/run/sddm/{f66ea786-13c9-4499-95f6-f7bdce850668} -background none -noreset 
-displayfd 17 -seat seat0 vt7
root  1854  0.0  0.0   6076   892 pts/3S+   08:39   0:00 grep Xorg
# grep /root /proc/582/maps
7f628cb07000-7f628cc48000 rw-s  00:15 1030181
/root/.cache/mesa_shader_cache/index (deleted)
7f628dab7000-7f628dbf8000 rw-s  00:15 1030181
/root/.cache/mesa_shader_cache/index (deleted)

Xorg when run as a daemon from sddm should not touch any files under /root.
As an aside the system has only had one user login and that user was not root.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29)

Xorg X server log files on system:
--
-rw-r--r--. 1 root root 41271 Jun 11 13:47 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 11655.719] (--) Log file renamed from "/var/log/Xorg.pid-582.log" to 
"/var/log/Xorg.0.log"
[ 11655.722] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[ 11655.722] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[ 11655.722] Current Operating System: Linux athena 4.19.0-9-amd64 #1 SMP 
Debian 4.19.118-2 (2020-04-29) x86_64
[ 11655.722] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 
root=UUID=6b40496e-ccb0-48fd-8764-167e82fcd779 ro security=selinux 
lockdown=confidentiality quiet
[ 11655.722] Build Date: 05 March 2019  08:11:12PM
[ 11655.722] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[ 11655.722] Current version of pixman: 0.36.0
[ 11655.722]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 11655.722] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 11655.723] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jun  1 12:25:59 
2020
[ 11655.726] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 11655.728] (==) No Layout section.  Using the first Screen section.
[ 11655.728] (==) No screen section available. Using defaults.
[ 11655.728] (**) |-->Screen "Default Screen Section" (0)
[ 11655.728] (**) |   |-->Monitor ""
[ 11655.729] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 11655.729] (==) Automatically adding devices
[ 11655.729] (==) Automatically enabling devices
[ 11655.729] (==) Automatically adding GPU devices
[ 11655.729] (==) Max clients allowed: 256, resource mask: 0x1f
[ 11655.732] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 11655.732]Entry deleted from font path.
[ 11655.737] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 11655.737] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 11655.737] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 11655.737] (II) Loader magic: 0x561dbc8d9e20
[ 11655.737] (II) Module ABI versions:
[ 11655.737]X.Org ANSI C Emulation: 0.4
[ 11655.737]X.Org Video Driver: 24.0
[ 11655.737]X.Org XInput driver : 24.1
[ 11655.737]X.Org Server Extension : 10.0
[ 11655.740] (++) using VT number 7

[ 11655.740] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[ 11655.743] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 11655.763] (--) PCI:*(0@0:2:0) 8086:2a42:17aa:20e4 rev 7, Mem @ 
0xf000/4194304, 0xd000/268435456, I/O @ 0x1800/8, BIOS @ 
0x/131072
[ 11655.763] (--) PCI: (0@0:2:1) 8086:2a43:17aa:20e4 rev 7, Mem @ 
0xf040/1048576
[ 11655.763] (II) LoadModule: "glx"
[ 11655.768] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 11655.819] (II) Module glx: vendor="X.

Bug#962984: downloads all updates at startup without my permission and installs them too

[ss]

Source: discover

Severity: critical


Tags: security







-- System Information:

Debian Release: 10.4

  APT prefers stable-updates

  APT policy: (500, 'stable-updates'), (500, 'stable')

Architecture: amd64 (x86_64)

Foreign Architectures: i386



Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)

Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE

Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en 
(charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash

Init: systemd (via /run/systemd/system)

LSM: AppArmor: enabled

Bug#962992: gnome-audio: Please consider rebuilding package for reproducible-builds and other merits

[Boyuan Yang]

Source: gnome-audio
Version: 2.22.2-1
Severity: normal
Tags: sid
X-Debbugs-CC: n...@debian.org

Dear Debian gnome-audio package maintainer,

I was looking into old packages that received no upload in the last 10 years
and found the package gnome-audio you maintain.

It seems that your package received no upload in the last 10 years. There are
many technical points that can be improved by migrating into new toolchains,
including the adoptation of build-arch/build-indep targets and package
reproducibility [1], which requires all packages generated before 2014 to be
rebuilt using the new toolchain.

Since this package is mostly a data package, the packaging instructions can
also be greatly simplified with recent tools. Please consider refreshing your
packaging and make another upload. Thanks!


-- 
Regards,
Boyuan Yang


[1] https://wiki.debian.org/ReproducibleBuilds


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

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[J. Bruce Fields]

On Tue, Jun 16, 2020 at 06:16:58PM +0200, Salvatore Bonaccorso wrote:
> This might be unneeded to test but as additional datapoint which
> confirms the suspect: I tried check the commit around 47057abde515
> ("nfsd: add support for the umask attribute") in 4.10-rc1
> 
> A kernel built with 47057abde515~1, and mounting from an enough recent
> client which has at least dff25ddb4808 ("nfs: add support for the
> umask attribute") does not show the observed behaviour, the server
> built with 47057abde515 does.

Thanks for the confirmation!

I think I'll send the following upstream.

--b.

commit 595ccdca9321
Author: J. Bruce Fields 
Date:   Tue Jun 16 16:43:18 2020 -0400

nfsd: apply umask on fs without ACL support

The server is failing to apply the umask when creating new objects on
filesystems without ACL support.

To reproduce this, you need to use NFSv4.2 and a client and server
recent enough to support umask, and you need to export a filesystem that
lacks ACL support (for example, ext4 with the "noacl" mount option).

Filesystems with ACL support are expected to take care of the umask
themselves (usually by calling posix_acl_create).

For filesystems without ACL support, this is up to the caller of
vfs_create(), vfs_mknod(), or vfs_mkdir().

Reported-by: Elliott Mitchell 
Reported-by: Salvatore Bonaccorso 
Fixes: 47057abde515 ("nfsd: add support for the umask attribute")
Signed-off-by: J. Bruce Fields 

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 0aa02eb18bd3..8fa3e0ff3671 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1225,6 +1225,9 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct svc_fh 
*fhp,
iap->ia_mode = 0;
iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type;
 
+   if (!IS_POSIXACL(dirp))
+   iap->ia_mode &= ~current_umask();
+
err = 0;
host_err = 0;
switch (type) {
@@ -1457,6 +1460,9 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp,
goto out;
}
 
+   if (!IS_POSIXACL(dirp))
+   iap->ia_mode &= ~current_umask();
+
host_err = vfs_create(dirp, dchild, iap->ia_mode, true);
if (host_err < 0) {
fh_drop_write(fhp);

Bug#962991: ITP: r-bioc-beachmat -- I/O for several formats storing matrix data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-beachmat -- I/O for several formats storing matrix data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-beachmat
  Version : 2.4.0+ds
  Upstream Author : Aaron Lun
* URL : https://bioconductor.org/packages/beachmat/
* License : GPL-3
  Programming Lang: GNU R
  Description : I/O for several formats storing matrix data
 Provides a consistent C++ class interface for reading from and
 writing data to a variety of commonly used matrix types. Ordinary
 matrices and several sparse/dense Matrix classes are directly supported,
 third-party S4 classes may be supported by external linkage, while all
 other matrices are handled by DelayedArray block processing.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-beachmat

Bug#939297: breezy: Please provide git-remote-bzr program

[Jelmer Vernooij]

On Wed, Jun 17, 2020 at 08:22:21AM +0800, Paul Wise wrote:
> Thanks for your work on getting the Breezy version into Debian.
FWIW the current implementation still ships with a warning, since it
needs more work - especially in terms of performance - but should work
fine for most smaller repositories.

I'm hoping to improve this for the 3.2 series of Breezy; if you do run
into issues, bug reports would be very welcome.

jelmer

Bug#939297: breezy: Please provide git-remote-bzr program

[Paul Wise]

On Wed, 23 Oct 2019 18:41:11 +0200 Sven Joachim wrote:

> Maybe it would be better to try and revive the original git-remote-bzr
> package?  Paul Wise has attempted to port it to Python3[1], but I don't
> know how far he got.

I didn't get far enough to be able to run it. Unfortunately upstream
was hostile to the idea of porting to Breezy and to Python 3 so I ended
up not doing anything further with it.

Thanks for your work on getting the Breezy version into Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962990: blhc: False positive with ngetty

[Eriberto]

Em ter., 16 de jun. de 2020 às 21:12, Joao Eriberto Mota Filho
 escreveu:
>
> Dear Simon Ruderich,
>
> ngetty builds with dietlibc. When defining CC, blhc see "gcc" and interpret
> it as a command. See below:
>
> 142:NONVERBOSE BUILD: CC = diet -Os gcc -W

The same issue occurs in blhc:

# blhc --all --debian blhc_0.11-1_amd64.build
CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security): ok 43 - ./t/logs/ignore-line --ignore-line
"\./prepare-script gcc test-[a-z]\.c" --ignore-line
"\s*\./prepare-script gcc test-[a-z]\.c .+" (exit code)
CPPFLAGS missing (-D_FORTIFY_SOURCE=2): ok 43 - ./t/logs/ignore-line
--ignore-line "\./prepare-script gcc test-[a-z]\.c" --ignore-line
"\s*\./prepare-script gcc test-[a-z]\.c .+" (exit code)
LDFLAGS missing (-Wl,-z,relro -Wl,-z,now): ok 43 -
./t/logs/ignore-line --ignore-line "\./prepare-script gcc
test-[a-z]\.c" --ignore-line "\s*\./prepare-script gcc test-[a-z]\.c
.+" (exit code)
CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security): ok 44 - ./t/logs/ignore-line --ignore-line
"\./prepare-script gcc test-[a-z]\.c" --ignore-line
"\s*\./prepare-script gcc test-[a-z]\.c .+" (output)
CPPFLAGS missing (-D_FORTIFY_SOURCE=2): ok 44 - ./t/logs/ignore-line
--ignore-line "\./prepare-script gcc test-[a-z]\.c" --ignore-line
"\s*\./prepare-script gcc test-[a-z]\.c .+" (output)
LDFLAGS missing (-Wl,-z,relro -Wl,-z,now): ok 44 -
./t/logs/ignore-line --ignore-line "\./prepare-script gcc
test-[a-z]\.c" --ignore-line "\s*\./prepare-script gcc test-[a-z]\.c
.+" (output)

Regards,

Eriberto

Bug#962978: podman exec fails, reporting an AppArmor problem

[Dmitry Smirnov]

On Wednesday, 17 June 2020 5:45:24 AM AEST Ben Hutchings wrote:
> When I run "podman exec ..." on a running container, it always fails:
> 
> $ sudo podman exec 8791af6116b9 ps
> Error: AppArmor not initialized correctly: OCI runtime error
> 
> (This is a multi-process container running systemd; I don't know if
> that makes a difference to the behaviour.)
> 
> I was able to work around this by adding "apparmor=0" to the kernel
> command line.

Just recently upstream fixed this problem in "crun"
but the fix is not released yet:

  https://github.com/containers/crun/commit/1d87fa9ee32

-- 
All the best,
 Dmitry Smirnov.

---

A foolish faith in authority is the worst enemy of truth.
-- Albert Einstein


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

Bug#962990: blhc: False positive with ngetty

[Joao Eriberto Mota Filho]

Package: blhc
Version: 0.11-1
Severity: normal
Tags: upstream

Dear Simon Ruderich,

ngetty builds with dietlibc. When defining CC, blhc see "gcc" and interpret
it as a command. See below:

142:NONVERBOSE BUILD: CC = diet -Os gcc -W

Thanks in advance.

Regards,

Eriberto

Bug#962988: When started, xfstt doesn't listen at any sockets (neither unix nor tcp) if /tmp/.font-unix/ directory already exists

[Andrey ``Bass'' Shcheglov]

Related to bug #962989 
.



signature.asc
Description: OpenPGP digital signature

Bug#962989: Please enhance /etc/init.d/X11-common script to additionally manage /tmp/.font-unix socket directory

[Andrey ``Bass'' Shcheglov]

Package: x11-common
Version: 1:7.7+19
Severity: normal
Tags: patch

Currently, xfstt package manages the /tmp/.font-unix socket directory
privately, creating it during start-up and removing during its shutdown
(see bug #962988 ).

This may cause problems if multiple font server instances (e. g.: both xfs and
xfstt) are installed, sharing the same socket directory.

-- System Information:
Distributor ID: Debian
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

Kernel: Linux 4.9.0-11-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages x11-common depends on:
ii  lsb-base  10.2019051400

x11-common recommends no packages.

x11-common suggests no packages.

-- no debconf information
--- /etc/init.d/x11-common.orig	2020-06-17 02:25:21.261416236 +0300
+++ /etc/init.d/x11-common	2020-06-17 02:27:55.694594122 +0300
@@ -14,6 +14,7 @@
 PATH=/usr/bin:/usr/sbin:/bin:/sbin
 SOCKET_DIR=.X11-unix
 ICE_DIR=.ICE-unix
+FONT_DIR=.font-unix
 
 . /lib/lsb/init-functions
 if [ -f /etc/default/rcS ]; then
@@ -81,7 +82,7 @@
 }
 
 do_status () {
-if [ -d "/tmp/$ICE_DIR" ] && [ -d "/tmp/$SOCKET_DIR" ]; then
+if [ -d "/tmp/$ICE_DIR" ] && [ -d "/tmp/$SOCKET_DIR" ] && [ -d "/tmp/$FONT_DIR" ]; then
   return 0
 else
   return 4
@@ -95,6 +96,7 @@
 fi
 set_up_dir "$SOCKET_DIR"
 set_up_dir "$ICE_DIR"
+set_up_dir "$FONT_DIR"
 if [ "$VERBOSE" != no ]; then
   log_end_msg 0
 fi

Bug#962988: When started, xfstt doesn't listen at any sockets (neither unix nor tcp) if /tmp/.font-unix/ directory already exists

[Andrey ``Bass'' Shcheglov]

Package: xfstt
Version: 1.10-1
Severity: grave
Tags: upstream

During its start-up, xfstt creates the `/tmp/.font-unix/` directory in order to 
place its socket there.

If, however, the above directory already exists, xfstt:

 - doesn't create the unix socket there if the socket file doesn't exist,
 - doesn't re-use the existing socket file, and
 - fails to listen at a TCP socket even if configured so.

STR:

 1. Make sure xfstt isn't running or stop it first.
 2. As root, create the /tmp/.font-unix/ directory.
 3. Delete /tmp/.font-unix/fs7101 (the socket file).
 4. Start xfstt.
 5. The daemon will start w/o any error:

> # service xfstt status
> [ ok ] xfstt is running.
> 
> # ps -ef | grep xfstt | grep -v grep
> root 31878 1  0 02:00 ?00:00:00 /usr/bin/xfstt --daemon 
> --port 7101 --unstrap --encoding iso8859-1

 6. In spite of the above, the socket file won't be re-created:

> # ls -l /tmp/.font-unix/
> total 0

 7. Additionally, xfstt will no longer be listening at TCP port 7101:

> # lsof -p 31878
> COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
> xfstt   31878 root  cwdDIR  254,212288 1314666 
> /usr/share/fonts/truetype
> xfstt   31878 root  rtdDIR  254,1 4096   2 /
> xfstt   31878 root  txtREG  254,2   129224  805495 /usr/bin/xfstt
> xfstt   31878 root  memREG  254,4   311653  134640 
> /var/cache/xfstt/ttname.dir
> xfstt   31878 root  memREG  254,1  18244962028 
> /lib/x86_64-linux-gnu/libc-2.28.so
> xfstt   31878 root  memREG  254,1   100712 661 
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> xfstt   31878 root  memREG  254,1  15794483929 
> /lib/x86_64-linux-gnu/libm-2.28.so
> xfstt   31878 root  memREG  254,2  1570256 2104093 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
> xfstt   31878 root  memREG  254,472536  134639 
> /var/cache/xfstt/ttinfo.dir
> xfstt   31878 root  memREG  254,1   1656321889 
> /lib/x86_64-linux-gnu/ld-2.28.s

Normally, I'm also expecting 3 sockets in lsof output:

> xfstt   1663 root0u  unix 0x8838fffb7800  0t0 4774342 
> /tmp/.font-unix/fs7101 type=STREAM
> xfstt   1663 root1u  IPv44774346  0t0 TCP *:7101 
> (LISTEN)
> xfstt   1663 root2u  IPv64774347  0t0 TCP *:7101 
> (LISTEN)

If I re-start xfstt, it'll remove and re-create the /tmp/.font-unix/ directory, 
but this directory
shouldn't be managed by xfstt alone as it may be shared between multiple X font 
servers (e. g.: xfs).

The problem stems from the following fragment in xfstt.cc:

> if (mkdir(sockdir, 01777) < 0) {
> error(_("cannot make socket directory %s!\n"), 
> sockdir);
> close(sd);
> return -1;
> }

If the directory already exists and has the right permissions, xfstt should 
just proceed.

If the directory already exists but lacks some permissions, xfstt should 
attempt to change those (when running as root).

BTW, /etc/init.d/x11-common script from x11-common already does the job of 
creating X11 socket directories,
so it could be enhanced to take care of /tmp/.font-unix, too.

-- System Information:
Distributor ID: Debian
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

Kernel: Linux 4.9.0-11-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xfstt depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  lsb-base   10.2019051400

xfstt recommends no packages.

xfstt suggests no packages.

-- debconf information:
* xfstt/listen_tcp: true

Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]

[Sean Whitton]

control: tag -1 +pending

Hello Ian,

On Tue 16 Jun 2020 at 12:11PM +01, Ian Jackson wrote:

> I think "native package versions" refers to "versionn numbers which
> are supposed to be Debian-native", not "the version numbers of
> native-format packages".
>
> Can I suggest that this sentence might be clarified as follows
>
>   remember that hyphen (-) cannot be used in
>   native {-package versions-}{+version numbers+}
>
> ?

Thanks, applied this change.

-- 
Sean Whitton

Bug#927375: [libxfont1] Please re-build libxfont1 with --enable-fc

[Andrey ``Bass'' Shcheglov]

Apparently, this bug is also causing bug #858512 
.

-- 
Regards,
Andrey ``Bass'' Shcheglov.

Bug#937437: pyfeed: Python2 removal in sid/bullseye

[Thomas Preud'homme]

Hi Moritz,

I've filled #962985 and #962986. I don't see why these library packages should 
be kept without reverse dependency.

Best regards,

Thomas.

Bug#962986: RM: xmlelements -- ROM; Last reverse dependency is to be removed

[Thomas Preud'homme]

Package: ftp.debian.org
Severity: normal

With the upcomming removal of pyfeed (#962985), xmlements is going to be without
reverse dependency and should therefore be removed from both unstable
and experimental.

Best regards,

Thomas

Bug#962985: RM: pyfeed -- ROM; No reverse dependency

[Thomas Preud'homme]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

pyfeed is no longer needed by sat-xmpp-core and is therefore no longer
needed in the Debian archive. I would thus like to remove it from both
unstable and experimental.

Best regards,

Thomas

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Lucas Nussbaum]

On 16/06/20 at 21:07 +0100, Adam D. Barratt wrote:
> On Tue, 2020-06-16 at 16:40 +0200, Julien Cristau wrote:
> > On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> > > Control: severity -1 serious
> > > 
> > > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum wrote:
> > > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > > > something in udd seems to extract entire source packages to
> > > > > > /tmp/getwatch.*.  This fills up the disk.  Please make it not
> > > > > > do that.
> [...]
> > > This happened again.  If it won't get fixed I'll go ahead and
> > > disable that job.
> > > 
> > Done now, removed the "upstream" importer from the config file.
> > 
> 
> It looks like that wasn't enough, as ullmann filled its disk again.
> 
> I've now also updated rudd.conf to disable the importer there.

I emptied the 'upstream' UDD table (no data is better than wrong data).

In a previous message, it was proposed to use temporary space under
/srv, but /srv only has 3.1 GB left. Could you maybe create a
/srv/udd.debian.org/tmp with maybe 10G ?

Also, does DSA offer the service to send icinga notifications to service
owners? Apparently the condition where this happens is quite rare
occurences on 08/2019, 12/2019, 06/2020), so notifying me after the
files were cleaned up from /tmp makes it hard to identify which packages
cause this issue. If I could get notified when a warning limit is
reached, it would be much easier to debug.

Lucas

Bug#962983: RM: gnome-doc-utils -- RoQA; Deprecated, dead upstream, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gnome-doc-utils. There are seven reverse dependencies left in
unstable at this point (gconf-editor, gnome-chemistry-utils, viking, xiphos,
florence and mp3splt), but they are all dropped from testing for > two
months and have RC bugs already.

Cheers,
Moritz

Bug#586413: RFA: a lot of packages

[Sven Geuer]

Hi Mike,
Hi Ola,

I would be interested in maintaining tightvnc as a new member of the
Debian Remote Maintainers Team. I already started some work on it in a
private repository on salsa [1]. 'FTBFS with gcc-10' is already fixed.

Being a DM, I currently maintain two packages under the umbrella of the
Debian Security Tools Packaging Team, and had contributed to other
packages of this team [2].

@Mike: May I ask you to accept me as team member to debian-remote?
@Ola: Would you want to stay listed as uploader with moving tightvnc to
the team?

Please let me know, if you accept my application.

Best,
Sven

[1] https://salsa.debian.org/sven-geuer-guest/tightvnc
[2] https://qa.debian.org/developer.php?email=debmaint%40g-e-u-e-r.de

On Sat, 21 Dec 2019 11:02:37 +0100 Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:
> Hi Ola, Ben and Timo,
> 
> On Sun, 20 Jun 2010 00:02:59 +0200 Ola Lundqvist 
wrote:
>  > Hi
>  >
>  > On Sat, Jun 19, 2010 at 11:50:35PM +0300, Timo Juhani Lindfors
wrote:
>  > > Ben Armstrong  writes:
>  > > > Although I cannot take on sole maintainership, I'm interested
in the
>  > > > survival of the best VNC server and client in Debian. If a
team can
>  > > > be put together, I would be happy to contribute in what small
ways I
>  > > > can.
>  > >
>  > > I'm a daily user of vnc4server/xvnc4viewer 4.1.1+X4.3.0-31.
Please let
>  > > me know if you need help in testing :-)
>  > >
>  > > > What about eventual replacement by TigerVNC (
http://tigervnc.org/),
>  > > > since upstream for that fork is actually active?
>  > >
>  > > realvncserver, tightvncserver and vnc4server all seem to contain
an
>  > > embedded copy of xfree/Xorg source code. If tigerVNC's Xorg
module
>  > > actually works this sounds really promising. Any idea why it is
not
>  > > developed in the Xorg tree? Is it still because Xorg does not
want
>  > > GPL'd code?
>  >
>  > Yes. License problems do not change over night.
>  >
>  > > The only earlier attempt on a modular Xorg vnc module I've heard
about
>  > > is xf4vnc: http://xf4vnc.sourceforge.net/modular.html -- How
does this
>  > > compare against TigerVNC?
>  >
>  > It compiles (with a few fixes), but I never got it working, at
>  > least not in a compatible way to the current vnc packages.
>  >
>  > I have not got either TigerVNC nor xf4vnc in a good enough way
>  > for release. So I do not know.
>  >
>  > Last try was a few (1-3 I do not remember) years ago though so
>  > things may have changed.
>  >
>  > Best regards,
>  >
>  > // Ola
> 
> I have just looked at tightvnc in the context of my Debian LTS work
and 
> am preparing a security upload to Debian unstable, buster and
stretch 
> (and jessie LTS, of course).
> 
> (I will NMU the unstable one soon with a 5 days delay).
> 
> As tightvnc is up for adoption, I am thinking of adopting this
package 
> and move it into the context of the Debian Remote Maintainers Team 
> (debian-remote@l.d.o.). I'd consider this a QA measure. And, I am
quite 
> expertised with the imake build system that gets used for building
Xvnc 
> (nx-libs uses it, too).
> 
> As I understand it, the 1.x version is still maintained upstream.
(There 
> even is a new upstream release available).
> 
> So for providing a minimal amount of maintenance shared by several 
> people moving over to a team is maybe a good idea.


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

Bug#962982: buster-pu: package jigdo/0.7.3-5

[Steve McIntyre]

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

Hi!

I'd like to push a tiny update into buster for jigdo please. The
existing version in buster doesn't support https, and this is causing
issues for users (e.g. #962776). The changes are tiny, backported from
upstream changes already shipping in sid/bullseye.

Here's a debdiff...

diff -Nru jigdo-0.7.3/debian/changelog jigdo-0.7.3/debian/changelog
--- jigdo-0.7.3/debian/changelog2017-12-07 16:38:20.0 +
+++ jigdo-0.7.3/debian/changelog2020-06-16 21:54:52.0 +0100
@@ -1,3 +1,10 @@
+jigdo (0.7.3-5+deb10u1) buster; urgency=medium
+
+  * Backport more upstream changes to make jigdo-lite and jigdo-mirror
+support https. Closes: #962776
+
+ -- Steve McIntyre <93...@debian.org>  Tue, 16 Jun 2020 21:54:52 +0100
+
 jigdo (0.7.3-5) unstable; urgency=medium
 
   * Switch addresses from atterer.org to atterer.org in various places
diff -Nru jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch 
jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch
--- jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch2017-12-07 
15:40:56.0 +
+++ jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch2020-06-16 
21:54:52.0 +0100
@@ -17,3 +17,12 @@
  *) return 1;
esac
  }
+@@ -596,7 +596,7 @@ imageDownload() {
+ for pass in x xx xxx  x xx xxx ; do
+   $jigdoFile print-missing-all --image="$image" --jigdo="$jigdoF" \
+ --template="$template" $jigdoOpts $uriOpts \
+-  | egrep -i '^(http:|ftp:|$)' >"$list"
++  | egrep -i '^(http:|https:|ftp:|$)' >"$list"
+   missingCount=`egrep '^$' <"$list" | wc -l | sed -e 's/ *//g'`
+   # Accumulate URLs in $@, pass them to fetchAndMerge in batches
+   shift "$#" # Solaris /bin/sh doesn't understand "set --"
diff -Nru jigdo-0.7.3/debian/patches/07.more_https_support.patch 
jigdo-0.7.3/debian/patches/07.more_https_support.patch
--- jigdo-0.7.3/debian/patches/07.more_https_support.patch  1970-01-01 
01:00:00.0 +0100
+++ jigdo-0.7.3/debian/patches/07.more_https_support.patch  2020-06-16 
21:54:52.0 +0100
@@ -0,0 +1,46 @@
+commit 53abb98c46c9ee2d298b29359f1376aea1891f88
+Author: Steve McIntyre 
+Date:   Thu Nov 7 18:16:20 2019 +
+
+Make jigdo-mirror believe in https too
+
+diff --git a/scripts/jigdo-mirror b/scripts/jigdo-mirror
+index 1324f11..fb0aa3b 100644
+--- a/scripts/jigdo-mirror
 b/scripts/jigdo-mirror
+@@ -105,12 +105,16 @@ userAgent="jigdo-mirror/1.0 (`wget --version 2>/dev/null 
| (read ver; echo $ver)
+ #__
+ 
+ # isURI 
+-# Returns 0 (true) if the supplied string is a HTTP/FTP URL, otherwise 1
++# Returns 0 (true) if the supplied string is a HTTP/HTTPS/FTP/FILE
++# URL, otherwise 1
+ isURI() {
+-case "$1" in
+-http:*|ftp:*|HTTP:*|FTP:*|file:*|FILE:*) return 0;;
+-*) return 1;
+-esac
++  case "$1" in
++[hH][tT][tT][pP]:*) return 0;;
++[hH][tT][tT][pP][sS]:*) return 0;;
++[fF][tT][pP]:*) return 0;;
++[fF][iI][lL][eE]:*) return 0;;
++*) return 1;
++  esac
+ }
+ #__
+ 
+@@ -193,11 +197,11 @@ makeImage() {
+ for pass in x xx xxx  x xx xxx ; do
+ if $havePMA; then
+ $jigdoFile print-missing-all $ijtOpts $jigdoOpts $uriOpts \
+-| egrep -i '^(http:|ftp:|$)' >"list"
++| egrep -i '^(https:|http:|ftp:|$)' >"list"
+ else
+ # Quick hack until jigdo-port supports print-missing-all
+ $jigdoFile print-missing $ijtOpts $jigdoOpts $uriOpts \
+-| egrep -i '^(http:|ftp:|$)' \
++| egrep -i '^(https:|http:|ftp:|$)' \
+ | sed -n '/./{p;s/^.*$//;p;}' >"list"
+ fi
+ missingCount=`egrep '^$' <"list" | wc -l | sed -e 's/ *//g'`
diff -Nru jigdo-0.7.3/debian/patches/series jigdo-0.7.3/debian/patches/series
--- jigdo-0.7.3/debian/patches/series   2017-12-07 16:38:20.0 +
+++ jigdo-0.7.3/debian/patches/series   2020-06-16 21:54:52.0 +0100
@@ -5,3 +5,4 @@
 04.jigdo-lite-tmpdir.patch
 05.jigdo-lite-grep-options.patch
 06.jigdo-lite-store-filesPerFetch.patch
+07.more_https_support.patch

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

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

Bug#962981: ITP: fonts-sil-akatab -- font for rendering Tifinagh characters

[Bobby de Vos]

Package: wnpp
Version N/A; reported 2020-06-16
Severity: wishlist

Greetings,

My team at SIL-WSTech has released a font not in Debian, Akatab,
that I would like to package for Debian.

Package name: fonts-sil-akatab
Version : 1.000
Upstream Author : SIL WSTech 
URL : https://software.sil.org/akatab/
License : OFL-1.1
Section : fonts
Description : Akatab is a Unicode font for rendering Tifinagh
characters in the Tamahaq and Tamashek languages

Akatab ("writing") is designed to reflect a handwriting style and even
the "writing in sand" effect. This Character Inventory document
demonstrates the characters that are included in the font.

This font uses state-of-the-art OpenType and Graphite font technologies
to provide accurate typography including the formation of bi-consonant
ligatures. Variations of characters are included in the font to meet
personal and regional preferences. Documentation included with the font
package will show these variants and how to access them.

Historically this writing system has been written in both right-to-left
and left-to-right orientations. Akatab has the necessary characters and
technical features to write in both directions.

Inclusion of basic Latin repertoire is provided as a convenience, e.g.,
for use in menus or for displaying markup in text files. This font is
not intended for extensive Latin script use.

The Tifinagh block was first added to Unicode 4.1 and subsequently
amended up through Unicode 6.1. See the latest code chart.

It builds those binary packages:

fonts-sil-akatab - Arabic script font for the Kano region

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

https://software.sil.org/akatab/

Fabian Greffrath or Daniel Glassey can sponsor this package.

Regards,
Bobby
-- 
Bobby de Vos
/bobby_de...@sil.org/



signature.asc
Description: OpenPGP digital signature

Bug#858512: xfstt: xset fp+ unix/:7101 -> Incorrect font server address or syntax

[Andrey ``Bass'' Shcheglov]

This can actually be a consequence of `libxfont1` package no longer built with 
`--enable-fc`,
i. e. X server (which depends on `libxfont2`) is no longer capable of 
understanding
the `tcp/host:7100`, `inet/host:7100` and `unix/:7100` font path URL syntax.

So this bug is related to bug #927375, and, until it's fixed, both `libxfont1` 
and `libxfont2`
packages should claim they're breaking `xfstt` in exactly the same manner 
they're currently
breaking `xfs` (from Debian 7).

-- 
Regards,
Andrey ``Bass'' Shcheglov.

Bug#962560: code-saturne built-in file editor fails

[Gilles Filippini]

Hi Clinton,

On Tue, 9 Jun 2020 14:08:12 -0700 Clinton Winant
 wrote:
> Package: code-saturne
>   Version: 6.0
> 
>   Severity: grave - makes the package  unusable or mostly so: output in
> built-in editor causes SaturneGUI to crash
> 
>   When I try to examine output files with the code-saturne built-in
>   file editor, the program terminates with error on the console of the
>   following kind:
> 
> for EnSight output
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py",
> line 910, in _explorerDoubleClick
> self._viewSelectedFile()
>   File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py",
> line 745, in _viewSelectedFile
> self.openFile(fn=fn)
>   File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py",
> line 991, in openFile
> text = file.read()
>   File "/usr/lib/python3.8/codecs.py", line 322, in decode
> (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0:
> invalid start byte
> ./SaturneGUI: line 7:  5541 Aborted \code_saturne gui $@
> 
> for MED output
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py",
> line 745, in _viewSelectedFile
> self.openFile(fn=fn)
>   File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py",
> line 991, in openFile
> text = file.read()
>   File "/usr/lib/python3.8/codecs.py", line 322, in decode
> (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0:
> invalid start byte
> ./SaturneGUI: line 7:  5843 Aborted \code_saturne gui $@
> 
> CGNS formatted output behaves in the same way.  Histogram files (.txt)
> are displayed correctly ( but the output is of little value.
> 
>   I am using Debian GNU/Linux testing (Bullseye), kernel Debian 5.6.14-1
> (2020-05-23)
>   ldd --version
> ldd (Debian GLIBC 2.30-8) 2.30

I've reported this issue to upstream and they think this might be
related to your dataset. Would you mind sharing an example producing
these errors?

Thanks in advance,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#962979: RM: rust-python27-sys -- RoQA; Py2 specific, no reverse deps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove rust-python27-sys. It's Python 2-specific and there are
no reverse deps. Acked by Sylvestre (CCed) in #938423.

Cheers,
Moritz

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Adam D. Barratt]

On Tue, 2020-06-16 at 16:40 +0200, Julien Cristau wrote:
> On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> > Control: severity -1 serious
> > 
> > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum wrote:
> > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > > something in udd seems to extract entire source packages to
> > > > > /tmp/getwatch.*.  This fills up the disk.  Please make it not
> > > > > do that.
[...]
> > This happened again.  If it won't get fixed I'll go ahead and
> > disable that job.
> > 
> Done now, removed the "upstream" importer from the config file.
> 

It looks like that wasn't enough, as ullmann filled its disk again.

I've now also updated rudd.conf to disable the importer there.

Regards,

Adam

Bug#962980: RM: pysycache -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pysycache. It's dead upstream, unmaintained (last maintainer 
upload in 2010)
and depends on Python 2.

Cheers,
Moritz

Bug#918744: stretch-pu: package opensc/0.1.9-1~deb9u1

[Hilko Bengen]

* Adam D. Barratt:

>> Reading through the changelog between the two Debian versions, there
>> are several changes that we normally would not consider, including a
>> switch to Debhelper 11 and a change of supported OpenSSL version.
>> 
>> In order to try and assess the practical impact, would it be possible
>> to have a binary debdiff between the current packages and your
>> proposed
>> upload.
>
> That was over a year ago now, and there doesn't appear to have been any
> further response.
>
> We're now planning for the final point release for stretch before it
> moves to LTS status, so it may be too late to handle this in practical
> terms.

Sorry for forgetting.

I'm inclined to leave this unresolved.

I'm assuming that that most if not all users who have run into the
YubiKey/OpenSC problems have upgraded to buster (or beyond) or solved
their problems otherwise.

If you think this is still worthwhile fixing, here's an updated
.debian.tar.xz with Debhelper and OpenSSL build-dependencies changed to
match those of opensc/0.16.0-3+deb9u1. Unfortunately, I am unable to
test this properly right now.

Cheers,
-Hilko


opensc_0.19.0-1~deb9u1.debian.tar.xz
Description: application/xz

Bug#952626: cont...@bugs.debian.org

[Sebastien Bacher]

severity 952626 normal
thanks

The current version built fine, seems rather a flacky test if anything
Could you perhaps try if you see the issue still with 0.9?
https://buildd.debian.org/status/package.php?p=bolt&suite=unstable

Bug#962978: podman exec fails, reporting an AppArmor problem

[Ben Hutchings]

Package: podman
Version: 1.6.4+dfsg1-3
Severity: important

Dear Maintainer,

When I run "podman exec ..." on a running container, it always fails:

$ sudo podman exec 8791af6116b9 ps
Error: AppArmor not initialized correctly: OCI runtime error

(This is a multi-process container running systemd; I don't know if
that makes a difference to the behaviour.)

I was able to work around this by adding "apparmor=0" to the kernel
command line.

Ben.

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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)

Versions of packages podman depends on:
ii  conmon   2.0.9-1
ii  containernetworking-plugins  0.8.5-1
ii  crun 0.13+dfsg-1
ii  libc62.30-8
ii  libdevmapper1.02.1   2:1.02.167-1+b1
ii  libgpgme11   1.13.1-6
ii  libseccomp2  2.4.3-1+b1

Versions of packages podman recommends:
ii  buildah 1.11.6-1
ii  fuse-overlayfs  1.0.0-1
ii  slirp4netns 1.0.1-1
ii  tini0.18.0-1+b1
ii  uidmap  1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  

-- no debconf information

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#962977: ITP: nanofilt -- filtering and trimming of long read sequencing data

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: nanofilt -- filtering and trimming of long read sequencing data
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: nanofilt
  Version : 2.6.0
  Upstream Author : Wouter De Coster
* URL : https://github.com/wdecoster/nanofilt
* License : GPL-3
  Programming Lang: Python
  Description : filtering and trimming of long read sequencing data
 Filtering and trimming of long read sequencing data. Filtering on
 quality and/or read length, and optional trimming after passing filters.
 Reads from stdin, writes to stdout. Optionally reads directly from an
 uncompressed file specified on the command line.
 .
 Intended to be used: 
 1. directly after fastq extraction. 
 2. prior to mapping. 
 3. in a stream between extraction and mapping.

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

Bug#962976: RFA: nedit -- powerful, customizable, Motif based text editor

[Paul Gevers]

Package: wnpp
Severity: normal

I request an adopter for the nedit package. I became the maitainer of
nedit back in the days when I was searching for ways to contribute to
Debian, the package was orphaned. However, I never really used nedit
myself, but, as there wasn't much happening upstream, the situation
was OK. Today, I was pointed at a seemingly active fork of it [1],
which I don't intent to handle. So it's time for me to request for
adoption.

Paul

[1] https://sourceforge.net/projects/xnedit/

The package description is:
 NEdit is a multi-purpose text editor for the X Window System, which
 combines a standard, easy to use, graphical user interface with the
 thorough functionality and stability required by users who edit text
 eight hours a day. It provides intensive support for development in
 a wide variety of languages, text processors, and other tools, but
 at the same time can be used productively by just about anyone who
 needs to edit text.
 .
 Because of its mature age, NEdit does not support UTF-8 text files,
 nor will that be implemented.



signature.asc
Description: OpenPGP digital signature

Bug#962773: libpcre2-dev: Linuxinfo fails to link: ./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'

[Helge Kreutzmann]

Hello Matthew,
thanks for your reply.
On Tue, Jun 16, 2020 at 07:24:29PM +0100, Matthew Vernon wrote:
> On 13/06/2020 20:44, Helge Kreutzmann wrote:
> 
> > gcc  -g -O2 -fdebug-prefix-map=/tmp/testfoo2/linuxinfo-3.1.2=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -lpcre2-8 
> > -Wl,-z,relro -o linuxinfo linuxinfo.o linuxinfo_common.o linuxinfo_arm.o 
> > linuxinfo_alpha.o linuxinfo_ia64.o linuxinfo_intel.o linuxinfo_m68k.o 
> > linuxinfo_ppc.o linuxinfo_sh.o linuxinfo_hppa.o linuxinfo_s390.o 
> > linuxinfo_avr.o linuxinfo_sparc.o linuxinfo_mips.o linuxinfo_unknown.o
> > /usr/bin/ld: linuxinfo_common.o: in function `regstrcmp':
> > ./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'
> 
> This is a bit confusing to me, as I think the symbol is there -
> 
> if you do objdump -T [path to your libpcre2-8.so] do you see pcre2_compile_8
> (et al) there?

In my sid chroot:
root@samd:/# objdump -T /usr/lib/x86_64-linux-gnu/libpcre2-8.so | grep 
pcre2_compile_8
ba80 gDF .text  55cf  Base pcre2_compile_8

> On my testing system, I do...

Is this the expected output?

Greetings

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


signature.asc
Description: PGP signature

Bug#958953: stretch-pu: package cups/2.2.1-8+deb9u6

[Didier 'OdyX' Raboud]

15 juin 2020 21:43 "Adam D. Barratt"  a écrit:
> On Mon, 2020-04-27 at 09:03 +0200, Didier 'OdyX' Raboud wrote:
>> CVE-2020-3898 and CVE-2019-8842 got fixed in unstable and pending for
>> stable (#958814), after coordinated disclosure.
>> 
>> I'd like to fix these in an oldstable upload too:
>> 
>> cups (2.2.1-8+deb9u6) stretch; urgency=medium
>> 
>> * Backport upstream security fixes:
>> - CVE-2020-3898: heap-buffer-overflow in libcups’s
>> ppdFindOption()
>> function in ppd-mark.c
>> - CVE-2019-8842: The `ippReadIO` function may under-read an
>> extension
>> field
> 
> Please go ahead; sorry for the delay.

NP; uploaded.

Thanks for your time,

OdyX

Bug#962773: libpcre2-dev: Linuxinfo fails to link: ./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'

[Matthew Vernon]

Hi,

On 13/06/2020 20:44, Helge Kreutzmann wrote:


gcc  -g -O2 -fdebug-prefix-map=/tmp/testfoo2/linuxinfo-3.1.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -lpcre2-8 
-Wl,-z,relro -o linuxinfo linuxinfo.o linuxinfo_common.o linuxinfo_arm.o 
linuxinfo_alpha.o linuxinfo_ia64.o linuxinfo_intel.o linuxinfo_m68k.o 
linuxinfo_ppc.o linuxinfo_sh.o linuxinfo_hppa.o linuxinfo_s390.o 
linuxinfo_avr.o linuxinfo_sparc.o linuxinfo_mips.o linuxinfo_unknown.o
/usr/bin/ld: linuxinfo_common.o: in function `regstrcmp':
./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'


This is a bit confusing to me, as I think the symbol is there -

if you do objdump -T [path to your libpcre2-8.so] do you see 
pcre2_compile_8 (et al) there?


On my testing system, I do...

Regards,

Matthew

Bug#911569: src:haskell-hit: dead upstream, not worth the maintenance burden?

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-hit -- ROM; broken and dead upstream
Control: severity -1 normal

Hi,

Please remove haskell-hit from Debian. It is unmaintained and doesn't
work with the latest version of GHC.

Thanks,

-- 
Ilias

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Thorsten Glaser]

Ben Hutchings dixit:

>This is the dpkg bug where it fails to replace a directory with a
>symlink.  For some reason that requires workarounds in every other
>package instead of being fixed in dpkg.

Yeah, this is annoying, but AIUI they call it a feature; a local
admin can symlink directories around if they suddenly lack space
on a partition (this was before bind mounts existed).

Thanks,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#962902: [debian-mysql] Bug#962902: server does not start

[Otto Kekäläinen]

> My question is: Why does the server sometimes require this file to be
> present, and where? I mean, this software has imho no business asking
> for that file, to begin with.

I have never seen this issue anywhere and I have no clue what that
file is. If you can provide instructions how to reproduce it, I could
try to dig into what it is about.

Bug#905385: stretch-pu: package weboob/1.2-1

[Adam D. Barratt]

On Tue, 2020-06-16 at 18:05 +0900, Marc Dequènes (duck) wrote:
> Quack,
> 
> On 2020-06-16 04:37, Adam D. Barratt wrote:
> 
> > We're now planning for the final point release for stretch before
> > it moves to LTS support. Is this still something that you're
> > (either of you) interested in fixing for stretch?
> 
> Thanks for reaching out.
> 
> Since a removal request was pushed forcefully I assumed it would
> affect all suites.

No, removal from unstable only affects that suite, and subsequently
testing. For (old)stable, separate removal requests are needed.

The package wasn't in testing at the point of the buster release, so
isn't in stable, but is currently still in oldstable (and jessie, aka
oldoldstable, but that's entirely unchangeable and will be archived
soon).

> Anyway I see no point in fixing the package instead of removal at
> this stage, unless this is impossible to undesirable for the release
> of course.

That's entirely your choice. I'll convert this request to a removal
from oldstable,  but if you do decide that you'd like to update it
instead then please let us know ASAP.

Regards,

Adam

Bug#962975: tiger: Missing dependency on lsb-release

[Elliott Mitchell]

Package: tiger
Version: 1:3.2.4~rc1-1

The configuration may be unusual, but during the update to the current
stable, I ended up not installing the lsb-release package.  This could
be very unusual, but from tiger's cron script it appears tiger actually
depends upon lsb-release.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#962861: RFP: drm-info -- Small utility to dump info about DRM devices

[Sudip Mukherjee]

ooi, I had a look at the coredump.

#0  0x in ?? ()
#1  0x7f43bfe22751 in ?? () from /lib/x86_64-linux-gnu/libpci.so.3
#2  0x7f43bfe2054a in ?? () from /lib/x86_64-linux-gnu/libpci.so.3
#3  0x7f43bfe208b7 in pci_lookup_name () from
/lib/x86_64-linux-gnu/libpci.so.3
#4  0x55f574f94bb2 in print_device (obj=) at ../pretty.c:106
#5  0x55f574f95ac4 in print_node (obj=0x55f57511a9c0,
path=) at ../pretty.c:774
#6  print_drm (obj=) at ../pretty.c:795
#7  0x55f574f8f482 in main (argc=1, argv=) at ../main.c:36


-- 
Regards
Sudip

Bug#962972: workaround until firmware-realtek is updated

[Grant Grundler]

sudo bash
cd /lib/firmware/rtl_nic
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153b-2.fw
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153a-4.fw
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153a-3.fw
wget
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8153a-2.fw
^D

Kudos to Sedat Dilek  in comment #30 of bug 947356
for "pointing out the obvious". :)
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947356#30

Bug#946308: freespace2: diff for NMU version 3.7.4+repack-1.1

[Adrian Bunk]

On Wed, Jun 17, 2020 at 12:36:23AM +1000, Dmitry Smirnov wrote:
> On Wednesday, 17 June 2020 12:05:19 AM AEST Adrian Bunk wrote:
> > I've prepared an NMU for freespace2 (versioned as 3.7.4+repack-1.1) and
> > uploaded it to DELAYED/14. Please feel free to tell me if I should
> > cancel it.
> 
> Thank you very much for your help.

Thanks, rescheduled for immediate upload.

> Cheers,
>  Dmitry Smirnov.

cu
Adrian

Bug#962974: t-coffee: fills RAM after reporting PID too high

[Étienne Mollier]

Package: t-coffee
Version: 13.41.0.28bdc39+dfsg-3
Severity: normal

Dear Maintainer,

When launching the t_coffee command with a high PID, probably
above the threshold of 26, the program remains stuck in a
loop involving a memory leak.

To reproduce the issue, you need a system with a pid_max way
higher than 26.  For instance I have the new default from
Linux:

$ cat /proc/sys/kernel/pid_max
4194304

and launching the command with the -version flag is sufficient
to trigger the bug (assuming the PID affected was higher than
26):

$ t_coffee -version
PROGRAM: T-COFFEE Version_13.41.0.28bdc39 (2019-11-30 10:21:53 - 
Revision 5d5a1c1 - Build 465)

--ERROR: MAX_N_PID exceded -- Recompile changing the value of MAX_N_PID 
(current: 26 Requested: 374228)
^C** Forced interuption of main parent process 374228
User defined signal 1

(SIGINT is trapped, so sending SIGUSR1 is necessary to stop it.)

Apparently pushing MAX_N_PID to 4194304, if possible, might help
in solving this is issue.

Kind Regards,
Étienne.


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/6 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages t-coffee depends on:
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libstdc++6  10.1.0-3

Versions of packages t-coffee recommends:
ii  amap-align  2.2+git20080214.600fc29+dfsg-1
ii  clustalo1.2.4-6
ii  clustalw2.1+lgpl-6
ii  dialign-tx  1.0.2-12
ii  fsa 1.15.9+dfsg-4
ii  kalign  1:3.2.3-3
ii  libsoap-lite-perl   1.27-1
ii  libxml-simple-perl  2.25-1
ii  mafft   7.467-1
ii  muscle  1:3.8.1551-2
ii  mustang 3.2.3-3
ii  ncbi-blast+ 2.10.0-1
ii  poa 2.0+20060928-8
ii  prank   0.0.170427+dfsg-2
ii  probcons1.12-12
ii  proda   1.0-12
ii  tm-align20190822+dfsg-2

Versions of packages t-coffee suggests:
pn  boxshade   
pn  seaview
pn  t-coffee-examples  

-- no debconf information

-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Ben Hutchings]

Control: notfixed 942861 5.3.9-1
Control: forcemerge 942861 -1

On Tue, 2020-06-16 at 17:44 +0100, Ben Hutchings wrote:
> Control: found -1 5.3.2-1~exp1
> 
> On Wed, 10 Jun 2020 13:55:17 +0200 Thorsten Glaser  wrote:
> > Package: linux-image-amd64
> > Version: 5.6.14-2
> > Severity: serious
> > Justification: Policy 2.3
> > 
> > tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
> > total 0
> > tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
> > drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/
> 
> This is the dpkg bug where it fails to replace a directory with a
> symlink.  For some reason that requires workarounds in every other
> package instead of being fixed in dpkg.
> 
> This instance was introduced by:
> 
> commit 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
> Author: Ben Hutchings 
> Date:   Tue Oct 1 22:27:29 2019 +0100
> 
> Require metapackage dependencies to be the same version, and link doc dirs

Actually you already reported this as #942861 and I applied the
workaround, but it looks like I specified the wrong prior-version to
dpkg-maintscript-helper.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



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

Bug#962972: firmware-realtek: unable to load firmware patch rtl_nic/rtl8153a-2.fw (-2)

[Grant Grundler]

Package: firmware-realtek
Version: 20190717-2
Severity: important

TL;DR Please update rtl_nic. This will solve most of the issues reported 
against rtl815x devices.

Linux gggnuc6 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux

Errors that an update will fix:
[79912.317675] r8152 2-2.4:1.0: firmware: failed to load rtl_nic/rtl8153a-2.fw 
(-2)
[79912.317683] r8152 2-2.4:1.0: Direct firmware load for rtl_nic/rtl8153a-2.fw 
failed with error -2
  AND
[79912.458292] r8152 2-2.1:1.0: firmware: failed to load rtl_nic/rtl8153b-2.fw 
(-2)
[79912.458296] r8152 2-2.1:1.0: Direct firmware load for rtl_nic/rtl8153b-2.fw 
failed with error -2


"modprobe r8152" results in the following dmesg output:
[78645.896245] r8152 2-2.1:1.0 enx00e04cf007a4: carrier on
[79887.986255] usbcore: deregistering interface driver r8152
[79887.986552] r8152 2-2.1:1.0 enx00e04cf007a4: Stop submitting intr, status 
-108
[79888.042247] r8152 2-2.4:1.0 enx0023568c0143: Stop submitting intr, status 
-108
[79912.294537] usb 2-2.4: reset SuperSpeed Gen 1 USB device number 4 using 
xhci_hcd
[79912.317675] r8152 2-2.4:1.0: firmware: failed to load rtl_nic/rtl8153a-2.fw 
(-2)
[79912.317683] r8152 2-2.4:1.0: Direct firmware load for rtl_nic/rtl8153a-2.fw 
failed with error -2
[79912.317687] r8152 2-2.4:1.0: unable to load firmware patch 
rtl_nic/rtl8153a-2.fw (-2)
[79912.351441] r8152 2-2.4:1.0 eth0: v1.11.11
[79912.354955] r8152 2-2.4:1.0 enx0023568c0143: renamed from eth0
[79912.434704] usb 2-2.1: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[79912.458292] r8152 2-2.1:1.0: firmware: failed to load rtl_nic/rtl8153b-2.fw 
(-2)
[79912.458296] r8152 2-2.1:1.0: Direct firmware load for rtl_nic/rtl8153b-2.fw 
failed with error -2
[79912.458298] r8152 2-2.1:1.0: unable to load firmware patch 
rtl_nic/rtl8153b-2.fw (-2)
[79912.491249] r8152 2-2.1:1.0 eth0: v1.11.11
[79912.491294] usbcore: registered new interface driver r8152
[79912.496221] r8152 2-2.1:1.0 enx00e04cf007a4: renamed from eth0
[79915.982266] IPv6: ADDRCONF(NETDEV_CHANGE): enx0023568c0143: link becomes 
ready
[79915.982925] r8152 2-2.4:1.0 enx0023568c0143: carrier on
[79916.304655] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04cf007a4: link becomes 
ready
[79916.305100] r8152 2-2.1:1.0 enx00e04cf007a4: carrier on


The rtl8153a-2 and rtl8153a-3 devices are widely used and Realtek finally 
upstreamed
the firmware patching mechanism they had in their inhouse driver around Q4 2019:
 
https://lore.kernel.org/netdev/1394712342-15778-335-taiwan-albe...@realtek.com/

These patches helped chrome OS reliably detect and use RTL8153 devices.

However, the rtl8153a-3.fw file Realtek original submitted was broken and was
updated in Feb 2020 and ChromeOS picked up this update in April, 2020:

https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+log/refs/heads/master/rtl_nic

https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/db0430c080d38e3055aec81f44b4c84012dba079

While I'm using a personal email to request this update, I am also 
grund...@chromium.org
and have extensively tested these patches. They work.

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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.137

-- no debconf information

Bug#902901: FTBFS: Tests fail

[Ilias Tsitsimpis]

This package is still unbuildable after 2 years, with no response from
upstream. Since there are no rev dependencies for this package, I intend
to remove it from Debian.

-- 
Ilias

Bug#962973: haskell-readline: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-readline
Version: 1.0.3.0-9
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (last upstream upload in 2013).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962971: python3-ruamel.yaml.clib: overwrites files from python3-ruamel.yaml without Replaces

[Simon McVittie]

Package: python3-ruamel.yaml.clib
Version: 0.2.0-1
Severity: serious
Justification: Policy 7.6.1

Steps to reproduce:
* Have python3-ruamel.yaml from testing
* Upgrade

Expected result: successful upgrade

Actual result:

> Preparing to unpack .../25-python3-ruamel.yaml.clib_0.2.0-1_amd64.deb ...
> Unpacking python3-ruamel.yaml.clib (0.2.0-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-w9QDSF/25-python3-ruamel.yaml.clib_0.2.0-1_amd64.deb 
> (--unpack):
>  trying to overwrite 
> '/usr/lib/python3/dist-packages/_ruamel_yaml.cpython-38-x86_64-linux-gnu.so', 
> which is also in package python3-ruamel.yaml 0.15.89-3+b2
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Preparing to unpack .../26-python3-ruamel.yaml_0.16.10-2_all.deb ...
> Unpacking python3-ruamel.yaml (0.16.10-2) over (0.15.89-3+b2) ...
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-w9QDSF/25-python3-ruamel.yaml.clib_0.2.0-1_amd64.deb

Workaround: retry the upgrade until apt decides to upgrade
python3-ruamel.yaml before installing python3-ruamel.yaml.clib.

This looks like the "Split, new A always requires new B" case from
. The solution is usually
to have:

Package: python3-ruamel.yaml
Depends: python3-ruamel.yaml.clib (>= some version)

Package: python3-ruamel.yaml.clib
Breaks: python3-ruamel.yaml (<< 0.16.10)
Replaces: python3-ruamel.yaml (<< 0.16.10)

so that they have to be upgraded together, with python3-ruamel.yaml
temporarily broken during the upgrade transaction.

Thanks,
smcv

Bug#962969: lsb-release: lsb_release references non-existent lsb(8)

[Nick Black]

Package: lsb-release
Version: 11.1.0
Severity: minor

Dear Maintainer,

The lsb_release(1) man page contains a SEE ALSO entry for lsb(8). So far as I
can tell, this page does not exist in any Debian package (apt-file search
man8/lsb). The reference ought be removed.



-- Package-specific info:
lsb_release output
-*- -*- -*- -*- -*-
Distributor ID: Debian
Description:Debian GNU/Linux bullseye/sid
Release:unstable
Codename:   sid
-*- -*- -*- -*- -*-
Apt policy
-*- -*- -*- -*- -*-
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://packages.microsoft.com/repos/vscode stable/main amd64 Packages
 release o=vscode stable,a=stable,n=stable,l=vscode stable,c=main,b=amd64
 origin packages.microsoft.com
 500 http://dl.google.com/linux/chrome/deb stable/main amd64 Packages
 release v=1.0,o=Google LLC,a=stable,n=stable,l=Google,c=main,b=amd64
 origin dl.google.com
 500 https://www.dsscaw.com/repos/apt/debian unstable/main amd64 Packages
 release o=Dirty South Supercomputing,n=unstable,l=Dirty South 
Supercomputing,c=main,b=amd64
 origin www.dsscaw.com
   1 http://ftp.us.debian.org/debian experimental/contrib amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
   1 http://ftp.us.debian.org/debian experimental/non-free amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
   1 http://ftp.us.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 300 http://ftp.us.debian.org/debian unstable/contrib amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
 300 http://ftp.us.debian.org/debian unstable/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 300 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
Pinned packages:
 libcudf-dev -> 0.8-3+b1 with priority 800
 libnppim10 -> 10.2.89-1 with priority 800
 libcudf-ocaml-dev -> 0.8-3+b1 with priority 800
 libnppicc10 -> 10.2.89-1 with priority 800
 libnvgraph10 -> 10.2.89-1 with priority 800
 libcuinj64-10.2 -> 10.2.89-1 with priority 800
 libnpps10 -> 10.2.89-1 with priority 800
 nvidia-cuda-toolkit-gcc -> 10.2.89-1 with priority 800
 libnppitc10 -> 10.2.89-1 with priority 800
 libnvtt2 -> 2.1.0-git20160229+dfsg-2~exp1+b4 with priority 800
 libcubew-dev -> 4.4~rc2-1 with priority 800
 libcubew-doc -> 4.4~rc2-1 with priority 800
 libcublaslt10 -> 10.2.89-1 with priority 800
 libcupti10.2 -> 10.2.89-1 with priority 800
 libcusparse10 -> 10.2.89-1 with priority 800
 libcublas10 -> 10.2.89-1 with priority 800
 libcusolvermg10 -> 10.2.89-1 with priority 800
 libnppicom10 -> 10.2.89-1 with priority 800
 libnvjpeg10 -> 10.2.89-1 with priority 800
 nvidia-nsight -> 10.2.89-1 with priority 800
 libnvrtc10.2 -> 10.2.89-1 with priority 800
 libcusolver10 -> 10.2.89-1 with priority 800
 nvidia-openjdk-8-jre -> 9.+8u252-b09-1~deb9u1~10.2.89-1 with priority 800
 libnvtt-bin -> 2.1.0-git20160229+dfsg-2~exp1+b4 with priority 800
 nvidia-profiler -> 10.2.89-1 with priority 800
 libnvtoolsext1 -> 10.2.89-1 with priority 800
 libnvtt-dev -> 2.1.0-git20160229+dfsg-2~exp1+b4 with priority 800
 libcupti-dev -> 10.2.89-1 with priority 800
 libcupti-doc -> 10.2.89-1 with priority 800
 libnvblas10 -> 10.2.89-1 with priority 800
 nvidia-cuda-toolkit -> 10.2.89-1 with priority 800
 libnvidia-ml-dev -> 10.2.89-1 with priority 800
 libnppidei10 -> 10.2.89-1 with priority 800
 libcufftw10 -> 10.2.89-1 with priority 800
 nvidia-visual-profiler -> 10.2.89-1 with priority 800
 libnppc10 -> 10.2.89-1 with priority 800
 libcurand10 -> 10.2.89-1 with priority 800
 libnppist10 -> 10.2.89-1 with priority 800
 libnppial10 -> 10.2.89-1 with priority 800
 libnppisu10 -> 10.2.89-1 with priority 800
 libcufft10 -> 10.2.89-1 with priority 800
 libnppif10 -> 10.2.89-1 with priority 800
 nvidia-cuda-dev -> 10.2.89-1 with priority 800
 libcube4w7 -> 4.4~rc2-1 with priority 800
 nvidia-cuda-doc -> 10.2.89-1 with priority 800
 libcudart10.2 -> 10.2.89-1 with priority 800
 libnppig10 -> 10.2.89-1 with priority 800
 nvidia-opencl-dev -> 10.2.89-1 with priority 800
 boinc-client-nvidia-cuda -> 7.16.15+dfsg-1exp1 with priority 800
 nvidia-cuda-gdb -> 10.2.89-1 with priority 800
-*- -*- -*- -*- -*-
   sources.list
-*- -*- -*- -*- -*-
deb http://ftp.us.debian.org/debian/ unstable main non-free contrib
deb-src http://ftp.us.debian.org/debian/ unstable main non-free contrib
deb http://ftp.us.debian.org/d

Bug#962970: haskell-permutation: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-permutation
Version: 0.5.0.5-3
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (last upstream upload in 2015).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Ben Hutchings]

Control: found -1 5.3.2-1~exp1

On Wed, 10 Jun 2020 13:55:17 +0200 Thorsten Glaser  wrote:
> Package: linux-image-amd64
> Version: 5.6.14-2
> Severity: serious
> Justification: Policy 2.3
> 
> tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
> total 0
> tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
> drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/

This is the dpkg bug where it fails to replace a directory with a
symlink.  For some reason that requires workarounds in every other
package instead of being fixed in dpkg.

This instance was introduced by:

commit 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
Author: Ben Hutchings 
Date:   Tue Oct 1 22:27:29 2019 +0100

Require metapackage dependencies to be the same version, and link doc dirs

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



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

Bug#816640: ruby-eventmachine: FTBFS under pbuilder with USENETWORK=no: TestResolver fails (no implicit conversion of nil into String)

[duck]

Quack,

Andreas, could you explain to me why you reopened this ticket? Did you 
stumble on another test using the network? I built the package locally 
and on Salsa and it seemed to be fixed.


Also I don't understand why you merged it with #919085 which seem to 
address a broader problem. I see one test failing on mipsel and other 
failures in non-releasing arches, but it seems the situation is 
different from the original report. I'm not sure how to fix this test 
yet.


Regards.
\_o<

--
Marc Dequènes

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Salvatore Bonaccorso]

Hi Bruce,

On Mon, Jun 15, 2020 at 10:42:12PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote:
> > Thanks for the detailed reproducer.
> > 
> > It's weird, as the server is basically just setting the transmitted
> > umask and then calling into the vfs to handle the rest, so it's not much
> > different from any other user.  But the same reproducer run just on the
> > ext4 filesystem does give the right permissions
> > 
> > Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does:
> > 
> > if (!IS_POSIXACL(path.dentry->d_inode))
> > mode &= ~current_umask();
> > error = security_path_mkdir(&path, dentry, mode);
> > if (!error)
> > error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> > 
> > whereas nfsd just calls into vfs_mkdir().
> > 
> > And that IS_POSIXACL() check is exactly a check whether the filesystem
> > supports ACLs.  So I guess it's the responsibility of the caller of
> > vfs_mkdir() to handle that case.
> 
> But, that's unsatisfying: why isn't vfs_mkdir() taking care of this
> itself?  And what about that security_path_mkdir() call?  And are the
> other cases of that switch in fs/nfsd/vfs.c:nfsd_create_locked()
> correct?  I think there may be some more cleanup here called for, I'll
> poke around tomorrow.

This might be unneeded to test but as additional datapoint which
confirms the suspect: I tried check the commit around 47057abde515
("nfsd: add support for the umask attribute") in 4.10-rc1

A kernel built with 47057abde515~1, and mounting from an enough recent
client which has at least dff25ddb4808 ("nfs: add support for the
umask attribute") does not show the observed behaviour, the server
built with 47057abde515 does.

Regards,
Salvatore

Bug#962530: Tor service won't start when apparmor is active and "/" is on an overlayfs

[Stefan Baur]

Am 16.06.20 um 14:48 schrieb intrigeri:

> So, I have a question:
> 
>> 4. run the following commands:
>>apt update
>>apt install apparmor -y
>>service apparmor start
> 
> Did the apparmor service start before you started it manually?
> I suppose it did not start, hence the need to start it manually,
> right?

That is correct. I ran into this issue on a system that isn't a classic
Debian Live system, but is using overlayfs (to minimize actual file
system writes on a type of flash media that doesn't have wear leveling).

I was looking for an easy way for the maintainer/triager to replicate my
issue, so instead of providing the steps needed to recreate my
particular environment, my choice fell on Debian Live.


[...]
> Tails' customization that makes it work with overlayfs
> lives in files that should be linked from:
> https://tails.boum.org/contribute/design/application_isolation/

Thanks for the pointer.


>> As apparmor is causing the issue, but the corresponding "system_tor"
>> config file is part of the tor package, I figured I should file this
>> against the tor package.  Feel free to reassign the bug to the apparmor
>> package if bugs about broken/incomplete apparmor profiles should be
>> filed against that one.
> 
> I'm reassigning to apparmor: if apparmor.service starts automatically
> in a Debian Live environment, that's a bug in that service.

Well, no, it doesn't start automatically in a Debian Live environment,
but it does start automatically in a pretty much regular Debian
environment that does use overlayfs for the root file system.

So if it's hard to get apparmor and overlayfs to play along nicely,
maybe the check shouldn't be for a Debian Live environment but more
generally for an environment that has its root file system mounted via
overlayfs?  To avoid breaking existing installs of that kind, it should
probably print a warning to syslog instead of disabling apparmor completely.

I found that for me, adding

   /upper/var/lib/tor/** r,

underneath

 # During startup, tor (as root) tries to open various things such as
 # directories via check_private_dir().  Let it.
 /var/lib/tor/** r,

allows me to start tor.  I haven't tried if

 /var/lib/tor/** r,

can/should be removed or needs to stay in that case. Someone more
experienced with apparmor than me should have a look at that, I think.

Note that "/upper" is not the path I'm using during the overlayfs mount,
the mountpoint actually looks like this:
overlay on / type overlay
(rw,relatime,lowerdir=/overlay/root-ro,upperdir=/overlay/root-rw/upper,workdir=/overlay/root-rw/work)

So maybe a generic fix (or a hint at how to fix it) is possible?

On apparmor install/startup, check for an overlay mount, and if it is
present, warn the user that they may need to change/add paths in their
apparmor profiles?

For extra fancyness, you could try to parse the

upperdir=/overlay/root-rw/upper

string and add "you may need to prefix /${upperdir##*/} to paths" or
something like that to the syslog message.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

Bug#962968: libauthen-sasl-perl: Net::LDAP with GSSAPI SASL bind connecting with wrong sasl_ssf on Debian buster

[Richard Landster]

Package: libauthen-sasl-perl
Version: 2.1600-1
Severity: important

Dear Maintainer,

I have a Perl script to read from an OpenLDAP instance using Net::LDAP
with a GSSAPI bind. The script works fine on Debian stretch but fails on
Debian buster.

Note that on both servers the line at the bottom of the Perl code that
runs ldapsearch produces the same correct results, so I am sure that the
Kerberos ticket cache is correct on both servers.

Looking at the OpenLDAP logs I see that the ldapsearch run shows up with
the strength factors sasl_ssf=256 ssf=256 while the Net::LDAP bind shows
up with the strength factors sasl_ssf=1 ssf=256. Since the Net::LDAP bind
is using Kerberos, the sasl_ssf should be 56, not 1.

###

use strict;
use warnings;
use Authen::SASL;
use Net::LDAP;
use Data::Dumper;

my $server_name = 'ldap.example.com';
$ENV{'KRB5CCNAME'} = '/tmp/krb.tkt';

my $ld = Net::LDAP->new($server_name, version => '3');
$ld->start_tls(verify => 'require');

if (!$ld or $ld == -1) {
die "Could not connect to directory server $server_name";
}

my $SASL = Authen::SASL->new('GSSAPI');
my $status = $ld->bind(sasl => $SASL);

if ($status->code) {
die  'Bind error: (' . $status->error_name . ') ' . $status->error_text;
}

my $base   = 'dc=example,dc=com';
my $filter = '(uid=johndoe)';
my @attrs  = ('uid', 'sn');
$status = $ld->search(
base=> 'dc=example,dc=com',
filter  => $filter,
attrs   => \@attrs,
) ;

my @entries = $status->all_entries;
# This results in nothing (but should result in the same data as the ldapsearch 
below):
warn Dumper @entries ;

my $attrs = join(' ', @attrs) ;
my $cmd = "ldapsearch -LLL -h $server_name -b $base '$filter' $attrs";
# This gives the correct result:
warn `$cmd`;


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libauthen-sasl-perl depends on:
ii  perl  5.28.1-6

libauthen-sasl-perl recommends no packages.

Versions of packages libauthen-sasl-perl suggests:
ii  libdigest-hmac-perl  1.03+dfsg-2
ii  libgssapi-perl   0.28-3+b1

-- no debconf information

Bug#962967: ITP: google-oauth-client-java -- Google OAuth Client Library for Java

[Olek Wojnar]

Package: wnpp
Severity: wishlist
Owner: Olek Wojnar 

* Package name: google-oauth-client-java
  Version : 1.27.0
  Upstream Author : Jeff Ching 
* URL : https://github.com/googleapis/google-oauth-java-client
* License : Apache-2.0
  Programming Lang: Java
  Description : Google OAuth Client Library for Java

Powerful and easy-to-use Java library for the OAuth 1.0a and OAuth 2.0
authorization standards. The Google OAuth Client Library for Java is designed
to work with any OAuth service on the web, not just with Google APIs. It is
built on the Google HTTP Client Library for Java.

Bug#858512: xfstt: xset fp+ unix/:7101 -> Incorrect font server address or syntax

[Andrey ``Bass'' Shcheglov]

I confirm this behaviour.

I'm running a Devuan 3 (identical to Debian 10) box.

I've run `xfstt --sync` in order to generate the cache of my TTF font
directories, and configured `xfstt` to also listen at TCP port 7101:

> # cat /etc/default/xfstt 
> LISTEN_TCP='yes'
> ARGS="${ARGS} --port 7101"

This can be confirmed by running `lsof` (despite `aa_DJ.utf8` is *not*
my locale):

> # lsof -p 20380
> COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
> xfstt   20380 root  cwdDIR  254,212288 1314666 
> /usr/share/fonts/truetype
> xfstt   20380 root  rtdDIR  254,1 4096   2 /
> xfstt   20380 root  txtREG  254,2   129224  805495 
> /usr/bin/xfstt
> xfstt   20380 root  memREG  254,4   311653  134640 
> /var/cache/xfstt/ttname.dir
> xfstt   20380 root  memREG  254,2   337024 2111564 
> /usr/lib/locale/aa_DJ.utf8/LC_CTYPE
> xfstt   20380 root  memREG  254,2  2586242 2111562 
> /usr/lib/locale/aa_DJ.utf8/LC_COLLATE
> xfstt   20380 root  memREG  254,1  18244962028 
> /lib/x86_64-linux-gnu/libc-2.28.so
> xfstt   20380 root  memREG  254,1   100712 661 
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> xfstt   20380 root  memREG  254,1  15794483929 
> /lib/x86_64-linux-gnu/libm-2.28.so
> xfstt   20380 root  memREG  254,2  1570256 2104093 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
> xfstt   20380 root  memREG  254,472536  134639 
> /var/cache/xfstt/ttinfo.dir
> xfstt   20380 root  memREG  254,2 3448 2904297 
> /usr/lib/locale/ru_RU.utf8/LC_TIME
> xfstt   20380 root  memREG  254,2  294 2904167 
> /usr/lib/locale/os_RU/LC_MONETARY
> xfstt   20380 root  memREG  254,2   34 2111572 
> /usr/lib/locale/aa_DJ.utf8/LC_PAPER
> xfstt   20380 root  memREG  254,2   62 2111611 
> /usr/lib/locale/agr_PE/LC_NAME
> xfstt   20380 root  memREG  254,2  165 2904294 
> /usr/lib/locale/ru_RU.utf8/LC_ADDRESS
> xfstt   20380 root  memREG  254,2   52 2364393 
> /usr/lib/locale/ce_RU/LC_TELEPHONE
> xfstt   20380 root  memREG  254,2   23 2111567 
> /usr/lib/locale/aa_DJ.utf8/LC_MEASUREMENT
> xfstt   20380 root  memREG  254,226402 2124463 
> /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
> xfstt   20380 root  memREG  254,2  341 2904295 
> /usr/lib/locale/ru_RU.utf8/LC_IDENTIFICATION
> xfstt   20380 root  memREG  254,1   1656321889 
> /lib/x86_64-linux-gnu/ld-2.28.so
> xfstt   20380 root0u  unix 0x88381a63a400  0t0 3349764 
> /tmp/.font-unix/fs7101 type=STREAM
> xfstt   20380 root1u  IPv43344308  0t0 TCP *:7101 
> (LISTEN)
> xfstt   20380 root2u  IPv63344309  0t0 TCP *:7101 
> (LISTEN)


The above can be additionally confirmed by connecting to localhost:7101
with `telnet`.

Still, whenever I'm trying to add an entry to my font path using either
TCP or UNIX sockets, the request fails:

> $ xset fp+ inet/localhost:7101
> xset:  bad font path element (#16), possible causes are:
> Directory does not exist or has wrong permissions
> Directory missing fonts.dir
> Incorrect font server address or syntax
> $ xset fp+ tcp/localhost:7101
> xset:  bad font path element (#16), possible causes are:
> Directory does not exist or has wrong permissions
> Directory missing fonts.dir
> Incorrect font server address or syntax
> $ xset fp+ unix/:7101
> xset:  bad font path element (#16), possible causes are:
> Directory does not exist or has wrong permissions
> Directory missing fonts.dir
> Incorrect font server address or syntax

This problem, until fixed, basically renders the package useless.

-- 
Regards,
Andrey ``Bass'' Shcheglov.



signature.asc
Description: OpenPGP digital signature

Bug#962966: ITP: scrappie -- basecaller for Nanopore sequencer

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: scrappie -- basecaller for Nanopore sequencer
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: scrappie
  Version : 1.4.2
  Upstream Author : Copyright:  
* URL : https://github.com/nanoporetech/scrappie
* License : https://salsa.debian.org/med-team/scrappie

Bug#962965: ITP: yanosim:Read simulator nanopore DRS datasets

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: yanosim
  Version : 0.1
  Upstream Author : Matthew Parker
* URL : https://github.com/bartongroup/yanosim

* License : Expat
  Programming Lang: Python
  Description : Read simulator nanopore DRS datasets

 It has three options:
 1 yanosim model:
 Creates an model of mismatches, insertions and deletions
 based on an alignment of nanopore DRS reads to a
 reference. Reads should be aligned to a transcriptome
 i.e. without spliced alignment, using minimap2. They
 should have the cs tag.
 .
 2 yanosim quantify:
 Quantify the number of reads mapping to each
 transcript in a reference, so that the right number
 of reads can be simulated.
 .
 3 yanosim simulate
 Given a model created using yanosim model, and
 per-transcript read counts created using yanosim
 simulate, simulate error-prone long-reads from the
 given fasta file.

I take the responsibility to maintain this package.

Bug#947803: smartmontools: smartctl -l error causes Micron 2200S NVME to fail

[Michael Becker]

PS: output of lspci -vvvs 71:00.0

71:00.0 Non-Volatile memory controller: Micron Technology Inc Device 5410 (rev 
01) (prog-if 02 [NVM Express])
Subsystem: Micron Technology Inc Device 0100
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [108 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [110 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ 
L1_PM_Substates+
  PortCommonModeRestoreTime=32us PortTPowerOnTime=20us
L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
   T_CommonMode=0us LTR1.2_Threshold=81920ns
L1SubCtl2: T_PwrOn=44us
Capabilities: [200 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr-
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- 
ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 0401 000f 7107 3a74fcf2
Capabilities: [300 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn-, PerformEqu-
LaneErrStat: 0
Kernel driver in use: nvme
Kernel modules: nvme

Bug#947803: smartmontools: smartctl -l error causes Micron 2200S NVME to fail

[Michael Becker]

same here – Debian sid

smartctl --version: smartctl 7.1 2019-12-30 r5022
uname -srvmpio: Linux 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 
unknown unknown GNU/Linux

running smartctl -a /dev/nvme0 results in consecutive messages:

[DRHD]: handling fault status reg 3
[DMA Read]: Request device [71:00.0] PASID  fault addr fd26 [fault 
reason 06] PTE read access is not set

hope this helps a little ...

Bug#962861: RFP: drm-info -- Small utility to dump info about DRM devices

[Sudip Mukherjee]

On Mon, Jun 15, 2020 at 09:35:56AM +0200, Guido Günther wrote:
> Package: wnpp
> Severity: wishlist
> 

> 
> drm_info dumps information about available drm device like available
> devices, planes, encoders, crtcs and connectors and their DRM
> properties.

This looks like an useful utility and I did an initial packaging. But
while testing I get a segfault after printing all the information.

$ drm_info 
Node: /dev/dri/card0
├───Driver: bochs-drm (bochs dispi vga interface (qemu stdvga)) version 1.0.0 
(20130925)
│   ├───DRM_CLIENT_CAP_STEREO_3D supported
│   ├───DRM_CLIENT_CAP_UNIVERSAL_PLANES supported
│   ├───DRM_CLIENT_CAP_ATOMIC supported
│   ├───DRM_CLIENT_CAP_ASPECT_RATIO supported
│   ├───DRM_CLIENT_CAP_WRITEBACK_CONNECTORS supported
│   ├───DRM_CAP_DUMB_BUFFER = 1
│   ├───DRM_CAP_VBLANK_HIGH_CRTC = 1
│   ├───DRM_CAP_DUMB_PREFERRED_DEPTH = 24
│   ├───DRM_CAP_DUMB_PREFER_SHADOW = 0
│   ├───DRM_CAP_PRIME = 0
│   ├───DRM_CAP_TIMESTAMP_MONOTONIC = 1
│   ├───DRM_CAP_ASYNC_PAGE_FLIP = 0
│   ├───DRM_CAP_CURSOR_WIDTH = 64
│   ├───DRM_CAP_CURSOR_HEIGHT = 64
│   ├───DRM_CAP_ADDFB2_MODIFIERS = 0
│   ├───DRM_CAP_PAGE_FLIP_TARGET = 0
│   ├───DRM_CAP_CRTC_IN_VBLANK_EVENT = 1
│   ├───DRM_CAP_SYNCOBJ = 0
│   └───DRM_CAP_SYNCOBJ_TIMELINE = 0
Segmentation fault

I also tried with "drm_info -j" and that works pergectly without any error.

Note: I have used Debian packages of json-c, libdrm and libpci. It will
be good to have a manpage along with the fix for segfault.

--
Regards
Sudip

Bug#962964: haskell-io-choice: Removal notice: broken and obsolete

[Ilias Tsitsimpis]

Source: haskell-io-choice
Version: 0.0.7-1
Severity: grave
Justification: renders package unusable

Since GHC 8.0, IO is now an instance of Alternative, making this package
obsolete (see https://github.com/kazu-yamamoto/io-choice/issues/6).
Newer versions of mighttpd2 do not depend on it anymore, so there are
no rev dependencies left.

I intend to remove this package.

-- 
Ilias

Bug#962963: RFS: sosreport/3.9.1-1 -- Set of tools to gather troubleshooting data from a system

[Eric Desrochers]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sosreport"

* Package name : sosreport
Version : 3.9.1-1
Upstream Author : Bryn M. Reeves
* URL : https://github.com/sosreport/sos
* License : GPL-2+
* Vcs : https://salsa.debian.org/sosreport-team/sosreport
Section : admin

It builds those binary packages:

sosreport - Set of tools to gather troubleshooting data from a system

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/s/sosreport/sosreport_3.9.1-1.dsc

Changes since the last upload:

* New 3.9.1 upstream release.
This maintenance release includes:
- New plugins: sos_extras, ovirt_engine_backup, console,
validation_framework.
- lxd plugin collections have been overhauled.
- Fixed handling of the namespace pattern for the networking
plugin.
- A basic path is now defined in Policy for all subclasses.
.
Plugin API Enhancements:
- Enablement checks have been extended to include architecture
constraints.
- SoSPredicate has been extended to include architecture constraints,
as well as negative constraints for all elements.
- Plugins will now capture service status information for all services
defined in the services class attr.
.
Further release information and tarballs are available at:
- https://github.com/sosreport/sos/releases/tag/3.9.1
.
* Former patches now fixed upstream:
- d/p/0001-unittest-py3-fix.patch
.
* Other specific modifications:
- Include simple.sh, an upstream port of the travis test to bash,
as part of the package autopkgtest.

Regards,

Bug#962875: [Debian-iot-maintainers] Processed: block 962875 with 962876 962877 962878 962879 962880 962881 962882 962883 962884 962885 962886 962887

[Nicolas Mora]

This bug will be resolved when Glewlwyd 2.x will be packaged into unstable.

I'm currently waiting for iddawc in the NEW queue to be accepted in
experimental to move on.



signature.asc
Description: OpenPGP digital signature

Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Adam D. Barratt]

On Tue, 2020-06-16 at 10:06 +0200, Carsten Leonhardt wrote:
> Julien Cristau  writes:
> 
> > Control: tag -1 confirmed
> > Sorry for the delay, please go ahead.
> 
> For information, I've uploaded the package some time ago and it's
> waiting in the NEW queue for FTP master review.

Thanks for the update.

I've asked on IRC if an ftpmaster can have a look (it needs a master
rather than an assistant, in order to get the package to appear in our
review queue afterwards).

Regards,

Adam

Bug#962962: haskell-hstatsd: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-hstatsd
Version: 0.1-7
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (last upstream upload in 2013).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962960: kdiff3: Choose X Everywhere / For All Unsolved menu items missing

[Matthew Gabeler-Lee]

Package: kdiff3
Version: 1.8.01-1+b1
Severity: normal

The Merge menu items to Choose A/B/C Everywhere or For All Unsolved
(Whitespace) Conflicts are not showing up in the kdiff3 build in bullseye. 
Downgrading to the version in buster and they show up again.

I also tried 1.8.01-1 from snapshot.debian.org and it has the same issue.

The changelog shows this entry:

  Don't enable "Choose C for Everthing" on two way merge

but this is also seeming to happen on 3 way merge (via git mergetool)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (490, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kdiff3 depends on:
ii  kio   5.70.1-1
ii  libc6 2.30-8
ii  libkf5configcore5 5.70.0-1
ii  libkf5configwidgets5  5.70.0-1
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5xmlgui5 5.70.0-1
ii  libqt5core5a  5.12.5+dfsg-10+b1
ii  libqt5gui55.12.5+dfsg-10+b1
ii  libqt5printsupport5   5.12.5+dfsg-10+b1
ii  libqt5widgets55.12.5+dfsg-10+b1
ii  libstdc++610.1.0-3

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.8.01-1

kdiff3 suggests no packages.

-- no debconf information

Bug#962961: haskell-gnutls: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-gnutls
Version: 0.2-6
Severity: grave
Justification: renders package unusable

This package seems to be unmaintained (homepage returns 404, last upload
from 2015). It does not build with GHC 8.8, is not part of Stackage and
has no rev dependencies.

I intend to remove this package.

-- 
Ilias

Bug#962959: haskell-edison-api: Removal notice: broken and unuseful

[Ilias Tsitsimpis]

Source: haskell-edison-api
Version: 1.3.1-5
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/robdockins/edison/pull/16

This package does not build with GHC 8.8 and is not part of Stackage.
Agda replaced Edison with Data.Sequence in the latest version, so there
are no rev dependencies anymore.

I intend to remove this package.

-- 
Ilias

Bug#962958: haskell-edison-core: Removal notice: broken and unuseful

[Ilias Tsitsimpis]

Source: haskell-edison-core
Version: 1.3.2.1-3
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/robdockins/edison/pull/16

This package does not build with GHC 8.8 and is not part of Stackage.
Agda replaced Edison with Data.Sequence in the latest version, so there
are no rev dependencies anymore.

I intend to remove this package.

-- 
Ilias

Bug#962957: ITP: puppet-module-etcddiscovery -- Puppet module for Etcd-discovery service

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-etcddiscovery
  Version : 0.1.0
  Upstream Author : Thomas Goirand 
* URL : 
https://salsa.debian.org/openstack-team/puppet/puppet-module-etcddiscovery
* License : Apache-2.0
  Programming Lang: Puppet, Ruby
  Description : Puppet module for Etcd-discovery service

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 Etcd-discovery.

Note: This is part of openstack-cluster-installer, and it's useful for
setting-up magnum without internet connectivity.

Bug#962956: reniced: reniced logs several syntax errors

[Francesco Potortì]

Package: reniced
Version: 1.21-1
Severity: normal

In daemon.log I read:

Jun 16 15:43:03 tucano reniced[3522]: Starting reniced:
Jun 16 15:43:03 tucano reniced[3552]: Starting reniced:
Jun 16 15:43:03 tucano reniced[3552]: rgument " " isn't numeric in addition 
(+) at /usr/bin/reniced line Argument " " isn't numeric in addition (+) at 
/usr/bin/reniced line 435,  line 3.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 4.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 5.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 6.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 7.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 8.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 9.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 10.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 11.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 12.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 13.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 14.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 15.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 16.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 17.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 18.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 19.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 20.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 21.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 22.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 23.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 24.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 25.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 26.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 27.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 28.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 29.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 30.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 31.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 32.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 33.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 34.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 35.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 36.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 37.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 38.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) at /usr/bin/reniced line 435,  line 39.
Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
addition (+) 

Bug#962955: haskell-crypto-pubkey-openssh: Removal notice: broken and unmaintained

[Ilias Tsitsimpis]

Source: haskell-crypto-pubkey-openssh
Version: 0.2.7-9
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/knsd/crypto-pubkey-openssh/pull/23

This package seems to be unmaintained (last upstream upload in 2015).
Does not build with GHC 8.8, is not part of Stackage and has no rev
dependencies.

I intend to remove this package.

-- 
Ilias

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Julien Cristau]

On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> Control: severity -1 serious
> 
> On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum wrote:
> > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > something in udd seems to extract entire source packages to
> > > > /tmp/getwatch.*.  This fills up the disk.  Please make it not do that.
> > > 
> > > Hi,
> > > 
> > > Thanks for reporting.
> > > 
> > > It needs to extract the source packages to get the watch file. I don't
> > > think there's a way to ask dpkg-source to only extract a single file,
> > > and I don't want to re-implement dpkg-source.
> > > 
> > It would be a single call to tar or patch though, which doesn't seem
> > like a huge amount of effort.
> > 
> > > Reviewing the code, there was a path where the tmp dir was not removed.
> > > I've fixed that. I'm not 100% sure this fixes everything, but it should
> > > clearly help.
> > > 
> > There were quite a few getwatch temp dirs before I rebooted ullmann just
> > now because it was out of space.
> > 
> > > However, I also note that /tmp is on /, and / is quite small (only 5.3
> > > GB remaining). Would it be possible to add some disk space for /tmp or /
> > > on ullmann?
> > > 
> > I'd dispute the "quite small" bit, extracting watch files shouldn't need
> > more than 5g.  But you could also put your temp files somewhere under
> > /srv?
> > 
> This happened again.  If it won't get fixed I'll go ahead and disable that 
> job.
> 
Done now, removed the "upstream" importer from the config file.

Cheers,
Julien

Bug#946308: freespace2: diff for NMU version 3.7.4+repack-1.1

[Dmitry Smirnov]

On Wednesday, 17 June 2020 12:05:19 AM AEST Adrian Bunk wrote:
> I've prepared an NMU for freespace2 (versioned as 3.7.4+repack-1.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I should
> cancel it.

Thank you very much for your help.

-- 
Cheers,
 Dmitry Smirnov.

---

A foolish faith in authority is the worst enemy of truth.
-- Albert Einstein


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

Bug#962954: RM: fever [mipsel] -- ICE; FTBFS; Go compiler is broken on mipsel

[Sascha Steinbiss]

Package: ftp.debian.org
Severity: normal

Please remove the old version of the fever binary package from testing
for the mipsel architecture.
Due to #960674, it currently does not build on mipsel as there is a
deeper problem with the Go compiler on this architecture. Please see the
corresponding bug report for more information [1].

I would like to remove this arch that currently blocks testing migration
for upstream version updates. It is very unlikely that the package will
be used on MIPS systems.

Thanks!
Sascha

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

Bug#962953: ITP: wahay -- Easy-to-use, secure and decentralized conference call

[Clement Hermann]

Package: wnpp
Severity: wishlist
Owner: Clement Hermann 

* Package name: wahay
  Version : 0.0~git20200606.4f8e43a-1
  Upstream Author : Centro de Autonomía Digital (https://autonomia.digital)
* URL : https://wahay.org
* License : GPLv3
  Programming Lang: Go
  Description : Easy-to-use, secure and decentralized conference call
 Wahay is voice call application that allows you to easily host and participate
 in conference calls, without the need for any centralized servers or services.
 It is meant to be as easy-to-use as possible, while still providing extremely
 high security and privacy out of the box.
 .
 In order to do this, it uses Tor (https://torproject.org) Onion Services
 in order to communicate between the end-points, and the Mumble
 (https://www.mumble.info) protocol for the actual voice communication.

Bug#962952: azure-cli: exception when connecting to azure services

[Ritesh Raj Sarraf]

Package: azure-cli
Version: 2.6.0-1
Severity: important

rrs@priyasi:~/NoBackup$ az vm user update --resource-group 
lab40-obs-ubuntu-docker-494104 --name obs-ubuntu-docker --username rrs 
--password 

The command failed with an unexpected error. Here is the traceback:

No module named 'antlr4'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/knack/cli.py", line 215, in invoke
cmd_result = self.invocation.execute(args)
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 553, in execute
self.commands_loader.load_arguments(command)
  File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 345, 
in load_arguments
loader.load_arguments(command)  # this adds entries to the argument 
registries
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/vm/__init__.py", line 
31, in load_arguments
from azure.cli.command_modules.vm._params import load_arguments
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/vm/_params.py", line 
31, in 
from azure.cli.command_modules.monitor.actions import get_period_type
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/monitor/actions.py", 
line 7, in 
import antlr4
ModuleNotFoundError: No module named 'antlr4'

To open an issue, please run: 'az feedback'
19:37 ♒ ॐ ♅ ⛢   ☹ 😟=> 1  


I couldn't find any antlr4 named python module in Debian.

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

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

Versions of packages azure-cli depends on:
ii  python33.8.2-3
ii  python3-azure-cli  2.6.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#962951: aptitude: missing command 'status'

[Michael Becker]

Package: aptitude
Version: 0.8.13-1+b1
Severity: wishlist

I would like to have a command 'aptitude status' which shows the last line 
displayed by 'aptitude -v update':

Current status: 0 (+0) broken, 0 (+0) upgradable, 0 (+0) new.

without having to actually check for an update.
This command should be available for non root users.

Bug#946308: freespace2: diff for NMU version 3.7.4+repack-1.1

[Adrian Bunk]

Control: tags 946308 + pending

Dear maintainer,

I've prepared an NMU for freespace2 (versioned as 3.7.4+repack-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru freespace2-3.7.4+repack/debian/changelog freespace2-3.7.4+repack/debian/changelog
--- freespace2-3.7.4+repack/debian/changelog	2018-07-12 11:57:59.0 +0300
+++ freespace2-3.7.4+repack/debian/changelog	2020-06-16 16:22:34.0 +0300
@@ -1,3 +1,10 @@
+freespace2 (3.7.4+repack-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove -march=native usage. (Closes: #946308)
+
+ -- Adrian Bunk   Tue, 16 Jun 2020 16:22:34 +0300
+
 freespace2 (3.7.4+repack-1) unstable; urgency=medium
 
   * New upstream release [July 2016].
diff -Nru freespace2-3.7.4+repack/debian/patches/i386-baseline.patch freespace2-3.7.4+repack/debian/patches/i386-baseline.patch
--- freespace2-3.7.4+repack/debian/patches/i386-baseline.patch	1970-01-01 02:00:00.0 +0200
+++ freespace2-3.7.4+repack/debian/patches/i386-baseline.patch	2020-06-16 16:22:31.0 +0300
@@ -0,0 +1,15 @@
+Description: SSE is not part of the i386 baseline
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/946308
+
+--- freespace2-3.7.4+repack.orig/configure.ac
 freespace2-3.7.4+repack/configure.ac
+@@ -158,7 +158,7 @@ case "$target" in
+ 		fs2_os_linux="yes"
+ 
+ 		if test "$fs2_generic_architecture" = "yes" ; then
+-			D_CFLAGS="$D_CFLAGS -mtune=generic -mfpmath=sse -msse -msse2"
++			D_CFLAGS="$D_CFLAGS -mtune=generic"
+ 		else
+ 			D_CFLAGS="$D_CFLAGS -march=native"
+ 		fi
diff -Nru freespace2-3.7.4+repack/debian/patches/series freespace2-3.7.4+repack/debian/patches/series
--- freespace2-3.7.4+repack/debian/patches/series	2015-04-16 04:46:03.0 +0300
+++ freespace2-3.7.4+repack/debian/patches/series	2020-06-16 16:22:31.0 +0300
@@ -0,0 +1 @@
+i386-baseline.patch
diff -Nru freespace2-3.7.4+repack/debian/rules freespace2-3.7.4+repack/debian/rules
--- freespace2-3.7.4+repack/debian/rules	2018-07-12 11:47:25.0 +0300
+++ freespace2-3.7.4+repack/debian/rules	2020-06-16 16:22:31.0 +0300
@@ -15,7 +15,7 @@
 $(info DEB_BUILD_MAINT_OPTIONS:$(origin DEB_BUILD_MAINT_OPTIONS)=$(DEB_BUILD_MAINT_OPTIONS))
 
 #LDFLAGS+= -Wl,--as-needed
-CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech
+CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech --enable-generic-architecture
 
 %:
 	dh $@

Bug#962950: RM: boost1.67 -- ROM; forc-removal, buggy, impossible to rebuild, should not be released

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal

boost1.67 is buggy, it cannot be rebuild against new icu abi, as that
would break dist-upgrades from stable->testing; it uses python2 which
must be removed; and it cannot be used together with current icu from
testing/unstable.

All of the reverse-dependencies are RC buggy, scheduled to be
autoremoved and/or should be made uninstallable.

Please force-remove boost1.67 from unstable, and if any
reverse-dependencies / reverse-build-dependencies are left, make them
uninstallable.

Once dogecoin/leatherman/facter are removed or resolved in testing,
boost1.67 can be removed from testing too.

kig maintianer downgraded RC bugs against kig package, and forces to
use buggy boost1.67 with unreleasable python2 bindings, which are
optional in kig.

Regards,

Dimitri.

Bug#962949: ITS: libxsmm

[Boyuan Yang]

Source: libxsmm
Version: 1.9-1
Tags: sid
X-Debbugs-CC: mba...@debian.org
Severity: important

Dear Debian libxsmm package maintainer,

After looking into the package you maintain (libxsmm, 
https://tracker.debian.org/pkg/libxsmm), I found that this package
received no updates since its initial release in 2018 and is not in
good shape (with RC bugs). As a result, I am filing an ITS (Intent to
Salvage) request against your package according to section 5.12 of
Debian's Developers' Reference [1].

Please let me know if you are still willing to maintain this package.
According to the criteria listed at [2], I am supposed to upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(July 7, 2020) to continue with package salvaging. Since this package
is also team-maintained under Debian Science Team, I will be uploading
team upload to fix release-critical bugs first and make another upload
onto DELAYED/0 after 28 days (July 14, 2020) to take over package
maintenance.


My current plan is to fix those RC bugs first. The detailed plan is:

* (Build-)depend on sse4.2-support to ensure SSE4.2 support
* Disallow packaging building on non-x86 non-64bit architectures
* Drop python2
* Package new upstream release, if feasible


If you find it necessary to pause the ITS process at any time, please
let me know *immediately* by replying this bug report.

Thank you for your previous work in Debian and looking forward to your
reply.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging


-- 
Regards,
Boyuan Yang


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

Bug#962948: ITP: vsmartcard -- A virtual smartcard toolkit

[Philippe Thierry]

Package: wnpp
Severity: wishlist
Owner: phi...@debian.org


* Package name: vsmartcard
  Version : 3.3
  Upstream Author : Frank Morgner
* URL : https://frankmorgner.github.io/vsmartcard/
* License : GPL3+
  Programming Lang: C
  Section : utils
  Description : A complete toolkit for virtual smartcards
emulation and interaction

thanks,
-- 
Philippe THIERRY


signature.asc
Description: PGP signature

Bug#962947: ITP: shovill: Assemble bacterial isolate genomes from Illumina paired-end reads

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: shovill
  Version : 1.1.0
  Upstream Author : Torsten Seemann
* URL : https://github.com/tseemann/shovill

* License : GPL-3+
  Programming Lang: Perl
  Description : Assemble bacterial isolate genomes from Illumina
paired-end reads

 Shovill is a pipeline which uses SPAdes at its core,
 but alters the steps before and after the primary
 assembly step to get similar results in less time.
 Shovill also supports other assemblers like SKESA,
 Velvet and Megahit, so you can take advantage of the
 pre- and post-processing the Shovill provides
 with those too.

I take the responsibility to maintain this package.

Bug#962946: mdadm: --name not valid in grow mode

[Marc Lehmann]

Package: mdadm
Version: 4.1-1
Severity: normal

Dear Maintainer,

The mdadm manpage lists --name under "For create, build, or grow". But
mdadm disagrees:

   # mdadm --grow /dev/md127 --name raid1
   mdadm: :option --name not valid in grow mode

-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root

--- /etc/default/mdadm
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] 
[raid10] 
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   80 1953514584 sda
   81 262144 sda1
   82 1782579200 sda2
   83  170672199 sda3
   8   16  117220824 sdb
   8   17 102400 sdb1
   8   18  117117383 sdb2
   8   32  488386584 sdc
   8   48 2930266582 sdd
   8   49   1007 sdd1
   8   50 262143 sdd2
   8   51 2930002944 sdd3
   8   64 58595475456 sde
   8   65 58595474415 sde1
 2530  838860800 dm-0
 2531  536870912 dm-1
 2532 262144 dm-2
 2533 57756610560 dm-3
 2534 57756610560 dm-4
 2535  536870912 dm-5
 2536  536854528 dm-6
 2537  838844416 dm-7
 2538   25165824 dm-8
 25391048576 dm-9
 253   10  209715200 dm-10
 253   11   25165824 dm-11
 253   12 57756610560 dm-12
 253   13  209715200 dm-13

--- LVM physical volumes:
  PV VG Fmt  Attr PSize  PFree   
  /dev/sda2  vg_cerebro lvm2 a--   1.66t <450.50g
  /dev/sde1  vg_cerebro lvm2 a--  54.57t   0 
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=8143448k,nr_inodes=2035862,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1633596k,mode=755)
/dev/mapper/cryptroot on / type btrfs 
(rw,noatime,nossd,space_cache,subvolid=257,subvol=/rootfs)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/hugetlb type cgroup 
(rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21807)
mqueue on /dev/mqueue type mqueue (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mapper/cryptroot on /cryptroot type btrfs 
(rw,noatime,nossd,space_cache,subvolid=5,subvol=/)
/dev/mapper/vg_cerebro-boot on /boot type ext4 (rw,noatime)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/cryptlocalvol on /cryptlocalvol type btrfs 
(rw,relatime,nossd,discard,space_cache,subvolid=5,subvol=/)
/dev/mapper/cryptlocalvol on /localvol type btrfs 
(rw,relatime,nossd,discard,space_cache,subvolid=257,subvol=/rootfs)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
/etc/auto.