Bug#930428: debootstrap should ensure matching _apt uid

[Trek]

On Thu, 20 Jun 2019 22:31:15 +0200
Ansgar Burchardt  wrote:

> If _apt deserves a special solution, I would suggest assigning the
> _apt user a static uid instead of patching debootstrap.

it seems to me the simplest approach, from a technical point of view,
and it's the one I'm using since _apt user was introduced (making sure
uids match)

ciao!

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Xavi Drudis Ferran]

Hello. Maybe you know already (because the problem seems to be lack of 
maintainer). But there is a python-uniconvertor 2.0 that no longer depends on 
python-imaging but on python-pil (python2, I believe)

https://sk1project.net/modules.php?name=Products=uniconvertor=download

They offer source and some .debs for a couple architechtures and Debian 9, but 
I haven't tried them or audited the licenses or anything. 

I suppose it would still require packaging. Unfortunately I don't know
enough about debian policies or about python. I might try to learn, but 
I think Debian is frozen now ? 

Bug#930812: unblock: cargo/0.35.0-2

[Ximin Luo]

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

Please unblock package cargo

rustc 1.34.2 was unblocked in bug #930661 but the bug requestor forgot to file
the corresponding unblock request for cargo version 0.35.0-1. This is the
recommended version of cargo that goes with that rust version.

unblock cargo/0.35.0-2

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#929666: #929666 ITP: conmon -- An OCI container runtime monitor

[Birger Schacht]

Hi,

On 6/21/19 4:06 AM, Dmitry Smirnov wrote:
> Birger, let's move the repository to "debian" group please, shall we?

Feel free to do so- I'm neither a DD nor a DM, so I can't move it there.
I've added you and siretart as maintainers, if thats needed.

cheers,
Birger

Bug#926393: surf: Cannot read local files/ directories: "Error opening file [filename] : Permission denied"

[Giuseppe Bilotta]

Hello Reiner,

On Thu, Jun 20, 2019 at 11:43 AM Reiner Herrmann  wrote:
> On Thu, Jun 20, 2019 at 09:30:59AM +0200, Giuseppe Bilotta wrote:
> > I came across this issue just now. This is an apparmor profile issue,
> > since by default it's configured to prevent access to local files except
> > for a small selection (it even fails to load the corret theme in my
> > case).
> >
> > A temporary workaround until this is fixed is to put apparmor in
> > complain mode for surf (`aa-complain /usr/bin/surf` as root should do
> > it).
>
> Local files are intentionally not allowed to be accessed by the browser,
> expect those needed for it to work properly.

While I appreciate the intent behind this restriction (prevent the
usage of the browser as a remote attach vector), the downsides are too
vast. It effectively prevents the use of that browser to browse/view
local HTML files or SVG images, something which is actually pretty
common. It also prevents explicit (user-controlled) requests to access
local files, e.g. to upload them to a website (attachments to email
with webmail, custom images for forum profiles and whatnot).

I do not think the kind of security that this profile intends to
provide can actually be provided by AppArmor profiles, because they
get too restrictive; non-local access to local files is something that
the browser must protect against in its own code, because the choice
can only be made based on contextual information that is not available
to AppArmor.

> Which theme files does it fail to load?

Here's the full audit log with surf in complain mode when I launch it
from the command-line to view a local HTML file.

[  +0.02] audit: type=1400 audit(1561092652.194:52):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/usr/share/themes/Breeze/gtk-3.20/gtk.css" pid=19839 comm="surf"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[  +0.113718] audit: type=1400 audit(1561092652.306:53):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/.uuid" pid=19839 comm="surf"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.04] audit: type=1400 audit(1561092652.306:54):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/" pid=19839 comm="surf"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.166007] audit: type=1400 audit(1561092652.474:55):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/usr/share/themes/Breeze/gtk-3.20/gtk.css" pid=19847
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000
ouid=0
[  +0.049100] audit: type=1400 audit(1561092652.522:56):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/.uuid" pid=19847
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000
ouid=1000
[  +0.06] audit: type=1400 audit(1561092652.522:57):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/.Fontmatrix/Activated/" pid=19847
comm="WebKitWebProces" requested_mask="r" denied_mask="r" fsuid=1000
ouid=1000
[  +0.043384] audit: type=1400 audit(1561092652.566:58):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/file.html" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.023214] audit: type=1400 audit(1561092652.586:59):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/file.css" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.88] audit: type=1400 audit(1561092652.586:60):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/otherfile.css" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[  +0.000457] audit: type=1400 audit(1561092652.590:61):
apparmor="ALLOWED" operation="open" profile="/usr/bin/surf"
name="/home/user/path/image.png" pid=19848 comm="pool"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000


(Sorry for the line wrap, this is being sent from gmail.)

-- 
Giuseppe "Oblomov" Bilotta

Bug#930811: experimental: Update autopackagetests to drop support for Python 2

[James Page]

Package: python-dogpile.cache
Version: 0.7.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/tests/import,control: Drop Python 2 test as package only
ships Python 3.

Only applies in experimental.

Thanks for considering the patch.


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

Kernel: Linux 5.0.0-15-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-dogpile.cache-0.7.1/debian/tests/control 
python-dogpile.cache-0.7.1/debian/tests/control
--- python-dogpile.cache-0.7.1/debian/tests/control 2019-03-21 
13:29:29.0 +
+++ python-dogpile.cache-0.7.1/debian/tests/control 2019-06-21 
05:55:24.0 +0100
@@ -1,4 +1,3 @@
 Tests: import
 Depends:
- python-dogpile.cache,
  python3-dogpile.cache,
diff -Nru python-dogpile.cache-0.7.1/debian/tests/import 
python-dogpile.cache-0.7.1/debian/tests/import
--- python-dogpile.cache-0.7.1/debian/tests/import  2019-03-21 
13:29:29.0 +
+++ python-dogpile.cache-0.7.1/debian/tests/import  2019-06-21 
05:54:44.0 +0100
@@ -1,4 +1,3 @@
 #!/bin/sh
 set -e
-python -c 'import dogpile.cache'
 python3 -c 'import dogpile.cache'

Bug#930809: sbox-dtc FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: sbox-dtc
Version: 1.11.7-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sbox-dtc fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes sbox-dtc cross buildable. Please consider applying the attached
patch.

Helmut
diff -u sbox-dtc-1.11.7/debian/changelog sbox-dtc-1.11.7/debian/changelog
--- sbox-dtc-1.11.7/debian/changelog
+++ sbox-dtc-1.11.7/debian/changelog
@@ -1,3 +1,10 @@
+sbox-dtc (1.11.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 21 Jun 2019 06:07:00 +0200
+
 sbox-dtc (1.11.7-1) unstable; urgency=medium
 
   * Fixed homepage field (Closes: #655490).
diff -u sbox-dtc-1.11.7/debian/rules sbox-dtc-1.11.7/debian/rules
--- sbox-dtc-1.11.7/debian/rules
+++ sbox-dtc-1.11.7/debian/rules
@@ -11,7 +11,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE)
+   dh_auto_build -- sbox env
touch build-stamp
 
 clean:
@@ -27,8 +27,6 @@
dh_prep 
dh_installdirs
 
-   $(MAKE) sbox
-   $(MAKE) env
install -D -m 4755 sbox debian/sbox-dtc/usr/lib/cgi-bin/sbox
install -D -m 0755 env 
debian/sbox-dtc/usr/share/doc/sbox-dtc/examples/env
install -D -m 0644 debian/lintian/sbox-dtc 
debian/sbox-dtc/usr/share/lintian/overrides/sbox-dtc

Bug#930810: kparts FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: kparts
Version: 5.54.0-1
Tags: pending

kparts fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kparts/commit/f5dd7f4797cf7ca8487cdbf5d8b4e728c6484824
Please close this bug with the next upload to trigger a qa rebuild.

Helmut

Bug#930618: node-terser does not install file mentioned in package.json's main field and fails Error: Cannot find module 'terser'

[Pirate Praveen]

On 2019, ജൂൺ 20 5:08:24 PM IST, Xavier  wrote:
>Hello,
>
>there is something wrong with your patch:
>W: node-terser source: binaries-have-file-conflict node-terser
>uglifyjs.terser usr/lib/nodejs/terser/dist/bundle.js
>
>Your link overrides a regular file

Only node-terser should include this file, uglifyjs.terser already depends on 
node-terser.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#930767: systemd-analyze security mis-detects blacklist-only SystemCallFilter=~@foo

[Trent W. Buck]

Michael Biebl wrote:
> Hi
>
> Am 20.06.19 um 09:57 schrieb Trent W. Buck:
> > Package: systemd
> > Version: 241-5
> > Severity: minor
> > File: /usr/bin/systemd-analyze
> >
> > Below are two units which both block @debug syscalls (confirmed by strace 
> > crashing).
> > systemd-analyze incorrectly claims @debug is allowed in one of them.
> >
> > It seems a "blacklist-only" SystemCallFilter= results in a blacklist in 
> > systemctl show, and systemd-analyze can't understand that?
> > A "whitelist, then blacklist" SystemCallFilter= results in a whitelist in 
> > systemctl show, which systemd-analyze understands.
> >
>
> Could you raise this upstream at
> https://github.com/systemd/systemd/issues and report back with the bug
> number.

I report all bugs to Debian so I don't have to learn how to interact
with non-DFSG upstream bug trackers.  I haven't learnt how to use
github's ticket system, and I probably won't anytime soon.  Sorry.

Bug#930309: ITA: libtomcrypt

[Nicolas Mora]

signature.asc
Description: OpenPGP digital signature

Bug#929666: #929666 ITP: conmon -- An OCI container runtime monitor

[Dmitry Smirnov]

Birger, let's move the repository to "debian" group please, shall we?

  https://salsa.debian.org/debian

Thanks.

-- 
Regards,
 Dmitry Smirnov

---

A wise man proportions his belief to the evidence.
-- David Hume, "An Inquiry Concerning Human Understanding"


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

Bug#930808: libc6: ${PLATFORM} is expanded as haswell instead of x86_64

[Vincent Hobeïka]

Package: libc6
Version: 2.28-10
Severity: important

Dear Maintainer,

It seems ${PLATFORM} is wrongly expanded on x86_64 architectures with
libc6 2.28. This leads to troubles while referencing libraries.

This doesn't seem related to the usage of curly braces.

You can find the reproductions steps below:

$ arch
x86_64

$ strace -ELD_PRELOAD='/sss/$PLATFORM/'  -s300  /bin/cat
execve("/bin/cat", ["/bin/cat"], 0x5607e51d5490 /* 62 vars */) = 0
brk(NULL)   = 0x560cc39d5000
readlink("/proc/self/exe", "/bin/cat", 4096) = 8
openat(AT_FDCWD, "/sss/haswell/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)

$ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat
execve("/bin/cat", ["/bin/cat"], 0x563dc5b51490 /* 62 vars */) = 0
brk(NULL)   = 0x55f8d420d000
readlink("/proc/self/exe", "/bin/cat", 4096) = 8
openat(AT_FDCWD, "/sss/haswell/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)

Feel free to ask me any additionnal information.

Best regards,

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (900, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc1  1:8.3.0-6

Versions of packages libc6 recommends:
ii  libidn2-0  2.0.5-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.71
pn  glibc-doc  
ii  libc-l10n  2.28-10
ii  locales2.28-10

-- debconf information:
  glibc/disable-screensaver:
  glibc/kernel-too-old:
  glibc/restart-failed:
  glibc/upgrade: true
* libraries/restart-without-asking: false
  glibc/kernel-not-supported:
* glibc/restart-services: cups cron

Bug#930807: poppler-utils: pdftoppm "-png -scale-to 1920" generates PNG with 1921 pixels in width

[Anthony Fok]

Package: poppler-utils
Version: 0.71.0-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The current pdftoppm sometimes creates PPM or PNG with a width that is
off-by-one, e.g.:

  $ pdftoppm Lauda_Sion.pdf Lauda_Sion -png -scale-to 1920
  $ file Lauda_Sion_01.png
  Lauda_Sion_01.png: PNG image data, 1921 x 1080, 8-bit colormap, non-interlaced

If I recall correctly, pdftoppm used to create output images with
exactly 1920 pixels in width, so this could be a regression, but my
memory is vague and I haven't done extensive testing yet.

  -scale-to 19200 → 19201
  -scale-to 3840 → 3841
  -scale-to 1920 → 1921
  -scale-to 960 → 961
  -scale-to 480 → 481
  -scale-to 240 → 241
  -scale-to 120 → 121
  -scale-to 60 → 61
  -scale-to 30 → 31
  -scale-to 15 → 16

The PDF file from which I observe this has a page size of 659.52 x 370.98 pts.

I created another 16:9 PDF file with page size of 1152 x 648 pts for
testing, but in this case, pdftoppm generates PNGs with perfect 1920x1080 
dimensions.

Thanks,

Anthony

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages poppler-utils depends on:
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libfreetype6  2.9.1-3
ii  liblcms2-22.9-3
ii  libpoppler82  0.71.0-5
ii  libstdc++68.3.0-7

poppler-utils recommends no packages.

poppler-utils suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl0MGzQACgkQ6iUAtBLF
ms+EVQ//SLszIKIDiAd68lT5Dd2CUjDBUAFo8tFesTsJhfyAV4RwKd6i1dv66ill
eLeBJhxMY2q6sysRQZdX4cE3iDRfTx46xzMkE9F1d8q2jkbgSbVu1p0+Z+ni1kli
/0DX0ZrVwHMSGJjGW905/MAJ2qiCyGZx9ofLj75j+slOJlKJw9Isx9j/PWRPhRKX
G2r8r/fBqY7cpCFwuxGb8tVS2hknaEYQUw9Ytpzgh0n6CUpU5YnL5rZIQPe4leno
9gcaE3KB5EbV/iQeD7AnXMcMC721smP0nlKS8saMdYzEL/T5cknwyyuotYl8pMGZ
3CpAGLxHD0bhMJL8NzKYbBOKocgB16xUKZgGGx4cGWPjnCokA3ro0V13c1CFqyg9
m4yyoosyMFFhQFiJpKRDek6hxp5hnYYletSuNqFa9QcILkjFvr6RpBUL06lVv6tn
rvihZAyXxIiIZg+VJkcG8zwQRAh9DRK4kYUA1W0pLU9O4mV/gzbbus1l1hQnURdj
y7OtLJ3NoZKr/InePKB74UM+JkaTkVIMgNsg1w6XX5B8TqauE8dqzbXoxi1czjij
NSI9JtdGh9BSW+AapQzq3coimECk9LGQXz383g6RJ9CU9OuNvWvsMH5cgTS9977h
RFDh/+Wy956/D1zFL3YRSmhpkDNWmBg4lheC3gqrMd3Nrs2O5Jc=
=TAL/
-END PGP SIGNATURE-

Bug#930806: ITP: urlextractor -- Information gathering and website reconnaissance

[Josue Ortega]

Package: wnpp
Severity: wishlist

* Package name : urlexractor
Version : 0.2.0
Upstream Author : eschultze 
* URL : https://github.com/eschultze/URLextractor
* License : MIT
Description : Information gathering and website reconnaissance
urlextractor gathers information from the specified URL and prints it to STDOUT
The following information is gathered:
 - IP and hosting info like city and country (using FreegeoIP)
 - DNS servers (using dig)
 - ASN, Network range, ISP name (using RISwhois)
 - Load balancer test
 - Whois for abuse mail (using Spamcop)
 - PAC (Proxy Auto Configuration) file
 - Compares hashes to diff code
 - robots.txt (recursively looking for hidden stuff)
 - Source code (looking for passwords and users)
 - External links (frames from other websites)
 - Directory FUZZ (like Dirbuster and Wfuzz - using Dirbuster) directory list)
 - URLvoid API - checks Google page rank, Alexa rank and possible blacklists
 - Provides useful links at other websites to correlate with IP/ASN
 - Option to open ALL results in browser at the end


signature.asc
Description: PGP signature

Bug#930805: dash: Dash strips out newline from multi-line string literal when line starts with an empty $()

[Martin D.]

Package: dash
Version: 0.5.7-4+b1
Severity: normal

Dear Maintainer,

In multi-line string literals, a line which starts with a $()-style
subshell which outputs an empty string will have its trailing newline
stripped. For example, this code:

echo "
$(echo '') hello
$(echo '') world"

will output " hello world", when other shells I've tried
(zsh, bash, ksh) all output:

"
 hello
 world"

I haven't looked at what posix says about this particular issue,
but the behavior of all the other shells looks way more sensible in my
opinion. If they're actually wrong and dash implements posix correctly,
feel free to ignore this issue.

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

Kernel: Linux 3.16.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii  debianutils  4.4+b1
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u10

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#798726: trac: fails to send email with ascii charset when ticket contains utf character

[Lê Quốc Huy]

On Fri, 11 Sep 2015 18:29:16 -0400 Stephen Crowley wrote:
> Package: trac
> Version: 1.0.8+dfsg-1
> Severity: important
> 
> Just make a ticket and put some symbol like → in it. 
> 
> Trac[web_ui] ERROR: Failure sending notification on change to ticket #262: 
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u03bf' in 
> position 11: ordinal not in range(128)
> 
> -- System Information:
> Debian Release: 8.2
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/32 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages trac depends on:
> ii libjs-excanvas 0.r3-3
> ii libjs-jquery 1.7.2+dfsg-3.2
> ii libjs-jquery-timepicker 1.2-1
> ii libjs-jquery-ui 1.10.1+dfsg-1
> ii python 2.7.9-1
> ii python-genshi 0.7-3
> ii python-pkg-resources 5.5.1-1
> ii python-setuptools 5.5.1-1
> pn python:any 
> 
> Versions of packages trac recommends:
> ii apache2 [httpd] 2.4.10-10+deb8u3
> ii python-babel 1.3+dfsg.1-5
> ii python-docutils 0.12+dfsg-1
> ii python-pygments 2.0.1+dfsg-1.1
> ii python-subversion 1.8.10-6+deb8u1
> ii python-tz 2012c+dfsg-0.1
> 
> Versions of packages trac suggests:
> pn libapache2-mod-wsgi 
> pn python-psycopg2 
> pn python-textile 
> ii trac-accountmanager 0.4.3-2
> pn trac-authopenid 
> pn trac-bitten 
> pn trac-bzr 
> pn trac-customfieldadmin 
> ii trac-email2trac 2.8.4-1
> ii trac-graphviz 0.7.5-1
> pn trac-ja-resource 
> ii trac-mastertickets 3.0.2+20111224-2
> ii trac-mercurial 1.0.0.3+hg8df754d9b36a-1.1
> pn trac-spamfilter 
> pn trac-wikiprint 
> pn trac-wikirename 
> ii trac-wysiwyg 0.12.0.3+r10725-1
> ii trac-xmlrpc 1.1.2+r10706-1
> 
> -- no debconf information
> 


Được gửi từ iPhone của tôi

Bug#801821: cwidget: string dialogs/editline should allow to put the cursor at the end of the line

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2015-10-15 00:24 Manuel A. Fernandez Montecelo:

Source: cwidget
Severity: wishlist

::dialog::string() or editline should put the cursor at the end of the line by
default, or provide a way to achieve that.

See aptitude's #613794 for explanation and discussion.


Implemented, marking this bug as +pending.

--
Manuel A. Fernandez Montecelo 

Bug#930271: iw: cannot scan if two cells on 2.4Ghz and 5Gz have same SSID

[Paride Legovini]

Martin Monperrus wrote on 14/06/2019:
> Hi Paride,
> 
> Thanks for your answer. Would you recommend to report it on
> https://bugzilla.kernel.org/?

Hi Martin,

I'd say the bug belongs there, but keep in mind that for your report to
be considered I think you'll be asked to compile the latest version of
the vanilla kernel.

IF your WiFi adapter needs a firmware it may be worth trying to use the
latest version released by the manufacturer.

Paride

Bug#930803: new program: runcached

[Andras Korn]

Package: moreutils
Version: 0.62-1
Severity: wishlist

Hi,

I just wrote this script:
https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
it might be a good addition to moreutils.

It caches the stdout, stderr and exit status of arbitrary commands for a
configurable length of time, returning data from cache on subsequent
invocations if the cache is still fresh.

It currently has semi-esoteric dependencies: it's written in zsh and uses
chpst from the runit package for locking. If you're willing to include the
script I can change it to use flock(1) instead, but I'm not rewriting it in
POSIX sh.

Best regards,

András

-- 
  Want to make  using your computer? hold shift and press '4' four times.

Bug#911884: Info received (Atril fail to zoom for large pdf)

[Andreas Beckmann]

Control: reopen -1

On Thu, 09 May 2019 23:18:50 +0200 =?utf-8?B?UmljaGFyZCBFbGnDocWh?=
 wrote:
> Hi vangelis,
> But bug stays unresolved - zooming more than 175% fails, but there are more 
> zoom levels - 200, 300, 400, 800%.

Thus reopening this bug, which was closed with an invalid version anyway.

Andreas

Bug#930798: radicale: silently falls back to defaults (without authn) when running with config for 1.x under uwsgi

[Jonas Smedegaard]

Hi namesake :-)

Quoting Jonas Schäfer (2019-06-20 21:44:10)
> I upgraded from stretch to buster while having apt-listchanges and 
> apt-listbugs installed. I modified the uwsgi configuration to use 
> python3 instead of python27 (since radicale is now python3 based) and 
> reloaded the uwsgi-emperor.
> 
>* What was the outcome of this action?
> 
> The upgrade passed without any notice from apt-listchanges or 
> apt-listbugs regarding radicale.
> 
> radicale was operating, but it was not performing any authentication; 
> every password was accepted for every user name, opening the server up 
> for denial of service by unauthorized users (by spamming data on it) 
> and possibly opening up access to existing data (if the configuration 
> fits).
> 
>* What outcome did you expect instead?
> 
> I expect either:
> 
> (1) radicale to fail to start and/or operate at all, due to the 
> obviously invalid configuration. This is the case when I run radicale 
> manually from the command line (it already chokes at the `well-known` 
> section, not to mention that there’s no LDAP support anymore).
> 
> (2) a prominent warning via apt-listchanges that the configuration 
> format has changed drastically, that LDAP is not supported anymore, 
> and that attempting to run radicale with an invalid configuration may 
> lead to it running without any authentication at all.
> 
> At this stage in the release cycle, (2) may be the way to go (and is 
> fully sufficient In My Opinion).

Thanks for reporting this issue!

Which exact package version did you upgrade from?

I ask because there was supposed to be a NEWS entry informing about 
major changes.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#928111: [pre-approval] unblock: icu/63.2-1

[GCS]

Control: tags -1 -moreinfo

Hi Paul,

On Tue, Jun 18, 2019 at 7:23 PM Paul Gevers  wrote:
> There are quite a lot of changes in the diff, and only at the end we get
> to the Reiwa support (if I understand the code and comments at all). You
> haven't explained these other changes. If all we are now talking about
> is Reiwa support I will *not* unblock the current version of icu, as it
> introduces changes that are not targeted at fixing that.
 Indeed, there are other changes. Let me go into more details via the
upstream commit list[1] which is on the maint-63 branch (important
bugfixes only for the 63 release).
The 63.1 release happened on Oct 13, 2018 with the last commit of
ICU-20205 (RelativeDateTimeFormatter pt data fix, improved error
handing and test)[2].
The first fix is ICU-20208 (uspoof.cpp function checkImpl should be
static) [3] and I've backported it with ICU-20246 (Fixing another
integer overflow in number parsing) [4] (security issues) to (and
already in) Buster.
Fixes between these commits (ICU-20214 Fix namespace error on Cygwin,
ICU-20209 Fix build failures on Windows and ICU-20240 Fix Windows
build failure) [5] are for Windows only and don't affect us.
Next is a faster operation change with hashtables (ICU-20250 faster
MutableCodePointTrie.build()) [6]. An additional speed change is the
startup regression change (ICU-20250 make UnicodeSet(intprop=value)
faster) [7] that I had to reverse apply (meaning not part of the
source in this unblock request) due to its ABI break.
The next commit is for the Java ICU source [8] (ICU is split in Debian
to src:icu and src:icu4j), ICU-20255 revert to reflection for methods
not yet in Android API thus not part of this unblock request.
Then comes the Japanese era Reiwa support commits [9] (ICU-20536),
these would be very good to have for Buster. Then the version number
update with the IANA tzdata update to 2019a [10] come. The latter is
preprocessed to the source/data/in/icudt63l.dat file.

In general the other changes you see are Windows only related changes.
What I didn't mention is the hashtable speedup fix[6] and the IANA
tzdata 2019a update which is preprocessed to the dat file.
I know there's one more commit [11] (ICU-20558 Fix regression in
DateTimePatternGenerator) but as I haven't seen it before it's also
not in this unblock request (ie, not yet backported). How this should
be handled? Do you need more information for icu-63.2-2 and/or can I
use this fix as well and need to ask you only then for the unblock?

Thanks for consideration,
Laszlo/GCS
[1]  https://github.com/unicode-org/icu/commits/maint/maint-63
[2]  
https://github.com/unicode-org/icu/commit/46895456ad1b6660d17eaeba2c101600ad8d8eb8
[3]  
https://github.com/unicode-org/icu/commit/8baff8f03e07d8e02304d0c888d0bb21ad2eeb01
[4]  
https://github.com/unicode-org/icu/commit/6cbd62e59e30f73b444be89ea71fd74275ac53a4
[5]  
https://github.com/unicode-org/icu/commit/78d61f7cb9ecd98664d134da5909c8cc3dcee5a6
 
https://github.com/unicode-org/icu/commit/fced46c6a9404719482a27a29baa371809a64f37
 
https://github.com/unicode-org/icu/commit/2094a48c20193d8ecee70dc39a18f61bfda41f25
[6]  
https://github.com/unicode-org/icu/commit/38b882fe30e7105e691c0d48d35864724ea72979
[7]  
https://github.com/unicode-org/icu/commit/f3fa0d604ef6527a01dab96f4bfa3c5290127337
[8]  
https://github.com/unicode-org/icu/commit/0af507c4dabe517d9daa621d2d8c59c74b04af59
[9]  
https://github.com/unicode-org/icu/commit/838a14ee42336270260b54e11cd453a94b3c1a2d
 
https://github.com/unicode-org/icu/commit/c948a1ae3132ab7e5af28f3321905dbaf97b0ce4
[10] 
https://github.com/unicode-org/icu/commit/4f715ae124c418a15a3fa4d8fb14f406576a7ee5
[11] 
https://github.com/unicode-org/icu/commit/5df4d7dfd8d77dd16aa3a0b398d50a22f4c85daa

Bug#930801: unblock: rdma-core/22.3-1

[Benjamin Drung]

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

Hi,

rdma-core is maintained by the Linux RDMA group. It follows the Linux
kernel release schedule and concepts. Upstream backports fixes to their
stable branches. We have currently rdma-core 22.1-1 in Debian
unstable/testing. Upstream released 22.3 which contains only bug fixes.

I prepared an updated package 22.3-1 (patch attached). Before uploading
anything, I like to hear your opinion: Is this change okay for buster,
should I wait for the release, or better keep that update out of buster?

unblock rdma-core/22.3-1

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

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

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8310ec6c..db291328 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,7 +65,7 @@ endif()
 set(PACKAGE_NAME "RDMA")
 
 # See Documentation/versioning.md
-set(PACKAGE_VERSION "22.1")
+set(PACKAGE_VERSION "22.3")
 # When this is changed the values in these files need changing too:
 #   debian/control
 #   debian/libibverbs1.symbols
@@ -360,23 +360,23 @@ else()
   set(HAVE_FULL_SYMBOL_VERSIONS 1)
 endif()
 
-if (${NO_PYVERBS})
-  set(CYTHON_EXECUTABLE "")
-else ()
-  # Look for Python. We prefer some variant of python 3 if the system has it.
-  FIND_PACKAGE(PythonInterp 3 QUIET)
-  if (NOT ${PythonInterp_FOUND})
-FIND_PACKAGE(PythonInterp REQUIRED)
-  endif()
-  FIND_PACKAGE(cython)
-endif()
-
 # Look for Python. We prefer some variant of python 3 if the system has it.
 FIND_PACKAGE(PythonInterp 3 QUIET)
-if (NOT ${PythonInterp_FOUND})
+if (PythonInterp_FOUND)
+  # pyverbs can only use python3:
+  if (NO_PYVERBS)
+set(CYTHON_EXECUTABLE "")
+  else()
+FIND_PACKAGE(cython)
+  endif()
+else()
+  # But we still must have python (be it 2) for the build process:
   FIND_PACKAGE(PythonInterp REQUIRED)
+  set(CYTHON_EXECUTABLE "")
 endif()
+
 # A cython & python-devel installation that matches our selected interpreter.
+
 if (CYTHON_EXECUTABLE)
  # cmake has really bad logic here, if PythonIterp has been run it tries to
  # find a matching -devel installation but will happily return a non-matching
diff --git a/buildlib/RDMA_BuildType.cmake b/buildlib/RDMA_BuildType.cmake
index 0951edad..17206f51 100644
--- a/buildlib/RDMA_BuildType.cmake
+++ b/buildlib/RDMA_BuildType.cmake
@@ -8,7 +8,7 @@ function(RDMA_BuildType)
   # in performance contexts it doesn't make much sense to have the default 
build
   # turn off the optimizer.
   if(NOT CMAKE_BUILD_TYPE)
-set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE String
+ set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING
   "Options are ${build_types}"
   FORCE
   )
diff --git a/buildlib/cbuild b/buildlib/cbuild
index 9ced0de6..15095d0c 100755
--- a/buildlib/cbuild
+++ b/buildlib/cbuild
@@ -641,10 +641,6 @@ def run_deb_build(args,env):
 "-e","DEB_BUILD_OPTIONS=parallel=%u"%(multiprocessing.cpu_count()),
 ];
 
-if not env.build_pyverbs:
-opts.append("-e");
-opts.append("EXTRA_CMAKE_FLAGS=%s"%(' '.join(["-DNO_PYVERBS=1"])));
-
 # Create a go.py that will let us run the compilation as the user and
 # then switch to root only for the packaging step.
 with open(os.path.join(tmpdir,"go.py"),"w") as F:
diff --git a/buildlib/check-build b/buildlib/check-build
index 5ae0cc1c..348b0590 100755
--- a/buildlib/check-build
+++ b/buildlib/check-build
@@ -14,6 +14,7 @@ import copy
 import shlex
 import pipes
 from contextlib import contextmanager;
+from distutils.version import LooseVersion;
 
 def get_src_dir():
 """Get the source directory using git"""
@@ -106,7 +107,7 @@ def check_lib_symver(args,fn):
 private,args.PACKAGE_VERSION));
 
 syms = list(syms - private);
-syms.sort(key=lambda x:re.split('[._]',x));
+syms.sort(key=LooseVersion)
 if newest_symver != syms[-1]:
 raise ValueError("Symbol version %r implied by filename %r not the 
newest in ELF (%r)"%(
 newest_symver,fn,syms));
diff --git a/buildlib/package-build-test b/buildlib/package-build-test
index 46a1cf6f..29c17838 100755
--- a/buildlib/package-build-test
+++ b/buildlib/package-build-test
@@ -11,7 +11,7 @@ if [ -e "/.dockerenv" ] || (grep -q docker /proc/self/cgroup 
&>/dev/null); then
exit 0
 fi
 
-for OS in centos7 tumbleweed
+for OS in centos7 leap
 do
echo
echo "Checking package build for ${OS} "
diff --git a/debian/changelog b/debian/changelog
index 1b67953d..9f805206 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+rdma-core (22.3-1) unstable; 

Bug#930428: debootstrap should ensure matching _apt uid

[Ansgar Burchardt]

Philipp Kern writes:
> 20/06/2019 20:22, Ansgar Burchardt wrote:
>> You look up which uid the _apt user inside the chroot has and use that.
>
> Yeah, but that scales poorly if you have a centralized firewall
> policy. It means that you need to maintain dynamic rules. I know it's
> possible and you can dedicate a chain to it. At the same time I think
> this problem is actually common enough that it deserves a solution.

If _apt deserves a special solution, I would suggest assigning the _apt
user a static uid instead of patching debootstrap.

Ansgar

Bug#930800: gdm3: Can't switch user

[Vipul]

Package: gdm3
Version: 3.22.3-3+deb9u2
Severity: normal

Dear Maintainer,

I can't switch user by clicking switch user option present in status menu. A
window is opened and asking for password of same user from which I want to
switch instead of opening list users (which happens normally). And when I
clicked on "Login as another user" it pop-up a lock screen. This is not a
consistent bug means I can't reproduce it whenever I want to and resolved by
rebooting the system. I've switched user many time in same session before
facing this issue and this is happening fourth or fifth times in last 3 weeks.


Output of syslog:

Jun 20 18:38:58 debian gdm3: gdm_session_set_environment_variable: assertion
'value != NULL' failed
Jun 20 18:38:59 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: Could not get session id for session. Check that logind is properly
installed and pam_systemd is getting used at login.
Jun 20 18:38:59 debian gnome-session-binary[18803]: WARNING: Could not get
session id for session. Check that logind is properly installed and pam_systemd
is getting used at login.
Jun 20 18:39:00 debian systemd[1]: Starting Clean php session files...
Jun 20 18:39:00 debian systemd[1]: Started Clean php session files.
Jun 20 18:39:01 debian gnome-shell[18813]: Unable to initialize Clutter: Unable
to open display. You have to set the DISPLAY environment variable, or use the
--display command line argument
Jun 20 18:39:01 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-session-binary[18803]: WARNING: App
'org.gnome.Shell.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-shell[18865]: Unable to initialize Clutter: Unable
to open display. You have to set the DISPLAY environment variable, or use the
--display command line argument
Jun 20 18:39:01 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
Jun 20 18:39:01 debian gnome-session-binary[18803]: WARNING: App
'org.gnome.Shell.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-session-binary[18803]: WARNING: App
'org.gnome.Shell.desktop' respawning too quickly
Jun 20 18:39:01 debian gnome-session-binary[18803]: Unrecoverable failure in
required component org.gnome.Shell.desktop
Jun 20 18:39:01 debian gnome-session[18803]: Unable to init server: Could not
connect: Connection refused
Jun 20 18:39:01 debian kernel: [193975.401003] gnome-session-f[18868]: segfault
at 0 ip 7f5390052e19 sp 7ffde803af80 error 4 in
libgtk-3.so.0.2200.11[7f538fd7+70]
Jun 20 18:39:01 debian gnome-settings-[18869]: Unable to initialize GTK+
Jun 20 18:39:01 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-session-binary[18803]: WARNING: App 'gnome-
settings-daemon.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-settings-[18872]: Unable to initialize GTK+
Jun 20 18:39:01 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: App 'gnome-settings-daemon.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-session[18803]: gnome-session-binary[18803]:
WARNING: App 'gnome-settings-daemon.desktop' respawning too quickly
Jun 20 18:39:01 debian gnome-session-binary[18803]: WARNING: App 'gnome-
settings-daemon.desktop' exited with code 1
Jun 20 18:39:01 debian gnome-session-binary[18803]: Unrecoverable failure in
required component gnome-settings-daemon.desktop
Jun 20 18:39:01 debian gnome-session-binary[18803]: WARNING: App 'gnome-
settings-daemon.desktop' respawning too quickly
Jun 20 18:39:01 debian gnome-session[18803]: Unable to init server: Could not
connect: Connection refused
Jun 20 18:39:01 debian kernel: [193975.450670] gnome-session-f[18875]: segfault
at 0 ip 7fd8fd8b4e19 sp 7ffd11f086e0 error 4 in
libgtk-3.so.0.2200.11[7fd8fd5d2000+70]
Jun 20 18:39:01 debian gnome-session-binary[18803]: Entering running state
Jun 20 18:39:01 debian gdm3: Child process -18801 was already dead.
Jun 20 18:39:01 debian CRON[18878]: (root) CMD (  [ -x
/usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then
/usr/lib/php/sessionclean; fi)
Jun 20 18:39:02 debian dbus[774]: [system] Activating via systemd: service
name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Jun 20 18:39:02 debian systemd[1]: Starting Hostname Service...
Jun 20 18:39:02 debian dbus[774]: [system] Successfully activated service
'org.freedesktop.hostname1'
Jun 20 18:39:02 debian systemd[1]: Started Hostname Service.
Jun 20 18:39:02 debian gnome-shell[2554]: JS LOG: [impatience] enabled
Jun 20 18:39:02 debian gnome-shell[2554]: JS LOG: [impatience] enabled
Jun 20 18:39:02 debian gnome-shell[2554]: JS LOG: [impatience] setting new

Bug#930693: ksh: previous versions have the info

[Boyuan Yang]

Control: severity -1 important
Control: fixed -1 2020.0.0~alpha1-1~exp1

在 2019-06-18二的 17:30 -0400，Greg Wooledge写道：
> Having ksh removed from buster is definitely not my preferred outcome.
> Getting one line added to the copyright file would be ideal, but if
> that's not allowed, then I can live with "fixed after buster".

Doing so accordingly.

Thanks,
Boyuan Yang


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

Bug#930799: unblock: postgresql-11/11.4-1

[Christoph Berg]

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

Please unblock package postgresql-11. The new version fixes
CVE-2019-10164.

debian/* diff:

diff --git a/debian/changelog b/debian/changelog
index d9bedcb..2f7e899 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+postgresql-11 (11.4-1) unstable; urgency=medium
+
+  * New upstream version.
++ Fix buffer-overflow hazards in SCRAM verifier parsing
+  (Jonathan Katz, Heikki Linnakangas, Michael Paquier)
+
+  Any authenticated user could cause a stack-based buffer overflow by
+  changing their own password to a purpose-crafted value.  In addition to
+  the ability to crash the PostgreSQL server, this could suffice for
+  executing arbitrary code as the PostgreSQL operating system account.
+
+  A similar overflow hazard existed in libpq, which could allow a rogue
+  server to crash a client or perhaps execute arbitrary code as the
+  client's operating system account.
+
+  The PostgreSQL Project thanks Alexander Lakhin for reporting this
+  problem.  (CVE-2019-10164)
+
+ -- Christoph Berg   Tue, 18 Jun 2019 11:03:14 +0200
+
 postgresql-11 (11.3-1) unstable; urgency=medium

   * New upstream version.

unblock postgresql-11/11.4-1

Christoph

Bug#930798: radicale: silently falls back to defaults (without authn) when running with config for 1.x under uwsgi

[Jonas Schäfer]

Package: radicale
Version: 2.1.11-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I have a stretch-based radicale installation running under uwsgi with
the attached uwsgi configuration. Under stretch, everything is
operating correctly and radicale authenticates against the LDAP
service specified in the configuration.

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

I upgraded from stretch to buster while having apt-listchanges and
apt-listbugs installed. I modified the uwsgi configuration to use
python3 instead of python27 (since radicale is now python3 based) and
reloaded the uwsgi-emperor.

   * What was the outcome of this action?

The upgrade passed without any notice from apt-listchanges or
apt-listbugs regarding radicale.

radicale was operating, but it was not performing any authentication;
every password was accepted for every user name, opening the server up
for denial of service by unauthorized users (by spamming data on it)
and possibly opening up access to existing data (if the configuration
fits).

   * What outcome did you expect instead?

I expect either:

(1) radicale to fail to start and/or operate at all, due to the
obviously invalid configuration. This is the case when I run radicale
manually from the command line (it already chokes at the `well-known`
section, not to mention that there’s no LDAP support anymore).

(2) a prominent warning via apt-listchanges that the configuration
format has changed drastically, that LDAP is not supported anymore, and
that attempting to run radicale with an invalid configuration may lead
to it running without any authentication at all.

At this stage in the release cycle, (2) may be the way to go (and is fully
sufficient In My Opinion).


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

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

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  python3  3.7.3-1
ii  python3-radicale 2.1.11-6

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
pn  apache2 
pn  apache2-utils   
pn  libapache2-mod-proxy-uwsgi  
pn  python3-bcrypt  
pn  python3-passlib 
pn  uwsgi   
ii  uwsgi-plugin-python32.0.18-1

-- Configuration Files:
/etc/radicale/config changed:
[encoding]
request = utf-8
stock = utf-8
[well-known]
caldav = /
carddav = /
[auth]
type = LDAP
ldap_url = ldap://192.168.10.1/
ldap_base = ou=Account,dc=zombofant,dc=net
ldap_attribute = uid
ldap_filter = (objectClass=inetOrgPerson)
[storage]
type = multifilesystem
filesystem_folder = /var/lib/radicale/collectionsfnord
[rights]
type = from_file
file = /etc/radicale/rights

/etc/uwsgi-emperor/vassals/radicale.ini
[uwsgi]
http-socket = 0.0.0.0:9001
processes = 1
threads = 1
auto-procname = true
procname-prefix-spaced = [radicale]

harakiri = 30

need-plugin = python27
wsgi-file = /usr/share/radicale/radicale.wsgi
enable-threads = true
offload-threads = 1

-- no debconf information

Bug#916310: New maintainers

[William Desportes]

Hello everyone,

At https://salsa.debian.org/phpmyadmin-team/phpmyadmin/project_members
new members have joined the team and a new version is available
(4.9.0.1) : https://tracker.debian.org/action-items/776413

I just wanted to keep you updated and to let you know that some work is
being done to repair the package (patches and new versions..).

You can browse https://salsa.debian.org/groups/phpmyadmin-team/-/issues
to see what is going on and follow the progress.


I also joined the team https://salsa.debian.org/phpmyadmin-team as a
phpMyAdmin team member.

Regards,

William Desportes




signature.asc
Description: OpenPGP digital signature

Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

[Samuel Thibault]

Control: tags -1 + buster-ignore

Hello,

Holger Wansing, le jeu. 20 juin 2019 10:31:39 +0200, a ecrit:
> ButterflyOfFire  wrote:
> > I think it is okay for those diacritics.
> 
> I have uploaded that fix now.

Thanks!

> Leaving this bug open as a reminder for the "real" problem inside of gtk (?)

Tagging accordingly.

To gtk+2.0 maintainers: the debian installer is getting hung inside the
graphical debconf (and not in the textual debconf) when trying to make
gtk+2.0 display

"لاحقاً"

and we have replaced it with 

"لاحقا"

as a workaround for Buster, but we'll have to fix this bug eventually.

Samuel

Bug#930797: unblock: xen/4.11.1+92-g6c33308a8d-1

[Hans van Kranenburg]

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

Please unblock package src:xen

Hi release team,

Yesterday we uploaded a security update for Xen. This update also
contains the mitigations for Microarchitectural Data Sampling.

The upstream source is forwarded from commit 87f51bf366 to commit
6c33308a8d:
https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;hp=87f51bf366;h=6c33308a8d

There are no further packaging changes (except for the changelog, of
course):

 >8 

xen (4.11.1+92-g6c33308a8d-1) unstable; urgency=high

  * Update to new upstream version 4.11.1+92-g6c33308a8d, which also
contains the following security fixes:
- Fix: grant table transfer issues on large hosts
  XSA-284 (no CVE yet) (Closes: #929991)
- Fix: race with pass-through device hotplug
  XSA-285 (no CVE yet) (Closes: #929998)
- Fix: x86: steal_page violates page_struct access discipline
  XSA-287 (no CVE yet) (Closes: #930001)
- Fix: x86: Inconsistent PV IOMMU discipline
  XSA-288 (no CVE yet) (Closes: #929994)
- Fix: missing preemption in x86 PV page table unvalidation
  XSA-290 (no CVE yet) (Closes: #929996)
- Fix: x86/PV: page type reference counting issue with failed IOMMU
update
  XSA-291 (no CVE yet) (Closes: #929995)
- Fix: x86: insufficient TLB flushing when using PCID
  XSA-292 (no CVE yet) (Closes: #929993)
- Fix: x86: PV kernel context switch corruption
  XSA-293 (no CVE yet) (Closes: #92)
- Fix: x86 shadow: Insufficient TLB flushing when using PCID
  XSA-294 (no CVE yet) (Closes: #929992)
- Fix: Microarchitectural Data Sampling speculative side channel
  XSA-297 CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091
  (Closes: #929129)
  * Note that the fixes for XSA-297 will only have effect when also loading
updated cpu microcode with MD_CLEAR functionality. When using the
intel-microcode package to include microcode in the dom0 initrd, it
has to
be loaded by Xen. Please refer to the hypervisor command line
documentation about the 'ucode=scan' option.
  * Fixes for XSA-295 "Unlimited Arm Atomics Operations" will be added
in the
next upload.

 -- Hans van Kranenburg   Tue, 18 Jun 2019 09:50:19 +0200

 >8 

We prefer to keep releasing from the upstream stable release branches,
because:

(i) upstream only put bugfixes and security fixes on their stable
branches (ii) trying to assemble our own subset of the patches is
riskier than taking upstream's collection (iii) the upstream stable
release branch has undergone extensive testing, which we cannot repeat
in Debian.

The binary packages built from src:xen are:

libxencall1
libxencall1-dbgsym
libxen-dev
libxendevicemodel1
libxendevicemodel1-dbgsym
libxenevtchn1
libxenevtchn1-dbgsym
libxenforeignmemory1
libxenforeignmemory1-dbgsym
libxengnttab1
libxengnttab1-dbgsym
libxenmisc4.11
libxenmisc4.11-dbgsym
libxenstore3.0
libxenstore3.0-dbgsym
libxentoolcore1
libxentoolcore1-dbgsym
libxentoollog1
libxentoollog1-dbgsym
xen-doc
xen-hypervisor-4.11-amd64
xen-hypervisor-common
xenstore-utils
xenstore-utils-dbgsym
xen-system-amd64
xen-utils-4.11
xen-utils-4.11-dbgsym
xen-utils-common
xen-utils-common-dbgsym

The source debdiff is attached for sake of completeness.

Please unblock.

Thanks a lot,
Hans van Kranenburg
Debian Xen Team



debdiff_xen_4.11.1+26-g87f51bf366-3_xen_4.11.1+92-g6c33308a8d-1.txt.gz
Description: application/gzip

Bug#930428: debootstrap should ensure matching _apt uid

[Philipp Kern]

On 20/06/2019 09:50, Ansgar Burchardt wrote:

Ansgar Burchardt writes:

(I don't maintain debootstrap.)

I don't think it is a good idea to require debootstrap to know about
such details.

For limiting network access, I would recommend instead using network
namespaces (to only provide limited network access for all processes)
and/or user namespaces (if filtering for single UIDs is really needed).
These do not require any uids to match between in- and outside.


And sadly the submitter's address bounced my mail as the mail provider
the submitter uses cannot parse RFC-5321 mail addresses correctly.


Well, you can use -submitter@ if you already know that your domain is 
problematic. Even re-reading the RFC I'm not sure why that's a bug. RFC 
5321 references RFC 1035's definition of the label, which specifies that 
a  needs to be first in the label. I didn't immediately find 
anything updating that part of RFC 1035. RFC 2181 also specifies that 
applications can impose additional restrictions on top of labels.


I'm happy to file an internal bug report if there is actually supporting 
documentation rather than just trying out the boundaries of 
deliverability. (Where I mostly wish you good luck. It's not a fight I 
want to have, which is also why I mostly stopped using my @debian.org 
address.)


Kind regards
Philipp Kern

Bug#930428: debootstrap should ensure matching _apt uid

[Philipp Kern]

On 20/06/2019 20:22, Ansgar Burchardt wrote:

Trek writes:

Ansgar Burchardt wrote:

For limiting network access, I would recommend instead using network
namespaces (to only provide limited network access for all processes)
and/or user namespaces (if filtering for single UIDs is really
needed). These do not require any uids to match between in- and
outside.

filtering out the root user is a pretty common security practice and
setting an iptables rule on uids is simple for system administrators

So you don't run sshd (requires root with network access)?  That seems
rather uncommon to me.


There is a difference between running an sshd that only listens and 
allowing outbound connections as root, though. But that's a tangent.



using namespaces, how can you block any user but not the _apt user if it
is not already created?

You look up which uid the _apt user inside the chroot has and use that.


Yeah, but that scales poorly if you have a centralized firewall policy. 
It means that you need to maintain dynamic rules. I know it's possible 
and you can dedicate a chain to it. At the same time I think this 
problem is actually common enough that it deserves a solution.



P.S.: the patch seems ok to me, I don't like hard-conding the _apt user
line in /etc/passwd, as apt postinst uses adduser, but it's not clear
to me when adduser is installed during debootstrap

You cannot use `adduser` as debootstrap might install binaries you
cannot execute (in the first stage).

But the effects of the patch are different from calling adduser, for
example the _apt user it creates has no entry in /etc/shadow.  Such
inconsistencies are not good.


Yeah, that's certainly not desirable. But there's also a limited amount 
of places (like /etc/shadow) that need to be touched in addition.


Kind regards
Philipp Kern

Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1

[Sébastien Béhuret]

Package: hdparm
Version: 9.58+ds-1
Severity: serious

Dear Maintainers,

In this version of hdparm, a new option 'force_spindown_time' was
introduced to set the spindown time for disks that don't support APM.
This option is supposed to translate to hdparm -S, similarly to the
original option 'spindown_time'.

hdparm package comes with 3 main scripts:

1) /usr/lib/pm-utils/power.d/95hdparm-apm
This script will translate 'force_spindown_time' to hdparm -S and apply the
option even if APM was not detected.
This is the desired behavior.

2) /etc/apm/event.d/20hdparm
This script will ignore /etc/hdparm.conf and apply hard-coded defaults
instead.
This behavior is unexpected.
Expected/Desired behavior: Read /etc/hdparm.conf and apply relevant options.

3) /lib/hdparm/hdparm-functions (sourced from /lib/udev/hdparm, which is
invoked by udev rule /lib/udev/rules.d/85-hdparm.rules)
- 'force_spindown_time' is buggy because it is not converted back to -S,
which leads to a syntax error during hdparm execution (e.g. hdparm
force_spindown_time$VALUE instead of hdparm -S$VALUE).
- Both options 'spindown_time' and 'force_spindown_time' are processed even
if APM is not supported. From the comments in the configuration file
(/etc/hdparm.conf), it is understood that 'spindown_time' will be applied
for APM disks only and 'force_spindown_time' for all disks (or possibly for
non-APM disks only).
- The scripts will also apply hard-coded defaults for -S and -B if APM was
detected. The hard-coded defaults differ from those used in
/etc/apm/event.d/20hdparm, leading to inconsistent behavior.

4) Additional issues with non-APM disks:
- Manually invoking hdparm -S$VALUE /dev/sdx is simply ignored even though
hdparm executes successfully. The disks do not spin down after the time
delay when there was no access.
- Manually invoking hdparm -y /dev/sdx will spin down the disks
immediately. The disks will not wake up unless they are accessed, which is
the expected behavior.

These were all working fine in hdparm 9.51+ds-1+deb9u1, which is the
current version in stretch.

In short, it is currently impossible to obtain a consistent and working
configuration for non-APM disks.

Many thanks and regards,
Sebastien Behuret

Bug#930795: unblock: ruby-airbrussh/1.3.2-1

[Samuel Henrique]

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

Hello,

I'm asking for the unblock of ruby-airbrussh
because a critical bug was solved in the last upload.

The bug is related to the package throwing an exception when dealing with
non UTF-8 characters coming from SSH.

I decided to upload the latest release instead of patching the previous
release because the only functionality change of the latest release is this
one, all the other changes can't possibly affect the package, and in this
case it's simpler to have the latest release then to patch it and possibly
induce the users to think that this problem is not fixed:

* Files changed that fix this problem:
  - lib/airbrussh/console.rb

* Other files changed, not needed to fix the problem, can't break anything
and makes the package better:
  - test/airbrussh/console_test.rb (it's a new test case for this problem)

* Other files changed, not needed to fix the problem, can't break anything
and does not make any difference on the package:
  - appveyor.yml
  - CHANGELOG.md
  - lib/airbrussh/version.rb
  - LICENSE.txt
  - .travis.yml
As you can see, all of the files in this case are metadata files.

I didn't open a RC bug on BTS because I'm assuming it's not necessary as we
already have the upstream one and the fix is already on Unstable.

This is the bug that was fixed in this new release:
https://github.com/mattbrictson/airbrussh/issues/120
PR + some discussion:
https://github.com/mattbrictson/airbrussh/pull/121

Special attention to the fact that the bug was noticed while using
capistrano, which depends on this package and was the only reason I
packaged it.

Thanks,

-- 
Samuel Henrique 


ruby-airbrussh.debdiff
Description: Binary data

Bug#929564: gatb-core-testdata: broken symlink: /usr/share/doc/gatb-core/test/gatb-core-cppunit -> ../../../../lib/gatb-core/gatb-core-cppunit

[Andreas Tille]

On Thu, Jun 20, 2019 at 03:30:59PM +0200, Andreas Beckmann wrote:
> On 20/06/2019 07.16, Andreas Tille wrote:
> > That's actually quite strange.  In local builds using pbuilder the file
> > /usr/lib/gatb-core/gatb-core-cppunit is created and part of the package
> 
> have you tried --binary-arch/--binary-indep builds, too?

I've build using

dpkg-buildpackage -b

which builds correctly including /usr/lib/gatb-core/gatb-core-cppunit.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#820597: Devuan ... let's remove such reference

[Jorge]

On Mon, 18 Apr 2016 16:49:48 +0200 Raphael Hertzog  
wrote:

> On Mon, 11 Apr 2016, Roland Mas wrote:
> > I agree. I probably wouldn't have added it if the question arose
> > today (I still don't particularly like the concept, and I'm even more
> > unimpressed by the lack of release). But since the text is already
> > written and the project is alive, I see no reason to actively 
remove it.

>
> Thanks. So I suggest that we drop it for the stretch version of the book
> if the situation does not improve with a release until then.
>
> What about the other distributions suggested by Osamu?
>
> - Trisquel
> - SteamOS
> - Skolelinux
>
> I think it makes sense to document SteamOS because it's a big 
reference in

> the gaming world.
>
> Trisquel possibly to please the Free Software purists... but I'm not
> convinced.
>
> Skolelinux is Debian-Edu and is thus not strictly a derivative but a
> sub-project covered in chapter 1 already.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>
>


I wouldn't add Trisquel, because it's based on Ubuntu. Yes, ultimately, 
an Ubuntu derivative is a Debian derivative, but do we really want to 
add those? PureOS is a FSF-supported Debian derivative, so I plan to add 
that one to fill that free software purist lack.

Bug#930428: debootstrap should ensure matching _apt uid

[Ansgar Burchardt]

Trek writes:
> Ansgar Burchardt wrote:
>> For limiting network access, I would recommend instead using network
>> namespaces (to only provide limited network access for all processes)
>> and/or user namespaces (if filtering for single UIDs is really
>> needed). These do not require any uids to match between in- and
>> outside.
>
> filtering out the root user is a pretty common security practice and
> setting an iptables rule on uids is simple for system administrators

So you don't run sshd (requires root with network access)?  That seems
rather uncommon to me.

> using namespaces, how can you block any user but not the _apt user if it
> is not already created?

You look up which uid the _apt user inside the chroot has and use that.

> P.S.: the patch seems ok to me, I don't like hard-conding the _apt user
> line in /etc/passwd, as apt postinst uses adduser, but it's not clear
> to me when adduser is installed during debootstrap

You cannot use `adduser` as debootstrap might install binaries you
cannot execute (in the first stage).

But the effects of the patch are different from calling adduser, for
example the _apt user it creates has no entry in /etc/shadow.  Such
inconsistencies are not good.

Ansgar

Bug#930794: unblock: intel-microcode/3.20190618.1

[Henrique de Moraes Holschuh]

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

Please unblock package intel-microcode

This is an update that adds the MDS mitigations for Sandybridge server
and HEDT (Core-X).  Other than those two updated microcode files, there
are just changes to text files.

It has been the subject of a security update (DSA 4447-2, and soon DLA
1789-2), please refer to

https://security-tracker.debian.org/tracker/CVE-2019-11091

for details.

diff attached (with the microcode blob changes removed for clarity).

diffstat (git, ignores rename of symlink):
 changelog|7 +++
 debian/changelog |  106 +--
 intel-ucode/06-2d-06 |binary
 intel-ucode/06-2d-07 |binary
 releasenote  |   46 ++
 5 files changed, 74 insertions(+), 85 deletions(-)


unblock intel-microcode/3.20190618.1

Thank you

-- 
  Henrique Holschuh
diff --git a/changelog b/changelog
index b6f59a6..f3579cf 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+2019-06-18:
+  * Implements MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223
+CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
+  * Updated Microcodes:
+sig 0x000206d6, pf_mask 0x6d, 2019-05-21, rev 0x061f, size 18432
+sig 0x000206d7, pf_mask 0x6d, 2019-05-21, rev 0x0718, size 19456
+
 2019-05-14:
   * Implements MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223
 CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
diff --git a/debian/changelog b/debian/changelog
index f7c67ce..ac6bfe1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,50 +1,68 @@
+intel-microcode (3.20190618.1) unstable; urgency=medium
+
+  * New upstream microcode datafile 20190618
++ SECURITY UPDATE
+  Implements MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223
+  CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
+  for Sandybridge server and Core-X processors
++ Updated Microcodes:
+  sig 0x000206d6, pf_mask 0x6d, 2019-05-21, rev 0x061f, size 18432
+  sig 0x000206d7, pf_mask 0x6d, 2019-05-21, rev 0x0718, size 19456
+  * Add some missing (minor) changelog entries to 3.20190514.1
+  * Reformat 3.20190514.1 changelog entry to match rest of changelog
+
+ -- Henrique de Moraes Holschuh   Wed, 19 Jun 2019 09:05:54 
-0300
+
 intel-microcode (3.20190514.1) unstable; urgency=high
 
   * New upstream microcode datafile 20190514
-  * SECURITY UPDATE
-Implements MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223
-CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
-  * New Microcodes:
-sig 0x00030678, pf_mask 0x02, 2019-04-22, rev 0x0838, size 52224
-sig 0x00030678, pf_mask 0x0c, 2019-04-22, rev 0x0838, size 52224
-sig 0x00030679, pf_mask 0x0f, 2019-04-23, rev 0x090c, size 52224
-sig 0x000406c3, pf_mask 0x01, 2019-04-23, rev 0x0368, size 69632
-sig 0x000406c4, pf_mask 0x01, 2019-04-23, rev 0x0411, size 68608
-sig 0x00050657, pf_mask 0xbf, 2019-02-27, rev 0x521, size 47104
-  * Updated Microcodes:
-sig 0x000206a7, pf_mask 0x12, 2019-02-17, rev 0x002f, size 12288
-sig 0x000306a9, pf_mask 0x12, 2019-02-13, rev 0x0021, size 14336
-sig 0x000306c3, pf_mask 0x32, 2019-02-26, rev 0x0027, size 23552
-sig 0x000306d4, pf_mask 0xc0, 2019-03-07, rev 0x002d, size 19456
-sig 0x000306e4, pf_mask 0xed, 2019-03-14, rev 0x042e, size 16384
-sig 0x000306e7, pf_mask 0xed, 2019-03-14, rev 0x0715, size 17408
-sig 0x000306f2, pf_mask 0x6f, 2019-03-01, rev 0x0043, size 34816
-sig 0x000306f4, pf_mask 0x80, 2019-03-01, rev 0x0014, size 18432
-sig 0x00040651, pf_mask 0x72, 2019-02-26, rev 0x0025, size 21504
-sig 0x00040661, pf_mask 0x32, 2019-02-26, rev 0x001b, size 25600
-sig 0x00040671, pf_mask 0x22, 2019-03-07, rev 0x0020, size 14336
-sig 0x000406e3, pf_mask 0xc0, 2019-04-01, rev 0x00cc, size 100352
-sig 0x000406f1, pf_mask 0xef, 2019-03-02, rev 0xb36, size 30720
-sig 0x00050654, pf_mask 0xb7, 2019-04-02, rev 0x25e, size 32768
-sig 0x00050662, pf_mask 0x10, 2019-03-23, rev 0x001a, size 32768
-sig 0x00050663, pf_mask 0x10, 2019-03-23, rev 0x717, size 24576
-sig 0x00050664, pf_mask 0x10, 2019-03-23, rev 0xf15, size 23552
-sig 0x00050665, pf_mask 0x10, 2019-03-23, rev 0xe0d, size 19456
-sig 0x000506c9, pf_mask 0x03, 2019-01-15, rev 0x0038, size 17408
-sig 0x000506ca, pf_mask 0x03, 2019-03-01, rev 0x0016, size 15360
-sig 0x000506e3, pf_mask 0x36, 2019-04-01, rev 0x00cc, size 100352
-sig 0x000506f1, pf_mask 0x01, 2019-03-21, rev 0x002e, size 11264
-sig 0x000706a1, pf_mask 0x01, 2019-01-02, rev 0x002e, size 73728
-sig 0x000806e9, pf_mask 0x10, 2019-04-01, rev 0x00b4, size 98304
-sig 0x000806e9, pf_mask 0xc0, 2019-04-01, rev 0x00b4, size 99328
-sig 0x000806ea, pf_mask 0xc0, 2019-04-01, rev 0x00b4, size 99328
-sig 0x000806eb, 

Bug#930793: openssl: libssl1.1 uses unguarded debconf prompt for a question it does not ship

[Dimitri John Ledkov]

Package: openssl
Version: 1.1.1b-2ubuntu1
Severity: normal

Dear Maintainer,

libssl1.1 postinst queries unguarded for the following template:

db_get libraries/restart-without-asking

However unfortunate people who have have /var/cache/debconf removed,
will at this point get error code 10 from db_get for template not
found and libssl1.1 will fail to configure. As per debconf-devel
guidance shared templates like these should be copied into each
package that uses them.

Please copy libraries/restart-without-asking template from glibc into
openssl package.

Regards,

Dimitri.

Bug#930792: openssl: libssl1.1 does not restart services on upgrade

[Dimitri John Ledkov]

Package: openssl
Version: 1.1.1
Severity: normal

Dear Maintainer,

libssl1.1.postinst did not bump the version check for services
restart. And services do need to be restarted when upgrading from
1.1.0 to 1.1.1* series.

Plese update the postinst to trigger services restart when upgrading
from pre-1.1.1 series.

Regards,

Dimitri.

Bug#930790: net-acct FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: net-acct
Version: 0.71-9.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

net-acct fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - makes net-acct cross buildable. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru net-acct-0.71/debian/changelog 
net-acct-0.71/debian/changelog
--- net-acct-0.71/debian/changelog  2019-04-02 19:59:09.0 +0200
+++ net-acct-0.71/debian/changelog  2019-06-20 19:13:54.0 +0200
@@ -1,3 +1,10 @@
+net-acct (0.71-9.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 20 Jun 2019 19:13:54 +0200
+
 net-acct (0.71-9.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru net-acct-0.71/debian/rules net-acct-0.71/debian/rules
--- net-acct-0.71/debian/rules  2009-10-29 23:23:21.0 +0100
+++ net-acct-0.71/debian/rules  2019-06-20 19:13:32.0 +0200
@@ -9,7 +9,7 @@
 
 .PHONY: override_dh_auto_build
 override_dh_auto_build:
-   $(MAKE) -C src MASQ=-DREMAP_MASQUERADE
+   dh_auto_build --sourcedirectory=src -- MASQ=-DREMAP_MASQUERADE
cp src/naccttab.sample debian/naccttab
 
 .PHONY: override_dh_auto_clean

Bug#575149: gcalcli: Patch for fix

[Nik Melchior]

Package: gcalcli
Version: 4.0.4-2
Followup-For: Bug #575149

Dear Maintainer,

I took a quick look at the source, and the attached patch seems to fix
the problem for me.  Thanks.

-- System Information:
Debian Release: buster/sid
  APT prefers precise-updates
  APT policy: (990, 'precise-updates'), (990, 'precise-security'), (990, 
'precise-backports'), (990, 'precise'), (500, 'xenial-updates'), (500, 
'xenial'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gcalcli depends on:
ii  python33.7.3-1
ii  python3-dateutil   2.6.1-1
ii  python3-googleapi  1.5.5-1
ii  python3-httplib2   0.9.2+dfsg-1
ii  python3-oauth2client   4.1.2-3
ii  python3-parsedatetime  2.4-2
ii  python3-six1.10.0-4

Versions of packages gcalcli recommends:
ii  python3-vobject  0.9.6.1-0.1

gcalcli suggests no packages.

-- no debconf information

diff -rU3 gcalcli-4.0.4.orig/gcalcli/gcal.py gcalcli-4.0.4/gcalcli/gcal.py
--- gcalcli-4.0.4.orig/gcalcli/gcal.py	2019-06-20 12:32:54.774960427 -0400
+++ gcalcli-4.0.4/gcalcli/gcal.py	2019-06-20 12:33:15.930767639 -0400
@@ -1548,7 +1548,7 @@
 continue
 if val.lower() == 'i':
 new_event = self._retry_with_backoff(
-self._cal_service()
+self.get_cal_service()
 .events()
 .insert(
 calendarId=self.cals[0]['id'],

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Ivan!

That is good news!!

Ivan Vučica wrote in :
 |On Thu, Jun 20, 2019 at 12:55 AM Steffen Nurpmeso  \
 |wrote:
 |> Steffen Nurpmeso wrote in <20190619234414.zvcpd%stef...@sdaoden.eu>:
 |>   ...
 |>|Dear Ivan.  If you are willing to test once again, at [1] there is
 |>|a complete ball, but you could also simply apply the attached
 |>|patch instead, which is very much smaller.
 |>|
 |>|I am sorry for the inconvenience, and i hope this fixes GSSAPI.
 |>  ...
 |>
 |> the patch was reversed; here is the right one.
 |
 |You did not quote "the right one", but the master branch seems to use
 |6b070335 from the previous email, so I used that.
 |
 |If you mean the attachment, AFAICT it matches 6b070335 so that was
 |already included. :-)

Aeh, ok. :--)

 |>|No, this is actually success. I kdestroyed the ticket cache
 |>|beforehand, and kinited.
 |>
 |> And isn't that cooler than OAUTH?  And no advertising, neither
 |> yesterday nor today and very likely also tomorrow not.
 |
 |It all comes down to scalability and scoping of non-password
 |authentication on larger systems. OAuth2 is simpler than Kerberos, and
 |doesn't (as generally implemented) depend on a secret being provided
 |to obtain a TGT.

 |But it's not why I brought it up earlier; XOAUTH2 (and other mechanism
 |names used to represent this authentication method using a bearer
 |token obtained through out-of-channel means, which can be a browser,

I really dislike being a "lesser secure app".  My passwords are
stored on an encrypted volume (if i would be truly professional
i would have some encrypted key stick instead), which is normally
not even mounted.  They actually exist in a file in netrc syntax
which is encrypted via PGP, and only decrypted on-the-fly.  Why is
this less trustable than some storage system at Google?  It
crosses the wire, maybe.  But that uses the same encryption method
that i would have to use when creating the OAuth originally.  That
is once, maybe.  So then why not being able to use an account
master and a secondary per-service key regulary?

My thought is just that with Kerberos i can have a local ticket
that is initialized once, via a local password.  Any further
communication is then based upon this temporary ticket.  They may
call it bearer token instead.

But my real critic lies about twenty years in the past, once
Germany got a new passport.  I have never understood why they did
not ship a PGP and a SSL key/certificate with a usage notice, also
for the most common applications alongside that.  And a rather
cheap chip reader which could optionally have been bought
bundled.  They should have placed a chip directly on it maybe
even.  I mean, what am i without my passport, on a border, in
a foreign country, in a police control?  The FreeBSD developers
recommended RSA 4096 already by then, which should still be worth
a decade or even longer, as i understand things.

I dedicated all my being to my people/country naturally, just by
being born like that, and if i can be selective upon that, i'd
rather not give mobile phone identity or whatever to large
companies if possible.  That much is plain.  I am pretty much
anti-capitalistic in that sense.  But it is not that i really
care, all that can't be helped and has been addressed in
literature and films for more than half a century.  The pain comes
when it hits you personally, and i do not see why i am treated as
a lesser secure app.

 |but don't have to be) is just one of many SASL mechanisms you'd get
 |for free.

Yes, SASL is on the TODO list for a long time, at least as an
option.  I really hope for end of 2020 for v15.  This could then
be some kind of (optional) filter on a socket level maybe, if
i recall correctly, usable by all protocols we understand by then,
and any others later on.
I mean it could of course be (rather) hacked in already today, it
would likely not take a week, maybe even not more than two or
three days, i have forgotten (i added the TODO five years and
a month ago ;-)

 |> I should have warned you that the password and credentials will be
 |> included in the debug output.
 |
 |No, it's to be expected if it's obvious that there's raw IMAP protocol
 |being logged. That's why I took care and removed what looked like
 |credentials. (Thankfully, I'm familiar enough with IMAP anyway.)

Good.  We also say "user .. pass", but i did it so that one can
debug whether it is the right one, say.  You can always create
a temporary tty/terminal and/or slock when you are away.
Whatever.

 |> /6b070335d77251308e1910f9efb2e08754a1f176
 |
 |Thank you, this has fixed it.

That is really good news!  I happily skip setting up a GSSAPI test
bed next week then, it is midsummer!!  Thank you, Ivan.

 |I was seeing this, though:
 |
 |```
 |s-nail:  s-nail version v14.9.13.  Type `?' for help
 |+[imap://ivuc...@myhostname.ds.mydomain.net/]INBOX: 3 messages
 |▸O  1 xx2019-01-29 03:15 /40755 
 | O  2 xxx 2019-02-01 09:58 /31642 a
 | O  3 

Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"

[Gunnar Wolf]

Hello Sean,

> In #904558 I asked the T.C. for advice about how to move #802501
> forward.  Their ultimate response was to recommend that a working group
> of developers come up with some method, other than exiting nonzero, for
> a maintscript to indicate that it failed to restart services.  Let me
> take this opportunity to thank all those who were involved in #904558.
> 
> In this message, I seek to explain my understanding of what the closing
> of T.C. bug #904558 means for debian-policy bug #802501, and those
> merged with it.  Apologies for the length.  I wanted this general sort
> of reasoning to be recorded somewhere for reference in future
> discussions.

Thank you for providing this framing and for helping us (me, at
least!) better understand the circumstances of your bug filing. Quite
probably, I should have probably read #802501 during the #904558
discussion (and it's a very short bug FWIW), but didn't. Understanding
the bug follow-up policy of the Policy Editors makes me more at ease
with what we (TC) decided — We were not the first ones to fail to find
an always-good solution :-|

Now, I would more than welcome this bugs to be pushed to the right
areas: To d-devel, or to a new, specialized working group tackling the
issue. Both in the bugs and in our discussions, it is often repeated
(quoting here Sam, from #802501) «as a distribution, I think we should
explicitly encourage people to consider the consequences on
dist-upgrade and other operations». Inconsistently failing is *not*
OK, and nobody implied it that way...

So,

> The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
> addition to the 'wontfix' tag.
> 
> ~ ~ ~
> 
> In #904558, I did not ask the T.C. to rule on what maintscripts should
> do when they fail to restart a service.  Rather, I asked them to weigh
> in on the decision between the options described above, given that the
> Policy Changes Process had failed to achieve consensus.  However, in the
> message closing #904558, the T.C. indicated that they declined to issue
> a ruling about what maintscripts should do when they fail to restart a
> service.  So the second option described above, corresponding to the
> 'ctte' usertag, has been taken off the table.
> 
> That leaves us with the question of whether to leave #802501 open, in
> the absence of the possibility of closing it by having the T.C. make a
> call.  Given that this bug has already been filed (at least) twice, I
> think it would be best for us to leave it open.  So I'm tagging
> wontfix+stalled.

I want to interpret this wontfix+stalled, and the TC answer ("The
Technical Committee does not engage in design of new proposals and
policies") don't mean this problem will just lay dormant and unsolved
forever. As Marga said in her mail closing this bug, «While we
recognize that this is a problem worth fixing, this is not something
that we can fix as a body and need the help of the Developers to do
it.»

I want to insist on our recommendation to create a work group of
developers to tackle this issue. Maybe we can start it off as a BoF
session in DC19?


signature.asc
Description: PGP signature

Bug#930789: iproute2: -json flag to bridge produces broken JSON

[Anton Ivanov]

Package: iproute2
Version: 4.20.0-2
Severity: normal

Dear Maintainer,

bridge -json mdb show

["mdb":[]]

The outer brackets should be curly.

A.

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

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

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libcap2-bin1:2.25-2
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libelf10.176-1.1
ii  libmnl01.0.4-2
ii  libselinux12.8-1+b1
ii  libxtables12   1.8.2-4

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- debconf information:
  iproute2/setcaps: false

Bug#930446: popularity-contest: unable to submit report, impossible to debugo

[Bill Allombert]

On Thu, Jun 20, 2019 at 06:04:23PM +0200, Stefan Fritsch wrote:
> It seems it is run twice, once from /etc/cron.d/popularity-contest and
> once from /etc/cron.daily. And the run from cron.d is at a different
> time on each host and was successful and did not log anything.

Good!

> But the
> second run via run-parts /etc/cron.daily (without --crond) fails because
> it is at the same time on all systems. And that produces log spam.
> 
> # grep daily /etc/crontab
> 25 6* * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.daily )
> 
> Maybe the successful run should be remembered somehow?

It is remembered by looking at the date of /var/log/popularity-contest.
If it is recent, nothing is done.
Maybe you have a cronjob that remove this file ?
Or a backup program that mess with the timestamp ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#930788: creating /var/lib/dpkg/cmethopt

[Ansgar Burchardt]

Package: apt,dselect
Severity: normal

Hi,

  [ X-Debbugs-Cc'ed -boot@ for debootstrap ]

today I learned that debootstrap as special code to create the file
/var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function
setup_dselect_method in functions.  It seems wrong that debootstrap
has to know about such a particular detail.

Alternatives to debootstrap might also not create the file at all.

So I wonder if this could be created somewhere else.  An APT developer
said this is used by dselect and suggested to file a bug against
apt,dselect; he also had the idea that the file might be created in
dselect's postinst.

Ansgar

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Stefan Fritsch]

Am 20.06.19 um 13:25 schrieb Bill Allombert:
>> When submission fails, popcon-upload dies with a timeout. There should
>> probably be a randomized sleep to distribute the server load better. I
>> think there could be a lot more popcon submissions if this is done.
> 
> What is the time in /etc/cron.d/popularity-contest ?
> (something like 33 5 * * *)
> 
> Does it work better if you change it to some other time ?
> What cron ae you using


# cat /etc/cron.d/popularity-contest
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
41 4 * * *   roottest -x /etc/cron.daily/popularity-contest &&
/etc/cron.daily/popularity-contest --crond

# dpkg -l *cron*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  anacron  (no description available)
ii  cron   3.0pl1-133   amd64process scheduling daemon
un  cron-daemon  (no description available)



It seems it is run twice, once from /etc/cron.d/popularity-contest and
once from /etc/cron.daily . And the run from cron.d is at a different
time on each host and was successful and did not log anything. But the
second run via run-parts /etc/cron.daily (without --crond) fails because
it is at the same time on all systems. And that produces log spam.

# grep daily /etc/crontab
25 6* * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )

Maybe the successful run should be remembered somehow?

Bug#929949: New upstream version 0.8 available, compatible with python3

[Alexander Zangerl]

On Thu, 20 Jun 2019 00:12:05 +0200, Sebastien Bacher writes:
>Oh, also could you share your current packaging work? It would make 
>easier to trigger the problem and help with upstream reporting...

done (somewhat reluctantly) at https://salsa.debian.org/debian/duplicity
branch master is for upstream as-is, and the debian branch contains
the quilt patches and so on.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"Mama, was kreut da?" - "Das heißt kriecht!" - "Mama, wo kreut 
das Kriecht hin?" -- gschropperl.myblog.de


signature.asc
Description: Digital Signature

Bug#930666: Please document consensus on use of dh sequencer

[Russ Allbery]

Sean Whitton  writes:

>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -259,18 +259,49 @@ files, sockets or setuid or setgid files.. [#]_
>>  Main building script: ``debian/rules``
>>  --
>>
>> -This file must be an executable makefile, and contains the
>> -package-specific recipes for compiling the package and building binary
>> -package(s) from the source.
>> -
>> -It must start with the line ``#!/usr/bin/make -f``, so that it can be
>> -invoked by saying its name rather than invoking ``make`` explicitly.
>> -That is, invoking either of ``make -f debian/rules args...`` or 
>> ``./debian/rules args...`` must result in identical behavior.
>> +This file must be an executable makefile.  It contains the
>> +package-specific recipes for compiling the source (if required) and
>> +constructing one or more binary packages.
>> +
>> +``debian/rules`` must start with the line ``#!/usr/bin/make -f`` so that
>> +it can be executed by running ``./debian/rules`` from the top of the
>> +source package.  Invoking either of ``make -f debian/rules  ...`` or
>> +``./debian/rules  ...`` must result in identical behavior.

> I must admit to being sad to see the demise of "invoked by saying its
> name", but this is probably a sensible change.

I probably shouldn't have muddled this patch with the wording
clarification, but I found the previous text a bit confusing.  It's a nice
turn of phrase, but I've never seen anyone elsewhere refer to running a
script via a relative path as "saying its name."

> A tiny thing is that you seem to have switched "" for "",
> which seems wrong.

I'll put this back to args... since it just muddles the discussion, and we
can talk about that separately some other time.  But, for the record,
"" would imply that all the arguments have to be given as a single
argument and would be later split, as opposed to " ...", which allows
for one or more arguments.

> However, any SHOULD requirement in Policy implicitly has that structure:
> "you should X unless there is reason not to X".  Perhaps MUST
> requirements don't have that implicit structure, because perhaps the
> idea in such cases is that there is never reason not to X.

I agree with Sam that this is not the way Policy is currently written.
This *is* what RFC 2119 SHOULD means, but this is one of the places where
Policy diverges from RFC 2119.  We say:

| Non-conformance with guidelines denoted by *should* (or *recommended*)
| will generally be considered a bug, but will not necessarily render a
| package unsuitable for distribution.

which isn't as clear as it could be, but doesn't leave clear room for
maintainer discretion or other reasons, just a lot of room for severity.
Compare to RFC 2119:

| This word, or the adjective "RECOMMENDED", mean that there may exist
| valid reasons in particular circumstances to ignore a particular item,
| but the full implications must be understood and carefully weighed
| before choosing a different course.

which is much weaker than Policy should.

> Would it be right to say that what we are trying to express is the idea
> that dh should be used when there aren't *package-specific* reasons not
> to use dh, and for new packages, we're recommending a workflow of
> starting with the assumption that no such package-specific reasons
> exist?

I don't think so, since this doesn't account for a maintainer who is
writing a new packaging helper, which is not a package-specific reason
(it's a maintainer-specific reason).  I also don't think the project
consensus was to tell Jonas (the cdbs maintainer) to use dh for all new
packages.

I understand the concern about making the language too weak, but I also
don't think there's a need to be too firm here.  The goal, at least as I
see it, is to push people who don't have strong opinions towards dh, not
to try to convince the people who do have strong opinions.  (I think that
convincing is worthwhile but I think it will happen organically and Policy
isn't really the place.)

> I find the expression "default content" odd in this context, I think
> because defaults are things that executable programs have, not source
> code.

> Can I suggest we talk instead about the "starting point for the content
> of d/rules" and say something like "this starting point is often
> sufficient to build a package satisfying most of the requirements below
> (and many others), and where it is not, package-specific instructions
> are usually expressed using override targets" ?

That sounds great to me.  I'll make that change in my draft.

-- 
Russ Allbery (r...@debian.org)   

Bug#930722: arc, arcanist: Both ship arc binary

[Julian Andres Klode]

On Wed, Jun 19, 2019 at 06:23:51AM -0700, Sylvestre Ledru wrote:
> 
> Le 19/06/2019 à 12:14, Julian Andres Klode a écrit :
> > Package: arc,arcanist
> > Severity: serious
> > 
> > arc: /usr/bin/arc
> > arcanist: /usr/bin/arc
> > 
> > One of them needs to be renamed, or both.
> 
> Or change the Debian policy as it is a waste of our time... and no gain for
> the user. ;)

I guess arcanist will also become irrelevant once KDE gets
rid of that phabricator nuisance.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#929949: New upstream version 0.8 available, compatible with python3

[Alexander Zangerl]

On Tue, 18 Jun 2019 21:23:18 +0200, Sebastien Bacher writes:
>Thanks for the status update. Did you report those issues upstream yet?

one only, at this time; i've seen that you added a few of them.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, Zertifiziernung: Ein Geschäftsmodell, das heisse
Luft zu Papier verdichtet und dann gegen Währung tauscht. -- Jörg Dorchain


signature.asc
Description: Digital Signature

Bug#930666: Please document consensus on use of dh sequencer

[Russ Allbery]

Bill Allombert  writes:
> On Tue, Jun 18, 2019 at 06:24:45PM -0700, Russ Allbery wrote:

>>  The following targets are required and must be implemented by
>>  ``debian/rules``: ``clean``, ``binary``, ``binary-arch``,
>> -``binary-indep``, ``build``, ``build-arch`` and ``build-indep``. These
>> -are the targets called by ``dpkg-buildpackage``.
>> +``binary-indep``, ``build``, ``build-arch`` and ``build-indep``.  (When
>> +using ``dh``, these are implemented using the wildcard pattern shown
>> +above.)  These are the targets called by ``dpkg-buildpackage``.

> Hello Russ,

> I find this layering violation rather confusing especially if dh should
> be seen as the rule and not the exception.

> There are maybe an hundred places where we could mention dh,
> with statement like "when using dh, do something else".

I think there are fewer of them than you might think (I had that
impression too going in, but found that there were a lot fewer than I had
expected), but I also think that making those changes going forward will
be valuable.  We've already started doing that with debhelper, largely in
footnotes, and having a more systematic way of structuring that would be
useful.  I think this may be usefully expressed in metadata: some way to
flag a section of Policy with "debhelper does this for you" (since in most
cases it doesn't matter if you're using debhelper directly or via dh).

That said, this is way too large of a problem to solve in this bug.  I
think we need to stay focused on one section of policy here with a few
tactical fixes so that the text still reads cleanly and not confusingly
(which is the goal above), and then look at what we can do elsewhere to
spread the clarity once we've agreed on what we want to say here.

> Maybe what we need is a separate 'dh packaging manual' where packaging
> is explained from dh point of view.

That already exists, I think?  That's the debhelper documentation.

Another option would be to leave out the minimal debian/rules example
entirely and just refer entirely to the dh manual.  Maybe that's better.

-- 
Russ Allbery (r...@debian.org)   

Bug#930774: guile-2.2: FTBFS when built with dpkg-buildpackage -A

[Rob Browning]

Santiago Vila  writes:

> To reproduce please try "dpkg-buildpackage -A".

Thanks.  I should have time to work on this over the weekend.

> While we are at it, uploading in source-only form (dpkg-buildpackage -S) 
> helps a lot
> to discover these kind of bugs sooner.

Right -- that's what I intend to be doing, but I must have forgotten to
use the right arguments this time.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#930787: pulseaudio: Microphone base volume stuck at 8739/13%/-52.50dB - low volume vs alsa

[Veek.M]

Package: pulseaudio
Version: 10.0-1+deb9u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Tried to record audio from my MIC

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Direct Alsa works and the recording is loud but with Pulseaudio started it
doesn't work - the volume is low. base volume: 8739 /  13% / -52.50 dB
index: 1
name: 

   * What was the outcome of this action?
tears

   * What outcome did you expect instead?
my charming voice on Youtube - microphone recording


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.9.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN.utf8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to C.UTF-8), LANGUAGE=en_IN.utf8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pulseaudio depends on:
ii  adduser  3.115
ii  libasound2   1.1.3-5
ii  libasound2-plugins   1.1.1-1
ii  libc62.24-11+deb9u4
ii  libcap2  1:2.25-1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.26-2
ii  libpulse010.0-1+deb9u1
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.27-3
ii  libsoxr0 0.1.2-2
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   6.3.0-18+deb9u1
ii  libsystemd0  232-25+deb9u11
ii  libtdb1  1.3.11-2
ii  libudev1 232-25+deb9u11
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.4-3+deb9u1
ii  libx11-xcb1  2:1.6.4-3+deb9u1
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20161125
ii  pulseaudio-utils 10.0-1+deb9u1

Versions of packages pulseaudio recommends:
ii  rtkit  0.11-4+deb9u1

Versions of packages pulseaudio suggests:
ii  paman0.9.4-1+b3
pn  paprefs  
ii  pavucontrol  3.0-3.1
ii  pavumeter0.9.3-4+b3
ii  udev 232-25+deb9u11

-- Configuration Files:
/etc/pulse/daemon.conf changed:
; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no
; high-priority = yes
; nice-level = -11
; realtime-scheduling = yes
; realtime-priority = 5
; exit-idle-time = 20
; scache-idle-time = 20
; dl-search-path = (depends on architecture)
; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa
; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0
; resample-method = speex-float-1
; enable-remixing = yes
; enable-lfe-remixing = no
; lfe-crossover-freq = 0
; flat-volumes = yes
; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20
; default-sample-format = s16le
; default-sample-rate = 44100
  default-sample-rate = 48000
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right
; default-fragments = 4
; default-fragment-size-msec = 25
; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0

/etc/pulse/default.pa changed:
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif
.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix
.ifexists module-gconf.so
.nofail
load-module module-gconf
.fail
.endif
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-intended-roles
load-module 

Bug#930785: mutt: "file exists" error when saving attachment to CIFS share

[Lionel Élie Mamane]

By contrast, here's the strace when saving to an ext4 filesystem:

25780 access("/home/user/filename.pdf", F_OK) = -1 ENOENT (No such file or 
directory)
25780 write(1, "\rSaving...\33[37m\33[40m\33[K\33(B\33[m\33[3"..., 47) = 47
25780 getpid()  = 25780
25780 mkdir("/home/user/.muttYpPdUJ", 0700) = 0
25780 openat(AT_FDCWD, "/home/user/.muttYpPdUJ/filename.pdf", 
O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 5
25780 close(5)  = 0
25780 link("/home/user/.muttYpPdUJ/filename.pdf", "/home/user/filename.pdf") = 0
25780 lstat("/home/user/.muttYpPdUJ/filename.pdf", {st_mode=S_IFREG|0600, 
st_size=0, ...}) = 0
25780 lstat("/home/user/filename.pdf", {st_mode=S_IFREG|0600, st_size=0, ...}) 
= 0
25780 unlink("/home/user/.muttYpPdUJ/filename.pdf") = 0
25780 unlink("/home/user/.muttYpPdUJ/filename.pdf") = -1 ENOENT (No such file 
or directory)
25780 rmdir("/home/user/.muttYpPdUJ") = 0
25780 openat(AT_FDCWD, "/home/user/filename.pdf", O_WRONLY|O_CREAT|O_NOFOLLOW, 
0600) = 5
25780 lstat("/home/user/filename.pdf", {st_mode=S_IFREG|0600, st_size=0, ...}) 
= 0
25780 fstat(5, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
25780 fcntl(5, F_GETFL) = 0x28001 (flags 
O_WRONLY|O_LARGEFILE|O_NOFOLLOW)


CIFS share mounted as

\\server\share on /home/user/mnt/share type cifs 
(rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=user,domain=DOMAIN,uid=1000,forceuid,gid=1000,forcegid,addr=XXX.XXX.XXX.XXX,file_mode=0600,dir_mode=0700,nounix,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1,user=user)



On Thu, Jun 20, 2019 at 04:24:29PM +0200, Lionel Elie Mamane wrote:
> Package: mutt
> Version: 1.7.2-1+deb9u1
> Severity: important
> 
> When saving an attachment from into a directory on a CIFS share
> (Windows 2012R2 server), mutt creates an empty file and then fails
> with the error message "file exists (errno=17)". Saving is successful
> if one tries again to same filename and then chooses "overwrite".
> 
> Here's the relevant part of an strace:
> 
> 25780 restart_syscall(<... resuming interrupted poll ...>) = 1
> 25780 read(0, "\r", 1)  = 1
> 25780 rt_sigaction(SIGINT, {sa_handler=0x556436f378e0, sa_mask=[], 
> sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f374591b840}, NULL, 8) = 0
> 25780 access("vente-2019/filename.pdf", F_OK) = -1 ENOENT (No such file or 
> directory)
> 25780 write(1, "\rSaving...\33[37m\33[40m\33[K\33(B\33[m\33[3"..., 47) = 47
> 25780 getpid()  = 25780
> 25780 mkdir("vente-2019/.muttySzSP2", 0700) = 0
> 25780 openat(AT_FDCWD, "vente-2019/.muttySzSP2/filename.pdf", 
> O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 5
> 25780 close(5)  = 0
> 25780 link("vente-2019/.muttySzSP2/filename.pdf", "vente-2019/filename.pdf") 
> = 0
> 25780 lstat("vente-2019/.muttySzSP2/filename.pdf", {st_mode=S_IFREG|0600, 
> st_size=0, ...}) = 0
> 25780 lstat("vente-2019/filename.pdf", {st_mode=S_IFREG|0600, st_size=0, 
> ...}) = 0
> 25780 unlink("vente-2019/.muttySzSP2/filename.pdf") = 0
> 25780 rmdir("vente-2019/.muttySzSP2")   = 0
> 25780 write(1, "\7", 1) = 1
> 25780 write(1, "\rfopen: File exists (errno = 17)", 32) = 32
> 
> -- Package-specific info:
> NeoMutt 20170113 (1.7.2)
> Copyright (C) 1996-2016 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
> 
> System: Linux 4.9.0-9-amd64 (x86_64)
> libidn: 1.33 (compiled with 1.33)
> hcache backends: tokyocabinet
> 
> Compiler:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 
> 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
> --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
> --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
> --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
> --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
> --enable-multilib --with-tune=generic 

Bug#930786: apt-get with -b (--compile, --build) should sanitize the environment, like debuild

[Julian Andres Klode]

On Thu, Jun 20, 2019 at 04:49:39PM +0200, Vincent Lefevre wrote:
> Package: apt
> Version: 1.8.2
> Severity: wishlist
> 
> When using the -b (--compile, --build) option to build the package,
> apt-get should sanitize the environment, like what debuild does
> (see the debuild(1) man page).

People generally have wildly different views on that. I do not think
that APT is the right place to do this, as it means it will also
need to provide a way to override variables.

That's different from sanitizing PATH for system installs, as builds
are generally something where you do want to set some vars; but for
installs, we need a sane-ish environment.

Using debuild if available would be an option too, but I don't really
know if I'd want that. My general advise would be not to use -b and
use either debuild or dpkg-buildpackage based on your personal preferences;
optimally sbuild.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#761219: debian-policy: document versioned Provides

[Sean Whitton]

control: tag -1 -patch +pending

Hello,

On Thu 20 Jun 2019 at 04:43pm +0200, gregor herrmann wrote:

> Seconded as well.

Thanks.  Applied.

-- 
Sean Whitton

Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"

[Sean Whitton]

tag 802501 + wontfix
user debian-pol...@packages.debian.org
usertag 802501 = normative stalled
thanks

Hello,

In #904558 I asked the T.C. for advice about how to move #802501
forward.  Their ultimate response was to recommend that a working group
of developers come up with some method, other than exiting nonzero, for
a maintscript to indicate that it failed to restart services.  Let me
take this opportunity to thank all those who were involved in #904558.

In this message, I seek to explain my understanding of what the closing
of T.C. bug #904558 means for debian-policy bug #802501, and those
merged with it.  Apologies for the length.  I wanted this general sort
of reasoning to be recorded somewhere for reference in future
discussions.

~ ~ ~

When the Policy Changes Process fails to establish consensus, we have a
few options.  If we think that consensus hasn't been established only
because no-one has volunteered to come up with an adequately detailed
response to the problem uncovered by the filing and discussion of the
bug, and the bug has been open for a while with no evidence of anyone
working on it, we (the Policy Editors) will often just close the bug.
We don't want such things to stick around, clogging up the list of open
issues in a way that's demotivating.  This is the 'obsolete' usertag.

If we think that consensus hasn't been established because there are
good arguments on all sides, but we (the Policy Editors) additionally
think that argument to determine the very best solution is less
important right now than settling on one of the possible solutions
rather than remaining in further discussion, then we can refer the bug
to the T.C. to make a call between the competing options.  This was, I
think, the intended purpose of the 'ctte' usertag, but we haven't been
using it.

Finally, if we don't want to refer the bug to the T.C. -- generally
because it's not important enough -- but we think that closing the bug
would be counterproductive because someone else will just open a new bug
raising the same issue again at some near point in time, we can just
leave the bug open, as a kind of placeholder to hopefully reduce the
number of duplicate bugs filed.  I just added a 'stalled' usertag for
this case.

The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
addition to the 'wontfix' tag.

~ ~ ~

In #904558, I did not ask the T.C. to rule on what maintscripts should
do when they fail to restart a service.  Rather, I asked them to weigh
in on the decision between the options described above, given that the
Policy Changes Process had failed to achieve consensus.  However, in the
message closing #904558, the T.C. indicated that they declined to issue
a ruling about what maintscripts should do when they fail to restart a
service.  So the second option described above, corresponding to the
'ctte' usertag, has been taken off the table.

That leaves us with the question of whether to leave #802501 open, in
the absence of the possibility of closing it by having the T.C. make a
call.  Given that this bug has already been filed (at least) twice, I
think it would be best for us to leave it open.  So I'm tagging
wontfix+stalled.

~ ~ ~

In filing #904558, I made an alternative suggestion to the above:

> As a Policy delegate I want to move this issue along, and I can see
> three ways of doing that:
>
> 1. write a patch to explicitly state in Policy that what happens when a
>service (re)start fails in a maintscript is left up to package
>maintainer discretion, and close the bugs
> [...]

I no longer think this would be useful enough to have in Policy, but I'd
like to hear from anyone who disagrees.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Preserving the rather large CC list for now…

On Thu, Jun 20, 2019 at 06:05:22AM -0400, Sam Hartman wrote:

I feel very uncomfortable with a change as big as this revert happening
this late in the release cycle.


How big is big? The MR I raised resurrects a patch that changes one line
of code, and was shipped in the last stable release. Although it looks
like further work is needed to make the change as smooth as possible so
this would grow. However, the patch certainly needs more testing. Is the
issue that it results in a large change in terms of what software is
executed by the user as a consequence, and what of that has been tested
thus far in the freeze?

How late is late? How would you have felt about it back in early April,
when I first raised it? I was surprised to discover it then, and I felt
it was late in the cycle even then. But mostly whats happened since is
nothing.

I absolutely do not blame the GNOME team here. Simon McVittie and
Michael Biebl in particular have taken risks sticking their heads above
the parapet to engage with me on this matter, and both have made it
clear that it would be unreasonable for them to make the call given
their respective levels of involvement. I respect that, and I am
extremely grateful for them engaging with the issue. The others are
either too busy or have taken a decision not to engage with a
potentially toxic issue, and I respect that, too: we are all volunteers
who have to make our own choices about what we are prepared to do and
engage in. Besides, like many teams, the GNOME team is clearly
under-resourced.

I am a *little* disappointed that this does not seem to have been
thought of as an important, project-wide issue. Regardless of whether
one uses GNOME or Wayland oneself, the matter of the default desktop for
the distribution we are all working to produce, and the experience that
our users will get out of the box, I would have thought was important
for all of us. It reinforces the idea, to me, that we are largely
working in our own silos, and not concerned (enough) about the holistic
distribution as a whole.


And yet, the lack of a clear reconfirmation in this time line even given
the wonderfully civil discussion is telling.


I'm very pleased that the discussion has come across as civil. I've
tried really hard from my end to achieve that, I know that issues around
GNOME can result in some very toxic communications.


My proposal--which again I have no power to implement--is that we go
forward with the current default.  However, we remain open to a revert
in the first couple of buster point releases.


There are caveats with switching the default in either direction. 
Let's say we go with Wayland now, and later decide to switch as per the

criteria/process you sketch below.

• users of the default, who got Wayland from Buster onwards and had no
  problems, would subsequently find themselves switched to Xorg by
  stable-updates, which IMHO would be unexpected (if noticed) and
  contrary to the expectations of a stable release.

• A user who installed or upgraded and got Wayland by default but had
  problems, would have likely addressed them by switching to the Xorg
  session explicitly (assuming they could figure out that doing so
  mitigated their issues). Changing the default would only prevent
  *future* users from hitting the same problems.


The criteria for that revert should be based on the actual severity and
frequence of problems our users run into, but should specifically
exclude the blanket reluctance to  make a change like that in a point
release.  We would still need adequate testing of such a revert.


My concern with this is it's a new set of policies and procedures, not
codified anywhere, with a lot of detail to work out "on the hoof" (how
do we measure frequency of problems? do we go with the existing bug
severity guidelines? How much is adequate testing? etc.)

So combined with the user experience above, I think we would be best not
to change the default within a stable release cycle, unless there was
some kind of enormous catastrophic issue with Wayland that we don't
know about yet, and that's unlikely.

I still argue that the traditional Debian conservative, when-its-ready
approach would be the distribution status quo (Xorg), but I recognise
the concerns about the proposed patch, further work needed, lack of
testing etc.; and those are not issues I think I can resolve alone.


--
Jonathan Dowland

Bug#903862: FTBFS: override_dh_auto_test exits with exit 2

[Vincent Lefevre]

Control: tags -1 fixed-upstream

On 2018-07-16 03:41:02 +0200, Vincent Lefevre wrote:
> Control: retitle -1 FTBFS: override_dh_auto_test fails due to test-real-data 
> when $SHELL is set to /bin/zsh
> Control: severity -1 minor
> Control: tags -1 - moreinfo unreproducible
> 
> I could check that unsetting SHELL before building avoids the failure.

This has been fixed upstream.

BTW, I think that when building a package (-b option), apt-get should
sanitize the environment, like what debuild does. I've reported a
wishlist bug for that:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930786

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

Bug#930786: apt-get with -b (--compile, --build) should sanitize the environment, like debuild

[Vincent Lefevre]

Package: apt
Version: 1.8.2
Severity: wishlist

When using the -b (--compile, --build) option to build the package,
apt-get should sanitize the environment, like what debuild does
(see the debuild(1) man page).

For instance, the SHELL environment variable can affect the build
(bug 903862 for gnucash).

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.9\.0-9-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: 

Bug#761219: debian-policy: document versioned Provides

[gregor herrmann]

On Thu, 20 Jun 2019 11:00:58 +0100, Sean Whitton wrote:

> On Fri 07 Jun 2019 at 10:50AM +01, Dominic Hargreaves wrote:
> 
> > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
> > index 1d790e8..3b68420 100644
> > --- a/policy/ch-relationships.rst
> > +++ b/policy/ch-relationships.rst
> > @@ -17,15 +17,16 @@ package names, separated by vertical bar (pipe) symbols 
> > ``|``. In such a
> >  case, that part of the dependency can be satisfied by any one of the
> >  alternative packages.  [#]_
> >
> > -All of the fields except for ``Provides`` may restrict their
> > -applicability to particular versions of each named package. This is done
> > -in parentheses after each individual package name; the parentheses
> > -should contain a relation from the list below followed by a version
> > -number, in the format described in :ref:`s-f-Version`.
> > +All of the fields may restrict their applicability to particular versions
> > +of each named package. This is done in parentheses after each individual
> > +package name; the parentheses should contain a relation from the list
> > +below followed by a version number, in the format described in
> > +:ref:`s-f-Version`.
> >
> >  The relations allowed are ``<<``, ``<=``, ``=``, ``>=`` and ``>>`` for
> >  strictly earlier, earlier or equal, exactly equal, later or equal and
> > -strictly later, respectively.  [#]_
> > +strictly later, respectively. The exception is the Provides field, for
> > +which only ``=`` is allowed.  [#]_
> >
> >  Whitespace may appear at any point in the version specification subject
> >  to the rules in :ref:`s-controlsyntax`, and must appear
> > @@ -446,17 +447,43 @@ they can say:
> >  and the ``bar-plus`` package will now also satisfy the dependency for
> >  the ``foo`` package.
> >
> > -If a relationship field has a version number attached, only real
> > -packages will be considered to see whether the relationship is satisfied
> > -(or the prohibition violated, for a conflict or breakage). In other
> > -words, if a version number is specified, this is a request to ignore all
> > -``Provides`` for that package name and consider only real packages. The
> > -package manager will assume that a package providing that virtual
> > -package is not of the "right" version. A ``Provides`` field may not
> > -contain version numbers, and the version number of the concrete package
> > -which provides a particular virtual package will not be considered when
> > -considering a dependency on or conflict with the virtual package name.
> > -[#]_
> > +A ``Provides`` field may contain version numbers, and such a version number
> > +will be considered when considering a dependency on or conflict with the
> > +virtual package name.  [#]_ For example, given the following packages:
> > +
> > +::
> > +
> > +Package: foo
> > +Depends: bar (>= 1.0)
> > +
> > +Package: bar
> > +Version: 0.9
> > +
> > +Package: bar-plus
> > +Provides: bar (= 1.0)
> > +
> > +the ``bar-plus`` package will again satisfy the dependency for
> > +the ``foo`` package with the virtual package name.  [#]_ If the 
> > ``Provides``
> > +field does not specify a version number, it will not satisfy versioned
> > +dependencies or violate versioned ``Conflicts`` or ``Breaks``. For example,
> > +given the following packages:
> > +
> > +::
> > +
> > +Package: foo
> > +Depends: bar (>= 1.0)
> > +
> > +Package: bar
> > +Version: 0.9
> > +
> > +Package: bar-plus
> > +Provides: bar (= 1.0)
> > +
> > +Package: bar-clone
> > +Provides: bar
> > +
> > +the ``bar-plus`` package will satisfy the dependency for the ``foo``
> > +package, but the ``bar-clone`` package will not.
> >
> >  To specify which of a set of real packages should be the default to
> >  satisfy a particular dependency on a virtual package, list the real
> > @@ -670,10 +697,8 @@ dependencies.
> > together and then configured in their dependency order.
> >
> >  .. [#]
> > -   It is possible that a future release of ``dpkg`` may add the ability
> > -   to specify a version number for each virtual package it provides.
> > -   This feature is not yet present, however, and is expected to be used
> > -   only infrequently.
> > +   This functionality was introduced in dpkg 1.17.11 and newer and
> > +   full support has been provided in the Debian archive since 2018.
> >
> >  .. [#]
> > To see why ``Breaks`` is normally needed in addition to ``Replaces``,
> 
> Seconded.  Thank you again.

Seconded as well.


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: U2: With our Without You


signature.asc
Description: Digital Signature

Bug#930785: mutt: "file exists" error when saving attachment to CIFS share

[Lionel Elie Mamane]

Package: mutt
Version: 1.7.2-1+deb9u1
Severity: important

When saving an attachment from into a directory on a CIFS share
(Windows 2012R2 server), mutt creates an empty file and then fails
with the error message "file exists (errno=17)". Saving is successful
if one tries again to same filename and then chooses "overwrite".

Here's the relevant part of an strace:

25780 restart_syscall(<... resuming interrupted poll ...>) = 1
25780 read(0, "\r", 1)  = 1
25780 rt_sigaction(SIGINT, {sa_handler=0x556436f378e0, sa_mask=[], 
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f374591b840}, NULL, 8) = 0
25780 access("vente-2019/filename.pdf", F_OK) = -1 ENOENT (No such file or 
directory)
25780 write(1, "\rSaving...\33[37m\33[40m\33[K\33(B\33[m\33[3"..., 47) = 47
25780 getpid()  = 25780
25780 mkdir("vente-2019/.muttySzSP2", 0700) = 0
25780 openat(AT_FDCWD, "vente-2019/.muttySzSP2/filename.pdf", 
O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 5
25780 close(5)  = 0
25780 link("vente-2019/.muttySzSP2/filename.pdf", "vente-2019/filename.pdf") = 0
25780 lstat("vente-2019/.muttySzSP2/filename.pdf", {st_mode=S_IFREG|0600, 
st_size=0, ...}) = 0
25780 lstat("vente-2019/filename.pdf", {st_mode=S_IFREG|0600, st_size=0, ...}) 
= 0
25780 unlink("vente-2019/.muttySzSP2/filename.pdf") = 0
25780 rmdir("vente-2019/.muttySzSP2")   = 0
25780 write(1, "\7", 1) = 1
25780 write(1, "\rfopen: File exists (errno = 17)", 32) = 32

-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-9-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-bO92sq/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-bO92sq/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS 
+HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET 
+HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP 

Bug#887045: iwlwifi bug still in 4.19.37-3

[Rainer Sabelka]

I'm also affected by this bug. Running Buster with latest (official) kernel  
on a Gigabyte Brix GB-EAPD-4200 box.

# uname -a
Linux brix1 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 (2019-05-15) x86_64 GNU/
Linux


[433951.400223] WARNING: CPU: 2 PID: 402 at drivers/net/wireless/intel/
iwlwifi/mvm/tx.c:1431 iwl_mvm_rx_tx_cmd+0x1e6/0x650 [iwlmvm]
[433951.400228] Modules linked in: devlink nf_tables nfnetlink ctr ccm bridge 
8021q garp stp mrp llc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic arc4 nls_ascii nls_cp437 vfat iwlmvm fat intel_rapl 
btusb btrtl x86_pkg_temp_thermal btbcm mac80211 btintel bluetooth kvm_intel 
snd_soc_skl kvm snd_soc_skl_ipc irqbypass crct10dif_pclmul snd_soc_sst_ipc 
iwlwifi snd_soc_sst_dsp crc32_pclmul i915 snd_hda_ext_core 
snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core cfg80211 evdev snd_compress 
drbg efi_pstore snd_hda_intel drm_kms_helper snd_hda_codec snd_hda_core 
ghash_clmulni_intel snd_hwdep intel_cstate mei_me ansi_cprng cdc_ether 
intel_rapl_perf ecdh_generic wdat_wdt snd_pcm rfkill usbnet drm sg option mei 
mii usb_wwan snd_timer usbserial ucsi_acpi pcspkr efivars snd typec_ucsi 
soundcore i2c_algo_bit
[433951.400365]  typec video pcc_cpufreq button it87 hwmon_vid coretemp 
efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic 
fscrypto ecb sd_mod crc32c_intel ahci libahci xhci_pci libata xhci_hcd 
sdhci_pci cqhci aesni_intel sdhci aes_x86_64 scsi_mod crypto_simd cryptd 
glue_helper usbcore mmc_core r8169 lpc_ich realtek i2c_i801 libphy usb_common 
fan i2c_hid thermal hid
[433951.400454] CPU: 2 PID: 402 Comm: irq/133-iwlwifi Not tainted 4.19.0-5-
amd64 #1 Debian 4.19.37-3
[433951.400456] Hardware name: GIGABYTE GB-EAPD-4200/MZAPLEP-00, BIOS F8 
01/18/2018
[433951.400485] RIP: 0010:iwl_mvm_rx_tx_cmd+0x1e6/0x650 [iwlmvm]
[433951.400490] Code: 5c 24 28 48 8d 44 24 28 48 39 c3 0f 84 8c 02 00 00 44 0f 
b6 6c 24 0a c6 44 24 13 00 41 8d 45 ff 66 89 44 24 10 e9 ea 00 00 00 <0f> 0b 
81 4b 28 00 01 00 00 45 31 f6 49 8b 47 10 48 8b b0 d0 03 00
[433951.400494] RSP: 0018:9abf012d7d38 EFLAGS: 00010246
[433951.400499] RAX: 0001 RBX: 8bdc353f1c00 RCX: 
80150014
[433951.400502] RDX: 80150015 RSI: 0001 RDI: 
8bdc37566f00
[433951.400504] RBP: 8bdc34294000 R08: 8bdc353f1c30 R09: 
c0dbf101
[433951.400507] R10: 8bdc30eaf980 R11: 0001 R12: 
8bdc35206324
[433951.400510] R13: 0088 R14: 170a R15: 
8bdc3536d548
[433951.400514] FS:  () GS:8bdc37b0() knlGS:

[433951.400517] CS:  0010 DS:  ES:  CR0: 80050033
[433951.400520] CR2: 7fb1e775c028 CR3: 00018a20a000 CR4: 
003406e0
[433951.400523] Call Trace:
[433951.400555]  iwl_pcie_rx_handle+0x239/0x860 [iwlwifi]
[433951.400579]  iwl_pcie_irq_handler+0x183/0x6b0 [iwlwifi]
[433951.400589]  ? irq_finalize_oneshot.part.43+0x100/0x100
[433951.400595]  irq_thread_fn+0x1f/0x60
[433951.400600]  irq_thread+0xe7/0x170
[433951.400605]  ? irq_forced_thread_fn+0x70/0x70
[433951.400610]  ? irq_thread_check_affinity+0xd0/0xd0
[433951.400615]  kthread+0x112/0x130
[433951.400620]  ? kthread_bind+0x30/0x30
[433951.400628]  ret_from_fork+0x35/0x40
[433951.400635] ---[ end trace 703640882042d75e ]---


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

Bug#930784: load-with-code-conversion: Symbol’s value as variable is void: @KOM-BUILTIN-SERVER-ALIASES@

[Göran Weinholt]

Package: lyskom-elisp-client
Version: 0.48+git.20160707.372be663-1
Severity: important

The lyskom client does not start when using `M-x lyskom`. An error is logged:

load-with-code-conversion: Symbol’s value as variable is void: 
@KOM-BUILTIN-SERVER-ALIASES@


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

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

Versions of packages lyskom-elisp-client depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  emacs  1:26.1+1-3.2
ii  emacs-lucid [emacsen]  1:26.1+1-3.2

lyskom-elisp-client recommends no packages.

lyskom-elisp-client suggests no packages.

-- debconf information:
* lyskom-elisp-client/server-list-query: false

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Ivan Vučica]

On Thu, Jun 20, 2019 at 12:55 AM Steffen Nurpmeso  wrote:
> Steffen Nurpmeso wrote in <20190619234414.zvcpd%stef...@sdaoden.eu>:
>   ...
>  |Dear Ivan.  If you are willing to test once again, at [1] there is
>  |a complete ball, but you could also simply apply the attached
>  |patch instead, which is very much smaller.
>  |
>  |I am sorry for the inconvenience, and i hope this fixes GSSAPI.
>  ...
>
> the patch was reversed; here is the right one.

You did not quote "the right one", but the master branch seems to use
6b070335 from the previous email, so I used that.

If you mean the attachment, AFAICT it matches 6b070335 so that was
already included. :-)

>  |No, this is actually success. I kdestroyed the ticket cache
>  |beforehand, and kinited.
>
> And isn't that cooler than OAUTH?  And no advertising, neither
> yesterday nor today and very likely also tomorrow not.

It all comes down to scalability and scoping of non-password
authentication on larger systems. OAuth2 is simpler than Kerberos, and
doesn't (as generally implemented) depend on a secret being provided
to obtain a TGT.

But it's not why I brought it up earlier; XOAUTH2 (and other mechanism
names used to represent this authentication method using a bearer
token obtained through out-of-channel means, which can be a browser,
but don't have to be) is just one of many SASL mechanisms you'd get
for free.

> I should have warned you that the password and credentials will be
> included in the debug output.

No, it's to be expected if it's obvious that there's raw IMAP protocol
being logged. That's why I took care and removed what looked like
credentials. (Thankfully, I'm familiar enough with IMAP anyway.)

> /6b070335d77251308e1910f9efb2e08754a1f176

Thank you, this has fixed it.

I was seeing this, though:

```
s-nail:  s-nail version v14.9.13.  Type `?' for help
+[imap://ivuc...@myhostname.ds.mydomain.net/]INBOX: 3 messages
▸O  1 xx2019-01-29 03:15 /40755 
 O  2 xxx 2019-02-01 09:58 /31642 a
 O  3 xxx. 2019-01-28 15:34 /24693 aaa
There are new messages in the error message ring (denoted by ERROR)
  It can be managed with the `errors' command
ERROR# ? errors
   1.
? errors
The error ring is empty
? q
Held 3 messages in +[imap://ivuc...@myhostname.ds.mydomain.net/]INBOX
```

I'm not sure how to use the 'errors' command or where this error came
from. In the meantime I cleaned the inbox, so I am no longer seeing
this error and probably can't easily reproduce it.

Either way, the original bug is now gone from upstream, so if
experimental were updated to 6b070335d77251308e1910f9efb2e08754a1f176
or later, that would solve debian bug #930691.

Bug#930783: FTBFS: mate-applets on ppc64el

[Frédéric Bonnard]

Package: src:mate-applets
Version: 1.20.3-2
Control: tags -1 ftbfs patch

--

Dear maintainer,
mate-applets fails to build on ppc64el.
On this architecture libcpupower is used instead of libcpufreq .
Looking at upstream, it seems that mate-applets completely switched to
libcpupower on all arch since kernel 4.7.
So I propose to follow that move by depending on libcpupower-dev and
remove patch 1000-fix-build-on-linux-4.7-or-newer.patch that suppose libcpufreq 
use :
https://salsa.debian.org/debian-mate-team/mate-applets/merge_requests/1

Regards,


F.


pgpcAnX4KP7k7.pgp
Description: PGP signature

Bug#930776: unblock: ionit/0.3.2-1

[Benjamin Drung]

Control: tags -1 - moreinfo

Am Donnerstag, den 20.06.2019, 15:02 +0200 schrieb Paul Gevers:
> Control: tags -1 moreinfo confirmed
> 
> Hi Benjamin,
> 
> On 20-06-2019 14:05, Benjamin Drung wrote:
> > Okay. I prepared a version with just the fixes for the
> > ionit.service
> > (debdiff attached). Why not going through testing-proposed-updates? 
> > If
> > not, the version number will be 0.3.2+really0.2.1-2 instead of
> > 0.2.1-2.
> 
> Or better 0.3.2+really0.2.1-1 (as the first version of the upstream
> version 0.3.2+really0.2.1) but I don't mind yours if you really
> prefer that.

Okay. Uploaded that debdiff as 0.3.2+really0.2.1-1.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

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

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#930715: release.debian.org: gcc-mingw-w64 Buster upload

[Ivo De Decker]

user release.debian@packages.debian.org
usertag 930715 unblock
tags 930715 confirmed moreinfo
retitle 930715 unblock: gcc-mingw-w64/21.3~deb10u1
thanks


Hi,

Please note that you didn't use the correct usertag. Please do so in the
future to avoid the bug getting missed.

On Wed, Jun 19, 2019 at 09:27:46AM +0200, Stephen Kitt wrote:
> I uploaded an updated gcc-mingw-w64 package to unstable, 21.3, with a
> fix for #928214. I’ve since been informed (by Paul Gevers, re
> Mednafen) that gcc-8 8.3.0-7 won’t be migrating, which means
> gcc-mingw-w64 21.3 won’t either.
> 
> Could I upload the package as 21.3~deb10u1 to testing-pu? The diff
> between 21.2 and 21.3 is as follows:

OK. Please go ahead with the 21.3~deb10u1 upload and set the distribution to
'buster' (not 'testing' or 'testing-proposed-updates') and remove the moreinfo
tag from this bug once the upload has been accepted and built everywhere.

> The package is currently building in unstable, with a killed job on
> i386 for some reason; it also builds fine in testing.

I guess there was a buildd reboot. I gave back the build for unstable on i386.

Thanks,

Ivo

Bug#930782: tomb: Invalid default cipher "aes-xts-plain64:sha256"

[S. G.]

Package: tomb
Version: 2.5+dfsg1-2
Severity: normal
Tags: upstream

Dear Maintainer,

The default cipher is not accepted by cryptsetup any more.

Locking a freshly digged tomb by

$ tomb lock -k x.key x.tomb

fails with

[...]
tomb [W] cryptsetup luksFormat returned an error.
tomb [E] Operation aborted.

According to https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt the default
cipher "aes-xts-plain64:sha256" is not valid. ":sha256" only goes with "aes-
cbc-essiv:sha256". The valid cipher would be "aes-xts-plain64".

Locking the tomb specifying the valid cipher on the command line works

$ tomb lock -k x.key -o aes-xts-plain64 x.tomb

[...]
tomb  .  Done locking x using Luks dm-crypt aes-xts-plain64
tomb (*) Your tomb is ready in x.tomb and secured with key x.key

"aes-xts-plain64:sha256" should be corrected to "aes-xts-plain64" in
/usr/bin/tomb and the manpage.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tomb depends on:
ii  cryptsetup-bin  2:2.1.0-5
ii  e2fsprogs   1.44.5-1
ii  gnupg   2.2.12-1
ii  pinentry-gnome3 [pinentry]  1.1.0-2
ii  sudo1.8.27-1
ii  zsh 5.7.1-1

tomb recommends no packages.

tomb suggests no packages.

-- no debconf information

Bug#930387: rdekstop: security issues fixed in 1.8.5 and 1.8.6

[Salvatore Bonaccorso]

On Tue, Jun 11, 2019 at 09:22:30PM +0200, Salvatore Bonaccorso wrote:
> Source: rdesktop
> Version: 1.8.4-1
> Severity: grave
> Tags: security upstream fixed-upstream
> Justification: user security hole
> Control: fixed -1 1.8.6-1
> 
> Hi
> 
> 1.8.6-1 mentions a new upstream release with many security fixes, but
> none of those apparently have (yet) a CVE. Filling this bug for having
> an unique identifier for the tracker in meanwhile.
> 
> Reference: 
> https://tracker.debian.org/news/1041036/accepted-rdesktop-186-1-source-into-unstable/

AFAICS there is not clear information on which issues are fixed
exactly,
https://groups.google.com/forum/#!topic/rdesktop-announce/czgpKDfm2D0
is a bit scarce on information.

Probably if we are going to release a stretch-security update it might
be worth doing an import of 1.8.6 for the security update itself and
moving from 1.8.4-1~deb9u1 to the new upstream version.

Regards,
Salvatore

Bug#930671: libauthen-radius-perl: most basic usage stopped working

[Niko Tyni]

Control: tag -1 patch
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=129869

On Wed, Jun 19, 2019 at 08:27:51PM +0300, Niko Tyni wrote:
> On Tue, Jun 18, 2019 at 10:52:03AM +0200, Ferenc Wágner wrote:
> > Package: libauthen-radius-perl
> > Version: 0.29-1
> > Severity: important
>  
> > I recently upgraded to buster and noticed that our RADIUS test plugin
> > does not work anymore.  Downgrading libauthen-radius-perl to 0.27-1
> > fixes the issue.  Take the first example from the top of the man page:
> > 
> >   use Authen::Radius;
> >   $r = new Authen::Radius(Host => 'myserver', Secret => 'mysecret');
> >   print "auth result=", $r->check_pwd('myname', 'mypwd'), "\n";

> >   unknown attr name 1 at /usr/share/perl5/Authen/Radius.pm line 865.

> This needs to be reported and fixed upstream; I'll look at it in the
> next few days unless someone else beats me to it.

I've reported this upstream with the attached proposed patch.

Will wait a bit before applying the patch for Debian in case upstream
has comments.
-- 
Niko Tyni   nt...@debian.org
>From ba0078591c35d1d6a404828aab9d06fb43c4d5fc Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Thu, 20 Jun 2019 16:43:30 +0300
Subject: [PATCH] Fix 0.28 regression with check_pwd()

add_attributes() is documented to accept raw numeric attributes,
and check_pwd() uses those.

Bug-Debian: https://bugs.debian.org/930671
---
 Radius.pm |  3 ++-
 t/error.t | 13 -
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Radius.pm b/Radius.pm
index fd0a6c9..3497e99 100644
--- a/Radius.pm
+++ b/Radius.pm
@@ -862,7 +862,8 @@ sub add_attributes {
 $attr_name = $1;
 }
 
-die 'unknown attr name '.$attr_name if (! exists $dict_name{$attr_name});
+die 'unknown attr name '.$attr_name
+if ($attr_name =~ /\D/ and ! exists $dict_name{$attr_name});
 
 $id = $dict_name{$attr_name}{id} // int($attr_name);
 $vendor = vendorID($attr);
diff --git a/t/error.t b/t/error.t
index 6a02cb3..e1c8f5f 100644
--- a/t/error.t
+++ b/t/error.t
@@ -1,6 +1,6 @@
 use strict;
 use warnings;
-use Test::More tests => 9;
+use Test::More tests => 12;
 use Test::NoWarnings;
 
 BEGIN { use_ok('Authen::Radius') };
@@ -17,3 +17,14 @@ ok( $auth->clear_attributes, 'clear attributes');
 
 is($auth->get_error(), 'ENONE', 'error was reset');
 is(Authen::Radius->get_error(), 'ENONE', 'global error also reset');
+
+my @attributes = (
+{ Name => 1, Value => 'user', Type => 'string' },
+{ Name => 2, Value => 'pass', Type => 'string' },
+{ Name => 4, Value => '127.0.0.1', Type => 'ipaddr' }
+);
+
+# called by check_pwd()
+ok( $auth->add_attributes(@attributes), 'add attributes');
+is($auth->get_error(), 'ENONE', 'no error with add_attributes');
+is(Authen::Radius->get_error(), 'ENONE', 'no global error either');
-- 
2.20.1

Bug#930781: python3-socks: Deprecation warning emitted on import

[Jamie Bliss]

Package: python3-socks
Version: 1.6.8+dfsg-1
Severity: normal

Dear Maintainer,

PySocks 1.6.8 has a deprecated import and a warning is emitted on import. This
is triggered by importing requests, an extremely common HTTP library. It has
been fixed in upstream 1.7.0

This happens for any software that uses requests, whether or not they depend on
PySocks. It just happens for every application that uses it as soon as
python3-socks is installed on a system.

In addition, this warning becomes user-visible if the application surfaces
warnings in some way (in a log or on stdout).



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

Kernel: Linux 4.19.0-5-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=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 python3-socks depends on:
ii  python3  3.7.3-1

python3-socks recommends no packages.

python3-socks suggests no packages.

-- no debconf information

Bug#906548: fix from qtwebenigne

[Michal Klocek]

forwarded from https://bugreports.qt.io/browse/QTBUG-75097

see https://codereview.qt-project.org/c/qt/qtwebengine-chromium/+/265678

Br

Michal

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[tony mancill]

On Wed, Jun 19, 2019 at 10:48:29PM +0200, Matthias Klose wrote:
> On 19.06.19 22:03, Paul Gevers wrote:
> > Hi Tony,
> > 
> > On 18-06-2019 22:14, tony mancill wrote:
> >> Things are looking good so far with 11.0.4+4+really11.0.3+7 in unstable,
> >> and so I would like to prepare the t-p-u upload.  At the moment, the
> >> version I have is 11.0.3+7-5, since that would have been the "next"
> >> 11.0.3+7 Debian revision for unstable.  The 11.0.3+7 orig.tar.xz already
> >> in the archive is the same one used for the "really" to unstable and
> >> this build, and this versioning makes it clear to users what they are
> >> getting.  The resulting changelog would be:
> >>
> >>> diff -Nru openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog 
> >>> openjdk-11-11.0.3+7/debian/changelog
> >>> --- openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog   2019-06-14 
> >>> 12:28:25.0 -0700
> >>> +++ openjdk-11-11.0.3+7/debian/changelog  2019-06-16 11:24:19.0 
> >>> -0700
> >>> @@ -1,3 +1,10 @@
> >>> +openjdk-11 (11.0.3+7-5) buster; urgency=medium
> >>> +
> >>> +  * Team upload.
> >>> +  * Upload 11.0.4+4+realy11.0.3+7-2 to buster t-p-u.
> >>> +
> >>> + -- tony mancill   Sun, 16 Jun 2019 11:24:19 -0700
> >>
> >> Is this acceptable to the Release Team?  If not, (and I know there have
> >> been some differing opinions), how shall we version the t-p-u package?
> > 
> > I think the most logical version would be 11.0.3+7-4+deb10u1, as this is
> > a targeted upload to buster.
> 
> let's use a version which also can be nicely used for the backports upload.
> 
> > I don't have a strong opinion on it. I
> > still don't like it we go via tpu but I understand the ranting argument.
> 
> this will be very short-lived until the final 11.0.4 release to be uploaded 
> into
> security.

I interpret this exchange to mean that 11.0.3+7-5 is still the version
preferred by the OpenJDK Team and so have uploaded that, built against
buster and with distribution set the buster.

Let me know if I misinterpreted and should upload with a different
version, and thank you for the discussion and patience with this one.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#929564: gatb-core-testdata: broken symlink: /usr/share/doc/gatb-core/test/gatb-core-cppunit -> ../../../../lib/gatb-core/gatb-core-cppunit

[Andreas Beckmann]

On 20/06/2019 07.16, Andreas Tille wrote:
>>   /usr/share/doc/gatb-core/test/gatb-core-cppunit -> 
>> ../../../../lib/gatb-core/gatb-core-cppunit (gatb-core-testdata)
>>
>> The target does not seem to exist in any package in the archive.
> 
> That's actually quite strange.  In local builds using pbuilder the file
> /usr/lib/gatb-core/gatb-core-cppunit is created and part of the package

have you tried --binary-arch/--binary-indep builds, too?

Andreas

Bug#930780: ITS: pssh

[Mo Zhou]

Source: pssh
Version: 2.3.1-1

I plan to salvage pssh and fix at least the following bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891340

Bug#929318: [pcp] Bug#929318: unblock: papi/5.7.0+dfsg-1

[Andreas Beckmann]

Control: tag -1 - moreinfo

On Thu, 20 Jun 2019 09:26:25 +1000 Nathan Scott  wrote:
> If we cannot use the tested, stable, upstream bugfix update provided
> earlier due to the release constraints,

582 files changed, 14181 insertions(+), 6612 deletions(-)
That is way way too much so short before the planned release date.

> please go ahead and NMU as
> needed Andreas - thanks.

NMU uploaded and unblock request filed.

> FWIW, the PCP development packages do not depend on any PAPI (and
> never have) - it is only older versions of the 'pcp' package itself,
> which contain the pmdapapi binary - now retired to help resolve this
> issue.

I still fail to see why you needed to "fix" this papi bug in pcp (with
the "fix" being removal of papi support). There was no risk of papi
getting autoremoved, there were different people pinging the rc bugs
frequently to reset the timer.


Andreas

PS: The 4.3.2-1 changelog entry contained no details on debian/ changes
in the pcp package at all - besides the Uploaders update that was not
included in the package

Bug#930776: unblock: ionit/0.3.2-1

[Paul Gevers]

Control: tags -1 moreinfo confirmed

Hi Benjamin,

On 20-06-2019 14:05, Benjamin Drung wrote:
> Okay. I prepared a version with just the fixes for the ionit.service
> (debdiff attached). Why not going through testing-proposed-updates? If
> not, the version number will be 0.3.2+really0.2.1-2 instead of 0.2.1-2.

Or better 0.3.2+really0.2.1-1 (as the first version of the upstream
version 0.3.2+really0.2.1) but I don't mind yours if you really prefer that.

testing-proposed-updates doesn't get much (if any) QA. Use unstable
please. debdiff looks acceptable.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#925090: Updating the pcp Uploaders list

[Andreas Beckmann]

Followup-For: Bug #925090
Control: found -1 4.3.2-1

the Uploaders change was not present in 4.3.2-1


Andreas

Bug#930779: unblock: pcp/4.3.2+really4.3.1-0.1

[Andreas Beckmann]

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

Please unblock package pcp
s.t. we can finish the late papi5.7 transition.

Only changelog differs.
I had to start from 4.3.1-1, thus the 4.3.2-1 changelog entry is
missing. There were lots of undocumented debian/ changes in 4.3.2-1 and
the only documented one (uploader cleanup) was not present in the
package.

unblock pcp/4.3.2+really4.3.1-0.1
diff -Nru pcp-4.3.1/debian/changelog pcp-4.3.2+really4.3.1/debian/changelog
--- pcp-4.3.1/debian/changelog  2019-02-25 23:12:54.0 +0100
+++ pcp-4.3.2+really4.3.1/debian/changelog  2019-06-20 14:15:47.0 
+0200
@@ -1,3 +1,11 @@
+pcp (4.3.2+really4.3.1-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainer approval.
+  * Revert to previous upstream release 4.3.1 in order to rebuild against
+libpapi5.7 for buster.
+
+ -- Andreas Beckmann   Thu, 20 Jun 2019 14:15:47 +0200
+
 pcp (4.3.1-1) unstable; urgency=low
 
   * New release (full details in CHANGELOG).

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi,

here we are again for the buster release cycle.

$ curl -s http://ftp.debian.org/debian/dists/buster-backports/Release | head -n4
Origin: Debian Backports
Label: Debian Backports
Suite: buster-backports
Codename: buster-backports

$ curl -s http://ftp.debian.org/debian/dists/buster/Release | head -n4
Origin: Debian
Label: Debian
Suite: testing
Codename: buster

The Suite for buster-backports should be "testing-backports" right now 
and become "stable-backports" when buster gets released.

cheers,
Stefan

On 18.06.17 09:46, Stefan Bühler wrote:
> Hi,
> 
> On Tue, 6 Jun 2017 13:33:03 +0200 Stefan Bühler wrote:
>> Hi,
>>
>> On Sun, 26 Apr 2015 22:01:03 +0200 Stefano Zacchiroli 
>> wrote:
>>> Heya,
>>>
>>> On Tue, Jul 02, 2013 at 10:30:40AM +0200, Stefano Zacchiroli wrote:
   ./wheezy-backports/Release:Suite: wheezy-backports
   ./wheezy-backports/Release:Codename: wheezy-backports

 as you can see from the last 2 lines, both Suite and Codename are set
 to "wheezy-backports" whereas, to be consistent with the rest, the
 suite should be something like "stable-backports".
>>>
>>> JFTR, it looks like this bug has been propagated to the just released
>>> suite Jessie. Currently,
>>> http://ftp.debian.org/debian/dists/jessie-backports/Release reads:
>>>
>>>   Suite: jessie-backports
>>>   Codename: jessie-backports
>>>
>>> To cope with this, I've just hard-coded yet another release name in
>>> sources.d.n configuration, to make sure that the new backports suite is
>>> included.
>>>
>>> It would be nice to fix this now for jessie+1.
>>
>> Didn't work out so far, stretch is affected by this as well:
>>
>> $ curl -s http://ftp.debian.org/debian/dists/stretch-backports/Release
>> Origin: Debian Backports
>> Label: Debian Backports
>> Suite: stretch-backports
>> Codename: stretch-backports
>> [...]
>>
>> Maybe this could still be fixed in time? I guess right now "Suite"
>> should read "testing-backports", hoping it becomes "stable-backports" on
>> release.
> 
> Still broken after the stretch release.  Maybe this time just fix it
> although it is already released (right now there is nothing in it yet
> anyway)?
> 
> As a workaround if someone wants to pin:
> 
> Pin: release o=Debian Backports,a=stable-backports
> 
> They should pin instead or additionally:
> 
> Pin: release o=Debian Backports,n=stretch-backports
> 
> Or (if you don't mix oldstable / stable backports sources):
> 
> Pin: release o=Debian Backports
> 
> Pinning a=stretch-backports ("a=" instead of "n="!) might work now, but
> breaks if this bug gets fixed.
> 
> cheers,
> Stefan
> 

Bug#930777: linux-image-4.19.0-5-amd64: console screen not working

[Jürgen Bausa]

Some additional information:

X runs in the rather unusual resolution of 1366x768x24.

I did not specify this resolution by myself (no xorg.conf). I think it was 
found by X. I tried to specify this resolution for the linux kernel, but it 
had no effect.

Jürgen

Bug#930776: unblock: ionit/0.3.2-1

[Benjamin Drung]

Control: tags -1 - moreinfo

Am Donnerstag, den 20.06.2019, 13:45 +0200 schrieb Paul Gevers:
> Control: tags -1 moreinfo
> 
> Hi Benjamin
> 
> On 20-06-2019 12:52, Benjamin Drung wrote:
> > ionit runs too late for /etc/network/interfaces (RC bug #919690).
> > This
> > is fixed in 0.3.2-1. The debdiff is attached.
> 
> Please, pretty please. At this moment of the release only targeted
> fixes
> [1]. Revert the other upstream changes and upload a version which
> targets the bug only (e.g. with a +really version). Your fix has to
> go
> through unstable, not testing-proposed-updates.

Okay. I prepared a version with just the fixes for the ionit.service
(debdiff attached). Why not going through testing-proposed-updates? If
not, the version number will be 0.3.2+really0.2.1-2 instead of 0.2.1-2.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

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

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet
diff -Nru ionit-0.2.1/debian/changelog ionit-0.2.1/debian/changelog
--- ionit-0.2.1/debian/changelog	2019-01-07 14:22:30.0 +0100
+++ ionit-0.2.1/debian/changelog	2019-06-20 13:55:12.0 +0200
@@ -1,3 +1,10 @@
+ionit (0.2.1-2) testing-proposed-updates; urgency=medium
+
+  * Run ionit.service before systemd-modules-load.service
+  * Run ionit.service before systemd-udev-trigger.service (Closes: #919690)
+
+ -- Benjamin Drung   Thu, 20 Jun 2019 13:55:12 +0200
+
 ionit (0.2.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch
--- ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch	1970-01-01 01:00:00.0 +0100
+++ ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch	2019-06-20 13:51:57.0 +0200
@@ -0,0 +1,33 @@
+From f56792f9b2d618d38207170d61f420bf58e26603 Mon Sep 17 00:00:00 2001
+From: Benjamin Drung 
+Date: Wed, 10 Apr 2019 13:30:47 +0200
+Subject: [PATCH] Run ionit.service before systemd-modules-load.service
+
+In case you want to render modprobe configuration files, the ionit
+service needs to run before systemd-modules-load.service (which runs
+also before sysinit.target and races with ionit.service).
+
+Therefore let ionit.service run explicitly before
+systemd-modules-load.service.
+
+Signed-off-by: Benjamin Drung 
+---
+ ionit.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ionit.service b/ionit.service
+index 1e23862..a67cc88 100644
+--- a/ionit.service
 b/ionit.service
+@@ -3,7 +3,7 @@ Description=Render configuration files from Jinja templates
+ Documentation=man:ionit(1)
+ DefaultDependencies=no
+ After=local-fs.target
+-Before=ferm.service network-pre.target openibd.service shutdown.target sysinit.target
++Before=ferm.service network-pre.target openibd.service shutdown.target sysinit.target systemd-modules-load.service
+ Wants=network-pre.target
+ RequiresMountsFor=/usr
+ 
+-- 
+2.20.1
+
diff -Nru ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch
--- ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch	1970-01-01 01:00:00.0 +0100
+++ ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch	2019-06-20 13:52:07.0 +0200
@@ -0,0 +1,40 @@
+From 11b6dbab36c0b1d983179d10e3a079e0f31102bc Mon Sep 17 00:00:00 2001
+From: Benjamin Drung 
+Date: Thu, 20 Jun 2019 12:14:42 +0200
+Subject: [PATCH] Run ionit.service before systemd-udev-trigger.service
+
+live-boot creates a `/etc/network/interfaces` file that contains an
+`allow-hotplug` entry for the network boot device `eth0`.
+`systemd-udev-trigger.service` executes
+`/lib/udev/rules.d/80-ifupdown.rules` which calls
+`/lib/udev/ifupdown-hotplug`. This scripts starts `ifup@eth0.service`.
+Afterwards `ionit` runs and might replace `allow-hotplug` by `auto` if a
+template `/etc/network/interfaces.jinja` is provided. Then
+`networking.service` and `ifup@eth0.service` will start at the same time
+and race.
+
+Therefore let `ionit.service` run before `systemd-udev-trigger.service`
+to support generating `/etc/network/interfaces`.
+
+Bug-Debian: https://bugs.debian.org/919690
+Signed-off-by: Benjamin Drung 
+---
+ ionit.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ionit.service b/ionit.service
+index a67cc88..8f56106 100644
+--- a/ionit.service
 b/ionit.service
+@@ -3,7 +3,7 @@ Description=Render configuration files from Jinja templates
+ 

Bug#926780: unblock gcc-8/8.3.0-7 and updated cross builds

[Paul Gevers]

Control: tags -1 wontfix
Control: close -1

Hi Matthias,

On 06-06-2019 12:01, Paul Gevers wrote:> doko, I know you are
maintaining quite some key packages, so extra work> is probably not what
you are looking for, but neither are we and on top> of that, we don't
like turning down unblock request (hence the time it> took to reply, at
least that's the reason for me). In this case, and> also for gcc-7
(hence cc of that bug) it would be great if we could> understand from
the beginning why you believe why we should except this.> And no, I am
not going to find upstream repositories and bug trackers> for all the
packages that we get unblock requests for. You'll have to> help us
making the judgment.
I take the lack of reply from your side to mean that you are not
pursuing to drive this further to an unblock. To clean up the unblock
that probably will not see any further action, I am closing it as
wontfix. If you are still interested, you can of course reopen, but be
aware that the time for unblocks for buster is running out quickly now [1].

Sorry.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/06/msg3.html



signature.asc
Description: OpenPGP digital signature

Bug#926884: distcc: Does not work with clang

[Shawn Landden]

#1) I talked to some other dds and this is not a release critical bug

#2) this is a different bug from the python script bug.

Regarding the other bug:
That script *does* work (I developed and use it on Debian), however that is
a nasty bug and I don't know how to solve it.

Shawn.

El jue., 20 jun. 2019 1:13, Christian Marillat 
escribió:

> > Package: distcc
> > Followup-For: Bug #926884
> >
> > This package should not be released in Buster with this bug,
> > clang is an important compiler (and much easier for cross-compiling)
> > and not working with it is too big of a bug.
>
> I'm sorry but no. Your python script doesnt work for Debian See #920709
>
> Christian
>

Bug#930666: Please document consensus on use of dh sequencer

[Bill Allombert]

On Tue, Jun 18, 2019 at 06:24:45PM -0700, Russ Allbery wrote:
>  The following targets are required and must be implemented by
>  ``debian/rules``: ``clean``, ``binary``, ``binary-arch``,
> -``binary-indep``, ``build``, ``build-arch`` and ``build-indep``. These
> -are the targets called by ``dpkg-buildpackage``.
> +``binary-indep``, ``build``, ``build-arch`` and ``build-indep``.  (When
> +using ``dh``, these are implemented using the wildcard pattern shown
> +above.)  These are the targets called by ``dpkg-buildpackage``.

Hello Russ,

I find this layering violation rather confusing especially if dh should
be seen as the rule and not the exception.

There are maybe an hundred places where we could mention dh,
with statement like "when using dh, do something else".

Maybe what we need is a separate 'dh packaging manual' where packaging
is explained from dh point of view.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#930778: debian-maintainers: Keyboard/Mouse not working under X session with LxQt DE

[Jonathan]

Package: debian-maintainers
Severity: normal

It seems to be a problem with the correct package dependencies not being 
included in lxqt package. The problem is solved when installing manually these 
packages:

xserver-xorg-input-evdev xserver-xorg-input-libinput xserver-xorg-input-mouse 
xserver-xorg-input-kbd

In tty session the keyboard is working.

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

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

Bug#930776: unblock: ionit/0.3.2-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Benjamin

On 20-06-2019 12:52, Benjamin Drung wrote:
> ionit runs too late for /etc/network/interfaces (RC bug #919690). This
> is fixed in 0.3.2-1. The debdiff is attached.

Please, pretty please. At this moment of the release only targeted fixes
[1]. Revert the other upstream changes and upload a version which
targets the bug only (e.g. with a +really version). Your fix has to go
through unstable, not testing-proposed-updates.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/06/msg3.html



signature.asc
Description: OpenPGP digital signature

Bug#930618: node-terser does not install file mentioned in package.json's main field and fails Error: Cannot find module 'terser'

[Xavier]

Hello,

there is something wrong with your patch:
W: node-terser source: binaries-have-file-conflict node-terser
uglifyjs.terser usr/lib/nodejs/terser/dist/bundle.js

Your link overrides a regular file

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Bill Allombert]

On Thu, Jun 20, 2019 at 11:09:10AM +0200, Stefan Fritsch wrote:
> Hi Bill,
> 
> I have some new info:

Thanks for coming back to me!

> When submission fails, popcon-upload dies with a timeout. There should
> probably be a randomized sleep to distribute the server load better. I
> think there could be a lot more popcon submissions if this is done.

What is the time in /etc/cron.d/popularity-contest ?
(something like 33 5 * * *)

Does it work better if you change it to some other time ?
What cron ae you using

> Also, popcon-upload should log errors to syslog.
> 
> The fallback to email only happens if "$MODE" = "--crond". But if the
> script is called via cron.daily it gets called without parameters and
> this never happens. Is this intentional?

This is to avoid sending the email twice. The problem is that there is
no way to know if the email was received.

The script is normally called by /etc/cron.d/popularity-contest with
--crond.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#930647: [Pkg-javascript-devel] Bug#930647: this is a timezone issue

[Pirate Praveen]

On 2019, ജൂൺ 20 2:07:38 PM IST, Paolo Greppi  wrote:
>nodejs -e 'dsv = require("."); console.log(dsv.csvFormat([{date: new
>Date(2018, 0, 1)}]));'
>TZ='UTC' nodejs -e 'dsv = require(".");
>console.log(dsv.csvFormat([{date: new Date(2018, 0, 1)}]));'
>TZ='EST' nodejs -e 'dsv = require(".");
>console.log(dsv.csvFormat([{date: new Date(2018, 0, 1)}]));'
>TZ='America/Los_Angeles' nodejs -e 'dsv = require(".");
>console.log(dsv.csvFormat([{date: new Date(2018, 0, 1)}]));'
>
>outputs respectively:
>2017-12-31T23:00Z
>2018-01-01
>2018-01-01T05:00Z
>2018-01-01T08:00Z
>
>looking at the 1st failing test:
>test.deepEqual(dsv.csvFormat([{date: new Date(2018, 0, 1)}]),
>"date\n2018-01-01T08:00Z");
>it looks like the upstream developers live in California
>
>so it can be fixed with:
>https://salsa.debian.org/js-team/node-d3-dsv/commit/9a445e4a6c01237c5e73a71daa8ad142450007e9
>
>Paolo

Thanks for the fix. I was thinking a change in some timezone library caused it 
as it had worked in previous versions.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#930675: sddm: Unable to start a parallel user session

[Bert Schlumwig]

Package: sddm
Version: 0.18.0-1
Followup-For: Bug #930675

Sorry, but this bug is still existing:

After a reboot, I was not able to start a parallel session any more.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.71
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libpam0g1.3.1-5
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5network5  5.11.3+dfsg1-1
ii  libqt5qml5  5.11.3-4
ii  libqt5quick55.11.3-4
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-5
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  qml-module-qtquick2 5.11.3-4
ii  x11-common  1:7.7+19
ii  xserver-xorg [xserver]  1:7.7+19

Versions of packages sddm recommends:
ii  haveged 1.9.1-7
ii  libpam-systemd  241-5
ii  sddm-theme-breeze [sddm-theme]  4:5.14.5.1-1

Versions of packages sddm suggests:
pn  libpam-kwallet5   
pn  qtvirtualkeyboard-plugin  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#930777: linux-image-4.19.0-5-amd64: console screen not working

[Jürgen Bausa]

Package: src:linux
Version: 4.19.37-3
Severity: important

Dear Maintainer,

I have just updated my notebook (Acer C-740, originally a Chromebook) from 
stretch to buster.
While in stretch everything was fine, after upgrading to buster console output 
is broken.
I see just a black screen which flashes about every second. grub and X output 
are fine.
When switching from X to console, I get again the flashing. Switching back to X 
everything is good.
In addition I found out that the boot process takes about 10 s longer than 
normal.
When I start the system with the old stretch kernel which is still installed, 
everything
is fine.

To make grub console output work I had to add "GRUB_GFXMODE=1024x768x16" to 
/etc/default/grub.
However, I did this when initially installing debian some time ago (maybe 
jessie).

I tried the 4.19 kernel image from Sid but it did not make a difference.

I also tried to put nomodeset to the kernel command line. Then I get a readable 
console,
but X doesnt start.

Also tried different grub options with no success.

Regards,

Jürgen


-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=52fdfb17-4761-450f-9daa-57d87b982104 ro quiet tpm_tis.interrupts=0

** Not tainted

** Kernel log:
[4.056855] lp: driver loaded but no devices found
[4.071633] ppdev: user-space parallel port driver
[4.085538] RPC: Registered named UNIX socket transport module.
[4.085540] RPC: Registered udp transport module.
[4.085541] RPC: Registered tcp transport module.
[4.085542] RPC: Registered tcp NFSv4.1 backchannel transport module.
[4.087663] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,discard
[4.397884] chromeos ramoops using acpi device.
[4.443961] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[4.455816] elan_i2c i2c-ELAN:00: i2c-ELAN:00 supply vcc not found, 
using dummy regulator
[4.455836] elan_i2c i2c-ELAN:00: Linked as a consumer to regulator.0
[4.456731] battery: ACPI: Battery Slot [BAT0] (battery present)
[4.464100] ACPI: AC Adapter [AC] (on-line)
[4.500842] tpm_tis 00:04: 1.2 TPM (device-id 0xB, rev-id 16)
[4.561792] iTCO_vendor_support: vendor-support=0
[4.574024] elan_i2c i2c-ELAN:00: Elan Touchpad: Module ID: 0x005a, 
Firmware: 0x0006, Sample: 0x0008, IAP: 0x0009
[4.575535] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[4.575596] iTCO_wdt: Found a Wildcat Point_LP TCO device (Version=2, 
TCOBASE=0x1060)
[4.588794] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[4.588983] input: Elan Touchpad as 
/devices/pci:00/INT3432:00/i2c-0/i2c-ELAN:00/input/input4
[4.601308] input: PC Speaker as /devices/platform/pcspkr/input/input5
[4.601491] sd 0:0:0:0: Attached scsi generic sg0 type 0
[4.643865] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms 
ovfl timer
[4.643867] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[4.643868] RAPL PMU: hw unit of domain package 2^-14 Joules
[4.643869] RAPL PMU: hw unit of domain dram 2^-14 Joules
[4.643870] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[4.694645] audit: type=1400 audit(1561028664.383:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=271 
comm="apparmor_parser"
[4.696422] audit: type=1400 audit(1561028664.387:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=270 comm="apparmor_parser"
[4.719415] audit: type=1400 audit(1561028664.407:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=277 comm="apparmor_parser"
[4.724028] systemd-journald[204]: Received request to flush runtime journal 
from PID 1
[4.747740] audit: type=1400 audit(1561028664.435:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=285 
comm="apparmor_parser"
[4.747745] audit: type=1400 audit(1561028664.435:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=285 comm="apparmor_parser"
[4.752278] audit: type=1400 audit(1561028664.443:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=276 comm="apparmor_parser"
[4.752282] audit: type=1400 audit(1561028664.443:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=276 
comm="apparmor_parser"
[4.752285] audit: type=1400 audit(1561028664.443:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/cupsd//third_party" pid=276 comm="apparmor_parser"
[4.775381] audit: type=1400 audit(1561028664.463:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Michael Biebl]

Am 20.06.19 um 11:25 schrieb Jonathan Carter:
> I just have a small proposal:
> 
> Selecting "Gnome on Xorg" is really easy from GDM for anyone who has
> trouble on Wayland. It might be worth while adding that to the release
> notes so that users who are not quite ready for Wayland yet know that
> there's an easy way to get the old behavior back without having to
> re-install stretch or some other distro.

That seems like a very good idea to document this prominently in the
release notes. After all, we do install both Xorg and Wayland support,
so switching the desktop session is indeed trivial.

I was about to file a bug report against release-notes to add such a
section, but then it probably makes sense to wait for a final decision.

Related to that, we already have
https://salsa.debian.org/ddp-team/release-notes/commit/5496e24

Assuming it is decided, that the default is switched back to Xorg, this
existing paragraph in the release notes should be adapted accordingly.

Michael

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

Bug#930776: unblock: ionit/0.3.2-1

[Benjamin Drung]

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

Please unblock package ionit

ionit runs too late for /etc/network/interfaces (RC bug #919690). This
is fixed in 0.3.2-1. The debdiff is attached.

ionit is a quite new and very small tool (popcon count: 4), which is
developed and used by us. It has 100% test coverage (run at build time
and as autopkgtest).

unblock ionit/0.3.2-1

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

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

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet
diff -Nru ionit-0.2.1/debian/changelog ionit-0.3.2/debian/changelog
--- ionit-0.2.1/debian/changelog2019-01-07 14:22:30.0 +0100
+++ ionit-0.3.2/debian/changelog2019-06-20 12:21:44.0 +0200
@@ -1,3 +1,13 @@
+ionit (0.3.2-1) unstable; urgency=medium
+
+  * New upstream release.
+- Support specifying a configuration file
+- Support specifying --config multiple times
+- Run ionit.service before systemd-modules-load.service
+- Run ionit.service before systemd-udev-trigger.service (Closes: #919690)
+
+ -- Benjamin Drung   Thu, 20 Jun 2019 12:21:44 
+0200
+
 ionit (0.2.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ionit-0.2.1/ionit ionit-0.3.2/ionit
--- ionit-0.2.1/ionit   2019-01-07 14:01:10.0 +0100
+++ ionit-0.3.2/ionit   2019-06-20 12:17:42.0 +0200
@@ -28,6 +28,7 @@
 
 import ionit_plugin
 
+DEFAULT_CONFIG = "/etc/ionit"
 LOG_FORMAT = '%(asctime)s %(name)s %(levelname)s: %(message)s'
 SCRIPT_NAME = "ionit"
 
@@ -86,23 +87,34 @@
 return context
 
 
-def collect_context(directory):
+def get_config_files(paths):
+"""Return files for the given paths (could either be files or 
directories)."""
+logger = logging.getLogger(SCRIPT_NAME)
+files = []
+for path in paths:
+logger.debug("Searching for configuration files in '%s'...", path)
+try:
+if os.path.isfile(path):
+files.append(path)
+else:
+files += sorted([os.path.join(path, f) for f in 
os.listdir(path)])
+except OSError as error:
+logger.warning("Failed to read configuration directory: %s", error)
+logger.debug("Configuration files: %s", files)
+return files
+
+
+def collect_context(paths):
 """Collect context that will be used when rendering the templates"""
 logger = logging.getLogger(SCRIPT_NAME)
-logger.debug("Collecting context from '%s'...", directory)
-try:
-files = sorted(os.listdir(directory))
-except OSError as error:
-logger.warning("Failed to read configuration directory: %s", error)
-files = []
+logger.debug("Collecting context...")
 
 failures = 0
 context = {}
 
-for filename in files:
+for file in get_config_files(paths):
 file_context = None
-file = os.path.join(directory, filename)
-extension = os.path.splitext(filename)[1]
+extension = os.path.splitext(file)[1]
 try:
 if extension == ".json":
 logger.info("Reading configuration file '%s'...", file)
@@ -184,9 +196,9 @@
 def main(argv):
 """Main function with argument parsing"""
 parser = argparse.ArgumentParser()
-parser.add_argument("-c", "--config", default="/etc/ionit",
-help="Configuration directory containing context for 
rendering (default: "
- "%(default)s)")
+parser.add_argument("-c", "--config", action="append",
+help="Configuration directory/file containing context 
for rendering "
+ "(default: %s)" % (DEFAULT_CONFIG,))
 parser.add_argument("-t", "--templates", default="/etc",
 help="Directory to search for Jinja templates 
(default: %(default)s)")
 parser.add_argument("-e", "--template-extension", default="jinja",
@@ -197,6 +209,8 @@
 help="Decrease output verbosity to warnings and 
errors",
 action="store_const", const=logging.WARNING)
 args = parser.parse_args(argv)
+if args.config is None:
+args.config = [DEFAULT_CONFIG]
 logging.basicConfig(level=args.log_level, format=LOG_FORMAT)
 logger = logging.getLogger(SCRIPT_NAME)
 
diff -Nru ionit-0.2.1/ionit.py ionit-0.3.2/ionit.py
--- ionit-0.2.1/ionit.py2019-01-07 14:01:10.0 +0100
+++ ionit-0.3.2/ionit.py2019-06-20 12:17:42.0 +0200
@@ -28,6 +28,7 @@
 
 import ionit_plugin
 
+DEFAULT_CONFIG = "/etc/ionit"
 LOG_FORMAT = '%(asctime)s %(name)s %(levelname)s: %(message)s'
 SCRIPT_NAME = "ionit"
 
@@ -86,23 +87,34 @@
 return context
 

Bug#930775: dialog: fails when window gets resized

[Alex Tsitsimpis]

Package: dialog
Version: 1.3-20190211-1
Severity: normal

Dear Maintainer,

When resizing a window where dialog runs, dialog exits with error. I tested
this both on Stretch with dialog from Buster, and on Buster itself.

The easiest way to reproduce it is:

1) Run dialog on a terminal window:
$ dialog --msgbox test 0 0

2) Resize the terminal window (or send SIGWINCH to the dialog process).

In the above scenario dialog exits with error.

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

Kernel: Linux 4.19.5-arr-9-g4694f1517d3f (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dialog depends on:
ii  debianutils   4.8.1.1
ii  libc6 2.24-11+deb9u4
ii  libncursesw6  6.1+20181013-2
ii  libtinfo6 6.1+20181013-2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information