Bug#959222: qemu-user-static: does not register binary formats

[contact]

Package: qemu-user-static
Version: 1:5.0-3
Severity: important

qemu-user-static installs files in /usr/share/binfmts/ but never calls
`update-binfmts --import` to register the binary formats.

Bug#951117: eo logs in .xsession-errors eat all disk space

[Ross Vandegrift]

On Wed, Apr 29, 2020 at 11:21:42AM +0200, Adrian Immanuel Kiess wrote:
> The log files get up to 20 Gigabyte large per day because of this happening.
> The only difference here is that I don't get this error messages logged to
> .xsession-errors but to /var/log/syslog and journalctl.
> 
> I can reproduce this bug reported here before.
> 
> Is there any workaround known for this or an bug fix on it's way?

Upstream has made some changes to make logging quieter, it'll be available in
E24.  It should be available before too long - EFL1.24 is just out, and E24 is
scheduled for soon after.

Ross

Bug#959201: Acknowledgement (jami-daemon: dring does not start due to a symbol lookup error)

[Bruno Kleinert]

Hi,

the cause seems to be an ABI change in /usr/lib/x86_64-linux-
gnu/libyaml-cpp.so.0.6.3 in package libyaml-cpp0.6 between versions
0.6.2-4 and 0.6.3-1:

While 0.6.2-4 exported
0006bd60 B _ZN4YAML6detail9node_data12empty_scalarB5cxx11E

0.6.3-1 now exports
00029af0 T _ZN4YAML6detail9node_data12empty_scalarB5cxx11Ev


I looked at the symbols which dring needs:

20190215.1.f152c98~ds1-1+b1 looks for the one exported by 0.6.2-4 of
libyaml-cpp0.6
004ee180 B _ZN4YAML6detail9node_data12empty_scalarB5cxx11E

After recompilation against libyaml-cpp0.6 0.6.3-1 it looks like this:
 U _ZN4YAML6detail9node_data12empty_scalarB5cxx11Ev

If I understand this correctly, the upload of libyaml-cpp0.6 lacks a
bump of the SO name to reflect the ABI change and this bug has to be
forwarded to libyaml-cpp0.6.

Cheers,
Bruno


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

Bug#959157: fix for CVE-2020-1749 in linux-image-4.19.0-9 breaks wireguard

[Jason A. Donenfeld]

https://git.zx2c4.com/wireguard-linux-compat/commit/?id=4602590adee92557847e61c8cd14445d35fbfa2e

Bug#956869: wireguard-dkms missing dependency on bc

[Jason A. Donenfeld]

https://salsa.debian.org/debian/wireguard-linux-compat/-/merge_requests/7

Bug#959220: adequate informs about obsolete-conffile in torbrowser-launcher

[shirish शिरीष]

Package: torbrowser-launcher
Version: 0.3.2-10
Severity: normal
User: debian...@lists.debian.org
Usertags : obsolete-conffile adequate

Dear Maintainer,
Adequate informed me of two obsolete conffiles while upgrading
torbrowser-launcher. One of them from November 2016. Please let me
know if any more info. is needed and fix it :)

$ adequate torbrowser-launcher
torbrowser-launcher: obsolete-conffile /etc/apparmor.d/local/torbrowser.Tor.tor
torbrowser-launcher: obsolete-conffile
/etc/apparmor.d/local/torbrowser.Browser.firefox

The second one is from November 2016.

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-5
ii  python3   3.8.2-3
ii  python3-gpg   1.13.1-6
ii  python3-pyqt5 5.14.2+dfsg-1+b1
ii  python3-requests  2.23.0+dfsg-2
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.2.7-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.4-1+b1

-- Configuration Files:
/etc/apparmor.d/local/torbrowser.Browser.firefox changed:
owner /{dev,run}/shm/org.mozilla.* rw,


-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#959219: davmail: minor backporting issues

[Vincent McIntyre]

Subject: davmail: minor backporting issues
Package: davmail
Version: 5.5.1.3299-2
Severity: wishlist
Tags: patch

I was trying to build this on buster and hit a couple of small issues.
Not sure how many of these qualify as 'bugs' vs 'features' but thought
I would report just in case some need addressing.

First, the dependency 'debhelper-compat (=12)' seems to lead to an
error

 % dpkg-buildpackage -us -uc
 dpkg-buildpackage: info: source package davmail
 dpkg-buildpackage: info: source version 5.5.1.3299-2
 dpkg-buildpackage: info: source distribution UNRELEASED
 dpkg-buildpackage: info: source changed by Debian Janitor 
 dpkg-buildpackage: info: host architecture amd64
  dpkg-source --before-build .
 dpkg-source: info: using patch list from debian/patches/series
 dpkg-source: info: applying 0001-no-windows-service.patch
 dpkg-source: info: applying 0006-Disable-the-check-for-a-new-release.patch
  fakeroot debian/rules clean
 dh clean --with javahelper
debian/rules override_dh_auto_clean
 make[1]: Entering directory '/var/tmp/git/clones/davmail'
 test -d lib || mkdir lib
 dh_auto_clean
 ant -propertyfile ./debian/ant.properties clean
 Buildfile: /var/tmp/git/clones/davmail/build.xml

 clean:

 BUILD SUCCESSFUL
 Total time: 0 seconds
 make[1]: Leaving directory '/var/tmp/git/clones/davmail'
jh_clean
 dpkg-query: package 'debhelper-compat' is not installed
 Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
 jh_linkjars: dpkg -L "debhelper-compat" returned exit code 1
dh_clean
  dpkg-source -b .
 dpkg-source: info: using source format '3.0 (quilt)'
 dpkg-source: info: building davmail using existing 
./davmail_5.5.1.3299.orig.tar.gz
 dpkg-source: info: using patch list from debian/patches/series
 dpkg-source: warning: ignoring deletion of directory src/data
 dpkg-source: info: building davmail in davmail_5.5.1.3299-2.debian.tar.xz
 dpkg-source: info: building davmail in davmail_5.5.1.3299-2.dsc
  debian/rules build
 dh build --with javahelper
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
jh_linkjars
 dpkg-query: package 'debhelper-compat' is not installed
 Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
 jh_linkjars: dpkg -L "debhelper-compat" returned exit code 1
 make: *** [debian/rules:5: build] Error 1
 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


I worked around this like so

diff --git a/debian/control b/debian/control
index e0972dde..efe2adc0 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Alexandre Rossi 
Uploaders: Geert Stappers 
Section: net
Priority: optional
-Build-Depends: debhelper-compat (=12),
+Build-Depends: debhelper (>= 12),
   default-jdk,
   ant,
   ant-optional,

as well as reinstating the debian/compat file

 echo 12 >debian/compat

After a bit of digging it seems this was fixed in javahelper-0.72.10
(see #933715). So probably nothing needs to be done here.


When it came to installation, I got this error

 adduser: Please enter a username matching the regular expression configured
 via the NAME_REGEX configuration variable.  Use the `--force-badname'
 option to relax this check or reconfigure NAME_REGEX.
 dpkg: error processing package davmail (--install):

Which this patch fixes

index e3185b58..7bcaad57 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -6,7 +6,7 @@ if ! pidof systemd > /dev/null; then
USER=_davmail

if ! getent passwd $USER > /dev/null; then
-adduser --quiet --system --no-create-home --home /var/lib/$USER $USER
+adduser --quiet --system --no-create-home --force-all --home 
/var/lib/$USER $USER
fi

for i in /var/log/davmail /var/lib/$USER;


Note that --force-badname is deprecated, according to dpkg-statoverride;
I get this warning if I use -force-badname

 : warning: deprecated --force option; use --force-all instead

I briefly poked around in the adduser git but I don't see where this warning
is coming from.

Kind regards
Vince


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

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

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-71
ii  init-system-helpers   1.56+nmu1
ii  jarwrapper0.72.9
ii  libcommons-codec-java 1.11-1
ii  libcommons-httpclient-java3.1-15
ii  

Bug#959218: RM: atitvout -- RoQA; Unmaintained; Inactive Upstream; Low Popcon

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: r...@gna.org

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/956472 , please remove package
atitvout from Debian archive. Its upstream has been inactive since 2003 and
the package saw no upload for 11 years. Its popcon is also low (18). The
package removal proposal received no reply from current package maintainer.

-- 
Regards,
Boyuan Yang


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

Bug#959217: RM: python-imaging-doc-handbook -- RoQA; Dead Upstream; Unmaintained; Useless;

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: s...@debian.org

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/955792 , Please remove package python-
imaging-doc-handbook from Debian archive. It is the documentation of long
disappeared python-imaging library. Since python-imaging has disappeared for
many years, it is not reasonable to keep its documentation in the archive
anymore.

-- 
Regards,
Boyuan Yang


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

Bug#959216: RM: ho22bus -- RoQA; Unmaintained; Dead Upstream;

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

As discussed in https://bugs.debian.org/956862 , please remove package ho22bus
from Debian archive. It has a dead upstream with no maintainer activity in the
last 8 years. Its popcon value is also low (18).

-- 
Regards,
Boyuan Yang


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

Bug#959158: [pkg-netfilter-team] Bug#959158: iptables: ip6tables-restore dumps core

[Arturo Borrero Gonzalez]

On Thu, Apr 30, 2020, 09:21 Matej Marusak  wrote:

> Package: iptables
> Version: 1.8.4-3
> Severity: normal
>
> Dear Maintainer,
>
> In cockpit tests [1] we are seeing ip6tables-restore dumping core often.
> It only happens on debian-testing and only in one specific test. Also
> it does not happen always, around 1/3 of runs actually hit this.
> I tried to get some commandline reproduced, but even slightly tweaking
> our tests and it stopped being reproducible. So my gut feeling is that
> this is timing related and our tests hit it just right.
>
> Please see [1] to see backtrace, journal and core.
>
> The core backtrace:
> #0  0x7f16d2993679 in nftnl_table_list_free (list=0x0) at table.c:393
> #1  0x5613a6503fa9 in flush_cache (h=0x7fff89baf4e0, c=0x7fff89baf550,
> tablename=0x0) at nft-cache.c:622
> #2  0x5613a65044f9 in flush_cache (tablename=0x0, c=,
> h=) at nft-cache.c:651
> #3  nft_release_cache (h=) at nft-cache.c:651
>
>
> As I mentioned, I am unfortunatelly not able to find commandline
> reproducer, but I am more than happy to provide any outup or try any
> command.
>
> Hope it is actionable.
> Regards,
> MM
>
>
> [1] https://github.com/cockpit-project/bots/issues/809
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.5.0-1-cloud-amd64 (SMP w/1 CPU core)
> 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 iptables depends on:
> ii  libc62.30-4
> ii  libip4tc21.8.4-3
> ii  libip6tc21.8.4-3
> ii  libmnl0  1.0.4-3
> ii  libnetfilter-conntrack3  1.0.8-1
> ii  libnfnetlink01.0.1-3+b1
> ii  libnftnl11   1.1.6-1
> ii  libxtables12 1.8.4-3
> ii  netbase  6.1
>
> Versions of packages iptables recommends:
> pn  nftables  
>
> Versions of packages iptables suggests:
> ii  firewalld  0.8.2-1
> ii  kmod   27-2
>
> -- no debconf information
>
> ___
> pkg-netfilter-team mailing list
> pkg-netfilter-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-netfilter-team



Thanks for the report.

Could you please provide the ip6tables ruleset that is causing this? i.e,
the ruleset you are trying to restore.

>
>

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> One small issue... Valgrind recommends -O0 or -O1

TIL :) Thanks, Jeff!

> You can sometimes locate a bus error at build time with -Wcast-align.
> At runtime you can usually locate them with -fsanitize=undefined.

I had previously tried UBSan and, while it turned up a number of shifting and 
strict aliasing violations, it did not find anything that I believe could be 
the cause of the mipsel bus error.

> I can't track the trail any further. The source code is missing for
> pvm_pkdouble and pvm_upkdouble. I would be very suspect of
> pvm_pkdouble and pvm_upkdouble.

Unfortunately I think the reason you can’t find their source is that this code 
is unused. It is inside a ifdef SRE_ENABLE_PVM block and this macro is not 
defined during the build. You can confirm this by deleting these lines and 
recompiling.

AFAICT the code in src/squid is a library taken wholesale from somewhere else 
and then modified (see src/squid/clustalo.README). It contains a lot of code 
that goes unused in Clustal Omega.

Is the priority goal here to simply ship a non-crashing clustalo mipsel binary 
that BioPython can depend on? If so, maybe we can just disable compiler 
optimisation (-O0) and this may avoid provoking the bus error. Of course this 
doesn’t fix the underlying problem(s), but it looks as if debugging this to its 
root cause is going to result in the Debian package carrying a lot of invasive 
dquilt patches on top of upstream. OTOH I don’t know the performance 
requirements of BioPython and maybe an unoptimised clustalo is unacceptable to 
it.

Bug#959214: hdparm.8: Some cleaning of the manual

[Bjarni Ingi Gislason]

Package: hdparm
Version: 9.58+ds-5
Severity: minor
Tags: patch

Dear Maintainer,

  The patch is in the attachment.

  Summary:

Remove space at end of lines.

Change [\]- to \(en if it is
a numeric range.

Change misused metric prefixes to binary ones, Ki,
Mi, Gi, or Ti, if indicated.

Change -- in x--y to \(em (em-dash), or, if an
option, to "\-\-".

Change a two-fonts macro to an one-font macro for a
single argument.

Change a HYPHEN-MINUS (code 0x55, 2D) to a dash
(minus) if it matches " -[:alpha:]" or \[aq]-[:alpha:] (for options).

Add a comma (or \&) after "e.g." and "i.e.", or use English words.

Begin a sentence on a new line.

Split long lines (> 80).

Use a unpaddable (no-break) space between a number and its unit.


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

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

Versions of packages hdparm depends on:
ii  libc6 2.30-4
ii  lsb-base  11.1.0

Versions of packages hdparm recommends:
pn  powermgmt-base  

hdparm suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason
--- hdparm.82020-04-18 19:08:16.0 +
+++ hdparm.8.new2020-04-29 14:38:38.0 +
@@ -6,22 +6,23 @@ hdparm \- get/set SATA/IDE device parame
 .B hdparm
 [options] [device ...]
 .SH DESCRIPTION
-.BI hdparm
+.B hdparm
 provides a command line interface to various kernel interfaces
 supported by the Linux SATA/PATA/SAS "libata" subsystem
 and the older IDE driver subsystem.  Many newer (2008 and later)
 USB drive enclosures now also support "SAT" (SCSI-ATA Command Translation)
-and therefore may also work with hdparm.  E.g. recent WD "Passport" models
+and therefore may also work with hdparm.  E.g., recent WD "Passport" models
 and recent NexStar-3 enclosures.
 Some options may work correctly only with the latest kernels.
 .SH OPTIONS
 When no options are given,
-.B -acdgkmur
+.B \-acdgkmur
 is assumed.
-For "Get/set" options, a query without the optional parameter (e.g. \-d) will 
query (get)
-the device state, and with a parameter (e.g., \-d0) will set the device state.
+For "Get/set" options, a query without the optional parameter (e.g.,
+\-d) will query (get) the device state, and with a parameter (e.g.,
+\-d0) will set the device state.
 .TP
-.I -a 
+.I \-a
 Get/set sector count for filesystem (software) read-ahead.
 This is used to improve performance in sequential reads of large files,
 by prefetching additional
@@ -29,18 +30,18 @@ blocks in anticipation of them being nee
 Many IDE drives also have a separate built-in read-ahead function,
 which augments this filesystem (software) read-ahead function.
 .TP
-.I -A
+.I \-A
 Get/set the IDE drive\'s read-lookahead feature (usually ON by default).
 Usage:
-.B -A0
+.B \-A0
 (disable) or
-.B -A1
+.B \-A1
 (enable).
 .TP
-.I -b
+.I \-b
 Get/set bus state.
 .TP
-.I -B
+.I \-B
 Get/set Advanced Power Management feature, if the drive supports it. A low 
value
 means aggressive power management and a high value means better performance.
 Possible settings range from values 1 through 127 (which permit spin-down),
@@ -50,7 +51,7 @@ and the highest I/O performance with a s
 A value of 255 tells hdparm to disable Advanced Power Management altogether
 on the drive (not all drives support disabling it, but most do).
 .TP
-.I -c
+.I \-c
 Get/set (E)IDE 32-bit I/O support.  A numeric parameter can be
 used to enable/disable 32-bit I/O support.
 Currently supported values include
@@ -69,7 +70,7 @@ Note that "32-bit" refers to data transf
 interface card only; all (E)IDE drives still have only a 16-bit connection
 over the ribbon cable from the interface card.
 .TP
-.I -C
+.I \-C
 Check the current IDE power mode status, which will always be one of
 .B unknown
 (drive does not support this command),
@@ -81,19 +82,19 @@ or
 .B sleeping
 (lowest power mode, drive is completely shut down).
 The
-.B -S, -y, -Y,
+.B \-S, \-y, \-Y,
 and
-.B -Z
+.B \-Z
 options can be used to manipulate the IDE power modes.
 .TP
-.I -d
+.I \-d
 Get/set the "using_dma" flag for this drive.  This option now works
 with most combinations of drives and PCI interfaces which support DMA
 and which are known to the kernel IDE driver.
 It is also a good idea to use the appropriate
-.B -X
+.B \-X
 option in combination with
-.B -d1
+.B \-d1
 to ensure that the drive itself is programmed for the correct DMA mode,
 although most BIOSs should do this for you at boot time.
 Using DMA nearly always gives the best performance,
@@ -102,50 +103,51 @@ But there are at least a few configurati
 for which DMA does not make much of a difference, or may even slow
 things down (on really messed up hardware!).  Your mileage may vary.
 .TP
-.I --dco-freeze
+.I 

Bug#937431: pyepl: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

> > yes, AFAIK it is dead.  Let's RM.   you ? me ? ;)

> Please go ahead :-)

FTR #959213

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#959174: php7.4-fpm: should not depend on "systemd" ideally?

[Dmitry Smirnov]

On Thursday, 30 April 2020 11:08:00 PM AEST Ondřej Surý wrote:
> No, please stop. It’s perfectly OK for a package to depend on systemd
> services.

Why such hostility?? Yes it is OK but it would be even better to avoid hard 
dependency.

Pulling systemd into application containers is less than useless (and perhaps 
even harmful) because systemd is dysfunctional in containers and it prevents 
SysV init scripts from being used.

Without systemd I could use "systemctl" replacement but hard dependency on 
systemd blocks that option...


> This is not a bug.

As far as I'm concerned gaining dependency on systemd is a regression that 
requires a lot of accommodation in containers build and init scripts.

Is is even necessary? What for?



> Also see the discussion in #952895. This
> energy would be better spent on things like #952897.

Thanks for the pointers but I still want to understand rationale for hard 
dependency on "systemd" and _ideally_ only Recommend it if possible.

Using php-fpm inside application containers without systemd is a perfectly 
valid use case.


> > Also, what is "systemd-tmpfiles"?? How is it useful? Is it an artefact
> > from the past?
> 
> This is done as a courtesy, so you can actually use equivs (+ f.e.
> opentmpfiles).

But "opentmpfiles" do not provide "systemd-tmpfiles" hence there is no way to 
avoid installing "systemd" when PHP-FPM is required.

-- 
Cheers,
 Dmitry Smirnov.

---

The further a society drifts from the truth, the more it will hate those
that speak it.
-- George Orwell


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

Bug#932081: [PATCH] sogo/sope: Unable to connect to a remote IMAP server

[Bastian Germann]

These two patches change sogo and sope to build with wolfSSL. I
successfully built the packages with the patches but did not test them yet.
>From 030619b756b03ef6a7284e1e98282baee5a02c7b Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Thu, 30 Apr 2020 20:26:32 +0200
Subject: [PATCH] Link with wolfssl

Debian bug #932081 reports GnuTLS to cause problems with IMAP connections.
Address this by linking with wolfssl instead of OpenSSL because sogo does
not have a license exception for linking with OpenSSL.

wolfssl is a replacement for OpenSSL which has an API compatible layer.
Use that with a new patch.
---
 debian/control  |  2 +-
 debian/patches/0005-Link-with-wolfssl.patch | 45 +
 debian/patches/series   |  1 +
 debian/rules|  2 +-
 4 files changed, 48 insertions(+), 2 deletions(-)
 create mode 100644 debian/patches/0005-Link-with-wolfssl.patch

diff --git a/debian/control b/debian/control
index addda7e..f30b41e 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: debhelper-compat (= 12),
  libgnustep-base-dev,
  libxml2-dev,
  libldap2-dev,
- libgnutls28-dev,
+ libwolfssl-dev,
  libpq-dev,
  default-libmysqlclient-dev,
  zlib1g-dev
diff --git a/debian/patches/0005-Link-with-wolfssl.patch b/debian/patches/0005-Link-with-wolfssl.patch
new file mode 100644
index 000..b285488
--- /dev/null
+++ b/debian/patches/0005-Link-with-wolfssl.patch
@@ -0,0 +1,45 @@
+From: Bastian Germann 
+Date: Thu, 30 Apr 2020 16:19:07 +0200
+Subject: Link with wolfssl
+
+Link with wolfssl instead of OpenSSL.
+OpenSSL linking would require a license exception for dependent GPL packages.
+---
+ configure| 2 +-
+ sope-core/NGStreams/GNUmakefile.preamble | 7 ---
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/configure b/configure
+index 9cefbe2..afdf6a3 100755
+--- a/configure
 b/configure
+@@ -509,7 +509,7 @@ checkDependencies() {
+   checkLinking "gnutls"  optional;
+   fi;
+   elif test "x$ARG_CFGSSL" = "xssl"; then
+-  checkLinking "ssl" required;
++  checkLinking "wolfssl" required;
+   elif test "x$ARG_CFGSSL" = "xgnutls"; then
+   checkLinking "gnutls"  required;
+   fi
+diff --git a/sope-core/NGStreams/GNUmakefile.preamble b/sope-core/NGStreams/GNUmakefile.preamble
+index 5f85e65..8efd3a7 100644
+--- a/sope-core/NGStreams/GNUmakefile.preamble
 b/sope-core/NGStreams/GNUmakefile.preamble
+@@ -51,12 +51,13 @@ ADDITIONAL_CPPFLAGS += -DHAVE_GNUTLS=1
+ libNGStreams_LIBRARIES_DEPEND_UPON += -lgnutls
+ NGStreams_LIBRARIES_DEPEND_UPON += -lgnutls
+ else
+-ifeq ($(HAS_LIBRARY_ssl),yes)
++ifeq ($(HAS_LIBRARY_wolfssl),yes)
+ libNGStreams_OBJC_FILES += NGActiveSSLSocket.m
+ NGStreams_OBJC_FILES += NGActiveSSLSocket.m
+ ADDITIONAL_CPPFLAGS += -DHAVE_OPENSSL=1 -DOPENSSL_NO_KRB5
+-libNGStreams_LIBRARIES_DEPEND_UPON += -lssl -lcrypto
+-NGStreams_LIBRARIES_DEPEND_UPON += -lssl -lcrypto
++ADDITIONAL_INCLUDE_DIRS += -I/usr/include/wolfssl
++libNGStreams_LIBRARIES_DEPEND_UPON += -lwolfssl
++NGStreams_LIBRARIES_DEPEND_UPON += -lwolfssl
+ endif
+ endif
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 1a5c500..1ddd70e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 0002-Do-not-build-xmlrpc-and-stxsaxdriver.patch
 0003-Unset-MAKEFLAGS-and-MFLAGS-in-configure.patch
 0004-Fix-FTBFS-on-sh4.patch
+0005-Link-with-wolfssl.patch
diff --git a/debian/rules b/debian/rules
index 3acaf35..e5c5075 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,7 +14,7 @@ override_dh_auto_clean:
 	dh_auto_clean
 
 override_dh_auto_configure:
-	./configure --disable-strip --with-gnustep --with-ssl=gnutls
+	./configure --disable-strip --with-gnustep --with-ssl=ssl
 
 override_dh_auto_build:
 	$(MAKE) all messages=yes OBJCFLAGS="$(CFLAGS)"
-- 
2.26.2

>From f8403e0152f3b61bb95aabdcaec4558d42e33667 Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Thu, 30 Apr 2020 21:20:49 +0200
Subject: [PATCH] Link with wolfssl (Closes: #932081)

Debian bug #932081 reports GnuTLS to cause problems with IMAP connections.
Address this by linking with wolfssl instead of OpenSSL because sogo does
not have a license exception for linking with OpenSSL.

wolfssl is a replacement for OpenSSL which has an API compatible layer.
Use that with a new patch.
---
 debian/README.Debian|  7 ---
 debian/control  |  2 +-
 debian/patches/0001-Link-with-wolfssl.patch | 23 +
 debian/patches/series   |  1 +
 debian/rules|  4 +++-
 5 files changed, 28 insertions(+), 9 deletions(-)
 create mode 100644 debian/patches/0001-Link-with-wolfssl.patch

diff --git a/debian/README.Debian b/debian/README.Debian
index 3c7e7717e..9c6a767d2 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -12,13 +12,6 @@ used 

Bug#959210: no automatic Xorg configuration for NVidia

[Andreas Beckmann]

On 30/04/2020 22.18, Eduard Bloch wrote:
> I don't know what the problem is. Looking at Xorg log, it seems that it

The problem happens earlier, before xorg gets started:
The nvidia module does not get loaded at boot.

> still insist on loading NOUVEAU. So I think something is broken in your
> package, the bit which was supposed to turn nouveau off.

I think something is "special" in your long grown system, some local
tweak long forgotten that now gets in the way of nvidia ...

/etc/modules-load.d/nvidia.conf should be responsible for loading the
nvidia-drm kernel module, while
/etc/modprobe.d/nvidia-blacklists-nouveau.conf prevents nouveau from
being loaded automatically.

Does manual 'modprobe -v nvidia-drm' work? If not, dmesg may contain
interesting error messages.

I saw this in your report that makes me suspicious: why is the radeon
module loaded?

> lsmod:
> Module  Size  Used by
...> radeon   1630208  0
> ttm   122880  1 radeon
> pktcdvd49152  1
> drm_kms_helper245760  1 radeon
> cec61440  1 drm_kms_helper
...


Andreas

PS: if nvidia-drm.ko is loaded, xorg should use nvidia automatically

Bug#958979: azure-cli: az ecr login crash

[Luca Boccassi]

On Mon, 27 Apr 2020 16:48:32 +0200 Dominique Dumont 
wrote:
> Package: azure-cli
> Version: 2.0.81+ds-5
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
appropriate ***
> 
>* What led up to the situation?
> 
> $ az acr login  
> The 'azure-devops' extension is not compatible with this version of
the CLI.
> You have CLI core version 2.0.81 and this extension requires a min of 2.2.0.
 
Did you install the devops extension via the package? python3-azext-devops

-- 
Kind regards,
Luca Boccassi

Bug#959208: add working instructions to disable nouveau

[Andreas Beckmann]

On 30/04/2020 22.08, Eduard Bloch wrote:
> lrwxrwxrwx 1 root root   22 Apr 30 21:51 /etc/alternatives/glx -> 
> /usr/lib/mesa-diverted

In this configuration, the nvidia driver is disabled.
But that has changed in your next bug report.


Andreas

Bug#959213: RM: pyepl -- ROM; dead upstream, not guaranteed python3 compatibility

[Yaroslav Halchenko]

Package: ftp.debian.org
Severity: normal

all said in the subject line.  Upstream CCed just in case ;-)

Bug#955064: Simply allowing any version of Sphinx in setup.py fixes the problem

[GCS]

Hi Thomas,

On Thu, Apr 30, 2020 at 11:03 PM Thomas Goirand  wrote:
> Attached debdiff fixes the issue. Can I NMU it? A bunch of the OpenStack
> packages that I maintain will otherwise be auto-removed soon...
 Thanks, but I've the same in the queue. Uploading shortly not to risk
your packages.

Cheers,
Laszlo/GCS

Bug#956728: openjdk-11: Please enablel buildwatch.sh on sh4

[John Paul Adrian Glaubitz]

Hi!

On 4/14/20 8:06 PM, John Paul Adrian Glaubitz wrote:
> I just noticed that sh4 is missing in the list of architectures for which
> the buildwatch.sh script is enabled. This explains why the builds on sh4
> sometimes time out.
Thanks for addressing this issue for openjdk-{11,13,15}. Unfortunately, 
openjdk-14
slipped through [1] and the build of openjdk-14 still times out on sh4 [2].

Could you add the missing change for openjdk-14 as well?

Thanks,
Adrian

> [1] 
> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/rules?h=openjdk-14#n1032
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=openjdk-14=sh4=14.0.1%2B7-1=1587208305=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#959144: mozjs68: Build-depends on cargo and rustc but doesn't actually use it

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

The attached patch removes the checks for the LLVM and Rust toolchains from
the build system and allows to build mozjs68 without LLVM and Rust in the
build dependencies. With the patch applied, it should be possible to drop the
patch Bug-1545437-Add-options-to-specify-Rust-target-name.patch.

Tested on both Debian and openSUSE [1].

Adrian

> [1] 
> https://build.opensuse.org/package/show/home:glaubitz:branches:mozilla:Factory/mozjs68

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Remove unused LLVM and Rust build dependencies
 Since the Javascript engine is normally part of Firefox, its build
 system has dependencies on the LLVM and Rust toolchains. This limits
 the number of architectures which mozjs68 can be built on.
 .
 It turns out, however, that neither LLVM nor Rust are used when mozjs68
 is being built and these build dependencies are therefore not necessary.
 .
 This patch removes them and allows mozjs68 to be built on any architecture.
 .
Author: John Paul Adrian Glaubitz 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959144
Forwarded: no
Last-Update: 2020-04-30

Index: mozjs68-68.6.0/js/moz.configure
===
--- mozjs68-68.6.0.orig/js/moz.configure
+++ mozjs68-68.6.0/js/moz.configure
@@ -18,11 +18,6 @@ def building_js(build_project):
 option(env='JS_STANDALONE', default=building_js,
help='Reserved for internal use')
 
-include('../build/moz.configure/rust.configure',
-when='--enable-compile-environment')
-include('../build/moz.configure/bindgen.configure',
-when='--enable-compile-environment')
-
 @depends('JS_STANDALONE')
 def js_standalone(value):
 if value:
Index: mozjs68-68.6.0/moz.configure
===
--- mozjs68-68.6.0.orig/moz.configure
+++ mozjs68-68.6.0/moz.configure
@@ -598,36 +598,6 @@ set_config('MAKENSISU_FLAGS', nsis_flags
 
 check_prog('7Z', ('7z', '7za'), allow_missing=True, when=target_is_windows)
 
-
-@depends(host_c_compiler, c_compiler, bindgen_config_paths)
-def llvm_objdump(host_c_compiler, c_compiler, bindgen_config_paths):
-clang = None
-for compiler in (host_c_compiler, c_compiler):
-if compiler and compiler.type == 'clang':
-clang = compiler.compiler
-break
-elif compiler and compiler.type == 'clang-cl':
-clang = os.path.join(os.path.dirname(compiler.compiler), 'clang')
-break
-
-if not clang and bindgen_config_paths:
-clang = bindgen_config_paths.clang_path
-llvm_objdump = 'llvm-objdump'
-if clang:
-out = check_cmd_output(clang, '--print-prog-name=llvm-objdump',
-   onerror=lambda: None)
-if out:
-llvm_objdump = out.rstrip()
-return (llvm_objdump,)
-
-
-llvm_objdump = check_prog('LLVM_OBJDUMP', llvm_objdump, what='llvm-objdump',
-  when='--enable-compile-environment',
-  paths=toolchain_search_path)
-
-add_old_configure_assignment('LLVM_OBJDUMP', llvm_objdump)
-
-
 # Please do not add configure checks from here on.
 
 # Fallthrough to autoconf-based configure

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Hi Jeffrey,

thanks a lot for this analysis.  Any chance that somebody could
turn this into a patch I could try?

Kind regards

 Andreas.

On Thu, Apr 30, 2020 at 03:40:12PM -0400, Jeffrey Walton wrote:
> On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille  wrote:
> >  ...
> > So it seems the bus error occures somehow here:
> >
> >
> > https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346
> 
> NewProgress is at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.c#L53.
> It uses a progress_t at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.h#L25.
> 
> typedef struct {
> /* where to write to */
> FILE *prFile;
> /* prefix printed before each step */
> char *pcPrefix;
> bool bPrintCR;
> char pcLastLogMsg[1024];
> Stopwatch_t *prStopwatch;
> } progress_t;
> 
> And stopwatch_t at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.h:
> 
> struct stopwatch_s {
>   time_t t0; /* Wall clock time, ANSI time()  */
> #ifdef SRE_STRICT_ANSI
>   clock_t cpu0; /* CPU time, ANSI clock()*/
> #else
>   struct tms cpu0; /* CPU/system time, POSIX times()*/
> #endif
> 
>   double elapsed; /* elapsed time, seconds */
>   double user; /* CPU time, seconds */
>   double sys; /* system time, seconds */
> };
> 
> There are your doubles that are likely the problem.
> 
> And what do we have here at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.c#L276
> ...
> 
> void
> StopwatchPVMPack(Stopwatch_t *w)
> {
>   pvm_pkdouble(&(w->elapsed), 1, 1);
>   pvm_pkdouble(&(w->user),1, 1);
>   pvm_pkdouble(&(w->sys), 1, 1);
> }
> void
> StopwatchPVMUnpack(Stopwatch_t *w)
> {
>   pvm_upkdouble(&(w->elapsed), 1, 1);
>   pvm_upkdouble(&(w->user),1, 1);
>   pvm_upkdouble(&(w->sys), 1, 1);
> }
> 
> I can't track the trail any further. The source code is missing for
> pvm_pkdouble and pvm_upkdouble. I would be very suspect of
> pvm_pkdouble and pvm_upkdouble.
> 
> Jeff
> 

-- 
http://fam-tille.de

Bug#959212: RFS: libowfat/0.30-3 [QA] -- Reimplementation of libdjb, shared library

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libowfat
   Version : 0.30-3
   Upstream Author : Felix von Leitner 
 * URL : http://www.fefe.de/libowfat/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/libowfat
   Section : libs

It builds those binary packages:

  libowfat0 - Reimplementation of libdjb, shared library
  libowfat-dev - Reimplementation of libdjb, development files
  libowfat-dietlibc-dev - Reimplementation of libdjb, dietlibc version

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libo/libowfat/libowfat_0.30-3.dsc

Changes since the last upload:

   * QA upload.
   * Fix FTBFS with GCC-10. (Closes: #957462)
   * Orphan the package. (See: #813097)
   * Update Standards-Version to 4.5.0
   * Use debhelper-compat.
 - Update compat level to 13.
   * Mark Vcs to salsa.
   * Add symbols file.
   * Remove whitespace from control and changelog.
   * Remove duplicate section.


-- 
Regards
Sudip

Bug#959211: utimensat system call no working properly on SMB shares

[Alberto Sentieri]

Package: samba
Version: 4.5.16

The system call utimensat is failing when the protocol version is 2.0 or 
upper is selected.


The package samba version 2:4.5.16+dfsg-1+deb9u2 is the last one 
available for Debian stretch. Its interaction with Debian buster using 
cifs-utils version 2:6.8-2 is causing the particular system call to 
fail. In my case, the samba server is running under debian stretch, 
while the workstation is running debian buster. A simple program like 
 of  from a ext4 file system to the SMB file system 
will store the incorrect time stamp on the samba server.


/bin/cp program executes some code like this, before finishing:

write (fd, buffer, length);
utimensat (fd, NULL, timestamps, 0);
close (fd);

I create a C program which will execute this sequence of statements. 
Curiously the time stamp is correct for a small amount of time, and then 
it switches to the current time. The program, which I called x2, will be 
run by the following batch script:


#!/bin/bash
NAME='/samba_share/test2.txt'
rm -f "${NAME}"
ls -ls "${NAME}"
./x2 "${NAME}"
ls -ls "${NAME}"
sleep 1
ls -ls "${NAME}"

The result of running the script is:

$ ./script.sh
ls: cannot access '/samba_share/test2.txt': No such file or directory
0 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /samba_share/test2.txt
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 16:33 /samba_share/test2.txt

As one can see, the file time stamp is correct just after x2 finishes, 
and it become incorrect one second later. If, while mounting the share 
with mount.cifs, I specify -o vers=1.0, then the problem does not 
happen, I mean, the time stamp will be the same (Feb 5 2017) just after 
x2 ends and 1 second after its end.


The program x2 uses the same sequence of commands that /bin/cp -p or 
/bin/mv uses. Here is its source code:


#include 
#include 
#include 
#include 
#include 
#include 
#include 

static char *data = "test data\n";
static struct timespec timestamps [2] = {
    { 1588174263, 908624390 },
    { 1486350336, 481422339 }
};

int main (int argc, char **argv)
{
    int fd;

    if (argc > 1) {
        fd = openat (AT_FDCWD, argv [1], O_WRONLY|O_CREAT, 0666);
        if (fd >= 0) {
            write (fd, data, strlen (data));
            /* do not use glibc utimensat directly, it does not allow 
NULL as a second argument */

            syscall (SYS_utimensat, fd, NULL, timestamps, 0);
            close (fd);
            return 0;
        }
    }
    printf ("something went wrong\n");
    return 0;
}

it can be easily compiled by .

I used tcpdump to capture the traffic between the workstation running x2 
and the samba server. I noticed that gnome3 file manager works correctly 
even when a protocol referred as SMB2 by wireshark is used. I mean that 
a file copied from ext4 to smb by file manager has the correct time 
stamp under protocol version 2.0 and above, which does not happen with 
the x2 program displayed above.


Based on the network traffic, I have the impression that the gnome3 file 
manager uses a sequence like the one below:

write
close
open
utimensat
close

So, after the last write the file is closed and opened again before 
executing utimensat.

Bug#955064: Simply allowing any version of Sphinx in setup.py fixes the problem

[Thomas Goirand]

Hi Laszlo,

Attached debdiff fixes the issue. Can I NMU it? A bunch of the OpenStack
packages that I maintain will otherwise be auto-removed soon...

Cheers,

Thomas Goirand (zigo)
diff -Nru grpc-1.26.0/debian/changelog grpc-1.26.0/debian/changelog
--- grpc-1.26.0/debian/changelog2020-03-21 18:23:30.0 +0100
+++ grpc-1.26.0/debian/changelog2020-04-30 22:49:57.0 +0200
@@ -1,3 +1,10 @@
+grpc (1.26.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild.
+
+ -- Thomas Goirand   Thu, 30 Apr 2020 22:49:57 +0200
+
 grpc (1.26.0-2) unstable; urgency=medium
 
   * Build with protobuf version 3.11.4 or later (closes: #946194).
diff -Nru grpc-1.26.0/debian/patches/allow-any-sphinx.patch 
grpc-1.26.0/debian/patches/allow-any-sphinx.patch
--- grpc-1.26.0/debian/patches/allow-any-sphinx.patch   1970-01-01 
01:00:00.0 +0100
+++ grpc-1.26.0/debian/patches/allow-any-sphinx.patch   2020-04-30 
22:49:57.0 +0200
@@ -0,0 +1,16 @@
+Description: Allow any version of sphinx
+Author: Thomas Goirand 
+Forwarded: no
+Last-Update: 2020-04-30
+
+--- grpc-1.26.0.orig/setup.py
 grpc-1.26.0/setup.py
+@@ -336,7 +336,7 @@ INSTALL_REQUIRES = (
+ )
+ 
+ SETUP_REQUIRES = INSTALL_REQUIRES + (
+-'Sphinx~=1.8.1',
++'Sphinx',
+ 'six>=1.10',
+   ) if ENABLE_DOCUMENTATION_BUILD else ()
+ 
diff -Nru grpc-1.26.0/debian/patches/series grpc-1.26.0/debian/patches/series
--- grpc-1.26.0/debian/patches/series   2019-12-20 15:34:21.0 +0100
+++ grpc-1.26.0/debian/patches/series   2020-04-30 22:49:57.0 +0200
@@ -9,3 +9,4 @@
 fix-protoc-path.patch
 add_grpc_libdir.patch
 unbreak_foreach.patch
+allow-any-sphinx.patch

Bug#959190: gssproxy: Log flooded by gssproxy

[Vincent Danjean]

  Hi,

Le 30/04/2020 à 20:21, Robbie Harwood a écrit :
> Hi Vincent,
> 
> Please see `man gssproxy.conf` for logging options.  You probably want to set 
> debug_level to 0 to disable logging.

  I did not do it because one can read in the manpage:
   debug (boolean)
   Enable debugging to syslog.

   Default: debug = false

   debug_level (integer)
   Detail level at which to log debugging messages. 0 corresponds to no 
logging, while 1 turns on basic debug logging. Level 2 increases verbosity, 
including more detailed credential verification.

   At level 3 and above, KRB5_TRACE output is logged. If KRB5_TRACE was 
already set in the execution environment, trace output is sent to its value 
instead.

   Default: 1 if debug is true, otherwise 0

As neither debug nor debug_level is set in my config, I was
expecting that no debug log was generated, so messages were
error reportings that cannot be prevented.

And indeed, I tried to put "debug_level = 0" in both
gssproxy.conf and 99-nfs-client.conf (while reverting my
ccache:FILE:.. change)

=> no effect (i.e. logs are flooded again)

  Regards,
Vincent

> Thanks,
> --Robbie

Bug#937431: pyepl: Python2 removal in sid/bullseye

[Moritz Muehlenhoff]

On Thu, Apr 30, 2020 at 03:06:57PM -0400, Yaroslav Halchenko wrote:
> 
> On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:
> 
> > On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote:
> > > Package: src:pyepl
> > > Version: 1.1.0+git12-g365f8e3-3
> > > Severity: normal
> > > Tags: sid bullseye
> > > User: debian-pyt...@lists.debian.org
> > > Usertags: py2removal
> 
> > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > Python2 from the distribution, as discussed in
> > > https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> > > Your package either build-depends, depends on Python2, or uses Python2
> > > in the autopkg tests.  Please stop using Python2, and fix this issue
> > > by one of the following actions.
> 
> > pyepl is dead upstream, let's remove it?
> 
> yes, AFAIK it is dead.  Let's RM.   you ? me ? ;)

Please go ahead :-)

Cheers,
Moritz

Bug#959190: Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[Vincent Danjean]

  Hi,

Le 30/04/2020 à 20:23, Robbie Harwood a écrit :
> Hi Vincent,
> 
> I disagree about "usually", but I have a larger question, which is: why are 
> you using gssproxy if you want the credentials in an easily accessible 
> location?  The entire point of the daemon is privilege separation.

  I'm using gssproxy because I've some (cron jobs) system users
that must access to the NFS. For them, I add a keytab using
client_keytab:/var/lib/gssproxy/clients/%U.keytab
  If I understand correctly, classical (normal, loggued) users
already have their credential and, in this case, gssproxy
should not be used?

  In fact, this is linked to my other bug report
(#959190 that I put in CC) where you just point me to the
fact that I can totally disable the logs.

  My use case is a machine with a kerberized NFS.
Logged users (with kerberos credentials) generates lots of
logs (as told in #959190) unless gssproxy is pointed to
their file credential.
  When gssproxy is complaining, these users still can access
to the NFS (so I suspect that after gssproxy failure, classical
credential retrieval is used).

  With your explanation, I understand now that gssproxy
config should not be changed and was correct (so #959186
can be closed). But it means that, under normal and default
config, gssproxy can generate lots of logs.
  The admin can totally disable the logs as you told me,
but it means that he will not have any information in case
of problems. I will do this for now as I cannot handle
several GB of logs per days when some application are
running, but I would suggest that a way for gssproxy to
limits its logs (rate limit and/or log only the first messages
of similar messages or ...) would be way better.

  Many thanks for your information
  Regards
Vincent

> Thanks,
> --Robbie
> 
> On April 30, 2020 10:48:29 AM EDT, Vincent Danjean  
> wrote:
>> Package: gssproxy
>> Version: 0.8.0-1.1
>> Severity: normal
>>
>>  Hi,
>>
>>  The default configuration file looks for kerberos credentials
>> in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
>> are in ccache:FILE:/tmp/krb5cc_%U
>>  Is this configuration intended? Why? I had to change it, I found
>> the solution on several internet forum where it said that this is
>> an error in the default configuration. I'm not sure if this is the
>> case (an error) or if the default configuration file targets another
>> usage.
>>
>>  Regards
>>Vincent
>>
>> -- System Information:
>> Debian Release: 10.3
>>  APT prefers stable
>> APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>> 'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>> TAINT_UNSIGNED_MODULE
>> 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 /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages gssproxy depends on:
>> ii  libc6 2.28-10
>> ii  libgssapi-krb5-2  1.17-3
>> ii  libgssrpc41.17-3
>> ii  libini-config50.6.1-2
>> ii  libk5crypto3  1.17-3
>> ii  libkrb5-3 1.17-3
>> ii  libpopt0  1.16-12
>> ii  libref-array1 0.6.1-2
>> ii  libselinux1   2.8-1+b1
>> ii  libverto1 0.3.0-2
>>
>> gssproxy recommends no packages.
>>
>> gssproxy suggests no packages.
>>
>> -- Configuration Files:
>> /etc/gssproxy/99-nfs-client.conf changed:
>> [service/nfs-client]
>>  mechs = krb5
>>  cred_store = keytab:/etc/krb5.keytab
>>  cred_store = ccache:FILE:/tmp/krb5cc_%U
>>  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>>  cred_usage = initiate
>>  allow_any_uid = yes
>>  trusted = yes
>>  euid = 0
>>
>>
>> -- no debconf information


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#959209: ITP: manila-tempest-plugin -- OpenStack Integration Test Suite - Manila plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: manila-tempest-plugin
  Version : 1.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/manila-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Manila plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Manila plugin.

Bug#959206: sshd: kex_exchange_identification failures are logged as error

[Christian Göttsche]

Package: openssh-server
Version: 1:8.2p1-4

I am running sshd on a custom port and a few bots/spammers are trying
to connect.
This lead to messages like:

sshd[197482]: error: kex_exchange_identification: Connection closed by
remote host
sshd[205072]: error: kex_exchange_identification: banner line contains
invalid characters
sshd[1012348]: error: kex_exchange_identification: client sent invalid
protocol identifier "GET / HTTP/1.1"

Since these events are non-critical and remotely trigger-able, can the
severity of these log entries be lowered from error to warning?

Best regards
 Christian Göttsche

Bug#959207: ITP: kquickcharts -- A QtQuick plugin providing high-performance charts.

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: Sandro Knauß 

* Package name: kquickcharts
  Version : 5.69.0
  Upstream Author : KDE
* URL : https://invent.kde.org/kde/kquickcharts
* License : LGPL-2.1+3+KDEeV
  Programming Lang: C++, QML
  Description : A QtQuick plugin providing high-performance charts.

 A module to Render gpu-accelerated charts. It supports three different
 chart types: pie, line and bar, which can be fed from multiple types of
 data sources. There is also support for axis labels, an axis grid and a
 legend.  Additionally, there is a submodule that contains some
 convenience items.

 The pie and line charts are rendered using a technique called signed
 distance fields, which allows efficient GPU-accelerated rendering of 2D
 shapes without loss of quality.


kquickcharts was added to KDE Frameworks in December and is intended to
replace kqtquickcharts on the long run.

It is intended to package within the "Debian/Kubuntu Qt/KDE Maintainers"
team.

Bug#943664: Solution for PowerMac11,2

[Ralf P.]

Hi.

On my Apple G5 (PowerMac11,2) hardware acceleration was disabled
because of a failed "ring 0 test", resulting in the error
"undefined symbol: exaGetPixmapDriverPrivate"

According to a note I found on the net "the PCIe-x16 slot is directly
connected to the system controller and the other PCIe-x slots are
routed through some kind of hub."

The "ring 0 test" failure was resolved after moving the graphics card
from the x16 slot to the x8 slot. Hardware acceleration now works.


Note: For me this triggers another bug: If I run my AMD Radeon
hardware accelerated the X11 internal font server shows garbled
(sometimes looking like reversed) characters.
Client side font rendering (Firefox, LibreOffice, Emacs, sakura)
works.
My Nvidia card is affected too. Until now I have no soultion for this.

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Jeffrey Walton]

On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille  wrote:
>  ...
> So it seems the bus error occures somehow here:
>
>
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346

NewProgress is at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.c#L53.
It uses a progress_t at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.h#L25.

typedef struct {
/* where to write to */
FILE *prFile;
/* prefix printed before each step */
char *pcPrefix;
bool bPrintCR;
char pcLastLogMsg[1024];
Stopwatch_t *prStopwatch;
} progress_t;

And stopwatch_t at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.h:

struct stopwatch_s {
  time_t t0; /* Wall clock time, ANSI time()  */
#ifdef SRE_STRICT_ANSI
  clock_t cpu0; /* CPU time, ANSI clock()*/
#else
  struct tms cpu0; /* CPU/system time, POSIX times()*/
#endif

  double elapsed; /* elapsed time, seconds */
  double user; /* CPU time, seconds */
  double sys; /* system time, seconds */
};

There are your doubles that are likely the problem.

And what do we have here at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.c#L276
...

void
StopwatchPVMPack(Stopwatch_t *w)
{
  pvm_pkdouble(&(w->elapsed), 1, 1);
  pvm_pkdouble(&(w->user),1, 1);
  pvm_pkdouble(&(w->sys), 1, 1);
}
void
StopwatchPVMUnpack(Stopwatch_t *w)
{
  pvm_upkdouble(&(w->elapsed), 1, 1);
  pvm_upkdouble(&(w->user),1, 1);
  pvm_upkdouble(&(w->sys), 1, 1);
}

I can't track the trail any further. The source code is missing for
pvm_pkdouble and pvm_upkdouble. I would be very suspect of
pvm_pkdouble and pvm_upkdouble.

Jeff

Bug#932197: Bug#937144: Request to join the Neurodebian group

[Yaroslav Halchenko]

On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:

> On Wed, Feb 26, 2020 at 04:15:03PM +0100, Andreas Tille wrote:
> > On Wed, Feb 26, 2020 at 08:37:30AM -0500, Yaroslav Halchenko wrote:
> > > thank you Andreas!!!

> > > re etelemetry:  I made it optional for previous version of the
> > > package:

> > >   $> quilt series
> > >   deb-no-demand-on-etelemetry

> > >   $> git describe
> > >   debian/0.6.0-1

> > Thanks for the hint.  While this could possibly speet up the upload of
> > nipype I for myself are fine with waiting for the new Build-Depends.
> > Anybody who wants to speed up things is kindly invited to add this patch
> > and upload.

> What's the status here? python-etelemetry is now in the archive and testing.

my problem with any version of nipype ended up stalling tests with
python3.8. See e.g. https://github.com/nipy/nipype/pull/3154 for
interactions with upstream and now a dedicated issue 
https://github.com/nipy/nipype/issues/3209

I guess what we could do is to upload currently present in debian
version with python 3.8 testing disabled and hope for the best ;)  I
will exercise (update packaging and see if builds/test otherwise ok with
3.7 etc) that now

Then we wait for python3-rdflib 5.0 being uploaded (just submitted a
wishlist bug report to have it updated), and upload fresh snapshot (or
release if by then done) of nipype.

any suggestions to the plan? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#959205: fresh (13 days old) 5.0.0 release is out, will be needed for nipype

[Yaroslav Halchenko]

Package: python3-rdflib
Version: 4.2.2-5
Severity: wishlist


https://github.com/RDFLib/rdflib/releases

and nipype introduced 5.0.0 as minimal dependency:
https://github.com/nipy/nipype/pull/3154/files#diff-652049a763b24d096b8211ef8d633748R113

it would be great if 5.0.0 was uploaded to Debian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable-updates'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-rdflib depends on:
ii  python33.8.2-3
ii  python3-isodate0.6.0-2
ii  python3-pyparsing  2.4.6-2

Versions of packages python3-rdflib recommends:
ii  python3-html5lib   1.0.1-3
ii  python3-sparqlwrapper  1.8.5-1

Versions of packages python3-rdflib suggests:
pn  python-rdflib-doc  

-- no debconf information

Bug#937431: pyepl: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:

> On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote:
> > Package: src:pyepl
> > Version: 1.1.0+git12-g365f8e3-3
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal

> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html

> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.

> pyepl is dead upstream, let's remove it?

yes, AFAIK it is dead.  Let's RM.   you ? me ? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#959191: release-notes: mention configuration file split in logrotate

[Justin B Rye]

Christian Göttsche wrote:
> Package: release-notes
> 
> With version 3.14.0 [1] logrotate split the configuration for btmp and
> wtmp into separate configuration files.
> There are bug reports regarding this issue: #945932, #928516, #922045.

To me this seems more like something that should go in the logrotate
NEWS.Debian file, but maybe that's too hard to get into Stable, so
I'll just proofread the suggested addition:

> Over at #946779 Julien suggested adding a section (5.3.10 ?).

It would also need a title; maybe something like

   5.3.10  Split in configuration for logrotate
 
> Maybe the section can be like the following:
> 
>The shipped configurations for "/var/log/btmp" and "/var/log/wtmp" have
>been split from the main configuration file (/etc/logrotate.conf) into
>separate standalone files (/etc/logrotate.d/btmp respectively
  ^^^
>/etc/logrotate.d/wtmp).

"Respectively" isn't a conjunction, and there's no need here for
anything more complicated than "and".

> 
>If you had modified /etc/logrotate.conf in this regard, make sure
^^^
s/had/have/

>to re-adjust the two new files to your needs and drop any references to
>(b|w)tmp from the main file, to avoid logrotate skip rotation due to a
 
>duplicate definition.

Quick fix: s/skip/skipping/.  Probably better:

  since duplicate definitions can cause errors.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#959075: ifupdown: Bonding is not working with ifenslave 2.10 wich removes ifenslave command

[Gilles Mocellin]

Le mercredi 29 avril 2020, 09:48:10 CEST Guus Sliepen a écrit :
> On Wed, Apr 29, 2020 at 09:21:19AM +0200, Gilles Mocellin wrote:
> > Package: ifupdown
> > Version: 0.8.35+b1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > The ifenslave package does not provides ifenslave command anymore
> > (starting from 2.10), bonding interface needs to be done with iproute2 :
> > # ip link set enp6s0 master bond0
> > 
> > I think ifupdown uses ifenslave command, because my system does not
> > bring my bond anymore.
> 
> Hello Gilles,

Hello Guus,

> The ifupdown package itself doesn't provide support for bonding at all,
> it is the ifenslave package itself which provides that support. Nothing
> should be calling the ifenslave binary anymore.

So we should reassign this bug to ifenslave package.
And sure, this package  has been upgraded, not ifupdown.

[;..]
> Hm, that looks fine. Can you try to run:
> 
> sudo ifdown -v bond0
> sudo ifup -v bond0
> 
> And send me a copy of the output? Hopefully that will help narrow down
> the issue. Another thing to try is to remove "bond-slaves enp6s0 enp7s0"
> from the bond0 stanza, and instead add "bond-master bond0" to the enp6s0
> and enp7s0 stanzas.

Here is  the ifup -v complete log to see all the dependances.
There's  an infinite loop rtying to setup the master bond.

/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ meta = meta ]
+ exit 0
run-parts: executing /etc/network/if-pre-up.d/vde2
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant

ifup: configuring interface lo=lo (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet = meta ]
+ IF_BOND_SLAVES=
+ [ -n  ]
+ [ -n  -o -n  ]
+ exit 0
run-parts: executing /etc/network/if-pre-up.d/vde2
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/sbin/ip link set dev lo up
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ifenslave
+ [ inet = meta ]
+ [  ]
run-parts: executing /etc/network/if-up.d/postfix
run-parts: executing /etc/network/if-up.d/wpasupplicant

ifup: configuring interface enp6s0=enp6s0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet = meta ]
+ IF_BOND_SLAVES=
+ [ -n  ]
+ [ -n  -o -n  ]
+ exit 0
run-parts: executing /etc/network/if-pre-up.d/vde2
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant


/sbin/ip link set dev enp6s0 up 2>/dev/null || true
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ifenslave
+ [ inet = meta ]
+ [  ]
run-parts: executing /etc/network/if-up.d/postfix
run-parts: executing /etc/network/if-up.d/wpasupplicant

ifup: configuring interface enp7s0=enp7s0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet = meta ]
+ IF_BOND_SLAVES=
+ [ -n  ]
+ [ -n  -o -n  ]
+ exit 0
run-parts: executing /etc/network/if-pre-up.d/vde2
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant


/sbin/ip link set dev enp7s0 up 2>/dev/null || true
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ifenslave
+ [ inet = meta ]
+ [  ]
run-parts: executing /etc/network/if-up.d/postfix
run-parts: executing /etc/network/if-up.d/wpasupplicant

ifup: configuring interface bond0=bond0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet = meta ]
+ IF_BOND_SLAVES=enp6s0 enp7s0
+ [ -n  ]
+ [ -n enp6s0 enp7s0 -o -n balance-alb ]
+ setup_master bond0
+ add_master
+ [ -f /sys/class/net/bond0/bonding/slaves ]
+ return
+ early_setup_master
+ sysfs fail_over_mac 
+ [ -n  ]
+ return 0
+ setup_master
+ add_master
+ [ -f /sys/class/net/bond0/bonding/slaves ]
+ return
+ early_setup_master
+ sysfs fail_over_mac 
+ [ -n  ]
+ return 0
...
...
+ setup_master
+ add_master
+ [ -f 

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Jeffrey Walton]

On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille  wrote:
>
> Control: tags -1 help
>
> as it can be seen on the recent build log of clustalo on mips[1] the
> build fails with
>
> # Run additional test from python-biopython package to verify that
> # this will work as well
> src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error

You can sometimes locate a bus error at build time with -Wcast-align.
At runtime you can usually locate them with -fsanitize=undefined.

On x86 -Wcast-align usually triggers when casting to/from floats and
doubles. I don't know what triggers on MIPS, bit it may include
integers. You should look for all calls that perform casts to/from
void* and uint8_t* with a dereference. I.e.,

uint8_t y[8] = ...;
double x = *(double*)y;

If MIPS is sensitive to alignment (beyond x86 slop), then something
like this will get you into trouble, too:

uint8_t y[8] = ...;
unsigned long x = *(unsigned long*)y;

I don't know about MIPS, but... I've experienced the problem with
long's on SPARCv8. SPARCv8 needs 8-byte alignments because they have a
specialized 64-bit move instruction. Or SPARCv8 needs an extra
compile/link switch that disables the 64-bit move. The option is
-xmemalign, which tells the toolchain what alignments can be assumed.

Jeff

Bug#959204: ITP: rootlesskit -- Linux-native "fake root" for rootless containers

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: rootlesskit
  Version : 0.9.4-1
  Upstream Author : Akihiro Suda
* URL : https://github.com/rootless-containers/rootlesskit
* License : Apache-2.0
  Programming Lang: Go
  Description : Linux-native "fake root" for rootless containers

 The purpose of RootlessKit is to run Docker and
 Kubernetes as an unprivileged user (known as "Rootless mode"),
 so as to protect the real root on the host from potential
 container-breakout attacks.
 .
 RootlessKit creates user_namespaces(7) and mount_namespaces(7),
 and executes newuidmap(1)/newgidmap(1) along with subuid(5) and
 subgid(5).

 Package will be prepared at
 http://salsa.debian.org/go-team/packages/rootlesskit

Bug#958554: beautifulsoup4: autopkgtest failure.

[Stefano Rivera]

Control: forwarded -1 https://bugs.launchpad.net/beautifulsoup/+bug/1872279

> From diffing test logs I belive this was most-likely caused by the
> update to python-soupsieve

Yep.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#955711: schroedinger-maeparser tansition is complete

[Andrius Merkys]

Hello,

schroedinger-maeparser transition seems to be complete. All related
packages had been rebuilt, and have already migrated to testing. I suppose
transition bug can now be closed.

Best,
Andrius

Bug#959110: we need to run more scripts in Makefile than just gulp build

[Pirate Praveen]

at least packages/babel-plugin-transform-runtime/scripts/build-dist.js 
should be run during build to fix this.


I think it is safer to run make build.

Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[Robbie Harwood]

Hi Vincent,

I disagree about "usually", but I have a larger question, which is: why are you 
using gssproxy if you want the credentials in an easily accessible location?  
The entire point of the daemon is privilege separation.

Thanks,
--Robbie

On April 30, 2020 10:48:29 AM EDT, Vincent Danjean  wrote:
>Package: gssproxy
>Version: 0.8.0-1.1
>Severity: normal
>
>  Hi,
>
>  The default configuration file looks for kerberos credentials
>in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
>are in ccache:FILE:/tmp/krb5cc_%U
>  Is this configuration intended? Why? I had to change it, I found
>the solution on several internet forum where it said that this is
>an error in the default configuration. I'm not sure if this is the
>case (an error) or if the default configuration file targets another
>usage.
>
>  Regards
>Vincent
>
>-- System Information:
>Debian Release: 10.3
>  APT prefers stable
>APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>TAINT_UNSIGNED_MODULE
>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 /bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages gssproxy depends on:
>ii  libc6 2.28-10
>ii  libgssapi-krb5-2  1.17-3
>ii  libgssrpc41.17-3
>ii  libini-config50.6.1-2
>ii  libk5crypto3  1.17-3
>ii  libkrb5-3 1.17-3
>ii  libpopt0  1.16-12
>ii  libref-array1 0.6.1-2
>ii  libselinux1   2.8-1+b1
>ii  libverto1 0.3.0-2
>
>gssproxy recommends no packages.
>
>gssproxy suggests no packages.
>
>-- Configuration Files:
>/etc/gssproxy/99-nfs-client.conf changed:
>[service/nfs-client]
>  mechs = krb5
>  cred_store = keytab:/etc/krb5.keytab
>  cred_store = ccache:FILE:/tmp/krb5cc_%U
>  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>  cred_usage = initiate
>  allow_any_uid = yes
>  trusted = yes
>  euid = 0
>
>
>-- no debconf information

Bug#959190: gssproxy: Log flooded by gssproxy

[Robbie Harwood]

Hi Vincent,

Please see `man gssproxy.conf` for logging options.  You probably want to set 
debug_level to 0 to disable logging.

Thanks,
--Robbie

On April 30, 2020 11:03:29 AM EDT, Vincent Danjean  wrote:
>Package: gssproxy
>Version: 0.8.0-1.1
>Severity: important
>
>  Hi,
>
>  On a system with kerberos (AD with sssd) and NFS mount,
>some applications (long bioinfo applications with data on
>the NFS partition) generate lots of logs that fill the
>root (or /var/log/) partition.
>  To have an idea, in less than 24h, more that 5GB of
>logs have been generated. There are all similar to:
>
>Apr 30 14:31:24 ge95142-vm1 gssproxy[6880]: gssproxy[6888]: (OID: { 1 2
>840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide
>more information, No credentials cache found
>[and 300 similar lines for the same *second*]
>
>And I find them tree times: they are logged into
>/var/log/syslog, /var/log/daemon.log and /var/log/auth.log.
>
>
>  You should really provide a way to either limit the
>rate of the logs and/or provide an way to avoid logs
>(I do not find any).
>
>  Regards,
>Vincent
>
>
>-- System Information:
>Debian Release: 10.3
>  APT prefers stable
>APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>TAINT_UNSIGNED_MODULE
>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 /bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages gssproxy depends on:
>ii  libc6 2.28-10
>ii  libgssapi-krb5-2  1.17-3
>ii  libgssrpc41.17-3
>ii  libini-config50.6.1-2
>ii  libk5crypto3  1.17-3
>ii  libkrb5-3 1.17-3
>ii  libpopt0  1.16-12
>ii  libref-array1 0.6.1-2
>ii  libselinux1   2.8-1+b1
>ii  libverto1 0.3.0-2
>
>gssproxy recommends no packages.
>
>gssproxy suggests no packages.
>
>-- Configuration Files:
>/etc/gssproxy/99-nfs-client.conf changed:
>[service/nfs-client]
>  mechs = krb5
>  cred_store = keytab:/etc/krb5.keytab
>  cred_store = ccache:FILE:/tmp/krb5cc_%U
>  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>  cred_usage = initiate
>  allow_any_uid = yes
>  trusted = yes
>  euid = 0
>
>
>-- no debconf information

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Jeffrey Walton]

On Thu, Apr 30, 2020 at 10:33 AM Matthew Fernandez
 wrote:
>
> > On Apr 30, 2020, at 00:31, Andreas Tille  wrote:
> >
> > On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote:
> >
> >> The other option I suggested was Valgrind, but if you can’t run apt-file 
> >> you probably can’t install Valgrind either.
> >
> > Well, I guess apt-get is permitted for sudo but not apt-file.  So I can
> > probably install valgrind inside the chroot environment.  I've never
> > worked with valgrind.  What am I supposed to do?
>
> Valgrind, in its default mode, checks for a variety of memory issues 
> (use-after-free, write out-of bounds, …). You don’t need any special 
> configure/build options, but you probably want to enable debug symbols 
> (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re 
> running with Valgrind: `valgrind ./src/clustalo -i 
> debian/tests/biopython_testdata/f002 …`.

One small issue... Valgrind recommends -O0 or -O1:


Compile your program with -g to include debugging information so that
Memcheck's error messages include exact line numbers. Using -O0 is
also a good idea, if you can tolerate the slowdown. With -O1 line
numbers in error messages can be inaccurate, although generally
speaking running Memcheck on code compiled at -O1 works fairly well,
and the speed improvement compared to running -O0 is quite
significant. Use of -O2 and above is not recommended as Memcheck
occasionally reports uninitialised-value errors which don't really
exist.


Also see the Valgrind Quick Start Guide, Section 2. Preparing Your
Programs, at http://valgrind.org/docs/manual/QuickStart.html.

Jeff

Bug#959182: Build failures due to missing linux/time_types.h

[Max Kellermann]

On 2020/04/30 19:58, Guillem Jover  wrote:
> I assume then that your linux-libc-dev is older than 5.1, which is
> when that header got introduced? Are you building in testing/sid?

True, my linux-libc-dev is 4.19.98-1.

If the package requires at least version 5.1, then it should declare
exactly that in the "Depends" line.

Bug#959203: RM: ruby2.5

[Lucas Kanashiro]

Package: ftp.debian.org
Severity: normal
Usertags: rm
X-Debbugs-CC: debian-r...@lists.debian.org

Hi,

As you can see in #953881 the ruby 2.7 transition is done and there is no 
package in the archive depending on ruby2.5 according to dak. Could you please 
remove src:ruby2.5 and its binaries from unstable?

Thanks in advance!

-- 
Lucas Kanashiro

Bug#959202: src:php-defaults: fails to migrate to testing for too long

[Paul Gevers]

Source: php-defaults
Version: 73
Severity: serious
Control: close -1 75
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 958423 958424

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:php-defaults
has been trying to migrate since 2020-02-21 [2]. Hence, I am filing this
bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=php-defaults






signature.asc
Description: OpenPGP digital signature

Bug#959201: jami-daemon: dring does not start due to a symbol lookup error

[Bruno Kleinert]

Package: jami-daemon
Version: 20190215.1.f152c98~ds1-1+b1
Severity: grave
Justification: renders package unusable

Hi,

Jami fails to connect to its daemon dring because it cannot start due to a
symbol lookup error:

/usr/lib/ring/dring: symbol lookup error: /usr/lib/ring/dring: undefined
symbol: _ZN4YAML6detail9node_data12empty_scalarB5cxx11E

Cheers,
Bruno



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

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

Versions of packages jami-daemon depends on:
ii  libargon2-10~20171227-0.2
ii  libasound2 1.2.2-2.1
ii  libavcodec58   7:4.2.2-1+b1
ii  libavdevice58  7:4.2.2-1+b1
ii  libavfilter7   7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil567:4.2.2-1+b1
ii  libc6  2.30-4
ii  libdbus-c++-1-0v5  0.9.0-8.1
ii  libgcc-s1 [libgcc1]10-20200418-1
ii  libgcc11:10-20200418-1
ii  libgnutls303.6.13-2
ii  libixml10  1:1.8.4-2
ii  libjsoncpp11.7.4-3.1
ii  libnatpmp1 20150609-7+b2
ii  libnettle7 3.5.1+really3.5.1-2
ii  libpcre3   2:8.39-12+b1
ii  libpulse0  13.0-5
ii  librestbed0 [librestbed0]  4.0~dfsg1-5
ii  libsecp256k1-0 0.1~20170810-2
ii  libstdc++6 10-20200418-1
ii  libswresample3 7:4.2.2-1+b1
ii  libswscale57:4.2.2-1+b1
ii  libudev1   245.5-2
ii  libupnp13  1:1.8.4-2
ii  libuuid1   2.34-0.1
ii  libyaml-cpp0.6 0.6.3-1
ii  zlib1g 1:1.2.11.dfsg-2

jami-daemon recommends no packages.

jami-daemon suggests no packages.

-- no debconf information

Bug#932197: Bug#937144: Request to join the Neurodebian group

[Moritz Mühlenhoff]

On Wed, Feb 26, 2020 at 04:15:03PM +0100, Andreas Tille wrote:
> On Wed, Feb 26, 2020 at 08:37:30AM -0500, Yaroslav Halchenko wrote:
> > thank you Andreas!!!
> > 
> > re etelemetry:  I made it optional for previous version of the
> > package:
> > 
> > $> quilt series
> > deb-no-demand-on-etelemetry
> > 
> > $> git describe
> > debian/0.6.0-1
> 
> Thanks for the hint.  While this could possibly speet up the upload of
> nipype I for myself are fine with waiting for the new Build-Depends.
> Anybody who wants to speed up things is kindly invited to add this patch
> and upload.

What's the status here? python-etelemetry is now in the archive and testing.

Cheers,
Moritz

Bug#959182: Build failures due to missing linux/time_types.h

[Guillem Jover]

On Thu, 2020-04-30 at 19:26:46 +0200, Max Kellermann wrote:
> On 2020/04/30 18:32, Guillem Jover  wrote:
> > You are missing the linux-libc-dev package which gets pulled in by the
> > libc6-dev package.
> 
> linux-libc-dev, libc6-dev and build-essential are all installed.

I assume then that your linux-libc-dev is older than 5.1, which is
when that header got introduced? Are you building in testing/sid?

> > I'd recommend just installing the build-essential package, which is
> > what every package in Debian can assume being present when being built.
> 
> .. but if you believe these are required, but not installed, then why
> does this -dev package not depend on them?

For the same reason we do not declare Depends on essential packages,
or Build-Depends on build-essential packages. I think adding this
explicitly for a -dev is fine, and helpful for users, but the
environment expected to build stuff in Debian assumes build-essential.

> In any case, no matter how you turn it around, it's a package bug.

Not necessarily. :)

Thanks,
Guillem

Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[Moritz Mühlenhoff]

On Mon, Apr 20, 2020 at 09:57:30AM +0200, Thomas Goirand wrote:
> On 4/20/20 4:36 AM, peter green wrote:
> 
> Funcsigs is a backport of the PEP 362 function signature features from
> Python 3.3's inspect module. Python 2 has never been removed from this
> package. Though instead, we shall remove this source package entirely
> from Debian.
> 
> Traceback2 *already* has Python 2 support removed in Sid. I uploaded
> this on the 21st of march, pressured by its potential autoremoval.
> 
> > If the maintainers of nipype are willing to upload a python 3 version
> > soon, then option 1 is IMO the preffered way forward, but a new upstream
> > version is not something I would be prepared to NMU.
> 
> There's no other choice but to fix nipype at this point, or wait until
> it gets autoremoved from Testing. IMO, it'd be fine to NMU a new
> upstream release if you contact the current maintainer and/or using the
> delayed queue.

JFTR, nipype is removed from testing since August last year, so this is totally
not a blocker :-)

Cheers,
Moritz

Bug#953881: transition: ruby2.7 only

[Paul Gevers]

Hi Lucas,

On 26-04-2020 15:14, James McCoy wrote:
> On Thu, Apr 23, 2020 at 02:09:35PM +0200, Paul Gevers wrote:
>> I
>> suggest you apply the same fix you already did here [2] and stop
>> building the python package for now if that works.
> 
> Done and uploaded, however that now makes mercurial FTBFS, as I had
> notified them earlier this month (#956007).  I've now raised that bug to
> serious.

According to dak, ruby2.5 can now be removed. Can you proceed and
request it's removal from unstable?

Paul

elbrus@coccia:~$ dak rm --no-action -R --suite testing ruby2.5
Will remove the following packages from testing:

libruby2.5 | 2.5.7-1+b1 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
   ruby2.5 |2.5.7-1 | source
   ruby2.5 | 2.5.7-1+b1 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
ruby2.5-dev | 2.5.7-1+b1 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
ruby2.5-doc |2.5.7-1 | all

Maintainer: Debian Ruby Team


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

elbrus@coccia:~$ dak rm --no-action -R ruby2.5
Will remove the following packages from unstable:

libruby2.5 | 2.5.7-1+b1 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
   ruby2.5 |2.5.7-1 | source
   ruby2.5 | 2.5.7-1+b1 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
ruby2.5-dev | 2.5.7-1+b1 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
ruby2.5-doc |2.5.7-1 | all

Maintainer: Debian Ruby Team


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#932955: smbd No way to bind to IPv4 only

[darkpenguin]

(Posted by mistake into the old bug again; re-posting here)

https://groups.google.com/forum/#!topic/mailing.unix.samba-technical/sXU9OidKxjY

Here, I've found a discussion about how did this come to exist.

Is there an upstream bugtracker for samba? (Or does anyone actually
notice bugs in Debian stable?)


-- 
darkpenguin

Bug#937431: pyepl: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote:
> Package: src:pyepl
> Version: 1.1.0+git12-g365f8e3-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

pyepl is dead upstream, let's remove it?

Cheers,
Moritz

Bug#958780: [Pkg-javascript-devel] Bug#958780: do we really want to do this ?

[Pirate Praveen]

On Thu, Apr 30, 2020 at 6:57 pm, Paolo Greppi  
wrote:

see below ...

Il 30/04/20 18:10, Pirate Praveen ha scritto:

 ...
 I have pushed my changes to babel7 branch and the error I get is,

 gulp build
 [15:53:07] Local gulp not found in /<>
 [15:53:07] Try running: npm install gulp
 [15:53:07] Using globally installed gulp
 [15:53:07] Using gulpfile /<>/gulpfile.js
 [15:53:07] Starting 'build'...
 [15:53:13] Finished 'build' after 6.18 s
 node ./scripts/build-webpack.js
 Unhandled rejection TypeError: fileDependencies.map is not a 
function
at compiler.run 
(/<>/scripts/build-webpack.js:118:38)

 ...


If you get that, it means webpack failed.
The confusing error is because the stats data structure of our 
webpack (4.30.0) is not compatible with the webpack they expect 
(2.7.0).


To actually see the errors, tweak the compiler.run callback like this:

compiler.run((err, stats) => {
  var stringify = require('json-stringify-safe');
  console.log(stringify(stats, null, 2));
});

I attach the JSON it prints. Sample extract:

"error": {
  "origin": null,
  "dependencies": null,
  "module": "[Circular ~.compilation.entries.0]",
  "name": "ModuleBuildError",
  "error": {
"code": "BABEL_VERSION_UNSUPPORTED",
"version": "6.26.0",
"range": "^7.0.0-0"
  }
}


I think it would be easier to embed gulp-babel 7.x in node-yarnpkg 
until we can update babel-loader also.

Bug#950619: dbus-c++ build depends on the removed libecore-dev

[peter green]

Looking at the changelog for efl, the maintainer decided to give up on dev 
packages for the individual libraries and only provide one dev package ( 
libefl-all-dev ) for all the efl libraries. Transitional packages were provided 
for the buster release, but have now been dropped in bullseye/sid.

Thus the thing to do here is to change the build-dependency from libecore-dev 
to libefl-all-dev . I made this change locally and it test-built succesfully. I 
have decided to go ahead with a NMU and per the NMU guidelines to do so without 
delay. A debdiff is attatched to this mail.

diff -Nru dbus-c++-0.9.0/debian/changelog dbus-c++-0.9.0/debian/changelog
--- dbus-c++-0.9.0/debian/changelog 2018-01-27 00:08:15.0 +
+++ dbus-c++-0.9.0/debian/changelog 2020-04-30 17:10:39.0 +
@@ -1,3 +1,11 @@
+dbus-c++ (0.9.0-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change build-dependency from obsolete libecore-dev to libefl-all-dev
+(Closes: 950619)
+
+ -- Peter Michael Green   Thu, 30 Apr 2020 17:10:39 +
+
 dbus-c++ (0.9.0-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dbus-c++-0.9.0/debian/control dbus-c++-0.9.0/debian/control
--- dbus-c++-0.9.0/debian/control   2015-08-21 06:38:59.0 +
+++ dbus-c++-0.9.0/debian/control   2020-04-30 17:10:39.0 +
@@ -11,7 +11,7 @@
  dpkg-dev (>= 1.16.1),
  graphviz,
  libdbus-1-dev (>= 0.60),
- libecore-dev,
+ libefl-all-dev,
  libexpat1-dev,
  libglib2.0-dev,
  libgtkmm-2.4-dev (>= 1:2.24.4-2~),

Bug#958989: dgit-user(7): building instructions don't work

[Nikolaus Rath]

On Apr 30 2020, Ian Jackson  wrote:
> Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
> work"):
>> Here's another datapoint:
>> 
>> $ dgit clone valgrind
>> $ cd vagrind; sbuild -c buster-amd64
>> 
>> works fine (i.e., if I don't apply any changes).
>
> Can you please send me those changes ?  Best would be if you pushed
> them to git branch somewhere I can clone them.

I just this one more time, just to be sure:

$ git apply /valgrind_copy_file_range.patch
$ git add .
$ git commit -m "Way better than vanilla!"
[dgit/sid 7d9e235] Way better than vanilla!
 13 files changed, 140 insertions(+), 1 deletion(-)
 create mode 100644 memcheck/tests/linux/sys-copy_file_range.c
 create mode 100644 memcheck/tests/linux/sys-copy_file_range.stderr.exp
 create mode 100644 memcheck/tests/linux/sys-copy_file_range.vgtest

$ gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
libdistro-info-perl is not installed, Debian release names are not known.
libdistro-info-perl is not installed, Ubuntu release names are not known.
gbp:info: Changelog 1:3.15.0-2~1.gbp7d9e23 (snapshot #1) prepared up to 7d9e235
gbp:info: Changelog committed for version 1:3.15.0-2~1.gbp7d9e23

$ git clean -xdf
$ sbuild -c buster-amd64 -A --no-clean-source --dpkg-source-opts='-Zgzip -z1 
--format=1.0 -sn'
dpkg-source: info: using source format '1.0'
dpkg-source: warning: source directory 'valgrind' is not 
- 'valgrind-3.15.0'
dpkg-source: info: building valgrind in valgrind_3.15.0-2~1.gbp7d9e23.tar.gz
dpkg-source: info: building valgrind in valgrind_3.15.0-2~1.gbp7d9e23.dsc
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on vostro.rath.org

+==+
| valgrind 1:3.15.0-2~1.gbp7d9e23 (amd64)  Thu, 30 Apr 2020 17:39:00 + |
+==+

Package: valgrind
Version: 1:3.15.0-2~1.gbp7d9e23
Source Version: 1:3.15.0-2~1.gbp7d9e23
Distribution: UNRELEASED
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full


+--+
| Pre Build Commands   |
+--+


/home/nikratio/in-progress/debian-packages/scripts/scan.sh
--

+ where=/home/nikratio/in-progress/debian-packages/debs
+ origin=local
+ label=repo
+ cd /home/nikratio/in-progress/debian-packages/debs
+ apt-ftparchive sources .
+ tee /home/nikratio/in-progress/debian-packages/debs/Sources
+ gzip -9
+ apt-ftparchive packages /home/nikratio/in-progress/debian-packages/debs
+ sed s@/home/nikratio/in-progress/debian-packages/debs@@
+ tee /home/nikratio/in-progress/debian-packages/debs/Packages
+ gzip -9
+ apt-ftparchive -oAPT::FTPArchive::Release::Origin=local 
-oAPT::FTPArchive::Release::Label=repo 
-oAPT::FTPArchive::Release::Codename=/home/nikratio/in-progress/debian-packages/debs
 release /home/nikratio/in-progress/debian-packages/debs
+ sponge /home/nikratio/in-progress/debian-packages/debs/Release

I: Finished running 
'/home/nikratio/in-progress/debian-packages/scripts/scan.sh'.

Finished processing commands.

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/buster-amd64-965184b1-c941-43ec-893e-7fd9d5dad820' with 
'<>'
I: NOTICE: Log filtering will replace 'build/valgrind-bDbzcM/resolver-CCBiIN' 
with '<>'

+--+
| Update chroot|
+--+

Err:1 http://127.0.0.1:8000 ./ InRelease
  Could not connect to 127.0.0.1:8000 (127.0.0.1). - connect (111: Connection 
refused)
Hit:2 http://httpredir.debian.org/debian buster InRelease
Hit:3 http://httpredir.debian.org/debian buster-backports InRelease
Reading package lists...
W: Failed to fetch http://127.0.0.1:8000/./InRelease  Could not connect to 
127.0.0.1:8000 (127.0.0.1). - connect (111: Connection refused)
W: Some index files failed to download. They have been ignored, or old ones 
used instead.
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
  ca-certificates e2fsprogs-l10n fakeroot libcgi-fast-perl libcgi-pm-perl
  libclass-accessor-perl libencode-locale-perl libfakeroot libfcgi-perl
  libgpg-error-l10n libhtml-parser-perl libhtml-tagset-perl libhttp-date-perl
  libhttp-message-perl libio-html-perl libio-string-perl
  liblocale-gettext-perl liblwp-mediatypes-perl libparse-debianchangelog-perl
  libssl1.1 libsub-name-perl libtimedate-perl liburi-perl openssl

Bug#959200: RM: pymtp -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pymtp. It depends on Python 2, is dead upstream and there
are no remaining rdeps.

Cheers,
Moritz

Bug#959197: linux: I/O deadlock after ~3days on hpsa md RAID 0

[jk18buugz]

Package: linux
Version: linux-5.4.35

Dear Maintainers,

since using Linux-Kernel 5.6 after Upgrade from 4.19 my hpsa md RAID 0 hangs 
after some days. (Debian Testing, compiled from Debian "Vanilla Kernel")
Please take a look at my syslog:

Apr 30 15:58:31 srv381 kernel: [544209.588021] sd 0:0:10:0: [sdj] tag#173 
FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 30 15:58:31 srv381 kernel: [544209.588026] sd 0:0:10:0: [sdj] tag#173 Sense 
Key : Medium Error [current] [descriptor]
Apr 30 15:58:31 srv381 kernel: [544209.588028] sd 0:0:10:0: [sdj] tag#173 Add. 
Sense: Record not found
Apr 30 15:58:31 srv381 kernel: [544209.588032] sd 0:0:10:0: [sdj] tag#173 CDB: 
Write(16) 8a 00 00 00 00 01 91 28 00 00 00 00 01 30 00 00
Apr 30 15:58:31 srv381 kernel: [544209.588035] blk_update_request: critical 
medium error, dev sdj, sector 6730285056 op 0x1:(WRITE) flags 0x10 phys_seg 
5 prio class 0
Apr 30 15:58:42 srv381 kernel: [544220.603519] sd 0:0:10:0: [sdj] tag#179 
FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 30 15:58:42 srv381 kernel: [544220.603523] sd 0:0:10:0: [sdj] tag#179 Sense 
Key : Medium Error [current] [descriptor]
Apr 30 15:58:42 srv381 kernel: [544220.603527] sd 0:0:10:0: [sdj] tag#179 Add. 
Sense: Unrecovered read error
Apr 30 15:58:42 srv381 kernel: [544220.603530] sd 0:0:10:0: [sdj] tag#179 CDB: 
Read(16) 88 00 00 00 00 00 4a d1 69 b0 00 00 02 50 00 00
Apr 30 15:58:42 srv381 kernel: [544220.603533] blk_update_request: critical 
medium error, dev sdj, sector 1255238064 op 0x0:(READ) flags 0x80700 phys_seg 
16 prio class 0
Apr 30 15:59:05 srv381 kernel: [544243.400236] XFS (md0p2): writeback error on 
sector 6730284320
Apr 30 15:59:41 srv381 kernel: [544279.528345] sd 0:0:10:0: [sdj] tag#143 
FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 30 15:59:41 srv381 kernel: [544279.528352] sd 0:0:10:0: [sdj] tag#143 Sense 
Key : Medium Error [current] [descriptor]
Apr 30 15:59:41 srv381 kernel: [544279.528354] sd 0:0:10:0: [sdj] tag#143 Add. 
Sense: Record not found
Apr 30 15:59:41 srv381 kernel: [544279.528358] sd 0:0:10:0: [sdj] tag#143 CDB: 
Write(16) 8a 00 00 00 00 01 91 2c c2 c8 00 00 01 38 00 00
Apr 30 15:59:41 srv381 kernel: [544279.528361] blk_update_request: critical 
medium error, dev sdj, sector 6730597064 op 0x1:(WRITE) flags 0x10 phys_seg 
20 prio class 0
Apr 30 15:59:41 srv381 kernel: [544279.557380] XFS (md0p2): writeback error on 
sector 6730597056
Apr 30 16:00:19 srv381 kernel: [544317.433932] hpsa :05:00.0: scsi 
0:0:10:0: resetting physical  Direct-Access ATA  TP04000GBPHYS 
DRV SSDSmartPathCap- En- Exp=1
Apr 30 16:00:24 srv381 kernel: [544322.470747] hpsa :05:00.0: waiting 2 
secs for device to become ready.
Apr 30 16:00:26 srv381 kernel: [544324.497534] hpsa :05:00.0: waiting 4 
secs for device to become ready.
Apr 30 16:00:30 srv381 kernel: [544328.529549] hpsa :05:00.0: waiting 8 
secs for device to become ready.
Apr 30 16:00:38 srv381 kernel: [544336.721590] hpsa :05:00.0: waiting 16 
secs for device to become ready.
Apr 30 16:00:54 srv381 kernel: [544352.849662] hpsa :05:00.0: waiting 32 
secs for device to become ready.
Apr 30 16:01:27 srv381 kernel: [544385.617802] hpsa :05:00.0: waiting 32 
secs for device to become ready.
Apr 30 16:02:00 srv381 kernel: [544418.386133] hpsa :05:00.0: waiting 32 
secs for device to become ready.
Apr 30 16:02:32 srv381 kernel: [544451.154095] hpsa :05:00.0: waiting 32 
secs for device to become ready.
Apr 30 16:02:55 srv381 kernel: [544473.682061] INFO: task jbd2/sda2-8:270 
blocked for more than 120 seconds.
Apr 30 16:02:55 srv381 kernel: [544473.682101]   Tainted: G  I E
 5.4.35-custom #1
Apr 30 16:02:55 srv381 kernel: [544473.682128] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 30 16:02:55 srv381 kernel: [544473.682164] jbd2/sda2-8 D0   270 
 2 0x80004000
Apr 30 16:02:55 srv381 kernel: [544473.682166] Call Trace:
Apr 30 16:02:55 srv381 kernel: [544473.682176]  ? __schedule+0x2e3/0x740
Apr 30 16:02:55 srv381 kernel: [544473.682178]  ? bit_wait_timeout+0x90/0x90
Apr 30 16:02:55 srv381 kernel: [544473.682179]  schedule+0x39/0xa0
Apr 30 16:02:55 srv381 kernel: [544473.682181]  io_schedule+0x12/0x40
Apr 30 16:02:55 srv381 kernel: [544473.682182]  bit_wait_io+0xd/0x50
Apr 30 16:02:55 srv381 kernel: [544473.682184]  __wait_on_bit+0x2a/0x90
Apr 30 16:02:55 srv381 kernel: [544473.682186]  
out_of_line_wait_on_bit+0x92/0xb0
Apr 30 16:02:55 srv381 kernel: [544473.682190]  ? var_wake_function+0x20/0x20
Apr 30 16:02:55 srv381 kernel: [544473.682198]  
jbd2_journal_commit_transaction+0x107c/0x1930 [jbd2]
Apr 30 16:02:55 srv381 kernel: [544473.682203]  ? 
try_to_del_timer_sync+0x4f/0x80
Apr 30 16:02:55 srv381 kernel: [544473.682208]  kjournald2+0xb7/0x280 [jbd2]
Apr 30 16:02:55 srv381 kernel: [544473.682210]  ? finish_wait+0x80/0x80
Apr 30 16:02:55 srv381 kernel: [544473.682213]  kthread+0xf9/0x130
Apr 30 

Bug#959199: opensmtpd: local mbox delivery fails with "lockspool: /var/mail/.lock: Permission denied"

[Chris Ruvolo]

Package: opensmtpd
Version: 6.6.4p1-1~bpo10+1
Severity: important

Dear Maintainer,

I ran into a local mbox delivery problem.  Log file repeatedly shows:

  lockspool: /var/mail/.lock: Permission denied

/var/mail is root:mail 2775

Messages remain "inflight" or "pending".

Anonymized smtpd.conf:

  listen on localhost

  table aliases file:/etc/aliases
  table secrets file:/etc/mail.secrets

  action "local_mail" mbox alias 

  action "gmail" relay host smtp+tls://gm...@smtp.gmail.com:587 auth 

  match from any for domain "example.net" action "local_mail"
  match from any for domain "host.example.net" action "local_mail"

  match for local action "local_mail"
  match from local for any action "gmail"

Thanks for your assistance looking into this.

-Chris

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages opensmtpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  ed 1.15-1
ii  init-system-helpers1.56+nmu1
ii  libasr01.0.2-2
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libevent-2.1-6 2.1.8-stable-4
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1d-0+deb10u3
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages opensmtpd recommends:
ii  opensmtpd-extras  6.6.0-1~bpo10+1

Versions of packages opensmtpd suggests:
ii  ca-certificates  20190110

-- Configuration Files:
/etc/smtpd.conf changed [not included]

-- debconf information excluded

Bug#958989: dgit-user(7): building instructions don't work

[Nikolaus Rath]

On Apr 30 2020, Ian Jackson  wrote:
> Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
> work"):
>> Here's another datapoint:
>> 
>> $ dgit clone valgrind
>> $ cd vagrind; sbuild -c buster-amd64
>> 
>> works fine (i.e., if I don't apply any changes).
>
> Can you please send me those changes ?  Best would be if you pushed
> them to git branch somewhere I can clone them.

Here they are. 


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
commit 5f00db0
Author: Alexandra Hajkova 
Date:   Thu May 2 08:24:02 2019 -0400

Add support for the copy_file_range syscall

Support amd64, x86, arm64, ppc64, ppc32 and s390x architectures.
Also add sys-copy_file_range test case.

diff --git a/configure.ac b/configure.ac
index d043ce3..3528925 100755
--- a/configure.ac
+++ b/configure.ac
@@ -4172,6 +4172,7 @@ AC_CHECK_FUNCS([ \
 utimensat\
 process_vm_readv  \
 process_vm_writev \
+copy_file_range \
 ])
 
 # AC_CHECK_LIB adds any library found to the variable LIBS, and links these
@@ -4187,6 +4188,8 @@ AM_CONDITIONAL([HAVE_PTHREAD_SPINLOCK],
[test x$ac_cv_func_pthread_spin_lock = xyes])
 AM_CONDITIONAL([HAVE_PTHREAD_SETNAME_NP],
[test x$ac_cv_func_pthread_setname_np = xyes])
+AM_CONDITIONAL([HAVE_COPY_FILE_RANGE],
+   [test x$ac_cv_func_copy_file_range = xyes])
 
 if test x$VGCONF_PLATFORM_PRI_CAPS = xMIPS32_LINUX \
  -o x$VGCONF_PLATFORM_PRI_CAPS = xMIPS64_LINUX ; then
diff --git a/coregrind/m_syswrap/priv_syswrap-linux.h b/coregrind/m_syswrap/priv_syswrap-linux.h
index f76191a..1edf9eb 100644
--- a/coregrind/m_syswrap/priv_syswrap-linux.h
+++ b/coregrind/m_syswrap/priv_syswrap-linux.h
@@ -379,6 +379,7 @@ DECL_TEMPLATE(linux, sys_getsockname);
 DECL_TEMPLATE(linux, sys_getpeername);
 DECL_TEMPLATE(linux, sys_socketpair);
 DECL_TEMPLATE(linux, sys_kcmp);
+DECL_TEMPLATE(linux, sys_copy_file_range);
 
 // Some arch specific functions called from syswrap-linux.c
 extern Int do_syscall_clone_x86_linux ( Word (*fn)(void *), 
diff --git a/coregrind/m_syswrap/syswrap-amd64-linux.c b/coregrind/m_syswrap/syswrap-amd64-linux.c
index 30e7d0e..0c1d8d1 100644
--- a/coregrind/m_syswrap/syswrap-amd64-linux.c
+++ b/coregrind/m_syswrap/syswrap-amd64-linux.c
@@ -863,6 +863,8 @@ static SyscallTableEntry syscall_table[] = {
LINXY(__NR_statx, sys_statx), // 332
 
LINX_(__NR_membarrier,sys_membarrier),// 324
+
+   LINX_(__NR_copy_file_range,   sys_copy_file_range),   // 326
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/coregrind/m_syswrap/syswrap-arm64-linux.c b/coregrind/m_syswrap/syswrap-arm64-linux.c
index 290320a..f66be2d 100644
--- a/coregrind/m_syswrap/syswrap-arm64-linux.c
+++ b/coregrind/m_syswrap/syswrap-arm64-linux.c
@@ -819,7 +819,7 @@ static SyscallTableEntry syscall_main_table[] = {
//   (__NR_userfaultfd,   sys_ni_syscall),// 282
LINX_(__NR_membarrier,sys_membarrier),// 283
//   (__NR_mlock2,sys_ni_syscall),// 284
-   //   (__NR_copy_file_range,   sys_ni_syscall),// 285
+   LINX_(__NR_copy_file_range,   sys_copy_file_range),   // 285
//   (__NR_preadv2,   sys_ni_syscall),// 286
//   (__NR_pwritev2,  sys_ni_syscall),// 287
//   (__NR_pkey_mprotect, sys_ni_syscall),// 288
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 73ef98d..cd0ee74 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -12093,6 +12093,36 @@ POST(sys_bpf)
}
 }
 
+PRE(sys_copy_file_range)
+{
+  PRINT("sys_copy_file_range (%lu, %lu, %lu, %lu, %lu, %lu)", ARG1, ARG2, ARG3,
+ARG4, ARG5, ARG6);
+
+  PRE_REG_READ6(vki_size_t, "copy_file_range",
+int, "fd_in",
+vki_loff_t *, "off_in",
+int, "fd_out",
+vki_loff_t *, "off_out",
+vki_size_t, "len",
+unsigned int, "flags");
+
+  /* File descriptors are "specially" tracked by valgrind.
+ valgrind itself uses some, so make sure someone didn't
+ put in one of our own...  */
+  if (!ML_(fd_allowed)(ARG1, "copy_file_range(fd_in)", tid, False) ||
+  !ML_(fd_allowed)(ARG3, "copy_file_range(fd_in)", tid, False)) {
+ SET_STATUS_Failure( VKI_EBADF );
+  } else {
+ /* Now see if the offsets are defined. PRE_MEM_READ will
+double check it can dereference them. */
+ if (ARG2 != 0)
+PRE_MEM_READ( "copy_file_range(off_in)", ARG2, sizeof(vki_loff_t));
+ if (ARG4 != 0)
+PRE_MEM_READ( "copy_file_range(off_out)", ARG4, sizeof(vki_loff_t));
+  }
+}
+
+
 #undef PRE
 #undef POST
 
diff --git a/coregrind/m_syswrap/syswrap-ppc32-linux.c 

Bug#959196: More detailed description for kwin-wayland-backend-* packages

[Christian Göttsche]

Package: src:kwin
Version: 4:5.17.5-2

Please add some differentiating descriptions to the
kwin-wayland-backend-* packages,
so it's easier for users to understand which backend they want to have.

Bug#959198: openblas: synchronize FP CSR between threads

[Hideki Yamane]

Source: openblas
Severity: normal
X-Debbugs-Cc: henr...@debian.org

Dear Maintainer,

 I've found some people complain about Ubuntu/Debian's openblas
 package via twitter and they rebuild it from source, since it
 seem that not work as expected with SMP (see http://verifiedby.me/adiary/060
 (In Japanese)).

 I'm not familiar with this issue, but it may be worth to check, IMHO.
 

-- 
Hideki Yamane 
>From f0dab10eaf513857293b9db9ed4dc46bc4fae5ee Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Fri, 1 May 2020 02:24:49 +0900
Subject: [PATCH] add 0007-synchronize-FP-CSR-between-threads.patch

---
 ...7-synchronize-FP-CSR-between-threads.patch | 21 +++
 debian/patches/series |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 debian/patches/0007-synchronize-FP-CSR-between-threads.patch

diff --git a/debian/patches/0007-synchronize-FP-CSR-between-threads.patch b/debian/patches/0007-synchronize-FP-CSR-between-threads.patch
new file mode 100644
index 000..5878acc
--- /dev/null
+++ b/debian/patches/0007-synchronize-FP-CSR-between-threads.patch
@@ -0,0 +1,21 @@
+From: Hideki Yamane 
+Date: Fri, 1 May 2020 02:12:56 +0900
+Subject: synchronize FP CSR between threads
+
+---
+ Makefile.rule | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.rule b/Makefile.rule
+index a4465e4..2543daa 100644
+--- a/Makefile.rule
 b/Makefile.rule
+@@ -208,7 +208,7 @@ NO_AFFINITY = 1
+ # DEVICEDRIVER_ALLOCATION = 1
+ 
+ # If you need to synchronize FP CSR between threads (for x86/x86_64 only).
+-# CONSISTENT_FPCSR = 1
++CONSISTENT_FPCSR = 1
+ 
+ # If any gemm argument m, n or k is less or equal this threshold, gemm will be execute
+ # with single thread. (Actually in recent versions this is a factor proportional to the
diff --git a/debian/patches/series b/debian/patches/series
index 69b41f9..dd1d3e7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ remove-openmp-warning.patch
 no-embedded-lapack.patch
 shared-blas-lapack.patch
 matgen-symbols-not-included.patch
+0007-synchronize-FP-CSR-between-threads.patch
-- 
2.26.2

Bug#959182: Build failures due to missing linux/time_types.h

[Max Kellermann]

On 2020/04/30 18:32, Guillem Jover  wrote:
> You are missing the linux-libc-dev package which gets pulled in by the
> libc6-dev package.

linux-libc-dev, libc6-dev and build-essential are all installed.

> I'd recommend just installing the build-essential package, which is
> what every package in Debian can assume being present when being built.

.. but if you believe these are required, but not installed, then why
does this -dev package not depend on them?

In any case, no matter how you turn it around, it's a package bug.

Bug#958989: dgit-user(7): building instructions don't work

[Ian Jackson]

Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
work"):
> Here's another datapoint:
> 
> $ dgit clone valgrind
> $ cd vagrind; sbuild -c buster-amd64
> 
> works fine (i.e., if I don't apply any changes).

Can you please send me those changes ?  Best would be if you pushed
them to git branch somewhere I can clone them.

> > gives the error from dpkg-source, but
> >
> > (b)   schroot into the buster-amd64 chroot
> >   sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=null -A \
> >   --no-clean-source --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'
> >
> > works.
> 
> Yes - with the caveat that in the second case I manually bind-mounted
> the directory that contained the .orig.gz and the git repo.

This latter rune ought not to need the .orig ...

> > Can you send me the output of
> >printenv | sort
> > and the version of dpkg-dev you have outside the chroot ?
[etc.]

Thanks.  I don't see anything in there that looks at all relevant.

Ian.

Bug#958989: dgit-user(7): building instructions don't work

[Nikolaus Rath]

On Apr 29 2020, Ian Jackson  wrote:
> Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
> work"):
>> On Apr 28 2020, Ian Jackson  wrote:
>> >mkdir ../aside
>> >mv ../valgrind_* ../aside
>> >sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=null -A \
>> >  --no-clean-source --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'
>> >
>> > and send me the log ?
>> 
>> This worked.
>> 
>> 
>> Log is attached (generated with `script`).
>
> Thanks.
>
> This is all quite mysterious to me and I'm not sure where to go next.

Here's another datapoint:

$ dgit clone valgrind
$ cd vagrind; sbuild -c buster-amd64

works fine (i.e., if I don't apply any changes).

> So on with (1).  To recap, AIUI we now have a situation where in your
> setup
>
> (a)   sbuild -c buster-amd64 -A \
>   --no-clean-source --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'
>
> gives the error from dpkg-source, but
>
> (b)   schroot into the buster-amd64 chroot
>   sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=null -A \
>   --no-clean-source --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'
>
> works.

Yes - with the caveat that in the second case I manually bind-mounted
the directory that contained the .orig.gz and the git repo.


> I think (a) will run dpkg-source to build the source pacakge outside
> the chroot.  (b) obviously runs it inside it.  Maybe you have some
> environment variable or a funny version of dpkg-dev or something ?
>
> Can you send me the output of
>printenv | sort
> and the version of dpkg-dev you have outside the chroot ?

$ printenv | sort
BROWSER=firefox
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DEBEMAIL=nikol...@rath.org
DEBFULLNAME=Nikolaus Rath
DEBSIGN_KEYID=0xD113FCAC3C4E599F
DESKTOP_SESSION=lightdm-xsession
DISPLAY=:0
EC2_CERT=/home/nikratio/lib/aws-x509-cert.pem
EC2_PRIVATE_KEY=/home/nikratio/lib/aws-x509-key.pem
EDITOR=vim
GDM_LANG=en_US.utf8
GDMSESSION=lightdm-xsession
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GTK_IM_MODULE=xim
HISTCONTROL=ignoredups
HOME=/home/nikratio
LANG=en_US.UTF-8
LESSCLOSE=/usr/bin/lesspipe %s %s
LESSOPEN=| /usr/bin/lesspipe %s
LESS=-S -i -R
LOGNAME=nikratio
LS_COLORS=
MATLABPATH=/home/nikratio/lib/matlab/
OLDPWD=/home/nikratio
OPENSSL_CONF=/home/nikratio/lib/ca/openssl/openssl.cnf
PAGER=less
PATH=/home/nikratio/bin:/home/nikratio/.local/bin:/usr/local/sbin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11
PROMPT_DIRTRIM=3
PS1=\n\[\033[01;30m\][$?] 
\[\033[01;31m\]\u@\h${SCHROOT_CHROOT_NAME:+(${SCHROOT_CHROOT_NAME})}\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\n\$
 
PWD=
PYTHONSTARTUP=/home/nikratio/.pythonrc.py
QT_IM_MODULE=xim
QT_STYLE_OVERRIDE=Fusion
SHELL=/bin/bash
SHLVL=0
SSH_AGENT_PID=2869
SSH_AUTH_SOCK=/tmp/ssh-xbEBM4HCJ0av/agent.2590
TERMINAL=gnome-terminal
TERM=xterm-256color
TEXDOCVIEW_html=firefox %s
TEXDOCVIEW_pdf=evince %s
TEXDOCVIEW_text=less %s
TEXMFHOME=/home/nikratio/lib/texmf
USER=nikratio
_=/usr/bin/printenv
VISUAL=vim
VTE_VERSION=5402
WINDOWID=18874371
XAUTHORITY=/home/nikratio/.Xauthority
XDG_CURRENT_DESKTOP=GNOME
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/nikratio
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=lightdm-xsession
XDG_SESSION_ID=2
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SESSION_TYPE=x11
XDG_VTNR=7

$ dpkg --version
Debian 'dpkg' package management program version 1.19.7 (amd64).
This is free software; see the GNU General Public License version 2 or
later for copying conditions. There is NO warranty.

> Also I would like to try a repro that is smaller than valgrind :-).
> I wonder if you would be willing to try using the test case from the
> dgit test suite:
>
>   # apt --no-install-recommends install dgit dgit-infrastructure
> devscripts debhelper fakeroot build-essential chiark-utils-bin \
> bc faketime liburi-perl sbuild man-db
>   # ^ # from dgit/debian/tests/control, stanza for sbuild-gitish
>
>   $ dgit clone dgit
>   $ cd dgit
>   $ DGIT_SCHROOT_CHROOT=buster-amd64 tests/tests/sbuild-gitish 2>&1 |tee log

That worked (log attached).


Best,
-Nikolaus


-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
++ set -o pipefail
++ . tests/lib-core
++ . tests/lib-restricts
++ trap '
rc=$?
set +e
[ "x$DGIT_TEST_KEEP_MUSTCLEAN" != x ] || \
[ "x$DGIT_TEST_TMP" = x ] || rm -rf $DGIT_TEST_TMP/must-clean
set -e
test $rc = 0 || t-report-failure
' EXIT
++ t-filter-out-git-hyphen-dir
++ local pathent
+++ type -p git-rev-parse
+++ :
++ pathent=
++ case "$pathent" in
++ return
++ t-set-intree
++ '[' x = x ']'
++ return
++ : -D
++ export DGIT_TEST_DEBUG
++ : x
++ export DGIT_TEST_DEBPUSH_DEBUG
++ :
++ export 'GIT_COMMITTER_DATE=153000 +0100'
++ GIT_COMMITTER_DATE='153000 

Bug#959195: apache2: Extras for deflate.conf: text/javascript

[Timo Tijhof]

Package: apache2
Version: 2.4.25

The default deflate.conf file provided in the Debian package for apache2
instructs the server to consider compressing responses for
application/javascript. [1]

This MIME type is declared as canonical for ".js" by RFC 4329, [2] and is
also associated with ".js" in the default mime.types file. This means for
static JS files served from disk, Apache compresses them out-of-the-box.

However, out in the wild, the text/javascript MIME type is quite common,
if not more common, [3] than application/javascript. As such, when Apache
proxies responses from CGI applications or from other external services,
it often ends up not compressing JavaScript responses.

This is currently known to affect MediaWiki, WordPress, and likely other
popular web applications as well. [4][5] It can be non-trivial for an
upstream like MediaWiki to change this as these MIME types may be deeply
embedded in stable APIs and data structures. For example, it's database
schema and its `ctype` HTTP query parameter both require `text/javascript`.

RFC 4329 defines "equivalent processing requirements for text/javascript,
… and application/javascript". As such, I think Apache2 should consider
both of these for compression by default.

This has the potential to have a big impact on the web. As an example, there
seem to be lots of public MediaWiki sites out there who use Debian Linux (or
downstreams like Ubuntu), and have mod_deflate enabled with the default
compression for text/html and text/css, but have apparently not realised the
lack of JS compression and/or were unable to configure it. [6]

I am new to Debian and its bug tracker and would be interested in submitting
a patch for this if the request is accepted.

-- Timo Tijhof

Principal Engineer,
Performance Team,
Wikimedia Foundation.

[1] Original patch:
https://salsa.debian.org/apache-team/apache2/-/commit/4d93abc8899873ff27080f9261093a02e47320e4

[2] RFC 4329: https://tools.ietf.org/html/rfc4329

[3] text/javascript might become the canonical instead:
https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

[4] WordPress:
https://github.com/WordPress/WordPress/blob/5.4.1/wp-includes/SimplePie/Misc.php#L2130

[5] MediaWiki:
https://gerrit.wikimedia.org/g/mediawiki/core/+/1.34.1/includes/resourceloader/ResourceLoader.php#892

[6] StackOverflow: https://duckduckgo.com/?q=stackoverflow+
"text%2Fjavascript"+"apache"+"deflate"

Bug#930492: mingw-w64-tools: x86_64-w64-mingw32-pkg-config does not see installed dpkg-dev

[Artem V. Ageev]

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: beastie 
To: Debian Bug Tracking System <930...@bugs.debian.org>
Subject: mingw-w64-tools: x86_64-w64-mingw32-pkg-config does not see 
installed dpkg-dev

Message-ID: <158826484870.32854.370491533500620.reportbug@e470>
X-Mailer: reportbug 7.6.0
Date: Thu, 30 Apr 2020 19:40:48 +0300

Package: mingw-w64-tools
Version: 7.0.0-2
Followup-For: Bug #930492

Dear Maintainer,

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


   * What led up to the situation?

valac --cc gcc-mingw-w64-x86-64 --pkg-config 
x86_64-w64-mingw32-pkg-config untitled.vala


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

apt install -y dpkg-dev

   * What was the outcome of this action?

"Please install dpkg-dev to use pkg-config when cross-building"

   * What outcome did you expect instead?

Compilation finished successfully.

I ask you to help me!

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


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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 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 mingw-w64-tools depends on:
ii  libc6   2.30-4
ii  pkg-config  0.29.2-1

mingw-w64-tools recommends no packages.

mingw-w64-tools suggests no packages.

-- no debconf information

Bug#959182: Build failures due to missing linux/time_types.h

[Guillem Jover]

Control: reopen -1

On Thu, 2020-04-30 at 18:32:32 +0200, Guillem Jover wrote:
> On Thu, 2020-04-30 at 15:21:30 +0200, Max Kellermann wrote:
> > Package: liburing-dev
> > Version: 0.6-2
> 
> > It appears to be impossible to build anything with liburing-dev, not
> > even the examples shipped in the package:
> > 
> >  $ gcc /usr/share/doc/liburing-dev/examples/io_uring-test.c
> >  In file included from /usr/include/liburing.h:14,
> >   from 
> > /usr/share/doc/liburing-dev/examples/io_uring-test.c:13:
> >  /usr/include/liburing/compat.h:5:10: fatal error: linux/time_types.h: No 
> > such file or directory
> >   #include 
> >^~~~
> >  compilation terminated.
> 
> You are missing the linux-libc-dev package which gets pulled in by the
> libc6-dev package.
> 
> I'd recommend just installing the build-essential package, which is
> what every package in Debian can assume being present when being built.
> 
> I'm closing the report.

Hmm, I'm not sure whether this is really consistently applied in the
distribution for -dev packages. But I guess I could just add the
linux-libc-dev dependency here. So I'll do that.

Thanks,
Guillem

Bug#952689: libcddb2: freedb service is closing down

[nito]

On Thu, 27 Feb 2020 16:19:48 +0100 Andreas Ronnquist  
wrote:> Package: libcddb2
> Version: 1.3.2-6+b1
> Severity: important
> 
> Dear Maintainer,
> 
> According to a notice on https://freedb.org, that service is closing
> down. I assume that libcddb is using that server, and only that -
> please inform me if I am mistaken.

I'm not the maintainer, but according to libccdb's documentataion it does use 
freedb.org as the default server, *but* it can also be used with other 
compatible servers.
http://libcddb.sourceforge.net/API/cddb__conn_8h.html#54641c0dac5234713f1916d8d70d8e8b

Afaik gnudb.org should be such a compatible server.

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

On Thu, Apr 30, 2020 at 07:17:50AM -0700, Matthew Fernandez wrote:
> 
> Valgrind, in its default mode, checks for a variety of memory issues 
> (use-after-free, write out-of bounds, …). You don’t need any special 
> configure/build options, but you probably want to enable debug symbols 
> (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re 
> running with Valgrind: `valgrind ./src/clustalo -i 
> debian/tests/biopython_testdata/f002 …`.


Running on mipsel:

(sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind src/clustalo -i 
debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
temp_test.aln --outfmt clustal --force
==15149== Memcheck, a memory error detector
==15149== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15149== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==15149== Command: src/clustalo -i debian/tests/biopython_testdata/f002 
--guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force
==15149== 
==15149== Conditional jump or move depends on uninitialised value(s)
==15149==at 0x4007828: cached_fpabi_reject_phdr_p 
(dl-machine-reject-phdr.h:57)
==15149==by 0x4007828: elf_machine_reject_phdr_p 
(dl-machine-reject-phdr.h:217)
==15149==by 0x4008080: open_verify.constprop.0 (dl-load.c:1688)
==15149==by 0x4009D7C: _dl_map_object (dl-load.c:2181)
==15149==by 0x40011F8: map_doit (rtld.c:607)
==15149==by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196)
==15149==by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215)
==15149==by 0x4001138: do_preload (rtld.c:778)
==15149==by 0x4002560: handle_preload_list (rtld.c:879)
==15149==by 0x4005B08: dl_main (rtld.c:1684)
==15149==by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253)
==15149==by 0x400199C: _dl_start_final (rtld.c:447)
==15149==by 0x4001D44: _dl_start (rtld.c:539)
==15149== 
==15149== Invalid read of size 1
==15149==at 0x486F558: ??? (in 
/usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8)
==15149==by 0x486F5F0: ??? (in 
/usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8)
==15149==  Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd
==15149==at 0x484B89C: malloc (in 
/usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so)
==15149==by 0x126674: CkMalloc (util.c:83)
==15149==by 0x126864: CkStrdup (util.c:213)
==15149==by 0x1108F4: ConvertOldCmdline(int*, char***, int, char**) 
(main.cpp:358)
==15149==by 0x10FCDC: main (main.cpp:467)
==15149== 
==15149== Invalid read of size 4
==15149==at 0x1221B8: PairDistances (pair_dist.c:346)
==15149==by 0x114774: AlignmentOrder (clustal-omega.c:835)
==15149==by 0x115024: Align (clustal-omega.c:1221)
==15149==by 0x112EB4: MyMain (mymain.c:1192)
==15149==by 0x10FCF0: main (main.cpp:469)
==15149==  Address 0x83b0 is not stack'd, malloc'd or (recently) free'd
==15149== 
==15149== 
==15149== Process terminating with default action of signal 10 (SIGBUS)
==15149==at 0x1221B8: PairDistances (pair_dist.c:346)
==15149==by 0x114774: AlignmentOrder (clustal-omega.c:835)
==15149==by 0x115024: Align (clustal-omega.c:1221)
==15149==by 0x112EB4: MyMain (mymain.c:1192)
==15149==by 0x10FCF0: main (main.cpp:469)
==15149== 
==15149== HEAP SUMMARY:
==15149== in use at exit: 8,039 bytes in 34 blocks
==15149==   total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated
==15149== 
==15149== LEAK SUMMARY:
==15149==definitely lost: 128 bytes in 2 blocks
==15149==indirectly lost: 0 bytes in 0 blocks
==15149==  possibly lost: 0 bytes in 0 blocks
==15149==still reachable: 7,911 bytes in 32 blocks
==15149== suppressed: 0 bytes in 0 blocks
==15149== Rerun with --leak-check=full to see details of leaked memory
==15149== 
==15149== Use --track-origins=yes to see where uninitialised values come from
==15149== For lists of detected and suppressed errors, rerun with: -s
==15149== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Bus error


Is this different from your tests on amd64?

 
> > On the other hand:  Is valgrind possibly able to uncover issues also
> > on any other architecture?
> 
> You mean if we were to use Valgrind to debug this on e.g. x86? In my own 
> experiments on amd64, both ASan and Valgrind found multiple issues in both 
> Clustal Omega and its dependency, argtable2. However I don’t believe any of 
> the remaining ones I was seeing after the last patches I sent you could be 
> causing the mipsel bus error; they were all memory leaks.

Thanks again for your great support and the time you've spent.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#959016: Team Salsa Page

[Olek Wojnar]

The team now has a Salsa presence [1] as well.

-Olek

[1] https://salsa.debian.org/bazel-team

Bug#958780: [Pkg-javascript-devel] Bug#958780: do we really want to do this ?

[Pirate Praveen]

On Sun, Apr 26, 2020 at 4:33 pm, Paolo Greppi  
wrote:
My understanding is that node-gulp-babel v8 should be used with 
babel7.
Same goes for node-babel-loader, you need v8 for babel7, but we only 
have node-babel-loader 7 in Debian.


If we want babel6 to co-exist with babel7, then we don't want to just 
update node-gulp-babel and node-babel-loader to v8.
We want to keep node-gulp-babel and node-babel-loader at v7 for 
compatibility with babel6, and upload new node-gulp-babel8 and 
node-babel-loader8 for babel7.


Back to the topic of this bug, do we really want to upgrade the yarn 
build system from babel6 to babel7 ?
Here is some indication that upstream is not interested: 
https://github.com/yarnpkg/yarn/pull/6322
But I have raised the issue anyway: 
https://github.com/yarnpkg/yarn/issues/8083


I was able to build part of node-yarnpkg with babel7 (the part that 
uses gulp-babel). Since babel 7 does not need babel-loader 8.x right 
now (gulp-babel and rollup-plugin-babel are build dependencies of babel 
7 and has to go together to unstable) we could continue using 
babel-loader 7.x that works with babel 6 (so node-yarnpkg will be using 
both babel 7 and babel 6). babel-loader 7 -> 8 transition will need to 
be handled later.


I have pushed my changes to babel7 branch and the error I get is,

gulp build
[15:53:07] Local gulp not found in /<>
[15:53:07] Try running: npm install gulp
[15:53:07] Using globally installed gulp
[15:53:07] Using gulpfile /<>/gulpfile.js
[15:53:07] Starting 'build'...
[15:53:13] Finished 'build' after 6.18 s
node ./scripts/build-webpack.js
Unhandled rejection TypeError: fileDependencies.map is not a function
   at compiler.run (/<>/scripts/build-webpack.js:118:38)
   at finalCallback (/usr/share/nodejs/webpack/lib/Compiler.js:220:39)
   at hooks.done.callAsync.err 
(/usr/share/nodejs/webpack/lib/Compiler.js:236:13)
   at AsyncSeriesHook.eval [as callAsync] (eval at create 
(/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), 
:6:1)
   at AsyncSeriesHook.lazyCompileHook [as _callAsync] 
(/usr/share/nodejs/tapable/lib/Hook.js:35:21)

   at onCompiled (/usr/share/nodejs/webpack/lib/Compiler.js:234:21)
   at hooks.afterCompile.callAsync.err 
(/usr/share/nodejs/webpack/lib/Compiler.js:631:15)
   at AsyncSeriesHook.eval [as callAsync] (eval at create 
(/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), 
:6:1)
   at AsyncSeriesHook.lazyCompileHook [as _callAsync] 
(/usr/share/nodejs/tapable/lib/Hook.js:35:21)
   at compilation.seal.err 
(/usr/share/nodejs/webpack/lib/Compiler.js:628:31)
   at AsyncSeriesHook.eval [as callAsync] (eval at create 
(/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), 
:6:1)
   at AsyncSeriesHook.lazyCompileHook [as _callAsync] 
(/usr/share/nodejs/tapable/lib/Hook.js:35:21)
   at hooks.optimizeAssets.callAsync.err 
(/usr/share/nodejs/webpack/lib/Compilation.js:1329:35)
   at AsyncSeriesHook.eval [as callAsync] (eval at create 
(/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), 
:6:1)
   at AsyncSeriesHook.lazyCompileHook [as _callAsync] 
(/usr/share/nodejs/tapable/lib/Hook.js:35:21)
   at hooks.optimizeChunkAssets.callAsync.err 
(/usr/share/nodejs/webpack/lib/Compilation.js:1320:32)

Bug#959193: libperl5i-perl: Test failures with Devel::Declare 0.006022-1

[gregor herrmann]

Source: libperl5i-perl
Version: 2.13.2-1
Severity: serious
Tags: upstream ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=131226

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As noted on ci.d.n and in CPAN RT, libperl5i-perl is broken by the
recent updagrade of libdevel-declare-perl.

Couldn't find declarator 'func' at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare/Context/Simple.pm line 47.

Devel::Declare::Context::Simple::skip_declarator(perl5i::2::Signatures=HASH(0x55bdfacdc748))
 called at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare/MethodInstaller/Simple.pm 
line 62

Devel::Declare::MethodInstaller::Simple::parser(perl5i::2::Signatures=HASH(0x55bdfacdc748),
 "func", 4, 1) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare/MethodInstaller/Simple.pm 
line 25
Devel::Declare::MethodInstaller::Simple::__ANON__("func", 4) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare.pm line 277
Devel::Declare::linestr_callback("const", "func", 4) called at 
t/Meta/methods.t line 115
t/Meta/methods.t . 
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 

etc.


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl6q98ZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaKThAAoaPibfxHkbZDHE8qNwRhy9BxzqDyApOxQizwPlKcpimPKpv4kbbC+9K9
nvTNUCDM5i3IlHTQG9V0/VwRzlX+sdpo8iGQj6UtDdGRt+BP85sewQU+HjFvpVBR
X3nD2jZmt0S/EWGiUVG65ld/6dBsaPZA63CkVtGzLHJ3h5ybsrDF1+9dQgARXRfM
/Mpdg0GMnCRZXNcAaXvddXHDYdJ//X2IW1cJwxnHzldmrSRAx5dHB0Nvdk+Inwne
IwO8VEgJOvMycKhtiyxQ13T/+4EB+R7qiwRBhV4/9eGTBQ4rfzT1AtQeez98gO1i
0warPeNN+Jxw2Htsg0O5qWG0KayTJSR2xzvBUvHEsc5gg096SHNcujbu6MN+CC8J
/jdOop5ioUIAZDyMJlufPEtvUK4pX6uPDCU9S3DeujuZdiLWl7wWn18P0cr7uGql
72wCGgsfREIhqe8KiN16dGbF14H6hucI2J7pDI1BjK4877whV3/WxZNgP9FF/8T4
/tUxZEOucvD/Hd9g+A/1Hnm4cvdZSPC2wpzWDXYos4ihMXsMwORC8j3nXlaaj5AS
OOwbzmBNQDwhXy3wa5hHII5q+7A55mSiKFWhtWmPYj20IK66/qEvup/N8UakwYl0
Pmqlqw1GETSx6858NsW0S3N7F9jfIgaSFbCYQXu+IgwBE3Qf8Is=
=ieDu
-END PGP SIGNATURE-

Bug#959194: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7f024b2fbad0' of type 'MaiAtkType13b'

[shirish शिरीष]

Package: firefox-esr
Version: 68.7.0esr-1
Severity: normal

Dear all,

I always get the above in a firefox session.

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-4
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200418-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.18-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.44.7-4
ii  libsqlite3-0  3.31.1-5
ii  libstartup-notification0  0.12-6
ii  libstdc++610-20200418-1
ii  libx11-6  2:1.6.9-2
ii  libx11-xcb1   2:1.6.9-2
ii  libxcb-shm0   1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#958749: libconfig-model-dpkg-perl: Parsing of wrapped long patch subjects incorrect

[Dominique Dumont]

On samedi 25 avril 2020 00:17:18 CEST you wrote:
> I have packages with patches maintained using gbp-pq, which wraps long
> first lines of commits, indenting the subsequent line with a single space,
> using that full (wrapped) line as the "Subject:".

On the other hand the DEP-3 specification [1] mentions:
"This obligatory field contains at least a short description on the first line. 
When Subject is used, it is expected that the long description is outside of 
the structured fields. "

Cme tries to salvage information from the Subject field and move in the free 
form description, after all allowed parameters (Last-UPdate) in this case.

I think gbp-pq should not produce multi lines Subject fields

All the best

[1] https://dep-team.pages.debian.net/deps/dep3/

Bug#958277: simple-cdd: Resulting Install CD asks for questions answered in the profiles/NAME.x files

[Vagrant Cascadian]

On 2020-04-29, Buck wrote:
>> The maintainer scripts for each individual package and their debconf
>> templates are where to look.
>
> I recommend putting this in the docs.

I'll consider that, or at least referencing the relevent information
found in other existing documentation.


>> I wouldn't expect the "hello" program to document the fundamentals of
>> computer science, or the working of electricity, or atomic theory, or
>> the origins of the universe... even though all of those are, ostensibly,
>> all relevent.
>
> I would, in the way that docs are supposed to do that.  I think you
> don't know a lot about documentation theory.

Given your response, clearly I do not.


> You do all of that by saying "This project requires a computer running
> Debian," and if people aren't sure they have that then they research
> Debian, and computers, and their dependencies, etc.  That's just the
> way all documenation is always written.  Anything else is just
> scribbles.

There are always, of course, some unstated assumptions in any
documentation. The meaningful question is which assumptions are a
reasonable starting point, in my opinion... and opinions on this will
surely vary.


> Anyway you effectively do that in yours, so it's not material here.
> But it is similar to how the debian-installer doc should reference the
> HowTo, which should reference the README as the authoritative doc.

The debian-installer documentation should not reference simple-cdd
documentation, though the debian-handbook you earlier referenced
probably should.


> Otherwise we're all just clicking around desperate for anything that
> says "simple-cdd" on it.

I do take issue with your previous assertions that READMEs aren't
generally useful in Debian. I typically first look at the --help output
of a program, the manpage, and then whatever I can find in
/usr/share/doc/PACKAGE... and I daresay I find this to be quite
productive approach.


>>> Great idea!  Are you aware that the README does not mention
>>> "debconf-get-selections" once?  So it would take someone who does this
>>> every day to think of this excellent solution.  Thank you for sharing
>>> this.  I recommend adding it to the README, maybe the HowTo..
>>
>> This could perhaps be briefly touched on in the simple-cdd README, and
>> referencing relevent chapters of the debian-installer manual.
>
> It probably belongs in the same section that the first item does about
> debconf templates.  In a section about how to create a useful preseed
> file.

Thanks.


>> If you load the preseeding after the question has already been asked,
>> then at best, it doesn't magically travel through time an un-ask the
>> question... at best, it does nothing, at worst, it might trigger bugs.
>
> That makes sense but it does not relate to anything clear about how
> NAME.preseed works, how --preseed works, and how --auto-preseed works.
> Please, I've asked this every way that is possible.  Please document
> this interplay.

There are no --preseed or --auto-preseed options for simple-cdd; I
presume you're referring to --profiles and --auto-profiles.

I've tried to explain over and over again how they behave, and I'm still
unsure what would be documentation that would work for you on this
point, so I am apparently every bit at a loss as you are, unfortunately.

Let's come back to that once I've had a chance to troubleshoot the
locale/country/keyboard selection issues; expected behavior is a bit
difficult to demonstrate if there are bugs affecting exactly that
behavior.


>> an't know for sure, but sounds like it *might* be a bug in the code.
>>
>> If you could re-try with "simple-cdd --locale=en_CH --keyboard=us" with
>> an empty ./profiles directory and empty ./images directory (you can
>> probably leave ./tmp, since it sounds like you don't have much
>> bandwidth), that would be great.
>
> I did this, moved profiles/ and deleted images/.  The new image was
> generated in seconds which makes me wonder if I was really doing what
> you want.

Thanks for testing.

It shouldn't take long when you have all or most of the packages already
in the local mirror under ./tmp, so it does not surprise me that the
build went quickly.


> Anyway, the result is the same.  I am asked what installer to use, I
> choose regular "Install" and

The bootloader prompting you (e.g. where you had to choose "Install") is
handled by something else entirely. The "test" profile included as part
of simple-cdd sets the BOOT_TIMEOUT debian-cd option in order to handle
this.


> my first question is what language to use.

Ok, I'll attempt to reproduce the issue locally and debug it.


> One difference is you wrote "simple-cdd --locale=en_CH --keyboard=us"
> but I used "build-simple-cdd --locale=en_CH --keyboard=us" and I think
> that was just a typo right?  Anyway I also did it your way and the
> result was the same.

It should make no difference, simple-cdd and build-simple-cdd are
symlinks to the same file.


> So it's looking like a 

Bug#956501: console-setup: keyboard layout in /etc/default/keyboard is not set correctly on startup

[Celejar]

On Sun, 12 Apr 2020 00:31:29 -0400 Celejar  wrote:
> Package: console-setup
> Version: 1.195
> Severity: normal
> 
> Hi,
> 
> I'm not sure if this is a problem with console-setup or
> keyboard-configuration.
> 
> ~$ cat /etc/default/keyboard 
> # KEYBOARD CONFIGURATION FILE
> 
> # Consult the keyboard(5) manual page.
> 
> XKBMODEL="pc105"
> XKBLAYOUT="us,il"
> XKBVARIANT="dvorak,"
> XKBOPTIONS="terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps"
> 
> BACKSPACE="guess"
> 
> Until recently, these settings were all correctly set on system startup,
> but the keyboard layout settings are currently not set correctly on
> startup:
> 
> ~$ setxkbmap -query
> rules:  evdev
> model:  pc105
> layout: us
> variant:dvorak
> options:terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps

Additionally: I checked /var/log/Xorg.0.log (attached), and it claims
that the options are indeed set correctly. But the fact is that they
are not, as per the above "setxkbmap -query" command.

Celejar

Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package

[Lev Lamberov]

Hi Jan,

Чт 30 апр 2020 @ 15:33 Jan Wielemaker :

> On 4/30/20 3:10 PM, Lev Lamberov wrote:
>  > Recently I was (again!) approached by some embedded developers who asked
>  > to provide Core_system as a separate package and try to break
>  > swi-prolog-nox into several smaller packages.
>  >
>  > Currently, I'm thinking about breaking it into swi-prolog-core
>  > (containing Core_system), swi-prolog-core-packages (containing
>  > Core_packagse; depends on swi-prolog-core) and swi-prolog-nox
>  > (containing other components from the original swi-prolog-nox; depends
>  > on swi-prolog-core and swi-prolog-core-packages). What do you think
>  > about it?
>
> As long as swi-prolog-nox still provides a useable Prolog system I'm
> happy. I would go with Jonas in that case though and have yet another
> basic package that just contains the shared object and possibly the main
> executable and boot file (swipl.prc)
>
> Just the shared object is enough to create runtimes when using
> --stand-alone as this creates a file that starts with the swipl
> executable. Adding the swipl executable to the base package allows to
> start the state with some option and makes the state smaller (but not
> much, `swipl` is really short). Adding the boot.prc file adds only 90Kb
> and actually allows running Prolog. Without libraries, but you could
> distribute the essentials with some application as .pl or .qlf files.
>
> If we rethink from the start, my ideal is that "swi-prolog" creates a
> pretty much complete installation, including xpce (gui, ide). Yes, there
> are quit a few dependencies, but virtually every desktop installation
> has most of these installed anyway.
>
> Then we can have some hierarchy below that. Some parts are clear, but
> the real dependencies between the various packages is largely unknown
> and easily varies between versions. If you are interested I could come
> up with some meaningful splits.
>
> Bottom line should be just the real core (as above), which is enough to
> run saved states.  You than have two options for saved states relying
> on foreign packages: include the package in the saved state or install
> the package.

So, my proposal is to have to following packages:

1. swi-prolog-core (with Core_system)

2. swi-prolog-core-packages (with Core_packages), depends on
swi-prolog-core

3. swi-prolog-nox (original swi-prolog-nox, but without
swi-prolog-{core,core-packages}), depends on
swi-prolog-{core,core-packages}

4. swi-prolog-x (without changes at the moment)

5. swi-prolog-java (without changes at the moment)

6. swi-prolog-bdb (without changes at the moment)

7. swi-prolog-odbc (without changes at the moment)

8. swi-prolog-doc (without changes at the moment)

9. swi-prolog-test (without changes at the moment)

10. swi-prolog, depends on swi-prolog-{nox,x} as we have now

11. swi-prolog-full, depends on swi-prolog and
swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
except swi-prolog-test)

Later we can break swi-prolog-nox into smaller parts, but I don't think
it is necessary to do this now. I'd prefer not to hurry with these
changes, let's have it as a goal for the next Debian release.

Another thing mentioned by Jonas is that swi-prolog-nox depends on -dev
packages (libedit-dev, libgmp-dev, libncurses-dev, libreadline-dev).
These are development libraries, that is they contain header files to
link against these libraries. This requires installing some other
development packages. Moreover, sometimes development packages are
somewhat large (say, installed size of libgmp10 is 579 KB, but installed
size of libgmp-dev is 1952 KB). So, one of the arguments of breaking
swi-prolog packages into smaller parts is that it will make possible to
install only what is needed also in terms of development packages.

Cheers!
Lev

Bug#959191: release-notes: mention configuration file split in logrotate

[Christian Göttsche]

Package: release-notes

With version 3.14.0 [1] logrotate split the configuration for btmp and
wtmp into separate configuration files.
There are bug reports regarding this issue: #945932, #928516, #922045.

Over at #946779 Julien suggested adding a section (5.3.10 ?).

Maybe the section can be like the following:

   The shipped configurations for "/var/log/btmp" and "/var/log/wtmp" have
   been split from the main configuration file (/etc/logrotate.conf) into
   separate standalone files (/etc/logrotate.d/btmp respectively
   /etc/logrotate.d/wtmp).

   If you had modified /etc/logrotate.conf in this regard, make sure
   to re-adjust the two new files to your needs and drop any references to
   (b|w)tmp from the main file, to avoid logrotate skip rotation due to a
   duplicate definition.


Best regards,
   Christian Göttsche

[1]: 
https://github.com/logrotate/logrotate/blob/master/ChangeLog.md#3140---2018-03-09

Bug#959192: iproute2: whitespace at EOL in CLI tool output

[Thorsten Glaser]

Package: iproute2
Version: 5.6.0-1
Severity: minor
Tags: upstream

tglase@tglase-nb:~ $ ip a | grep -c ' $'
5
tglase@tglase-nb:~ $ ip r | grep -c ' $'
13

Both should be 0. I didn’t test the other subcommands and tools.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/2 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 /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libbsd00.10.0-1
ii  libc6  2.30-4
ii  libcap21:2.33-1
ii  libcap2-bin1:2.33-1
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libelf10.176-1.1
ii  libmnl01.0.4-3
ii  libselinux13.0-1+b3
ii  libxtables12   1.8.4-3

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- debconf information:
* iproute2/setcaps: false

Bug#959178: RFS: eject/2.1.5+deb1+cvs20081104-15 [ITA] -- ejects CDs and operates CD-Changers under Linux

[atzlinux]

在 2020/4/30 下午9:20, Adam Borowski 写道:
> On Thu, Apr 30, 2020 at 08:42:07PM +0800, atzlinux wrote:
>> * Package name : eject
>> Version : 2.1.5+deb1+cvs20081104-15
> Somehow, initial whitespace in your mail is corrupted.

I am use thunderbird ,xfce. The RFS email  is sended by click "Send the
filled out template below by mail
"
link under Firefox on:

https://mentors.debian.net/sponsors/rfs-howto/eject

I also didn't know why "initial whitespace" is corrupted. Perhaps is
relations to the locale setting,I use locale LANG=zh_CN.utf8.

>> Changes since the last upload:
>>
>> [ 肖盛文 ]
>> * d/control:
>> Bumped Standards-Version to 4.5.0
>> add Build-Depends: debhelper (>= 12)
>> delete lintian useless-autoreconf-build-depends: autotools-dev
>> +Rules-Requires-Root: no
>> * Fixs lintian:
>> unused-file-paragraph-in-dep5-copyright
>> wildcard-matches-nothing-in-dep5-copyright
>> executable-in-usr-lib usr/lib/eject/dmcrypt-get-device
>> * delete the outdated watch url
>> * add debian/manpages
>> * add debian/install
>> * add debian/eject-udeb.install
>> * d/rules:
>> use install files
>> use manpages
>> deleted no use deb_dir udeb_dir env variables
>> add dh_dwz for udeb packages
>> * New maintainer (Closes: #92)
> Alas, it fails to build for me:
>
> dh_dwz -Xdebian/eject-udeb/usr/bin/eject
> dh_dwz -Xdebian/eject-udeb/usr/bin/volname
> dwz: debian/eject/usr/bin/eject: .gnu_debugaltlink section already present
> dwz: debian/eject/usr/bin/volname: .gnu_debugaltlink section already present
> dwz: debian/eject/usr/lib/eject/dmcrypt-get-device: .gnu_debugaltlink section 
> already present
> dwz: Too few files for multifile optimization
> dh_dwz: error: dwz 
> 

Bug#958502: Bug#959188: gnome-terminal: SHELL env variable honored only for first tab not for subsequent open tabs in the same window

[Simon McVittie]

Control: tags -1 upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253

On Thu, 30 Apr 2020 at 15:44:28 +0100, tglman wrote:
> When running gnome terminal with a environment variable SHELL this is honored
> only at the first tab, not of subsequent tabs

This is a more specific instance of #958502. It isn't clear what the
intended behaviour is: there are several conflicting requirements.

On one hand, there's a reasonable expectation that creating a new
window/tab should do exactly the same thing as launching a new instance
of gnome-terminal (for example from GNOME Shell), without any special
environment other than whatever was inherited from the session.

On the other hand, users of applications that are not single-instance
expect that running gnome-terminal will copy the environment from its
parent process, not just for the first window/tab but for all subsequent
windows/tabs. But that causes a different inconsistency: if you launch
gnome-terminal from an xterm with SHELL=fish, and launch it from a
different xterm with SHELL=bash, then create a new window with
Ctrl+Shift+N, is that new window's shell fish or bash? It can't be both.
If the behaviour is first-run-wins (or last-run-wins), then you'll get
weird environment variables "leaking" into all your gnome-terminals
if the first (or last) gnome-terminal launch happens to have had that
weird environment.

See also https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253,
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/236 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954652.

I don't think Debian is going to diverge from upstream on this; whatever
reasonable conclusion they come to about how gnome-terminal is meant to
work, we shouldn't arbitrarily change that.

smcv

Bug#959189: bbswitch-dkms: fails to build for kernel 5.6.7

[Luca Boccassi]

On Thu, 2020-04-30 at 17:14 +0200, Andreas Beckmann wrote:
> Control: severity -1 serious
> 
> On 30/04/2020 16.54, Giacomo Mulas wrote:
> > ./include/linux/proc_fs.h:64:24: note: expected ‘const struct proc_ops *’ 
> > but argument is of type ‘struct file_operations *’
> 
> OK, another one of these ... I'll take care of it.
> 
> 
> Andreas

Hi,

Note there's https://github.com/Bumblebee-Project/bbswitch/pull/196

Not merged yet, and I have not tested it.



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

Bug#959189: bbswitch-dkms: fails to build for kernel 5.6.7

[Andreas Beckmann]

Control: severity -1 serious

On 30/04/2020 16.54, Giacomo Mulas wrote:
> ./include/linux/proc_fs.h:64:24: note: expected ‘const struct proc_ops *’ but 
> argument is of type ‘struct file_operations *’

OK, another one of these ... I'll take care of it.


Andreas

Bug#959190: gssproxy: Log flooded by gssproxy

[Vincent Danjean]

Package: gssproxy
Version: 0.8.0-1.1
Severity: important

  Hi,

  On a system with kerberos (AD with sssd) and NFS mount,
some applications (long bioinfo applications with data on
the NFS partition) generate lots of logs that fill the
root (or /var/log/) partition.
  To have an idea, in less than 24h, more that 5GB of
logs have been generated. There are all similar to:

Apr 30 14:31:24 ge95142-vm1 gssproxy[6880]: gssproxy[6888]: (OID: { 1 2 840 
113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, No credentials cache found
[and 300 similar lines for the same *second*]

And I find them tree times: they are logged into
/var/log/syslog, /var/log/daemon.log and /var/log/auth.log.


  You should really provide a way to either limit the
rate of the logs and/or provide an way to avoid logs
(I do not find any).

  Regards,
Vincent


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

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3
ii  libgssrpc41.17-3
ii  libini-config50.6.1-2
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  libpopt0  1.16-12
ii  libref-array1 0.6.1-2
ii  libselinux1   2.8-1+b1
ii  libverto1 0.3.0-2

gssproxy recommends no packages.

gssproxy suggests no packages.

-- Configuration Files:
/etc/gssproxy/99-nfs-client.conf changed:
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0


-- no debconf information

Bug#959188: gnome-terminal: SHELL env variable honored only for first tab not for subsequent open tabs in the same window

[tglman]

Package: gnome-terminal
Version: 3.36.1.1-3
Severity: normal

Dear Maintainer,

When running gnome terminal with a environment variable SHELL this is honored
only at the first tab, not of subsequent tabs

example running

env SHELL=/usr/bin/fish gnome-terminal

will open a window with the fish shell, but then opening a new tab in that
window will use the system default shell.

Thank you



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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.36.0-1
ii  gnome-terminal-data   3.36.1.1-3
ii  gsettings-desktop-schemas 3.36.0-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-4
ii  libdconf1 0.36.0-1
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.18-1
ii  libpango-1.0-01.44.7-4
ii  libuuid1  2.34-0.1
ii  libvte-2.91-0 0.60.1-1
ii  libx11-6  2:1.6.9-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.44.1-1
ii  nautilus-extension-gnome-terminal  3.36.1.1-3
ii  yelp   3.36.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#959187: RFP: ooni-probe-cli -- OONI Probe Command Line Interface

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: ooni-probe-cli
  Version : 3.0.0-rc.14
  Upstream Author : Arturo Filastò
* URL : https://github.com/ooni/probe-cli/
* License : BSD-3-clause
  Programming Lang: Golang
  Description : OONI Probe Command Line Interface

power-user interface to the OONI probe system. The Open Observatory of
Network Interference (OONI) is a free software project that aims to
empower decentralized efforts in increasing transparency of Internet
censorship around the world.

Bug#744073: New maintainer needs an update

[Graham Inggs]

Hi Julien

On Thu, 30 Apr 2020 at 10:03, Julien Puydt  wrote:
> I have been the most active maintainer of scilab in Debian recently,
> and I'm reviewing old bugs : is ubuntu still having issues with the
> scilab packaging in Debian?

Looking at Ubuntu's publishing history for scilab [1], it seems these
issues were fixed upstream and included in 5.5.0-1.

Regards
Graham


[1] https://launchpad.net/ubuntu/+source/scilab/+publishinghistory

Bug#959189: bbswitch-dkms: fails to build for kernel 5.6.7

[Giacomo Mulas]

Package: bbswitch-dkms
Version: 0.8-8
Severity: important

Dear Maintainer,

with the recent release on sid of the new linux kernel 5.6.7, I stumbled on
a problem with the bbswitch module, which fails to build with the following
error message:

make[1]: ingresso nella directory "/usr/src/linux-source-5.6.7.1"
  CC [M]  /var/lib/dkms/bbswitch/0.8/build/bbswitch.o
/var/lib/dkms/bbswitch/0.8/build/bbswitch.c: In function ‘bbswitch_init’:
/var/lib/dkms/bbswitch/0.8/build/bbswitch.c:460:63: error: passing argument 4 
of ‘proc_create’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  460 | acpi_entry = proc_create("bbswitch", 0664, acpi_root_dir, 
_fops);
  |   
^~
  |   |
  |   struct 
file_operations *
In file included from ./include/acpi/acpi_bus.h:83,
 from ./include/linux/acpi.h:32,
 from /var/lib/dkms/bbswitch/0.8/build/bbswitch.c:32:
./include/linux/proc_fs.h:64:24: note: expected ‘const struct proc_ops *’ but 
argument is of type ‘struct file_operations *’
   64 | struct proc_dir_entry *proc_create(const char *name, umode_t mode, 
struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
  |^~~

Apparently some structures changed in the new kernel, making it incompatible
with bbswitch.

Of course, it still builds and works on 5.5.x and older kernels, but still,
since 5.6.x is now the default on sid I think this should be tagged important.

Thanks in advance, best regards
Giacomo Mulas

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

Kernel: Linux 5.5.17-jak (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set 
to it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bbswitch-dkms depends on:
ii  dkms  2.8.1-5

bbswitch-dkms recommends no packages.

Versions of packages bbswitch-dkms suggests:
ii  bumblebee  3.2.1-22

-- no debconf information

Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[Vincent Danjean]

Package: gssproxy
Version: 0.8.0-1.1
Severity: normal

  Hi,

  The default configuration file looks for kerberos credentials
in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
are in ccache:FILE:/tmp/krb5cc_%U
  Is this configuration intended? Why? I had to change it, I found
the solution on several internet forum where it said that this is
an error in the default configuration. I'm not sure if this is the
case (an error) or if the default configuration file targets another
usage.

  Regards
Vincent

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

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3
ii  libgssrpc41.17-3
ii  libini-config50.6.1-2
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  libpopt0  1.16-12
ii  libref-array1 0.6.1-2
ii  libselinux1   2.8-1+b1
ii  libverto1 0.3.0-2

gssproxy recommends no packages.

gssproxy suggests no packages.

-- Configuration Files:
/etc/gssproxy/99-nfs-client.conf changed:
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0


-- no debconf information

Bug#524758: bogofilter: Bogofilter crashes on some mails

[Matthias Andree]

tags 524758 -moreinfo
tags 524758 +confirmed +upstream +fixed-upstream
thanks

I think upstream Git commit 8eaeb85c should fix this.
To appear in the next release after 1.2.5 (which has already been released).

If it does not, please recompile bogofilter with debug log,
provide your test message, your database, your configuration,
the command line, and a backtrace.

Bug#959185: Ubuntu only additions

[Gunnar Hjalmarsson]

This is the merge request:

https://salsa.debian.org/debian/ibus/-/merge_requests/9

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#956371: deal.ii: diff for NMU version 9.1.1-9.1

[Graham Inggs]

Control: tags -1 + fixed-upstream

Hi Tobias

On Wed, 29 Apr 2020 at 21:39, Tobias Frost  wrote:
> I've prepared an NMU for deal.ii (versioned as 9.1.1-9.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Mattias Maier pointed out this is already fixed upstream [1] in the same way.

If I'm not mistaken, you are already a member of science-team on salsa.
Please go ahead with a team upload.

Regards
Graham


[1] 
https://github.com/dealii/dealii/commit/adb1281b842d5bd9c89e0483e25e5922ed08fdef

Bug#959137: lasagne: (autopkgtest) needs update for new version of numpy: 'numpy.float64' object cannot be interpreted as an integer

[Stephen Sinclair]

The package has been updated in salsa and is awaiting sponsorship.

regards,
Steve

On Wed, Apr 29, 2020 at 9:48 PM Paul Gevers  wrote:
>
> Source: lasagne
> Version: 0.1+git20181019.a61b76f-2
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org, nu...@packages.debian.org
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:numpy
>
> Dear maintainer(s),
>
> With a recent upload of numpy the autopkgtest of lasagne fails in
> testing when that autopkgtest is run with the binary packages of numpy
> from unstable. It passes when run with only packages from testing. In
> tabular form:
>
>passfail
> numpy  from testing1:1.18.3-1
> lasagnefrom testing0.1+git20181019.a61b76f-2
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration of numpy to testing
> [1]. Of course, numpy shouldn't just break your autopkgtest (or even
> worse, your package), but it seems to me that the change in numpy was
> intended and your package needs to update to the new situation.
>
> If this is a real problem in your package (and not only in your
> autopkgtest), the right binary package(s) from numpy should really add a
> versioned Breaks on the unfixed version of (one of your) package(s).
> Note: the Breaks is nice even if the issue is only in the autopkgtest as
> it helps the migration software to figure out the right versions to
> combine in the tests.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=numpy
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/lasagne/5197094/log.gz
>
> === FAILURES
> ===
> 
> TestTPSTransformLayer.test_transform_thin_plate_spline_variable_input _
>
> start = -1, stop = 1, num = 4.0, endpoint = True, retstep = False, dtype
> = None
> axis = 0
>
> @array_function_dispatch(_linspace_dispatcher)
> def linspace(start, stop, num=50, endpoint=True, retstep=False,
> dtype=None,
>  axis=0):
> """
> Return evenly spaced numbers over a specified interval.
>
> Returns `num` evenly spaced samples, calculated over the
> interval [`start`, `stop`].
>
> The endpoint of the interval can optionally be excluded.
>
> .. versionchanged:: 1.16.0
> Non-scalar `start` and `stop` are now supported.
>
> Parameters
> --
> start : array_like
> The starting value of the sequence.
> stop : array_like
> The end value of the sequence, unless `endpoint` is set to
> False.
> In that case, the sequence consists of all but the last of
> ``num + 1``
> evenly spaced samples, so that `stop` is excluded.  Note
> that the step
> size changes when `endpoint` is False.
> num : int, optional
> Number of samples to generate. Default is 50. Must be
> non-negative.
> endpoint : bool, optional
> If True, `stop` is the last sample. Otherwise, it is not
> included.
> Default is True.
> retstep : bool, optional
> If True, return (`samples`, `step`), where `step` is the spacing
> between samples.
> dtype : dtype, optional
> The type of the output array.  If `dtype` is not given,
> infer the data
> type from the other input arguments.
>
> .. versionadded:: 1.9.0
>
> axis : int, optional
> The axis in the result to store the samples.  Relevant only
> if start
> or stop are array-like.  By default (0), the samples will be
> along a
> new axis inserted at the beginning. Use -1 to get an axis at
> the end.
>
> .. versionadded:: 1.16.0
>
> Returns
> ---
> samples : ndarray
> There are `num` equally spaced samples in the closed interval
> ``[start, stop]`` or the half-open interval ``[start, stop)``
> (depending on whether `endpoint` is True or False).
> step : float, optional
> Only returned if `retstep` is True
>
> Size of spacing between samples.
>
>
> See Also
> 
> arange : Similar to `linspace`, but uses a step size (instead of the
>  number of samples).
> geomspace : Similar to `linspace`, but with numbers spaced
> evenly on a log
> scale (a geometric progression).
> logspace : Similar to `geomspace`, but with the end points
> specified as
>logarithms.
>
> Examples
> 
> >>> 

Bug#524758: bogofilter: Bogofilter crashes on some mails

[Matthias Andree]

Tags: +confirmed -moreinfo
Found: 1.2.4+dfsg1-13
Found: 1.2.4+dfsg1-9

One simple way to reproduce this appears to be running this without
pre-existing wordlist.db:

echo $'\ngood' | bogofilter -n
echo $'\ngood' | bogofilter -Rv

I am adding a related "make check" test upstream as
bogofilter/src/tests/t.debian-bug-524758.