Bug#911048: libadios-{mpich,openmpi}-dev: broken symlink: /usr/lib/x86_64-linux-gnu/adios/{mpich,openmpi}/libadiosf_internal_nompi.a -> ../../libadiosf_internal_nompi.a

[Andreas Beckmann]

Package: libadios-mpich-dev,libadios-openmpi-dev
Version: 1.13.1-8
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

0m47.6s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/adios/mpich/libadiosf_internal_nompi.a -> 
../../libadiosf_internal_nompi.a (libadios-mpich-dev)

0m40.6s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/adios/openmpi/libadiosf_internal_nompi.a -> 
../../libadiosf_internal_nompi.a (libadios-openmpi-dev)


libadiosf_internal_nompi.a does not exist in any package in the archive.


cheers,

Andreas


libadios-mpich-dev_1.13.1-8.log.gz
Description: application/gzip

Bug#911047: ledgersmb: broken symlink: /usr/share/ledgersmb/bin/diagnose -> ../utils/diagnostics/diagnose.sh

[Andreas Beckmann]

Package: ledgersmb
Version: 1.6.5+ds-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

1m36.8s ERROR: FAIL: Broken symlinks:
  /usr/share/ledgersmb/bin/diagnose -> ../utils/diagnostics/diagnose.sh 
(ledgersmb)


cheers,

Andreas


ledgersmb_1.6.5+ds-1.log.gz
Description: application/gzip

Bug#911046: xen-utils-common: broken symlink: /usr/share/doc/xen-utils-common/html -> ../xen/html

[Andreas Beckmann]

Package: xen-utils-common
Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

0m33.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/xen-utils-common/html -> ../xen/html (xen-utils-common)


Is xen-utils-common missing a Depends/Recommends/Suggests: xen-doc?


cheers,

Andreas


xen-utils-common_4.11.1~pre.20180911.5acdd26fdc+dfsg-3.log.gz
Description: application/gzip

Bug#908154: Any progress?

[Juergen Gross]

This bug is now older than one month without any activity from gcc
maintainers.

Up to now this bug has been observed on debian only. It has been
observed in multiple gcc versions.

This bug is blocking Linux kernel patches to go in!


Juergen

Bug#911037: blank display at startup: [GFX1-]: Failed to lock new back buffer

[Carsten Schoenert]

Hi,

Am 15.10.18 um 03:21 schrieb Tim Connors:
> Package: thunderbird
> Version: 1:60.0-3~deb9u1
> Severity: important
> 
> At thunderbird startup, I get a completely blank display, associated
> with terminal message: [GFX1-]: Failed to lock new back buffer.
> 
> (I presume this bug should be grave, but how can I be the only person
> on the planet affected by it?  The package is completely unusable to
> me as of the update.)

if it is related to AppArmor then the answer is simply No because the
AppArmor profile is disabled by default.

> At each focus event thereafter, the window flashes, and a system log
> message is output:
> 
> Oct 15 12:06:27 weinberg kernel: [233610.647925] audit: type=1400 
> audit(1539565587.008:2707): apparmor="DENIED" operation="mknod" 
> profile="thunderbird" name="/run/shm/org.chromium.viOLay" pid=20087 
> comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=2983 ouid=2983
> 
> (different /run/shm/ tmp dir everytime)
> 
> Stale apparmor profile affecting latest security update?  Looks like
> #887973 but that was claimed to have been fixed in a version far far
> away.
> 
> /etc/apparmor.d/usr.bin.thunderbird, provided by this version of
> thunderbird, still references only /dev/shm:
> 
>   owner /dev/shm/org.chromium.* rw, # for Chromium IPC
> 
> 
> I note also this report:
> https://lists.dyne.org/lurker/message/20180918.101827.26f69559.de.html
> 
> But users shouldn't be updating /etc/apparmor.d files that are the
> responsibility of the package.

Hm, I still don't see what this report is about. It looks like it this
is related to AppArmor.

What have you done to get clearance on this?
Have you an enabled or a disabled AppArmor profile? I guess you are
running an active profile for Thunderbird.

Do you have checked if any AddOn is possibly provoking your issues?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

-- 
Regards
Carsten Schoenert

Bug#911045: xenstore-utils: removal of xenstore-utils makes files disappear from xen-utils-common

[Andreas Beckmann]

Package: xenstore-utils
Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install xen-utils-common/stretch
  # (1)
  apt-get install xenstore-utils/sid
  apt-get remove xenstore-utils
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/man/man1/xenstore-chmod.1.gz
  /usr/share/man/man1/xenstore-ls.1.gz
  /usr/share/man/man1/xenstore.1.gz

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The xenstore-utils package has the following relationships with 
xen-utils-common:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  xen-utils-common (<= 4.11.1~pre+1.733450b39b-1~)

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

3m53.7s ERROR: FAIL: After purging files have disappeared:
  /usr/share/man/man1/xenstore-chmod.1.gzowned by: xenstore-utils
  /usr/share/man/man1/xenstore-ls.1.gz   owned by: xenstore-utils
  /usr/share/man/man1/xenstore.1.gz  owned by: xenstore-utils

3m53.7s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/xen-utils-common.list   not owned


cheers,

Andreas


xen-utils-common=4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9_xenstore-utils=4.11.1~pre.20180911.5acdd26fdc+dfsg-3.log.gz
Description: application/gzip

Bug#911044: sysvinit-core,initscripts: drop alternative dependency on file-rc

[Andreas Beckmann]

Package: sysvinit-core,initscripts
Version: 2.88dsf-59.10
Severity: important

file-rc is gone from sid


Andreas

Bug#911043: rng-tools does not perform as expected on Beaglebone Black with OMAP hw rng

[Jeffrey Walton]

Package: rng-tools
Version: 2-unofficial-mt.14-1
X-Debbugs-CC: robertcnel...@gmail.com,
pkg-systemd-maintain...@lists.alioth.debian.org

rng-tools does not perform as expected on a Beaglebone Black. The
dev-board has a built-in rng, and the kernel driver loads as expected.
/dev/hwrng is full, but /dev/random is suffering depletion. After
draining /dev/random, it takes 646 seconds to read 10 bytes in
blocking mode.

The problem seems to be the wrapper script of systemd around the old
sysinit script. Or maybe the wrapper is OK but systemd is the problem.
I don't know what the problem is at the moment.

Manually running '/etc/init.d/rng-tools start' and things work as
expected. /dev/random has a bountiful stream of bits.

A related question where I tried to troubleshoot it is at
https://unix.stackexchange.com/q/475489/56041. Unfortunately, I don't
know enough about the system components and they way they are supposed
to interact.

This report may be related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776597 .

This may be CVE worthy. It is effectively a security related DoS due
to a configuration problem.

At this point I think it would be wise to provide a proper systemd
service file for rng-tools.

I am happy to manually install and test an updated *.deb package for
rng-tools. Just point me to a download.

-

Some hardware information.

$ cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 996.14
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Serial  : 

-

$ apt-cache show rng-tools
Package: rng-tools
Version: 2-unofficial-mt.14-1
Installed-Size: 148
Maintainer: Henrique de Moraes Holschuh 
Architecture: armhf
Replaces: intel-rng-tools
Provides: intel-rng-tools
Depends: libc6 (>= 2.4), udev (>= 0.053) | makedev (>= 2.3.1-77)
Conflicts: intel-rng-tools
Description: Daemon to use a Hardware TRNG
Description-md5: 6da2aca3dd07b55b609d9cf3d5d7cd57
Tag: interface::daemon, network::server, role::program
Section: utils
Priority: optional
Filename: pool/main/r/rng-tools/rng-tools_2-unofficial-mt.14-1_armhf.deb
Size: 47364
MD5sum: eb9bde7feaec413754e4b1f255865c8d
SHA1: 4ab63f0ec0f84499decbfe916c248580f51ab560
SHA256: a017aa416bda627a20cf5fdcf51f2a46471b800225a3b3abb5c6774b3cd94c6e

-

$ apt-cache show systemd
Package: systemd
Version: 230-7~bpo8+2
Architecture: armhf
Maintainer: Debian systemd Maintainers

Installed-Size: 6490
Pre-Depends: libc6 (>= 2.8), libgcc1 (>= 1:4.4.0)
Depends: libacl1 (>= 2.2.51-8), libapparmor1 (>= 2.9.0-3+exp2),
libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.19.1), libc6 (>= 2.17),
libcap2 (>= 1:2.10), libcryptsetup4 (>= 2:1.4.3), libgcrypt20 (>=
1.6.1), libgpg-error0 (>= 1.14), libidn11 (>=1.13), libkmod2 (>= 5~),
liblzma5 (>= 5.1.1alpha+20120614), libmount1 (>= 2.20.1), libpam0g (>=
0.99.7.1), libseccomp2 (>= 2.1.0), libselinux1 (>= 2.1.9), libsystemd0
(= 230-7~bpo8+2), util-linux (>= 2.25.2-6), mount (>= 2.25.2-6),
adduser, libcap2-bin
Recommends: libpam-systemd, dbus
Suggests: systemd-ui, systemd-container, policykit-1
Conflicts: klogd
Breaks: apparmor (<< 2.9.2-1), ifupdown (<< 0.8.5~), laptop-mode-tools
(<< 1.68~), lsb-base (<< 4.1+Debian4), lvm2 (<< 2.02.104-1),
systemd-shim (<< 8-2), udev(<< 228-5)
Replaces: udev (<< 228-5)
Multi-Arch: foreign
Homepage: http://www.freedesktop.org/wiki/Software/systemd
Priority: important
Section: admin
Filename: pool/main/s/systemd/systemd_230-7~bpo8+2_armhf.deb
Size: 2146126
SHA256: b8ad0cd78f01d14980fa728baa841a2a59d85c706e6a3843930a8d932d289d04
SHA1: cf280cd4a7564a50404b95c04967be9ba468
MD5sum: bb29e98702695017bc9241c6b81d600f
Description: system and service manager
 systemd is a system and service manager for Linux. It provides aggressive
 parallelization capabilities, uses socket and D-Bus activation for starting
 services, offers on-demand starting of daemons, keeps track of processes
 using Linux control groups, supports snapshotting and restoring of the system
 state, maintains mount and automount points and implements an elaborate
 transactional dependency-based service control logic.
 .
 systemd is compatible with SysV and LSB init scripts and can work as a
 drop-in replacement for sysvinit.
 .
 Installing the systemd package will not switch your init system unless you
 boot with init=/bin/systemd or install systemd-sysv in addition.
Description-md5: daa2c3e0044c2c2f5adc47475a3d6969

Package: systemd
Version: 215-17+deb8u7
Installed-Size: 7977
Maintainer: Debian systemd Maintainers

Architecture: armhf
Depends: libacl1 (>= 2.2.51-8), libaudit1 (>= 1:2.2.1), libblkid1 (>=
2.19.1), libcap2 (>= 1:2.10), libcryptsetup4 (>= 2:1.4.3), libkmod2
(>= 5~), libpam0g (>=0.99.7.1), 

Bug#911042: ftcbfs

[Helmut Grohne]

Source: cryptsetup
Version: 2:2.0.4-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cryptsetup fails to cross build from source, because debian/rules uses
the build architecture compiler for building askpass via the make
default of $(CC). Including dpkg's buildtools.mk supplies a default that
works for cross compilation. After doing so, cryptsetup cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru cryptsetup-2.0.4/debian/changelog 
cryptsetup-2.0.4/debian/changelog
--- cryptsetup-2.0.4/debian/changelog   2018-08-07 17:25:30.0 +0200
+++ cryptsetup-2.0.4/debian/changelog   2018-10-15 06:27:13.0 +0200
@@ -1,3 +1,10 @@
+cryptsetup (2:2.0.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Supply $(CC) from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 15 Oct 2018 06:27:13 +0200
+
 cryptsetup (2:2.0.4-2) unstable; urgency=medium
 
   * debian/cryptsetup-initramfs.preinst: Don't try to overwrite
diff --minimal -Nru cryptsetup-2.0.4/debian/rules cryptsetup-2.0.4/debian/rules
--- cryptsetup-2.0.4/debian/rules   2018-08-07 17:25:30.0 +0200
+++ cryptsetup-2.0.4/debian/rules   2018-10-15 06:27:11.0 +0200
@@ -7,6 +7,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow,+pie
 DEB_CFLAGS_MAINT_APPEND = -Wall
 include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
 
 CONFFLAGS =
 

Bug#911041: calculix-cgx FTCBFS: hard codes the build architecture compiler g++

[Helmut Grohne]

Source: calculix-cgx
Version: 2.11+dfsg-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

calculix-cgx fails to crossbuild from source, because the upstream
Makefile hard codes the build architecture compiler for the final linker
invocation. After making it subsitutable (see patch attached), it fails
to cross build due to #911040. Please consider applying the attached
patch anyway and close this bug when doing so.

Helmut
--- calculix-cgx-2.11+dfsg.orig/cgx_2.11/src/Makefile
+++ calculix-cgx-2.11+dfsg/cgx_2.11/src/Makefile
@@ -22,7 +22,7 @@
 OUTIL = $(SUTIL:.c=.o)
 
 cgx: $(OLIB) $(OUTIL) $(OULIB)
-	g++ -std=gnu++98 $(OULIB)  $(OLIB) $(OUTIL)  $(CFLAGS) $(LFLAGS) -o  $@
+	$(CXX) -std=gnu++98 $(OULIB)  $(OLIB) $(OUTIL)  $(CFLAGS) $(LFLAGS) -o  $@
 
 
 

Bug#911040: libsnl-dev is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

Package: libsnl-dev
Version: 0.2.1.svn.18-1
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:calculix-cgx

calculix-cgx fails to cross build from source, because it cannot find
-lSNL during linking. Although it is requested for the host
architecture, it happens to be installed for the build architecture due
to libsnl-dev's Multi-Arch: foreign marking. That's wrong. For more
details refer to the emitted lintian tag. Please remove the erroneous
marking.

Helmut
diff --minimal -Nru libsnl-0.2.1.svn.18/debian/changelog 
libsnl-0.2.1.svn.18/debian/changelog
--- libsnl-0.2.1.svn.18/debian/changelog2015-05-01 19:40:16.0 
+0200
+++ libsnl-0.2.1.svn.18/debian/changelog2018-10-15 06:11:41.0 
+0200
@@ -1,3 +1,10 @@
+libsnl (0.2.1.svn.18-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove wrong Multi-Arch: foreign from libsnl-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 15 Oct 2018 06:11:41 +0200
+
 libsnl (0.2.1.svn.18-1) unstable; urgency=medium
 
   * Initial release (Closes: #783483)
diff --minimal -Nru libsnl-0.2.1.svn.18/debian/control 
libsnl-0.2.1.svn.18/debian/control
--- libsnl-0.2.1.svn.18/debian/control  2015-07-04 22:28:44.0 +0200
+++ libsnl-0.2.1.svn.18/debian/control  2018-10-15 06:11:38.0 +0200
@@ -14,7 +14,6 @@
 Section: libdevel
 Depends: libsnl0 (= ${binary:Version}),
  ${misc:Depends}
-Multi-Arch: foreign
 Description: Simple Nurbs Library (development files)
  libSNL is a library of routines used for the 
  manipulation of non-uniform rational B-Splines (NURBS).

Bug#891096: planet-venus: python-beautifulsoup is replaced with python-bs4

[Paul Wise]

Control: reopen -1

On Tue, 02 Oct 2018 00:57:59 +0200 Jonas Smedegaard wrote:

> planet-venus only reference BeautifulSoup in a vendor dir which is fully 
> patched out and therefore irrelevant.

In that case the Recommends should be removed, reopening.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#776413: The status of ed

[Lev Lamberov]

Dear FTP Masters,

I'd like to request your input on #776413. It is concerned with the
priority of the ed package. There are two conflicting requests. Some
users request ed to have priority "optional", other users request it to
be "important". Please, take a look at the discussion in the mentioned
bug report (and also in the related one, #416585).

Some time ago (see, #416585) the priority of the ed package has been
changed to "optional", but ed is still a part of POSIX standard. For me
personally the main issue here is the interpretation of "Unix-like" in
the Debian Policy: "Important programs, including those which one would
expect to find on any Unix-like system."

With regards,
Lev Lamberov

Bug#911039: fusiondirectory: [INTL:fr] French debconf templates translation

[Grégoire Scano]

Package: fusiondirectory
Version: 1.2.2-3
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates translation, proofread by the
debian-l10n-french mailing list contributors.

Kind regards

Grégoire
# Translation of the fusiondirectory debconf templates to French.
# Copyright (C) 2018, French l10n Team 
# This file is distributed under the same license as the fusiondirectory 
package.
# Grégoire Scano , 2018
msgid ""
msgstr ""
"Project-Id-Version: fusiondirectory 1.2.2-3\n"
"Report-Msgid-Bugs-To: fusiondirect...@packages.debian.org\n"
"POT-Creation-Date: 2018-08-28 17:16+0200\n"
"PO-Revision-Date: 2018-09-12 14:09+0800\n"
"Last-Translator: Grégoire Scano \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Really perform FusionDirectory major version upgrade?"
msgstr ""
"Faut-il vraiment effectuer la mise à niveau vers une version majeure de "
"FusionDirectory ?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"You are about to upgrade FusionDirectory to a new major version. Please "
"consult the UPGRADE documentation first: /usr/share/doc/fusiondirectory/"
"UPGRADE.md.gz"
msgstr ""
"Vous êtes sur le point de mettre à niveau FusionDirectory vers une nouvelle "
"version majeure. Merci de consulter la documentation de MISE À NIVEAU dans "
"un premier temps : /usr/share/doc/fusiondirectory/UPGRADE.md.gz"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"FusionDirectory comes with tools to migrate from one major version to "
"another. However, as with other LDAP directory setups, exceptional "
"circumstances or wrong data in the LDAP tree may sometimes prevent these "
"tools from migrating everything."
msgstr ""
"FusionDirectory est accompagné d'outils pour migrer d'une version majeure à "
"une autre. Cependant, comme avec d'autres configurations de répertoire LDAP, "
"des circonstances exceptionnelles ou des données erronées dans l'arbre LDAP "
"peuvent parfois empêcher ces outils de tout migrer."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"In this case, the directory information tree may even need to be manually "
"adapted outside of FusionDirectory with tools such as ldapmodify or ldapvi."
msgstr ""
"Dans ce cas, l'arbre d'information de répertoire peut même avoir besoin "
"d'être adapté manuellement en dehors de FusionDirectory avec des outils tels "
"que ldapmodify ou ldapvi."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"If you do not choose to proceed, the upgrade process for FusionDirectory "
"related packages will be canceled."
msgstr ""
"Si vous choisissez de ne pas poursuivre, le processus de mise à niveau des "
"paquets associés à FusionDirectory va être annulé."

#. Type: error
#. Description
#: ../templates:2001
msgid "FusionDirectory upgrade canceled"
msgstr "Mise à niveau de FusionDirectory annulée"

#. Type: error
#. Description
#: ../templates:2001
msgid ""
"The upgrade of FusionDirectory has been canceled on user request. The "
"installation process will be aborted."
msgstr ""
"La mise à niveau de FusionDirectory a été annulée à la demande de "
"l'utilisateur. Le processus d'installation va être interrompu."

Bug#911038: sysconfig: inconsistent sitelib path

[Alec Leamas]

Package: python3.6
Version: 3.6.7~rc1-1

On 3.7, the python.m4 automake macro reports the site path as
./usr/lib/x86_64-linux-gnu/python3.6/site-packages. This causes all
sorts of interesting installation issues.

Looking into the situation the python.m4 macro uses

if can_use_sysconfig:
sitedir = sysconfig.get_path('purelib',
vars={'base':'$am_py_prefix'})
else:
from distutils import sysconfig
sitedir = sysconfig.get_python_lib(0, 0, prefix='$am_py_prefix')

Now, sysconfig seems to be broken:

>>> import sysconfig
>>> sysconfig.get_path('purelib', vars={'base':'/usr/local'})
'/usr/local/lib/python3.6/site-packages'

while distutils.sysconfig actually is fine:

>>> from distutils import sysconfig
>>> sysconfig.get_python_lib(0, 0, prefix='/usr/local')
'/usr/local/lib/python3/dist-packages'

Since I cannot see that python.m4 does anything wrong here I file the
issue against python.

Regards,

Alec Leamas

Bug#911037: blank display at startup: [GFX1-]: Failed to lock new back buffer

[Tim Connors]

Package: thunderbird
Version: 1:60.0-3~deb9u1
Severity: important

At thunderbird startup, I get a completely blank display, associated
with terminal message: [GFX1-]: Failed to lock new back buffer.

(I presume this bug should be grave, but how can I be the only person
on the planet affected by it?  The package is completely unusable to
me as of the update.)

At each focus event thereafter, the window flashes, and a system log
message is output:

Oct 15 12:06:27 weinberg kernel: [233610.647925] audit: type=1400 
audit(1539565587.008:2707): apparmor="DENIED" operation="mknod" 
profile="thunderbird" name="/run/shm/org.chromium.viOLay" pid=20087 
comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=2983 ouid=2983

(different /run/shm/ tmp dir everytime)

Stale apparmor profile affecting latest security update?  Looks like
#887973 but that was claimed to have been fixed in a version far far
away.

/etc/apparmor.d/usr.bin.thunderbird, provided by this version of
thunderbird, still references only /dev/shm:

  owner /dev/shm/org.chromium.* rw, # for Chromium IPC


I note also this report:
https://lists.dyne.org/lurker/message/20180918.101827.26f69559.de.html

But users shouldn't be updating /etc/apparmor.d files that are the
responsibility of the package.




-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'),
(1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages thunderbird depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libatk1.0-0   2.28.1-1~bpo9+1
ii  libc6 2.24-11+deb9u3
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libgtk2.0-0   2.24.31-2
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-en-au [hunspell-dictionary]  1:5.2.5-1
ii  hunspell-en-gb [hunspell-dictionary]  1:5.2.5-1
ii  lightning 1:60.0-3~deb9u1

Versions of packages thunderbird suggests:
ii  apparmor  2.11.0-3+deb9u2
ii  fonts-lyx 2.3.1-2-1~bpo9+1
ii  libgssapi-krb5-2  1.15-1+deb9u1

-- no debconf information


-- 
Tim Connors

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Bill Brelsford]

On Mon Oct 15 2018 at 12:19 AM +0200, Michael Biebl wrote:
> I was a bit too eager. The sd-notify support in dpkg was not quite ready
> yet. The dpkg maintainer has improved the code.
> Could you test again with version 1.19.2+test2, 

This one fixes it (3 successful boots so far).  Thanks, Michael.

-- 
Bill Brelsford
w...@k2di.net

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Control: noowner -1

Hi,

Update: I've learned that Debian Installer work needs to be completed
about four months before the freeze.  As it looks like I'll be swamped
with work for the next month or two I'm unsetting myself as owner.

If no one finishes the work in time for buster freeze I'll resume work
sometime this spring.  It's not nearly as simple as I'd hoped it would
be.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#872885: netty-tcnative-1.1: Please migrate to openssl1.1 in Buster

[Emmanuel Bourg]

Le 13/10/2018 à 00:32, Emmanuel Bourg a écrit :

> - tycho (through aether again), I'm working on an upgrade no longer
> depending on it

The tycho update is ready but requires equinox-p2 which is still in NEW.

> - libgpars-groovy-java which is used by groovy. I don't have a solution
> for this one yet.

I've uploaded libgpars-groovy-java/1.2.1-10 with the Netty part removed,
it was never used in Debian.

Bug#911036: partman-lvm: Volume group name "■" has invalid characters, and cannot removed

[Hideki Yamane]

Package: partman-lvm
Version: 124
Severity: important
tags: d-i

Hi,

 While installing with d-i buster alpha3, I've tried to remove Logical Volume
 but couldn't. At VT4 shows below error

> partman-lvm:Volume group name "■" has invalid characters
> partman-lvm:Cannot process volume group ■

 However, LV names are "home", "root" and "swap_1", not "■".
 ("■" may be mojibake?)


># lvscan
>  ACTIVE'/dev/elitebook830-vg/root' [<27.94 GiB] inherit
>  ACTIVE'/dev/elitebook830-vg/swap_1' [<31.84 GiB] inherit
>  ACTIVE'/dev/elitebook830-vg/home' [<893.34 GiB] inherit

 And "lvremove /dev/elitebook830-vg/{root,swap_1,home}" works well at VT2.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#911025: Transition to postgresql-11

[Jeremy Bicha]

On Sun, Oct 14, 2018 at 5:15 PM Christoph Berg  wrote:
> Stepping back a bit, does the package really need a database server on
> the local machine?

Yes. At least if you don't, it doesn't want to let you use it and
gives this error:

$ glom
Your installation of Glom is not complete, because PostgreSQL is not
available on your system. PostgreSQL is needed for self-hosting of
Glom databases.

Please report this bug to your vendor, or your system administrator so
it can be corrected.

> Does it need to depend on a single server version?

Well, I wouldn't think so, but the build tests seemed to hang when I
either had postgresql-11 installed or no postgresql version at all.

How soon do you need this issue fixed? I'm ok with glom being removed
from Testing if that helps.

Thanks,
Jeremy Bicha

Bug#911035: O: ngetty -- getty replacement - one single daemon for all consoles

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the ngetty package.

The package description is:
 Ngetty is a daemon that starts login sessions on virtual console
 terminals, on demand.  It is a good replacement for all those getty
 processes started from init that, most of the time, are only taking
 up memory.  Since it is compiled statically with dietlibc, the ngetty
 binary size is only about 2k and uses considerably less memory than a
 usual getty implementations.


Upstream ( http://riemann.fmi.uni-sofia.bg/ngetty/ ) has gone, and
things around system daemon has been changed.  The original idea might
be still valid, but the software itself would be questionable.  Thus,
I stop maintaining.
-- 

Bug#911034: O: libpcre++ -- C++ wrapper class for pcre

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the libpcre++ package.

The package description is:
 PCRE++ is a C++ wrapper-class for the library PCRE (Perl Compatible
 Regular Expressions).
 .
 Its class allows you to use perl alike regular expressions in your C++
 applications. You can use it to search in strings, to split strings
 into parts using expressions or to search and replace a part of a
 string with another part.

Upstream is no longer active.  IIRC, I started packaging this for
libapache2-mod-auth-openid, but it removed the dependency by using
libpcre directly.  And it seems that's a practice.  Thus, I stop
maintaining.
-- 

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

[2018-10-13 13:20] Niko Tyni 
> The libgdbm6 transition broke autopkgtest checks of src:perl and
> libmarc-charset-perl.
> 
> It looks like some GDBM databases which were working with the older
> gdbm are not readable any more with the new one.

After a bit more research I deduced, that libmarc-charset-perl, as
present in sid, was build with gdbm-1.8.3. gdbm-1.9 is incompatible with
1.8.3, so it is pure luck, that thigs worked with gdbm-1.14.

I am sorry to say it, but probably binNMU or sourceful upload would be
required for all packages, that bundle gdbm databases, generated by
(gdbm << 1.9)

Bug#911024: src:haskell-monadplus: unmaintained

[Clint Adams]

On Sun, Oct 14, 2018 at 05:01:16PM -0700, Sean Whitton wrote:
> Just to note in the bug that the reason haskell-monadplus was packaged
> was for agda, which still build-depends on it.  So if we don't think
> monadplus is worth the maintenance burden, neither is agda; we should
> get rid of that too.  (I don't have an opinion on this as I am not
> maintaining either.)

agda 2.5.4.1 no longer build-depends on it so this particular problem
 will be resolved whenever there are binary builds of agda/unstable.

Bug#911033: O: libopkele -- OpenID support library in C++

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the libopkele package.

The package description is:
 libopkele is a C++ implementation of an OpenID decentralized identity
 system.  It provides OpenID protocol handling, leaving authentication
 and user interaction to the implementor.

The only use of this package is by libapache2-mod-auth-openid.
And upstream is no longer active.  Thus, I stop maintaining.
-- 

Bug#911032: O: libapache2-mod-auth-openid -- OpenID authentication module for Apache2

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the libapache2-mod-auth-openid package.

The package description is:
 mod_auth_openid is an authentication module for Apache2.
 It handles the functions of an OpenID consumer as specified in the
 OpenID 2.0 specification.

Upstream is no longer active and libapache2-mod-auth-openidc is better
now.  Thus, I stop maintaining.
-- 

Bug#911024: src:haskell-monadplus: unmaintained

[Sean Whitton]

Hello Clint,

On Sun 14 Oct 2018 at 08:37PM GMT, Clint Adams wrote:

> Package: src:haskell-monadplus
> Version: 1.4.2-5
> Severity: serious
>
> monadplus is probably not worth the maintenance burden.
> Please close this bug if you disagree.

Just to note in the bug that the reason haskell-monadplus was packaged
was for agda, which still build-depends on it.  So if we don't think
monadplus is worth the maintenance burden, neither is agda; we should
get rid of that too.  (I don't have an opinion on this as I am not
maintaining either.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

control: tag -1 +moreinfo

[2018-10-13 13:20] Niko Tyni 
> For reference, the output with libgdbm5 1.14.1-6+b1 is
> 
>  % gdbm_dump debian/tests/data/jessie.gdbm
>  # GDBM dump file created by GDBM version 1.14.1. 03/01/2018 on Sat Oct 13 
> 13:15:59 201
> 8
>  #:version=1.0
>  #:file=debian/tests/data/jessie.gdbm
>  #:uid=1000,user=niko,gid=1000,group=niko,mode=644
>  # End of header
>  #:len=3
>  Zm9v
>  #:len=9
>  amVzc2llIE9L
>  #:count=1
>  # End of data

I compiled gdbm-1.14.1 from source to check
`/usr/lib/libmarc-charset-perl/Table'.  For me, exit code is non-zero. I
belive that issue is with database, but older versions of gdbm_dump
failed to properly report it.

In addition, just checked bin:man-db database. It is fine. So I believe
problem is not /too/ grave.

But I agree, usability issue is at hand: something worked (no matter
why), and now it no longer works. Let us debug.

How those problematic databases are created?

Bug#911031: installation-reports: sorry to shorten it would wreck it.. security code bugs out when entered

[Wicca Robin]

Package: installation-reports
Severity: important

Dear Maintainer,

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

1st I can not add the requested program.  I can't use my security code it just
errors out

   * What led up to the situation?
I used the code after a reboot but it is complicated
I had to do a reboot because I was updating the software options
that failed but I also had a failure at home with my keyboard, after which I
replaced it with one that works

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I attempted to replace my keyboard in hopes it would fix the error when I
rebooted but it did not
I attempted to follow the directions given to clear the issue in the "dkpg"
but they failed to work  I tried several ways after the instructions failed

 * What was the outcome of this action?
The outcome is I can't upgrade or add or do anything that requires my security
code

   * What outcome did you expect instead?
I hoped changing the keyboards out would fix the issue when I rebooted

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



-- Package-specific info:

Boot method: 
Image version: 
Date: 

Machine: 
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u4"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux Silly 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 5520/5500/X58 I/O Hub 
to ESI Port [8086:3405] (rev 12)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:836b]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub 
PCI Express Root Port 1 [8086:3408] (rev 12)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub 
PCI Express Root Port 3 [8086:340a] (rev 12)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub 
PCI Express Root Port 7 [8086:340e] (rev 12)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:14.0 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub 
System Management Registers [8086:342e] (rev 12)
lspci -knn: 00:14.1 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub 
GPIO and Scratch Pad Registers [8086:3422] (rev 12)
lspci -knn: 00:14.2 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub 
Control Status and RAS Registers [8086:3423] (rev 12)
lspci -knn: 00:14.3 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub 
Throttle Registers [8086:3438] (rev 12)
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 
Family) USB UHCI Controller #4 [8086:3a37]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:82d4]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 
Family) USB UHCI Controller #5 [8086:3a38]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:82d4]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.2 USB controller [0c03]: Intel Corporation 82801JI (ICH10 
Family) USB UHCI Controller #6 [8086:3a39]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:82d4]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801JI (ICH10 
Family) USB2 EHCI Controller #2 [8086:3a3c]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:82d4]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 
Family) HD Audio Controller [8086:3a3e]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:82ea]
lspci -knn: Kernel driver 

Bug#911030: bugs.debian.org: [bugreport.cgi] contains Perl error in page source

[nyov]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

the html source of b.d.o/cgi-bin/bugreport.cgi contains this Perl error:





Cheers

Bug#911029: libpam-mount: port to pcre2

[Jeremy Bicha]

Source: libpam-mount
Version: 2.16-8

It would be nice if libpam-mount would switch to the new pcre2 library
instead of the older pcre3 (sorry about the confusing name).

While this was attempted in 2.16-8, a careful look at the build logs
show that pcre3 is still used. Another build-dependency pulls in pcre3
and the resulting binary still depends on pcre3.

And configure.ac only supports the older pcre library.

https://buildd.debian.org/status/package.php?p=libpam-mount

Thanks,
Jeremy Bicha

Bug#908012: wine-development: gcc-8 build with -O2 causes some apps to crash

[Michael Gilbert]

control: tag -1 moreinfo

> Negative, wine stable is not affected, at least for my use-case.
> According to the winehq bug, it all started from wine 3.8.

What about the latest uploads of wine-development, do they work for
you now?  This should be fixed by upstream's DECLSPEC_HOTPATCH updates
as of 3.17.

Best wishes,
Mike

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 11.10.18 um 01:00 schrieb Bill Brelsford:
> On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
>> I've compiled a dpkg test package from this branch [1].
>> Bill, it would be great if you can install this dpkg package and try it
>> along with the attached patch for the udev init script.
> 
> I installed your new dpkg and patched the udev init script, but it
> doesn't work.  S-s-d apparently doesn't wait for udev to be ready.

I was a bit too eager. The sd-notify support in dpkg was not quite ready
yet. The dpkg maintainer has improved the code.
Could you test again with version 1.19.2+test2, please

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#911028: UDD: support for rsyncable udd.dump backup in pg_dump -Fd format

[nyov]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: udd


Dear UDD heroes,

the publicly available udd.dump [1] is 1.5 GB and I'd like to ask for
the possibility to turn it from a PGDMP in `pg_dump -Fc` format
to a dir'ed `pg_dump -Fd` which might, with the many tables within udd,
provide a measure of bandwidth-savings for mirrors of the database when
the periodic dumps don't update some of the tables and can therefore
be skipped in a mirror run. (Potentially could save time on dumps and
restores as well, as -Fd can dump and restore tables in parallel.)

Further saving (and ease of mirror use) could possibly be achieved by
providing an rsync module of the dump directory [1], if the possibility
exists of setting that up on ullmann.d.o.

Reasoning:

Since the database is constantly changing and may require a mirror to
update often, grabbing a new 1.5GB file perhaps multiple times daily
can be daunting to some lower-bandwidth connections (while some tables
actually get updates only daily or less).


After a chat with mapreri I don't have high hopes wrt the rsync module,
but I was encouraged to just put it out there anyway.

< mapreri> nyov: of course, if you wish a -Fd dump, it should be provided 
alongside the current -Fc one, not instead.

And that is probably the final nail in the coffin - having two having both
is really a necessity.


As an alternative option -- perhaps udd.dump could be dumped without
pg_dump internal compression (-Z0) and instead piped through lzma/xz [2],
as the popcon dump already does?


[1] https://udd.debian.org/dumps/
[2] https://salsa.debian.org/qa/udd/blob/master/scripts/dump-db-more-frequently
https://salsa.debian.org/qa/udd/blob/master/scripts/dump-db.sh


Cheers

Bug#909718: debian-live: it is a UEFI 32 only system.

[Steve McIntyre]

On Sun, Oct 14, 2018 at 12:39:22PM +0200, beta-tester wrote:
>Package: debian-live
>Followup-For: Bug #909718
>
>Dear MaintaineSteve McIntyre,
>
>my system have UEFI 32 only, a "legacy" BIOS mode does not exist.
>
>i can not disable SecureBoot.
>the Windows System Partition is encrypted by BitLocker on the har drive,
>and i saw a video where somebody disabled SecureBoot to boot Linux Live
>and after re-enabling SecureBoot later to boot into Windows again,
>the system run into BitLocker Recovery mode,
>and he had to use BitLocker Recovery to decrypt and re-encrypt everything 
>again.
>
>so disabling SecureBoot will destroy the stored BitLocker-key somehow.
>
>thats because disabling SecureBoot is not an option.

OK, so that's a limitation on your system.

>why are UEFI32 only tablet/netbook users disadvantaged or excluded
>from using Linux / Debian?
>i mean to me it looks like it is only a matter of providing proper signed 
>grub-efi-ai32-signed package or shim-signed or what ever packages are involved.

We're working on providing appropriate signed packages for various
architectures, but we're not 100% there yet. We already support 32-bit
UEFI systems in general, but if something else is stopping you from
disabling Secure Boot then that is a blocker *for now*.

>or is Debian Linux Live friendly only for big customers with big hardware?

I don't understand why you're making that unhelpful comment.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Bug#910878: transition: qtbase-opensource-src

[Emilio Pozuelo Monfort]

On 12/10/2018 18:24, Dmitry Shachnev wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> Qt has released a new bugfix release (5.11.2) recently, and we need a
> transition to get it into unstable. The packages are already prepared
> in experimental.
> 
> It is a patch release so it should go smooth compared to minor (5.x.0)
> releases.
> 
> As usual, we have two sub-transitions:
> 
> title = "qtbase-opensource-src";
> is_affected = .depends ~ "qtbase-abi-5-11-0" | .depends ~ "qtbase-abi-5-11-2";
> is_good = .depends ~ "qtbase-abi-5-11-2";
> is_bad = .depends ~ "qtbase-abi-5-11-0";
> 
> and
> 
> title = "qtdeclarative-opensource-src";
> is_affected = .depends ~ "qtdeclarative-abi-5-11-0" | .depends ~ 
> "qtdeclarative-abi-5-11-2";
> is_good = .depends ~ "qtdeclarative-abi-5-11-2";
> is_bad = .depends ~ "qtdeclarative-abi-5-11-0";

I have created the trackers, but let's wait for the kde transition to finish as
the two collide.

> 
> Note that we will likely want to do one more transition before Buster
> release. Namely, one that will switch the default OpenGL version from desktop
> to OpenGL ES on arm64. We are not yet ready for it, and it will affect
> more packages (including some that will need NMUs), so we decided to decouple
> it from this one.

Ok.

Cheers,
Emilio

Bug#910567: ITA: sn -- Small NNTP server for leaf sites

[Robert J. Clay]

On Sun, Oct 14, 2018 at 4:12 PM Hilko Bengen  wrote:
>
> * Robert J. Clay:
>
> >Did you push all of the branches? I only see one branch, named
> > 'upstream'; and like I mentioned, that only has one commit listed when
> > I look *using 'tid', for instance).  No 'pristine-tar'  or even a
> > 'master'  branch.
>
> There are two branches, "upstream" and "master".

   Ah, it seems I should have looked at the repo as it is online more
closely.  I've pulled the 'master' branch. I'll continue reviewing it
and I've already done a local test build (in buster) as well as
running lintian directly using the '-IE --pedantic --show-overrides'
parameters.


> No "pristine-tar"  branch.

I suppose that with an upstream which has not been updated in
years, having a 'pristine-tar' branch is not quite as useful as it can
be with other packages with a more active upstream. In fact, I wonder
if uploads would even need the orig archive.  (I'll need it for local
builds, of course.)


> For some reason Gitlab thinks that "upstream" should be the
> "default" branch, i.e. the branch that is checked out after a git clone.

   That's a salsa (gitlab) setting for the repository.  I've changed
that to 'master'.



-- 
Robert James Clay
rjc...@gmail.com
j...@rocasa.us

Bug#776413: Policy violation: ed priority "optional", should be "important"

[Ian Jackson]

Paul Hardy writes ("Bug#776413: Policy violation: ed priority "optional", 
should be "important""):
> I know that the package priority is up to the FTP Masters and not up
> to any of us.  I just mention the above as input for the ed maintainer
> to discuss with the FTP Masters if so desired.

I thought the bug that ed was not in the default install had been
fixed.  I agree that it ought to be in all but the most minimal
installations.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#910446: NMU diff (substantive patches in git-format-patch form)

[Ian Jackson]

Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in 
git-format-patch form)"):
> On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote:
> > Hi.  I fixed this bug, and some other FTBFS, and am about to upload
> > the result.  I'm doing this myself, right away, because this is an RC
> > bug which has triggered the autoremover to want to remove dgit.
> > 
> > Following the recommendation in dev ref 5.11.1, I have not use
> > DELAYED; and because I doubt that actually uploading it now will cause
> > you any difficulty.  I hope that's OK.
> > 
> > The patches I made are attached.  You can also find this as a git
> > branch, here:
...> 
> That's actually not what I prefer since I

Sorry about that.  But,

> - said I'm about to fix this

I did look in the bug [1] before starting work, this lunchtime UK
time, and there was no response there.

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

I have just checked the bug again, and your message to it crossed with
my decision to go ahead with the upload.  The timestamp on the
relevant .changes file shows that I did my formal build-for-upload at
14:28 UTC.  I and evidently spent a few minutes getting my NMU diff
email into shape and I sent that email at 14:36 and did the actual
dgit push at 14:37.

Your message to the bug was at 14:31 UTC.  I confess didn't check the
bug again in the 9 minutes between `dgit sbuild' and `dgit push'.

To be honest, if you had said any time in the past week, in the bug,
that you were intending to fix it I would have been quite happy to
leave the work to you.  But there was nothing from you in the bug and
the upstream git server (which I was able to see via http, even if the
git interface was giving me trouble) showed no recent activiy.

> - there's plenty of time until the autoremoval hits us

I'm generally quite busy and I had time and headspace to do this
technical work now.  I wasn't confident that that would occur again in
the next few weeks.

I'm sorry to be told that I have engaged in "sub par interaction".  I
was trying to help.  Can you explain to me what concrete problem my
action has caused you ?

I appreciate that being the recipient, several times a year, of
autoremoval notifications (not just from gbp) is a hazard of sitting
on top of a large dependency stack.  But it would be nice to be able
to at least fix these things oneself without being criticised.

It would be really helpful if people would respond to RC bugs *before*
their entire reverse dependency stack has received an `autoremoval'
email.

I guess I can be criticised for not emailing the bug before starting
work.  Looking at my irc transcript it looks like I started at 12:00
UTC or so.  Of course once one has started on something like this it
is very discouraging to be told to stop and throw one's work away -
and I guess your message to the bug was prompted by the autoremoval
mail which had been sent ovrnight, so an additional mail from me would
have waited anyway.  So probably in this case if I had emailed the bug
at 12:00ish UTC it would have made no difference.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#776413: Policy violation: ed priority "optional", should be "important"

[Paul Hardy]

I considered using "ed" in a script to massage an upstream package
into shape during installation this past week, but decided not to
because ed is not part of the default Debian installation.

I think it is worth considering why ed is part of the POSIX standard
to this day in determining whether or not it should have priority
"important" and be included in the base installation.  The very first
sentence of the "DESCRIPTION" portion of the BSD 4.2 man page (1980s
vintage) for ed says: "_Ed_ is the standard text editor."
Historically, ed was the only text editor available on a bare-bones
Unix system booting from a minimal kernel before a customized kernel
had been configured and built, with video drivers, etc., to support
video monitors.

Most processors today are not connected to video monitors; most
processors are part of embedded systems.  When bringing up such a
system initially, you typically just have a power supply, the
processor chip, some flash memory that contains a minimal bootloader,
a serial console port on the processor's UART pins, and maybe a JTAG
port.  This bug report has mentioned vi(m) and sed as possible
replacements.  Neither are proper interactive single-line editors
designed to work over a serial line, and GNU sed is more powerful than
other sed implementations, and vi(m) is not suitable for operation
within a shell script.

Embedded systems are not going to be reporting their usage for popcon
statistics either, so a poor popcon showing can be misleading.

The Debian source package is about 1 Mbyte, almost half of which is
testsuite data, but the upstream tarball is less than 70 kilobytes.
Is Debian so constrained for space on its ISO images that it is not
possible to shoehorn in a copy of ed in the base installation?

I know that the package priority is up to the FTP Masters and not up
to any of us.  I just mention the above as input for the ed maintainer
to discuss with the FTP Masters if so desired.

Thank you,


Paul Hardy

Bug#910923: $PLATFORM is no longer expanded.

[Roman Lebedev]

On Sun, Oct 14, 2018 at 10:51 PM Aurelien Jarno  wrote:
>
> control: severity -1 normal
> control: retitle -1 libc6: broken support for curly braces DST
>
> On 2018-10-13 16:13, Roman Lebedev wrote:
> > Source: glibc
> > Version: 2.27-6
> > Severity: important
> >
> > Reproduction:
> > $ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat
> > execve("/bin/cat", ["/bin/cat"], 0x55ddc6b820f0 /* 64 vars */) = 0
> > brk(NULL)   = 0x56046d9c1000
> > access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
> > directory)
> > readlink("/proc/self/exe", "/bin/cat", 4096) = 8
> > openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
> > such file or directory)
Hm actually wait, i think i'm confused here.
Both the ${PLATFORM} and $PLATFORM seem to expand just fine.

$ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat | grep PLATFORM
...
openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22},
{iov_base="/sss/${PLATFORM}/", iov_len=21}, {iov_base="' from ",
iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be
preloaded (", iov_len=22}, {iov_base="cannot open shared object file",
iov_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so:
object '/sss/${PLATFORM}/' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
) = 124

$ strace -ELD_PRELOAD='/sss/$PLATFORM/'  -s300  /bin/cat | grep PLATFORM
...
openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22},
{iov_base="/sss/$PLATFORM/", iov_len=19}, {iov_base="' from ",
iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be
preloaded (", iov_len=22}, {iov_base="cannot open shared object file",
io
v_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so:
object '/sss/$PLATFORM/' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
) = 122

It clearly expanded PLATFORM to x86_64 in both cases, do you agree?

So whatever i'm seeing is something else, might be caused by docker.

Roman.

> > writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22}, 
> > {iov_base="/sss/${PLATFORM}/", iov_len=21}, {iov_base="' from ", 
> > iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be 
> > preloaded (", iov_len=22}, {iov_base="cannot open shared object file", 
> > iov_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so: object 
> > '/sss/${PLATFORM}/' from LD_PRELOAD cannot be preloaded (cannot open 
> > shared object file): ignored.
> > ) = 124
> >
> > So $PLATFORM is not expanded. This is a regression from 2.24
>
> Actually ${PLATFORM} is not expanded. If you try with $PLATFORM you will
> see it is correctly expanded.
>
> > According to
> > https://sourceware.org/bugzilla/show_bug.cgi?id=22299
> > it *should* be fixed in 2.27, but it is clerly still reproducible in
> > debian testing/sid.
>
> This is a different bug, as shown above the problem is that support for
> curly braces does not work anymore.
>
> > This is causing the following problem for me:
> > https://community.sonarsource.com/t/sonarqube-c-ubuntu-build-wrapper-ld-preload-error/300/2
>
> The workaround is to use $PLATFORM instead of ${PLATFORM}.
>
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Bug#911027: wishlist: debian/README.source

[Geert Stappers]

Package: ansible
Version: 2.6.5+dfsg-1
Severity: wishlist

Dear Maintainers,

IMHO would it a good thing if the Ansible package
also gets a debian/README.source file.


Quoting 
https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source

This file should explain how to do all of the following:

Generate the fully patched source, in a form ready for editing, that
would be built to create Debian packages. Doing this with a patch
target in debian/rules is recommended; see Main building script:
debian/rules.
Modify the source and save those modifications so that they will be applied 
when building the package.
Remove source modifications that are currently being applied when building 
the package.
Optionally, document what steps are necessary to upgrade the Debian
source package to a new upstream version, if applicable.

This explanation should include specific commands and mention any
additional required Debian packages. It should not assume familiarity
with any specific Debian packaging system or patch management tools.

This explanation may refer to a documentation file installed by one of the
package?s build dependencies provided that the referenced documentation
clearly explains these tasks and is not a general reference manual.

debian/README.source may also include any other information that would
be helpful to someone modifying the source package. Even if the package
doesn?t fit the above description, maintainers are encouraged to document
in a debian/README.source file any source package with a particularly
complex or unintuitive source layout or build system



Your command line history of the 2.7 release would be great.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#911023: memory leak in the backlight control of the dell-laptop module

[Mario.Limonciello]

We did fix a memory leak recently.

Please backport this and see it it helps

https://github.com/torvalds/linux/commit/affab51082174f60ef71ced8ab5fbe71f00e9ae3

On Oct 14, 2018 15:26, Pali Rohár  wrote:
Adding Mario to loop.

Memory leak can be also in ACPI/WMI or in the new dell-smbios.ko module.

On Sunday 14 October 2018 22:18:21 Marco d'Itri wrote:
> Package: src:linux
> Version: 4.18.10-2
> Severity: normal
> Tags: upstream
>
> (I am Cc'in the maintainers of the dell-laptop module, accordingly to
> modinfo.)
>
> After running this for about 1H:
>
> while true; do
>  echo 1 > 
> /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
>  sleep 0.25
>  echo 0 > 
> /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
>  sleep 0.25
> done
>
> most of the memory on my system is used and I get a flood of errors
> like these.
>
> This is a regression, I have noticed this behaviour for at least the
> past 4 months.
>
> Oct 14 16:01:37 bongo kernel: [534600.964709] kworker/1:3: page allocation 
> failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> Oct 14 16:01:37 bongo kernel: [534600.964715] kworker/1:3 cpuset=/ 
> mems_allowed=0
> Oct 14 16:01:37 bongo kernel: [534600.964725] CPU: 1 PID: 32257 Comm: 
> kworker/1:3 Tainted: GW  O  4.18.0-2-amd64 #1 Debian 4.18.10-1
> Oct 14 16:01:37 bongo kernel: [534600.964728] Hardware name: Dell Inc. 
> Latitude 7480/0R0YRF, BIOS 1.10.1 05/28/2018
> Oct 14 16:01:37 bongo kernel: [534600.964736] Workqueue: events 
> set_brightness_delayed
> Oct 14 16:01:37 bongo kernel: [534600.964739] Call Trace:
> Oct 14 16:01:37 bongo kernel: [534600.964749]  dump_stack+0x5c/0x7b
> Oct 14 16:01:37 bongo kernel: [534600.964756]  warn_alloc+0xfc/0x180
> Oct 14 16:01:37 bongo kernel: [534600.964763]  ? _cond_resched+0x15/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964769]  
> __alloc_pages_slowpath+0xcfe/0xd40
> Oct 14 16:01:37 bongo kernel: [534600.964775]  
> __alloc_pages_nodemask+0x236/0x250
> Oct 14 16:01:37 bongo kernel: [534600.964782]  kmalloc_order+0x14/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964787]  kmalloc_order_trace+0x1d/0xa0
> Oct 14 16:01:37 bongo kernel: [534600.964793]  
> acpi_ut_initialize_buffer+0x35/0x6b
> Oct 14 16:01:37 bongo kernel: [534600.964799]  
> acpi_evaluate_object+0x1d6/0x240
> Oct 14 16:01:37 bongo kernel: [534600.964810]  
> wmidev_evaluate_method+0x107/0x150 [wmi]
> Oct 14 16:01:37 bongo kernel: [534600.964819]  run_smbios_call+0x6d/0x1a0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964825]  dell_smbios_wmi_call+0x82/0xd0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964830]  dell_smbios_call+0x6f/0xc0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964836]  kbd_get_state+0x42/0xf0 
> [dell_laptop]
> Oct 14 16:01:37 bongo kernel: [534600.964843]  kbd_led_level_set+0x3c/0x1a0 
> [dell_laptop]
> Oct 14 16:01:37 bongo kernel: [534600.964848]  
> set_brightness_delayed+0x5b/0xa0
> Oct 14 16:01:37 bongo kernel: [534600.964854]  process_one_work+0x195/0x370
> Oct 14 16:01:37 bongo kernel: [534600.964859]  worker_thread+0x30/0x390
> Oct 14 16:01:37 bongo kernel: [534600.964864]  ? process_one_work+0x370/0x370
> Oct 14 16:01:37 bongo kernel: [534600.964868]  kthread+0x113/0x130
> Oct 14 16:01:37 bongo kernel: [534600.964872]  ? 
> kthread_create_worker_on_cpu+0x70/0x70
> Oct 14 16:01:37 bongo kernel: [534600.964876]  ret_from_fork+0x35/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964881] warn_alloc_show_mem: 2 
> callbacks suppressed
> Oct 14 16:01:37 bongo kernel: [534600.964881] Mem-Info:
> Oct 14 16:01:37 bongo kernel: [534600.964891] active_anon:472110 
> inactive_anon:155641 isolated_anon:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  active_file:302512 
> inactive_file:103400 isolated_file:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  unevictable:52 dirty:2 
> writeback:0 unstable:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  slab_reclaimable:34039 
> slab_unreclaimable:27446
> Oct 14 16:01:37 bongo kernel: [534600.964891]  mapped:104119 shmem:28056 
> pagetables:8196 bounce:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  free:108743 free_pcp:1 
> free_cma:0
> Oct 14 16:01:37 bongo kernel: [534600.964903] Node 0 active_anon:1888440kB 
> inactive_anon:622564kB active_file:1210048kB inactive_file:413600kB 
> unevictable:208kB isolated(anon):0kB isolated(file):0kB mapped:416476kB 
> dirty:8kB writeback:0kB shmem:112224kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
> anon_thp: 817152kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> Oct 14 16:01:37 bongo kernel: [534600.964906] Node 0 DMA free:15888kB 
> min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB 
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB 
> present:15988kB managed:15888kB mlocked:0kB kernel_stack:0kB pagetables:0kB 
> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> Oct 14 16:01:37 bongo kernel: [534600.964915] lowmem_reserve[]: 0 3123 

Bug#909913: closed by "Jonathan Carter (highvoltage)" (909913 done)

[Andreas Beckmann]

Control: found -1 0.3.0+dfsg1-4

Bug#911026: ITP: manuskript -- open-source tool for writers

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 

* Package name: manuskript
  Version : 0.7.0
  Upstream Author : Curtis Gedak 
* URL : http://www.theologeek.ch/manuskript/
* License : GPL-3+
  Programming Lang: Python3
  Description : open-source tool for writers


Manuskript is an open source tool for writers. It provides a rich environment
to help writers create their first draft and then further refine and edit
their masterpiece.

Manuskript is still in development, and in need of extensive testing.

Bug#911025: Transition to postgresql-11

[Christoph Berg]

Source: glom
Version: 1.30.4-1
Severity: serious

Hi,

buster will be releasing with postgresql-11. glom depends on
postgresql-10; please update the dependency.

Ideally, the package would only depend on "postgresql", so it doesn't
hardcode a dependency on a single version. The default postgresql
version on a system can be queried using

  /usr/share/postgresql-common/supported-versions | tail -1

(Debian will always only support one version, but if several are
present (e.g. via apt.postgresql.org), the last one is the default
one.)

Stepping back a bit, does the package really need a database server on
the local machine? Does it need to depend on a single server version?

Christoph

Bug#868411: gniall: Port to GTK+ 3

[Jeremy Bicha]

On Sun, Oct 14, 2018 at 5:00 PM Yavor Doganov  wrote:
> I am not in a position to decide the faith of a package that I do not
> maintain.  It looks like a tiny little program that doesn't appear to
> require too much effort wrt maintenance.  Its usefulness is debatable
> but I can say the same about tons of other Debian packages that are
> actively maintained upstream but I don't use; that's very subjective.

With its very low popcon and the fact that it has no maintainer in
Debian (or anywhere), I think your opinion is the most important here.

If you want it to stay in Debian, I can sponsor your upload.
Otherwise, I can file the removal bug now.

> No problem, my patch shouldn't stop you from removing the package if
> that is deemed as the better course of action.  (Although if you or
> other members of the GNOME team intend to remove rdeps rather than
> porting to current APIs, I would appreciate if you communicate your
> intention early enough to avoid unnecessary porting work.)

This is an exceptional case. I think this is the oldest app I've seen
in Debian (based on its last upstream release and maintainer upload
and lack of NMUs).

Thanks,
Jeremy Bicha

Bug#911022: flann breaks hugin autopkgtest: undefined symbol: LZ4_resetStreamHC

[Jochen Sprickerhof]

Hi Paul,

thanks for the report. The new flann version (1.9.1+dfsg-5) doesn't 
bundle lz4 anymore (as per policy and because it broke in Ubuntu, see 
LP: 1786543. I send a pull request to make use of pkg-config in Hugin:


https://salsa.debian.org/debian-phototools-team/hugin/merge_requests/1

@Andreas can you release a new Hugin version with this included? If you 
don't have time, I would push a NMU version to delayed/5, if that's ok 
with you.


Cheers Jochen

* Paul Gevers  [2018-10-14 21:47]:

Source: flann, hugin
Control: found -1 flann/1.9.1+dfsg-4
Control: found -1 hugin/2018.0.0+dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of flann the autopkgtest of hugin fails in testing
when that autopkgtest is run with the binary packages of flann from
unstable. It passes when run with only packages from testing. In tabular
form:
  passfail
flann  from testing1.9.1+dfsg-5
hugin  from testing2018.0.0+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
of flann 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? If needed, please
change the bug's severity.

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

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hugin/1147314/log.gz

autopkgtest [16:37:00]: test simple.pano.test: [---
Generating pto file...
Reading /tmp/tmp.ZePC1LACt6.hugin/left.jpeg...
Reading /tmp/tmp.ZePC1LACt6.hugin/right.jpeg...

Assigned 1 lenses.

Written output to /tmp/tmp.ZePC1LACt6.hugin/pano.pto
cpfind: symbol lookup error: cpfind: undefined symbol: LZ4_resetStreamHC
autopkgtest [16:37:00]: test simple.pano.test: ---]







signature.asc
Description: PGP signature

Bug#868411: gniall: Port to GTK+ 3

[Yavor Doganov]

Jeremy Bicha wrote:
> I think it would be better for Debian for gnial to be removed from
> Debian.  [...] Please let me know what you think we should do here.

I am not in a position to decide the faith of a package that I do not
maintain.  It looks like a tiny little program that doesn't appear to
require too much effort wrt maintenance.  Its usefulness is debatable
but I can say the same about tons of other Debian packages that are
actively maintained upstream but I don't use; that's very subjective.

> I apologize for the time you spent working on this package.

No problem, my patch shouldn't stop you from removing the package if
that is deemed as the better course of action.  (Although if you or
other members of the GNOME team intend to remove rdeps rather than
porting to current APIs, I would appreciate if you communicate your
intention early enough to avoid unnecessary porting work.)

Bug#879530: courier: contains code related to gnutls pgp supprt

[Dimitri John Ledkov]

On Sun, 22 Oct 2017 18:30:54 +0200 Andreas Metzler  wrote:
> Package: courier
> Version: 0.78.0-2
> Severity: minor
> Tags: upstream
> User: ametz...@bebt.de
> Usertags: deprecated-gnutls-3.6
>
> Hello,
>
> libs/tcpd/libcouriergnutls.c contains this code ...
> p->priority_list=safe_getenv(p, "TLS_PRIORITY",
> "NORMAL:-CTYPE-OPENPGP");
> [...]
> if (gnutls_priority_set_direct(ssl->session, ctx->priority_list,
>
> i.e. it explicitely disables gnutls support for openpgp certificates.
>
> GnuTLS stopped enabling OPENPGP certificates by default in 3.0.2 (Sept
> 2011). OpenPGP support in gnutls was removed in 3.6.0. (Noop stub
> functions are still shipped to avoid ABI breakage.)
>
> Therefore imho it makes sense to drop the pgp/gnutls code from courier.
>

Attaching patch.

Regards,

Dimitri.
diff -Nru courier-0.78.0/debian/changelog courier-0.78.0/debian/changelog
--- courier-0.78.0/debian/changelog	2018-02-02 14:24:05.0 +
+++ courier-0.78.0/debian/changelog	2018-10-14 21:33:38.0 +0100
@@ -1,3 +1,9 @@
+courier (0.78.0-2ubuntu3) cosmic; urgency=medium
+
+  * Disable gnutls OPENPGP certificates. Closes: #879530.
+
+ -- Dimitri John Ledkov   Sun, 14 Oct 2018 21:33:38 +0100
+
 courier (0.78.0-2ubuntu2) bionic; urgency=medium
 
   * Rebuild against new libgdbm5.
diff -Nru courier-0.78.0/debian/patches/0018-Fix-default-configuration-for-Debian.patch courier-0.78.0/debian/patches/0018-Fix-default-configuration-for-Debian.patch
--- courier-0.78.0/debian/patches/0018-Fix-default-configuration-for-Debian.patch	2017-09-12 20:55:55.0 +0100
+++ courier-0.78.0/debian/patches/0018-Fix-default-configuration-for-Debian.patch	2018-10-14 21:33:00.0 +0100
@@ -35,6 +35,18 @@
  
  ##NAME: COURIERTLS:0
  #
+@@ -146,9 +146,9 @@
+ #
+ # Set TLS protocol priority settings (GnuTLS only)
+ #
+-# DEFAULT: NORMAL:-CTYPE-OPENPGP
++# DEFAULT: NORMAL
+ #
+-# TLS_PRIORITY="NORMAL:-CTYPE-OPENPGP"
++# TLS_PRIORITY="NORMAL"
+ #
+ # This setting is also used to select the available ciphers.
+ #
 --- a/courier/module.esmtp/esmtpd.dist.in
 +++ b/courier/module.esmtp/esmtpd.dist.in
 @@ -36,7 +36,7 @@
@@ -62,6 +74,18 @@
  
  ##NAME: TARPIT:1
  #
+@@ -135,9 +135,9 @@
+ #
+ # Set TLS protocol priority settings (GnuTLS only)
+ #
+-# DEFAULT: NORMAL:-CTYPE-OPENPGP
++# DEFAULT: NORMAL
+ #
+-# TLS_PRIORITY="NORMAL:-CTYPE-OPENPGP"
++# TLS_PRIORITY="NORMAL"
+ 
+ ##NAME: TLS_PROTOCOL:0
+ #
 @@ -211,7 +211,7 @@
  # In all cases, $TLS_CERTFILE needs to be linked to one of the existing
  # certificate files.
@@ -99,6 +123,15 @@
  
  ##NAME: IMAPDSTARTTLS:0
  #
+@@ -110,7 +110,7 @@
+ #
+ # Set TLS protocol priority settings (GnuTLS only)
+ #
+-# DEFAULT: NORMAL:-CTYPE-OPENPGP
++# DEFAULT: NORMAL
+ #
+ # This setting is also used to select the available ciphers.
+ #
 --- a/libs/imap/imapd.dist.in
 +++ b/libs/imap/imapd.dist.in
 @@ -57,7 +57,7 @@
@@ -139,6 +172,18 @@
  
  ##NAME: POP3_STARTTLS:0
  #
+@@ -93,9 +93,9 @@
+ #
+ # Set TLS protocol priority settings (GnuTLS only)
+ #
+-# DEFAULT: NORMAL:-CTYPE-OPENPGP
++# DEFAULT: NORMAL
+ #
+-# TLS_PRIORITY="NORMAL:-CTYPE-OPENPGP"
++# TLS_PRIORITY="NORMAL"
+ #
+ # This setting is also used to select the available ciphers.
+ #
 --- a/libs/imap/pop3d.dist.in
 +++ b/libs/imap/pop3d.dist.in
 @@ -146,7 +146,7 @@
@@ -150,3 +195,28 @@
  
  ##NAME: POP3_LOG_DELETIONS:0
  #
+--- a/courier/courierd.dist.in
 b/courier/courierd.dist.in
+@@ -280,9 +280,9 @@
+ #
+ # Set TLS protocol priority settings (GnuTLS only)
+ #
+-# DEFAULT: NORMAL:-CTYPE-OPENPGP
++# DEFAULT: NORMAL
+ #
+-# TLS_PRIORITY="NORMAL:-CTYPE-OPENPGP"
++# TLS_PRIORITY="NORMAL"
+ #
+ # This setting is also used to select the available ciphers.
+ #
+--- a/libs/tcpd/libcouriergnutls.c
 b/libs/tcpd/libcouriergnutls.c
+@@ -239,7 +239,7 @@
+ 	}
+ 
+ 	p->priority_list=safe_getenv(p, "TLS_PRIORITY",
+- "NORMAL:-CTYPE-OPENPGP");
++ "NORMAL");
+ 
+ 	if ((certfile=strdup(safe_getenv(p, "TLS_CERTFILE", ""))) == NULL ||
+ 	(p->trustcerts=strdup(safe_getenv(p, "TLS_TRUSTCERTS", "")))

Bug#911024: src:haskell-monadplus: unmaintained

[Clint Adams]

Package: src:haskell-monadplus
Version: 1.4.2-5
Severity: serious

monadplus is probably not worth the maintenance burden.
Please close this bug if you disagree.

Bug#911023: memory leak in the backlight control of the dell-laptop module

[Pali Rohár]

Adding Mario to loop.

Memory leak can be also in ACPI/WMI or in the new dell-smbios.ko module.

On Sunday 14 October 2018 22:18:21 Marco d'Itri wrote:
> Package: src:linux
> Version: 4.18.10-2
> Severity: normal
> Tags: upstream
> 
> (I am Cc'in the maintainers of the dell-laptop module, accordingly to 
> modinfo.)
> 
> After running this for about 1H:
> 
> while true; do
>  echo 1 > 
> /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
>  sleep 0.25
>  echo 0 > 
> /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
>  sleep 0.25
> done
> 
> most of the memory on my system is used and I get a flood of errors 
> like these.
> 
> This is a regression, I have noticed this behaviour for at least the 
> past 4 months.
> 
> Oct 14 16:01:37 bongo kernel: [534600.964709] kworker/1:3: page allocation 
> failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> Oct 14 16:01:37 bongo kernel: [534600.964715] kworker/1:3 cpuset=/ 
> mems_allowed=0
> Oct 14 16:01:37 bongo kernel: [534600.964725] CPU: 1 PID: 32257 Comm: 
> kworker/1:3 Tainted: GW  O  4.18.0-2-amd64 #1 Debian 4.18.10-1
> Oct 14 16:01:37 bongo kernel: [534600.964728] Hardware name: Dell Inc. 
> Latitude 7480/0R0YRF, BIOS 1.10.1 05/28/2018
> Oct 14 16:01:37 bongo kernel: [534600.964736] Workqueue: events 
> set_brightness_delayed
> Oct 14 16:01:37 bongo kernel: [534600.964739] Call Trace:
> Oct 14 16:01:37 bongo kernel: [534600.964749]  dump_stack+0x5c/0x7b
> Oct 14 16:01:37 bongo kernel: [534600.964756]  warn_alloc+0xfc/0x180
> Oct 14 16:01:37 bongo kernel: [534600.964763]  ? _cond_resched+0x15/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964769]  
> __alloc_pages_slowpath+0xcfe/0xd40
> Oct 14 16:01:37 bongo kernel: [534600.964775]  
> __alloc_pages_nodemask+0x236/0x250
> Oct 14 16:01:37 bongo kernel: [534600.964782]  kmalloc_order+0x14/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964787]  kmalloc_order_trace+0x1d/0xa0
> Oct 14 16:01:37 bongo kernel: [534600.964793]  
> acpi_ut_initialize_buffer+0x35/0x6b
> Oct 14 16:01:37 bongo kernel: [534600.964799]  
> acpi_evaluate_object+0x1d6/0x240
> Oct 14 16:01:37 bongo kernel: [534600.964810]  
> wmidev_evaluate_method+0x107/0x150 [wmi]
> Oct 14 16:01:37 bongo kernel: [534600.964819]  run_smbios_call+0x6d/0x1a0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964825]  dell_smbios_wmi_call+0x82/0xd0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964830]  dell_smbios_call+0x6f/0xc0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964836]  kbd_get_state+0x42/0xf0 
> [dell_laptop]
> Oct 14 16:01:37 bongo kernel: [534600.964843]  kbd_led_level_set+0x3c/0x1a0 
> [dell_laptop]
> Oct 14 16:01:37 bongo kernel: [534600.964848]  
> set_brightness_delayed+0x5b/0xa0
> Oct 14 16:01:37 bongo kernel: [534600.964854]  process_one_work+0x195/0x370
> Oct 14 16:01:37 bongo kernel: [534600.964859]  worker_thread+0x30/0x390
> Oct 14 16:01:37 bongo kernel: [534600.964864]  ? process_one_work+0x370/0x370
> Oct 14 16:01:37 bongo kernel: [534600.964868]  kthread+0x113/0x130
> Oct 14 16:01:37 bongo kernel: [534600.964872]  ? 
> kthread_create_worker_on_cpu+0x70/0x70
> Oct 14 16:01:37 bongo kernel: [534600.964876]  ret_from_fork+0x35/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964881] warn_alloc_show_mem: 2 
> callbacks suppressed
> Oct 14 16:01:37 bongo kernel: [534600.964881] Mem-Info:
> Oct 14 16:01:37 bongo kernel: [534600.964891] active_anon:472110 
> inactive_anon:155641 isolated_anon:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  active_file:302512 
> inactive_file:103400 isolated_file:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  unevictable:52 dirty:2 
> writeback:0 unstable:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  slab_reclaimable:34039 
> slab_unreclaimable:27446
> Oct 14 16:01:37 bongo kernel: [534600.964891]  mapped:104119 shmem:28056 
> pagetables:8196 bounce:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  free:108743 free_pcp:1 
> free_cma:0
> Oct 14 16:01:37 bongo kernel: [534600.964903] Node 0 active_anon:1888440kB 
> inactive_anon:622564kB active_file:1210048kB inactive_file:413600kB 
> unevictable:208kB isolated(anon):0kB isolated(file):0kB mapped:416476kB 
> dirty:8kB writeback:0kB shmem:112224kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
> anon_thp: 817152kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> Oct 14 16:01:37 bongo kernel: [534600.964906] Node 0 DMA free:15888kB 
> min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB 
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB 
> present:15988kB managed:15888kB mlocked:0kB kernel_stack:0kB pagetables:0kB 
> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> Oct 14 16:01:37 bongo kernel: [534600.964915] lowmem_reserve[]: 0 3123 7812 
> 7812 7812
> Oct 14 16:01:37 bongo kernel: [534600.964922] Node 0 DMA32 free:302908kB 
> min:26968kB low:33708kB high:40448kB active_anon:474228kB 
> inactive_anon:109220kB 

Bug#879531: echoping: contains code related to gnutls pgp supprt

[Dimitri John Ledkov]

On Sun, 22 Oct 2017 18:38:28 +0200 Andreas Metzler  wrote:
> Package: echoping
> Version: 6.0.2-10
> Severity: minor
> Tags: upstream
> User: ametz...@bebt.de
> Usertags: deprecated-gnutls-3.6
>
> Hello,
>
> echoping.c contains this code ...
> upstream:
> const int   cert_type_priority[3] = { GNUTLS_CRT_X509,
> GNUTLS_CRT_OPENPGP, 0
> };
> gnutls_certificate_type_set_priority(session, cert_type_priority);
>
> as patched by Debian:
> gnutls_priority_set_direct(session, "NORMAL:+CTYPE-OPENPGP", NULL);
>
> i.e. it explicitely enables gnutls support for openpgp certificates.
>
> GnuTLS stopped enabling OPENPGP certificates by default in 3.0.2 (Sept
> 2011). OpenPGP support in gnutls was marked deprecated in 3.5.9 and was
> removed in 3.6.0. (Noop stub functions are still shipped to avoid ABI
> breakage.)
>
> Therefore imho it makes sense to drop the pgp/gnutls code from echoping.
>
> cu Andreas

Attaching patch.

Regards,

Dimitri.
Description: Remove usage of openpgp certificates. (Closes: #879531)
Author: Dimitri John Ledkov 
Bug-Debian: https://bugs.debian.org/879531

--- echoping-6.0.2.orig/echoping.c
+++ echoping-6.0.2/echoping.c
@@ -1018,7 +1018,7 @@ main(argc, argv)
 		err_sys
 		("Cannot create a new TLS session");
 	gnutls_priority_set_direct(session,
-			"NORMAL:+CTYPE-OPENPGP",
+			"NORMAL",
 			NULL);
 	gnutls_credentials_set(session,
 			   GNUTLS_CRD_CERTIFICATE,

Bug#769541: Forretningsforslag

[David Edward John R]

Dato: 13.10.2018
  
Jeg har et fortroligt forretningsforslag til dig, som er et betydeligt beløb 
værd (13,5 mio. GBP). Hvis du er interesseret, svar tilbage via nedenstående 
e-mail for flere detaljer.
 
Bemærk: Hvis du kan tale eller skrive på engelsk, svar venligst på engelsk for 
bedre kommunikation.
 
Med venlig hilsen,
Sir David Edward John R.
Vicedirektør
Markeder og bankvirksomhed,
Bank of England.
Tlf .: 075 4328 2201
E-mail: dav...@gmx.com
__
Sekretær: Fru Celine Harris

Bug#911023: memory leak in the backlight control of the dell-laptop module

[Marco d'Itri]

Package: src:linux
Version: 4.18.10-2
Severity: normal
Tags: upstream

(I am Cc'in the maintainers of the dell-laptop module, accordingly to 
modinfo.)

After running this for about 1H:

while true; do
 echo 1 > /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
 sleep 0.25
 echo 0 > /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
 sleep 0.25
done

most of the memory on my system is used and I get a flood of errors 
like these.

This is a regression, I have noticed this behaviour for at least the 
past 4 months.

Oct 14 16:01:37 bongo kernel: [534600.964709] kworker/1:3: page allocation 
failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
Oct 14 16:01:37 bongo kernel: [534600.964715] kworker/1:3 cpuset=/ 
mems_allowed=0
Oct 14 16:01:37 bongo kernel: [534600.964725] CPU: 1 PID: 32257 Comm: 
kworker/1:3 Tainted: GW  O  4.18.0-2-amd64 #1 Debian 4.18.10-1
Oct 14 16:01:37 bongo kernel: [534600.964728] Hardware name: Dell Inc. Latitude 
7480/0R0YRF, BIOS 1.10.1 05/28/2018
Oct 14 16:01:37 bongo kernel: [534600.964736] Workqueue: events 
set_brightness_delayed
Oct 14 16:01:37 bongo kernel: [534600.964739] Call Trace:
Oct 14 16:01:37 bongo kernel: [534600.964749]  dump_stack+0x5c/0x7b
Oct 14 16:01:37 bongo kernel: [534600.964756]  warn_alloc+0xfc/0x180
Oct 14 16:01:37 bongo kernel: [534600.964763]  ? _cond_resched+0x15/0x40
Oct 14 16:01:37 bongo kernel: [534600.964769]  
__alloc_pages_slowpath+0xcfe/0xd40
Oct 14 16:01:37 bongo kernel: [534600.964775]  
__alloc_pages_nodemask+0x236/0x250
Oct 14 16:01:37 bongo kernel: [534600.964782]  kmalloc_order+0x14/0x40
Oct 14 16:01:37 bongo kernel: [534600.964787]  kmalloc_order_trace+0x1d/0xa0
Oct 14 16:01:37 bongo kernel: [534600.964793]  
acpi_ut_initialize_buffer+0x35/0x6b
Oct 14 16:01:37 bongo kernel: [534600.964799]  acpi_evaluate_object+0x1d6/0x240
Oct 14 16:01:37 bongo kernel: [534600.964810]  
wmidev_evaluate_method+0x107/0x150 [wmi]
Oct 14 16:01:37 bongo kernel: [534600.964819]  run_smbios_call+0x6d/0x1a0 
[dell_smbios]
Oct 14 16:01:37 bongo kernel: [534600.964825]  dell_smbios_wmi_call+0x82/0xd0 
[dell_smbios]
Oct 14 16:01:37 bongo kernel: [534600.964830]  dell_smbios_call+0x6f/0xc0 
[dell_smbios]
Oct 14 16:01:37 bongo kernel: [534600.964836]  kbd_get_state+0x42/0xf0 
[dell_laptop]
Oct 14 16:01:37 bongo kernel: [534600.964843]  kbd_led_level_set+0x3c/0x1a0 
[dell_laptop]
Oct 14 16:01:37 bongo kernel: [534600.964848]  set_brightness_delayed+0x5b/0xa0
Oct 14 16:01:37 bongo kernel: [534600.964854]  process_one_work+0x195/0x370
Oct 14 16:01:37 bongo kernel: [534600.964859]  worker_thread+0x30/0x390
Oct 14 16:01:37 bongo kernel: [534600.964864]  ? process_one_work+0x370/0x370
Oct 14 16:01:37 bongo kernel: [534600.964868]  kthread+0x113/0x130
Oct 14 16:01:37 bongo kernel: [534600.964872]  ? 
kthread_create_worker_on_cpu+0x70/0x70
Oct 14 16:01:37 bongo kernel: [534600.964876]  ret_from_fork+0x35/0x40
Oct 14 16:01:37 bongo kernel: [534600.964881] warn_alloc_show_mem: 2 callbacks 
suppressed
Oct 14 16:01:37 bongo kernel: [534600.964881] Mem-Info:
Oct 14 16:01:37 bongo kernel: [534600.964891] active_anon:472110 
inactive_anon:155641 isolated_anon:0
Oct 14 16:01:37 bongo kernel: [534600.964891]  active_file:302512 
inactive_file:103400 isolated_file:0
Oct 14 16:01:37 bongo kernel: [534600.964891]  unevictable:52 dirty:2 
writeback:0 unstable:0
Oct 14 16:01:37 bongo kernel: [534600.964891]  slab_reclaimable:34039 
slab_unreclaimable:27446
Oct 14 16:01:37 bongo kernel: [534600.964891]  mapped:104119 shmem:28056 
pagetables:8196 bounce:0
Oct 14 16:01:37 bongo kernel: [534600.964891]  free:108743 free_pcp:1 free_cma:0
Oct 14 16:01:37 bongo kernel: [534600.964903] Node 0 active_anon:1888440kB 
inactive_anon:622564kB active_file:1210048kB inactive_file:413600kB 
unevictable:208kB isolated(anon):0kB isolated(file):0kB mapped:416476kB 
dirty:8kB writeback:0kB shmem:112224kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 817152kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Oct 14 16:01:37 bongo kernel: [534600.964906] Node 0 DMA free:15888kB min:132kB 
low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB 
inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB 
managed:15888kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB 
free_pcp:0kB local_pcp:0kB free_cma:0kB
Oct 14 16:01:37 bongo kernel: [534600.964915] lowmem_reserve[]: 0 3123 7812 
7812 7812
Oct 14 16:01:37 bongo kernel: [534600.964922] Node 0 DMA32 free:302908kB 
min:26968kB low:33708kB high:40448kB active_anon:474228kB 
inactive_anon:109220kB active_file:145492kB inactive_file:75160kB 
unevictable:0kB writepending:0kB present:3298264kB managed:3232156kB 
mlocked:0kB kernel_stack:64kB pagetables:748kB bounce:0kB free_pcp:0kB 
local_pcp:0kB free_cma:0kB
Oct 14 16:01:37 bongo kernel: [534600.964930] lowmem_reserve[]: 0 0 4688 4688 
4688
Oct 14 16:01:37 bongo kernel: [534600.964936] Node 0 Normal free:116176kB 

Bug#910567: ITA: sn -- Small NNTP server for leaf sites

[Hilko Bengen]

* Robert J. Clay:

>Did you push all of the branches? I only see one branch, named
> 'upstream'; and like I mentioned, that only has one commit listed when
> I look *using 'tid', for instance).  No 'pristine-tar'  or even a
> 'master'  branch.

There are two branches, "upstream" and "master". No "pristine-tar"
branch. For some reason Gitlab thinks that "upstream" should be the
"default" branch, i.e. the branch that is checked out after a git clone.

Cheers,
-Hilko

Bug#910941: apt-get changelog uses insecure HTTP for Debian

[Ben Hutchings]

On Sun, 2018-10-14 at 01:48 +0200, David Kalnischkies wrote:
> Control: clone -1 -2
> Control: severity -1 wishlist
> Control: reassign -2 ftp.debian.org
> 
> On Sat, Oct 13, 2018 at 05:06:37PM +0100, Ben Hutchings wrote:
> > The default value of Acquire::Changelogs::URI::Origin::Debian is
> > "http://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog;.
> 
> Note that this value is not used as long as the Release file contains
> a Changelogs: field – which has the same value ATM.
[...]
> That is so that any repository can provide changelogs for its packages –
> and that the URI can be changed without changing apt which has happened
> historically a few times before this mechanism was introduced ~3 years
> ago.

OK, this makes a lot of sense.  Presumably the settings in APT will be
removed once all a distribution's supported releases include this
field?

> > Since metadata.ftp-master.debian.org supports HTTP-S and redirects to
> > the https: scheme, the URL should be changed to use it from the start.
> 
> I think the apt client is exempt from such an automatic redirect.
> The "reason" is that apt < 1.5 has no built-in support for https and needs
> apt-transport-https installed.

Yes, I remember that problem.  My point was that the redirect indicates
that the https: URLs should be considered canonical.

> Changing that value now means that changelog wont work for stable users
> anymore who are trying to access newer Debian releases as long as they
> haven't a-t-https installed – but that might be acceptable.
[...]

That seems like a reasonable thing to require.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.




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

Bug#879537: filezilla: contains code related to gnutls pgp supprt

[Dimitri John Ledkov]

On Sun, 22 Oct 2017 18:49:04 +0200 Andreas Metzler  wrote:
> Package: filezilla
> Version: 3.27.0~rc1-1
> Severity: minor
> Tags: upstream
> User: ametz...@bebt.de
> Usertags: deprecated-gnutls-3.6
>
> Hello,
>
> src/engine/tlssocket_impl.cpp contains this code:
> #if FZ_USE_GNUTLS_SYSTEM_CIPHERS
> char const ciphers[] = "@SYSTEM";
> #else
> char const ciphers[] = 
> "SECURE256:+SECURE128:-ARCFOUR-128:-3DES-CBC:-MD5:+SIGN-ALL:-SIGN-RSA-MD5:+CTYPE-X509:-CTYPE-OPENPGP:-VERS-SSL3.0";
> #endif
> ...
> res = gnutls_priority_set_direct(m_session, ciphers, 0);
>
> i.e. it explicitely disables gnutls support for openpgp certificates.
>
> GnuTLS stopped enabling OPENPGP certificates by default in 3.0.2 (Sept
> 2011). OpenPGP support in gnutls was marked deprecated in 3.5.9 and was
> removed in 3.6.0. (Noop stub functions are still shipped to avoid ABI
> breakage.)
>
> Therefore imho it makes sense to drop the pgp/gnutls code from filezilla.

Can be done with --enable-gnutlssystemciphers

Regards,

Dimitri.
diff -Nru filezilla-3.33.0/debian/changelog filezilla-3.33.0/debian/changelog
--- filezilla-3.33.0/debian/changelog	2018-06-14 15:36:59.0 +0100
+++ filezilla-3.33.0/debian/changelog	2018-10-14 20:54:23.0 +0100
@@ -1,3 +1,10 @@
+filezilla (3.33.0-1ubuntu1) cosmic; urgency=medium
+
+  * Configure with --enable-gnutlssystemciphers to not use OPENPGP cert
+type in gnutls configure string. Closes: #879537
+
+ -- Dimitri John Ledkov   Sun, 14 Oct 2018 20:54:23 +0100
+
 filezilla (3.33.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru filezilla-3.33.0/debian/rules filezilla-3.33.0/debian/rules
--- filezilla-3.33.0/debian/rules	2018-06-14 15:36:59.0 +0100
+++ filezilla-3.33.0/debian/rules	2018-10-14 20:54:21.0 +0100
@@ -6,7 +6,7 @@
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --disable-autoupdatecheck --with-dbus
+	dh_auto_configure -- --disable-autoupdatecheck --with-dbus --enable-gnutlssystemciphers
 
 override_dh_auto_install:
 	# Create .xpm from .png and install it

Bug#910923: $PLATFORM is no longer expanded.

[Aurelien Jarno]

control: severity -1 normal
control: retitle -1 libc6: broken support for curly braces DST

On 2018-10-13 16:13, Roman Lebedev wrote:
> Source: glibc
> Version: 2.27-6
> Severity: important
> 
> Reproduction:
> $ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat
> execve("/bin/cat", ["/bin/cat"], 0x55ddc6b820f0 /* 64 vars */) = 0
> brk(NULL)   = 0x56046d9c1000
> access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
> directory)
> readlink("/proc/self/exe", "/bin/cat", 4096) = 8
> openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
> file or directory)
> writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22}, 
> {iov_base="/sss/${PLATFORM}/", iov_len=21}, {iov_base="' from ", 
> iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be 
> preloaded (", iov_len=22}, {iov_base="cannot open shared object file", 
> iov_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so: object 
> '/sss/${PLATFORM}/' from LD_PRELOAD cannot be preloaded (cannot open 
> shared object file): ignored.
> ) = 124
> 
> So $PLATFORM is not expanded. This is a regression from 2.24

Actually ${PLATFORM} is not expanded. If you try with $PLATFORM you will
see it is correctly expanded.

> According to
> https://sourceware.org/bugzilla/show_bug.cgi?id=22299
> it *should* be fixed in 2.27, but it is clerly still reproducible in
> debian testing/sid.

This is a different bug, as shown above the problem is that support for
curly braces does not work anymore.

> This is causing the following problem for me:
> https://community.sonarsource.com/t/sonarqube-c-ubuntu-build-wrapper-ld-preload-error/300/2

The workaround is to use $PLATFORM instead of ${PLATFORM}.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#911022: flann breaks hugin autopkgtest: undefined symbol: LZ4_resetStreamHC

[Paul Gevers]

Source: flann, hugin
Control: found -1 flann/1.9.1+dfsg-4
Control: found -1 hugin/2018.0.0+dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of flann the autopkgtest of hugin fails in testing
when that autopkgtest is run with the binary packages of flann from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
flann  from testing1.9.1+dfsg-5
hugin  from testing2018.0.0+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
of flann 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? If needed, please
change the bug's severity.

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

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hugin/1147314/log.gz

autopkgtest [16:37:00]: test simple.pano.test: [---
Generating pto file...
Reading /tmp/tmp.ZePC1LACt6.hugin/left.jpeg...
Reading /tmp/tmp.ZePC1LACt6.hugin/right.jpeg...

Assigned 1 lenses.

Written output to /tmp/tmp.ZePC1LACt6.hugin/pano.pto
cpfind: symbol lookup error: cpfind: undefined symbol: LZ4_resetStreamHC
autopkgtest [16:37:00]: test simple.pano.test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

control: tag -1 confirmed


[2018-10-13 13:20] Niko Tyni 
>
> part   text/plain1170
> Package: libgdbm6
> Version: 1.18-2
> Severity: grave
> X-Debbugs-Cc: p...@packages.debian.org, 
> libmarc-charset-p...@packages.debian.org
> 
> The libgdbm6 transition broke autopkgtest checks of src:perl and
> libmarc-charset-perl.
> 
> It looks like some GDBM databases which were working with the older
> gdbm are not readable any more with the new one.
> 
>  # file /usr/lib/libmarc-charset-perl/Table
>  /usr/lib/libmarc-charset-perl/Table: GNU dbm 1.x or ndbm database, little 
> endian, old

Yes, I can confirm the problem. I already located commit, that
introduced it (2ed540). Its commit message is 'Improve error checking',
so right now I am investigating, whether there is error in mentioned
commit, or mentioned database has format errors.

Bug#911021: tandem-mass FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: tandem-mass
Version: 1:20170201.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tandem-mass fails to cross build from source, because it uses the build
architecture compiler and consequently fails finding -lexpat, which is
only requested for the host architecture by Build-Depends. dh_auto_build
passes cross tools to make and once using dh_auto_build, tandem-mass
cross builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tandem-mass-20170201.1/debian/changelog 
tandem-mass-20170201.1/debian/changelog
--- tandem-mass-20170201.1/debian/changelog 2017-08-22 15:36:59.0 
+0200
+++ tandem-mass-20170201.1/debian/changelog 2018-10-14 21:26:59.0 
+0200
@@ -1,3 +1,10 @@
+tandem-mass (1:20170201.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 14 Oct 2018 21:26:59 +0200
+
 tandem-mass (1:20170201.1-1) unstable; urgency=low
 
   * debian/control: add secure vcs-git url.
diff --minimal -Nru tandem-mass-20170201.1/debian/rules 
tandem-mass-20170201.1/debian/rules
--- tandem-mass-20170201.1/debian/rules 2017-08-22 15:36:59.0 +0200
+++ tandem-mass-20170201.1/debian/rules 2018-10-14 21:26:55.0 +0200
@@ -29,7 +29,7 @@
 # Proper Makefile settings have been defined in src/Makefile_ubuntu
 # with a corresponding patch.
 
-   cd src && $(MAKE) -f Makefile_ubuntu
+   dh_auto_build --sourcedirectory=src --buildsystem=makefile -- -f 
Makefile_ubuntu
 
touch build-stamp
 

Bug#906016: transition: gjs built with mozjs60

[Jeremy Bicha]

I found a few more dependencies today:
gnome-initial-setup
gnome-panel
sssd

sssd doesn't need gdm3 so I opened
https://salsa.debian.org/sssd-team/sssd/merge_requests/3

Thanks,
Jeremy Bicha

Bug#908947: youtube-dl: backport youtube-dl to recent version for stretch

[Rogério Brito]

Em 12 de outubro de 2018 17:09:18 BRT, Holger Levsen  
escreveu:
>Dear Rogério, dear release team, dear backports-admins,
>
>On Sun, Sep 16, 2018 at 02:57:30PM +0200, Thierry wrote:
>> Package: youtube-dl
>> Version: 2017.05.18.1-1
>> Severity: grave
>> Justification: renders package unusable
>> 
>> Dear Maintainer,
>> 
>> the version of youtube-dl that is shipped with stretch does not work
>> anymore for the youtube website, making the package unusable for some
>> videos. It should be updated to a more recent version. If this is not
>> possible by Debian policy, stretch-backport should provide a recent
>> version.
>
>(it's not only youtube that's broken but also others..)
>
>For the 2nd time in 2 months today I have installed a local backport of
>youtube-dl on my machine (and soon will do the same at friends...) so
>by
>now I'm also pretty close to upload youtube 2018.09.10-1~bpo9+1 to
>stretch-backports to solve this (better) for "me" (and others) but then
>I really do believe this should be fixed by uploading
>2018.09.10-1~deb9u1 to stable(-updates).
>
>what's your stance on this? 
>
>I'm happy to prepare uploads to either if that helps. (and a proper bug
>if the stable updates route is chosen.)

Dear Holger and release team,

First of all, sorry for the short answer, but I am using my phone.

Second, I would like to more formally update youtube-dl for stable releases in 
conjunction with Holger.

The justification is that the package is very volatile and breaks every few 
weeks according to changes of the sites that it supports (and there are some 
big names besides YouTube itself).

Besides that, at least one other "important" package (namely, mpv) depends on 
youtube-dl.

So, what is the way to proceed with updates to stable releases? I've never done 
that before.

Thanks,

Rogério Brito.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#910567: ITA: sn -- Small NNTP server for leaf sites

[Robert J. Clay]

On Sun, Oct 14, 2018 at 11:08 AM Robert J. Clay  wrote:
> > I had put the sn package into git but as far as I recall I never
> > published that repository. Fixed that, see
> > .
>
>I cloned that to take a look.  I see that it only seems to have one
> branch & one commit, but multiple tags?

   Did you push all of the branches? I only see one branch, named
'upstream'; and like I mentioned, that only has one commit listed when
I look *using 'tid', for instance).  No 'pristine-tar'  or even a
'master'  branch.



-- 
Robert J. Clay
rjc...@gmail.com

Bug#911020: installation-guide: Comments on section D.3

[Brian Potkin]

Package: installation-guide
Severity: normal
Tags: d-i



Please have a look at

  https://lists.debian.org/debian-user/2018/10/msg00438.html

and its followup

  https://lists.debian.org/debian-user/2018/10/msg00448.html

Could changes to advice for /e/n/i and /etc/hosts be considered?

Regards,

Brian.

Bug#890200: PyQt5 package should provide an egg-info

[Bastian Germann]

I changed the package to include the files as described.

Bug#696508: bitcoin-qt: GUI client should register bitcoin: protocol with Iceweasel

[Petter Reinholdtsen]

I recently discovered one approach to registering new protocols that at least
work with firefox.  By registering the "pseudo" MIME type
x-scheme-handler/ with the mime system and the .desktop system,
at least the firefox browser will suggest to start the registered program.

I just uploaded a version of vlc-plugin-bittorrent using this trick to
support magnet: style links.  I suspect it can be used to support
bitcoin: style links too.

-- 
Happy hacking
Petter Reinholdtsen

Bug#909523: cachefilesd broken by apparmor

[Vincent Van Houtte]

I can confirm both the issue and the workaround.

Online sources seem to indicate that one can write an AppArmor profile 
for any daemon... I'm more than happy to contribute by testing and get 
this one solved.


Kr,

Vincent

Bug#911019: mandb: long waiting time during system update

[Antonio]

Package: man-db
Version: 2.8.4-2+b1
Severity: normal

Dear Maintainer,
why does mandb take about 1-2 minutes, each time, when invoked during
apt-get dist-
upgrade?
Thanks.

-- NOTE --

# files count:
$ find /usr/share/man -type f|wc -l
23424

/usr/share/man/it :   287
/usr/share/man/man1 :  6407
/usr/share/man/man2 :   639
/usr/share/man/man3 : 10607
/usr/share/man/man4 :   920
/usr/share/man/man5 :   567
/usr/share/man/man6 :   288
/usr/share/man/man7 :   328
/usr/share/man/man8 :  1447
/usr/share/man/man9 :  1934

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

Kernel: Linux 4.18.14-custom (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1), LANGUAGE=it
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  groff-base 1.22.3-10
ii  libc6  2.27-6
ii  libgdbm6   1.18-2
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.3-3
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor 2.13-8
ii  elinks [www-browser] 0.12~pre6-13
ii  groff1.22.3-10
ii  konqueror [www-browser]  4:18.04.0-1+b1
ii  less 487-0.1+b1
ii  links [www-browser]  2.17-1
ii  links2 [www-browser] 2.17-1
ii  lynx [www-browser]   2.8.9rel.1-2
ii  w3m [www-browser]0.5.3-36+b1

-- debconf information:
  man-db/rebuild-database: true
  man-db/build-database: true
* man-db/install-setuid: false
  man-db/auto-update: true

Bug#910997: i3-wm: please avoid dependency on x11-utils if possibly

[Michael Stapelberg]

control: tags -1 + pending

Thanks, addressing this in https://github.com/i3/i3/pull/3455

On Sun, Oct 14, 2018 at 5:39 PM Jonas Smedegaard  wrote:

> Package: i3-wm
> Version: 4.15-1
> Severity: minor
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> i3-wm depends on x11-utils.
>
> This indirectly pulls in Mesa which is consumes quite some diskspace.
>
> Please, if possible, avoid that dependency.
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvDYksACgkQLHwxRsGg
> ASGgyA/8DY4HJeyx9xdjlcJ31tTNut0hLQKFH1K7Voki5jZWDD8J9zi+wNhIOnKp
> Paaa/Rnmxy4lTl09l9Bg5ShK5+KrdrZGG0jFMKC15FkSyEEXq7YzKdZhq9oa2LmX
> CHA5FeYcM+Hk3KnNdIyDqYRJw1iSXhrVsegD4AOPAAFb6oArlawfrEvu6VqmKabJ
> ZEqgrHozle9nQfA8Xg7sPbEivPUGdbPoH66ct/1wf/D2Wb5qdydscYklhUsY5nSb
> 2UyA/z+a2bHK40Xv8JT/cobZ0Qf/WZlZlLce+lHhJFPde7f/Mxd/OMF+P1of9gYk
> 2DXHfHsSauQC9jtuJgMiv/f+jPXHefvr+b/qsPnSLAiCOWuTQg0kfGqVEc794/it
> JE/BuYJfgHM9jweNrv9W3BvWRWUbOrhgCFuBBr22WshDWKbJ/rdO4gdodRUp0lSH
> 5/1LX9RI7PTa4aD/HnDzHli/4Uu6PUDejXF9SRwaRlZ3Qk0/Idw2wPE7rs6+LV4o
> m84JQYQ7UdIB88GT7Fw7EBI1U0a39xY4GK0wz8JNfvR5wUS639gjijSQvDjsIheV
> 9AsEg9HJibauq3JtP9cdpYz0tmJbCdxt/zaYA6HekwSu+/DYgE8q+cBPJa6eyXIC
> AS3dDzMe/AF+R8D7Tt5OHSqv2lGWeQ6W1B/U/3yetNB3IXWfsno=
> =AytD
> -END PGP SIGNATURE-
>


-- 
Best regards,
Michael

Bug#910865: prometheus-node-exporter: Files in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ should not be compressed

[Martín Ferrari]

Philipp,

On 13/10/18 17:04, Philipp Kern wrote:

>> True. But right now I don't have the bandwidth do write those.. I would
>> be glad to add them if you write them :)
> 
> https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1
> 
> Please test and let me know if that works / doesn't work for you. And
> yes, maybe that should have been contributed upstream instead, but a
> distro can be more opinionated.

Thanks a lot! I left my comments on the merge request, for simpler
follow-up.

Re upstream: I think it is worth also contributing it upstream, it would
fit with the examples.

-- 
Martín Ferrari (Tincho)

Bug#911018: empry directories not removed

[積丹尼 Dan Jacobson]

Package: php7.2-cli
Version: 7.2.9-1

Purging configuration files for php7.2-cli (7.2.9-1) ...
dpkg: warning: while removing php7.2-cli, directory '/etc/php/7.2/cli/conf.d' 
not empty so not removed
Purging configuration files for php7.2-json (7.2.9-1) ...
dpkg: warning: while removing php7.2-json, directory 
'/etc/php/7.2/mods-available' not empty so not removed

$ find /etc/php/7.2/ -ls
   409602  4 drwxr-xr-x   4 root root 4096  1月 26  2018 
/etc/php/7.2/
   409604  4 drwxr-xr-x   3 root root 4096 10月 15 01:31 
/etc/php/7.2/cli
   409605  4 drwxr-xr-x   2 root root 4096 10月 15 01:31 
/etc/php/7.2/cli/conf.d
   409603  4 drwxr-xr-x   2 root root 4096 10月 15 01:31 
/etc/php/7.2/mods-available

OK I'll remove them all by hand.

Bug#910913: RFS: ghostwriter/1.7.3-1 [ITP]

[Herbert Fortes]

On 10/14/18 8:38 AM, ghost wrote:

Hi,

I've uploaded my version to mentors.d.n. I thought it would cause conflict 
since Sebastien already uploaded the same version, but never mind.



Thank you very much!

I did the upload. Let's see what FTP-Master thinks.



Regards,
Herbert
 

Bug#910551: marked as done (RFS: lebiniou/3.25-1 -- displays images that evolve with sound)

[Olivier Girondel]

Oups. Thanks for noticing this !

Best regards,

Bug#911017: RM: dompurify.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

dompurify.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911015: RM: jquery-timer.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

jquery-timer.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911016: ITP: lintian-brush -- automatically fix some lintian issues

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: lintian-brush
  Version : 0.1
  Upstream Author : Jelmer Vernooij 
* URL : https://salsa.debian.org/jelmer/lintian-brush
* License : GPLv2 or later
  Programming Lang: Python
  Description : automatically fix some lintian issues

This tool automatically fixes some common but automatically fixable
lintian issues, adds relevant changelog entries and commits to Git.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#911014: RM: jquery-slugify.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

jquery-slugify.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911011: RM: plupload.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

plupload.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state and is no longer actively maintained.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911012: RM: moxie.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

moxie.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state and is no longer actively maintained.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911013: RM: list.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

list.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state and is no longer actively maintained.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911010: RM: select2.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

select2.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state and is no longer actively maintained.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911009: RM: rebar.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

rebar.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state and is no longer actively maintained.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911008: RM: qtip2.js -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

qtip2.js is no longer needed by any package.

It was initially uploaded to package mailpile, which never reached a
releasable state and is no longer actively maintained.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#910959: grub-cloud-amd64: missing Conflicts: grub-coreboot, grub-efi-ia32, grub-ieee1275, grub-xen

[Bastian Blank]

Hi grub maintainers

On Sat, Oct 13, 2018 at 09:33:26PM +0200, Andreas Beckmann wrote:
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
> 
> etc/kernel/postinst.d/zz-update-grub
> etc/kernel/postrm.d/zz-update-grub

Is there are particular compelling reason why this files needs to be
duplicated in all grub-* packages, instead of residing in
grub(2)-common?  They are not even different from each other.

Given that it seems like this conflict is the only reason why two
variants are not cross-installable.

Bastian

-- 
Well, Jim, I'm not much of an actor either.

Bug#911007: RM: golang-github-btcsuite-btclog -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-github-btcsuite-btclog is no longer needed by any package.

It was initially uploaded to package lnd, which I could never finish due
to the state of the code, full of circular dependencies and vendored code.

Please remove it from the archive.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911006: RM: golang-github-juju-clock -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-github-juju-clock is no longer needed by any package.

It was initially uploaded to package lnd, which I could never finish due
to the state of the code, full of circular dependencies and vendored code.

Please remove it from the archive.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#911005: RM: golang-github-juju-utils-dev -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-github-juju-utils-dev is no longer needed by any package.

It was initially uploaded to package lnd, which I could never finish due
to the state of the code, full of circular dependencies and vendored code.

Please remove it from the archive.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#910966: RFS: 4pane/5.0-2

[Herbert Fortes]

On 10/14/18 11:24 AM, David Hart wrote:

Hi Herbert,


debian/changelog
- is "UNRELEASED".
- a comment: I never saw a changelog going to 'testing'. Like
   version 5.0-1. It is in Sid anyway. But there are less 4 lines
   in that part of the file


I wasn't sure what was right for that field. I've now changed it to 'unstable'.


debian/copyright
-  does not have a 'Files: debian/*". I never saw that either.


I don't think it's needed. As I'm both the packager and upstream, IIUC the
contents of a 'Files: debian/*' entry would just duplicate the overriding
'Files: *'. Please correct me if I'm mistaken.




I understand. I thought the same thing in a first time. And nobody
said anything before. Can not be wrong.

But then I thought the debian dir as a separated part. Not related
to other files.

If no sponsor does the upload the package before me, I will see it.



Regards,
Herbert

Bug#911004: flask-api: Please update Vcs-* fields and migrate to Debian Salsa platform

[Boyuan Yang]

Source: flask-api
Version: 0.6.4+dfsg-1
Severity: normal

Dear flask-api maintainers,

Your package still uses Alioth platform in Vcs-* URLs. Please consider
migrating the packaging repo onto Salsa platform and update those
fields in its next upload.

--
Regards,
Boyuan Yang

Bug#910885: not a bug

[Ximin Luo]

Control: notfound -1 0.7.0-1
Control: close -1

Hi, this is not a bug, it is due to how cargo dependencies work vs how dpkg 
dependencies work, for details see

https://github.com/kpcyrd/cargo-debstatus/issues/2

Furthermore there is also a bug in Britney where some packages might migrate 
too early, for details see

https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-September/002574.html

and the follow-ups.

See also #908364 #908366 #904485.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#911003: flask-api: Please package new upstream version (1.0)

[Boyuan Yang]

Source: flask-api
Version: 0.6.4+dfsg-1
Severity: normal
X-Debbugs-CC: ol...@debian.org z...@debian.org

Dear flask-api maintainers,

Package flask-api saw no upload since its intial upload in 2015. New
its upstream has released flask-api 1.0 in 2017; please consider
packaging the new version.

Thanks!

Regards,
Boyuan Yang

Bug#885137: It's also a dep for rollup-plugin-terser

[Pirate Praveen]

On 2018, ഒക്‌ടോബർ 14 6:04:17 PM IST, Julien Puydt  
wrote:
>Hi,
>
>serialize-javascript is also a dep for rollup-plugin-terser, which is 
>now needed for rollup.
>
>Embedding it in copy-webpack-plugin as it is small will not allow to 
>share it, so perhaps it should still be pushed as a separate package?

The argument pushed by ftp masters is to embed it multiple times if the module 
is small.

>jpuydt on irc.debian.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#911002: RM: golang-github-juju-schema -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-github-juju-schema is no longer needed by any package.

It was initially uploaded to package lnd, which I could never finish due
to the state of the code, full of circular dependencies and vendored code.

Please remove it from the archive.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#910959: grub-cloud-amd64: missing Conflicts: grub-coreboot, grub-efi-ia32, grub-ieee1275, grub-xen

[Bastian Blank]

Control: reassign -1 src:grub,grub-cloud-amd64

Hi Andreas

On Sat, Oct 13, 2018 at 09:33:26PM +0200, Andreas Beckmann wrote:
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.

You forget to actually assign it to both.  Let's fix that first.

Bastian

-- 
"Life and death are seldom logical."
"But attaining a desired goal always is."
-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

Bug#911001: RM: golang-gopkg-macaroon-bakery.v2 -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-gopkg-macaroon-bakery.v2 is no longer needed by any package.

It was initially uploaded to package lnd, which I could never finish due
to the state of the code, full of circular dependencies and vendored code.

Please remove it from the archive.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#910531: Severity

[Sune Vuorela]

severity 910531 normal
thanks

This doesn't make it unusable for everyone, so lowering severity.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#911000: RM: golang-github-zillode-notify -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-github-zillode-notify is no longer needed by any package
and is superseded by golang-github-syncthing-notify.

Please remove it from the archive.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature