Bug#962131: sqlite3 breaks python3.8 autopkgtest: CheckFuncDeterministic (sqlite3.test.userfunctions.FunctionTests)

[GCS]

Control: notfound -1 sqlite3/3.32.1-2
Control: retitle -1 bad SQLite deterministic check in self-tests

On Wed, Jun 3, 2020 at 5:09 PM Paul Gevers  wrote:
> With a recent upload of sqlite3 the autopkgtest of python3.8 fails in
> testing when that autopkgtest is run with the binary packages of sqlite3
> from unstable.
[...]
> Currently this regression is blocking the migration of sqlite3 to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
 Some background information. In SQLite you can tag functions as
deterministic, meaning it will always give back the same result on the
same input values. Python 3.8+ test it with: 'select deterministic() =
deterministic()' and think it will be called once as its assert is the
following: 'self.assertEqual(mock.call_count, 1)'. This is wrong, as
deterministic doesn't mean it will be called once for the left side of
the equality then filled out on the right side just because it's the
same function call. The query planner can and will call it again since
SQLite version 3.15.0, as you could see the called number is 2 in the
build failure.
That means it's a bad SQLite check implementation in Python 3.8+ which
was already reported to them as Issue 40784 [1]. They fixed it on
their Git master branch and of course backported for the 3.8 release
of Python [2]. Tested to be sure and it fixes the issue. Hopefully
Matthias will add it to its packaging soon.

Regards,
Laszlo/GCS
[1] https://bugs.python.org/issue40784
[2] 
https://github.com/python/cpython/commit/c610d970f5373b143bf5f5900d4645e6a90fb460

Bug#962084: Adding buster-backport to apt sources on install seems wrong

[Christian Ehrhardt]

On Thu, Jun 4, 2020 at 1:29 AM Sunil Mohan Adapa  wrote:

> On 03/06/20 12:35 am, Christian Ehrhardt wrote:
>


> We are planning to restrict selection of backports to Debian. A fix
> should be available soon[1]].


Thanks, LGTM

Pinning of packages should not effect
> non-Debian distributions.


Yes, as I said as well


>
> Beyond that we are also planning to make the selection of backports an
> explicit step in the user interface (restricted to Debian)[2].
>

good to know.


And ack on lowering severity. It was mostly based on recommendation by
other DDs in a quick IRC discussion.
But now that it is actively handled it should be fine soon anyway.

Bug#959848: python-pysnmp4-apps: diff for NMU version 0.3.2-2.2

[Adrian Bunk]

Control: tags 959848 + patch
Control: tags 959848 + pending

Dear maintainer,

I've prepared an NMU for python-pysnmp4-apps (versioned as 0.3.2-2.2) 
and uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru python-pysnmp4-apps-0.3.2/debian/changelog python-pysnmp4-apps-0.3.2/debian/changelog
--- python-pysnmp4-apps-0.3.2/debian/changelog	2020-04-05 06:49:55.0 +0300
+++ python-pysnmp4-apps-0.3.2/debian/changelog	2020-06-04 08:29:02.0 +0300
@@ -1,3 +1,11 @@
+python-pysnmp4-apps (0.3.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * python3-pysnmp4-apps: Breaks+Replaces: python-pysnmp4-apps
+(Closes: #959848)
+
+ -- Adrian Bunk   Thu, 04 Jun 2020 08:29:02 +0300
+
 python-pysnmp4-apps (0.3.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-pysnmp4-apps-0.3.2/debian/control python-pysnmp4-apps-0.3.2/debian/control
--- python-pysnmp4-apps-0.3.2/debian/control	2020-04-05 06:39:58.0 +0300
+++ python-pysnmp4-apps-0.3.2/debian/control	2020-06-04 08:29:00.0 +0300
@@ -16,6 +16,8 @@
 Package: python3-pysnmp4-apps
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
+Breaks: python-pysnmp4-apps
+Replaces: python-pysnmp4-apps
 Suggests: python3-pysnmp4-mibs
 Description: Applications for the Python SNMP library
  This package contains a set of SNMP applications written on top of

Bug#962084: Adding buster-backport to apt sources on install seems wrong

[Sunil Mohan Adapa]

severity 962084 important
thanks

FreedomBox does not ship the sources file or install it during post
installation phase. It only sets up the file during system configuration
step when first executed. This is similar to how it enables automatic
upgrades, enables a firewall etc. This to my understanding is not a
violation of Debian policy. I am reducing the severity accordingly.

This should allow FreedomBox to migrate to testing bringing unrelated
important fixes.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#962165: isc-dhcp-relay: dhcrelay is listening on all network interfaces instead of specified one

[Aladdin]

Package: isc-dhcp-relay
Version: 4.4.1-2
Severity: normal

Dear Maintainer,

Just installed isc-dhcp-relay package on my Buster and noticed one
interesting thing:

/usr/sbin/dhcrelay -d -i eth0 10.10.10.10
Requesting: eth0 as upstream: Y downstream: Y
Internet Systems Consortium DHCP Relay Agent 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/vnet0/
Sending on   LPF/vnet0/
Listening on LPF/lan1vbr/
Sending on   LPF/lan1vbr/
Listening on LPF/lan1vbr-fake/
Sending on   LPF/lan1vbr-fake/
Listening on LPF/dmz1vbr/
Sending on   LPF/dmz1vbr/
Listening on LPF/dmz1vbr-fake/
Sending on   LPF/dmz1vbr-fake/
Listening on LPF/eth0/
Sending on   LPF/eth0/
Sending on   Socket/fallback

As you can see, relay agent is listening on all of my interfaces:/ Why is
that? It seems that because of that I get plenty of the following messages:

dhcrelay[4114]: Discarding packet received on vnet0 interface that has no
IPv4 address assigned.

Is it possible to fix such behavior?

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

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

Versions of packages isc-dhcp-relay depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  debianutils4.8.6.1
ii  libc6  2.28-10
ii  libdns-export1104  1:9.11.5.P4+dfsg-5.1+deb10u1
ii  libirs-export161   1:9.11.5.P4+dfsg-5.1+deb10u1
ii  libisc-export1100  1:9.11.5.P4+dfsg-5.1+deb10u1
ii  lsb-base   10.2019051400

Versions of packages isc-dhcp-relay recommends:
ii  isc-dhcp-common  4.4.1-2

isc-dhcp-relay suggests no packages.

-- debconf information excluded

Bug#904590: Fix applied in new version

[Todd Andrews]

Hey Emmanuel, thanks for including me on the notification list. I'm not
seeing the Windows binary available yet at https://www.open-tickr.net/ but
I figure it might be a few days before it appears there. I'm not in a rush so
I'll keep checking.

On Tue, Jun 2, 2020 at 1:27 AM Emmanuel Thomas-Maurin 
wrote:

> Hi,
>
> Tickr last version (0.7.0-1) implements full HTTPS support. I'm waiting
> for my Debian mentor to check it and (if everything is OK) upload it to
> unstable.
>
> --
> Emmanuel Thomas-Maurin
>

Bug#962164: package-update-indicator FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: package-update-indicator
Version: 5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

package-update-indicator fails to cross build from source, because
debian/rules does not pass cross tools to make. The easiest way of doing
so - using dh_auto_build - does not entirely fix the build. For one
thing, the upstream Makefile hard codes the build architecture
pkg-config. For another, it stuffs a compiler flag into the CC variable,
which gets overridden by dh_auto_build. The flag should be moved to
CFLAGS. Please consider applying the attached patch.

Helmut
diff --minimal -Nru package-update-indicator-5/debian/changelog 
package-update-indicator-5/debian/changelog
--- package-update-indicator-5/debian/changelog 2020-02-20 22:34:28.0 
+0100
+++ package-update-indicator-5/debian/changelog 2020-06-04 06:39:22.0 
+0200
@@ -1,3 +1,13 @@
+package-update-indicator (5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Don't stuff compiler flags into CC.
++ Make pkg-config substitutable.
+
+ -- Helmut Grohne   Thu, 04 Jun 2020 06:39:22 +0200
+
 package-update-indicator (5-1) unstable; urgency=medium
 
   * New upstream version: 5
diff --minimal -Nru package-update-indicator-5/debian/patches/cross.patch 
package-update-indicator-5/debian/patches/cross.patch
--- package-update-indicator-5/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ package-update-indicator-5/debian/patches/cross.patch   2020-06-04 
06:39:12.0 +0200
@@ -0,0 +1,61 @@
+--- package-update-indicator-5.orig/Makefile
 package-update-indicator-5/Makefile
+@@ -30,7 +30,7 @@
+ BUG_ADDRESS = guido+...@berhoerster.name
+ 
+ # gcc, clang, icc, Sun/Solaris Studio
+-CC := $(CC) -std=c99
++CFLAGS += -std=c99
+ COMPILE.c =   $(CC) $(CFLAGS) $(XCFLAGS) $(CPPFLAGS) $(XCPPFLAGS) 
$(TARGET_ARCH) -c
+ # gcc, clang, icc
+ MAKEDEPEND.c =$(CC) -MM $(CFLAGS) $(XCFLAGS) $(CPPFLAGS) $(XCPPFLAGS)
+@@ -48,9 +48,10 @@
+ PAX :=pax
+ GZIP :=   gzip
+ SED :=sed
+-GLIB_COMPILE_SCHEMAS := $(shell pkg-config --variable=glib_compile_schemas 
gio-2.0)
+-GLIB_COMPILE_RESOURCES := $(shell pkg-config 
--variable=glib_compile_resources gio-2.0)
+-GLIB_MKENUMS :=   $(shell pkg-config --variable=glib_mkenums glib-2.0)
++PKG_CONFIG ?= pkg-config
++GLIB_COMPILE_SCHEMAS := $(shell $(PKG_CONFIG) --variable=glib_compile_schemas 
gio-2.0)
++GLIB_COMPILE_RESOURCES := $(shell $(PKG_CONFIG) 
--variable=glib_compile_resources gio-2.0)
++GLIB_MKENUMS :=   $(shell $(PKG_CONFIG) --variable=glib_mkenums glib-2.0)
+ XSLTPROC :=   xsltproc
+ DOCBOOK5_MANPAGES_STYLESHEET = 
http://docbook.sourceforge.net/release/xsl-ns/current/manpages/docbook.xsl
+ DOCBOOK5_MANPAGES_FLAGS = --stringparam man.authors.section.enabled 0 \
+@@ -71,9 +72,9 @@
+   --keyword=g_dngettext:2,3 \
+   --add-comments
+ INDICATOR_LIB := $(or \
+-  $(shell pkg-config --exists appindicator3-0.1 && \
++  $(shell $(PKG_CONFIG) --exists appindicator3-0.1 && \
+   printf '%s\\\n' appindicator3-0.1), \
+-  $(shell pkg-config --exists ayatana-appindicator3-0.1 && \
++  $(shell $(PKG_CONFIG) --exists ayatana-appindicator3-0.1 && 
\
+   printf '%s\\\n' ayatana-appindicator3-0.1), \
+   appindicator3-0.1)
+ INDICATOR_FLAG := $(if $(findstring ayatana,$(INDICATOR_LIB)), \
+@@ -160,10 +161,10 @@
+   -DSETTINGS_SCHEMA_ID=\"$(APPLICATION_ID)\" \
+   -DI_KNOW_THE_PACKAGEKIT_GLIB2_API_IS_SUBJECT_TO_CHANGE \
+   $(INDICATOR_FLAG)
+-$(PACKAGE): XCFLAGS = $(shell pkg-config --cflags gtk+-3.0 \
++$(PACKAGE): XCFLAGS = $(shell $(PKG_CONFIG) --cflags gtk+-3.0 \
+   $(INDICATOR_LIB) packagekit-glib2 \
+   polkit-gobject-1 upower-glib)
+-$(PACKAGE): LDLIBS =  $(shell pkg-config --libs gtk+-3.0 \
++$(PACKAGE): LDLIBS =  $(shell $(PKG_CONFIG) --libs gtk+-3.0 \
+   $(INDICATOR_LIB) packagekit-glib2 \
+   polkit-gobject-1 upower-glib)
+ 
+@@ -174,8 +175,8 @@
+   -DPACKAGE_LOCALE_DIR="\"$(localedir)\"" \
+   -DGETTEXT_PACKAGE=\"$(PACKAGE)\" \
+   -DSETTINGS_SCHEMA_ID=\"$(APPLICATION_ID)\"
+-$(PACKAGE)-prefs: XCFLAGS = $(shell pkg-config --cflags gtk+-3.0)
+-$(PACKAGE)-prefs: LDLIBS = $(shell pkg-config --libs gtk+-3.0)
++$(PACKAGE)-prefs: XCFLAGS = $(shell $(PKG_CONFIG) --cflags gtk+-3.0)
++$(PACKAGE)-prefs: LDLIBS = $(shell $(PKG_CONFIG) --libs gtk+-3.0)
+ 
+ ifneq ($(findstring $(OS_NAME),FreeBSD DragonFly OpenBSD),)
+   $(PACKAGE): XCPPFLAGS +=-I/usr/local/include
diff --minimal -Nru package-update-indicator-5/debian/patches/series 

Bug#962163: cxref FTCBFS: uses AC_TRY_COMPILE

[Helmut Grohne]

Source: cxref
Version: 1.6e-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cxref fails to cross build from source, because the configure script in
the cpp directory uses AC_TRY_RUN without a cross compilation
alternative. However, that particular check doesn't actually need to run
as all it tests are compile time constants. It can be turned into a
AC_TRY_COMPILE. Please consider applying the attached patch.

Helmut
--- cxref-1.6e.orig/cpp/configure.in
+++ cxref-1.6e/cpp/configure.in
@@ -44,13 +44,13 @@
 
AC_MSG_CHECKING([if installed gcc is new enough to use instead of cxref-cpp])
 
-   AC_TRY_RUN([
+   AC_TRY_COMPILE([
int main()
{
#if defined(__GNUC__) && ( ( __GNUC__==2 && __GNUC_MINOR__>=8 ) || __GNUC__>=3 )
 exit(0);
#else
-exit(1);
+#error too old
#endif
}
],

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

[Nicholas D Steeves]

Hi Alexandre,

Alexandre Lymberopoulos  writes:

> Hi Nicholas,
>
> I can perform this real-life testing, but I don't know how to get the
> package to install and test. Sorry for this naive question, but hydrogen
> is no longer available via apt(itutde), only the 0.9.7-6 installed here.
>

https://salsa.debian.org/multimedia-team/hydrogen.git
https://salsa.debian.org/multimedia-team/hydrogen

'debcheckout hydrogen' should do the trick, but then you'd still have to
build the package.

I think I've completed the preliminary conversion to debhelper, but
still need to triple check to see if I missed anything.  I haven't yet
completed the toil of combing through upstream commits to confirm that I
was correct in dropping most of the patches.  The package also needs a
copyright review.

That said, if you'd like to test a something I'd broadly call "an alpha
level release", where an upload to experimental would be "beta", here is
a link to the package in my google drive:

https://drive.google.com/drive/folders/1j506Sn2Ur1_Cue1WTJUKgYmPcQW6qZsh?usp=sharing

Of the debs you'll need libhydrogen-core-1.0.0, hydrogen-data, and of
course hydrogen.  I've provided the source package .build and .buildinfo
as well for the sake of transparency.

> Thanks for your help!
>

You're welcome :-)  'hope those patches were truly no longer necessary
and that this beta2 release is already functional.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#962162: ITP: macromoleculebuilder -- model the structure and dynamics of macromolecules

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 924251 962029

* Package name    : macromoleculebuilder
  Version : 3.0
  Upstream Author : Samuel Coulbourn Flores
* URL : https://simtk.org/projects/rnatoolbox
* License : Expat
  Programming Lang: C++
  Description : model the structure and dynamics of macromolecules

MMB can be used for morphing, homology modeling, folding (e.g. using
base pairing contacts), redesigning complexes, fitting to low-resolution
density maps, predicting local rearrangements upon mutation, and many
other applications.

I am interested in MMB as currently there seems to be no tool for
protein homology modeling in Debian. I intend to maintain this package
in DebiChem team.

Bug#962161: Please use ipxe.efi under UEFI

[Alkis Georgopoulos]

Package: win32-loader
Version: 0.10.0
Severity: important

Hi, thank you very much for the initial UEFI support!
Unfortunately, when I selected:

PXE mode: install a PXE loader to allow remote kernel loading

I didn't get ipxe.efi to be able to netboot, but it prompted me to 
download the stable or unstable debian kernel etc.


Please see this bug report and patch for grub-ipxe, to see how a 
grub.cfg can use either ipxe.lkrn or ipxe.efi dynamically:


https://salsa.debian.org/waldi/ipxe/-/merge_requests/1
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927783

So, if a user selects the PXE mode, please install both ipxe.lkrn and 
ipxe.efi, and use the grub.cfg mentioned in that bug report.


Thanks again!

Bug#962160: buster-pu: package pagekite/0.5.9.3-2

[Sunil Mohan Adapa]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This update proposes to fix bug #961984. Pagekite shipped certificates
internally which are now expired (as of 2020-05-31). All users of Pagekite are
unable to use the package securely as it can no longer make TLS connections to
frontend servers. This update makes Pagekite use Debian certificate database
instead of internal certificates (by shipping an additional configuration
file). Further information from upstream:
https://pagekite.wordpress.com/2020/05/30/tls-certificate-validation-issues/

The fix has been uploaded to unstable as part of pagekite/1.5.2.200531-1.
Source debdiff is attached. The patch has been tested as follows:

Installed and configured Pagekite on Debian Buster. In logs it shows that it is
unable to connect to the frontend server due TLS connection failures. Upgraded
to Pagkite with fix. Pagekite automatically restarts and connects properly to
the frontend server as per logs. The services on the Pagekite domain become
available after that.

This is an urgent fix that must go into stable-updates because the package
becomes unusable to most users without the fix.

Please let know if you need any more information.

Thanks,

- --
Sunil


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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl7Yb5oRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJEtRAAgQZWqu+XGN6HSgnZzoJdAhHreeHmqqNQ
S55/Du+xKopP0nx9Inup65SkdUwXCbwKqfdOMrgpvApAkMNa05abxcR9SQ8fi+ex
3kaaQm7DoC9tmlFnVe7bDyozHXbkOYoywj+bBbdTMYpQkezrSNNgZv7w14Du3wio
44acL6gqiUUPoG5wsBg664aWVtNpGKO7FQZpLN72FsTeE8XGN5seERIb/Cw6xU9m
S9/1qF5C/HajuZLkkcVPQBXDt+MGc5KS8L3PJiKqyNcxnfZ+x/WFcSfBrXDLoLVJ
Ga1ZMcs8U4gggEzSjgZTYn0oy5kWeRcAofhmTBjecRS64SUcHLM41KZHfir9Gkd+
QrZH8PMJSapzUiORA1ahhE1tvX5VYeHfLXpSts4nK8z+NTIjpuRiT86nN11vOSag
9eN6gh3INiD7RbmBGtOpTkSV6Dv33bP7YQxwIRns0YZ6d73Gocjby14d1NuUwcNQ
shgK2wXt3PwadKYaadBv2YPZIgtJDat/niVb9mMbJJl/EqUxou5vfiOqJzhdXYI0
IHjYBeSAZGJwrmUGO4IwO/SMkMViJwuODsJjVS++Ws4ba4ubeBuWfAWarxcXQwtL
Lhu6aZxTlecPUTLYghWY1jOqe67Xy9nfp6SMNt6hizy9tN9QntInzk2pbbWzi01m
oqSgncIG2A0=
=MHb2
-END PGP SIGNATURE-
diff -Nru pagekite-0.5.9.3/debian/changelog pagekite-0.5.9.3/debian/changelog
--- pagekite-0.5.9.3/debian/changelog   2018-03-30 07:54:06.0 -0700
+++ pagekite-0.5.9.3/debian/changelog   2020-06-03 18:10:32.0 -0700
@@ -1,3 +1,10 @@
+pagekite (0.5.9.3-2+deb10u1) UNRELEASED; urgency=medium
+
+  * Fix issue with expired internal certificates. Use
+Debian certificates instead of internal certificate. (Closes: #961984)
+
+ -- Sunil Mohan Adapa   Wed, 03 Jun 2020 18:10:32 -0700
+
 pagekite (0.5.9.3-2) unstable; urgency=medium
 
   [ Petter Reinholdtsen ]
diff -Nru pagekite-0.5.9.3/debian/control pagekite-0.5.9.3/debian/control
--- pagekite-0.5.9.3/debian/control 2018-03-30 07:54:06.0 -0700
+++ pagekite-0.5.9.3/debian/control 2020-06-03 18:10:32.0 -0700
@@ -23,6 +23,7 @@
 Package: pagekite
 Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}
+ , ca-certificates
  , daemon (>= 0.6)
  , python-socksipychain (>= 2.0.15)
  , python-openssl
diff -Nru pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch 
pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch
--- pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch  
1969-12-31 16:00:00.0 -0800
+++ pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch  
2020-06-03 18:10:32.0 -0700
@@ -0,0 +1,18 @@
+Description: Use Debian certificates instead of internal certificates
+ This is to make Pagekite use certificates shipped by Debian. Otherwise by
+ default, it uses internallly shipped certificates that may be outdated. See:
+ https://pagekite.wordpress.com/2020/05/30/tls-certificate-validation-issues/
+Author: Sunil Mohan Adapa 
+
+--- /dev/null
 b/etc/pagekite.d/90_debian_certs.rc
+@@ -0,0 +1,9 @@
++#
++# This is to make Pagekite use certificates shipped by Debian. Otherwise by
++# default, it uses internallly shipped certificates that may be outdated. See:
++# https://pagekite.wordpress.com/2020/05/30/tls-certificate-validation-issues/
++#
++# If you wish to override this setting, create another file starting with a
++# number higher than 90.
++#
++ca_certs = /etc/ssl/certs/ca-certificates.crt
diff -Nru pagekite-0.5.9.3/debian/patches/series 
pagekite-0.5.9.3/debian/patches/series
--- pagekite-0.5.9.3/debian/patches/series  2018-03-30 07:54:06.0 
-0700

Bug#962133: [Pkg-zsh-devel] Bug#962133: Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Daniel Shahaf]

Vincent Lefevre wrote on Wed, 03 Jun 2020 18:02 +0200:
> On 2020-06-03 17:45:11 +0200, Axel Beckert wrote:
> > Vincent Lefevre wrote:  
> > > Actually there's another one:
> > >   
> > > zira:~> dpkg -l | grep '^rc'  
> > > rc  openntpd   1:6.0p1-1  
> > >  amd64OpenBSD NTP daemon  
> > 
> > All packages shown as "rc" by dpkg on my system seem _not_ to be
> > installed but are usually removed, but not purged. Example:  
> 
> They are not installed, but are valid candidates for "dpkg -s"
> arguments.
> 
> > From the design of the current implementation (only show installed
> > packages for "dpkg -s" completion)  
> 
> Currently this is: installed and not marked to be uninstalled
> (or to be purged).
> 
> > it is correct that "dpkg -s" doesn't complete these packages.  
> 
> This is not correct.

Axel did not say that _dpkg's behaviour was correct.

Axel only said that _dpkg was behaving as designed.

Furthermore, in the snipped context Axel agreed that it would be
good to have _dpkg modified to behave as per your proposal.

> "dpkg -s" should complete to any valid
> argument, i.e. for which package information is available
> (thus this excludes purged packages). This is a real bug.

Bug#962156: josm: Could not initialize class org.openstreetmap.josm.data.cache.JCSCacheManager

[Sebastiaan Couwenberg]

fixed 962156 josm/0.0.svn16538+dfsg-3
thanks

Already reported in #962060 and fixed in -3.

Kind Regards,

Bas

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

Bug#962159: RFS: ddclient/3.9.1-1 [ITP] -- address updating utility for dynamic DNS services

[Richard Hansen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ddclient
   Version : 3.9.1-1
 * URL : https://ddclient.net
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.org/debian/ddclient
   Section : net

It builds those binary packages:

  ddclient - address updating utility for dynamic DNS services

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/ddclient/ddclient_3.9.1-1.dsc

Changes since the last upload:

   [ Martin Pitt ]
   * Drop obsolete initscripts dependency. /lib/init/vars.sh is now in the
 (required) sysvinit-utils. (Closes: #804975)
 .
   [ Christian Hofstaedtler ]
   * Bump Standards-Version to 3.9.8 (no changes required)
   * Update Vcs-Browser, Vcd-Git to use https URLs
 .
   [ Richard Hansen ]
   * Refresh patches via 'gbp pq'
   * New upstream version 3.9.0
   * Refresh patches
   * Add dependency on libdata-validate-ip-perl
   * Bump Standards-Version to 4.0.0
   * debian/copyright: Fix year
   * Switch upstream to GitHub
   * Add gbp.conf
   * Merge tag 'v3.9.0'
   * Merge tag 'v3.9.1' (Closes: #913308)
   * Refresh patches
   * Bump debhelper compat to 9 (no changes)
   * Change priority from extra to optional
   * Set shebang as required by Debian policy >= 4.1.2
   * Install RELEASENOTE as NEWS.gz
   * Use dh to build
   * Remove irrelevant examples
   * Install new relevant examples
   * Bump Standards-Version to 4.4.1
   * Update the Vcs-Git, Vcs-Browser URLs to the new home on salsa
   * Take over maintainership
   * Remove support for upgrading from ancient ddclient
   * Simplify debian/config and debian/postinst
   * Fail postinst if debconf's `db_get` fails
   * Fix quoting in shell scripts (Closes: #729960)
   * Unconditionally source debconf/confmodule in postinst
   * Recommend additional Perl modules for full protocol support
   * Ask for the protocol before asking for the server
   * Interpret an empty server as "use the default"
   * Update service and protocol choices (Closes: #745217, #625715)
   * Change default debconf check interval from 300 to 5m
   * Support `postinst reconfigure` (recommended by debconf-devel(7))
   * Remove the `run_daemon` control from the init script
   * Bump debhelper compat to 10
   * Add a systemd service node config.
 Thanks to Andreas Henriksson (Closes: #950246)
   * Change the default for "Run as a daemon?" to true
   * Bump Standards-Version to 4.5.0

Regards,

--
  Richard Hansen

Bug#962133: [Pkg-zsh-devel] Bug#962135: Bug#962135: patch for bugs 962133 and 962135

[Daniel Shahaf]

Vincent Lefevre wrote on Wed, 03 Jun 2020 21:14 +0200:
> On 2020-06-03 20:28:11 +0200, Axel Beckert wrote:
> > Daniel: Would you review it for upstream inclusion?

Sure.

> Note that this is not documented, so I thought that this was just
> internal, and 3rd party code should have its own functions.

As far as completion functions go, I'd err on the side of considering
the comment at the top of _deb_packages to be API documentation,
notwithstanding that it's only a top-of-file comment and not in the
manual.

Furthermore, I'd rather not remove code just because it's currently
unused in zsh.git.  The completion system — especially the Type/*
functions — is an API, not a blackbox.  Does the function proposed for
removal answer a useful question?  Might third party tools (or even
people's zshrc files) be using or in the future use that function?  The
function has already been written (and debugged, etc); how likely is it
that if we remove it, someone will have to reinvent the wheel?

So, I agree with Axel about the _deb_packages part of the patch.

As to the _dpkg part of the patch, first of all, it's incomplete:
it removes the "listfiles" case but not the code that sets that value.
Once the latter is removed too, the function will then display a single
asterisk to the user instead of an actual description.  And with _that_
fixed, there'll still be the issue that, where possible, it's better to
generate completions than to just tell the user what type of thing they're
supposed to type in.  Incorrect or incomplete code should, if possible,
be corrected rather than axed.

So I consider the _dpkg part of the patch a helpful debugging aid, but
I'm afraid I don't think it's ready to be merged as-is.

I'm not overly familiar with the aptitude/apt/dpkg/dselect hierarchy of
semantics, but in general, completion should (1) offer everything that
the command would accept, (2) not offer things the command won't accept.
That's in descending order of priority: it's usually better to offer too
much than too little.

HTH.  Let me know if you have further questions ☺

Cheers,

Daniel
(no pun intended)

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

[Alexandre Lymberopoulos]

Hi Nicholas,

I can perform this real-life testing, but I don't know how to get the
package to install and test. Sorry for this naive question, but hydrogen
is no longer available via apt(itutde), only the 0.9.7-6 installed here.

Thanks for your help!

Best, Alexandre

On May 23 2020, Nicholas D Steeves wrote:
> Hi Alexandre,
> 
> Please CC the bug (xyz...@bugs.debian.org) in the future.  I've had to
> cut your reply, because we can't release private mail to the public.
> 
> I appreciate that you filed an RFS for reintroduction of the package.
> When the package is reintroduced I'll open all the old auto-closed bugs;
> testing to see if an old bug still exists then that would be another way
> to help out.
> 
> Current status/progress update: I need to carefully examine upstream
> source to see which of the 1000-series patches that failed to rebase can
> be dropped.  I'll also have to analyse the package to see if sticking
> with CDBS would be for the best, or if we can move it to debhelper at
> this time.  Both of these things are a bit advanced, which is why I
> didn't leave this work for a newcomer; Increasingly I like to leave work
> for newcomers, because it sometimes feels hard to find a place to
> contribute.  Anyways, I think real-life testing has equal value to
> packaging, so thank you again for your willingness to contribute in
> this way! :-)
> 
> 
> Cheers,
> Nicholas
> 



-- 
===
Alexandre Lymberopoulos - lym...@ime.usp.br - http://www.ime.usp.br/~lymber
Instituto de Matemática e Estatística - Universidade de São Paulo
===

Bug#962158: lintian: New very problematic --fail-on default value

[Guillem Jover]

Package: lintian
Version: 2.80.0
Severity: important

[ This probably deserves to be serious, but I'm not sure I can be
  bothered… ]

Hi,

As was mentioned on debian-devel@l.d.o, and on #debian-qa, the new
default is very problematic, and has not been properly justified.

The general expectation is that a linter is supposed to exit non-0
when it finds at least errors. When people use it in manual mode,
they will just see the reported tags, but in automatic settings the
error code is what makes this useful at all.

This change means that any current caller which uses lintian as part
of its acceptance testing will now silently let broken things through
(until someone eventually notices the breakage), some examples of this
in Debian are:

  - dupload/dput/dput-ng
  - sbuild
  - pbuilder
  - check-all-the-things
  - debomatic (?)
  - jenkins-debian-glue
  - pkg-perl-tools
  - dpkg-buildpackage --check-command
  - etc.

Then also any CI setup that uses lintian (say in .gitlab-ci.yml or
.travis, .circleci, or similar stuff).

While these could be adapted in Debian, it would still leave any CI or
in-house setup that calls lintian broken. This is made worse due to the
new option not being available in older releases before the default got
changed, which would imply cumbersome backward compatibility checks that
decide whether to use the new option or not.

If the default change made sense due to some technical rationale, this
effort might be worthwhile, but as it is, this is a bad default that will
require tons of useless work and introduces breakage for no good reason.

Thanks,
Guillem

Bug#962157: lintian: No way to override --fail-on to none in command-line

[Guillem Jover]

Package: lintian
Version: 2.80.0
Severity: normal

Hi,

The newly introduced --fail-on option has no way to override a fail-on
setting in the configuration file (say «fail-on=error,warning») to set
it to no error on any condition (as in «--fail-on=none» or similar).

Thanks,
Guillem

Bug#962134: add Sound Open Firmware

[Mark Pearson]

On 6/3/2020 8:31 PM, Paul Wise wrote:
>
>
> SOF is free software, but many devices require binaries that are signed
> by Intel's keys, so the free license/source code much less useful and
> the binaries going into linux-firmware are needed for most people.
>
> More details in the links on this page:
>
> https://wiki.debian.org/Firmware/Open
>
> Mark, do Lenovo Laptops require the Intel-signed blobs?
>
Hi Paul - I'm afraid it does (not something of Lenovo's choosing to my 
knowledge...).


My understanding is the SOF team didn't want to use intel-firmware but 
I'm trying to find the discussion on the SOF mailing list as to why.


I think it was related to there being topology files and debug files and 
wanting to keep everything together - and the other two files didn't 
belong in intel-firmware.
There were also concerns about it moving outside of their control. Their 
solution was the sof-bin repository 
(https://github.com/thesofproject/sof-bin)


I have to admit - I hadn't considered the freedoms issues of that.
Is having a sof-firmware repository that is non-free the same way as 
intel-firmware? I'm guessing Debian doesn't want to increase the number 
of non-free packages?


I know the SOF team wanted to work with Debian on this issue a few 
months ago - I will dig up that email and point them at this bug so they 
can contribute to the conversation without me muddying the waters about 
their decisions (I was on their mailing list but not involved in the 
decision making)


Mark

Bug#962156: josm: Could not initialize class org.openstreetmap.josm.data.cache.JCSCacheManager

[Andrew Harvey]

Package: josm
Version: 0.0.svn16538+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I opened JOSM and tried to download an area of data from OSM but before the
JMapViewer window opened JOSM crashed with:

{{{
Revision:16538
Is-Local-Build:false
Build-Date:1970-01-23 23:34:59
Debian-Release:0.0.svn16538+dfsg-2
Build-Name:Debian

Identification: JOSM/1.5 (16538 Debian en_AU) Linux Debian GNU/Linux
bullseye/sid
Memory Usage: 441 MB / 3976 MB (138 MB allocated, but free)
Java version: 11.0.7+10-post-Debian-3, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Java package: openjdk-11-jre:amd64-11.0.7+10-3
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20200323-1
liboauth-signpost-java: liboauth-signpost-java:all-1.2.1.2-3
VM arguments: [--add-modules=java.scripting,java.sql, -Djosm.restart=true,
-Djava.net.useSystemProxies=true]

Plugins:
+ Mapillary (1.5.23)
+ apache-commons (35362)
+ apache-http (35092)
+ buildings_tools (35474)
+ editgpx (35248)
+ javafx-unixoid (35375)
+ jna (35092)
+ photo_geotagging (35405)
+ photoadjust (35405)
+ poly (35248)
+ reverter (35474)
+ tageditor (35258)
+ turnlanes (35405)
+ turnlanes-tagging (283)
+ turnrestrictions (35405)
+ undelete (35474)
+ utilsplugin2 (35476)

Tagging presets:
+ /usr/share/josm/data/defaultpresets.xml
+
https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/AU.zip
+ https://raw.githubusercontent.com/osmlab/name-suggestion-
index/master/dist/name-suggestions.presets.xml

Map paint styles:
- /usr/share/josm/styles/standard/potlatch2.mapcss
- https://raw.githubusercontent.com/yopaseopor/indoormap/master/indoormap-
style.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/Admin_Boundaries=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/SlovakiaBicycleRoutes=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/Enhanced_Lane_and_Road_Attributes=1
- https://josm.openstreetmap.de/josmfile?page=Styles/iD=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes=1
-
https://josm.openstreetmap.de/josmfile?page=Styles/LessObtrusiveNodes=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MTB=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Mountains=1
- https://raw.githubusercontent.com/OpenSidewalks/OpenSidewalks-
Schema/master/open_sidewalks.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/Osmc=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes=1
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport=1
- https://josm.openstreetmap.de/josmfile?page=Styles/sac_scale=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Sidewalks=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Surface=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Fixme=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Noname=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MapWithAI=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lit=1
- https://josm.openstreetmap.de/josmfile?page=Styles/LitObjects=1

Validator rules:
+ /validator/indoorhelper.validator.mapcss

Last errors/warnings:
- E: Failed to locate image
'
https://koordinates.a.ssl.fastly.net/media/settings/branding/favicon-lds.ico
'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- E: Failed to locate image
'https://www.spatial.nsw.gov.au/__data/assets/file/0017/224801/favicon.ico'
- W: javax.imageio.IIOException: Caught exception during read:. Cause:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
- E: Failed to locate image 'traffic_signs_presets/tunnel.png'
- W:  Tunnel: Could not get presets icon traffic_signs_presets/tunnel.png
- E: Handled by bug report queue: java.lang.NoClassDefFoundError: Could not
initialize class org.openstreetmap.josm.data.cache.JCSCacheManager
- E: Handled by bug report queue: java.lang.NoClassDefFoundError: Could not
initialize class org.openstreetmap.josm.data.cache.JCSCacheManager


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: AWT-EventQueue-0 (20) of main
java.lang.NoClassDefFoundError: Could not initialize class
org.openstreetmap.josm.data.cache.JCSCacheManager
at

Bug#960788: RFP: alsa-sof-firmware -- Intel SOF audio firmware and topology

[Paul Wise]

On Sat, 16 May 2020 12:28:37 -0400 Mark Pearson wrote:

> These are the SOF firmware and topology files needed to get the audio working
> on many modern Intel CPUs (whiskeylake, cometlake etc)
> With the SOF driver enabled (which it currently is in debian the kernel will
> load these firmware files at boot and the topology files are used by ALSA for
> configuring audio

Unfortunately SOF firmware, while it has freely licensed source code,
is not (very) useful to package properly (reproducibly built from
source etc) for Debian. The issue is that many devices require the
firmware binaries to have an Intel signature on them, so even though
we have freely licensed source code, we do not have the four freedoms
since we cannot upload our own firmware binaries onto the audio
devices. So the best option here is for Intel to do the building and
signing and get them included in linux-firmware and then Debian pull
the latest version of that.

More details in the links on this page:

https://wiki.debian.org/Firmware/Open

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#598892: RE

[wwwheadoffi...@gmail.com]

Bug#672284: lintian: False positive: no-debian-copyright when packages supply debian/$pkgname.copyright

[Felix Lechner]

Hi,

> having
> copyright files that vary with binary package doesn't make sense to me.

I struggled with that as well while rewriting the copyright check.
Lintian will soon ignore per-package copyrights in ./debian. It will
also produce errors.

Lintian may further print errors when copyright files in installation
packages are not true copies of the d/copyright file in their source.

> One nice thing that having separate copyright files per binary package
> would let you do is be unambiguous that a particular binary package with
> an OpenSSL dependency contains only BSD-licensed code even if the source
> package has other GPL-licensed code, so that you know for certain there's
> no clash with the OpenSSL license.

Leaving the relicensing of OpenSSL aside (plus, alternatives like
wolfSSL exist) I do not think that this fine point, while well
articulated, warrants the technical complexity or the legal risks.

Kind regards
Felix Lechner

Bug#962134: add Sound Open Firmware

[Paul Wise]

On Wed, 3 Jun 2020 18:02:50 +0200 Moritz Mühlenhoff wrote:

> This is free software and could go into main or am I missing something?

SOF is free software, but many devices require binaries that are signed
by Intel's keys, so the free license/source code much less useful and
the binaries going into linux-firmware are needed for most people.

More details in the links on this page:

https://wiki.debian.org/Firmware/Open

Mark, do Lenovo Laptops require the Intel-signed blobs?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962084: Adding buster-backport to apt sources on install seems wrong

[Sunil Mohan Adapa]

On 03/06/20 12:35 am, Christian Ehrhardt wrote:
> Package: plinth
> Version: 20.10
> severity: serious
> 
> Hi,
> running into issues today I realized that the new freedombox 20.10
> places this file on disk:
> $ cat /etc/apt/sources.list.d/freedombox2.list
>   # This file is managed by FreedomBox, do not edit.
>   # Allow carefully selected updates to 'freedombox' from backports.
>   deb http://deb.debian.org/debian buster-backports main
>   deb-src http://deb.debian.org/debian buster-backports main
> 
> IMHO a package should not on-install mess with apt sources. Users just
> don't expect this or the follow on consequences that can happen.
> For example you are pinning python packages from backports which I'd
> expect might lead to quite some dependency hell with other things installed.
> 
> I was facing this in Ubuntu where it is even more wrong and essentially
> breaking `apt update`, but IMHO it is even wrong if not outright
> forbidden by some policy in Debian. I mean adding 'buster-backports' and
> pinning to them in e.g. 'sid' - to me that sounds like calling for trouble.
> 
> I'd ask you to reconsider and remove this behavior. If you want/need to
> keep it then maybe at least consider adding a skip if `dpkg-vendor
> --derives-from Ubuntu` is true. Would that work better for you?

Thank you for the bug report.

We are planning to restrict selection of backports to Debian. A fix
should be available soon[1]]. Pinning of packages should not effect
non-Debian distributions. Packages will be installed from Backports if
available and if only if they are higher version. In all other cases
they will be installed from other sources and pinned priorities won't
effect in any way.

Beyond that we are also planning to make the selection of backports an
explicit step in the user interface (restricted to Debian)[2].

Links:

1) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/1824

2) https://salsa.debian.org/freedombox-team/freedombox/-/issues/1855

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#962138: perl-base: libperl5.30 version skew can break essential functionality

[Dominic Hargreaves]

On Wed, Jun 03, 2020 at 07:39:38PM +0300, Niko Tyni wrote:
> Package: perl-base
> Version: 5.30.2-1
> Severity: serious
> 
> Our Perl package dependencies and search path arrangements allow
> for a suitably versioned libperl5.30 package to break perl-base
> functionality. This is bad as perl-base is Essential:yes and is therefore
> required to stay functional at all times.
> 
> The specific version skew that triggers this is between minor upstream
> versions, so for instance 5.30.2-1 -> 5.30.3-1, which are the current
> version in testing and unstable.

> Minor upstream version upgrades in testing/unstable have been relatively
> rare in the past, and oldstable -> stable upgrades have always
> incorporated a major version bump since the 5.10 times (squeeze), when
> the dependencies and the package set were very different.

> I'm afraid this also means that a minor upstream version upgrade
> in stable has a higher risk of breaking things, so maybe we should
> reconsider #961443.

Agreed.
 
> I see two ways of fixing this (but happy to entertain other suggestions too).
> 
> A) Move /usr/lib//perl-base up on the @INC search path. This is
>shipped in perl-base and includes the parts of the standard library
>we consider part of Essential:yes functionality. It's currently last
>on @INC. The libperl5.30 and perl-modules-5.30 packages include copies
>of these files, shipped in /usr/{lib,share}//perl/5.30,
>so that they can be used "standalone" for different architectures or
>major versions. The position of these copies higher on @INC makes this
>bug possible.
> 
>IIRC I put /usr/lib//perl-base last because it's a nonstandard
>divergence from the upstream way of doing things, and I wanted it not
>to have an effect in the "normal" case when all the related packages
>are installed and configured. So it was only supposed to be a safeguard
>during upgrades and such. Clearly the safeguard is incomplete.
> 
> B) Do away with the /usr/{share,lib/x86_64-linux-gnu}/perl/5.30 -> 5.30.x
>symlinks currently shipped in libperl5.30 and perl-modules-5.30,
>and have the perl search path include the full upstream version. We
>tried this with the multiarch changes in 5.22 but reverted it with
>#787158 .  As I noted in that bug, this would mean that long running
>Perl programs could have @INC changed underneath them during version
>upgrades. This is not a showstopper by any means; we already have the
>'perl-major-upgrade' trigger for similar situations during major
>version upgrades, with at least some buy-in from packages like
>spamassassin IIRC.
> 
> I think A) is currently my preferred way of fixing this, and I think
> the upstream "divergence" issue it creates is not very important. I
> can envision some corner case regressions where standard library
> modules expect other modules to be in the same directory, but those
> seem improbable.
> 
> The main reason why I prefer option A is that it seems conceptually more
> correct (improving the standalone properties of perl-base). Also, option
> B may be harder to implement while keeping upgrade paths robust. But I
> haven't really thought this through yet.

Agreed, the upstream divergence seems like a very minor thing compared
to the advantage of a simpler, more predictable fix.

> On a brighter note, either of these options would close #798626 :)
> 
> Apologies for my verbosity and thanks for reading through; ideas and
> comments are naturally welcome. Despite the severity I don't think this
> is particularly urgent, except with the possibly implications for stable
> updates / #961443.

One reason to make this urgent is so that this issue doesn't occur when
5.30.3-1 transitions to testing in a couple of days. It doesn't sound
like the fix is especially hard, so it might be worth pushing through
if we can?

Cheers
Dominic

Bug#962154: Resolved

[Allan Herrera]

For reference which commands I used:
sudo apt-get install --reinstall -yqq command-not-found #For reinstalling
package
sudo nano /etc/apt/sources.list.d/google-chrome.list #Google chrome
repository
I commented it all that way:
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
#deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

sudo apt-get update& apt-get upgrade -yqq
sudo update-command-not-found

*Problem Solved, I expect this will be useful*

Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1

[Michael Shuler]

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


* Note: Please, upload this to stretch-updates as well to fix ongoing 
issues with failing web services from the expired AddTrust certificate. 
See #961907 for details.


I would like to upload ca-certificates_20200601~deb9u1 with the 
following fixes:


ca-certificates (20200601~deb9u1) stretch; urgency=medium

  * Rebuild for stretch.
  * Merge changes from 20200601
- d/control
  * This release updates the Mozilla CA bundle to 2.40, blacklists
distrusted Symantec roots, and blacklists expired "AddTrust External
Root". Closes: #956411, #955038, #911289, #961907
  * Fix permissions on /usr/local/share/ca-certificates when using 
symlinks.

Closes: #916833


diffstat for ca-certificates-20161130+nmu1+deb9u1 
ca-certificates-20200601~deb9u1


 .gitignore  |   12
 debian/ca-certificates.postinst |8
 debian/changelog|  228 +
 debian/copyright|   14
 mozilla/blacklist.txt   |   54
 mozilla/certdata.txt| 4927 


 mozilla/nssckbi.h   |6
 7 files changed, 2731 insertions(+), 2518 deletions(-)

Full debdiff.gz attached, due to the size of certdata changes.

--
Kind regards,
Michael Shuler


ca-certificates_20200601~deb9u1.debdiff.gz
Description: application/gzip

Bug#962154: command-not-found not called for inexisting commands

[Allan Herrera]

Package: command-not-found
Version: 18.04.5-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,


   Using any uexisting command
calling a command i.e. "sudi" shich doesnt exists or misspelled
   * I expext something like "sudi" command not found did you mean:
sudo from package sudo (just like in Ubuntu)
But i just get:
Could not find the database of available applications, run 
update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment
allan@claro:~/Escritorio/Laboratorio$ sudo update-command-not-found
[sudo] password for allan: 
allan@claro:~/Escritorio/Laboratorio$ sudi
Could not find the database of available applications, run 
update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment

I already tried running "update-command-not-found" as root and doesn't make any 
output and gets same error message
Thanks in advance.

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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019051400
ii  python3  3.7.3-1
ii  python3-apt  1.8.4.1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information

Bug#714454: ITP: polyphone -- soundfont editor (.sf2 format 2.01 and 2.04)

[Thorsten Glaser]

Packaging status: repository at
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/polyphone.git;a=summary

We’re currently held up by some licencing issues:

• https://github.com/davy7125/polyphone/issues/105 (showstopper,
  but the GPLv2-only code is from MuseScore, whom I asked to relicence)

• https://github.com/davy7125/polyphone/issues/106 (fixed in Debian,
  by adding the necessary info and licence to d/copyright)

• https://github.com/davy7125/polyphone/issues/107 (worked around,
  by using wolfSSL instead of OpenSSL, might even work)

I’m otherwise getting acceptable progress with packaging. I’ll also
make it use the system copy of sfarklib instead of bundling one, as
Policy demands.

The upstream-provided .deb crashes quite a lot for me, especially
on exit. I hope this is a matter of integration and will fix itself
with a proper build on sid; if not help debugging the C++/Qt5 issues
is welcome.

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#962153: RFP: webext-export-cookies -- exports cookies to a Netscape format cookies.txt file

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: webext-export-cookies
  Version : 0.3.2
  Upstream Author : Rotem Dan 
* URL : https://github.com/rotemdan/ExportCookies
* License : MIT/X11
  Programming Lang: JavaScript
  Description : exports cookies to a Netscape format cookies.txt file

Adds a browser action to save cookies to a standard Netscape
format cookies.txt file. Cookies can be exported either for
the current host, current domain or for all domains.

The Netscape cookies.txt can be used by several tools like curl or gallery-dl.

Bug#895597: lintian: recommend runuser(1) for recursive file changes

[Felix Lechner]

Hi dkg,

> From the tag description (extended in bug #889489), it's not clear to me
> *how* to use runuser for the requested fix and *why* using runuser
> actually fixes the problem described in the tag

> I can't comment on this directly, but the tag was also extended in
> #895370 which might explain a little more.

You filed both of the bugs referenced here but even though they are
closed, something was still unclear. I rewrote the tag description and
renamed the tag. Perhaps you have a moment to take brief look. Thanks!


https://salsa.debian.org/lintian/lintian/-/blob/master/tags/r/recursive-privilege-change.desc

Kind regards
Felix Lechner

Bug#962152: buster-pu: package ca-certificates/20200601~deb10u1

[Michael Shuler]

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


* Note: Please, upload this to buster-updates as well to fix ongoing 
issues with failing web services from the expired AddTrust certificate. 
See #961907 for details.



I would like to upload ca-certificates_20200601~deb10u1 with the 
following fixes:


ca-certificates (20200601~deb10u1) buster; urgency=medium

  * Rebuild for buster.
  * Merge changes from 20200601
- d/control; set d/gbp.conf branch to debian-buster
  * This release updates the Mozilla CA bundle to 2.40, blacklists
distrusted Symantec roots, and blacklists expired "AddTrust External
Root". Closes: #956411, #955038, #911289, #961907


diffstat for ca-certificates-20190110 ca-certificates-20200601~deb10u1

 debian/changelog  |   59
 debian/copyright  |   12
 debian/gbp.conf   |2
 mozilla/blacklist.txt |   26
 mozilla/certdata.txt  | 3908 
--

 mozilla/nssckbi.h |4
 6 files changed, 2318 insertions(+), 1693 deletions(-)

Full debdiff.gz attached, due to the size of certdata changes.

--
Kind regards,
Michael


ca-certificates_20200601~deb10u1.debdiff.gz
Description: application/gzip

Bug#962151: Failure to save: unitialized value $SETTINGS{"ps_backend"}

[martin f krafft]

Package: gscan2pdf
Version: 2.7.0-1
Severity: normal
Tags: upstream

When trying to save, nothing happens and the process indicator just 
freezes at 0%. In the debug logs, I see this:

  WARN - Use of uninitialized value $SETTING{"ps_backend"} in string 
  eq at /usr/bin/gscan2pdf line 2867.

lotus:~% grep ps_backend .config/gscan2pdfrc
   "ps_backend" : "pdftops",
lotus:~% pdftops -v
pdftops version 0.71.0
Copyright 2005-2018 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]8:6.9.10.23+dfsg-2.1+b2
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1
ii  libfilesys-df-perl 0.92-6+b5
ii  libgoocanvas2-perl 0.06-1
ii  libgtk3-perl   0.037-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.72-5
ii  libimage-magick-perl   8:6.9.10.23+dfsg-2.1
ii  libimage-sane-perl 5-1
ii  liblist-moreutils-perl 0.416-1+b5
ii  liblocale-gettext-perl 1.07-4
ii  liblog-log4perl-perl   1.49-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b8
ii  libpdf-api2-perl   2.037-1
ii  libproc-processtable-perl  0.59-2
ii  libreadonly-perl   2.050-2
ii  librsvg2-common2.48.4+dfsg-1
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.1.0+git191117-2
ii  libtry-tiny-perl   0.30-1
ii  sane-utils 1.0.27-3.2+b1

Versions of packages gscan2pdf recommends:
pn  djvulibre-bin   
ii  pdftk   2.02-5+b1
ii  pdftk-java [pdftk]  3.1.1-1
ii  tesseract-ocr   4.1.1-2
pn  unpaper 
ii  xdg-utils   1.1.3-2

gscan2pdf suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#962150: ITP: python3-readability-lxml -- HTML document cleaner, port of the ruby arc90 readability project

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: python3-readability-lxml
  Version : 0.6.1
  Upstream Author : Yuri Baburov 
* URL : http://github.com/buriy/python-readability
* License : Apache License 2
  Programming Lang: Python
  Description : HTML document cleaner, port of the ruby arc90 readability 
project

Given a html document, it pulls out the main body text and cleans it up.
This is a python port of a ruby port of arc90's readability project.

This package will be under DPMT maintainership.
It is a dependency for gnome-feeds.

Bug#962149: libwolfssl-dev: misspelt OpenSSL compatibility flags

[Thorsten Glaser]

Package: libwolfssl-dev
Version: 4.4.0+dfsg-2
Severity: normal

/usr/include/wolfssl/openssl/bio.h:#define BIO_FLAG_BASE64_NO_NL 
WOLFSSL_BIO_FLAG_BASE64_NO_NL
/usr/include/openssl/bio.h:# define BIO_FLAGS_BASE64_NO_NL  0x100

FLAG vs. FLAGS (the others probably as well)

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
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 libwolfssl-dev depends on:
ii  libwolfssl24  4.4.0+dfsg-2

libwolfssl-dev recommends no packages.

libwolfssl-dev suggests no packages.

-- no debconf information

Bug#961994: src:libcatmandu-perl: fails to migrate to testing for too long: causes autopkgtest regression

[Paul Gevers]

Hi Niko

On 03-06-2020 18:55, Niko Tyni wrote:
>> 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:libcatmandu-perl in unstable has been trying to migrate for 60 days
>> [2]. Hence, I am filing this bug.
> 
> So if I read this correctly, libcatmandu-perl cannot migrate because it
> breaks the test suite of libcatmandu-sru-perl in testing. The version of
> libcatmandu-sru-perl in unstable fixes this, but cannot migrate because
> it has a versioned dependency on libcatmandu-perl that is only satisfied
> in unstable.

Aha, that's unfortunate than. Normally this would mean that the test run
of libcatmandu-sru-perl for itself already yielded a good result for
libcatmandu-perl, but because the latter was updated, no such thing
happened. In such a case, britney doesn't solve it by itself.

> I believe the preferred way to get these to migrate together is to declare
> that libcatmandu-perl Breaks the older libcatmandu-sru-perl versions.

Or a reupload of libcatmandu-sru-perl would also solve it I believe.

> Alternatively, just waiting it out will probably work too: once testing
> removal happens, the newer packages can migrate on their own.

This would be a bad solution as ...

> However,
> if the test suite breakage is not just a technicality, the missing
> Breaks makes it possible for users to partially upgrade their systems
> to a broken combination.

This is the interesting question. Is there something broken in the
combination that we're testing? If so, I would prefer the Breaks.

> Paul, please correct me if I'm mistaken above :)

If it's *only* the test that's broken, I can manually trigger the right
test.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#962148: RFS: diodon/1.10.0-1 -- GTK+ Clipboard manager

[Oliver Sauder]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: diodon
   Version : 1.10.0-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon
 * License : GPL-2+
 * Vcs :
https://git.launchpad.net/~diodon-team/+git/debian-packaging
   Section : utils

It builds those binary packages:

  diodon - GTK+ Clipboard manager
  libdiodon0 - GTK+ Clipboard manager (main library)
  gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
  diodon-dev - GTK+ Clipboard manager (development files)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.10.0-1.dsc

Changes since the last upload:

   * New upstream release.
   * Switch to Ayatana AppIndicator (Closes: #956764)
   * Remove CPU intensive timer when using primary selection (Closes:
#956008)
   * Update translations
   * Replace Vcs-Bzr link with Vcs-Git
   * Update minimum build dependency version of libgtk
   * Bump Standard Version to 4.5.0

Regards,
Oliver

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Junchao Zhang]

On Sun, May 31, 2020 at 10:33 AM Drew Parsons  wrote:

> On 2020-05-27 22:00, Junchao Zhang wrote:
> > On Wed, May 27, 2020 at 12:09 AM Drew Parsons 
> > wrote:
> >
> >> On 2020-05-24 10:01, Drew Parsons wrote:
> >>> On 2020-05-23 23:45, Satish Balay wrote:
> 
>  One more issue: Most externalpackages don't support
> >> 64bit-indices.
> >> ...
>  We haven't tried using MUMPS in this mode with PETSc
> >>>
> >>> This will be the interesting test. I'll start with the 64-bit
> >> build of
> >>> MUMPS and see how tests hold up.
> >>
> >> The PETSc mumps tests seem to be robust with respect to 64 bit.
> >> (64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer
> >> -DINTSIZE64)
> >>
> >> That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS
> >> and 64 bit PETSc passes its tests with 32 bit MUMPS.
> >>
> >> The test in question that's passing is src/snes/tutorials/ex19, run
> >> with
> >> 'make runex19_fieldsplit_mumps'
> >> Perhaps it's not stress-testing 64 bit conditions.
> >
> > Could you provide more details, e.g., the error stack trace?
>
>
>
> Hi Junchao, PETSc's mumps test runs fine, there is no error to trace as
> such, just a diff with the reference output.
>
> With 32-bit PETSc and 64-bit [PORD] MUMPS,
>
> $ mpirun -n 2 ./ex19 -pc_type fieldsplit -pc_fieldsplit_block_size 4
> -pc_fieldsplit_type SCHUR -pc_fieldsplit_0_fields 0,1,2
> -pc_fieldsplit_1_fields 3 -fieldsplit_0_pc_type lu -fieldsplit_1_pc_type
> lu -snes_monitor_short -ksp_monitor_short
> -fieldsplit_0_pc_factor_mat_solver_type mumps
> -fieldsplit_1_pc_factor_mat_solver_type mumps
>
> returns the result:
>
> lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
>0 SNES Function norm 0.239155
>  0 KSP Residual norm 0.235858
>  1 KSP Residual norm < 1.e-11
>1 SNES Function norm 6.81968e-05
>  0 KSP Residual norm 2.30906e-05
>  1 KSP Residual norm < 1.e-11
>2 SNES Function norm < 1.e-11
> Number of SNES iterations = 2
>
>
> where output/ex19_fieldsplit_5.out has
>
> lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
>0 SNES Function norm 0.239155
>  0 KSP Residual norm 0.239155
>  1 KSP Residual norm < 1.e-11
>1 SNES Function norm 6.81968e-05
>  0 KSP Residual norm 6.81968e-05
>  1 KSP Residual norm < 1.e-11
>2 SNES Function norm < 1.e-11
> Number of SNES iterations = 2
>
>
> So the diff in this case is
>
> $make runex19_fieldsplit_mumps
> 3c3
> < 0 KSP Residual norm 0.239155
> ---
> > 0 KSP Residual norm 0.235858
> 6c6
> < 0 KSP Residual norm 6.81968e-05
> ---
> > 0 KSP Residual norm 2.30906e-05
>
I tested it with both 32-bit and 64-bit. They had the same result as yours.
It seems we need to update the output file in the repo. I will do it.
Thanks.

Bug#962147: xserver-xorg-video-ast: Package installs driver .so at path not found by Xorg

[Sergey Aleynikov]

Package: xserver-xorg-video-ast
Version: 1.1.5-1.1+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Running a machine with ASPEED AST2400 video.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Install this package, run 'startx'.

   * What was the outcome of this action?
I observe the only available screen resolution to be 640x480.

   * What outcome did you expect instead?
To be able to select all supported screen resolutions, up to 1920x1200.

The problem, as I see it, is that the Xorg package won't look into 
/usr/lib/x86_64-linux-gnu/xorg/modules/drivers/
for drivers, only into /usr/lib/xorg/modules/drivers/, in which all other 
xserver-xorg-video-* already install them, see

ls -al /usr/lib/xorg/modules/drivers/ | wc -l
25

Moving ast_drv.so into it solved this problem.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Mar  6  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Mar  5  2019 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
06:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED 
Graphics Family [1a03:2000] (rev 30)
83:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 
2060 SUPER] [10de:1f06] (rev a1)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 87 Jun 27  2015 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# NOXORGCONFEXISTED: No X.org configuration file existed when this backup was 
created.

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

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

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

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 56904 Jun  3 23:13 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[  1353.264] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[  1353.265] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[  1353.265] Current Operating System: Linux fangorn 4.19.0-9-amd64 #1 SMP 
Debian 4.19.118-2 (2020-04-29) x86_64
[  1353.265] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 
root=UUID=a340a5a0-24a4-4255-bab2-5cbeb945e180 ro quiet intel_iommu=on 
cgroup_enable=memory swapaccount=1 apparmor=0 nomodeset consoleblank=0 
spec_store_bypass_disable=on l1tf=flush kvm-intel.vmentry_l1d_flush=cond 
nmi_watchdog=0 spectre_v2_user=off random.trust_cpu=off net.ifnames=0
[  1353.266] Build Date: 05 March 2019  08:11:12PM
[  1353.266] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[  1353.266] Current version of pixman: 0.36.0
[  1353.266]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1353.266] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1353.268] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun  3 23:13:18 
2020
[  1353.268] (==) Using config file: "/etc/X11/xorg.conf"
[  1353.268] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1353.268] (==) ServerLayout "ServerLayout0"
[  1353.268] (==) No screen section available. Using defaults.
[  1353.268] (**) |-->Screen "Default Screen Section" (0)
[  1353.268] (**) |   |-->Monitor ""
[  1353.269] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1353.269] (**) Option "BlankTime" "0"
[  1353.269] (**) Option "StandbyTime" "0"
[  1353.269] (**) Option "SuspendTime" "0"
[  1353.269] (**) Option "OffTime" "0"
[  1353.269] (==) Automatically adding devices
[  1353.269] (==) Automatically enabling devices
[  1353.269] (==) Automatically adding GPU devices
[  1353.269] (==) Max clients allowed: 256, resource mask: 0x1f
[  1353.269] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1353.269]Entry deleted from font path.
[  1353.269] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1353.269] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1353.269] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1353.269] (II) Loader magic: 0x558410c31e20
[  1353.269] (II) Module ABI versions:
[  1353.269]

Bug#942590: mmdebstrap: Please support YAML configuration input file as alternative

[Johannes Schauer]

Control: block -1 by 962140

I think this bug can be closed once bdebstrap is in Debian. :)

Thanks!

signature.asc
Description: signature

Bug#871704: Labels of files in `/etc/init.d/` prevent systemd tools from working

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Followup-For: Bug #871704

Some additional information.
I've made some investigation. 
I could say, not all of service which has their name in it - failed to get 
status.
***
root@vps:/tmp# for i in `ls /etc/init.d/ ` ; do ls -Z /etc/init.d/$i ; 
systemctl is-active $i   ; done
system_u:object_r:initrc_exec_t:s0 /etc/init.d/apache2
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/apache-htcacheclean
inactive
system_u:object_r:auditd_initrc_exec_t:s0 /etc/init.d/auditd
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/bind9
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/bootlogd
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/cgmanager
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/cgproxy
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/cron
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/dbus
active
system_u:object_r:exim_initrc_exec_t:s0 /etc/init.d/exim4
Failed to retrieve unit: Access denied
system_u:object_r:entropyd_initrc_exec_t:s0 /etc/init.d/haveged
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/hwclock.sh
inactive
system_u:object_r:irqbalance_initrc_exec_t:s0 /etc/init.d/irqbalance
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/kmod
active
system_u:object_r:mysqld_initrc_exec_t:s0 /etc/init.d/mysql
Failed to retrieve unit: Access denied
system_u:object_r:initrc_exec_t:s0 /etc/init.d/netfilter-persistent
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/networking
active
system_u:object_r:ntpd_initrc_exec_t:s0 /etc/init.d/ntp
Failed to retrieve unit: Access denied
system_u:object_r:openvpn_initrc_exec_t:s0 /etc/init.d/openvpn
inactive
system_u:object_r:pcscd_initrc_exec_t:s0 /etc/init.d/pcscd
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/procps
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/rsync
inactive
system_u:object_r:syslogd_initrc_exec_t:s0 /etc/init.d/rsyslog
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/screen-cleanup
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/selinux-autorelabel
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/ssh
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/stop-bootlogd
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/stop-bootlogd-single
inactive
system_u:object_r:initrc_exec_t:s0 /etc/init.d/sudo
inactive
system_u:object_r:sysstat_initrc_exec_t:s0 /etc/init.d/sysstat
Failed to retrieve unit: Access denied
system_u:object_r:initrc_exec_t:s0 /etc/init.d/udev
active
system_u:object_r:initrc_exec_t:s0 /etc/init.d/unattended-upgrades
active
system_u:object_r:uuidd_initrc_exec_t:s0 /etc/init.d/uuidd
inactive
root@vps:/tmp#
***
As you can see, there are just exim4, mysql, ntp, sysstat.
So, the audit.log has this AVCs:
***
type=USER_AVC msg=audit(1591212457.570:6102): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/etc/init.d/exim4" cmdline="systemctl is-active 
exim4.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:exim_initrc_exec_t:s0 tclass=service  
exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1591212457.830:6103): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/etc/init.d/mysql" cmdline="systemctl is-active 
mysql.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:mysqld_initrc_exec_t:s0 tclass=service  
exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1591212457.862:6104): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/etc/init.d/ntp" cmdline="systemctl is-active 
ntp.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:ntpd_initrc_exec_t:s0 tclass=service  
exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1591212458.278:6105): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/etc/init.d/sysstat" cmdline="systemctl is-active 
sysstat.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:sysstat_initrc_exec_t:s0 tclass=service  
exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
***



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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: 

Bug#962146: liburi-title-perl: autopkgtest network issues

[Niko Tyni]

Package: liburi-title-perl
Version: 1.902-1
Severity: important

This package failed its autopkgtest checks twice recently on
ci.debian.net, probably due to network access peculiarities on the
nodes.

 
https://ci.debian.net/data/autopkgtest/testing/amd64/libu/liburi-title-perl/5736302/log.gz

 
https://ci.debian.net/data/autopkgtest/testing/arm64/libu/liburi-title-perl/5739697/log.gz

#   Failed test at t/image.t line 21.
#  got: undef
# expected: 'camel_head.v25e738a.png (png 60x65)'
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 

Looking at the test code, it tries to make a TCP
connection to www.yahoo.com:80 and is  supposed to
skip the tests if that fails.  Otherwise, it fetches
http://st.pimg.net/perlweb/images/camel_head.v25e738a.png presumably
with LWP::UserAgent and parses the image.

Not sure what goes wrong there. However, we're already skipping html.t
because it relies on external webpage contents, so probably this one
should be on the list too.

I've rescheduled the failed tests caused by this, as they were falsely
registered as perl 5.30.3-1 regressions.
-- 
Niko Tyni   nt...@debian.org

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Ok will do!

Thanks,
Gabriele

On Wed, 3 Jun 2020 at 20:06, Paul Gevers  wrote:
>
> Hi Gabriele,
>
> On 03-06-2020 18:29, Gabriele wrote:
> > Ok mystery solved :). Once I have this fixed, what should I do? Push
> > the new tarball with the same version (1.0.1-1) or should I bump
> > something in the version? I'd expect that perhaps that -1 should
> > become a -2? If so, what's the correct way of doing this?
>
> Unfortunately I don't have the energy to mentor you in this process
> right now. I recommend you consult debian-ment...@lists.debian.org or
> #debian-mentors on IRC for pointers to the right documentation and help
> to get this fixed.
>
> Paul
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#962145: nodejs: CVE-2020-11080 CVE-2020-8172 CVE-2020-8174 (June 2020 security release)

[Salvatore Bonaccorso]

Source: nodejs
Version: 10.20.1~dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 10.19.0~dfsg1-1

Hi,

The following vulnerabilities were published for nodejs.

CVE-2020-11080[0]:
HTTP/2 Large Settings Frame DoS

CVE-2020-8172[1]:
TLS session reuse can lead to host certificate verification bypass

CVE-2020-8174[2]:
napi_get_value_string_*() allows various kinds of memory corruption

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-11080
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11080
[1] https://security-tracker.debian.org/tracker/CVE-2020-8172
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8172
[2] https://security-tracker.debian.org/tracker/CVE-2020-8174
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8174
[3] https://nodejs.org/en/blog/vulnerability/june-2020-security-releases

Regards,
Salvatore

Bug#962144: ITP: gnome-feeds -- RSS/Atom feed reader for GNOME

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: gnome-feeds
  Version : 0.13.4
  Upstream Author : Gabriele Musco 
* URL : https://gitlab.gnome.org/World/gfeeds
* License : GPL
  Programming Lang: Python
  Description : RSS/Atom feed reader for GNOME

 GNOME-Feeds is an RSS/Atom feed reader with an adaptative UI.
 It is a Python3 GTK based application with a small screen compatible
 graphical user interface. It supports importing OPML files.

 This package will be under PAPT maintainership.

Bug#962143: ITP: python3-listparser -- Parse OPML, RDF+FOAF, and iGoogle subscription lists

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: python3-listparser
  Version : 0.18
  Upstream Author : Kurt Mckee 
* URL : https://github.com/kurtmckee/listparser
* License : LGPL
  Programming Lang: Python
  Description : Parse OPML, RDF+FOAF, and iGoogle subscription lists

 Parse OPML, RDF+FOAF, and iGoogle subscription lists
 listparser is a Python module that parses subscription lists (also called
 reading lists) and returns all of the feeds and subscription lists that it
 finds. It supports OPML, RDF+FOAF, and the iGoogle exported settings format,
 and runs in Python 2.7, Python 3.3 and up, PyPy, and Jython.
 .
 The OPML specification defines an outline as a hierarchical, ordered list
 of arbitrary elements. The specification is fairly open which makes it
 suitable for many types of list data, like RSS feeds.

 This package will be used as dependency for gnome-feeds.
 It will be under DPMT maintainership.

Bug#962142: python-rsa: CVE-2020-13757

[Salvatore Bonaccorso]

Source: python-rsa
Version: 4.0-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/sybrenstuvel/python-rsa/issues/146
Control: found -1 4.0-2

Hi,

The following vulnerability was published for python-rsa.

CVE-2020-13757[0]:
| Python-RSA 4.0 ignores leading '\0' bytes during decryption of
| ciphertext. This could conceivably have a security-relevant impact,
| e.g., by helping an attacker to infer that an application uses Python-
| RSA, or if the length of accepted ciphertext affects application
| behavior (such as by causing excessive memory allocation).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13757
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13757
[1] https://github.com/sybrenstuvel/python-rsa/issues/146

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962135: [Pkg-zsh-devel] Bug#962135: patch for bugs 962133 and 962135

[Vincent Lefevre]

Hi Axel,

On 2020-06-03 20:28:11 +0200, Axel Beckert wrote:
> Daniel: Would you review it for upstream inclusion?
> 
> > I've added a note about that:
> > 
> > # Note: Packages may be marked as "deinstall" or "purge", i.e. selected
> > # for deinstallation or to be purged (see dpkg(1) man page); this means
> > # that the operation has not been completed yet. In the meantime, such
> > # packages may still be installed (if marked as purge, one is not sure,
> > # though, as the package could have been uninstalled but not purged yet),
> > # so that purge and remove operations remain valid.
> 
> *sigh* IMHO this is highly misleading.
> 
> The difference between dpkg "states" (i.e. the current state) and
> "selection states" (i.e. the wanted state) only matters if you use
> dselect, which nearly nobody does nowadays.
> 
> So please do _not_ refer to "selection states" in such places since
> "selected for deinstallation" always sounds as if deinstallation is
> imminent while it in 99.9% of all cases already has happened, possibly
> even years ago.

Well, the dpkg(1) man page says "selection states" and
"selected for deinstallation":

  Package selection states
install
   The package is selected for installation.

hold   A  package  marked  to be on hold is not handled by dpkg, unless
   forced to do that with option --force-hold.

deinstall
   The package is selected for  deinstallation  (i.e.  we  want  to
   remove all files, except configuration files).

purge  The  package  is  selected  to be purged (i.e. we want to remove
   everything from system directories, even configuration files).

unknown
   The package selection is unknown.  A package that is also  in  a
   not-installed  state,  and  with an ok flag will be forgotten in
   the next database store.

Do you mean that this man page should be modified?

> > My patch also removes "deinstalled" from _deb_packages as it does not
> > seem to be used (and should be useless).
> 
> Not sure if this is wanted. That code might have been made "complete"
> on purpose for 3rd-party (or future internal) usage. I'd not remove it.

Perhaps, but why aren't there equivalent functions for the "install"
and "purge" states, then?

Note that this is not documented, so I thought that this was just
internal, and 3rd party code should have its own functions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Paul Gevers]

Hi Gabriele,

On 03-06-2020 18:29, Gabriele wrote:
> Ok mystery solved :). Once I have this fixed, what should I do? Push
> the new tarball with the same version (1.0.1-1) or should I bump
> something in the version? I'd expect that perhaps that -1 should
> become a -2? If so, what's the correct way of doing this?

Unfortunately I don't have the energy to mentor you in this process
right now. I recommend you consult debian-ment...@lists.debian.org or
#debian-mentors on IRC for pointers to the right documentation and help
to get this fixed.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#962141: docker.io: CVE-2020-13401

[Salvatore Bonaccorso]

Source: docker.io
Version: 19.03.7+dfsg1-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for docker.io.

CVE-2020-13401[0]:
| An issue was discovered in Docker Engine before 19.03.11. An attacker
| in a container, with the CAP_NET_RAW capability, can craft IPv6 router
| advertisements, and consequently spoof external IPv6 hosts, obtain
| sensitive information, or cause a denial of service.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13401
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13401
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1833233
[2] 
https://github.com/moby/libnetwork/commit/153d0769a1181bf591a9637fd487a541ec7db1e6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#961594: Connection failed [IP: 151.101.112.204 80]

[Christoph Berg]

> > I wonder if turning on apt's Debug::Acquire::http would give more of a
> > clue on where things go wrong?  OTOH given this is highly intermittent
> > it'd be quite noisy...  Christoph, would you be able to give that a try?
> 
> I'll do that now. The first two retries with that setting didn't
> reproduce the problem, though.

20:20:00 Get: 31 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:22:05 GET 
/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44%2bdfsg-5%2bdeb9u4_amd64.deb
 HTTP/1.1
20:22:05 Host: security.debian.org
20:22:05 User-Agent: Debian APT-HTTP/1.3 (1.4.10)
20:22:05
20:22:05
20:22:05 Answer for: 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44+dfsg-5+deb9u4_amd64.deb
20:22:05 HTTP/1.1 200 OK
20:22:05 Server: Apache
20:22:05 X-Content-Type-Options: nosniff
20:22:05 X-Frame-Options: sameorigin
20:22:05 Referrer-Policy: no-referrer
20:22:05 X-Xss-Protection: 1
20:22:05 Last-Modified: Thu, 23 Apr 2020 05:40:59 GMT
20:22:05 ETag: "35840-5a3eeb18b3cf9"
20:22:05 Cache-Control: public, max-age=2592000
20:22:05 Expires: Tue, 28 Apr 2020 19:09:10 GMT
20:22:05 X-Clacks-Overhead: GNU Terry Pratchett
20:22:05 Content-Type: application/x-debian-package
20:22:05 Via: 1.1 varnish
20:22:05 Content-Length: 219200
20:22:05 Accept-Ranges: bytes
20:22:05 Date: Wed, 03 Jun 2020 18:22:05 GMT
20:22:05 Via: 1.1 varnish
20:22:05 Age: 515696
20:22:05 Connection: keep-alive
20:22:05 X-Served-By: cache-fra19137-FRA, cache-hhn4026-HHN
20:22:05 X-Cache: HIT, HIT
20:22:05 X-Cache-Hits: 1, 1
20:22:05 X-Timer: S1591208526.784738,VS0,VE0
20:22:05
20:22:05 Get: 32 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:24:10 GET 
/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44%2bdfsg-5%2bdeb9u4_amd64.deb
 HTTP/1.1
20:24:10 Host: security.debian.org
20:24:10 User-Agent: Debian APT-HTTP/1.3 (1.4.10)
20:24:10
20:24:10
20:24:10 Answer for: 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44+dfsg-5+deb9u4_amd64.deb
20:24:10 HTTP/1.1 200 OK
20:24:10 Server: Apache
20:24:10 X-Content-Type-Options: nosniff
20:24:10 X-Frame-Options: sameorigin
20:24:10 Referrer-Policy: no-referrer
20:24:10 X-Xss-Protection: 1
20:24:10 Last-Modified: Thu, 23 Apr 2020 05:40:59 GMT
20:24:10 ETag: "35840-5a3eeb18b3cf9"
20:24:10 Cache-Control: public, max-age=2592000
20:24:10 Expires: Tue, 28 Apr 2020 19:09:10 GMT
20:24:10 X-Clacks-Overhead: GNU Terry Pratchett
20:24:10 Content-Type: application/x-debian-package
20:24:10 Via: 1.1 varnish
20:24:10 Content-Length: 219200
20:24:10 Accept-Ranges: bytes
20:24:10 Date: Wed, 03 Jun 2020 18:24:10 GMT
20:24:10 Via: 1.1 varnish
20:24:10 Age: 515821
20:24:10 Connection: keep-alive
20:24:10 X-Served-By: cache-fra19137-FRA, cache-hhn4074-HHN
20:24:10 X-Cache: HIT, HIT
20:24:10 X-Cache-Hits: 1, 2
20:24:10 X-Timer: S1591208651.836599,VS0,VE0
20:24:10
20:24:10 Get: 33 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:24:10 Fetched 16.6 MB in 8min 30s (32.4 kB/s)
20:24:10 E: Failed to fetch 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-common_2.4.44+dfsg-5+deb9u4_all.deb:
 Connection failed [IP: 151.101.112.204 80]
20:24:10 E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' 
to continue with missing packages
20:24:11 Reading package lists...

I wonder if the 2min delay before the 2nd last package points at
something. Possibly the transfer was ok for that .deb, but then apt
tries http keepalive but that's already closed?

It could be that the NAT layer in the build chroots here have bad
iptables rules that break this (they have isolated network namespaces
using newpid/newnet). But then, why does it only happen for
security.d.o only, and only for jessie+stretch when buster has also
security? It's also restricted to a set of VMs at Hetzner, while other
machines are fine.

Also, the phenomenon is new (~3 months old or so), while the (buster)
buildhosts are much older and the config hasn't been touched except
for kernel updates.

Christoph

Bug#962133: [Pkg-zsh-devel] Bug#962135: patch for bugs 962133 and 962135

[Axel Beckert]

Hi Vincent,

Vincent Lefevre wrote:
> I've attached a patch for Debian bugs 962133 ("dpkg -s" completion)
> and 962135 ("dpkg -l" completion), which also fixes "dpkg --remove"
> and "dpkg --purge" completions.

Thanks for the patch!

Daniel: Would you review it for upstream inclusion?

> I've added a note about that:
> 
> # Note: Packages may be marked as "deinstall" or "purge", i.e. selected
> # for deinstallation or to be purged (see dpkg(1) man page); this means
> # that the operation has not been completed yet. In the meantime, such
> # packages may still be installed (if marked as purge, one is not sure,
> # though, as the package could have been uninstalled but not purged yet),
> # so that purge and remove operations remain valid.

*sigh* IMHO this is highly misleading.

The difference between dpkg "states" (i.e. the current state) and
"selection states" (i.e. the wanted state) only matters if you use
dselect, which nearly nobody does nowadays.

So please do _not_ refer to "selection states" in such places since
"selected for deinstallation" always sounds as if deinstallation is
imminent while it in 99.9% of all cases already has happened, possibly
even years ago.

> My patch also removes "deinstalled" from _deb_packages as it does not
> seem to be used (and should be useless).

Not sure if this is wanted. That code might have been made "complete"
on purpose for 3rd-party (or future internal) usage. I'd not remove it.

Nevertheless good to know that it doesn't seem to get used in zsh
internally currently.

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

Bug#956580: closed by Ole Streicher (Re: aoflagger: boost update makes aoflagger uninstallable)

[Sebastian Ramacher]

On 2020-06-03 15:41:41 +0200, Ole Streicher wrote:
> Hi Sebastian,
> 
> 
> On 15.04.20 09:45, Sebastian Ramacher wrote:
> > Looking at aoflagger's build system, it could be affected by the same
> > issues during the next Python 3 transition. The build system currently
> > doesn't ensure that the libpython and libboost-python versions are
> > compatabile. So let's keep this bug open to get this properly fixed for
> > the next Python 3 transition.
> 
> The problem now re-appears, since boost it now 1.71 by default and this
> seems to not work. Pinning it to 1.67 helps. However, I think this is
> fragile and will break in future again.
> 
> What is the right way to ensure libpython3 and libboost-python are
> compatible? What is the reason that they are not in the moment?

I'm not sure what you mean. libboost-python1.71.0 is built against
Python 3.8 only and libpython3 currently points python3.8's libpython3.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong

[Petter Reinholdtsen]

[Al Stone]
> Hrm.  So write access seems to be more constrained than this led
> me to believe; I'll try these patches out and rebuild tonight.  I
> did think about using AUTOPKGTEST_TMP but had not convinced myself
> it was absolutely required.

Note, I am not convinced this will help, as I am flying blind without
the error messages, but thought it best to play it safe and use
AUTOPKGTEST_TMP just in case.  After all the 'hello' test seem to work,
and it would try to save directly to cwd which should be the top of the
source tree. :/

> Thank you for all the help, Petter!

Just glad to be of assistance. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2020-04-26 10:46:41, Antoine Beaupré wrote:

[...]

> I will also mention that this has landed in buster ages ago, and no ill
> effects were found there.

I meant bullseye here, sorry.

Any news? :)

a.

-- 
Striving for social justice is the most valuable thing to do in life
   - Albert Einstein

Bug#962133: patch for bugs 962133 and 962135

[Vincent Lefevre]

Control: tags 962133 patch
Control: tags 962135 patch

I've attached a patch for Debian bugs 962133 ("dpkg -s" completion)
and 962135 ("dpkg -l" completion), which also fixes "dpkg --remove"
and "dpkg --purge" completions. I've added a note about that:

# Note: Packages may be marked as "deinstall" or "purge", i.e. selected
# for deinstallation or to be purged (see dpkg(1) man page); this means
# that the operation has not been completed yet. In the meantime, such
# packages may still be installed (if marked as purge, one is not sure,
# though, as the package could have been uninstalled but not purged yet),
# so that purge and remove operations remain valid.

Basically, the fix consists of the _dpkg change.

My patch also removes "deinstalled" from _deb_packages as it does not
seem to be used (and should be useless).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -aurd compl-debian-deb/_deb_packages compl-debian-fix/_deb_packages
--- compl-debian-deb/_deb_packages  2020-03-22 15:12:25.0 +
+++ compl-debian-fix/_deb_packages  2020-06-03 17:09:43.704256786 +
@@ -1,6 +1,6 @@
 #autoload
 
-# Usage: _deb_packages expl...  
(installed|deinstalled|xinstalled|held|uninstalled|avail|available|source)
+# Usage: _deb_packages expl...  
(installed|xinstalled|held|uninstalled|avail|available|source)
 
 _deb_packages_update_avail () {
   if ( [[ ${+_deb_packages_cache_avail} -eq 0 ]] ||
@@ -41,19 +41,6 @@
   cachevar=_deb_packages_cache_held
 }
 
-_deb_packages_update_deinstalled () {
-  if ( [[ ${+_deb_packages_cache_deinstalled} -eq 0 ]] ||
-  _cache_invalid DEBS_deinstalled ) && ! _retrieve_cache DEBS_deinstalled;
-  then
-_deb_packages_cache_deinstalled=()
-dpkg --get-selections | while read package state ; do
-[[ $state = deinstall ]] && _deb_packages_cache_deinstalled+=$package
-done
-_store_cache DEBS_deinstalled _deb_packages_cache_deinstalled
-  fi
-  cachevar=_deb_packages_cache_deinstalled
-}
-
 _deb_packages_update_xinstalled () {
   if ( [[ ${+_deb_packages_cache_xinstalled} -eq 0 ]] ||
   _cache_invalid DEBS_xinstalled ) && ! _retrieve_cache DEBS_xinstalled;
@@ -103,14 +90,14 @@
 zstyle ":completion:*:*:$service:*" cache-policy _debs_caching_policy
   fi
 
-  [[ "$command" = 
(installed|deinstalled|xinstalled|held|uninstalled|avail|available|source) ]] 
|| {
+  [[ "$command" = 
(installed|xinstalled|held|uninstalled|avail|available|source) ]] || {
 _message "unknown command: $command"
 return
   }
 
   zstyle -s ":completion:${curcontext}:" packageset pkgset
 
-  [[ "$pkgset" = 
(installed|deinstalled|xinstalled|held|uninstalled|avail|available|source) ]] 
|| {
+  [[ "$pkgset" = 
(installed|xinstalled|held|uninstalled|avail|available|source) ]] || {
 pkgset="$command"
   }
 
diff -aurd compl-debian-deb/_dpkg compl-debian-fix/_dpkg
--- compl-debian-deb/_dpkg  2020-03-22 15:12:25.0 +
+++ compl-debian-fix/_dpkg  2020-06-03 17:24:33.866990607 +
@@ -149,21 +149,17 @@
   - nonrecur \
'*: :_deb_files'
   ;;
-  remove|status|listfiles)
-_call_function ret _dpkg_$state && return ret
-_arguments -C -A "-*" -s "$_dpkg_options[@]" \
-   '*:package:_deb_packages installed'
-  ;;
-  purge)
+# Note: Packages may be marked as "deinstall" or "purge", i.e. selected
+# for deinstallation or to be purged (see dpkg(1) man page); this means
+# that the operation has not been completed yet. In the meantime, such
+# packages may still be installed (if marked as purge, one is not sure,
+# though, as the package could have been uninstalled but not purged yet),
+# so that purge and remove operations remain valid.
+  list|listfiles|purge|remove|status)
 _call_function ret _dpkg_$state && return ret
 _arguments -C -A "-*" -s "$_dpkg_options[@]" \
'*:package:_deb_packages xinstalled'
   ;;
-  list)
-_call_function ret _dpkg_$state && return ret
-_arguments -C -A "-*" -s "$_dpkg_options[@]" \
-   '*:packages:_deb_packages avail'
-  ;;
   compare_versions)
 _call_function ret _dpkg_$state && return ret
 _arguments -C -A "-*" -s \

Bug#810865: parking infinoted.service

[Geert Stappers]

Parking this infinoted.service  in this issue. 

[Unit]
Description=infinoted server for Gobby collaborative text editor
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/infinoted-0.7
;At boot the service does not sart
;Adding --daemonize does not work either
;ExecStart=/usr/bin/infinoted-0.7 --daemonize

[Install]
WantedBy=multi-user.target


To be continued
Geert Stappers
-- 
Silence is hard to parse

Bug#960149: kmod: Enable support for gzip compressed kernel modules

[Vagrant Cascadian]

On 2020-06-02, Vagrant Cascadian wrote:
> On 2020-06-02, Marco d'Itri wrote:
>> On May 10, Vagrant Cascadian  wrote:
>>
>>> I see xz-compressed modules are supported, which is definitely useful,
>>> but gzip compressed modules are also widely used, and have different CPU
>>> vs. storage space tradeoffs.
>> No. This was already discussed in #952590, I do not want to add another 
>> dependency to the initramfs.
>
> And as said in that bug report as well, libz and numerous other
> compression libraries are already added with a default initramfs-tools.
>
> $ lsinitramfs /boot/initrd.img-5.6.0-2-arm64 | grep -E 'libz|liblz'
> usr/lib/aarch64-linux-gnu/liblz4.so.1
...
> usr/lib/aarch64-linux-gnu/libz.so.1
> usr/lib/aarch64-linux-gnu/libz.so.1.2.11
...
> Your argument that only if it uses plymouth doesn't appear to be
> correct:
>
> $ dpkg -l '*plymouth*'
> dpkg-query: no packages found matching *plymouth*

Though after checking on a more minimal system, something other than
plymouth was probably pulling those in... hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#962140: ITP: bdebstrap -- YAML config based multi-mirror Debian chroot creation tool

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: bdebstrap
  Version : 0.1
  Upstream Author : Benjamin Drung 
* URL : https://github.com/bdrung/bdebstrap
* License : MIT
  Programming Lang: Python
  Description : YAML config based multi-mirror Debian chroot creation tool

bdebstrap is an alternative to debootstrap and a wrapper around
mmdebstrap to support YAML based configuration files. It inherits all
benefits from mmdebstrap. The support for configuration allows storing
all customization in a YAML file instead of having to use a very long
one-liner call to mmdebstrap. It also layering multiple customizations
on top of each other, e.g. to support flavors of an image.

I developed this tool and plan to maintain it in Debian. We use this tool
in-house to build our Debian live images.

-- 
Benjamin Drung

DevOps Engineer and Debian & Ubuntu Developer
Platform Integration (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß, Hans-Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke

Member of United Internet

Bug#962139: [btrfs-progs] initramfs hooks failed with on libgcc_s.so.1

[Daniel Schröter]

Package: btrfs-progs
Version: 5.6-1
Severity: normal

Dear Maintainer,

if I do an
update-initramfs -v -c -k 5.6.0-2-amd64
it failed. I add
set -x
to
/usr/share/initramfs-tools/hooks/btrfs
so I get an better output:
[]
Adding binary /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
+ cp -pP /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
/var/tmp/mkinitramfs_PP4oJD//usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
+ echo /lib/x86_64-linux-gnu/libpthread.so.0
+ sed -e 
s#/lib/\([^/]*/\)\?\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\1\3#
+ nonoptlib=/lib/x86_64-linux-gnu/libpthread.so.0
+ echo /lib/x86_64-linux-gnu/libpthread.so.0
+ sed -e s#-linux-gnu/\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#-linux-gnu/\2#
+ nonoptlib=/lib/x86_64-linux-gnu/libpthread.so.0
+ [ -e /lib/x86_64-linux-gnu/libpthread.so.0 ]
+ x=/lib/x86_64-linux-gnu/libpthread.so.0
+ copy_exec /lib/x86_64-linux-gnu/libgcc_s.so.1
+ local src target x nonoptlib ret
+ src=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ target=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ copy_file binary /lib/x86_64-linux-gnu/libgcc_s.so.1 
/lib/x86_64-linux-gnu/libgcc_s.so.1
+ local type src target link_target
+ type=binary
+ src=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ target=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ [ -f /lib/x86_64-linux-gnu/libgcc_s.so.1 ]
+ return 2
+ return 1
+ return


It failed on /lib/x86_64-linux-gnu/libgcc_s.so.1. It's not available
# ll /lib/x86_64-linux-gnu/libgcc_s.so.1
ls: cannot access '/lib/x86_64-linux-gnu/libgcc_s.so.1': No such file or 
directory


In #950254 they mentioned that libgcc_s gets copied by initramfs-tools. Does it 
break the
workaround in /usr/share/initramfs-tools/hooks/btrfs?

Thanks for you work!

Bye



--- System information. ---
Architecture: Kernel:   Linux 5.5.0-2-amd64

Debian Release: bullseye/sid
  990 unstablemirror.1und1.de   500 stable  
packages.microsoft.com   500
stable  dl.google.com 1 experimentalmirror.1und1.de
--- Package information. ---
Depends(Version) | Installed
-+-=
libblkid1(>= 2.17.2) | 2.35.2-2
libc6   (>= 2.8) | 2.30-8
libcom-err2  (>= 1.43.9) | 1.45.6-1
libext2fs2 (>= 1.42) | 1.45.6-1
liblzo2-2  (>= 2.02) | 2.10-2
libuuid1   (>= 2.16) | 2.35.2-2
libzstd1  (>= 1.3.2) | 1.4.4+dfsg-3
zlib1g  (>= 1:1.2.0) | 1:1.2.11.dfsg-2


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
duperemove|

Bug#958090: Diamond-aligner keeps on failing its build time test on s390x

[Andreas Tille]

Hi,

despite upstream has tried hard to make diamond-aligner portable for all
64bit architectures the build time test keeps on failing for s390x[1]:

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
cd debian/tests && 
PATH=/<>/obj-s390x-linux-gnu:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 sh diamond-calls
+ mktemp -d
+ TESTDIR=/tmp/tmp.b7aBbuLXHF
+ diamond blastp --threads 1 --db test/C.faa.diamond --query test/E.faa --out 
/tmp/tmp.b7aBbuLXHF/E.faa.vs.C.faa.diamond -e 1e-05 --outfmt 6 --quiet 
--sensitive
make[1]: *** [debian/rules:33: override_dh_auto_test] Error 1


Upstream says[2] despite the --quiet option there should be some error
output.  I have removed the --quiet option in Git but did not uploaded
yet.  May be some s390 porter could have a look and provide some gdb or
strace output?

Kind regards

  Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=diamond-aligner=s390x=0.9.33-1=1591090725=0
[2] https://github.com/bbuchfink/diamond/issues/348#issuecomment-638285523

-- 
http://fam-tille.de

Bug#961013: diamond-aligner: Diamond faill with the error: Assertion `index >= 0 && index < size()' failed.

[Pranav Ballaney]

Hi,

I've narrowed the issue down to one (or a few) sequences. Basically this
error occurs whenever a query sequence is less than five nucleotides (and
is independent of the length of sequences in the database file). Besides,
it's not specific to the Debian package. I encountered the same error when
I compiled from the upstream source, but it went away when I downloaded the
compiled binary, so it's probably something to do with the way it is
compiled.

I've reported this on the Github issue page here
 along with the smallest
dataset that can be used to reproduce this issue. Maybe now we wait for
upstream to take a look?

Regards,
Pranav
ᐧ

On Fri, May 22, 2020 at 3:37 AM Andreas Tille  wrote:

> On Thu, May 21, 2020 at 06:33:05PM +0530, Pranav Ballaney wrote:
> > Yes, I've been able to reproduce and roughly pin point the issue, but it
> > needs some more work before it's solved.
>
> That's pretty good news.  Just take the time you need.
>
> Thanks for your effort
>
>   Andreas.
>
> --
> http://fam-tille.de
>

Bug#961994: src:libcatmandu-perl: fails to migrate to testing for too long: causes autopkgtest regression

[Niko Tyni]

On Mon, Jun 01, 2020 at 07:54:29PM +0200, Paul Gevers wrote:
> Source: libcatmandu-perl
> Version: 1.2012-1
> Severity: serious
> Control: close -1 1.2012-1
> Tags: sid bullseye
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
 
> 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:libcatmandu-perl in unstable has been trying to migrate for 60 days
> [2]. Hence, I am filing this bug.

So if I read this correctly, libcatmandu-perl cannot migrate because it
breaks the test suite of libcatmandu-sru-perl in testing. The version of
libcatmandu-sru-perl in unstable fixes this, but cannot migrate because
it has a versioned dependency on libcatmandu-perl that is only satisfied
in unstable.

I believe the preferred way to get these to migrate together is to declare
that libcatmandu-perl Breaks the older libcatmandu-sru-perl versions.

Alternatively, just waiting it out will probably work too: once testing
removal happens, the newer packages can migrate on their own. However,
if the test suite breakage is not just a technicality, the missing
Breaks makes it possible for users to partially upgrade their systems
to a broken combination.

Paul, please correct me if I'm mistaken above :)
-- 
Niko Tyni   nt...@debian.org

Bug#962135: zsh-common: "dpkg -l" completion should not proposed purged packages

[Vincent Lefevre]

Control: retitle -1 zsh-common: "dpkg -l" completion should not propose purged 
packages

On 2020-06-03 18:15:27 +0200, Vincent Lefevre wrote:
> "dpkg -l" proposes all packages known by apt-cache:
> 
> zira:~> dpkg -l [TAB]
> zsh: do you wish to see all 95490 possibilities (95491 lines)? 
> 
> For instance, in the completion list:
> 
> zira:~> dpkg -l abcde
> dpkg-query: no packages found matching abcde
> 
> Only packages with available information should be proposed, like
> "dpkg -s" (whose completion is currently buggy, see bug 962133).

Like for bug 962133, the fix should be easy: change avail
(which is used for "apt-cache show") to xinstalled. I'm going
to do some tests.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962084: Adding buster-backport to apt sources on install seems wrong

[Joseph Nuthalapati]

This is also being discussed on a Debian Salsa issue. Cross-linking.
https://salsa.debian.org/freedombox-team/freedombox/-/issues/1855

On 03/06/20 1:05 pm, Christian Ehrhardt wrote:
> Package: plinth
> Version: 20.10
> severity: serious
> 
> Hi,
> running into issues today I realized that the new freedombox 20.10
> places this file on disk:
> $ cat /etc/apt/sources.list.d/freedombox2.list
>   # This file is managed by FreedomBox, do not edit.
>   # Allow carefully selected updates to 'freedombox' from backports.
>   deb http://deb.debian.org/debian buster-backports main
>   deb-src http://deb.debian.org/debian buster-backports main
> 
> IMHO a package should not on-install mess with apt sources. Users just
> don't expect this or the follow on consequences that can happen.
> For example you are pinning python packages from backports which I'd
> expect might lead to quite some dependency hell with other things installed.
> 
> I was facing this in Ubuntu where it is even more wrong and essentially
> breaking `apt update`, but IMHO it is even wrong if not outright
> forbidden by some policy in Debian. I mean adding 'buster-backports' and
> pinning to them in e.g. 'sid' - to me that sounds like calling for trouble.
> 
> I'd ask you to reconsider and remove this behavior. If you want/need to
> keep it then maybe at least consider adding a skip if `dpkg-vendor
> --derives-from Ubuntu` is true. Would that work better for you?
> 
> -- 
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd

-- 
Regards,
Joseph Nuthalapati



signature.asc
Description: OpenPGP digital signature

Bug#962138: perl-base: libperl5.30 version skew can break essential functionality

[Niko Tyni]

Package: perl-base
Version: 5.30.2-1
Severity: serious

Our Perl package dependencies and search path arrangements allow
for a suitably versioned libperl5.30 package to break perl-base
functionality. This is bad as perl-base is Essential:yes and is therefore
required to stay functional at all times.

The specific version skew that triggers this is between minor upstream
versions, so for instance 5.30.2-1 -> 5.30.3-1, which are the current
version in testing and unstable.

The transcript at the end, from a current bullseye chroot with perl-base
and libperl5.30 but no perl installed, shows how perl-base can be
upgraded from sid without touching the other packages. After this, the
standard library in libperl5.30 is different version from perl-base but
has preference on the search path, causing version check bailouts and
breaking perl-base.

This works in the other direction too: if a newer version of libperl5.30
is unpacked, perl-base stops working in the same way. However,
the versioned dependency chain libperl5.30 -> perl-modules-5.30 (>=
${source:Version}) -> perl-base (>= ${Upstream-Version}-1) means that
libperl5.30 can't be configured in this combination.

The initial FTBFS of 5.30.3-1 on an arch:all sid buildd briefly resulted
in ideal conditions for this bug to trigger: unstable/amd64 then had
perl-modules-5.30 at version 5.30.2-1, but libperl5.30 and perl-base
at 5.30.3-1. Systems without the perl binary package were at that point
prone to upgrade to the newer perl-base while keeping perl-modules-5.30
and libperl5.30 at the old version. The autopkgtest checks of hkgerman
hit this when /usr/sbin/update-dictcommon-aspell (in dictionaries-common)
broke.

  https://ci.debian.net/data/autopkgtest/testing/arm64/h/hkgerman/5736806/log.gz

It's not clear to me what the practical effects of this issue are.
Pretty much all real systems have the perl binary package installed,
which seems to make apt unpack libperl5.30 and perl-base very close to
each other. We haven't had any upgrade failure reports from the recent
5.30.0 -> 5.30.1 upgrade FWIW.

Minor upstream version upgrades in testing/unstable have been relatively
rare in the past, and oldstable -> stable upgrades have always
incorporated a major version bump since the 5.10 times (squeeze), when
the dependencies and the package set were very different.

In any case, I think this needs to be fixed and should probably be
considered release critical.

I'm afraid this also means that a minor upstream version upgrade
in stable has a higher risk of breaking things, so maybe we should
reconsider #961443.

I see two ways of fixing this (but happy to entertain other suggestions too).

A) Move /usr/lib//perl-base up on the @INC search path. This is
   shipped in perl-base and includes the parts of the standard library
   we consider part of Essential:yes functionality. It's currently last
   on @INC. The libperl5.30 and perl-modules-5.30 packages include copies
   of these files, shipped in /usr/{lib,share}//perl/5.30,
   so that they can be used "standalone" for different architectures or
   major versions. The position of these copies higher on @INC makes this
   bug possible.

   IIRC I put /usr/lib//perl-base last because it's a nonstandard
   divergence from the upstream way of doing things, and I wanted it not
   to have an effect in the "normal" case when all the related packages
   are installed and configured. So it was only supposed to be a safeguard
   during upgrades and such. Clearly the safeguard is incomplete.

B) Do away with the /usr/{share,lib/x86_64-linux-gnu}/perl/5.30 -> 5.30.x
   symlinks currently shipped in libperl5.30 and perl-modules-5.30,
   and have the perl search path include the full upstream version. We
   tried this with the multiarch changes in 5.22 but reverted it with
   #787158 .  As I noted in that bug, this would mean that long running
   Perl programs could have @INC changed underneath them during version
   upgrades. This is not a showstopper by any means; we already have the
   'perl-major-upgrade' trigger for similar situations during major
   version upgrades, with at least some buy-in from packages like
   spamassassin IIRC.

I think A) is currently my preferred way of fixing this, and I think
the upstream "divergence" issue it creates is not very important. I
can envision some corner case regressions where standard library
modules expect other modules to be in the same directory, but those
seem improbable.

The main reason why I prefer option A is that it seems conceptually more
correct (improving the standalone properties of perl-base). Also, option
B may be harder to implement while keeping upgrade paths robust. But I
haven't really thought this through yet.

On a brighter note, either of these options would close #798626 :)

Apologies for my verbosity and thanks for reading through; ideas and
comments are naturally welcome. Despite the severity I don't think this
is particularly urgent, except with the possibly 

Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

[Dirk Eddelbuettel]

Conrad (of Armadillo fame) sent me this (and ok'ed passing it on):

  According to an Intel report back from 2011, -Bsymbolic-functions "is
  a dangerous option which can often result in some non-intuitive side
  effects".
  The report explicitly shows various problems with the option.
  
https://software.intel.com/content/www/us/en/develop/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects.html

  In the light of the above, it's a real wonder that Ubuntu uses the
  option at all.

  Perhaps Ubuntu developers meant well, but are not aware of the side effects ?

Graham do you think you can get it turned off for at least openblas?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#962134: add Sound Open Firmware

[Mark Pearson]

Hi,

Don't know if it helps but I raised #960788 on the same topic.
It has a few details on how other distro's have packaged it 
which might be helpful.

Once this is available I'm happy to do some testing.

Thanks
Mark

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

The issue is that
/usr/share/zsh/functions/Completion/Debian/_deb_packages
just considers packages in states install and hold:

_deb_packages_update_installed () {
  if ( [[ ${+_deb_packages_cache_installed} -eq 0 ]] ||
  _cache_invalid DEBS_installed ) && ! _retrieve_cache DEBS_installed;
  then
_deb_packages_cache_installed=()
dpkg --get-selections | while read package state ; do
[[ $state = (install|hold) ]] && _deb_packages_cache_installed+=$package
done
_store_cache DEBS_installed _deb_packages_cache_installed
  fi
  cachevar=_deb_packages_cache_installed
}

Instead, any state should be valid for "dpkg -s" completion.
It seems that this is what _deb_packages_update_xinstalled does:

xinstalled () {
  if ( [[ ${+_deb_packages_cache_xinstalled} -eq 0 ]] ||
  _cache_invalid DEBS_xinstalled ) && ! _retrieve_cache DEBS_xinstalled;
  then
_deb_packages_cache_xinstalled=()
dpkg --get-selections | while read package state ; do
_deb_packages_cache_xinstalled+=$package
done
_store_cache DEBS_xinstalled _deb_packages_cache_xinstalled
  fi
  cachevar=_deb_packages_cache_xinstalled
}

So the fix should be easy: in
/usr/share/zsh/functions/Completion/Debian/_dpkg

  remove|status|listfiles)
_call_function ret _dpkg_$state && return ret
_arguments -C -A "-*" -s "$_dpkg_options[@]" \
   '*:package:_deb_packages installed'
  ;;
  purge)
_call_function ret _dpkg_$state && return ret
_arguments -C -A "-*" -s "$_dpkg_options[@]" \
   '*:package:_deb_packages xinstalled'
  ;;

move "status" and "listfiles" to "purge" (which uses xinstalled).

Still, "remove" and "purge" would remain inconsistent, which
is another bug...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Hi Paul

Ok mystery solved :). Once I have this fixed, what should I do? Push
the new tarball with the same version (1.0.1-1) or should I bump
something in the version? I'd expect that perhaps that -1 should
become a -2? If so, what's the correct way of doing this?

Cheers,
Gabriele

On Wed, 3 Jun 2020 at 16:36, Paul Gevers  wrote:
>
> Hi Gabriele,
>
> On 02-06-2020 23:37, Gabriele wrote:
> > Many thanks for your reply. I have had a look at the logs linked on this 
> > page
> >
> > https://ci.debian.net/packages/a/austin/testing/amd64/
> >
> > The only version that passes is v1.0.0 and by looking at the logs of
> > v0.7.0 and v1.0.1, which fail, it's a miracle that v1.0.0 even passes.
> > Indeed v0.7.0 and v1.0.1 fail for the very same reason: the binary
> > used for the tests, src/austin, is simply not there. Why it is there
> > for the v1.0.0 I don't know, so it looks like the problem is with
> > v1.0.0 paradoxically.
>
> It's funny, the first tries of 1.0.0 also failed. And I believe they
> they only starting passing when python3.7 was not the default Python3
> anymore.
>
> > This is the diff inside the debian/ folder between v1.0.0 and v1.0.1
> > (TLDR: only debian/austin.1, debian/changelog and debian/copyright
> > have changed)
>
> Instead, I diffed the source and this struck my eye:
>
> diff -Nru austin-1.0.0/test/test_fork.bats austin-1.0.1/test/test_fork.bats
> --- austin-1.0.0/test/test_fork.bats2019-10-19 10:37:23.0 +
> +++ austin-1.0.1/test/test_fork.bats2020-02-21 19:27:02.0 +
> @@ -56,6 +56,12 @@
>then
>  skip "Test failed but marked as 'Ignore'"
>else
> +echo
> +echo "Collected Output"
> +echo ""
> +echo
> +echo "$output"
> +echo
>  false
>fi
>  }
> @@ -109,6 +115,6 @@
>invoke_austin "3.7"
>  }
>
> -# @test "Test Austin with Python 3.8" {
> -#   invoke_austin "3.8"
> -# }
> +@test "Test Austin with Python 3.8" {
> +  invoke_austin "3.8"
> +}
>
> So, with 1.0.0 your tests were passing because all tests were skipped,
> and only with 1.0.1 your tests started testing the code again and failed
> because the required binary couldn't be found.
>
>
> > Hence, to the best of my knowledge, there are no changes in the
> > debian/ area that would cause the binary in src/ to be there unless it
> > accidentally ended up, say, in the source tarball.
>
> I think I've showed an alternative explanation.
>
> > My next question to you is then: where is the binary supposed to be
> > found during autopkgtest? Can I assume it will be on the PATH during
> > testing, so that I can invoke it simply with "austin"? Or do I need to
> > specify a precise path?
>
> The testbed is a clean Debian installation, created with debbootstrap
> and only your test dependencies installed. Everything is in it's regular
> location, so if austin is on the regular path for users, it on the
> regular path for the debci user in the testbed. Not specifying the
> precise path makes sure your testing that it's on the path for your
> users too, so better without path.
>
> Paul
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#962137: FTBFS when building architecture independent packages only

[Daniel Baumann]

Package: nghttp2
Version: 1.41.0-1
Severity: normal

Hi,

when building nghttp2 arch-indep packages only (aka dpkg-buildpackage
-A), it currently fails:

---snip---
   dh_prep -i
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/build/nghttp2-1.41.0-1'
mkdir -p "debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"
cp -pr doc/manual/html/*
"debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"
rm "debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"/objects.inv
ln -sf /usr/share/javascript/jquery/jquery.js
"debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"/_static/jquery.js
ln -sf /usr/share/javascript/underscore/underscore.js
"debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"/_static/underscore.js
dh override_dh_auto_install-indep
make[1]: Leaving directory '/build/nghttp2-1.41.0-1'
   dh_install -i
   dh_installdocs -i
dh_installdocs: Cannot find (any matches for)
"usr/share/doc/nghttp2/README.rst" (tried in ., debian/tmp)

make: *** [debian/rules:68: binary-indep] Error 9
---snap

Regards,
Daniel

Bug#962136: FTBFS on i386 because of .la files

[Daniel Baumann]

Package: nghttp2
Version: 1.41.0-1
Severity: serious

Hi,

when building nghttp2 on i386 it fails to build at dh_missing because
debian/tmp/usr/lib/*/*.la is not included in any package (which is correct).

I suggest to add a 'rm -f debian/tmp/usr/lib/*/*.la' after the
dh_auto_install in rules.

Regards,
Daniel

Bug#962135: zsh-common: "dpkg -l" completion should not proposed purged packages

[Vincent Lefevre]

Package: zsh-common
Version: 5.8-4
Severity: normal
Tags: upstream

"dpkg -l" proposes all packages known by apt-cache:

zira:~> dpkg -l [TAB]
zsh: do you wish to see all 95490 possibilities (95491 lines)? 

For instance, in the completion list:

zira:~> dpkg -l abcde
dpkg-query: no packages found matching abcde

Only packages with available information should be proposed, like
"dpkg -s" (whose completion is currently buggy, see bug 962133).

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  curl   7.68.0-1 amd64command line tool for transferring 
data with URL syntax
ii  pass   1.7.3-2  all  lightweight directory-based 
password manager
ii  pulseaudio 13.0-5   amd64PulseAudio sound server
ii  qpdf   10.0.1-2 amd64tools for transforming and 
inspecting PDF files
ii  systemd245.5-3  amd64system and service manager
ii  udev   245.5-3  amd64/dev/ and hotplug management daemon
ii  vlc-bin3.0.10-1+b1  amd64binaries from VLC
ii  youtube-dl 2020.05.08-1 all  downloader of videos from YouTube 
and other sites

The following files were modified:

/etc/systemd/journald.conf
/etc/systemd/logind.conf
/etc/systemd/system.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

zsh-common depends on no packages.

Versions of packages zsh-common recommends:
ii  zsh  5.8-4

Versions of packages zsh-common suggests:
ii  zsh-doc  5.8-4

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962134: add Sound Open Firmware

[Moritz Mühlenhoff]

On Wed, Jun 03, 2020 at 05:25:21PM +0200, Marek Straka wrote:
> Package: firmware-linux-nonfree
> Version: 20190717-2
> Severity: normal
> 
> 
> Add Sound Open Firmware:
> https://github.com/thesofproject/sof-bin
> https://www.sofproject.org/

This is free software and could go into main or am I missing something?

Cheers,
Moritz

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

On 2020-06-03 17:45:11 +0200, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > Actually there's another one:
> > 
> > zira:~> dpkg -l | grep '^rc'
> > rc  openntpd   1:6.0p1-1
> >amd64OpenBSD NTP daemon
> 
> All packages shown as "rc" by dpkg on my system seem _not_ to be
> installed but are usually removed, but not purged. Example:

They are not installed, but are valid candidates for "dpkg -s"
arguments.

> From the design of the current implementation (only show installed
> packages for "dpkg -s" completion)

Currently this is: installed and not marked to be uninstalled
(or to be purged).

> it is correct that "dpkg -s" doesn't complete these packages.

This is not correct. "dpkg -s" should complete to any valid
argument, i.e. for which package information is available
(thus this excludes purged packages). This is a real bug.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

On 2020-06-03 17:34:44 +0200, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > The package libplacebo7 is installed, but "dpkg -s" completion does
> > not propose it:
> [...]
> > According to "dpkg -s [TAB]", it seems to be the only missing package.
> > I don't know what is particular with it, except that it is marked to
> > be purged.
> 
> "marked to be purged" in which application? Aptitude?

Yes, aptitude: before completing the upgrade (at the apt-listchanges
step), I wanted to have a look at the package description. But this
is not local to aptitude: aptitude just tells dpkg that the package
needs to be purged. I think that this is equivalent to what
"dpkg --set-selections" does.

> > But it is not purged yet, so that there is no reason to
> > take that into account.
> 
> I wonder if this could also be related to the fact that libplacebo7 is
> currently no more in Debian Unstable, just in Debian Testing:
> 
> → apt-cache policy libplacebo7
> libplacebo7:
>   Installed: (none)
>   Candidate: 1.7.0-2
>   Version table:
>  1.7.0-2 600
> 600 https://debian.ethz.ch/debian testing/main amd64 Packages

No, on another machine on which I haven't started the upgrade, the
completion is fine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Axel Beckert]

Control: severity -1 wishlist
Control: tag -1 + upstream

Hi Vincent,

Vincent Lefevre wrote:
> Actually there's another one:
> 
> zira:~> dpkg -l | grep '^rc'
> rc  openntpd   1:6.0p1-1  
>  amd64OpenBSD NTP daemon

All packages shown as "rc" by dpkg on my system seem _not_ to be
installed but are usually removed, but not purged. Example:

→ dpkg -l snapper
[...]
rc  snapper0.8.1-1  amd64Linux filesystem snapshot 
management tool
→ aptitude show snapper
Package: snapper
Version: 0.8.9-1+b1
State: not installed (configuration files remain)
[...]
→ dpkg -s sn
completing package
snetz  sniffglue  snooze snowdrop   sntop

>From the design of the current implementation (only show installed
packages for "dpkg -s" completion) it is correct that "dpkg -s"
doesn't complete these packages.

But it seems a valid point that especially the "dpkg -s" completion
also completes packages where only configuration files remain.

So from my point of view, this is a valid feature request for
upstream. Marking it as such.

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

Bug#962132: dropbear-initramfs should be Suggests not Recommends

[Guilhem Moulin]

Control: severity -1 wishlist

Hi Matt,

On Wed, 03 Jun 2020 at 15:20:25 +, Matt Johnston wrote:
> The dropbear package currently has Recommends: dropbear-initramfs
> so installing dropbear pulls in 30MB of other initramfs-related packages
> not needed for a container. "Suggests" would seem more appropriate going by
> the policy manual "The Recommends field should list packages that would be 
> found together with this one in all but unusual installations"

That's the plan, but it'll need to wait until Bullseye is released.  At
the moment the Breaks/Replaces/Recommends: dance is still necessary to
guaranty a smooth upgrade path after the package split (from dropbear to
dropbear-{run,initramfs}) and subsequent rename (from dropbear-run to
dropbear).  One can of course always install with --no-install-recommends
to avoid pulling the initramfs stuff :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong

[Al Stone]

On 03 Jun 2020 14:30, Petter Reinholdtsen wrote:
> 
> Could
> https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html >
> contain the key to why these test are failing?  It states
> 
>   "The cwd of each test is guaranteed to be the root of the source
>   package, which will have been unpacked but not built. However note
>   that the tests must test the installed version of the program. Tests
>   may not modify the source tree (and may not have write access to it)."

Hrm.  So write access seems to be more constrained than this led
me to believe; I'll try these patches out and rebuild tonight.  I
did think about using AUTOPKGTEST_TMP but had not convinced myself
it was absolutely required.

Thank you for all the help, Petter!

> If so, the following patch might help:
> 
> diff --git a/debian/tests/hello b/debian/tests/hello
> index 60943be..15c3985 100755
> --- a/debian/tests/hello
> +++ b/debian/tests/hello
> @@ -1,4 +1,5 @@
>  #!/bin/sh
> +cd $AUTOPKGTEST_TMP
>  cat > HELLO.cob<  HELLO * HISTORIC EXAMPLE OF HELLO WORLD IN COBOL
> IDENTIFICATION DIVISION.
> diff --git a/debian/tests/test01 b/debian/tests/test01
> index 22d943e..783901b 100755
> --- a/debian/tests/test01
> +++ b/debian/tests/test01
> @@ -2,10 +2,10 @@
>  cd debian/tests
>  
>  echo "info: compiling"
> -(cobc test01.cob > test01.act 2>&1)
> +(cobc test01.cob > $AUTOPKGTEST_TMP/test01.act 2>&1)
>  
>  echo "info: running"
> -cmp -s test01.exp test01.act
> +cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act
>  res=$?
>  if [ $res ] ; then
>  echo "success: test01 produced proper results"
> diff --git a/debian/tests/test02 b/debian/tests/test02
> index 2e06f74..99f0978 100755
> --- a/debian/tests/test02
> +++ b/debian/tests/test02
> @@ -2,10 +2,10 @@
>  cd debian/tests
>  
>  echo "info: compiling"
> -(cobc test02.cob > test02.act 2>&1)
> +(cobc test02.cob > $AUTOPKGTEST_TMP/test02.act 2>&1)
>  
>  echo "info: running"
> -cmp -s test02.exp test02.act
> +cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act
>  res=$?
>  if [ $res ] ; then
>  echo "success: test02 produced proper results"
> diff --git a/debian/tests/test03 b/debian/tests/test03
> index f378787..701ade9 100755
> --- a/debian/tests/test03
> +++ b/debian/tests/test03
> @@ -2,10 +2,10 @@
>  cd debian/tests
>  
>  echo "info: compiling"
> -(cobc test03.cob > test03.act 2>&1)
> +(cobc test03.cob > $AUTOPKGTEST_TMP/test03.act 2>&1)
>  
>  echo "info: running"
> -cmp -s test03.exp test03.act
> +cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act
>  res=$?
>  if [ $res ] ; then
>  echo "success: test03 produced proper results"
> diff --git a/debian/tests/test04 b/debian/tests/test04
> index 04b325e..c50b157 100755
> --- a/debian/tests/test04
> +++ b/debian/tests/test04
> @@ -2,10 +2,10 @@
>  cd debian/tests
>  
>  echo "info: compiling"
> -(cobc test04.cob > test04.act 2>&1)
> +(cobc test04.cob > $AUTOPKGTEST_TMP/test04.act 2>&1)
>  
>  echo "info: running"
> -cmp -s test04.exp test04.act
> +cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act
>  res=$?
>  if [ $res ] ; then
>  echo "success: test04 produced proper results"
> 
> -- 
> Happy hacking
> Petter Reinholdtsen
> 

-- 
Ciao,
al
--
Al Stone Debian Developer
E-mail: a...@ahs3.nethttp://www.debian.org
 a...@debian.org
--

Bug#933930: network-manager: Ethernet connection no longer works

[Andy Mann]

  
  
I note there are "carrier-changed" errors in this report.


  I had "carrier-changed" errors, frequently disconnecting my
ethernet, and after trying every solution in multiple forums, I
finally upgraded the CAT5 cable to a CAT7 cable (10 meter run -
cheap on ebay) which cured the problem. Apparently, the old CAT5
cable couldn't handle my ISP's upgraded speeds (Virgin Media,
UK). The new CAT7 cable has not only stopped the dropouts, but
also now allows the speed to auto-configure from 100Mb/s to
1000Mb/s.
Hope that helps anyone looking to fix "carrier-changed"
problems.

Andy, UK
---
On Mon, 5 Aug 2019 11:20:24 +0200 Vincent Lefevre
 wrote:
> Package: network-manager
> Version: 1.19.90-2
> Severity: grave
> Justification: renders package unusable
> 
> After upgrading to 1.19.90-2 and rebooting my machine, I
completely
> lost Ethernet connection.
> 
> cventin:~> journalctl -b -2 -g network
> -- Logs begin at Tue 2016-04-19 07:35:01 CEST, end at Mon
2019-08-05 11:12:14 CEST. --
> Aug 05 10:52:53 cventin kernel: e1000e: Intel(R) PRO/1000
Network Driver - 3.2.6-k
> Aug 05 10:52:53 cventin kernel: e1000e :00:19.0 eth0:
Intel(R) PRO/1000 Network Connection
> Aug 05 10:52:53 cventin ifup[485]: /bin/run-parts
--exit-on-error --verbose /etc/network/if-pre-up.d
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-pre-up.d/ethtool
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-pre-up.d/wpasupplicant
> Aug 05 10:52:53 cventin ifup[485]: /bin/run-parts
--exit-on-error --verbose /etc/network/if-pre-up.d
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-pre-up.d/ethtool
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-pre-up.d/wpasupplicant
> Aug 05 10:52:53 cventin ifup[485]: /bin/run-parts
--exit-on-error --verbose /etc/network/if-up.d
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/avahi-daemon
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/ethtool
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/mountnfs
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/wpasupplicant
> Aug 05 10:52:53 cventin ifup[485]: /bin/run-parts
--exit-on-error --verbose /etc/network/if-up.d
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/avahi-daemon
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/ethtool
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/mountnfs
> Aug 05 10:52:53 cventin ifup[485]: run-parts: executing
/etc/network/if-up.d/wpasupplicant
> Aug 05 10:52:54 cventin systemd[1]: Starting Network Time
Synchronization...
> Aug 05 10:52:55 cventin systemd[1]: Started Network Time
Synchronization.
> Aug 05 10:52:55 cventin systemd[1]: Starting Network Manager...
> Aug 05 10:52:55 cventin NetworkManager[789]: 
[1564995175.9222] NetworkManager (version 1.19.90) is starting...
(for the first time)
> Aug 05 10:52:55 cventin NetworkManager[789]: 
[1564995175.9223] Read config:
/etc/NetworkManager/NetworkManager.conf (lib:
no-mac-addr-change.conf)
> Aug 05 10:52:55 cventin NetworkManager[789]: 
[1564995175.9223] config: unknown key 'wifi.cloned-mac-address' in
section [device-mac-addr-change-wifi] of file
'/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
> Aug 05 10:52:55 cventin NetworkManager[789]: 
[1564995175.9223] config: unknown key 'ethernet.cloned-mac-address'
in section [device-mac-addr-change-wifi] of file
'/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
> Aug 05 10:52:55 cventin NetworkManager[789]: 
[1564995175.9251] bus-manager: acquired D-Bus service
"org.freedesktop.NetworkManager"
> Aug 05 10:52:55 cventin NetworkManager[789]: 
[1564995175.9316] monitoring ifupdown state file
'/run/network/ifstate'.
> Aug 05 10:52:55 cventin dbus-daemon[788]: [system] Activating
systemd to hand-off: service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.5'
(uid=0 pid=789 comm="/usr/sbin/NetworkManager --no-daemon ")
> Aug 05 10:52:56 cventin avahi-daemon[780]: Network interface
enumeration completed.
> Aug 05 10:52:56 cventin systemd[1]: Started Network Manager.
> Aug 05 10:52:56 cventin systemd[1]: Starting Network Manager
Wait Online...
> Aug 05 10:52:56 cventin systemd[1]: Reached target Network.
> Aug 05 10:52:57 cventin NetworkManager[789]: 

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Axel Beckert]

Hi,

Vincent Lefevre wrote:
> The package libplacebo7 is installed, but "dpkg -s" completion does
> not propose it:
[...]
> According to "dpkg -s [TAB]", it seems to be the only missing package.
> I don't know what is particular with it, except that it is marked to
> be purged.

"marked to be purged" in which application? Aptitude?

> But it is not purged yet, so that there is no reason to
> take that into account.

I wonder if this could also be related to the fact that libplacebo7 is
currently no more in Debian Unstable, just in Debian Testing:

→ apt-cache policy libplacebo7
libplacebo7:
  Installed: (none)
  Candidate: 1.7.0-2
  Version table:
 1.7.0-2 600
600 https://debian.ethz.ch/debian testing/main amd64 Packages

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

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Paul Gevers]

Hi Gabriele,

On 02-06-2020 23:37, Gabriele wrote:
> Many thanks for your reply. I have had a look at the logs linked on this page
> 
> https://ci.debian.net/packages/a/austin/testing/amd64/
> 
> The only version that passes is v1.0.0 and by looking at the logs of
> v0.7.0 and v1.0.1, which fail, it's a miracle that v1.0.0 even passes.
> Indeed v0.7.0 and v1.0.1 fail for the very same reason: the binary
> used for the tests, src/austin, is simply not there. Why it is there
> for the v1.0.0 I don't know, so it looks like the problem is with
> v1.0.0 paradoxically.

It's funny, the first tries of 1.0.0 also failed. And I believe they
they only starting passing when python3.7 was not the default Python3
anymore.

> This is the diff inside the debian/ folder between v1.0.0 and v1.0.1
> (TLDR: only debian/austin.1, debian/changelog and debian/copyright
> have changed)

Instead, I diffed the source and this struck my eye:

diff -Nru austin-1.0.0/test/test_fork.bats austin-1.0.1/test/test_fork.bats
--- austin-1.0.0/test/test_fork.bats2019-10-19 10:37:23.0 +
+++ austin-1.0.1/test/test_fork.bats2020-02-21 19:27:02.0 +
@@ -56,6 +56,12 @@
   then
 skip "Test failed but marked as 'Ignore'"
   else
+echo
+echo "Collected Output"
+echo ""
+echo
+echo "$output"
+echo
 false
   fi
 }
@@ -109,6 +115,6 @@
   invoke_austin "3.7"
 }

-# @test "Test Austin with Python 3.8" {
-#   invoke_austin "3.8"
-# }
+@test "Test Austin with Python 3.8" {
+  invoke_austin "3.8"
+}

So, with 1.0.0 your tests were passing because all tests were skipped,
and only with 1.0.1 your tests started testing the code again and failed
because the required binary couldn't be found.


> Hence, to the best of my knowledge, there are no changes in the
> debian/ area that would cause the binary in src/ to be there unless it
> accidentally ended up, say, in the source tarball.

I think I've showed an alternative explanation.

> My next question to you is then: where is the binary supposed to be
> found during autopkgtest? Can I assume it will be on the PATH during
> testing, so that I can invoke it simply with "austin"? Or do I need to
> specify a precise path?

The testbed is a clean Debian installation, created with debbootstrap
and only your test dependencies installed. Everything is in it's regular
location, so if austin is on the regular path for users, it on the
regular path for the debci user in the testbed. Not specifying the
precise path makes sure your testing that it's on the path for your
users too, so better without path.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

Actually there's another one:

zira:~> dpkg -l | grep '^rc'
rc  openntpd   1:6.0p1-1   
amd64OpenBSD NTP daemon
zira:~> dpkg -s openntpd
Package: openntpd
Status: deinstall ok config-files
Priority: optional
Section: net
[...]

but "dpkg -s openn[TAB]" does not give any completion.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962073: alsa-info is calling home without asking

[Elimar Riesebieter]

* Christoph Berg  [2020-06-02 23:23 +0200]:

> Package: alsa-utils
> Version: 1.2.2-1
> Severity: serious
> 
> Hi,
> 
> I just launched alsa-info and was surprised that it presented me with
> this popup box:
> 
> ┌───┐
> │ Newer version of ALSA-Info has been   │
> │ found │
> │   │
> │ Do you wish to download it?   │
> ├───┤
> │ < Yes > < No  >   │
> └───┘
> 
> Note that this box comes before it asks if the generated report should
> be uploaded somewhere.
> 
> I don't think it is appropriate for a simple CLI utility to call home
> without asking first.

What do you mean with "call home"?

There is indeed a new version available in [0] and [1]. It will be
contributed witch the next release of alsa-utils. So what makes this
"bug" serious?

[0] 
https://git.alsa-project.org/?p=alsa-utils.git;a=history;f=alsa-info/alsa-info.sh
[1] https://git.alsa-project.org/?p=alsa-utils.git;a=summary

Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)

Bug#961994: src:libcatmandu-perl: fails to migrate to testing for too long: causes autopkgtest regression

[Paul Gevers]

Control: notfound 961994 1.2012-1
Control: found 961994 1.1000-2

On 01-06-2020 19:54, Paul Gevers wrote:
> Source: libcatmandu-perl
> Version: 1.2012-1
> Severity: serious
> Control: close -1 1.2012-1

Oops, logical mistake there. The Version: line should have read the
version in testing. (Hopefully) fixing with this message.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#962134: add Sound Open Firmware

[Marek Straka]

Package: firmware-linux-nonfree
Version: 20190717-2
Severity: normal


Add Sound Open Firmware:
https://github.com/thesofproject/sof-bin
https://www.sofproject.org/



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

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

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20190717-2
ii  firmware-misc-nonfree  20190717-2

Versions of packages firmware-linux-nonfree recommends:
pn  amd64-microcode  
pn  intel-microcode  

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

Package: zsh-common
Version: 5.8-4
Severity: normal

The package libplacebo7 is installed, but "dpkg -s" completion does
not propose it:

zira:~> dpkg -s libplacebo7
Package: libplacebo7
Status: purge ok installed
Priority: optional
Section: libs
Installed-Size: 2332
Maintainer: Debian Multimedia Maintainers 
Architecture: amd64
Multi-Arch: same
Source: libplacebo
Version: 1.7.0-2
[...]

zira:~> dpkg -s libpl[TAB]
Completing package
libplack-perl libplexus-interpolation-java
libplexus-archiver-java   libplexus-io-java   
libplexus-cipher-java libplexus-sec-dispatcher-java   
libplexus-classworlds-javalibplexus-utils2-java   
libplexus-component-annotations-java  libplot2c2:amd64

According to "dpkg -s [TAB]", it seems to be the only missing package.
I don't know what is particular with it, except that it is marked to
be purged. But it is not purged yet, so that there is no reason to
take that into account.

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  curl   7.68.0-1 amd64command line tool for transferring 
data with URL syntax
ii  pass   1.7.3-2  all  lightweight directory-based 
password manager
ii  pulseaudio 13.0-5   amd64PulseAudio sound server
ii  qpdf   10.0.1-2 amd64tools for transforming and 
inspecting PDF files
ii  systemd245.5-3  amd64system and service manager
ii  udev   245.5-3  amd64/dev/ and hotplug management daemon
ii  vlc-bin3.0.10-1 amd64binaries from VLC
ii  youtube-dl 2020.05.08-1 all  downloader of videos from YouTube 
and other sites

The following files were modified:

/etc/systemd/system.conf
/etc/systemd/logind.conf
/etc/systemd/journald.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

zsh-common depends on no packages.

Versions of packages zsh-common recommends:
ii  zsh  5.8-4

Versions of packages zsh-common suggests:
ii  zsh-doc  5.8-4

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962132: dropbear-initramfs should be Suggests not Recommends

[Matt Johnston]

Package: dropbear
Version: 2019.78-2
Severity: normal

The dropbear package currently has Recommends: dropbear-initramfs
so installing dropbear pulls in 30MB of other initramfs-related packages
not needed for a container. "Suggests" would seem more appropriate going by
the policy manual "The Recommends field should list packages that would be 
found together with this one in all but unusual installations"

Thanks,
Matt

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

Kernel: Linux 5.3.0-46-generic (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=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_US.UTF-8 
(charmap=locale: Cannot set LC_CTYPE to default locale: No such file or 
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968) (ignored: LC_ALL set to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dropbear depends on:
pn  dropbear-bin  
ii  lsb-base  11.1.0

Versions of packages dropbear recommends:
pn  dropbear-initramfs  

Versions of packages dropbear suggests:
pn  runit  

Bug#913997: what is the current maintainer view on this ?

[Antonio Terceiro]

On Tue, May 26, 2020 at 08:05:31PM +0200, Paolo Greppi wrote:
> The issue has been raised again on the yarnpkg side:
> https://bugs.debian.org/940511
> 
> Antonio, what is your point of view ?
> Do you think we can fix this for the Bookworm release ?

I think that the people who created this problem in the first place
showed no empathy and were not flexible at all even after presented with
evidence that there were existing projects from before theirs that were
already using the yarn name.

I agree with the original maintainer that this namespace takeover
attempt feels like bullying. "Mine is bigger than yours" is not a good
argument for anything in Debian.

I have a lot of other priorities, and I only adopted cmdtest to keep
vmdb2 in testing since autopkgtest uses it for building vm images.  I
don't plan to spend a single minute of my time working towards changing
the status quo (with a caveat, see below).

Now, with that said, I understand that the current situation creates a
technical problem for a growing ecosystem in Debian. Unfortunately I
don't have any easy solution to propose.

I will not block technical work to solve this in the correct way, and as
gatekeeper that will need to be involved in a solution I will review and
apply patches that make sense.

Dropping the Provides: would be relatively easy.

Renaming the binary is harder, because there are at least two packages
that use yarn from cmdtest during the build: gitano and vmdb2. they
would need to be ported, and that's up to their maintainers and
upstreams, who I assume won't be happy about it.


signature.asc
Description: PGP signature

Bug#962102: ltunify, something to review

[Geert Stappers]

On Wed, Jun 03, 2020 at 12:40:08PM +0100, Anthony Perkins wrote:
> 
> Having looked into Solaar, I like the look of it, and it does have more
> features. However, it is a Python Gtk application and requires Gtk to build.
> 
> I therefore believe there might still be a use for ltunify, as it is a
> very small (35 kB) console application that has almost no build
> dependencies.
> 
> I believe this might be a good argument for including both. I have done
> the packaging work already in my personal Gitea repo. I can push this to
> Salsa for review if that would be useful.

Yes, make review possible.


Regards
Geert Stappers
(to be poked in four weeks)
-- 
Silence is hard to parse

Bug#962131: sqlite3 breaks python3.8 autopkgtest: CheckFuncDeterministic (sqlite3.test.userfunctions.FunctionTests)

[Paul Gevers]

Source: sqlite3, python3.8
Control: found -1 sqlite3/3.32.1-2
Control: found -1 python3.8/3.8.3-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of sqlite3 the autopkgtest of python3.8 fails in
testing when that autopkgtest is run with the binary packages of sqlite3
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
sqlite3from testing3.32.1-2
python3.8  from testing3.8.3-1
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 sqlite3 to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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=sqlite3

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.8/5744312/log.gz

test_progress (sqlite3.test.backup.BackupTests) ... ok
test_progress_all_pages_at_once_1 (sqlite3.test.backup.BackupTests) ... ok
test_progress_all_pages_at_once_2 (sqlite3.test.backup.BackupTests) ... ok
test_simple (sqlite3.test.backup.BackupTests) ... ok

==
FAIL: CheckFuncDeterministic (sqlite3.test.userfunctions.FunctionTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.8/sqlite3/test/userfunctions.py", line 290, in
CheckFuncDeterministic
self.assertEqual(mock.call_count, 1)
AssertionError: 2 != 1

--

Ran 286 tests in 0.404s

FAILED (failures=1, skipped=2)
test test_sqlite failed
1 test failed again:
test_sqlite



signature.asc
Description: OpenPGP digital signature

Bug#962130: r-cran-isospec: wrong name for R package

[Dylan Aïssi]

Package: r-cran-isospec
Version: 1.9.1-1
Severity: important

Hi,

isospec provides an R package (r-cran-isospec), but looking at the
IsoSpecR/DESCRIPTION file the name should be r-cran-isospecr (i.e.
with a final "R"). This is also confirmed by the package name at CRAN
(https://cran.r-project.org/package=IsoSpecR). This binary package
must be renamed.

Moreover, the d/rules file is bugged (would required another bug
report but lets talk a bit about it here for now) because the variable
{R:Depends} is not substituted. Consequently, the binary R package has
wrong dependencies (no dependency to r-base-core, r-api-, etc). As you
need to upload to NEW to fix the name of the package, it is possible
to split the source package and to use the archive from CRAN for the R
package. This will simplify the d/rules and fix the second issue.

Your package, your decision ;-)

Best,
Dylan

Bug#954301: ITP: python-rich -- library for rendering rich text and beautiful formatting to the terminal

[Chris Lamb]

merge 954301 962028
thanks

> I already filed an ITP for rich

Ok, let's merge these. I am also looking forward to this package
appearing in Debian.


Regards,

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

Bug#958888: ITP: pytorch -- Tensors and Dynamic neural networks in Python with strong GPU acceleration

[Mo Zhou]

Hi Petter,

Sorry. Nothing new except for the packages pending in NEW.

On Wed, Jun 03, 2020 at 02:13:52PM +0200, Petter Reinholdtsen wrote:
> [Mo Zhou]
> > I've uploaded all the necessary build dependencies to the NEW queue.
> > Now I'm waiting for the upstream to merge my pull requests.
> > 
> > will be maintained under Debian Deep Learning Team
> 
> Hi.  Any news on this?  See there are two versions pending in NEW.
> 
> -- 
> Happy hacking
> Petter Reinholdtsen

Bug#962129: ITP: xgboost -- Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library, for Python, R, Java, Scala, C++ and more

[zhao feng]

Package: wnpp
Severity: wishlist
Owner: zhaofeng 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org


* Package name: xgboost
  Version : 1.1.0
  Upstream Author : 
* URL : http://www.xgboost.ai/
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : Scalable, Portable and Distributed Gradient
Boosting (GBDT, GBRT or GBM) Library, for Python, R, Java, Scala, C++
and more

XGBoost is an optimized distributed gradient boosting library designed
to be highly efficient, flexible and portable. It implements machine
learning algorithms under the Gradient Boosting framework. XGBoost
provides a parallel tree boosting (also known as GBDT, GBM) that solve
many data science problems in a fast and accurate way. The same code
runs on major distributed environment (Hadoop, SGE, MPI) and can solve
problems beyond billions of examples.

XGBoost is useful in Data Science, Machine Learning and related area.
I suggest the package should be maintained within
DebianScience/Statistics if adopted and I am planning to package it.
Co-maintainers are welcome.

Bug#962009: Bug#962008: RFS: ca-certificates/20200601 [RC] -- Common CA certificates

[Adrian Bunk]

On Wed, Jun 03, 2020 at 08:40:02AM -0500, Michael Shuler wrote:
>...
> Generally, expiry date has not been an issue remaining in the bundle until
> removal upstream, since the certification authorities have managed migration
> to new roots well and openssl>=1.1.1 handles this gracefully. This appears
> to have not been the case with AddTrust and older openssl<1.1.1 bug, as that
> fix was not backported, to the best of my understanding.

gnutls has the same problem (#961889).

But you do have a point that libraries are supposed to handle this 
situation gracefully.

>...
> Re: security uploads:
> 
> I have received no reply from the security team, as of this message, so
> awaiting their OK/advice. Copy of email sent to team@security, since there
> is no secret info in here:
>...

Please wait for an ACK from the security team before making uploads
to -security or asking others to do so.

While maintainers are allowed to update their packages quite freely
in unstable (with some exceptions like library transitions ot the
freeze before a release), uploads to *-security and stable distributions 
need an ACK first.

> Kind regards,
> Michael

cu
Adrian

Bug#868220: ifupdown should support vlan-aware bridges

[Benedikt Spranger]

On Wed, 3 Jun 2020 13:50:56 +0200
Santiago Garcia Mantinan  wrote:

Hi,

sorry for the trouble.
> > the problem is I get operation not supported when setting
> > vlan_filtering 0 on my bridge, does the else really make sense
> > here?  
Unfortunately yes.
The brigde is configured at runtime and can be reconfigured. Without the
else part a user is forced to unset the filtering by hand if set by
try/error/accident.

> Well, this was added due to bugs.debian.org/950879 reported by
> Benedikt who kindly supplied the patch, the patch didn't cause any
> trouble on the tests I did and that's why I applied it like he sent
> it.
> 
> I have added Benedikt to my reply for him to comment on this.
OK.
 
> As I understand it, Gianluigi, if we remove the else there we won't
> set vlan filtering to 0 and thus you won't get the error, right?
>
> We have two options here, one is to remove it and the other to send
> the possible errors on the setting to 0 case to /dev/null.
May I introduce a third option?
I am not shure, if that pseudo file exists on every supported kernel,
but you got the idea. If that is prefered, i can dig through the kernel
sources and provide a patch.

NOTE: untested!
---8<---
# Activate VLAN filtering on VLAN aware bridges
   
if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then
  ip link set dev $IFACE type bridge vlan_filtering 1   
else
  if [ -f /sys/devices/virtual/net/$IFACE/bridge/vlan_filtering ]; then
ip link set dev $IFACE type bridge vlan_filtering 0
  fi
fi
---8<---

I do not like to paper over errors like sending them to /dev/null.
But I prefer that option over droping the else part.

Regards
Benedikt Spranger

Bug#960984: ITP: google-http-client-java -- Google HTTP Client Library for Java

[Olek Wojnar]

Hi Sudip,

On Wed, Jun 3, 2020 at 7:43 AM Sudip Mukherjee 
wrote:

>
> Do you know which modules from google-auth you will need? I think thats
> #959830.
>

Yes, I do: google-auth-library-credentials.jar,
google-auth-library-oauth2-http.jar. Take a look at [1], we've got lots of
good info there. Please let me know if anything is missing or you have any
other questions. We appreciate any assistance!

-Olek

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1