Bug#941058: multiline string support

[Trent W. Buck]

Package: elpa-yaml-mode
Version: 0.0.14-1
Severity: wishlist
File: /usr/share/emacs/site-lisp/elpa-src/yaml-mode-0.0.14/yaml-mode.el

In the attached file, yaml-mode indents the multi-line strings incorrectly.
Please fix indentation for multi-line strings.

(At least, ansible complains about the tab stops that yaml-mode suggests.
 I don't know speak yaml fluently, so I may have missed something obvious.)

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages elpa-yaml-mode depends on:
ii  emacsen-common  3.0.4

Versions of packages elpa-yaml-mode recommends:
ii  emacs  1:26.1+1-3.2
ii  emacs-gtk [emacs]  1:26.1+1-3.2

elpa-yaml-mode suggests no packages.

-- no debconf information
# Ref. https://github.com/paluh/ansible-augeas
- hosts: all
  tasks:
- action: augeas commands='ins ForwardAgent before 
"/files/etc/ssh/sshd_config"
   set "/files/etc/ssh/sshd_config/ForwardAgent" 
"yes"'

- action: augeas commands='
ins ForwardAgent before "/files/etc/ssh/sshd_config"
set "/files/etc/ssh/sshd_config/ForwardAgent" "yes"
'

Bug#941057: c-t-b-mipsen tries to build targets which are not configured for this package

[Matthias Klose]

Package: src:cross-toolchain-base-mipsen
Verson: 7
Severity: serious
Tags: sid bullseye

c-t-b-mipsen tries to build targets which are not configured for this package. 
The autopkg test is copied from the cross-toolchain-base package, and doesn't 
build any mips targets.  The purpose of the autopkg test is to find common build 
failures for linux, glibc and gcc updates, not for finding specific target 
issues (building all targets is too much).  So i would just propose dropping the 
test.


Also the test tries to build cross compilers on ppc64el and arm64 where they not 
built by the package.


As a last thing, please merge changes, or propose merges into the c-t-b package 
when working on the package.

Bug#858192: Abdullah Ramann

[Abdullah Ramann]

Salaam,

I am a broker linked with high profile investors from the Gulf who are 
interested and willing to fund your company/individual in any current project 
you are undergoing, they are privately seeking means of expanding their 
investment portfolio. To this end, we seek to know the possibility of going 
into partnership discussion with your company within your present scope of 
business.

Should you be interested in engaging us for a more detailed discussion on the 
proposal, we would be happy to do so in whatever medium you find much more 
appropriate for this engagement.

I look forward to your response.

Yours sincerely,

Abdullah Ramann

Ramann Private Broker LLC
P O Box 43007 Abu Dhabi
United Arab Emirates
Phone: 971-5-280-61378
Fax: 971-4-4256-003

Bug#941019: [Pkg-zfsonlinux-devel] Bug#941019: zfs-initramfs: Mounting natively encrypted ZFS root filesystem doesn't work, when plymouth is enabled

[Richard Laager]

This is:

https://github.com/zfsonlinux/zfs/issues/8306
https://github.com/zfsonlinux/zfs/issues/9193

fixed by:
https://github.com/zfsonlinux/zfs/pull/9202

merged at:
https://github.com/zfsonlinux/zfs/commit/f335b8ff

which should be available in 0.8.2 when it releases.

-- 
Richard

Bug#940662: contextfree FTCBFS: strips with the wrong strip

[John Horigan]

Helmut,

A new version of contextfree with your patch is awaiting the package
sponsor.
It can be viewed at https://mentors.debian.net/package/contextfree
This package also incorporates a new upstream version and updates
debhelper compatibility to v12.

-- john

Bug#939606:

[Marc Bonnor]

I spent the day building kernels ...

Power off working with kernel v5.2-rc5 and not working with v5.2-rc4.

Bug#939777: z8530-utils2 FTCBFS: does not use cross tools

[tony mancill]

tag 939777 +pending
thanks

On Sun, Sep 08, 2019 at 08:02:54PM +0200, Helmut Grohne wrote:
> Source: z8530-utils2
> Version: 3.0-1-9
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs

Hello Helmut,

Thank you for the patch reworking the upstream Makefile.  I will upload
soon; working to address one more bug before uploading...

Cheers,
tony

Bug#941056: qthid-fcd-controller FTCBFS: uses the build architecture qmake

[Helmut Grohne]

Source: qthid-fcd-controller
Version: 4.1-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qthid-fcd-controller fails to cross build from source, because
debian/rules hard codes the build architecture qmake for the v2
subdirectory. The easiest way of fixing that is using dh_auto_configure.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru qthid-fcd-controller-4.1/debian/changelog 
qthid-fcd-controller-4.1/debian/changelog
--- qthid-fcd-controller-4.1/debian/changelog   2019-09-08 01:01:21.0 
+0200
+++ qthid-fcd-controller-4.1/debian/changelog   2019-09-24 06:13:24.0 
+0200
@@ -1,3 +1,10 @@
+qthid-fcd-controller (4.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure use a cross qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 24 Sep 2019 06:13:24 +0200
+
 qthid-fcd-controller (4.1-4) unstable; urgency=medium
 
   * Qt5 port (Closes: #875160) (LP: #1757840)
diff --minimal -Nru qthid-fcd-controller-4.1/debian/rules 
qthid-fcd-controller-4.1/debian/rules
--- qthid-fcd-controller-4.1/debian/rules   2019-09-08 01:01:21.0 
+0200
+++ qthid-fcd-controller-4.1/debian/rules   2019-09-24 06:13:23.0 
+0200
@@ -6,7 +6,8 @@
 
 override_dh_auto_build:
- dh_auto_build
-   (cd v2 && qmake && make)
+   dh_auto_configure --sourcedirectory=v2
+   dh_auto_build --sourcedirectory=v2
 
 override_dh_install: qthid-fcd-controller.udev
dh_install

Bug#941055: dtkwm FTBFS: Project ERROR: set DTK_MODULE_NAME first

[Helmut Grohne]

Source: dtkwm
Version: 2.0.9-3
Severity: serious
Tags: ftbfs

dtkwm fails to build from source in unstable. A build ends with:

|dh_auto_build
|  make -j16
| make[1]: Entering directory '/build/1st/dtkwm-2.0.9'
| cd src/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/build/1st/dtkwm-2.0.9/src/src.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/build/1st/dtkwm-2.0.9=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -pedantic -Wdate-time -D_FORTIFY_SOURCE=2' 
'QMAKE_CFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/build/1st/dtkwm-2.0.9=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/build/1st/dtkwm-2.0.9=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
'QMAKE_CXXFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/build/1st/dtkwm-2.0.9=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' 'QMAKE_LFLAGS_RELEASE=-Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed' 'QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed' 
QMAKE_STRIP=: PREFIX=/usr ) && make -f Makefile
| Project ERROR: set DTK_MODULE_NAME first
| make[1]: *** [Makefile:46: sub-src-make_first-ordered] Error 3
| make[1]: Leaving directory '/build/1st/dtkwm-2.0.9'
| dh_auto_build: make -j16 returned exit code 2
| make: *** [debian/rules:35: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

See for instance 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/dtkwm_2.0.9-3.rbuild.log.gz

Helmut

Bug#941054: ITP: python-bowler -- safe code refactoring for modern Python projects

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

Package name: python-bowler
Version : x.y.z
Upstream Author : © Facebook, John Reese 
URL : https://github.com/facebookincubator/Bowler
License : Expat
Programming Lang: Python
Description : safe code refactoring for modern Python projects

Bowler is a refactoring tool for manipulating Python at the syntax
tree level. It enables safe, large scale code modifications while
guaranteeing that the resulting code compiles and runs. It provides
both a simple command line interface and a fluent API in Python for
generating complex code modifications in code.

Bowler uses a "fluent" Query API to build refactoring scripts through
a series of selectors, filters, and modifiers. Many simple
modifications are already possible using the existing API, but you can
also provide custom selectors, filters, and modifiers as needed to
build more complex or custom refactorings.
--

Bowler is an alternative to Rope.  It's supposed to be quite a bit
better, but I haven't tested it yet.  I believe it has a more active
upstream than Rope.  It may become a dependency for Elpy in the future.

I plan to maintain it as part of the DPMT or PAPT, and I will need a
sponsor for the initial upload.


Regards,
Nicholas

Bug#941036: cacti: CVE-2019-16723

[Salvatore Bonaccorso]

Hi Paul,

On Mon, Sep 23, 2019 at 10:28:31PM +0200, Paul Gevers wrote:
> Hi Salvatore,
> 
> Thanks for your report.
> 
> On 23-09-2019 22:20, Salvatore Bonaccorso wrote:
> > The following vulnerability was published for cacti, filling for
> > tracking the upstream issue. At time of writing, I think there was not
> > a patch upstream yet.
> 
> I think there is:
> https://github.com/Cacti/cacti/commit/7a6a17252a1cbda180b61fff244cb3ce797d5264
> 
> It mentioned the wrong issue, as documented here:
> https://github.com/Cacti/cacti/commit/de3833b0414383efc9e075dd13c95925e2ca504c

"Ack", thank you!

Regards,
Salvatore

Bug#784376: /usr/bin/parse-edid: Re: parse-edid: told me to report this weird EDID

[Witold Baryluk]

Package: read-edid
Version: 3.0.2-1+b1
Followup-For: Bug #784376

Same issue here on my my monitor.

Dumped edid file (from 
/sys/devices/pci:40/:40:03.1/:43:00.0/drm/card0/card0-DP-2/edid ) 
in attachement.

Checksum looks good, but the tool doesn't recognize any mode.



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

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

Versions of packages read-edid depends on:
ii  libc6 2.29-1
ii  libx86-1  1.1+ds1-10.2

read-edid recommends no packages.

read-edid suggests no packages.

-- no debconf information


edid.dat
Description: Binary data

Bug#936483: enki-aseba: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:16:32 + Matthias Klose  wrote:
> Package: src:enki-aseba
> Version: 1:1.6.0-6
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

it looks likes upstream merged a PR to support python 2 and 3 a while
back: https://github.com/enki-community/enki/pull/61 -- Georges, do
you plan to include at least that PR and upload enki-aseba? that would
help quite a lot with the removal of python2

Thanks,
Sandro

Bug#922234: Still ongoing

[Christian Balzer]

Hello,

just wanted to confirm that this is still ongoing and turned a significant
number of my sparse hairs gray in the middle of last night.

This is on a Supermicro SYS-2028TP-DC0FR/X10DRT-PIBF with 
Intel I350 and 82575EB ethernet interfaces and Mellanox ConnectX-3 in case
anybody is taking notes which firmware driver might be the culprit.

I also had to revert to the oldest (4.9.0-4) kernel to get this working and
have to basically consider everything with Stretch backport kernels to be
non-bootable at this point.

would be nice if somebody from the kernel team could pipe up so we can
provide more info if needed.

Regards,

Christian
-- 
Christian BalzerNetwork/Systems Engineer
ch...@gol.com   Rakuten Mobile Inc.

Bug#940983: [Pkg-rust-maintainers] Bug#940983: rust-sha-1: rebuilding results in broken dependencies.

[kpcyrd]

On Sun, Sep 22, 2019 at 11:07:57PM +0100, peter green wrote:
> Package: rust-sha-1
> Version: 0.8.1-2
> Severity: serious
> 
> If rust-sha-1 is re-built, the version mentioned in virtual package names in 
> the provides changes from "0.4" to "0.8", but the version mentioned in the 
> virtual package names in the depends stays at "0.4", thus breaking 
> dependencies between the binary packages.

hey!

I'm having trouble reproducing this, can you provide a specific error,
dpkg -I output or steps to reproduce?

0.8.1 was the only version of sha-1 that was ever uploaded to debian.

Thanks!

Bug#941005: [Pkg-shadow-devel] Bug#941005: shadow uses obsolete SELinux API

[Serge E. Hallyn]

Thanks.  If you feel so inclined, please feel free to file an issue for it
at github.com/shadow-maint/shadow.  I'll aim to fix this in the next week
or two.  (A lot of travel coming up)

On Mon, Sep 23, 2019 at 01:16:10PM +0200, Laurent Bigonville wrote:
> Source: shadow
> Version: 1:4.7-2
> Severity: normal
> User: selinux-de...@lists.alioth.debian.org
> Usertags: selinux
> 
> Hello,
> 
> It seems that the shadow source package is using obsolete SELinux API,
> for example:
> 
> In file included from passwd.c:46:
> /usr/include/selinux/flask.h:5:2: warning: #warning "Please remove any 
> #include's of this header in your source code." [-Wcpp]
>  #warning "Please remove any #include's of this header in your source code."
>   ^~~
> /usr/include/selinux/flask.h:6:2: warning: #warning "Instead, use 
> string_to_security_class() to map the class name to a value." [-Wcpp]
>  #warning "Instead, use string_to_security_class() to map the class name to a 
> value."
>   ^~~
> In file included from passwd.c:47:
> /usr/include/selinux/av_permissions.h:1:2: warning: #warning "Please remove 
> any #include of this header in your source code." [-Wcpp]
>  #warning "Please remove any #include of this header in your source code."
>   ^~~
> /usr/include/selinux/av_permissions.h:2:2: warning: #warning "Instead, use 
> string_to_av_perm() to map the permission name to a value." [-Wcpp]
>  #warning "Instead, use string_to_av_perm() to map the permission name to a 
> value."
> 
> That should be fixed as it could lead to security issues (or at least
> weakened security) for people using SELinux
> 
> Kind regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#941048: fwupd: provide option to never send report

[brian m. carlson]

On 2019-09-24 at 01:00:01, mario.limoncie...@dell.com wrote:
> To accomplish this, I believe you can just comment out ReportURI= in
> the LVFS remote and restart the daemon. (IE
> /etc/fwupd/remotes.d/lvfs.conf)

That doesn't seem to be effective.  Running "fwupdmgr get-updates"
still prompts, even after restarting the daemon.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#941053: gem: switch from libglewmx-dev to libglew-dev

[Paul Wise]

Source: gem
Version: 1:0.94-1
Severity: wishlist

I'd like to remove glewmx from Debian since upstream removed MX support
from GLEW a long time ago and doesn't plan to re-add MX support.

https://github.com/nigels-com/glew/issues/38
https://github.com/nigels-com/glew/releases

Please switch the Build-Depends from libglewmx-dev to libglew-dev.

Upstream may also want to remove the GLEW MX detection & usage.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#941052: UI: add keyboard shortcut E to run `grep-excuses -w $sourcepkgname`

[Paul Wise]

Package: aptitude
Version: 0.8.12-1
Severity: wishlist

When I'm in the aptitude UI looking up a broken dependency, I often
want to refer to the testing migration excuses information. It would be
nice if there was a keyboard shortcut E (similar to C) that would run
`grep-excuses -w $sourcepkgname` and present the output in a new window
(similar to the changelog output from C).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#941051: cryptsetup: luksFormat crash with benbi IV generator and LUKS2 integrity option(s)

[Jerad Simpson]

Package: cryptsetup
Version: 2:2.1.0-5+deb10u2
Severity: normal

Dear Maintainer,

I have been toying around with LUKS2 integrity and have found a situation that
apparently leads to a "Killed" process or a segmentation fault which looks like
it is due to a NULL pointer dereference in my dmesg output.

This lead me to change some of my original luksFormat parameters from using
benbi for IV generation over to plain64be, which does seem to work.  It also
makes me question whether benbi is a good or bad choice to use for a wide block
XTS mode, as I have been using for years.  Any input?  I'm no expert.

In short, this fails:

# cryptsetup luksFormat \
--cipher=twofish-xts-benbi \
--hash=sha512 \
--verify-passphrase \
--key-size=512 \
--use-random \
--type=luks2 \
--pbkdf=argon2id \
--pbkdf-memory=1048576 \
--pbkdf-parallel=4 \
--pbkdf-force-iterations=5 \
--integrity=hmac-sha256 \
--integrity-no-journal \
--sector-size=4096 \
/dev/kvmhost_vg/root

And, this works:

# cryptsetup luksFormat \
--cipher=twofish-xts-plain64be \
--hash=sha512 \
--verify-passphrase \
--key-size=512 \
--use-random \
--type=luks2 \
--pbkdf=argon2id \
--pbkdf-memory=1048576 \
--pbkdf-parallel=4 \
--pbkdf-force-iterations=5 \
--integrity=hmac-sha256 \
--integrity-no-journal \
--sector-size=4096 \
/dev/kvmhost_vg/root

Some more random information, for which feedback is always appreciated:

My rationale for using benbi might have always been way off base.  I have been
known to use pvmove to "defrag" my lvm2 volumes in the past and have always
been worried about this somehow breaking my encryption.  It never has broken
with benbi, and as I understood it, the IV counters would start at 1 and never
be tied directly to any physical harddrive sector.  However, maybe LVM
"sectors," since this occurs before the encryption, is what the IVs have always
been based upon.  Does anybody know if there is any truth in that?  I have not
decided to "defrag" my lvm2 volumes in ages.  In any case, I can live with
plain64 or plain64be, especially if I have been doing it wrong all along!
Mainly, I wanted maintainers to be aware of this crash.

Thank You,

Jerad Simpson



-- Package-specific info:

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

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

Versions of packages cryptsetup depends on:
ii  cryptsetup-initramfs  2:2.1.0-5+deb10u2
ii  cryptsetup-run2:2.1.0-5+deb10u2

cryptsetup recommends no packages.

cryptsetup suggests no packages.

-- no debconf information

Bug#941050: chromium: please remove unused Build-Depends on libglewmx-dev

[Paul Wise]

Source: chromium
Version: 76.0.3809.100-1
Severity: wishlist

Based on the recent build logs for chromium and the Depends of the
binary package, it seems like the Build-Depends on libglewmx-dev is no
longer needed, please remove it.

$ chronic getbuildlog chromium last amd64
$ grep -i glew chromium_76.0.3809.100-1_amd64.log | grep -vE 
'libglewmx-dev|libglewmx1.13'
$ apt-cache show chromium | grep -i glew
$ apt-file show chromium | grep -i glew

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#941048: fwupd: provide option to never send report

[Mario.Limonciello]

To accomplish this, I believe you can just comment out ReportURI= in the LVFS 
remote and restart the daemon. (IE /etc/fwupd/remotes.d/lvfs.conf)

> -Original Message-
> From: brian m. carlson 
> Sent: Monday, September 23, 2019 7:02 PM
> To: Debian Bug Tracking System
> Subject: Bug#941048: fwupd: provide option to never send report
> 
> Package: fwupd
> Version: 1.2.10-2
> Severity: wishlist
> 
> There are a wide variety of situations where a user may never want to send a
> report about successful firmware update.  For example, I've worked at a
> nonprofit dealing with mental health where sending reports to the vendor was
> forbidden as a blanket policy because they might contain sensitive client 
> data.
> Other people are concerned about privacy, and yet others may be on a metered
> or slow connection and wish not to send unneeded data.
> 
> Currently, every time "fwupd get-updates" runs, it prompts to send a report
> about the last update.  This is bothersome for users who never wish to send an
> update.  It would be beneficial if fwupd learned a configuration option to 
> never
> send an update for any reason and to avoid prompting to do so.
> 
> If a configuration option already exists to do this, consider this a request 
> to
> document the behavior or refer to a manual page for the configuration file in
> the fwupdmgr(1) manual page so it can be easily discovered.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-rc5-amd64 (SMP w/8 CPU cores) Kernel taint flags:
> TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libarchive13   3.4.0-1
> ii  libc6  2.29-2
> ii  libefiboot137-2
> ii  libefivar1 37-2
> ii  libelf10.176-1.1
> ii  libfwupd2  1.2.10-2
> ii  libgcab-1.0-0  1.2-5
> ii  libglib2.0-0   2.60.6-2
> ii  libgnutls303.6.9-5
> ii  libgpg-error0  1.36-7
> ii  libgpgme11 1.13.1-1
> ii  libgudev-1.0-0 233-1
> ii  libgusb2   0.3.0-1
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-26
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.64.2-2
> ii  libsqlite3-0   3.29.0-2
> ii  libxmlb1   0.1.8-1+b1
> ii  shared-mime-info   1.10-1
> 
> Versions of packages fwupd recommends:
> ii  bolt   0.8-4
> ii  fwupd-amd64-signed [fwupd-signed]  1.2.10+2
> ii  python33.7.3-1
> ii  tpm2-abrmd 2.1.1-1+b1
> ii  tpm2-tools 3.1.3-2+b1
> 
> fwupd suggests no packages.
> 
> -- no debconf information
> 
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

Bug#941049: lua-luaossl: Newer releases available upstream

[Unit 193]

Package: lua-luaossl
Severity: wishlist

Howdy,

There appears to be quite a few new versions available from upstream's GitHub 
releases[0].
It might be a good idea to update the watch file and upload the latest release.


[0]: https://github.com/wahern/luaossl/releases

~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#938722: tsung: diff for NMU version 1.7.0-3.1

[Sandro Tosi]

Control: tags 938722 + patch
Control: tags 938722 + pending


Dear maintainer,

I've prepared an NMU for tsung (versioned as 1.7.0-3.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru tsung-1.7.0/debian/changelog tsung-1.7.0/debian/changelog
--- tsung-1.7.0/debian/changelog	2017-11-16 00:55:06.0 -0500
+++ tsung-1.7.0/debian/changelog	2019-09-23 20:42:10.0 -0400
@@ -1,3 +1,12 @@
+tsung (1.7.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/tsung-python3.patch.txt
+- support Python3
+  * switch to use Python3, dropping python2 support; Closes: #938722
+
+ -- Sandro Tosi   Mon, 23 Sep 2019 20:42:10 -0400
+
 tsung (1.7.0-3) unstable; urgency=medium
 
   * debian/patches:
diff -Nru tsung-1.7.0/debian/control tsung-1.7.0/debian/control
--- tsung-1.7.0/debian/control	2017-11-14 21:54:06.0 -0500
+++ tsung-1.7.0/debian/control	2019-09-23 20:24:54.0 -0400
@@ -8,7 +8,7 @@
  erlang-dev (>= 1:13.b.1-dfsg-3),
  erlang-nox,
  erlang-src,
- python (>= 2.6.6-3~),
+ python3,
  dh-python,
  python3-sphinx
 Homepage: http://tsung.erlang-projects.org/
@@ -18,10 +18,10 @@
 Architecture: any
 Depends: gnuplot,
  libtemplate-perl,
- python-matplotlib,
+ python3-matplotlib,
  ${erlang:Depends},
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  libjs-jquery,
  libjs-underscore
 Recommends: openssh-client
diff -Nru tsung-1.7.0/debian/patches/series tsung-1.7.0/debian/patches/series
--- tsung-1.7.0/debian/patches/series	2017-11-16 00:44:36.0 -0500
+++ tsung-1.7.0/debian/patches/series	2019-09-23 20:20:10.0 -0400
@@ -1,3 +1,4 @@
 03_correct_lib_path.diff
 02_tsplot_manpage_typo.diff
 01_correct_share_path.diff
+tsung-python3.patch.txt
diff -Nru tsung-1.7.0/debian/patches/tsung-python3.patch.txt tsung-1.7.0/debian/patches/tsung-python3.patch.txt
--- tsung-1.7.0/debian/patches/tsung-python3.patch.txt	1969-12-31 19:00:00.0 -0500
+++ tsung-1.7.0/debian/patches/tsung-python3.patch.txt	2019-09-23 20:37:40.0 -0400
@@ -0,0 +1,125 @@
+# https://github.com/processone/tsung/issues/351#issuecomment-493781199
+
+--- a/src/tsung-plotter/tsplot.py.in
 b/src/tsung-plotter/tsplot.py.in
+@@ -1,4 +1,4 @@
+-#! /usr/bin/env python
++#! /usr/bin/env python3
+ # -*- Mode: python -*-
+ # -*- coding: utf-8 -*-
+ 
+@@ -41,7 +41,7 @@ SYS_STATS_CONF = os.path.join(SHAREDIR,
+ sys.path.append(LIBDIR)
+ 
+ from tsung_plotter.tsung import TsungLog
+-from ConfigParser import ConfigParser
++from configparser import ConfigParser
+ 
+ # Prevents pylab from requiring a X Server to run
+ import matplotlib
+@@ -204,7 +204,7 @@ def main(conffile, logs, legends, outdir
+ stats = [x.strip().rsplit('.', 1)
+  for x in config.get(s, 'stats').split(' ')]
+ except:
+-print 'error: unable to read plot "%s" stats' % s
++print('error: unable to read plot "%s" stats' % s)
+ continue
+ 
+ if config.has_option(s, 'styles'):
+@@ -235,8 +235,8 @@ def main(conffile, logs, legends, outdir
+ try:
+ p.__dict__['yfactor'] = map(float,config.get(s, 'yfactor').decode(encoding).split(','))
+ except ValueError:
+-print 'warning: %s yfactor not a number: %s' \
+-% (p.name, config.get(s, yfactor))
++print('warning: %s yfactor not a number: %s' \
++% (p.name, config.get(s, yfactor)))
+ # Text parameters - to decode into specified encoding
+ for attr in ['title', 'xlabel', 'ylabel', 'plottype', 'yscale']:
+ if config.has_option(s, attr):
+@@ -249,13 +249,13 @@ def main(conffile, logs, legends, outdir
+ try:
+ p.__dict__[attr] = config.getfloat(s, attr)
+ except ValueError:
+-print 'warning: %s %s not a number: %s' \
+-  % (p.name, attr, config.get(s, attr))
++print('warning: %s %s not a number: %s' \
++  % (p.name, attr, config.get(s, attr)))
+ 
+ outfile = p.plot(stats, dataset)
+ 
+ if verbose:
+-print 'Generated plot %s' % outfile
++print('Generated plot %s' % outfile)
+ 
+ if __name__ == "__main__":
+ from optparse import OptionParser
+@@ -280,10 +280,10 @@ if __name__ == "__main__":
+ config = options.config
+ 
+ if options.verbose:
+-print 'Using %s configuration file' % config
++print('Using %s configuration file' % config)
+ 
+ if not os.access(config, os.R_OK):
+-print "can't read configuration file: %s" % config
++print("can't read configuration file: %s" % config)
+ sys.exit(1)
+ 
+ # FIXME: error control
+@@ -295,7 +295,7 @@ if __name__ == "__main__":
+ 
+ # args are legend then file, any times wanted by user
+ if len(args) % 2 != 0:
+-

Bug#939294: [Pkg-utopia-maintainers] Bug#939294: network-manager: After upgrade to 1.20.0-1, mac address of wlan0 is randomized

[Benjamin Barenblat]

Just to add a data point, I’ve experienced the same failure as Jörn. I’m
using ath9k, not iwlwifi, so this may indeed be an implementation
difference between the two drivers. In the meantime, I’ve worked around
the issue by putting

[connection]
wifi.cloned-mac-address=permanent

in /etc/NetworkManager/NetworkManager.conf. This undoes the change in
upstream commit fae5ecec5a4d9987a1915441602cb78275a9f490 [1] and makes
NetworkManager default to using the permanent MAC address when it’s done
scanning.


[1] 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fae5ecec5a4d9987a1915441602cb78275a9f490

Bug#941048: fwupd: provide option to never send report

[brian m. carlson]

Package: fwupd
Version: 1.2.10-2
Severity: wishlist

There are a wide variety of situations where a user may never want to
send a report about successful firmware update.  For example, I've
worked at a nonprofit dealing with mental health where sending reports
to the vendor was forbidden as a blanket policy because they might
contain sensitive client data.  Other people are concerned about
privacy, and yet others may be on a metered or slow connection and wish
not to send unneeded data.

Currently, every time "fwupd get-updates" runs, it prompts to send a
report about the last update.  This is bothersome for users who never
wish to send an update.  It would be beneficial if fwupd learned a
configuration option to never send an update for any reason and to avoid
prompting to do so.

If a configuration option already exists to do this, consider this a
request to document the behavior or refer to a manual page for the
configuration file in the fwupdmgr(1) manual page so it can be easily
discovered.

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

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

Versions of packages fwupd depends on:
ii  libarchive13   3.4.0-1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.2.10-2
ii  libgcab-1.0-0  1.2-5
ii  libglib2.0-0   2.60.6-2
ii  libgnutls303.6.9-5
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.29.0-2
ii  libxmlb1   0.1.8-1+b1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt   0.8-4
ii  fwupd-amd64-signed [fwupd-signed]  1.2.10+2
ii  python33.7.3-1
ii  tpm2-abrmd 2.1.1-1+b1
ii  tpm2-tools 3.1.3-2+b1

fwupd suggests no packages.

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#711135: 2nd CfP: CLOUD COMPUTING 2020 || April 26 - 30, 2020 - Nice, France

[CLOUD COMPUTING 2020]

INVITATION:

=

Please consider to contribute to and/or forward to the appropriate groups the 
following opportunity to submit and publish original scientific results to:

- CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud 
Computing, GRIDs, and Virtualization

The submission deadline is December 13, 2019

Authors of selected papers will be invited to submit extended article versions 
to one of the IARIA Journals: http://www.iariajournals.org

=


== CLOUD COMPUTING 2020 | Call for Papers ===

CALL FOR PAPERS, TUTORIALS, PANELS


CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud Computing, 
GRIDs, and Virtualization

General page: http://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html

Submission page: 
http://www.iaria.org/conferences2020/SubmitCLOUDCOMPUTING20.html


Event schedule: April 26 - 30, 2020 - Nice, France


Contributions:

- regular papers [in the proceedings, digital library]

- short papers (work in progress) [in the proceedings, digital library]

- ideas: two pages [in the proceedings, digital library]

- extended abstracts: two pages [in the proceedings, digital library]

- posters: two pages [in the proceedings, digital library]

- posters:  slide only [slide-deck posted at www.iaria.org]

- presentations: slide only [slide-deck posted at www.iaria.org]

- demos: two pages [posted at www.iaria.org]

- doctoral forum submissions: [in the proceedings, digital library]


Proposals for:

- mini symposia: see http://www.iaria.org/symposium.html

- workshops: see http://www.iaria.org/workshop.html

- tutorials:  [slide-deck posed on www.iaria.org]

- panels: [slide-deck posed on www.iaria.org]


Submission deadline: December 13, 2019


Sponsored by IARIA, www.iaria.org

Extended versions of selected papers will be published in IARIA Journals:  
http://www.iariajournals.org

Print proceedings will be available via Curran Associates, Inc.: 
http://www.proceedings.com/9769.html

Articles will be archived in the free access ThinkMind Digital Library: 
http://www.thinkmind.org


The topics suggested by the conference can be discussed in term of concepts, 
state of the art, research, standards, implementations, running experiments, 
applications, and industrial case studies. Authors are invited to submit 
complete unpublished papers, which are not under review in any other conference 
or journal in the following, but not limited to, topic areas.

All tracks are open to both research and industry contributions, in terms of 
Regular papers, Posters, Work in progress, Technical/marketing/business 
presentations, Demos, Tutorials, and Panels.

Before submission, please check and comply with the editorial rules: 
http://www.iaria.org/editorialrules.html


CLOUD COMPUTING 2020 Topics (for topics and submission details: see CfP on the 
site)

Call for Papers: http://www.iaria.org/conferences2020/CfPCLOUDCOMPUTING20.html



TRENDS: New trends

Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, 
Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing 
and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High 
performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the 
public Clouds; Vehicular Cloud networks; Cloud orchestration features; 
Converged edge systems; Cloud federation; Micro-cloud provider federation; 
Open-implementation Cloud infrastructures; Untrusted Cloud environments; 
Multiple Clouds and data centers; Power Constrained VMs; Cloud Green 
abstraction layer

CLOUD: Cloud computing

Cloud economics; Core cloud services; Cloud technologies; Cloud computing; 
On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS 
applications]; Platform-as-service; Storage as a service in cloud; 
Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing 
programming and application development; Scalability, discovery of services and 
data in Cloud computing infrastructures; Trust and clouds; Client-cloud 
computing challenges; Geographical constraints for deploying clouds

CLOUD: Challenging features

Privacy, security, ownership and reliability issues; Performance and QoS; 
Dynamic resource provisioning; Power-efficiency and Cloud computing; Load 
balancing; Application streaming; Cloud SLAs; Business models and pricing 
policies; Cloud service subscription models; Cloud standardized SLA; 
Cloud-related privacy; Cloud-related control; Managing applications in the 
clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; 
Cloud brokering; Cloud contracts (machine readable); Cloud security; Security 
and assurance properties in cloud environments; Big Data Analytics in clouds; 
Cloud computing back-end solutions; Cloud applications portability; 
Cloud-native application design; Security by design for cloud 

Bug#940930: devscripts: add new script for self-service give-backs

[Paul Wise]

On Mon, 2019-09-23 at 14:16 +0200, Mattia Rizzolo wrote:

> Haven't both chromium and firefox already dropped it?  At least
> chromium did it more than a year ago, but it's quite easy to issue a
> new cert by using openssl manually.

I don't know about Chromium but I can still login to Debian services
using client certificates in Firefox.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#941047: tcp-wrappers: Consider installing libraries into /usr/lib/ instead of /lib/

[Boyuan Yang]

Source: tcp-wrappers
Version: 7.6.q-28
Severity: minor

Dear tcp-wrappers maintainer,

I'm wondering if we could install the libraries into /usr/lib/ instead
of /lib/. Such move seems to suit the target of usrmerge and that it
can be easily implemented in debian/rules file.

Thanks,
Boyuan Yang

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Ian Campbell]

On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> > Hello,
> > 
> > When I looked I elogind a while back I was able to build a package without
> > having a public libelogind0, I basically had that in my debian/rules file:
> > 
> > # We only build the libelogind0 and libelogind-dev if we are building for
> > # Devuan or its derivatives
> > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes)
> > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev
> > endif
> > 
> > libelogind library is only needed for applications that want to interact
> > with the daemon, in the ITP (#905388) bug I also noted that.
> > 
> > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to
> > communicate with the daemon part, was it checked that the API used is
> > compatible? Is there documentation of the differences, if any?
> 
> Yes, the APIs are the same (deliberately so).
> 
> > Bottom line, is libelogind even needed in the archive to achieve your goal
> > of having an implementation of the login1 D-Bus API not requiring systemd as
> > PID1?
> 
> Thanks.
> 
> I think you are correct that the login1 DBus API doesn't require libsystemd0 
> or
> libelogind0. However some packages, notably policykit use the sd-login(3) API
> which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs
> are the same between the two libraries (with the caveats noted in the
> libelogind0 package description) the implementations differ. I have been tolkd
> int he past by elogind upstream that it is not possible for elogind to use
> libsystemd0. For example libsystemd0 requires the concept of slices which
> elogind doesn't have.

Would it be any help at all of the "dbus client-ish" bits and the
"direct API-ish" bits of the two libraries were split up into two
separate libraries? i.e. would that allow the c/r/p replacement of one
of the two libraries (AIUI the API one is the more problematic) to be
pushed further up the dependency stack?

(my impression is no, but I thought I'd ask)

> The only way I have got all of these components to work together on an elogind
> systemd is to ensure everything uses libelogind0.

Has anyone investigated late dynamic binding using a stub library which
merely determines which init is running and then dlopens the
appropriate libsystemd0 of libelogind0 library and forwards the calls
to it?

I don't know if the dynamic linker could be coerced into doing the
selection automagically, in a way similar to how the hwcap stuff can be
used to pickup versions of libraries optimised for different classes of
processor. hwcap is provided by the kernel so I think can't be used
directly, but maybe there is a parallel mechanism somewhere?

Ian.

Bug#941046: bbdb: byte-compilation and startup broken with unversioned emacs

[David Bremner]

Package: bbdb
Version: 2.36-4.1
Severity: serious
Justification: package does not load

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

debian/bbdb.emacsen-install was never updated for unversioned
emacs. This means the package fails to byte compile, which in turn
causes the startup file to bail out.

I'm not 100% sure about the severity. This bug does mean that unless
people write their own startup code (manipulating load-paths and so
on), bbdb is completely useless.


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

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

Versions of packages bbdb depends on:
ii  emacs-gtk [emacsen]  1:26.1+1-4
ii  make 4.2.1-1.2
ii  perl 5.28.1-6

bbdb recommends no packages.

Versions of packages bbdb suggests:
pn  gnus | t-gnus  
pn  gnuserv
ii  perl   5.28.1-6
pn  vm 
pn  w3m-el 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl2JVkAACgkQA0U5G1Wq
FSHHEA/9GKyJ3tO/0HJyU+Tj+y1oYwoLOlbggdeCNgO5IcXUBAC3BH3wx8Y6ebQm
/XuKUAC+xReUc3FL7PjYPTm6evUQP6fCNF8IUqcQBEzzWM4WBeAFcefyyZOHN5on
kSS7oqMTou+GHGdP+xl9gmzP0VJCDerR7dQbOdK9cQNd5aCtcqewFrq42qjpgXnX
Rnnz1CQ8UFYtDVuYBxt2N0YU0I9828ssp8oDkduvjDMANZNCpyVn1qukJ/MnYYij
6jt4Tg86dLw+KljCI7I3mF4GAofRgyK9m8PfYS2cJSjMfZ3PDCHWJnLwWlz8UKcW
t23UjIKf0PWLQA1SjVee+fH+zoFo1tPmRD+gFKxjZE/+eo6CJJgnsviqlj3LUAtX
uGRpbGu26vJbaEg2FBLywN21Q3pDs95K73n8Ajq7dObrSNLF2ug6xnI+7qk+NWo9
YOg2Z27fZebrBBmVJ2DI+ebpOm3mV+Z2V0DiuXzXYTrKn0Ji5tAqs+ffvp6eNww/
L6kIf6CR0rTL6tom31TFJo3L8EITcFsZE4TeiyFXmjUwdkPuSksb3SeVS+DlEsBO
pa3X5/kgx1EVYSq0wCne8UE36+dHeXRT32Gl8T1X80Hc3Z0a6oFBZAd9Cy1tRtBu
IyFb0l6XI8zDEMc4PN32eUnpY2eJxKupjwty4TF1VMgeykz6Auk=
=/02+
-END PGP SIGNATURE-

Bug#941045: selinux-policy-default: system-policy-default causes pam_selinux failure

[Robert Senger]

Package: selinux-policy-default
Version: 2:2.20190201-2
Severity: normal

Dear Maintainer,

In enforcing mode, selinux causes pam_selinux and systemd process user@ to
fail when logging in via ssh.

root@prokyon:~# systemctl status user@1000
● user@1000.service - User Manager for UID 1000
   Loaded: loaded (/lib/systemd/system/user@.service; static; vendor preset:
enabled)
   Active: failed (Result: protocol) since Tue 2019-09-24 01:12:29 CEST; 40s
ago
 Docs: man:user@.service(5)
  Process: 6912 ExecStart=/lib/systemd/systemd --user (code=exited,
status=224/PAM)
 Main PID: 6912 (code=exited, status=224/PAM)

Sep 24 01:12:29 prokyon systemd[1]: Starting User Manager for UID 1000...
Sep 24 01:12:29 prokyon systemd[6912]: pam_selinux(systemd-user:session):
Unable to get valid context for rsenger
Sep 24 01:12:29 prokyon systemd[6912]: pam_selinux(systemd-user:session):
conversation failed
Sep 24 01:12:29 prokyon systemd[6912]: pam_unix(systemd-user:session): session
opened for user rsenger by (uid=0)
Sep 24 01:12:29 prokyon systemd[6912]: PAM failed: Cannot make/remove an entry
for the specified session
Sep 24 01:12:29 prokyon systemd[6912]: user@1000.service: Failed to set up PAM
session: Operation not permitted
Sep 24 01:12:29 prokyon systemd[6912]: user@1000.service: Failed at step PAM
spawning /lib/systemd/systemd: Operation not permitted
Sep 24 01:12:29 prokyon systemd[1]: user@1000.service: Failed with result
'protocol'.
Sep 24 01:12:29 prokyon systemd[1]: Failed to start User Manager for UID 1000.

No other hints in the logs. No AVC logged, neither with or without dontaudit
rules. System is Debian 10 buster.



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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.8-1+b1
ii  libsemanage1 2.8-2
ii  libsepol12.8-1
ii  policycoreutils  2.8-1
ii  selinux-utils2.8-1+b1

Versions of packages selinux-policy-default recommends:
pn  checkpolicy  
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

Bug#940516: valgrind: ONLY uses /usr/lib/$(arch)-linux-gnu/default.supp by default

[Asher Gordon]

Package: valgrind
Version: 1:3.15.0-1
Followup-For: Bug #940516

Hello,

I have updated the patch to include changes to the documentation. Please
see upstream #93376 [1] for the new patch and further updates.

I think there is a good chance that upstream will accept the patch, so
Debian should just wait until (if) that happens. And when (if) they
accept the patch and release version 3.16.0, Debian should also add

  VG_(add_suppression_file)("/usr/local/lib/valgrind");
  VG_(add_suppression_file)("/usr/lib/valgrind");

after

  VG_(add_suppression_file)(VG_(libdir));

in coregrind/m_main.c like I mentioned before.


Asher


[1] https://bugs.kde.org/show_bug.cgi?id=93376

-- 
If at first you don't succeed, redefine success.


signature.asc
Description: PGP signature

Bug#941043: vlc stop playing xsfp files when running inside GNOME+Wayland

[Javier Barroso]

Package: vlc
Version: 3.0.8-2+b1
Severity: normal

Dear Maintainer,

Since many years ago I always use vlc. Last saturday I had a
presentation of photos with xsfp format.

It failed (stopped at random jpg / .mov file), i had to pkill -9 vlc,
About 100 friends that were to view the photos started to sing "Windows
, windows ..." (they was joking :) ), because I was using Debian Sid
(of course) and vlc and then I had to switch to eog to see the photos
as alternative. eog
worked fine.

Today I studied the problem, I can see that vlc works fine on Xorg, but
that it doesn't work fine on wayland. I found the bug on vlc bugtracker [1]

I think vlc should advice about running better on Xorg, until vlc 4 is
released

Thank you
[1] https://trac.videolan.org/vlc/ticket/17829



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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.8-2+b1
ii  vlc-plugin-base  3.0.8-2+b1
ii  vlc-plugin-qt3.0.8-2+b1
ii  vlc-plugin-video-output  3.0.8-2+b1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.8-2
ii  vlc-plugin-notify  3.0.8-2+b1
ii  vlc-plugin-samba   3.0.8-2+b1
ii  vlc-plugin-skins2  3.0.8-2+b1
ii  vlc-plugin-video-splitter  3.0.8-2+b1
ii  vlc-plugin-visualization   3.0.8-2+b1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.29-1
ii  libvlc5  3.0.8-2+b1

Versions of packages libvlc5 depends on:
ii  libc62.29-1
ii  libvlccore9  3.0.8-2+b1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.8-2+b1

Versions of packages vlc-bin depends on:
ii  libc6   2.29-1
ii  libvlc-bin  3.0.8-2+b1
ii  libvlc5 3.0.8-2+b1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libaom0  1.0.0.errata1-2
ii  libarchive13 3.3.3-4
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.1.8-1
ii  libass9  1:0.14.0-2
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.1.4-1+b2
ii  libavformat587:4.1.4-1+b2
ii  libavutil56  7:4.1.4-1+b2
ii  libbasicusageenvironment12018.11.26-1.1+b1
ii  libbluray2   1:1.1.2-2
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libcddb2 1.3.2-6+b1
ii  libchromaprint1  1.4.3-3
ii  libdbus-1-3  1.12.16-1
ii  libdc1394-22 2.2.5-2.1
ii  libdca0  0.0.6-1
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.0.0-1
ii  libdvdread4  6.0.1-1
ii  libebml4v5   1.3.9-2
ii  libfaad2 2.9.0-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libfribidi0  1.0.5-3.1
ii  libgcc1  1:9.2.1-8
ii  libgcrypt20  1.8.5-2
ii  libglib2.0-0 2.60.6-2
ii  libgnutls30  3.6.9-5
ii  libgpg-error01.36-7
ii  libgroupsock82018.11.26-1.1+b1
ii  libharfbuzz0b2.6.1-3
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-9
ii  liblirc-client0  0.10.1-6
ii  liblivemedia64   2018.11.26-1.1+b1
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libmad0  0.15.1b-10
ii  libmatroska6v5   1.5.2-2
ii  libmicrodns0 0.1.0-2
ii  libmpcdec6   2:0.1~r495-1+b2
ii  libmpeg2-4   0.5.1-8+b1
ii  libmpg123-0  1.25.12-1
ii  libmtp9  1.1.16-2
ii  libncursesw6 6.1+20190803-1
ii  libnfs13 4.0.0-1
ii  libogg0  1.3.2-1+b1
ii  libopenmpt-modplug1  0.4.6-1
ii  libopus0 1.3-1+b1
ii  

Bug#941044: elpa-elpy: creating the elpy-doc package

[Salman Mohammadi]

Package: elpa-elpy
Version: 1.31.0-1
Severity: wishlist

Dear Nicholas,

It would be nice if you create the package `elpy-doc` alongside
elpa-elpy to manage html docs separately.

If you want, I can also offer my help, in form of an MR, to reduce the 
time you need to

invest on this matter


Regards,
Salman

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-elpy depends on:
ii dh-elpa-helper 2.0.2
ii elpa-company 0.9.9-2
ii elpa-find-file-in-project 5.7.7-1
ii elpa-highlight-indentation 0.7.0-4
ii elpa-pyvenv 1.20-2
ii elpa-s 1.12.0-3
ii elpa-yasnippet 0.13.0-3
ii emacsen-common 3.0.4
ii flake8 3.7.8-3
ii python3 3.7.3-1
ii python3-flake8 3.7.8-3

Versions of packages elpa-elpy recommends:
ii emacs 1:26.3+1-1
ii emacs-gtk [emacs] 1:26.3+1-1
ii libjs-sphinxdoc 1.8.5-3
ii python3-jedi 0.14.1-1

Versions of packages elpa-elpy suggests:
ii black 19.3b0-1
pn elpa-pip-requirements 
ii python3-autopep8 1.4.4-1
ii python3-jupyter-console 5.2.0-1
ii python3-pip 18.1-5
ii yapf3 0.28.0-1

-- no debconf information

Bug#941042: linux-image-amd64: Stretch-Backport depends on linux-image-4.19.0-0.bpo.6-amd64 which isn't avaiable

[cronoik]

Package: linux-image-amd64
Version: 4.19+105+deb10u1~bpo9+1
Severity: normal

Dear Maintainer,

the package linux-image-amd64 from the stretch-backports depends on 
linux-image-4.19.0-0.bpo.6-amd64 [1] which isn't avaiable via 
stretch-backports. The current available kernel via stretch-backports is 
linux-image-4.19.0-0.bpo.5-amd64 [2].  

[1] https://packages.debian.org/de/stretch-backports/linux-image-amd64
[2] 
https://packages.debian.org/de/stretch-backports/linux-image-4.19.0-0.bpo.5-amd64

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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.19.0-0.bpo.6-amd64

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#791931: Please support ARM64 (arm64 not in arch list, aarch not in config*)

[Simon McVittie]

Control: block 791931 by 456037

On Thu, 09 Jul 2015 at 12:03:46 -0400, Martin Michlmayr wrote:
> This package fails to build on arm64, but a quick looks suggests
> this package might be useful on arm64.

According to #456037, its bytecode interpreter assumes that pointers
can be stored in int without loss of information, which is obviously not
something that can be relied on (although apparently it worked in practice
on amd64 as of 2007-2008).

So the exclusion of arm64 (amd amd64, and s390x, and all other 64-bit
ABIs) from the architecture list is deliberate: it is only built for 32-bit
architectures, where its architectural assumptions are not fatally flawed.

smcv

Bug#925550: grub-efi-amd64-signed: Cannot verify grubx64.efi.signed against "Debian Secure Boot CA"

[Andreas Hunkeler]

Hi

Are there any news regarding the signed binary verification with sbverify? It 
still fails when used with the provided secure boot CA from 
https://dsa.debian.org/secure-boot-ca.

I managed to verify the certificate used to sign the binaries with the 
following commands - but I hope we get a version with sbverify and the root CA 
directly :)

1. Download CA cert from https://dsa.debian.org/secure-boot-ca

2. Convert downloaded CA cert to pem
    openssl x509 -inform der -outform pem -in secure-boot-ca -out debian-ca.pem

3. Extract the signature from the binary
    osslsigncode extract-signature -pem /boot/vmlinuz-... vmlinuz.sig

4. Show the signer cert and use it for verification
    openssl pkcs7 -inform pem -print_certs -text -in vmlinuz.sig

5. Verify the used signing cert against the CA from d.o
    openssl verify -verbose -CAfile debian-ca.pem debian-signer.pem
    debian-signer.pem: OK

I would also add a section to https://wiki.debian.org/SecureBoot or to a 
subpage for how to verify signed secure boot binaries (e.g. a new subpage like 
https://wiki.debian.org/SecureBoot/Verification)

Thanks
Andreas

--
OpenPGP Key AE852913B3757F790297FA2CF04BCF398957A857 @ https://keys.openpgp.org

Bug#940679: pandas: random test crashes

[Rebecca N. Palmer]

There's also a few more of these: 
https://salsa.debian.org/science-team/pandas/commit/c6fc5d5ccbec7ca833ca6d2556ab7013aff4b065


However, the above fix doesn't work: cdef attributes can't have default 
values.

Bug#937216: openvswitch: Python2 removal in sid/bullseye

[Ben Pfaff]

On Sat, Sep 21, 2019 at 09:44:14PM +0200, Thomas Goirand wrote:
> On 9/19/19 4:59 PM, Ben Pfaff wrote:
> > On Fri, Aug 30, 2019 at 07:29:41AM +, Matthias Klose wrote:
> >> Python2 becomes end-of-live upstream, and Debian aims to remove
> >> Python2 from the distribution, as discussed in
> >> https://lists.debian.org/debian-python/2019/07/msg00080.html
> >>
> >> Your package either build-depends, depends on Python2, or uses Python2
> >> in the autopkg tests.  Please stop using Python2, and fix this issue
> >> by one of the following actions.
> > 
> > For what it's worth, we're doing a Python 3-only conversion in the
> > upstream repo at the moment:
> > 
> > https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362813.html
> > 
> > However, the code already supported Python 3 almost everywhere before
> > this, so it's probably not necessary to backport this series for Debian.
> 
> Hi Ben,
> 
> What's hard is more to get rid of python2, like shebangs, etc. If you're
> doing it upstream, that's great, thanks. When do you think that will be
> done, and a new stable release will be done? Can you ping me when that's
> the case?

I think it will be done soon, within a week or two.  It's just a matter
of getting a little bit of review bandwidth from someone.

Our release process calls for the next stable release to branch off of
master on Jan. 15 and to release on Feb. 15.

Are you interested in hearing about the patches being committed or the
release coming out?  If it's just the latter, we have a very
low-bandwidth ovs-announce mailing list that you could subscribe.

Bug#941041: unbound: FTBFS with nettle 3.5.1, accesses ECC curves directly

[Magnus Holmgren]

Package: unbound
Version: 1.9.3-1
Tags: upstream
Severity: serious

_verify_nettle_ecdsa() (in validator/val_secalgo.c) uses the addresses of 
nettle_secp_256r1 and nettle_secp_384r1 directly. As the comment in ecc-
curve.h explains, "Due to ABI subtleties, applications should not refer to 
these directly, but use the below accessor functions." 
(nettle_get_secp_256r1() and nettle_get_secp_384r1().) Indeed, dnsmasq will 
fail to build with nettle 3.5.1, which I'm in the process of getting uploaded 
to unstable (and has been uploaded to experimental).

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#875227: [voxbo] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:12:21PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: voxbo
> Version: 1.8.5~svn1246-2
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

voxbo seems dead upstream and there's a Github fork at
https://github.com/kimberg/voxbo, but it's not ported there either.

Let's remove (for now)? Or does anyone intend to port it?

Cheers,
Moritz

Bug#874834: [Help] [avogadro] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sun, Sep 08, 2019 at 10:32:40PM +0200, Moritz Mühlenhoff wrote:
> On Wed, Dec 13, 2017 at 02:54:07PM +0100, Andreas Tille wrote:
> > control: tags -1 help
> > 
> > Hi,
> > 
> > I've moved avogadro packaging from SVN to Git.  I also had a look into
> > the Qt5 migration.  The Git repository[1] contains a branch qt5.  I
> > tried my best to adapt cmake to finalise the configuration step.
> 
> https://github.com/cryos/avogadro/issues/891 was tagged wontfix,
> so let's remove it from the archive? We're closing in on the Qt4 removal
> now.
> 
> It mentions an avogadro2, that can still be uploaded before bullseye
> release when ready.

I've now filed a removal bug.

Cheers,
Moritz

Bug#941040: RM: avogadro -- RoQA; Depends on qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove avogadro. It depends on Qt4 which is being removed (and Py2).
Upstream won't port it to Qt5.

Cheers,
Moritz

Bug#940859: [debian-mysql] Bug#940859: mariadb-server-10.3: keeps crashing a few seconds after start

[Dr. Axel Stammler]

Thank you for your quick reply.

The first crash happened surprisingly at a restart. The messages gave no details
whatsoever, only “segfault”.

Changing configuration setting made no difference.

After a while, the crashes started to happen a few minutes or even hours after 
a restart
so that I was able to dump most databases. The crashes kept happening 
unpredictably.

Reinstallation made no difference, even if all database and configuration files 
were
removed.

I then purged all Maria DB packages (and Kopano) and tested the harddisks and 
filesystems.
No errors were found.

I reinstalled the Maria DB server, re-created the users and databases and 
restored the
databases from the dumps. No further crashes have happened.

Thanks again.

- Axel


signature.asc
Description: PGP signature

Bug#914044: closed by Jonathan Carter (Fixed in tuxpaint 1:0.9.23-1)

[Helmut Grohne]

Control: reopen -1

On Mon, Sep 23, 2019 at 12:54:07PM +, Debian Bug Tracking System wrote:
> Subject: Fixed in tuxpaint 1:0.9.23-1

No, this is certainly not fixed in 1:0.9.23-1 as that's the version I
reported the bug.

Helmut

Bug#941034: fixed in libffado 2.4.2-1

[Yoann LE BARS]

Hello everybody out there!

On Mon, 23 Sep 2019 20:40:01 + Sebastian Ramacher
 wrote:
> We believe that the bug you reported is fixed in the latest version of
> libffado, which is due to be installed in the Debian FTP archive.
Indeed, version 2.4.2 is a bug fix. Among the bugs addressed in this
version, there is the bug I have reported.

Best regards.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Bug#940817: transition: liblouis

[Samuel Thibault]

Paul Gevers, le lun. 23 sept. 2019 21:51:06 +0200, a ecrit:
> On 21-09-2019 00:20, Samuel Thibault wrote:
> > Samuel Thibault, le ven. 20 sept. 2019 10:30:36 +0200, a ecrit:
> >> The new liblouis release (3.11.0) changed its ABI. I have checked
> >> the rdeps, they build and run fine, except liblouisutdml, which uses
> >> internal functions of liblouis. I have uploaded to experimental the new
> >> upstream release of liblouisutdml (2.8.0) which fixes compatibility with
> >> liblouis, it has no rdeps.
> > 
> > I forgot to mention that the new liblouisutdml doesn't build with the
> > old liblouis. That's why they have to go together, I can't upload
> > liblouisutdml to unstable yet.
> 
> Please go ahead.

They are now in.

Samuel

Bug#811180: Port bzr part to breezy

[Jelmer Vernooij]

This patch ports the Bazaar plugin to Breezy (which supports python 3)
and updates the dependencies accordingly.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc
diff -uNr etckeeper-1.18.10/debian/control etckeeper-1.18.10-brz/debian/control
--- etckeeper-1.18.10/debian/control	2019-01-16 18:51:37.0 +
+++ etckeeper-1.18.10-brz/debian/control	2019-09-23 20:37:45.897443278 +
@@ -3,7 +3,7 @@
 Priority: optional
 Build-Depends: debhelper-compat (= 11),
bats,
-   bzr (>= 1.5~),
+   brz,
dh-python,
dpkg-dev (>= 1.9.0),
fakeroot,
@@ -17,15 +17,14 @@
 
 Package: etckeeper
 Architecture: all
-Depends: git (>= 1:1.7) | mercurial | bzr (>= 1.5~) | darcs,
+Depends: git (>= 1:1.7) | mercurial | brz | darcs,
  ${misc:Depends},
  ${python:Depends},
 Recommends: cron-daemon
 Suggests: sudo (>= 1.7.4p4)
-Conflicts: bzr (<< 1.5~)
-Description: store /etc in git, mercurial, bzr or darcs
+Description: store /etc in git, mercurial, bazaar or darcs
  The etckeeper program is a tool to let /etc be stored in a git, mercurial,
- bzr or darcs repository. It hooks into APT to automatically commit changes
+ bazaar or darcs repository. It hooks into APT to automatically commit changes
  made to /etc during package upgrades. It tracks file metadata that version
  control systems do not normally support, but that is important for /etc, such
  as the permissions of /etc/shadow. It's quite modular and configurable, while
diff -uNr etckeeper-1.18.10/etckeeper-brz/__init__.py etckeeper-1.18.10-brz/etckeeper-brz/__init__.py
--- etckeeper-1.18.10/etckeeper-brz/__init__.py	1970-01-01 00:00:00.0 +
+++ etckeeper-1.18.10-brz/etckeeper-brz/__init__.py	2019-09-23 20:36:36.461049484 +
@@ -0,0 +1,31 @@
+#
+# Bazaar plugin that runs etckeeper pre-commit when necessary
+
+"""Runs etckeeper pre-commit when necessary."""
+
+from breezy.errors import BzrError
+from breezy.hooks import install_lazy_named_hook
+import os
+
+
+def etckeeper_startcommit_hook(tree):
+abspath = getattr(tree, "abspath", None)
+if abspath is None or not os.path.exists(abspath(".etckeeper")):
+# Only run the commit hook when this is an etckeeper branch
+return
+import subprocess
+ret = subprocess.call(["etckeeper", "pre-commit", abspath(".")])
+if ret != 0:
+raise BzrError("etckeeper pre-commit failed")
+
+
+install_lazy_named_hook(
+"breezy.mutabletree", "MutableTree.hooks",
+'start_commit', etckeeper_startcommit_hook, 'etckeeper')
+
+
+if __name__ == "__main__":
+from distutils.core import setup
+setup(name="brz-etckeeper", 
+  packages=["breezy.plugins.etckeeper"],
+  package_dir={"breezy.plugins.etckeeper":"etckeeper-brz"})
diff -uNr etckeeper-1.18.10/etckeeper-bzr/__init__.py etckeeper-1.18.10-brz/etckeeper-bzr/__init__.py
--- etckeeper-1.18.10/etckeeper-bzr/__init__.py	2018-12-23 17:06:45.0 +
+++ etckeeper-1.18.10-brz/etckeeper-bzr/__init__.py	1970-01-01 00:00:00.0 +
@@ -1,34 +0,0 @@
-#
-# Bazaar plugin that runs etckeeper pre-commit when necessary
-
-"""Runs etckeeper pre-commit when necessary."""
-
-from bzrlib.errors import BzrError
-import os
-
-def etckeeper_startcommit_hook(tree):
-abspath = getattr(tree, "abspath", None)
-if abspath is None or not os.path.exists(abspath(".etckeeper")):
-# Only run the commit hook when this is an etckeeper branch
-return
-import subprocess
-ret = subprocess.call(["etckeeper", "pre-commit", abspath(".")])
-if ret != 0:
-raise BzrError("etckeeper pre-commit failed")
-
-try:
-from bzrlib.hooks import install_lazy_named_hook
-except ImportError:
-from bzrlib.mutabletree import MutableTree
-MutableTree.hooks.install_named_hook('start_commit',
-etckeeper_startcommit_hook, 'etckeeper')
-else:
-install_lazy_named_hook(
-"bzrlib.mutabletree", "MutableTree.hooks",
-'start_commit', etckeeper_startcommit_hook, 'etckeeper')
-
-if __name__ == "__main__":
-from distutils.core import setup
-setup(name="bzr-etckeeper", 
-  packages=["bzrlib.plugins.etckeeper"],
-  package_dir={"bzrlib.plugins.etckeeper":"etckeeper-bzr"})
diff -uNr etckeeper-1.18.10/Makefile etckeeper-1.18.10-brz/Makefile
--- etckeeper-1.18.10/Makefile	2018-12-23 17:06:45.0 +
+++ etckeeper-1.18.10-brz/Makefile	2019-09-23 20:37:04.809210271 +
@@ -20,7 +20,7 @@
 TESTDIR := $(shell mktemp -u -d)
 
 build: etckeeper.spec etckeeper.version
-	-$(PYTHON) ./etckeeper-bzr/__init__.py build || echo "** bzr support not built"
+	-$(PYTHON) ./etckeeper-brz/__init__.py build || echo "** brz support not built"
 	-$(PYTHON) ./etckeeper-dnf/etckeeper.py build || echo "** DNF support not built"
 
 install: etckeeper.version
@@ -65,7 +65,7 @@
 	mkdir -p $(DESTDIR)$(prefix)/lib/zypp/plugins/commit
 	$(INSTALL) zypper-etckeeper.py 

Bug#934204: radare2: CVE-2019-14745

[Salvatore Bonaccorso]

Hi,

On Thu, Aug 08, 2019 at 09:22:44AM +0200, Salvatore Bonaccorso wrote:
> Source: radare2
> Version: 3.2.1+dfsg-5
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/radare/radare2/pull/14690
> 
> Hi,
> 
> The following vulnerability was published for radare2.
> 
> CVE-2019-14745[0]:
> | In radare2 before 3.7.0, a command injection vulnerability exists in
> | bin_symbols() in libr/core/cbin.c. By using a crafted executable file,
> | it's possible to execute arbitrary shell commands with the permissions
> | of the victim. This vulnerability is due to improper handling of
> | symbol names embedded in executables.

FTR, not only the initial commit but two more are needed to adress
this issue:

https://github.com/radareorg/radare2/commit/5411543a310a470b1257fb93273cdd6e8dfcb3af

and 

https://github.com/radareorg/radare2/commit/dd739f5a45b3af3d1f65f00fe19af1dbfec7aea7

are as well needed (otherwise radare2 will be affected by
CVE-2019-16718.

Regards,
Salvatore

Bug#941036: cacti: CVE-2019-16723

[Paul Gevers]

Hi Salvatore,

Thanks for your report.

On 23-09-2019 22:20, Salvatore Bonaccorso wrote:
> The following vulnerability was published for cacti, filling for
> tracking the upstream issue. At time of writing, I think there was not
> a patch upstream yet.

I think there is:
https://github.com/Cacti/cacti/commit/7a6a17252a1cbda180b61fff244cb3ce797d5264

It mentioned the wrong issue, as documented here:
https://github.com/Cacti/cacti/commit/de3833b0414383efc9e075dd13c95925e2ca504c

Paul



signature.asc
Description: OpenPGP digital signature

Bug#941038: sane: /lib/udev/rules.d/60-libsane.rules seems incomplete

[Guenter Zoechbauer]

Package: sane
Version: 1.0.14-13+b1
Severity: important



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

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

Versions of packages sane depends on:
ii  libc6 2.28-10
ii  libgimp2.02.10.8-2
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libgtk2.0-0   2.24.32-3
ii  libsane   1.0.27-3.2

sane recommends no packages.

Versions of packages sane suggests:
pn  gimp  

-- no debconf information



getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/009
# owner: root
# group: root
user::rw-
user:zoechi:rw-
group::rw-
mask::rw-
other::r--

When I copy the content of 
https://gemfury.com/malept/deb:libsane/-/content/lib/udev/rules.d/60-libsane.rules
 to /etc/udev/rules.d/60-libsane.rules
the output is

getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/010
# owner: root
# group: root
user::rw-
user:zoechi:rw-
group::rw-
group:scanner:rw-
mask::rw-
other::r--
 
which contains "scanner" as required.

Bug#941039: ITP: ciao-prolog -- Ciao logic programming language and development system

[Salvador Abreu]

Package: wnpp
Severity: wishlist
Owner: Salvador Abreu 

* Package name    : ciao-prolog
  Version : 1.18.0
  Upstream Author : Ciao support 
* URL : http://www.ciao-lang.org/
* License : LGPL
  Programming Lang: C, Prolog
  Description : Ciao logic programming language and development system

Ciao is an open source project developed by the Ciao team and many
contributors. The core Ciao system is provided under the GNU LGPL license.

Ciao is in very active and continuous development since the early 90's by an
international team, coordinated by CLIP group members at UPM and the IMDEA
Software Institute.

Ciao builds on its predecessor, &-Prolog, developed between 1984 and the mid
90's at the University of Texas at Austin, USA, the Microelectronics and
Technology Corporation, and UPM.

Bug#941037: sopt cross misbuilds: build/host confusion

[Helmut Grohne]

Source: sopt
Version: 3.0.1-2
Tags: patch

When cross building sopt, it successfully cross builds a broken binary
package, because it confuses build and host. Please refer to man
dpkg-architecture for a definition of these terms. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru sopt-3.0.1/debian/changelog sopt-3.0.1/debian/changelog
--- sopt-3.0.1/debian/changelog 2019-09-20 11:30:50.0 +0200
+++ sopt-3.0.1/debian/changelog 2019-09-23 22:20:31.0 +0200
@@ -1,3 +1,10 @@
+sopt (3.0.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build/host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 23 Sep 2019 22:20:31 +0200
+
 sopt (3.0.1-2) unstable; urgency=low
 
   * Switch to unstable to start transition
diff --minimal -Nru sopt-3.0.1/debian/patches/Multiarch-patch.patch 
sopt-3.0.1/debian/patches/Multiarch-patch.patch
--- sopt-3.0.1/debian/patches/Multiarch-patch.patch 2019-09-20 
11:30:23.0 +0200
+++ sopt-3.0.1/debian/patches/Multiarch-patch.patch 2019-09-23 
22:20:05.0 +0200
@@ -16,7 +16,7 @@
DESTINATION share/cmake/sopt
 -  LIBRARY DESTINATION lib
 -  ARCHIVE DESTINATION lib
-+  LIBRARY DESTINATION lib/${DEB_BUILD_MULTIARCH}
-+  ARCHIVE DESTINATION lib/${DEB_BUILD_MULTIARCH}
++  LIBRARY DESTINATION lib/${DEB_HOST_MULTIARCH}
++  ARCHIVE DESTINATION lib/${DEB_HOST_MULTIARCH}
INCLUDES DESTINATION include
)
diff --minimal -Nru sopt-3.0.1/debian/rules sopt-3.0.1/debian/rules
--- sopt-3.0.1/debian/rules 2019-02-02 10:43:36.0 +0100
+++ sopt-3.0.1/debian/rules 2019-09-23 22:20:29.0 +0200
@@ -4,7 +4,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-CMAKE_FLAGS += -DDEB_BUILD_MULTIARCH=`dpkg-architecture -qDEB_BUILD_MULTIARCH`
+CMAKE_FLAGS += -DDEB_HOST_MULTIARCH=`dpkg-architecture -qDEB_HOST_MULTIARCH`
 
 %:
dh $@ --buildsystem=cmake

Bug#941036: cacti: CVE-2019-16723

[Salvatore Bonaccorso]

Source: cacti
Version: 1.2.6+ds1-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/Cacti/cacti/issues/2964

Hi,

The following vulnerability was published for cacti, filling for
tracking the upstream issue. At time of writing, I think there was not
a patch upstream yet.

CVE-2019-16723[0]:
| In Cacti through 1.2.6, authenticated users may bypass authorization
| checks (for viewing a graph) via a direct graph_json.php request with
| a modified local_graph_id parameter.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16723
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16723
[1] https://github.com/Cacti/cacti/issues/2964

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Mark" == Mark Hindley  writes:

Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
>> Foo-package depends on the latest libsystemd0.  I'm running
>> unstable or testing.  The latest libsystemd0 isn't building on my
>> arch yet.  But elogind is simpler and has build fine on my arch.
>> I install foo-package and suddenly end up with libelogind0
>> instead of libsystemd0
>> 
>> This is probably a problem.  Libsystemd0 and libelogind0 probably
>> behave differently and you probably do care which one you have.
>> The specific problems depend on what init system I have, on
>> whether I have elogind running or systemd-logind, etc.  But it's
>> probably not a good situation.

Mark> I believe we have guarded against exactly this already because
Mark> libelogind0 conflicts with systemd, so you couldn't change
Mark> from libsystemd0 to libelogind0 on a systemd install without
Mark> removing the running systemd (which won't happen).

Well, we've guaranteed that you won't succeed.
With the apt fix, we've guaranteed  that the dependency order will be
respected for removal.

But I think it's still possible to get an incredible mess of your
systemd.
There's no guarantee that systemd removal will happen early in the
process.


Mark> Anyway, I am happy to try to work up a dpkg-divert solution if
Mark> that is likely to be more acceptable.

I don't know if it will be.
I'm trying to be a facilitator here and make sure all sides understand
each other.

So, the advantage of the dpkg-divert approach seems to me to be that if
you never turn it on, it can't hurt you.
So, for example, if you do more than install a package to trigger it, it
could be very safe for the systemd user.

Even if you trigger from the elogind postinst, that's probably OK so
long as very little hard depends on elogind.

The disadvantages are:

1) Making sure you never get into a situation where you try to boot
systemd with libelogind0.  Assuming you can dpkg-divert a symlink, you
can presumably manage the /sbin/init link, but you cannot stop someone
from init=/bin/systemd with libelogind0 as libsystemd0.  Although
systemd doesn't actually link to libsystemd0, so perhaps that's not
quite as bad as I thought, although I'm sure it isn't good..  (You may
not need to stop this: it's a disadvantage, and sometimes the chosen
solution has disadvantages).

2) There was FUD about dpkg-divert being inappropriate for critical
system functions.  I don't know whether this is still true or how big of
a deal it is.  But for example if things are in an inconsistent state on
upgrade between unpack phase and configure phase, that might be a
disadvantage.  Basically, I think it's probably fine if the initial
diversion has some fragility (where if your system crashes at that one
point, recovery is hard).  I think it's less amazing if every time you
upgrade systemd, elogind or similar, there is fragility.


Really at this point we need someone who is not you or I to speak up.

Bug#941035: xdaliclock FTCBFS: uses AC_TRY_RUN

[Helmut Grohne]

Source: xdaliclock
Version: 2.44+debian-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xdaliclock fails to cross build from source, because X11/configure.in
uses AC_TRY_RUN to verify that the compiler works. For cross
compilation, it should be assumed working. Please consider applying the
attached patch.

Helmut
--- xdaliclock-2.44+debian.orig/X11/configure.in
+++ xdaliclock-2.44+debian/X11/configure.in
@@ -59,7 +59,7 @@
  AC_MSG_RESULT(yes),
  AC_MSG_RESULT(no)
  AC_MSG_ERROR(Couldn't build even a trivial ANSI C program: check CC.),
- AC_MSG_ERROR(Couldn't build even a trivial ANSI C program: check CC.))
+ AC_MSG_RESULT(cross compiling... asssuming yes))
 
   if test -n "$GCC"; then
 AC_MSG_RESULT(Turning on gcc compiler warnings.)

Bug#941034: Patch

[Yoann LE BARS]

Hello everybody out there!

Attached to this message, the patch that fixes the bug.

Best regards.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

--- import_pyqt.py  (revision 2773)
+++ import_pyqt.py  (revision 2774)
@@ -20,27 +20,35 @@
 # along with this program.  If not, see .
 #
 
-ffado_pyqt_version = 4
-
-# This module handles the importing of PyQt modules for both PyQt4 and PyQt5.
-# The idea is to first try importing PyQt4.  If there's an import error it's
-# assumed PyQt5 is present instead and that is tried.
+# This module handles the importing of PyQt modules for both PyQt4 and PyQt5
+# under Python2 or Python3.  If Python3 is installed it is assumed that
+# PyQt5 is in use (this is reasonable because PyQt5 is what everyone wants
+# to use under Python3).  Otherwise (that is, under Python2), an import of
+# PyQt4 is tried first; if an import error occurs then PyQt5 is assumed.
 #
 # All modules used by any part of ffado-mixer are imported.  This greatly
 # simplifies the process.  Otherwise the modules to import would be delivered
 # by string variables, and there isn't a supported way to do this across 
 # Python2 and Python3.
-try:
+
+import sys
+ffado_python3 = sys.version_info >= (3,)
+
+if ffado_python3:
+ffado_pyqt_version = 5
+else:
+try:
+from PyQt4 import QtGui
+ffado_pyqt_version = 4
+except ImportError:
+ffado_pyqt_version = 5
+
+if ffado_pyqt_version == 4:
 from PyQt4 import QtGui, QtCore, Qt, uic
 from PyQt4.QtCore import QByteArray, QObject, QTimer, Qt, pyqtSignal, 
QString, pyqtSlot
 from PyQt4.QtGui import *
-ffado_pyqt_version = 4
-except ImportError:
+else:
 from PyQt5 import QtGui, Qt, QtCore, Qt, QtWidgets, uic
 from PyQt5.QtCore import QByteArray, QObject, pyqtSignal, pyqtSlot, 
QTimer, Qt
 from PyQt5.QtGui import *
 from PyQt5.QtWidgets import *
-ffado_pyqt_version = 5
-
-import sys
-ffado_python3 = sys.version_info >= (3,)

Bug#934627: transition: libmatio

[Paul Gevers]

Control: tags -1 confirmed

On 12-08-2019 17:24, Sébastien Villemot wrote:
> Please schedule a transition for libmatio. The new version stands in
> experimental. I expect the transition to be smooth (only two symbols
> deprecated, and those are not used by reverse dependencies according to
> sources.debian.org).

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

On Mon, Sep 23, 2019 at 03:34:50PM -0400, Sam Hartman wrote:
> Hi.
> I've looked a bit at the systemd code as compared to the elogind code.
> 
> One of the major reasons that libsystemd0 cannot be used as a
> replacement for libelogind0 is that elogind does not have compatible
> cgroup naming.
> The systemd (and elogind) libraries  do some operations over dbus.
> But other operations are done directly.  For example to look and see
> what session a pid is in, the library will look at the cgroups of the
> pid.
> Similarly to see whether a particular pid belongs to a uid, it looks at
> the cgroup naming.
> 
> If you take a look at src/basic/cgroup-util.c in the elogind sources and
> take a look at what is #if 0'd you can see the naming differences.

Yes. systemd uses user units and scopes. elogind can not support either and uses
internal hash containers.  So if a system is running elogind and polkit asks
libsystemd0 for a session id to a pid, it will search for a session-.scope
and find nothing.

See the two implementations of  cg_path_get_session():

 https://github.com/elogind/elogind/blob/d4a3f29/src/basic/cgroup-util.c#L1713

Mark

Bug#931551: transition: llvm-defaults to 8

[Paul Gevers]

Hi Shengjing, Sylvestre,

On 15-09-2019 09:52, Shengjing Zhu wrote:
>> Now that we release buster, I would like to move llvm-defaults to 
>> llvm-toolchain-8.

[...]

>> Affected: .depends ~ /(clang|llvm)1?-?[345678]/
>> Good: .depends ~ /(clang|llvm)1?-?[8]/
>> Bad: .depends ~ /(clang|llvm)1?-?[34567]/
>>
> 
> I recently package ccls, which depends on libllvm[1].
> I'm curious why this ben file doesn't include libllvm?

So am I, Sylvestre, can you comment please. Is this intentional, or just
missing from the ben file?

> And should I rebuild ccls manually? Or it will be handled by RT.
> I don't see ccls is on [2].

I think this has solved itself via uploads of ccls, right?

Paul

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
> Foo-package depends on the latest libsystemd0.  I'm running unstable or
> testing.  The latest libsystemd0 isn't building on my arch yet.  But
> elogind is simpler and has build fine on my arch.  I install foo-package
> and suddenly end up with libelogind0 instead of libsystemd0
> 
> This is probably a problem.
> Libsystemd0 and libelogind0 probably behave differently and you probably
> do care which one you have.
> The specific problems depend on what init system I have, on whether I
> have elogind running or systemd-logind, etc.
> But it's probably not a good situation.

I believe we have guarded against exactly this already because libelogind0
conflicts with systemd, so you couldn't change from libsystemd0 to libelogind0
on a systemd install without removing the running systemd (which won't happen).

> The concern is there might be other cases where the dependency resolver
> gives you an answer that is inappropriate for your environment.  We're
> not sure we have confidence we can enumerate and think about all these
> situations.

I agree we can't envisage all cases, but that is what testing is for.

Anyway, I am happy to try to work up a dpkg-divert solution if that is likely to
be more acceptable.

Thanks.

Mark

Bug#940817: transition: liblouis

[Paul Gevers]

Control: tags -1 confirmed

On 21-09-2019 00:20, Samuel Thibault wrote:
> Samuel Thibault, le ven. 20 sept. 2019 10:30:36 +0200, a ecrit:
>> The new liblouis release (3.11.0) changed its ABI. I have checked
>> the rdeps, they build and run fine, except liblouisutdml, which uses
>> internal functions of liblouis. I have uploaded to experimental the new
>> upstream release of liblouisutdml (2.8.0) which fixes compatibility with
>> liblouis, it has no rdeps.
> 
> I forgot to mention that the new liblouisutdml doesn't build with the
> old liblouis. That's why they have to go together, I can't upload
> liblouisutdml to unstable yet.

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#932817: Quotation request

[Carlson Dental Group]

The Sales Department,
  Please provide us with quotation for HP Laser Toner Cartridges listed below: 
 (6) HP 651A Black Original LaserJet Toner Cartridge, CE340A 
(6) HP 651A Cyan Original LaserJet Toner Cartridge, CE341A 
(6) HP 651A Yellow Original LaserJet Toner Cartridge, CE342A
(6) HP 651A Magenta Original LaserJet Toner Cartridge, CE343A
 All quoted items must be HP OEM Cartridges. If you have any question please 
email me on i...@carlsondentalgroups.com
 Thank you.
 David Cambel
Carlson Dental Group
13241 Bartram Park Blvd #1700
Jacksonville, FL 32258
Tel: 904 289 1509
www.carlsondentalgroup.com

Bug#940996: lightdm: when resuming from ram, user desktop appears for 1sec before getting prompted for a password

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2019-09-23 at 21:23 +0200, Damien Pous wrote:
> > You can vt-switch to VT7 to check for yourself, but I'd assume it *is* 
> > locked
> > (please report otherwise).
> If I switch to VT7 once the ligthdm login screen has appeared, I get
> to see my screen before suspend (desktop with the open applications,
> and thus potentially sensitive data, but everything frozen).
> I see it for 10 seconds, during which touchpad and keyboard are not
> responsive ; then the lightdm login screen appears again.
> I can repeat the process: if I do not login, I can still switch again
> to VT7 and see my frozen desktop for 10 more seconds... pretty bad...
> although not as bad as having the session wide open, I agree.

That's weird, I don't think I ever had that behavior. In all cases I remember
I have the behavior you describe below with the “you'll be redirected”
message.

> > Please also try the “late lock” settings and see if that makes a difference.
> Where/how can I play with this setting?

Light locker configuration is stored in gsettings, so try with dcond-editor in
/apps/light-locker. There's also a GUI tool at 
https://github.com/Antergos/light-locker-settings (not packaged in Debian).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2JH/gACgkQ3rYcyPpX
RFs/BQf/bdbOo7GJaFg2wPrjFW9EK12hnUL/5FS1NHranPqOk14zms7btBtYcr1D
qqfnHgE0KVcmECqb4XMoJGSXXSXHC6acHQQZ3UiVMkLFuQDvsNoKw3D3uJtr+agp
YGcDJHX29FrGLQBz02657HENHaRrCCHocYpQi/6eydEX4PW+Qi1D+6Fa024J/ixB
F6UZp7Dmw6an6xYzga3KwELRoTE7ZNfb7CmUFYuQuBQWRvdkOX6YbVAsVTWjWI4Q
ItgTd8ygQpDt+JtWG5Lh3r+bBzmTD7rL4Sd1l/KKc1jr/j/4hNvBJk21sytWWmx7
qnJOtBBTwtYfl6yJaksUecv/gwkpRQ==
=Ep0k
-END PGP SIGNATURE-

Bug#940996: lightdm: when resuming from ram, user desktop appears for 1sec before getting prompted for a password

[Damien Pous]

> You can vt-switch to VT7 to check for yourself, but I'd assume it *is* locked
> (please report otherwise).
If I switch to VT7 once the ligthdm login screen has appeared, I get
to see my screen before suspend (desktop with the open applications,
and thus potentially sensitive data, but everything frozen).
I see it for 10 seconds, during which touchpad and keyboard are not
responsive ; then the lightdm login screen appears again.
I can repeat the process: if I do not login, I can still switch again
to VT7 and see my frozen desktop for 10 more seconds... pretty bad...
although not as bad as having the session wide open, I agree.

> Please also try the “late lock” settings and see if that makes a difference.
Where/how can I play with this setting?


I did some other experiments:
- if I do [xfce4-session-logout -u] so that I get the login screen,
then switch to VT7, I see my desktop for a very brief amount of time
(much less than the second from my initial bug-report, but still, I
could imagine taking a picture of it), then I see white text on a
black background saying (in french) "this session is locked, you'll be
redirected in a moment", and I get the login screen after 10secs. If I
try again to switch to VT7 I get the white text directly (without
first seeing my desktop anymore)

- if I do [ligth-locker-command -l] then I get a black screen and I
need to switch to VT1 and then to VT8 to get the login screen. If I
switch to VT7 I get the white text on black background without seeing
my desktop. (That I need to switch first to VT1 is a bug that was
apparently already reported against light-locker.)

Best,
Damien

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

Hi.
I've looked a bit at the systemd code as compared to the elogind code.

One of the major reasons that libsystemd0 cannot be used as a
replacement for libelogind0 is that elogind does not have compatible
cgroup naming.
The systemd (and elogind) libraries  do some operations over dbus.
But other operations are done directly.  For example to look and see
what session a pid is in, the library will look at the cgroups of the
pid.
Similarly to see whether a particular pid belongs to a uid, it looks at
the cgroup naming.

If you take a look at src/basic/cgroup-util.c in the elogind sources and
take a look at what is #if 0'd you can see the naming differences.

I don't know what would happen if  you built a elogind that used systemd
naming.  I don't know what the next hurtle would be.


--Sam

Bug#900451: fenix: please upload pending changes from git, or remove from Debian

[Javier Serrano Polo]

On Wed, 30 May 2018 23:31:40 +0100 Simon McVittie 
wrote:
> src:fenix has had pending changes in git since 2015 which have
> not been uploaded.

On 2019-02-13, fenix 0.92a.dfsg1-12 was accepted into unstable. Please
close the report if you feel all significant issues have been solved.

> I can't help questioning whether a project that still isn't 64-bit
> clean is suitable for a stable release in 2018.

Debian's structural policies may be the fault.

smime.p7s
Description: S/MIME cryptographic signature

Bug#941003: iso-codes/iso_3166-1: [INTL:tr] turkish translation update

[Dr. Tobias Quathamer]

Am 23.09.19 um 12:01 schrieb Atila KOÇ:
> Please find attached the Turkish translation of iso-codes/iso_3166-1
> package.
> It has been submitted for review to the debian-l10n-turkish mailing list.

Hi Atila,

many thanks for your update. I've received an update for Turkish just
yesterday via Weblate[1], could you check if those changes are correct
and should remain in the repository?

Regards,
Tobias

[1] https://hosted.weblate.org/languages/tr/iso-codes/
From 86955f432b4874f779b399ae125c2abdf74605d3 Mon Sep 17 00:00:00 2001
From: Oguz Ersen 
Date: Sun, 22 Sep 2019 07:00:47 +
Subject: [PATCH] ISO 3166-1: Turkish from Weblate

100.0%, 420 of 420 strings
---
 iso_3166-1/tr.po | 85 +++-
 1 file changed, 40 insertions(+), 45 deletions(-)

diff --git a/iso_3166-1/tr.po b/iso_3166-1/tr.po
index 81f99f33..495b5cd9 100644
--- a/iso_3166-1/tr.po
+++ b/iso_3166-1/tr.po
@@ -12,20 +12,23 @@
 # Mert Dirik , 2008.
 # Ä°smail Baydan , 2011.
 # Atila KOÇ , 2013-2015,2018.
+# Oguz Ersen , 2019.
 msgid ""
 msgstr ""
 "Project-Id-Version: iso_3166-1\n"
 "Report-Msgid-Bugs-To: https://salsa.debian.org/iso-codes-team/iso-codes/;
 "issues\n"
 "POT-Creation-Date: 2019-03-20 13:20+0100\n"
-"PO-Revision-Date: 2018-09-25 15:25+0300\n"
-"Last-Translator: Atila KOÇ \n"
-"Language-Team: Turkish \n"
+"PO-Revision-Date: 2019-09-22 13:38+\n"
+"Last-Translator: Oguz Ersen \n"
+"Language-Team: Turkish \n"
 "Language: tr\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Generator: Poedit 1.8.11\n"
+"Plural-Forms: nplurals=2; plural=n != 1;\n"
+"X-Generator: Weblate 3.9-dev\n"
 
 #. Name for ABW
 msgid "Aruba"
@@ -201,15 +204,15 @@ msgstr "Bosna-Hersek Cumhuriyeti"
 
 #. Name for BLM
 msgid "Saint Barthélemy"
-msgstr "Sen Barthélemy"
+msgstr "Saint Barthélemy"
 
 #. Name for BLR
 msgid "Belarus"
-msgstr "Beyaz Rusya"
+msgstr "Belarus"
 
 #. Official name for BLR
 msgid "Republic of Belarus"
-msgstr "Beyaz Rusya Cumhuriyeti"
+msgstr "Belarus Cumhuriyeti"
 
 #. Name for BLZ
 msgid "Belize"
@@ -385,7 +388,7 @@ msgstr "Christmas Adası"
 
 #. Name for CYM
 msgid "Cayman Islands"
-msgstr "Seyman Adaları"
+msgstr "Cayman Adaları"
 
 #. Name for CYP
 msgid "Cyprus"
@@ -425,7 +428,7 @@ msgstr "Dominik"
 
 #. Official name for DMA
 msgid "Commonwealth of Dominica"
-msgstr "Dominika Milletler Topluluğu"
+msgstr "Dominik Milletler Topluluğu"
 
 #. Name for DNK
 msgid "Denmark"
@@ -592,10 +595,8 @@ msgid "Gambia"
 msgstr "Gambiya"
 
 #. Official name for GMB
-#, fuzzy
-#| msgid "Republic of Zambia"
 msgid "Republic of the Gambia"
-msgstr "Zambiya Cumhuriyeti"
+msgstr "Gambiya Cumhuriyeti"
 
 #. Name for GNB
 msgid "Guinea-Bissau"
@@ -823,7 +824,7 @@ msgstr "Kiribati Cumhuriyeti"
 
 #. Name for KNA
 msgid "Saint Kitts and Nevis"
-msgstr "Sen Kitts ve Nevis"
+msgstr "Saint Kitts ve Nevis"
 
 #. Name for KOR
 msgid "Korea, Republic of"
@@ -863,7 +864,7 @@ msgstr "Libya"
 
 #. Name for LCA
 msgid "Saint Lucia"
-msgstr "Sen Lucia"
+msgstr "Saint Lucia"
 
 #. Name for LIE
 msgid "Liechtenstein"
@@ -903,15 +904,15 @@ msgstr "Lüksemburg"
 
 #. Official name for LUX
 msgid "Grand Duchy of Luxembourg"
-msgstr "Lüksemburg Büyük Dukalığı"
+msgstr "Lüksemburg Büyük Dükalığı"
 
 #. Name for LVA
 msgid "Latvia"
-msgstr "Latviya"
+msgstr "Letonya"
 
 #. Official name for LVA
 msgid "Republic of Latvia"
-msgstr "Latviya Cumhuriyeti"
+msgstr "Letonya Cumhuriyeti"
 
 #. Name for MAC
 msgid "Macao"
@@ -923,7 +924,7 @@ msgstr "Çin Halk Cumhuriyeti Makao Özel İdari Bölgesi"
 
 #. Name for MAF
 msgid "Saint Martin (French part)"
-msgstr "Sen Martin (Fransız kısmı)"
+msgstr "Saint Martin (Fransız kısmı)"
 
 #. Name for MAR
 msgid "Morocco"
@@ -986,16 +987,12 @@ msgid "Republic of the Marshall Islands"
 msgstr "Marşal Adaları Cumhuriyeti"
 
 #. Name for MKD
-#, fuzzy
-#| msgid "New Caledonia"
 msgid "North Macedonia"
-msgstr "Yeni Kaledonya"
+msgstr "Kuzey Makedonya"
 
 #. Official name for MKD
-#, fuzzy
-#| msgid "Republic of Lithuania"
 msgid "Republic of North Macedonia"
-msgstr "Litvanya Cumhuriyeti"
+msgstr "Kuzey Makedonya Cumhuriyeti"
 
 #. Name for MLI
 msgid "Mali"
@@ -1015,7 +1012,7 @@ msgstr "Malta Cumhuriyeti"
 
 #. Name for MMR
 msgid "Myanmar"
-msgstr "Miyanmar"
+msgstr "Myanmar"
 
 #. Official name for MMR
 msgid "Republic of Myanmar"
@@ -1031,11 +1028,11 @@ msgstr "Moğolistan"
 
 #. Name for MNP
 msgid "Northern Mariana Islands"
-msgstr "Kuzey Meryem Adaları"
+msgstr "Kuzey Mariana Adaları"
 
 #. Official name for MNP
 msgid "Commonwealth of the Northern Mariana Islands"
-msgstr "Kuzey Meryem Adaları Milletler Topluluğu"
+msgstr "Kuzey Mariana Adaları Milletler Topluluğu"
 
 #. Name for MOZ
 msgid "Mozambique"
@@ -1127,7 +1124,7 @@ msgstr "Nikaragua Cumhuriyeti"
 
 #. Name for NIU, Official name for NIU
 msgid "Niue"
-msgstr "Nie"
+msgstr 

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Mark" == Mark Hindley  writes:


>> If we are going to use c/r/p libsystemd0, is there some way we
>> can limit the potential damage to people who have positively
>> indicated that they want to run a non-default init system?  One
>> of the concerns is what happens if apt decides somehow that it
>> wants to install libelogind0 when you don't expect it.

Mark> I have to admit I don't understand this fear. libsystemd0 is
Mark> just a way of talking to a running systemd process. If systemd
Mark> is not running and PID 1 libsystemd0 APIs generally return non
Mark> fatal errors. So by running a non-default init, libsystemd0 is
Mark> only there to satisfy dynamically loaded symbols at
Mark> runtime. Otherwise it is basically non functional. libelogind0
Mark> is the same if elogind isn't running.

Foo-package depends on the latest libsystemd0.  I'm running unstable or
testing.  The latest libsystemd0 isn't building on my arch yet.  But
elogind is simpler and has build fine on my arch.  I install foo-package
and suddenly end up with libelogind0 instead of libsystemd0

This is probably a problem.
Libsystemd0 and libelogind0 probably behave differently and you probably
do care which one you have.
The specific problems depend on what init system I have, on whether I
have elogind running or systemd-logind, etc.
But it's probably not a good situation.


The concern is there might be other cases where the dependency resolver
gives you an answer that is inappropriate for your environment.  We're
not sure we have confidence we can enumerate and think about all these
situations.


This is less likely with things like mail-transport-agent because the
dependencies are closer to their usage, or because the size of the
interacting parts of the dependency graph are smaller.

Bug#892939: Suggesting bug closed

[Torben Schou Jensen]

My display problem have been solved now by connecting monitor by HDMI
cable and DisplayPort/HDMI converter to HDMI-2 port.
This with kernel
Linux ci547 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64
GNU/Linux

Using HDMI cable on DP-1 port make drm issue "Link Training Unsuccessful"
messages.
On kernel 4.9.0-9 I had no problem getting 1920x1080 on DP-1.

ZOTAC ZI547 have 2 output ports, 1 DisplayPort (HDMI-2) and 1 HDMI (DP-1).

Bug#939835: 10 seconds delay when shutting down system caused by libvirt-guests.sh

[manul]

Package: libvirt-daemon
Version: 5.6.0-2
Followup-For: Bug #939835

Same issue here.

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

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

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.34-0.1
ii  libc6   2.29-2
ii  libcap-ng0  0.7.9-2+b1
ii  libdbus-1-3 1.12.16-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse22.9.9-2
ii  libgcc1 1:9.2.1-8
ii  libgnutls30 3.6.9-5
ii  libnetcf1   1:0.2.8-1+b3
ii  libparted2  3.2-26
ii  libpcap0.8  1.9.0-2
ii  libpciaccess0   0.14-1
ii  libselinux1 2.9-2+b2
ii  libudev1242-7
ii  libvirt05.6.0-2
ii  libxenmisc4.11  4.11.1+92-g6c33308a8d-2+b1
ii  libxenstore3.0  4.11.1+92-g6c33308a8d-2+b1
ii  libxentoollog1  4.11.1+92-g6c33308a8d-2+b1
ii  libxml2 2.9.4+dfsg1-7+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils2.9.4+dfsg1-7+b3
pn  netcat-openbsd   
pn  qemu-kvm | qemu  

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.6.0-2
pn  numad  

-- no debconf information

Bug#941034: FFADO-mixer does not load - patch to fix bug

[Sebastian Ramacher]

Package: ffado-mixer-qt4
Version: 2.4.1-0.1
Control: submitter -1 Yoann LE BARS 
Control: forwarded -1 
https://sourceforge.net/p/ffado/mailman/ffado-user/?viewmonth=201909=11
Control: tags -1 fixed-upstream upstream

On 2019-09-16 00:26:27, Yoann LE BARS wrote:
> 
> Hello everybody out there!
> 
>   I am using Debian 10:
> 
> $ cat /etc/debian_version
> 10.1
> 
>   I am using FFADO-mixer from standard distribution repositories:
> 
> $ aptitude versions ffado-mixer-qt4
> i   2.4.1-0.1 stable
> 900
> 
>   I have experimented a bug I have not seen in Debian bug tracker system:
> when I tried to launch FFADO-mixer, it failed to load (see log at the
> end of this message).
> 
>   I have asked for help on FFADO mailing list:
> 
> https://sourceforge.net/p/ffado/mailman/ffado-user/?viewmonth=201909=11
> 
>   Jonathan Whoithe has then sent a patch which solves the problem:
> 
> https://sourceforge.net/p/ffado/mailman/message/36760579/
> 
>   Well, I think this patch should probably be added to the package. Can
> anyone tell me what I should do to propose this patch? Should I open a
> bug issue on Debian bug tracker, then send the patch? Should I do
> something else?
> 
>   Best regards.
> 
> $ ffaddo-mixer-qt4
> Traceback (most recent call last):
>   File "/usr/share/ffado-mixer-qt4/ffado/import_pyqt.py", line 35, in
> 
> from PyQt4.QtCore import QByteArray, QObject, QTimer, Qt,
> pyqtSignal, QString, pyqtSlot
> ImportError: cannot import name 'QString' from 'PyQt4.QtCore'
> (/usr/lib/python3/dist-packages/PyQt4/QtCore.cpython-37m-x86_64-linux-gnu.so)
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/bin/ffado-mixer", line 31, in 
> from ffado.ffadowindow import *
>   File "/usr/share/ffado-mixer-qt4/ffado/ffadowindow.py", line 27, in
> 
> from ffado.config import *
>   File "/usr/share/ffado-mixer-qt4/ffado/config.py", line 35, in 
> from ffado.import_pyqt import *
>   File "/usr/share/ffado-mixer-qt4/ffado/import_pyqt.py", line 39, in
> 
> from PyQt5 import QtGui, Qt, QtCore, Qt, QtWidgets, uic
> RuntimeError: the PyQt5.QtCore and PyQt4.QtCore modules both wrap the
> QObject class

Let's turn this into a proper bugreport.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

Sam,

Many thanks for this.

On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote:
  Mark> I have tried the approach suggested by Laurent of using
  Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs
  Mark> to function correctly.
>  What trouble did you run into?

That sd-login(3) APIs failed to match pids to the current session and so
policykit authorisation failed.

> So, I think I understand Julian's issues better after trying to write my
> bits from the DPL mail.

You have explained Julian's position and concerns far more clearly than has ever
been the case directly to me.

> You haven't really tried to address them at all.

Hmmm. I think I have in line with the clarity with which they have been
expressed. But let's move on.

> His issue is that we have a long history of trouble with apt and c/r/p
> being used this deep in the dependency chain.
> So, he's arguing that you have a high bar (possibly infinitely high) for
> using that approach.
> 
> Ultimately he wants you to produce a solution where multiple init
> systems can be coinstalled and where you don't need a conflicts.

OK. But elogind is not an init. sysvinit-core and systemd are coinstallable, but
not sysvinit-core and systemd-sysv.

Do you mean he wants elogind and systemd to be coninstallable?

> I think you've explored some of that design space and have a feel for
> why some of that is unattractive.
> As an example, if you have systemd installed, it might be running.  The
> combination of systemd running and libelogind0 being the systemd library
> is unfortunate.  Trying to boot systemd in that configuration (using
> libelogind0) would presumably be quite fatal.

Yes and this is currently prevented because both elogind and libelogind0
conflict with systemd.

> So, the next question is why libelogind0 needs to exist.  That is why
> can't you just use libsystemd0 with elogind?
> What I've heard so far is "It doesn't work."

This was asked of elogind upstream this question almost a year ago:

 https://github.com/elogind/elogind/issues/97

In particular Yamakazure replied

 "What I can guarantee is, that if you link something against libsystemd, and
 then use elogind, that "something" will not work, as the inner workings of
 libsystemd are quite different. So keeping libsystemd around is no option. But
 if libsystemd is gone and simply replaced by libelogind, it might work."

And we have since demonstrated that once the libelogind0 exposes the same ABI as
libsystemd0 so it can be used as a direct replacement, it does work.

A couple of days ago I built elogind without libelogind0 and installed it on a
system with sysvinit-core and libsystemd0. Applications using the sd-login(3)
API, most notably policykit-1 failed to associate pids and sessions and so all
policykit-based authentication failed.

> Why doesn't it work?  How hard would it be to make it work?

I am not completely sure. But I think it is because elogind and systemd-login
store information in /sys/fs/cgroup/ differently because elogind does not have
or need many of the features of systemd. Currently you need a matched pair,
either systemd/libsystemd0 or elogind/libelogind0 for successful operation.

elogind is never going to have all the features of systemd. That would be
pointless. If you want or require all of those features, just use systemd.

> Would that be better for Debian than using c/r/p?
> And the answer to some of these might be "we don't know and we don't
> have anyone who can find out."
> That is a fine answer to give, although it might also be fine for the
> release team to say that they want that analysis before committing to
> something dangerous like c/r/p libsystemd0.
> 
> But even if we understand why libelogind0 is needed, then why do we need
> c/r/p libsystemd0?
> Could we do something with dpkg-divert? Would that be better?

It might possibly work. I will try it out. But, playing devil's advocate, I
don't really see the difference: you will still be replacing libsystemd.so with
libelogind.so. The only difference is where it happens -- in the package or via
dpkg-divert.

> If we are going to use c/r/p libsystemd0, is there some way we can limit
> the potential damage to people who have positively indicated that they
> want to run a non-default init system?
> One of the concerns is what happens if apt decides somehow that it wants
> to install libelogind0 when you don't expect it.

I have to admit I don't understand this fear. libsystemd0 is just a way of
talking to a running systemd process. If systemd is not running and PID 1
libsystemd0 APIs generally return non fatal errors. So by running a non-default
init, libsystemd0 is only there to satisfy dynamically loaded symbols at
runtime. Otherwise it is basically non functional. libelogind0 is the same if
elogind isn't running. 

So the scenarios I can see are

 1) systemd PID 1 with libsystemd0
 2) alternative init with libsystemd0
 3) alternative init with libelogind0
 4) no init 

Bug#940801: missing virtio block Kernel Objects

[Steve McIntyre]

On Mon, Sep 23, 2019 at 05:51:33PM +0200, Fred Boiteux wrote:
>    Hello Steve,
>
>[ I don't know if I have to CC: to the bug report, so not doing it, please
>feel free to correct me ]

[ re-adding the CC :-) ]

>I'm trying to install a Debian 10 Buster on a VM, booted by network boot,
>hosted on a [Debian] system without Internet access, so I try to give Debian
>Installer all stuff it need from a local HTTP mirror. The installer starts
>fine, but can't detect [virtual] disk and thus can't partition it. It seems
>the virtio_blk module isn't loaded, and I'm trying to find where it should be
>found and loaded by the installer…

Right.

So, let me explain the setup we have. There are different instances of
initramfs created for different needs, and they contain different
things.

1. netboot initramfs

   This is designed to be booted from the network. It includes the
   core of the installer. It includes a small-ish subset of kernel
   modules, basically just what's needed to configure network devices
   and then go and download all the other bits (filesystems, block
   device drivers, more installer modules, etc.) from a Debian mirror.

   If you're using a netboot setup, you will need to include a full
   set of udebs from a Debian mirror in a place where the installer
   can find them. An extra constraint for the network installer here
   is that the kernel module udebs you provide must match *exactly*
   the version of the kernel that you have booted. This is a thing
   that often bites people, hence I mention it.

   The initramfs here directly includes the contents of *some* of the
   udebs, so it will not need to fetch them separately.

2. CD/DVD/USB initramfs 

   This is designed to be booted from a disk-like device. It includes
   the core of the installer. It includes a small-ish subset of kernel
   modules, basically just what's needed to locate, configure and
   mount block devices so it can go and find the rest of the needed
   components (network drivers, more installer modules, etc.) from
   those block devices.

   If you're using a Debian-provided CD/DVD/USB based installer, then
   you will already have all the udebs that are needed to go with it,
   as part of that CD/DVD/USB image. The version constraint for the
   module udebs is still there, but you (normally) don't need to worry
   about this as you have a complete set of things in one place.

   Again, the initramfs here directly includes the contents of some of
   the udebs so we do *not* include those udebs in the CD/DVD/USB
   image, to save space - we don't need two copies, after all. This
   includes the "scsi" storage drivers and a few others.

So, this is why you haven't found the virtio modules on the contents
of the DVD image you're using. You'll probably need to grab the rest
of the udebs from a network mirror and share those separately. Look
for

  
pool/main/l/linux-signed-amd64/scsi-modules-4.19.0-6-amd64-di_4.19.67-2_amd64.udeb

for current buster for amd64, for example.

I hope that helps to explain?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#929323: cacti-spine: results_buffer size limits reporting capabilities

[Anthony Bible]

Paul,
I've noticed the upstream included a fix
(https://github.com/Cacti/spine/issues/94) and was wondering if you
might release this fix?

On 5/23/19 12:23 PM, Paul Gevers wrote:
> Control: forwarded -1 https://github.com/Cacti/spine/issues/94
>
> Hi Anthony
>
> On 21-05-2019 18:02, Anthony Bible wrote:
>> We have several services being checked that return more than 1024
>> bytes (with_resluts_buffer limit of cacti-spine). This makes it so
>> information doesn't get catalouged by cacti.
> Thanks for your report. I have forwarded it to the upstream issue tracker.
>
> Paul
>
-- 
Anthony Bible

Inetz Jr. Systems Administrator

Bug#940996: lightdm: when resuming from ram, user desktop appears for 1sec before getting prompted for a password

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2019-09-23 at 10:35 +0200, Damien wrote:
> When I suspend to ram (eg, by closing the lid), then wake up, I see the last
> state of my screen (desktop with open applications) for ~1sec before getting
> the lightdm password prompt.
> I don't know if my session is properly locked during that time, but for sure 
> it
> releases information which I would expect to be protected by proper screen
> locking.

You can vt-switch to VT7 to check for yourself, but I'd assume it *is* locked
(please report otherwise).

Please also try the “late lock” settings and see if that makes a difference.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2JAwAACgkQ3rYcyPpX
RFsZ2wf+Nu+gJhKjm0xY6xmm2BWLCARgh0I92KwlFEgpSKNIB9SHfuCXq00uDl+b
BIYtI6lkOQXccQuHx9VU3STLZx/2fxUFpknSCN20d3p0Zk85ga/1CnuMVe1+h7hw
NEXYlv/2FS4gkAbhYQkDl6KPIvb+JJkotwig5n8s/HGVJdTh6SmOIHtMAa9iewVy
B+BWR5eACVamu+xMxAJESnVosvYdtHpxbqxYSFrNQUUol87V9R6jGPnQRvGfTW6k
F+iKkfEGSKkzgk8rfWaFi2nJ1haluB35Eadl/akZZEJiHszP3NPTeBgxXKRAcn7g
CRxlUAH6AWjaBT7r+AOQ286RwbNQKA==
=hlxL
-END PGP SIGNATURE-

Bug#941025: autogen FTCBFS: multiple regressions

[Andreas Metzler]

On 2019-09-23 Helmut Grohne  wrote:
> Source: autogen
> Version: 1:5.18.16-2
> Severity: important
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs

> autogen fails to cross build from source. It used to build previously
> and this is important for cross bootstrapping Debian architectures.

> 1. config/ag_macros.m4 lacks a crucial comma in an application of
>AC_RUN_IFELSE. This causes arguments to be shifted. With the bug,
>presence of strcspn is misdetected everywhere and for cross
>compilation, the build simply fails.

> 2. build-aux/run-ag.sh hard codes some path for AGexe, which makes the
>build unable to find a working autogen.

> 3. The relevant callers of run-ag.sh fail to pass the corret AGexe.

> Please consider applying the attached patch.
[...]

Thank you.

I plan to let 1:5.18.16-2 migrate to testing first since migration to
guile-2.2 seems to be urgent (serious bug).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#941032: logwatch: dovecot 2.3.x LMTP delivery not recognized by logwatch

[Jo Valentine-Cooper]

Package: logwatch
Version: 7.5.0-1
Severity: normal
Tags: patch

In Dovecot 2.3.4.1 (as shipped in buster), LMTP deliverly log lines have
subtly changed such that the Dovecot service script for logwatch no
longer recognizes them. See diff below for illustrative example and fix.

Hope this helps!
-jo


--- /usr/share/logwatch/scripts/services/dovecot2018-12-30 
04:17:30.0 -0500
+++ /etc/logwatch/scripts/services/dovecot  2019-09-23 13:12:40.938216046 
-0400
@@ -242,6 +242,11 @@
 # dovecot: lmtp(u...@domain.com): 
msgid=<0.0.b.b83.1d385668207af0...@b12.mta01.sendsmaily.info>: saved mail to 
INBOX
   $Deliver{$User}{$Mailbox}++;
 
+# LMTP-based delivery Dovecot 2.3
+} elsif ( ($User, $Mailbox) = ( $ThisLine =~ /^$dovecottag 
lmtp\((.*)\)<.*><.*>: msgid=.*: saved mail to (.*)/ ) ) {
+# dovecot: lmtp(u...@domain.com)<2844>: 
msgid=<20987363.1159.374...@wordpress.com>: saved mail to INBOX
+  $Deliver{$User}{$Mailbox}++;
+
 # LMTP-based Sieve delivery
} elsif (my ($User, $Mailbox) = ( $ThisLine =~ /^$dovecottag lmtp\((?:\d+, 
)?(.*?)\)(?:<[^>]+><[^>]+>)?: .*: sieve: msgid=.*: stored mail into mailbox 
'(.*)'/ ) ) {
   $Deliver{$User}{$Mailbox}++;



-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages logwatch depends on:
ii  exim4-daemon-heavy [mail-transport-agent]  4.92-8+deb10u1
ii  perl   5.28.1-6

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.76-1
ii  libsys-cpu-perl  0.61-2+b4
ii  libsys-meminfo-perl  0.99-1+b3

logwatch suggests no packages.

-- no debconf information

Bug#941033: gitlab-runner: git lfs is broken: mk-prebuilt-images.sh missing git-lfs

[Melvin Vermeeren]

Package: gitlab-runner
Version: 12.1.0+dfsg-1
Severity: important
Tags: patch

The mk-prebuilt-images.sh is currently missing git-lfs, which is needed when the
runner handles repositories using git lfs. I have confirmed all that is required
to fix it is to include git-lfs in the cdebootstrap command.

Side note: I believe compressing the rootfs does not add anything in the end
because docker uses its own magic internally. This only applies to the first
tarball created, currently called stable.tar.xz. Could speed up the image
building by quite a bit by making it just stable.tar (and updating the ADD in
Dockerfile).

Thanks.

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

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

Versions of packages gitlab-runner depends on:
ii  adduser  3.118
ii  ca-certificates  20190110
ii  git  1:2.20.1-2
ii  libc62.28-10
ii  lsb-base 10.2019051400

Versions of packages gitlab-runner recommends:
ii  cdebootstrap  0.7.7+b12
ii  xz-utils  5.2.4-1

Versions of packages gitlab-runner suggests:
ii  docker.io  18.09.1+dfsg1-7.1+deb10u1

-- Configuration Files:
/etc/gitlab-runner/config.toml [Errno 13] Permission denied: 
'/etc/gitlab-runner/config.toml'

-- no debconf information

Bug#934242: state of the crystalhd package

[harald]

This is just a kind of memo for a new maintainer:

*) currently the active tree is https://github.com/dbason/crystalhd - last 
commit was 4 Jun 2018 with a kernel module change
*) a firmware-crystalhd package with bcm70012fw.bin and bcm70015fw.bin is 
needed in non-free for the module to work
*) as the module itself was removed from the kernel a crystalhd-dkms package is 
needed again, the module from above tree compiles against kernel source 
5.3.0-rc5

Bug#941028: python3-os-refresh-config: missing Breaks+Replaces: python-os-refresh-config

[Andreas Beckmann]

Package: python3-os-refresh-config
Version: 10.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python3-os-refresh-config_10.1.0-1_all.deb ...
  Unpacking python3-os-refresh-config (10.1.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-os-refresh-config_10.1.0-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/os-refresh-config', which is also in package 
python-os-refresh-config 0.1.2-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-os-refresh-config_10.1.0-1_all.deb


cheers,

Andreas


python-os-refresh-config=0.1.2-1_python3-os-refresh-config=10.1.0-1.log.gz
Description: application/gzip

Bug#920306: problem solved

[Alexander Beerhoff]

Hi, problem seem to be solved with kernel 5.
Still unable to wake up my system from sleep with distro kernel while with
kernel compiled myself no-problem

-- 
Umi sukoschi
Niwa ni izumi no
Ko no ma ka na

Bug#941027: transition: bullet

[Markus Koschany]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I would like to request a transition slot for Bullet 2.88 which is
already available in experimental.

The affected reverse-dependencies are:

* cyphesis-cpp
* efl
* gazebo
* hkl
* kido
* openmw
* ros-geometry
* ros-geometry2
* siconos

I have successfully rebuilt all reverse-dependencies except of
siconos. Currently siconos fails to build from source because of some
test failures. However this appears to be unrelated to the Bullet
transition and siconos has not mitgrated to testing anyway because of
that.

Regards,

Markus

Ben file:

title = "bullet";
is_affected = .depends ~ /libbullet2\.87|libbullet-extras2\.87/;
is_good = .depends ~ /libbullet2\.88|libbullet-extras2\.88/;
is_bad = .depends ~ /libbullet2\.87|libbullet-extras2\.87/;


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

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#941029: ndctl: please add Multi-Arch settings

[Adam Borowski]

Source: ndctl
Version: 65-1
Severity: wishlist

Hi!
While using cross-arch ndctl itself would be quite insane, there are
libraries coming higher in the stack that have other uses yet want to
(transitively) link to libndctl.  Also, folks who use weird archs like
ppc started submitting patches whose testing wants qemu.

Thus... could you please add Multi-Arch settings?

There are:
libndctl6, libdaxctl1: same
libndctl-dev, libdaxctl-dev: same
ndctl, daxctl: foreign


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

Kernel: Linux 5.3.1-00049-g50de0fd5c114 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#938874: yum-metadata-parser: Python2 removal in sid/bullseye

[Mike Miller]

On Sun, Sep 22, 2019 at 00:51:34 +0900, Kentaro Hayashi wrote:
> I'm not familiar with yum-metadata-parser at all, but
> I'm not willing to remove createrepo (it depends yum-metadata-parser)
> So, I've tried to fix this issue by adding python3 version.

Adding Python 3 support to yum-metadata-parser will not have much of an
impact. But if you want to proceed with an nmu or adopt this package,
feel free, this package is up for adoption, as well as createrepo.

Much more helpful long term would be to contribute to getting
createrepo_c (#912338) and dnf (no ITP yet) into Debian so these Python
2 packages can be dropped.

-- 
mike


signature.asc
Description: PGP signature

Bug#940660: elpa-elpy: add Suggests: python3-rope to refactor code

[Salman Mohammadi]

Hi David,

Yeah, I would update the MR to use Bowler , but 
currently Bowler is not in the repos.



Regards


On Sat, 21 Sep 2019 14:33:45 -0400 Nicholas D Steeves 
 wrote:


> Control: forwarded -1 https://github.com/jorgenschaefer/elpy/issues/1449
>
> Hi Salman and David,
>
> On Wed, Sep 18, 2019 at 01:54:17PM -0300, David Bremner wrote:
> > Salman Mohammadi  writes:
> >
> > > Package: elpa-elpy
> > > Version: 1.31.0-1
> > > Severity: normal
> > >
> > > Dear Nicholas,
> > >
> > > Adding this entry `Suggests: python3-rope` to debian/control ensures
> > > that we can refactor the code without error messages like this:
> > >
> > > elpy-rpc--default-error-callback: Elpy error: rope not installed, 
cannot

> > > refactor code.
> > >
> >
>
> Thank you for filing this bug, much appreciated. I've set the
> forwarded URL to the preexisting upstream issue on the removal of
> Rope. If upstream changes its mind about the removal. The current
> upstream maintainer doesn't use this functionality, so it's
> effectively unmaintained. To avoid deprecating your contribution,
> would you please update your MR to use Bowler if upstream switches to
> it?
>
> > Just for the record, Suggests won't cause it to be installed
> > automatically for many (most?) users.
>
> Thanks for the reminder ;-) Salman initially proposed a Recommends,
> which I NACKed, (see above paragraph and URL, esp previous
> maintainer's NACK of Rope usage for rationale), and also because IIRC
> Antoine (anarcat) said he didn't use it either in his initial RFP. I
> also use Elpy without rope.
>
>
> Cheers,
> Nicholas

Bug#941031: RFS: libinsane/1.0.1-1 [ITP] -- Library to access scanner

[Thomas Perret]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: libinsane
   Version : 1.0.1-1
   Upstream Author : https://groups.google.com/forum/#!forum/paperwork-gui
 * URL : https://gitlab.gnome.org/World/OpenPaperwork/libinsane
 * License : LGPL-3.0+
 * Vcs : https://salsa.debian.org/openpaperwork-team/libinsane
   Section : libs

It builds those binary packages:

  libinsane-dev - Library to access scanner - development files
  libinsane1 - Library to access scanner
  gir1.2-libinsane-1.0 - Library to access scanner - GObject bindings
  libinsane-doc - Library to access scanner - documentation

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libi/libinsane/libinsane_1.0.1-1.dsc

Changes since the last upload:

   * Initial release (Closes: #940962)

I took the liberty to forward to DD who offer sponsorship or help at some point.


Regards,

--
  Thomas Perret

Bug#941030: python3-os-apply-config: missing Breaks+Replaces: python-os-apply-config

[Andreas Beckmann]

Package: python3-os-apply-config
Version: 10.4.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python3-os-apply-config_10.4.1-1_all.deb ...
  Unpacking python3-os-apply-config (10.4.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-os-apply-config_10.4.1-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/os-apply-config', which is also in package 
python-os-apply-config 0.1.14-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-os-apply-config_10.4.1-1_all.deb


cheers,

Andreas


python-os-apply-config=0.1.14-1_python3-os-apply-config=10.4.1-1.log.gz
Description: application/gzip

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[gregor herrmann]

On Mon, 23 Sep 2019 13:02:04 +0100, Chris Lamb wrote:

> This has been fixed upstream here:
>   
> https://github.com/farblos/perl-Archive-Zip/commit/b0179cbbfeb276ceac0f424d32acf56811b01568

Thanks for the analysis!
I've now uploaded -2 with this patch (minus 2 not applying but
irrelevant hunks) plus the previous commit which also touches on the
same topic. Will monitor the behaviour a bit :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Jerry Lee Lewis: It'll Be Me


signature.asc
Description: Digital Signature

Bug#941026: netcfg_gateway_reachable wrongly rejects IPv6 link-local addresses

[Andrew Kanaber]

Package: netcfg
Version: 1.160
Severity: normal

When doing static IP configuration, netcfg will reject a gateway address
outside the host's network as defined by the netmask. This is wrong for IPv6
because the gateway can legitimately be a link-local address in fe80::/64
instead of the host's network range. Ubuntu have fixed this bug in their
version, see LP#1382295
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/1382295

The relevant function is netcfg_gateway_reachable in netcfg-common.c which
simply checks gateway_address & netmask == host_address. It should also allow
IPv6 addresses in the link local prefix fe80::/64.

Less importantly, the error message it triggers could be a bit clearer, "The
gateway address you entered is unreachable" sounds like it might be a network
error when it's purely a user-input parsing rejection - if the code had
actually tried the link-local address it would've worked. 

Thanks for your help,

Andrew Kanaber

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Adam Borowski]

On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote:
> Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that
> Mark> installed I can no longer reproduce #934491. The APT
> Mark> maintainers have said that adding a Breaks for the fixed
> Mark> version of apt is not useful.
> 
> Normally in a situation like this we would wait until the next stable
> release for depending on the change in apt.
> It's a bit complicated because it is a bug, but Julian's idea that we
> need to wait until bullseye+1 to depend on this apt fix is not an
> unreasonable approach.

So this avenue is right out.  Fixing the GUI uninstallability regression and
backporting it to Buster is urgent, waiting whole two years is not an
option.

We did have elogind coinstallable with libsystemd0 (before version
241.1-1+debian1) and at least for all _my_ use cases it worked well.
As I'm aware, the main problem is policykit, right?  There were initial
ideas, not liked by its maintainer, but we can analyze further.

Having some idea about other possible failures would be nice.

> Mark> I have tried the approach suggested by Laurent of using
> Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs
> Mark> to function correctly.
> What trouble did you run into?

If whatever trouble (not yet named) can't be fixed on the other side of
daemon, we can perhaps patch libsystemd0 itself?

> As an example, if you have systemd installed, it might be running.  The
> combination of systemd running and libelogind0 being the systemd library
> is unfortunate.  Trying to boot systemd in that configuration (using
> libelogind0) would presumably be quite fatal.

Right, both must be coinstallable; with systemd-logind gracefully refusing
to start when booted with some other init, and elogind likewise not starting
when systemd-the-init is pid 1.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941025: autogen FTCBFS: multiple regressions

[Helmut Grohne]

Source: autogen
Version: 1:5.18.16-2
Severity: important
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

autogen fails to cross build from source. It used to build previously
and this is important for cross bootstrapping Debian architectures.

1. config/ag_macros.m4 lacks a crucial comma in an application of
   AC_RUN_IFELSE. This causes arguments to be shifted. With the bug,
   presence of strcspn is misdetected everywhere and for cross
   compilation, the build simply fails.

2. build-aux/run-ag.sh hard codes some path for AGexe, which makes the
   build unable to find a working autogen.

3. The relevant callers of run-ag.sh fail to pass the corret AGexe.

Please consider applying the attached patch.

Helmut
--- autogen-5.18.16.orig/config/ag_macros.m4
+++ autogen-5.18.16/config/ag_macros.m4
@@ -428,7 +428,7 @@
char zRej@<:@@:>@ = reject;
char zAcc@<:@@:>@ = "a-ok-eject";
return strcspn( zAcc, zRej ) - 5;
-}] )]
+}] )],
 [ag_cv_run_strcspn=yes],[ag_cv_run_strcspn=no],[ag_cv_run_strcspn=no]
   ) # end of RUN_IFELSE
   ]) # end of AC_CACHE_VAL for ag_cv_run_strcspn
--- autogen-5.18.16.orig/build-aux/run-ag.sh
+++ autogen-5.18.16/build-aux/run-ag.sh
@@ -25,7 +25,6 @@
 # any containing directory must be created. The target is created with a
 # very old time stamp.
 #
-AGexe=/u/bkorb/tools/ag/autogen-bld/agen5/.libs/autogen
 find_exe() {
   eval local exe=\${$1}
   test -x "$exe" && return 0
--- autogen-5.18.16.orig/getdefs/Makefile.am
+++ autogen-5.18.16/getdefs/Makefile.am
@@ -32,7 +32,7 @@
 SUBDIRS = test
 EXTRA_DIST  = opts.def $(gdsrcs)
 AG_ENV  =  top_builddir="$(top_builddir)" top_srcdir="$(top_srcdir)" \
-	VERBOSE="$(V)"
+	VERBOSE="$(V)" AGexe="$(AGexe)"
 RUN_AG  = $(AG_ENV) $(SHELL) "${top_srcdir}/build-aux/run-ag.sh"
 
 all : gen
--- autogen-5.18.16.orig/xml2ag/Makefile.am
+++ autogen-5.18.16/xml2ag/Makefile.am
@@ -37,7 +37,7 @@
 AM_CPPFLAGS = @INCLIST@ $(LIBXML2_CFLAGS)
 AM_CFLAGS   = @WARN_CFLAGS@
 AG_ENV  =  top_builddir="$(top_builddir)" top_srcdir="$(top_srcdir)" \
-	VERBOSE="$(V)"
+	VERBOSE="$(V)" AGexe="$(AGexe)"
 RUN_AG   = $(AG_ENV) $(SHELL) "${top_srcdir}/build-aux/run-ag.sh"
 DOC_TIMEOUT = -DLEVEL=section --timeout=`expr $(AG_TIMEOUT) '*' 3`
 

Bug#941008: loggerhead, multiple dependency issues.

[Jelmer Vernooij]

On Mon, Sep 23, 2019 at 12:50:14PM +0100, peter green wrote:
> Package: loggerhead
> Version: 1.19~bzr479+dfsg-3
> Severity: serious
> 
> Loggerhead has multiple dependency issues.
> 
> The loggerhead source package build-depends on python-subunit which is no 
> longer built by the subunit source package.
> 
> The loggerhead source package build-depends on python-bzrlib.tests || bzr (<< 
> 2.4.0~beta1-2), the former is no longer built by the bzr source package and 
> the latter fails version constraints (the current version of bzr is 
> 2.7.0+bzr6622+brz )
> 
> The loggerhead binary package depends on python-bzrlib, which is no longer 
> built by the bzr source package.
> 
> I notice these issues seem to be fixed in experimental by turning loggerhead 
> into a transitional package to loggerhead-breezy. Should the experimental 
> package simply be uploaded to unstable?
We'll actually do this the other way around, since loggerhead upstream has 
moved to Breezy.

I'm planning to do an upload of loggerhead in the next couple of days that 
switches it to be Python3 and based on Breezy.

Loggerhead-breezy will then become a dummy transitional package that upgrades 
to loggerhead.

Jelmer

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Mark" == Mark Hindley  writes:

Mark> Julian,
Mark> On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote:
>> > I don't think it's reasonable to ship this package with C/R/P >
>> libsystemd0.
>> 
>> I understand that you don't like it. However, for libelogind0 to
>> export the same symbols as libsystemd0 so that it could C/R/P
>> libsystemd0 was the agreed solution to bug #923244.
>> 
>> Do you have another suggestion as to how we could have resolved
>> that? Other solutions were discounted at the time.
>> 
>> > I think it opens you (and, more importantly, users) up to
>> issues like > #934491.  Even if #935910 were to be fixed in the
>> package manager > in > bullseye, it would still mean libelogind0
>> couldn't ship with > the C/R/P > until bullseye+1.
>> 
>> I think it seems likely from discussions on #debian-dpkg that
>> #935910 will be fixed in APT and #934491 can be addressed by
>> adding Breaks: << fixed APT.

Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that
Mark> installed I can no longer reproduce #934491. The APT
Mark> maintainers have said that adding a Breaks for the fixed
Mark> version of apt is not useful.

Normally in a situation like this we would wait until the next stable
release for depending on the change in apt.
It's a bit complicated because it is a bug, but Julian's idea that we
need to wait until bullseye+1 to depend on this apt fix is not an
unreasonable approach.



Mark> I have tried the approach suggested by Laurent of using
Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs
Mark> to function correctly.
What trouble did you run into?


Mark> Are there any outstanding issues that you would like me to
Mark> address to resolve this bug?

So, I think I understand Julian's issues better after trying to write my
bits from the DPL mail.
You haven't really tried to address them at all.
His issue is that we have a long history of trouble with apt and c/r/p
being used this deep in the dependency chain.
So, he's arguing that you have a high bar (possibly infinitely high) for
using that approach.

Ultimately he wants you to produce a solution where multiple init
systems can be coinstalled and where you don't need a conflicts.

I think you've explored some of that design space and have a feel for
why some of that is unattractive.
As an example, if you have systemd installed, it might be running.  The
combination of systemd running and libelogind0 being the systemd library
is unfortunate.  Trying to boot systemd in that configuration (using
libelogind0) would presumably be quite fatal.

So, the next question is why libelogind0 needs to exist.  That is why
can't you just use libsystemd0 with elogind?
What I've heard so far is "It doesn't work."
Why doesn't it work?  How hard would it be to make it work?
Would that be better for Debian than using c/r/p?
And the answer to some of these might be "we don't know and we don't
have anyone who can find out."
That is a fine answer to give, although it might also be fine for the
release team to say that they want that analysis before committing to
something dangerous like c/r/p libsystemd0.

But even if we understand why libelogind0 is needed, then why do we need
c/r/p libsystemd0?
Could we do something with dpkg-divert?  Would that be better?

If we are going to use c/r/p libsystemd0, is there some way we can limit
the potential damage to people who have positively indicated that they
want to run a non-default init system?
One of the concerns is what happens if apt decides somehow that it wants
to install libelogind0 when you don't expect it.
It might be better to have some init-chooser app where you had to
explicitly decide you wanted to opt into a non-default init before it
was possible to get into a situation where libsystemd0 was provided by
libelogind0.
I don't see how to make that work; I'm just brainstorming.

I think it is reasonable for you to expect Julien to be constructively
engaged in the discussion, to find someone else who will constructively
engage and take ownership of his position, or for the bug to close.  At
one level Julien is frustrated: you haven't been addressing his core
issue of the design choice to use c/r/p libsystemd0 and to not have
multiple inits coinstallable.  But at another level Julien has stalled
your project for multiple months, and if we're going to do that we need
to be prepared to engage in trying to actually solve the problem.  I
think some of the frustration here may stem from you not knowing how to
respond to his issue.  You don't have a design without c/r/p libsystemd0
that meets your needs.  And so you've been focusing on trying to solve
the things you could, hoping that would be enough.  Where as a great way
to engage with an issue like this is to explain why Julien is asking you
to do something hard and ask him to work with you to find 

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Gunnar Hjalmarsson]

It may be worth mentioning that Ubuntu's security team has disabled 
CVE-2019-14822.patch in the stable releases for now.


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

Bug#940994: lintian: changelog-file-missing-explicit-entry false positive for versions like flatpak_1.2.5-0+deb10u1

[Simon McVittie]

On Mon, 23 Sep 2019 at 06:53:44 -0700, Felix Lechner wrote:
> On Mon, Sep 23, 2019 at 1:27 AM Simon McVittie  wrote:
> >
> > To accommodate the 0+deb10u1 convention, I think there should be an
> > exception to this tag, preventing it from being emitted for revision
> > numbers that "are based on" revision 0.
> 
> I struggled with something similar last week. There was some
> discussion on IRC, but no resolution. The relevant code is here:
> 
> 
> https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/changelog.pm#L141-149
> 
> Is your value of 'release' in d/changelog set to buster?

It was for this particular run, but for the majority of my builds it's
'UNRELEASED'.

> Would it be
> better to exempt direct uploads to past releases ($release ne
> 'unstable' && $release ne 'experimental')?

In my opinion: no, because the 0+ convention is equally applicable if
(for example) you have already uploaded foo_1.2.3-1 to experimental
containing changes that are not ready for unstable (perhaps during a
freeze or a transition), and now you want to release foo_1.2.3-0+deb11u1
or foo_1.2.3-0+sid because you have realised that the upstream 1.2.3
release contains an important bug fix that needs to be fast-tracked.

In that scenario, it would be misleading to use foo_1.2.3-1~deb11u1 or
foo_1.2.3-1~sid1, because that would imply that the packaging is based
on foo_1.2.3-1, rather than being branched from foo_1.2.2-7 or whatever
the current version in unstable is.

smcv

Bug#940728: pybuild does not copy all files in setup.py install

[Ole Streicher]

Hi Piotr,


On 23.09.19 17:32, Piotr Ożarowski wrote:
> Hi Ole,
> 
> [Ole Streicher, 2019-09-19]
>> can you explain why you set the severity to "normal"? This problem
>> causes another package to fail completely; this is IMO a reason to have
>> it RC.
> 
> two reasons:
> • this is a problem for one or two packages, few other thousands work fine

my understanding of the severity is that the number of nonfailing
packages does not matter for the severity; what counts is that it now
makes two of them unusable (transitively, more packages are affected).

> • I'm 90% sure this is not a bug in dh-python but in setuptools / distutils / 
> setup.py
>   (I will close this bug once I find some time to prove it)

Would you consider to reassign the bug then? It is still not resolved then.

Best

Ole

Bug#935381: python-pyramid-multiauth: diff for NMU version 0.8.0-1.1

[Andrey Rahmatullin]

Control: tags 935381 + patch
Control: tags 935381 + pending

Dear maintainer,

I've prepared an NMU for python-pyramid-multiauth (versioned as 0.8.0-1.1) and
uploaded it.

Regards.


-- 
WBR, wRAR
diff -Nru python-pyramid-multiauth-0.8.0/debian/changelog python-pyramid-multiauth-0.8.0/debian/changelog
--- python-pyramid-multiauth-0.8.0/debian/changelog	2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/changelog	2019-09-23 20:34:29.0 +0500
@@ -1,3 +1,11 @@
+python-pyramid-multiauth (0.8.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support (Closes: #935381).
+  * Update the priority from extra to optional.
+
+ -- Andrey Rahmatullin   Mon, 23 Sep 2019 20:34:29 +0500
+
 python-pyramid-multiauth (0.8.0-1) unstable; urgency=medium
 
   [ Denis Laxalde ]
diff -Nru python-pyramid-multiauth-0.8.0/debian/control python-pyramid-multiauth-0.8.0/debian/control
--- python-pyramid-multiauth-0.8.0/debian/control	2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/control	2019-09-23 20:32:43.0 +0500
@@ -1,13 +1,10 @@
 Source: python-pyramid-multiauth
 Section: python
-Priority: extra
+Priority: optional
 Maintainer: David Douard 
 Build-Depends:
  debhelper (>= 9),
  dh-python,
- python-all,
- python-setuptools,
- python-pyramid,
  python3-all,
  python3-setuptools,
  python3-pyramid,
@@ -16,16 +13,6 @@
 Vcs-Browser: https://github.com/douardda/pyramid_multiauth
 Vcs-Git: https://github.com/douardda/pyramid_multiauth.git
 
-Package: python-pyramid-multiauth
-Architecture: all
-Depends:
- ${python:Depends},
- ${misc:Depends}
-Description: authentication policy for the Pyramid web framework
- The pyramid_multiauth package provides MultiAuthenticationPolicy: a Pyramid
- authentication policy that proxies to a stack of other IAuthenticationPolicy
- objects, to provide a combined auth solution from individual pieces.
-
 Package: python3-pyramid-multiauth
 Architecture: all
 Depends:
diff -Nru python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install
--- python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install	2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/python3-pyramid-multiauth.install	1970-01-01 05:00:00.0 +0500
@@ -1 +0,0 @@
-usr/lib/python3*
diff -Nru python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install
--- python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install	2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/python-pyramid-multiauth.install	1970-01-01 05:00:00.0 +0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru python-pyramid-multiauth-0.8.0/debian/rules python-pyramid-multiauth-0.8.0/debian/rules
--- python-pyramid-multiauth-0.8.0/debian/rules	2016-04-13 21:09:05.0 +0500
+++ python-pyramid-multiauth-0.8.0/debian/rules	2019-09-23 20:32:48.0 +0500
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


signature.asc
Description: PGP signature

Bug#940728: pybuild does not copy all files in setup.py install

[Piotr Ożarowski]

Hi Ole,

[Ole Streicher, 2019-09-19]
> can you explain why you set the severity to "normal"? This problem
> causes another package to fail completely; this is IMO a reason to have
> it RC.

two reasons:
• this is a problem for one or two packages, few other thousands work fine
• I'm 90% sure this is not a bug in dh-python but in setuptools / distutils / 
setup.py
  (I will close this bug once I find some time to prove it)