Bug#885157: thunderbird: Upgrading from 1:52.5.0-1 to 1:52.5.2-1 enforces the AppArmor profile

[intrigeri]

Package: thunderbird
Version: 1:52.5.2-1
Severity: serious
X-Debbugs-Cc: Simon Deziel , Guido Günther 

Hi,

I've upgraded thunderbird from 1:52.5.0-1 to 1:52.5.2-1 in my test sid
VM after double-checking that
/etc/apparmor.d/disable/usr.bin.thunderbird existed and the profile
was not loaded.

The upgrade removed /etc/apparmor.d/disable/usr.bin.thunderbird
(because it's not shipped as a file owned by the package anymore) and
thus loaded the profile in enforced mode. I think this is not what was
intended with commit 8c57218.

I'm setting RC severity because enabling the AppArmor profile breaks
too much functionality, which is why we've decided to disable it
by default.

postinst got this added in 1:52.5.2-1:

# Disable apparmor on new installations and when we're 
upgrading from
# a version that had it enabled by default
if test -z "$2" || dpkg --compare-versions "$2" le "1:52.5.0-1~"; then
mkdir -p /etc/apparmor.d/disable
ln -s /etc/apparmor.d/usr.bin.thunderbird  
/etc/apparmor.d/disable/usr.bin.thunderbird
fi

The buggy behavior I'm reporting is caused by:

  $ dpkg --compare-versions "1:52.5.0-1" le "1:52.5.0-1~"
  $ echo $?
  1

… which might be surprising but it does make sense.

While of course:

  $ dpkg --compare-versions "1:52.5.0-1" le "1:52.5.0-1"
  $ echo $?
  0

… which is what the comparison should instead have been in the first
place, in the 1:52.5.2-1 upload.

But now that we got this wrong once, I think it'll be very hard to
recover and provide the intended behavior in _all_ cases. I think
we'll have to disable the profile on next upgrade again in many cases,
in order to revert the buggy change applied by this upgrade on sid
systems. I believe this could be achieved by replacing the test quoted
above with:

  test -z "$2" || dpkg --compare-versions "$2" le "1:52.5.2-1"

… which is hopefully equivalent to "the package version we're
upgrading from did forcibly enable the AppArmor profile in at least
some cases when it should not have".

Sadly, in some cases this will disable the profile even though the
administrator had opted-in and manually enabled it (i.e.
we reintroduce a one-time instance of #884191). I don't know how to
fix this, and IMO we should not block on it before we address the bug
I'm reporting here, but perhaps it's worth a NEWS.Debian entry?

Cheers,
-- 
intrigeri

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Andreas Tille]

Hi Gudjon,

On Mon, Dec 25, 2017 at 08:04:03AM +0100, Gudjon I. Gudjonsson wrote:
> > Which repo are you building from right now? I'd like to try it out just to 
> > see what
> > happens.
> > 
> I tried all options but without success.
> But the only thing that works in both sbuild and normal environment is to add 
> dependency 
> on elyxer. 

You should stop building the package on your local machine and use pbuilder
instead anyway.  This should give you initial lyx settings and is the way
to build a package anyway.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#724907: lintian: [new check] warn on deprecated find -perm +x option

[Andreas Metzler]

On 2017-12-22 Chris Lamb  wrote:
>> lintian: [new check] warn on deprecated find -perm +x option

> One problem here is how to avoid all the false positives in
> changelogs — both Debian and upstream — that refer to, for
> example, "moving away from deprecated -perm +x" option. :)

Hello,

thanks for maintaining lintian!

Isn't this a common problem (perhaps even with a common solution ;-)
for lintian checks?

Anyway. - I think this report can be closed. Findutils upstream has made
a release with the respective change about two years ago and Debian (and
everybody else) has shipped it in a stable release.

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

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Gudjon I. Gudjonsson]

Hi Sven

> 
> So if you do not use LyX for interactive document writing just rm -r ~/.lyx 
> in your
> build environment and it should reconfigure on the next invocation.
> 
> Another possibility would be that lyx fails to import and convert the manual 
> to the
> current LyX 2.2.x document format.
> Which repo are you building from right now? I'd like to try it out just to 
> see what
> happens.
> 
I tried all options but without success.
But the only thing that works in both sbuild and normal environment is to add 
dependency 
on elyxer. 

Latest changes are pushed to git and I uploaded the package to my private 
repository:

deb-src [allow-insecure=yes allow-downgrade-to-insecure=yes] 
http://gudjon.org/debian/ source/
deb [allow-insecure=yes allow-downgrade-to-insecure=yes] 
http://gudjon.org/debian/ amd64/

Can you please take a look?

Merry Christmash
Gudjon

Bug#884970: libexpat1-dev: libexpat.la missing

[Kipp Cannon]

On Fri, 2017-12-22 at 10:18 +0100, László Böszörményi (GCS) wrote:
> Control: tags -1 +moreinfo
> 
> On Fri, Dec 22, 2017 at 9:38 AM, Kipp Cannon
>  wrote:
> >* What led up to the situation?
> > 
> > attempting to compile a separate, unrelated, auto-
> > everything/libtool-ized
> > package, fails with
> > 
> > "/bin/sed: can't read /usr/lib/x86_64-linux-gnu/libexpat.la: No
> > such file or
> > directory
> > libtool:   error: '/usr/lib/x86_64-linux-gnu/libexpat.la' is not a
> > valid
> > libtool archive"
> 
>  Which is that package you are trying to compile?
> 
[snip]
> 
> Regards,
> Laszlo/GCS

It's an in-house software package.  It can be found here

http://software.ligo.org/lscsoft/source/gstlal-ugly-1.3.1.tar.gz

But if you were to try to reproduce the problem, compiling that
software requires several other in-house packages to be installed
first, including

http://software.ligo.org/lscsoft/source/gstlal-1.2.1.tar.gz

http://software.ligo.org/lscsoft/source/ldas-tools-framecpp-2.5.8.tar.g
z

and

http://software.ligo.org/lscsoft/source/gds-2.18.4.tar.gz

That last one is optional, but it's the optional component in gstlal-
ugly that requires GDS that trips over libexpat.

-Kipp

Bug#885149: exim4-base: exim4 and SMTPUTF8

[Andreas Metzler]

On 2017-12-24 Hanno Wagner  wrote:
> Package: exim4-base
> Version: 4.89-2+deb9u2
> Severity: wishlist

> exim4 isn't able to use SMTPUTF8 in it's default configuration within
> Debian.
> According to
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-internationalisation.html
> this is a decision to take while compiling exim4 (you need libidn and
> libidn2 and some additional configuration lines in the Makefile, see
> src/EDITME), so this is not something you can configure afterwards.

> I'd like to ask you to enable this in exim as a default. I already had
> the situation that a normal site tried to send a mail with UTF8-Header
> and it got bounced back to the sender.
[...]

Hello,

I suspect that message would have bounced with SMTPUTF8 even if exim4
was built with SMTPUTF8 support because the sender obviously is a broken
implementation that probably would not have enabled SMTPUTF8 at EHLO.

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

Bug#825095: [Python-modules-team] Bug#825095: python-backports-shutil-get-terminal-size: clashes over backports/__init__.py with python-backports.ssl-match-hostname

[Sandro Tosi]

control: reopen -1
control: blocks -1 884690

(resending now that the bug is unarchived)

On Mon, May 23, 2016 at 10:50 AM, Aaron M. Ucko  wrote:
> Package: python-backports-shutil-get-terminal-size
> Version: 1.0.0-1
> Severity: serious
> Justification: Policy 6.6(4)
>
> python-backports-shutil-get-terminal-size is impossible to install
> alongside python-backports.ssl-match-hostname:
>
>   Unpacking python-backports-shutil-get-terminal-size (1.0.0-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/python-backports-shutil-get-terminal-size_1.0.0-1_all.deb
>  (--unpack):
>trying to overwrite 
> '/usr/lib/python2.7/dist-packages/backports/__init__.py', which is also in 
> package python-backports.ssl-match-hostname 3.4.0.2-1
>
> Could you please take a look?

this is still happening!

i suspect the reason is because
python-backports-shutil-get-terminal-size ships a __init__.py file
upstream and that's the one that's actually being installed, while all
the other packages overriding dh_python2 to add "--namespace
backports" would install a file with a different content.

cfr:

$ cat /usr/lib/python2.7/dist-packages/backports/__init__.py
__path__ = __import__('pkgutil').extend_path(__path__, __name__)

as installed by python-backports.ssl-match-hostname

with

$ cat backports/__init__.py
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

as installed by python-backports-shutil-get-terminal-size; and if you
try to install them both:

Selecting previously unselected package
python-backports-shutil-get-terminal-size.
(Reading database ... 586099 files and directories currently installed.)
Preparing to unpack
.../python-backports-shutil-get-terminal-size_1.0.0-4_all.deb ...
Unpacking python-backports-shutil-get-terminal-size (1.0.0-4) ...
dpkg: error processing archive
/var/cache/apt/archives/python-backports-shutil-get-terminal-size_1.0.0-4_all.deb
(--unpack):
trying to overwrite
'/usr/lib/python2.7/dist-packages/backports/__init__.py', which is
also in package python-backports.functools-lru-cache 1.4-1
Errors were encountered while processing:
/var/cache/apt/archives/python-backports-shutil-get-terminal-size_1.0.0-4_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

this means either any of the other backports packages are installed or
ipython is not installable (as it depends on
python-backports-shutil-get-terminal-size)

can you please fix this asap?

Thanks,

On Mon, May 23, 2016 at 10:50 AM, Aaron M. Ucko  wrote:
> Package: python-backports-shutil-get-terminal-size
> Version: 1.0.0-1
> Severity: serious
> Justification: Policy 6.6(4)
>
> python-backports-shutil-get-terminal-size is impossible to install
> alongside python-backports.ssl-match-hostname:
>
>   Unpacking python-backports-shutil-get-terminal-size (1.0.0-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/python-backports-shutil-get-terminal-size_1.0.0-1_all.deb
>  (--unpack):
>trying to overwrite 
> '/usr/lib/python2.7/dist-packages/backports/__init__.py', which is also in 
> package python-backports.ssl-match-hostname 3.4.0.2-1
>
> Could you please take a look?
>
> Thanks!
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.5.0-2-amd64 (SMP w/4 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)
>
> ___
> Python-modules-team mailing list
> python-modules-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#884592: [Pkg-fonts-devel] Bug#884592: fonts-fantasque-sans: variants use the same name, making them unusable in most programs

[Vasudev Kamath]

Adam Borowski  writes:

>>
>> 1. Ship one variant in the fontconfig path and rest variants are placed
>>under /usr/share/fantasque-sans and mention this in NEWS and
>>README.Debian.
>
> That'd require manual action of the user, and wouldn't be easily
> discoverable.

Yeah that is my thought also.

>
>> 2. Provide different variants as part of fonts-fantasque-sans-[variant]
>>package.
>
> I'd rather split OTF vs TTF vs WOFF vs SVG -- an user hardly ever needs more
> than one format.

OK sounds correct.

>
>> 1 is bit ugly as user needs to put right variant into their fontconfig
>> path. 2nd one is elegant but then we some how need to handle the
>> transition. Question will be what will fonts-fantasque-sans meta package
>> will depend on :-).
>
> I'd go with 3. encode variant in the "family" field.
>
> If you look at some other fonts (better visible in a GTK2 font picker rather
> than in the GTK3 one), you can find variants usually presented as families,
> such as "Comic Neue" vs "Comic Neue Angular".

So what should be new package names?. Tell me from below which sounds
correct.

fonts-fantasque-noloopk-sans-ttf or fonts-fantasque-sans-noloopk-ttf

Basically fonts-fantasque-[variant]-sans-[type] or 
fonts-fantasque-sans-[variant]-[type]

Let me know which sounds correct. For me second one seems correct, but
I'm open to suggestion.

Bug#856080: Raising severity of bugs for esound reverse depends

[Jeremy Bicha]

Control: severity -1 serious

We do not intend to release Debian 10 "Buster" with esound. Therefore,
I am raising the severity of this bug now.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#884690: ImportError with astroid 1.5

[Sandro Tosi]

control: reassign -1 python-backports.functools-lru-cache

On Mon, Dec 18, 2017 at 6:31 AM, Matthias Klose  wrote:
> Package: python-astroid
> Version: 1.5.3-2
> Severity: serious
> Tags: sid buster
>
> Installing python-astroid and running
>
> $ python -c 'from astroid.node_classes import as_string'
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/astroid/__init__.py", line 57, in 
> 
> from astroid.nodes import *
>   File "/usr/lib/python2.7/dist-packages/astroid/nodes.py", line 30, in 
> 
> from astroid.node_classes import (
>   File "/usr/lib/python2.7/dist-packages/astroid/node_classes.py", line 24, in
> 
> from astroid import bases
>   File "/usr/lib/python2.7/dist-packages/astroid/bases.py", line 25, in 
> 
> MANAGER = manager.AstroidManager()
>   File "/usr/lib/python2.7/dist-packages/astroid/util.py", line 24, in 
> 
> lambda: importlib.import_module('.' + module_name, 'astroid'))
>   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name)
>   File "/usr/lib/python2.7/dist-packages/astroid/manager.py", line 21, in 
> 
> from astroid.interpreter._import import spec
>   File "/usr/lib/python2.7/dist-packages/astroid/interpreter/_import/spec.py",
> line 19, in 
> from backports.functools_lru_cache import lru_cache
> ImportError: No module named backports.functools_lru_cache

the problem is in backports.functools_lru_cache, as it doesnt install
a __init__.py if it's the only installed packages of the backports
namespace

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#885156: O: daemonize -- tool to run a command as a daemon

[Sandro Tosi]

Package: wnpp
Severity: normal

I intend to orphan the daemonize package.

The package description is:
 As defined in W. Richard Stevens’ 1990 book, UNIX Network Programming
 (Addison-Wesley, 1990), a daemon is “a process that executes ‘in the
 background’ i.e., without an associated terminal or login shell) either
 waiting for some event to occur, or waiting to perform some specified task on a
 periodic basis.” Upon startup, a typical daemon program will:
 .
  * Close all open file descriptors (especially standard input, standard output
and standard error)
  * Change its working directory to the root filesystem, to ensure that it
doesn’t tie up another filesystem and prevent it from being unmounted
  * Reset its umask value
  * Run in the background (i.e., fork)
  * Disassociate from its process group (usually a shell), to insulate itself
from signals (such as HUP) sent to the process group
  * Ignore all terminal I/O signals
  * Disassociate from the control terminal (and take steps not to reacquire one)
  * Handle any SIGCLD signals
 .
 Most programs that are designed to be run as daemons do that work for
 themselves. However, you’ll occasionally run across one that does not. When
 you must run a daemon program that does not properly make itself into a true
 Unix daemon, you can use daemonize to force it to run as a true daemon.

Bug#885155: chromium: Enable audio/microphone support (Again)

[johnw]

https://www.chromium.org/administrators/policy-list-3#AudioCaptureAllowed

--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC

Bug#885155: chromium: Enable audio/microphone support (Again)

[John Wong]

Package: chromium
Version: 63.0.3239.84-1
Severity: wishlist

Dear Maintainer,

 After upgrade chromium, I can not use microphone/voice search with 
chromium any more,
 It work well before upgrade, please help, thanks.

o< - >o

--- /usr/share/chromium/master_preferences  2017-12-04 00:05:00.0 
+0800
+++ /tmp/master_preferences 2017-12-25 12:29:07.927500500 +0800
@@ -27,7 +27,7 @@
 "enabled": false
   },
   "hardware": {
-"audio_capture_enabled": false
+"audio_capture_enabled": true
   },
   "default_apps": "noinstall",
   "hide_web_store_icon": true,

o< - >o

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

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

Versions of packages chromium depends on:
ii  chromium-common  63.0.3239.84-1
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.26.1-2
ii  libavcodec57 7:3.4.1-1+b1
ii  libavformat577:3.4.1-1+b1
ii  libavutil55  7:3.4.1-1+b1
ii  libc62.25-5
ii  libcairo21.15.8-3
ii  libcups2 2.2.6-3
ii  libdbus-1-3  1.12.2-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.5-3
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-0.1
ii  libgcc1  1:7.2.0-18
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.2-4
ii  libgtk-3-0   3.22.26-2
ii  libharfbuzz0b1.7.2-1
ii  libicu57 57.1-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.16-1+b1
ii  libnss3  2:3.34-1
ii  libopus0 1.2.1-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpng16-16  1.6.34-1
ii  libpulse011.1-4
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   7.2.0-18
ii  libvpx4  1.6.1-3
ii  libwebp6 0.6.0-4
ii  libwebpdemux20.6.0-4
ii  libwebpmux3  0.6.0-4
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-5.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-5
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
pn  fonts-liberation  

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#884780: RFS: piu-piu/1.0-1 [ITP]

[Adam Borowski]

On Sat, Dec 23, 2017 at 02:40:05PM +0300, Ivan Marov wrote:
> Hi!
> Actualy it's just a bash script, one file. There are no 'source', it is the
> source. What shal i do?
> https://github.com/vaniacer/piu-piu-SH/blob/master/piu-piu

A source package for a shell script is pretty trivial -- there's no
compilation step.

Most of the files needed are already included as here-docs in that
"debianizer" of yours.  That is:
* changelog
* control (plus a Source section)
* copyright
* man page

The rest are:
.--==[ source/format ]
3.0 (quilt)
+--==[ compat ]
10
+--==[ install ]
piu-piu usr/games
+--==[ rules ]
#!/usr/bin/make -f
%:
dh $@
`


Merry Saturnalia and copycat festivities!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#885154: ITP: libjs-browser-request -- Browser library compatible with the node-request package

[Hubert Chathi]

Package: wnpp
Owner: Hubert Chathi 
Severity: wishlist

* Package name: libjs-browser-request
  Version : 0.3.3
  Upstream Author : Jason Smith
* URL or Web page : https://github.com/jhs/browser-request
* License : Apache License 2.0
  Description : Browser library compatible with the node-request package

This package provides a library compatible with the request library for
Node.js.  The library can be used as a UMD module, or through a
JavaScript bundling tool that resolves require() statements such as
node-browserify-lite.

Bug#749198: libxml2: incorrect Relax NG parser error with included grammar

[Vincent Lefevre]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=326174
Control: found -1 2.9.4+dfsg1-5.2

On 2014-05-25 03:01:45 +0200, Vincent Lefevre wrote:
> Relax NG is broken: I get an Relax NG parser error on correct .rng files.
> I've attached a testcase.

This is actually due to comments before the root element grammar.
Removing these comments makes the failure disappear.

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

Bug#885142: tasksel: Use non-traditional packages for orca

[Jeremy Bicha]

From a58126d2de264d1ca91be439e3b5fb5b55a2e57d Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 24 Dec 2017 09:48:16 -0500
Subject: [PATCH] Use non-transitional package for orca

Closes: #885142
---
 debian/control | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index ef6a0a48..55fcbe43 100644
--- a/debian/control
+++ b/debian/control
@@ -110,7 +110,7 @@ Recommends:
 # accessibility support
 	kdeaccessibility,
 # orca works with kde, adding accessibility
-	gnome-orca,
+	orca,
 # cd/dvd burner
 	k3b,
 	k3b-i18n,
@@ -175,7 +175,7 @@ Recommends:
 # gui for configuration of the print server
 	system-config-printer,
 # orca works with lxde, adding accessibility
-	gnome-orca,
+	orca,
 # libreoffice accessibility needs the GTK frontend
 	libreoffice-gtk2,
 
@@ -192,7 +192,7 @@ Depends: ${misc:Depends},
  lxqt,
 Recommends: xsane,
 # orca works with qt, adding accessibility
-	gnome-orca,
+	orca,
 # libreoffice widgets using just gtk
 	libreoffice-gtk2,
 # Package management.
@@ -268,7 +268,7 @@ Recommends:
 # gui for configuration of the print server
 	system-config-printer,
 # orca works with xfce, adding accessibility
-	gnome-orca,
+	orca,
 # libreoffice accessibility needs the GTK frontend
 	libreoffice-gtk2,
 
@@ -313,7 +313,7 @@ Recommends:
 # we need a working network setup at least
 	network-manager-gnome,
 # orca works with mate, adding accessibility
-	gnome-orca,
+	orca,
 # libreoffice accessibility needs the GTK frontend
 	libreoffice-gtk3,
 
-- 
2.14.1

Bug#885153: fslint-gui won't find dangling symlinks

[Leon Meier]

Package: fslint
Version: 2.44-2

How to reproduce in Debian stable:

1) Make sure that /tmp does NOT contain a file named test.txt
2) Create /tmp/Test
3) Create a symlink /tmp/Test -> ../test.txt
4) Notice that the symlink is hanging, not pointing anywhere
5) Run fslint-gui /tmp/Test
6) Click on "Bad symlinks", make sure that "Dangling" is selected, and 
click on "Find"
7) Observe the error message ": ord() 
expected a character, but string of length 11 found".


The program fslint-gui errored on a directory containing dangling symlink.

What should have been done instead is displaying which symlink is broken 
(here: /tmp/Test/test.txt). This bug turns into a huge problem when you 
run fslint-gui on huge directories: you could derive that a dangling 
symlink probably exists, but you don't know where it is exactly.


Any bugfix?

Thanks in advance
Leon

Bug#885152: ITP: intel-me-cleaner -- Tool for partial deblobbing of Intel ME/TXE firmware images

[Bálint Réczey]

Hi Matthias,

Would you like to upload the PureOS package with small changes to Debian?
I remember we talked about you possibly packaging it for Debian but I did not
know it was already available for PureOS in the repo.


2017-12-25 0:18 GMT+01:00 Jonas Smedegaard :
> Quoting Balint Reczey (2017-12-25 00:02:20)
>> Package: wnpp
>> Owner: Balint Reczey 
>> Severity: wishlist
>> X-Debbugs-CC: debian-de...@lists.debian.org
>>
>> * Package name: intel-me-cleaner
>>   Version : 1.0+git20171022.g2ff65c1
>>   Upstream Author : Nicola Corna 
>> * URL : https://github.com/corna/me_cleaner
>> * License : GPL-3.0+
>>   Programming Lang: Python
>>   Description : Tool for partial deblobbing of Intel ME/TXE firmware 
>> images
>>
>> The Intel�� Management Engine (ME) is a microcontroller embedded in
>> most Intel chipsets manufactured since 2006 that runs independently
>> from the main CPU.
>>
>> It is not removable from the system and it runs a signed proprietary
>> firmware, with full network and memory access, which poses a serious
>> security threat. Even when disabled from the BIOS settings, Intel ME
>> is active: the only way to be sure it is disabled is to remove its
>> firmware from the flash chip.
>>
>> This package allows removing parts of the signed proprietary firmware
>> effectively disabling the Management Engine.
>
> You might benefit from the .deb package done for PureOS:
> https://repo.pureos.net/pureos/pool/main/m/me-cleaner/

Thanks Jonas!

Cheers,
Balint

>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#879526: dgit broken by recent dpkg (Can't locate object method "new" via package "Dpkg::Compression::Process" …)

[Ian Jackson]

Cyril Brulebois writes ("Bug#879526: dgit broken by recent dpkg (Can't locate 
object method "new" via package "Dpkg::Compression::Process" …)"):
> I'm not sure what the problem with use-ing Dpkg::Compression::Process
> unconditionally would be?

There isn't one, and that's how #879526 was fixed in dgit.

My comment ...

> Ian Jackson  (2017-10-22):
> > Sadly I am not aware of a good way of detecting missing `use'
> > direcctives other than waiting for things to break when an implicitly
> > loaded module is no longer loaded.

... related to the fact that there may be other similar bugs lurking
in dgit (and in other programs).  It would be nice if there was a way
to spot them.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#885152: ITP: intel-me-cleaner -- Tool for partial deblobbing of Intel ME/TXE firmware images

[Jonas Smedegaard]

Quoting Balint Reczey (2017-12-25 00:02:20)
> Package: wnpp
> Owner: Balint Reczey 
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: intel-me-cleaner
>   Version : 1.0+git20171022.g2ff65c1
>   Upstream Author : Nicola Corna 
> * URL : https://github.com/corna/me_cleaner
> * License : GPL-3.0+
>   Programming Lang: Python
>   Description : Tool for partial deblobbing of Intel ME/TXE firmware 
> images
> 
> The Intel�� Management Engine (ME) is a microcontroller embedded in 
> most Intel chipsets manufactured since 2006 that runs independently 
> from the main CPU.
> 
> It is not removable from the system and it runs a signed proprietary 
> firmware, with full network and memory access, which poses a serious 
> security threat. Even when disabled from the BIOS settings, Intel ME 
> is active: the only way to be sure it is disabled is to remove its 
> firmware from the flash chip.
> 
> This package allows removing parts of the signed proprietary firmware 
> effectively disabling the Management Engine.

You might benefit from the .deb package done for PureOS: 
https://repo.pureos.net/pureos/pool/main/m/me-cleaner/


 - 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#885152: ITP: intel-me-cleaner -- Tool for partial deblobbing of Intel ME/TXE firmware images

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: intel-me-cleaner
  Version : 1.0+git20171022.g2ff65c1
  Upstream Author : Nicola Corna 
* URL : https://github.com/corna/me_cleaner
* License : GPL-3.0+
  Programming Lang: Python
  Description : Tool for partial deblobbing of Intel ME/TXE firmware images

The Intel® Management Engine (ME) is a microcontroller embedded in most
Intel chipsets manufactured since 2006 that runs independently from the main
CPU.

It is not removable from the system and it runs a signed proprietary firmware,
with full network and memory access, which poses a serious security threat.
Even when disabled from the BIOS settings, Intel ME is active: the only way
to be sure it is disabled is to remove its firmware from the flash chip.

This package allows removing parts of the signed proprietary firmware
effectively disabling the Management Engine.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#885151: transmission FTCBFS: uses AC_RUN_IFELSE

[Helmut Grohne]

Source: transmission
Version: 2.92-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

transmission fails to cross build from source, because it uses
AC_RUN_IFELSE. Fortunately, the use is unnecessary and can simply be
filled with AC_COMPILE_IFELSE. The attached patch implements that.

After applying the patch, transmission still fails to cross build with a
qmake error. I'll have to discuss that with the qt maintainers, so
please close this bug anyway when fixing the just the AC_RUN_IFELSE
issue.

Helmut
Index: transmission-2.92/configure.ac
===
--- transmission-2.92.orig/configure.ac
+++ transmission-2.92/configure.ac
@@ -386,14 +386,12 @@
 dnl MINIUPNPC_API_VERSION and we won't have to figure
 dnl it out on our own
 if test "x$upnp_version" = "xunknown" ; then
-  AC_RUN_IFELSE(
+  AC_COMPILE_IFELSE(
 [AC_LANG_PROGRAM(
   [#include 
#include ],
-  [#ifdef MINIUPNPC_API_VERSION
-   return EXIT_SUCCESS;
-   #else
-   return EXIT_FAILURE;
+  [#ifndef MINIUPNPC_API_VERSION
+   #error MINIUPNPC_API_VERSION undefined
#endif]
 )],
 [upnp_version=">= 1.7"]

Bug#885150: orbit2 FTCBFS: broken embedded copy of AC_CHECK_ALIGNOF

[Helmut Grohne]

Source: orbit2
Version: 1:2.14.19-4
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

orbit2 fails to cross build from source, because its acinludes.m4
contains a broken and outdated embedded copy of AC_CHECK_ALIGNOF that
fails for cross compilation. It makes configure abort. After removing
the embedded copy (and thus using the upstream macro), configure
succeeds. The attached patch implements that.

The build still fails running src/idl-compiler/orbit-idl-2 with an Exec
format error. This secondary failure is not fixed in the attached patch.
Please close this bug anyway when fixing AC_CHECK_ALIGNOF.

Helmut
Index: orbit2-2.14.19/acinclude.m4
===
--- orbit2-2.14.19.orig/acinclude.m4
+++ orbit2-2.14.19/acinclude.m4
@@ -1,50 +1,3 @@
-###
-# type alignment test #
-###
-
-AC_DEFUN([AC_CHECK_ALIGNOF],
-	[changequote(<<, >>)dnl
-	dnl The name to #define.
-	define(<>,
-		translit(orbit_alignof_$1, [a-z *], [A-Z_P]))dnl
-	dnl The cache variable name.
-	define(<>,
-		translit(ac_cv_alignof_$1, [ *], [_p]))dnl
-	changequote([, ])dnl
-	AC_MSG_CHECKING(alignment of $1)
-	align_save_libs="$LIBS"
-	LIBS="$ORBIT_LIBS $LIBS"
-	AC_CACHE_VAL(AC_CV_NAME,
-		[AC_TRY_RUN(
-			[ #include 
-  #include 
-
-			#include "$srcdir/include/orbit/util/basic_types.h"
-			typedef struct {char s1;} CORBA_struct;
-			typedef void *CORBA_pointer;
-			struct test {char s1; $1 s2;};
-			main()
-			{
-			FILE *f=fopen("conftestval", "w");
-			if (!f) exit(1);
-			fprintf(f, "%d\n", &(((struct test*)0)->s2));
-			exit(0);
-			} ],
-			AC_CV_NAME=`cat conftestval`,
-			AC_CV_NAME=0, AC_CV_NAME=0)
-		])dnl
-	AC_MSG_RESULT($AC_CV_NAME)
-	if test "$AC_CV_NAME" = "0" ; then
-		AC_MSG_ERROR([Failed to find alignment. Check config.log for details.])
-	fi
-	LIBS="$align_save_libs"
-	AC_TYPE_NAME=$AC_CV_NAME
-	AC_SUBST(AC_TYPE_NAME)
-	undefine([AC_TYPE_NAME])dnl
-	undefine([AC_CV_NAME])dnl
-])
-
-
 dnl @synopsis AX_CFLAGS_GCC_OPTION (optionflag [,[shellvar][,[A][,[NA]]])
 dnl
 dnl AX_CFLAGS_GCC_OPTION(-fvomit-frame) would show a message as like

Bug#885149: exim4-base: exim4 and SMTPUTF8

[Hanno Wagner]

Package: exim4-base
Version: 4.89-2+deb9u2
Severity: wishlist

Dear Maintainer,

exim4 isn't able to use SMTPUTF8 in it's default configuration within
Debian.
According to
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-internationalisation.html
this is a decision to take while compiling exim4 (you need libidn and
libidn2 and some additional configuration lines in the Makefile, see
src/EDITME), so this is not something you can configure afterwards.

I'd like to ask you to enable this in exim as a default. I already had
the situation that a normal site tried to send a mail with UTF8-Header
and it got bounced back to the sender.

best regards, Hanno Wagner 

-- Package-specific info:
Exim version 4.89 #1 built 28-Nov-2017 21:58:00
Copyright (c) University of Cambridge, 1995 - 2017
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PRDR PROXY SOCKS 
TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

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

Kernel: Linux 4.14.5-zgsrv20080 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages exim4-base depends on:
ii  adduser3.115
ii  anacron2.3-24
ii  cron [cron-daemon] 3.0pl1-128+b1
ii  debconf [debconf-2.0]  1.5.61
ii  exim4-config [exim4-config-2]  4.89-2+deb9u2
ii  libc6  2.24-11+deb9u1
ii  libdb5.3   5.3.28-12+deb9u1
ii  lsb-base   9.20161125
ii  netbase5.4

Versions of packages exim4-base recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
ii  psmisc 22.21-2.1+b2

Versions of packages exim4-base suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20160123cvs-4
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.30-1+deb9u1
ii  jed [mail-reader]1:0.99.19-7+b1
ii  mutt [mail-reader]   1.7.2-1
ii  openssl  1.1.0f-3+deb9u1
pn  spf-tools-perl   
ii  swaks20170101.0-1

-- Configuration Files:
/etc/logrotate.d/exim4-base changed [not included]

-- debconf information excluded

Bug#885148: kleopatra depends on deprecated packages

[Peter Marschall]

Package: kleopatra
Version: 4:17.08.3-1
Severity: normal

Dear Maintainer(s),

kleopatra depends on 2 outdated packages
* gnupg2
* gnupg-agent
for which replacement packages are available
* gnupg
* gpg-agent

Because GnuPG changed its internal architecture to perform cryptographic
actions via gpg-agent, gnupg itself mandatorily depends on gpg-agent.

Therefore ian explicit dependency on gpg-agent is not required, and a
simple dependency on 
* gnupg
should be sufficient

Please consider updating the dependenciers in the next release to stop
pulling in deprecated packages.

Thanks for maintaining KDE in Debian
Peter


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

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

Versions of packages kleopatra depends on:
ii  dirmngr  2.2.3-1
ii  gnupg2   2.2.3-1
ii  gpg-agent [gnupg-agent]  2.2.3-1
ii  gpgsm2.2.3-1
ii  libassuan0   2.5.1-1
ii  libc62.25-3
ii  libgcc1  1:7.2.0-18
ii  libgpg-error01.27-5
ii  libgpgmepp6  1.10.0-1
ii  libkf5codecs55.37.0-2
ii  libkf5configcore55.37.0-2
ii  libkf5configgui5 5.37.0-2
ii  libkf5configwidgets5 5.37.0-2
ii  libkf5coreaddons55.37.0-2
ii  libkf5dbusaddons55.37.0-2
ii  libkf5i18n5  5.37.0-2
ii  libkf5iconthemes55.37.0-2
ii  libkf5itemmodels55.37.0-2
ii  libkf5kcmutils5  5.37.0-2
ii  libkf5libkleo5   4:17.08.3-1
ii  libkf5mime5  17.08.3-1
ii  libkf5notifications5 5.37.0-2
ii  libkf5textwidgets5   5.37.0-2
ii  libkf5widgetsaddons5 5.37.0-2
ii  libkf5windowsystem5  5.37.0-2
ii  libkf5xmlgui55.37.0-2
ii  libqgpgme7   1.10.0-1
ii  libqt5core5a 5.9.2+dfsg-6
ii  libqt5dbus5  5.9.2+dfsg-6
ii  libqt5gui5   5.9.2+dfsg-6
ii  libqt5network5   5.9.2+dfsg-6
ii  libqt5printsupport5  5.9.2+dfsg-6
ii  libqt5widgets5   5.9.2+dfsg-6
ii  libstdc++6   7.2.0-18
ii  paperkey 1.5-3
ii  pinentry-qt  1.0.0-3

kleopatra recommends no packages.

kleopatra suggests no packages.

-- no debconf information

Bug#789802: lintian: False positive source-contains-prebuilt-java-object reported against jar files without classes

[Chris Lamb]

tags 789802 + moreinfo
thanks

Hi Emmanuel,

> lintian: False positive source-contains-prebuilt-java-object reported
> against jar files without classes

Do you have any up-to-date false-positives? The ones you listed
are now not showing up for me :)


Regards,

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

Bug#885103: rename: "-n" option is ignored

[Peter De Wachter]

Hello Dominic,

[Resending with bugs.debian.org in Cc]

I feel that in Debian the expected behavior is that options and other
arguments can be mixed. Sure, no program bothers explicitly
documenting that, but why would they? It's simply the normal behavior
of glibc's getopt(3) after all. Programs that don't allow this are
exceptions.

Given that the previous version of rename allowed this and given that
it's expected behavior on Debian, I feel that this is a valid bug.

If on the other hand you really don't want to support this, I feel
it's necessary to give an explicit error message in this situation
("fatal: option -n must come before non-option arguments").

Best regards,
Peter


On Sun, Dec 24, 2017 at 8:49 PM, Dominic Hargreaves  wrote:
> On Sat, Dec 23, 2017 at 09:02:04PM +0100, Peter De Wachter wrote:
>> Package: rename
>> Version: 0.20-6
>> Severity: important
>>
>> rename ignores the '-n' option if it's not specified first on the command 
>> line:
>>
>> $ touch a
>> $ rename s/a/b/ -n a
>> $ ls -l a
>> ls: cannot access 'a': No such file or directory
>>
>> This is different from how the 'rename' command behaves in Debian stable.
>
> The implementation has changed, but the documented use of rename in
> Debian has always been that -n should be provided before the file list.
> I don't see us changing the behaviour of the new implementation to
> support these undocumented calling semantics.
>
> Best,
> Dominic.

Bug#753456: lintian: false positive: privacy-breach-donation: pnp4nagios-web

[Chris Lamb]

Paul Wise wrote:

> As far as I can tell this file is shipped verbatim in the binary package
> and none of the 

Bug#872724: pyasn1

[Timo Aaltonen]

Hi

I need newer pyasn1 for next FreeIPA upload, so I had a look at the
packages that depend on it, and rebuilt all. Only python-pyasn1-modules
and python-keyczar failed to build, and the latter doesn't have any
updates upstream since the last release. So it'd have to be patched I
guess. pyasn1-modules can be updated to 0.2.1 which built fine.

One issue with pyasn1 itself is that the tests now fail with pypy:

ERROR: testSizeOf (tests.type.test_univ.NoValueTestCase)
--
Traceback (most recent call last):
  File "tests/type/test_univ.py", line 151, in testSizeOf
sys.getsizeof(univ.noValue)
TypeError: getsizeof(...)
getsizeof(object, default) -> int

Return the size of object in bytes.

sys.getsizeof(object, default) will always return default on PyPy, and
raise a TypeError if default is not provided.

First note that the CPython documentation says that this function may
raise a TypeError, so if you are seeing it, it means that the program
you are using is not correctly handling this case.

On PyPy, though, it always raises TypeError.  Before looking for
alternatives, please take a moment to read the following explanation as
to why it is the case.  What you are looking for may not be possible.

A memory profiler using this function is most likely to give results
inconsistent with reality on PyPy.  It would be possible to have
sys.getsizeof() return a number (with enough work), but that may or
may not represent how much memory the object uses.  It doesn't even
make really sense to ask how much *one* object uses, in isolation
with the rest of the system.  For example, instances have maps,
which are often shared across many instances; in this case the maps
would probably be ignored by an implementation of sys.getsizeof(),
but their overhead is important in some cases if they are many
instances with unique maps.  Conversely, equal strings may share
their internal string data even if they are different objects---or
empty containers may share parts of their internals as long as they
are empty.  Even stranger, some lists create objects as you read
them; if you try to estimate the size in memory of range(10**6) as
the sum of all items' size, that operation will by itself create one
million integer objects that never existed in the first place.



How to proceed from here?

t

Bug#885103: rename: "-n" option is ignored

[Dominic Hargreaves]

On Sat, Dec 23, 2017 at 09:02:04PM +0100, Peter De Wachter wrote:
> Package: rename
> Version: 0.20-6
> Severity: important
> 
> rename ignores the '-n' option if it's not specified first on the command 
> line:
> 
> $ touch a
> $ rename s/a/b/ -n a
> $ ls -l a
> ls: cannot access 'a': No such file or directory
> 
> This is different from how the 'rename' command behaves in Debian stable.

The implementation has changed, but the documented use of rename in
Debian has always been that -n should be provided before the file list.
I don't see us changing the behaviour of the new implementation to
support these undocumented calling semantics.

Best,
Dominic.

Bug#806237: lintian: false positive for obsolete-url-in-packaging in debian/watch

[Chris Lamb]

tags 806237 + pending
thanks

Thanks! Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=6b16b02d41c4df215cde6423cc57e36e7f88aff7


Regards,

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

Bug#782277: please check for mismatches in python dependencies

[Chris Lamb]

Paul Wise wrote:

> These instances of what Matthias requested don't appear to be detected
> by the already implemented lintian checks, since they involve
> dependencies on python-* packages from other source packages.

Ah, thank you for your deligence and providing the examples!

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=c7efe44809a27239201874df70a1dd0781e4ede0


Regards,

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

Bug#885147: cflow man page says to use info page but none exists

[Ken Stailey]

Package: cflow
Version: 1:1.4+dfsg1-3
Severity: normal

Dear Serafeim Zanikolas (or Current Maintainer of cflow),

The cflow man page says to read the cflow info file but there is no
cflow info file.  The cflow info file was removed from the upstream
distribution entirely.  The "apt-file" program does not show it in any
package:

$ apt-file search cflow | grep info

returns nothing.  If I want to read the info page I have to use
another means to do so beside use anything Debian GNU/Linux includes.

Please include the info page as the man page says to use it:

$ man cflow | grep -B1 the.info
   A summary of options is included below. For a complete description, see
   the info(1) files.

Thanks and Regards,
Ken Stailey

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

Kernel: Linux 4.14.0-1-amd64 (SMP w/3 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)

Versions of packages cflow depends on:
ii  libc6  2.25-5

cflow recommends no packages.

cflow suggests no packages.

-- no debconf information

Bug#501557: build 2 similar binary packages from one source tree

[Adam Borowski]

On Mon, Dec 25, 2017 at 01:43:13AM +0900, Osamu Aoki wrote:
> maildrop source tree can be build with different build option to produce
> maildrop program in 2 ways for each arch.
> 
>  * set GID mail without restricted caller (maildrop)
>  * set UID root with restricted caller for courier-mta
>(maildrop-courier) -- This is now missing in archive but we used to
>have it.
> 
> Of course we can build 2 source packages to do this.  But is there any
> easy clean way to do this without making 2 source packages with
> identical upstream tarball.
> 
> Any pointer to a simple example which uses autotools as its build script
> is appreciated.  (Program example simpler than glibc or linux kernel is
> appreciated.)

While autotools in principle do support out-of-tree builds, a particular
program might still fail.  And, most non-autotools non-cmake build systems
don't support that at all.

In such cases, there's a heavy hammer of linking the whole build tree to
two temporary directories, and building from those.

For example, crawl does:

tree-stamp:
dh_testdir
mkdir build-console
cp -ldpR docs settings source CREDITS.txt build-console/
mkdir build-tiles
cp -ldpR docs settings source CREDITS.txt build-tiles/
touch tree-stamp

then for actual build:
cd build-console/source && $(MAKE) $(ARGS_CONSOLE)
cd build-tiles/source && $(MAKE) $(ARGS_TILES)


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#830307: virt-manager: creation of xen vms still broken

[astian]

Control: found -1 virt-manager/1:1.4.3-1

This is still broken.  For reference, Red Hat fixed this 1 and 1/2 years ago:

  https://bugzilla.redhat.com/show_bug.cgi?id=1334554

Cheers.

_

Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte 
E-Mail-Adresse mitnehmen! https://www.eclipso.de

Bug#785274: [git-buildpackage/master] pq: Parse DEP3 headers

[Maximiliano Curia]

tag 785274 pending
thanks

Date:   Sun Sep 11 16:23:11 2016 +0200
Author: Maximiliano Curia 
Commit ID: 17a471d1fc07935dd85c31d3a7c4ae3ea5c39208
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=17a471d1fc07935dd85c31d3a7c4ae3ea5c39208
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=17a471d1fc07935dd85c31d3a7c4ae3ea5c39208

pq: Parse DEP3 headers

Currently the patch headers in DEP3 format are partially
supported, as git's mailinfo only reads the From and Subject fields from
the first paragraph. But the default in dep3 patches is Description and
Author, that are ignored by git. Even worse, when this fields are in the
first paragraph (again the default) git mailinfo drops all the contained
information.

This patch parses the dep3 headers if git's mailinfo couldn't obtain any
useful information, any header other than Subject|Description and
Author|From is appended to the patch message.

The description field is splitted in first line for the short
description and the rest is prepended to the patch message.

Closes: #785274

  

Bug#885143: libreoffice-gtk2: Drop gtk2 support

[Jeremy Bicha]

On Sun, Dec 24, 2017 at 1:05 PM, Jean-Philippe Memgual
 wrote:
> things may have changee but iirc gtk3 release of lo had many display issues. 
> The support of this toolkit release has been in dev and more or less 
> experimental and not stable enough. Hence gtk2 in debin. Even upstream seem 
> to recommend gtk2 if one has display bugs.

Ubuntu (and all its flavors) have been shipping only the gtk3 version
by default since 5.2 over a year ago. Only the gtk3 version provides
native Wayland support and has better display of keyboard
shortcuts/accelerators in the File/Edit/View menus.

This bug is really about Buster, which is not expected to be a stable
release until 2019.

Thanks,
Jeremy Bicha

Bug#882427: bug report

[Andrei Karas]

Bug report created on libsdl bug tracker:  
https://bugzilla.libsdl.org/show_bug.cgi?id=4009  

Bug#876300: libsundials-dev: libsundials-serial-dev is gone

[Paolo Greppi]

Il 24/12/2017 04:10, Dima Kogan ha scritto:
>> Should there be a transitional package to ease the migration ?
> 
> There's nothing that depends on libsundials-serial-dev, so it's not
> obvious to me we need a migration package. Why do you think we need it?
> 
> dima

Hi dima,

It will cause breakage when existing installs will be migrated to buster.
My understanding is that with 'apt dist-upgrade' libsundials-serial-dev will
be gone and nothing will hint the user that she should install libsundials-dev.

Users hitting this issue may stumble into this bug report and find some relief.

Or you could document that somewhere (but where).

The transitional package would be classy don't you think ?
and it shouldn't be too much work; we're case #5 of:
https://wiki.debian.org/PackageTransition

Paolo

Bug#885143: libreoffice-gtk2: Drop gtk2 support

[Jean-Philippe Memgual]

hi

things may have changee but iirc gtk3 release of lo had many display issues. 
The support of this toolkit release has been in dev and more or less 
experimental and not stable enough. Hence gtk2 in debin. Even upstream seem to 
recommend gtk2 if one has display bugs.

merry christmas 




Jean-Philippe MENGUALLe 24 déc. 2017 4:13 PM, Jeremy Bicha  
a écrit :
>
> Package: libreoffice-gtk2 
> Version: 1:6.0.0~rc1-1 
> Tags: buster sid 
>
> Please consider dropping gtk2 support even if upstream continues to 
> provide a gtk2 compile option. 
>
> While it's impractical in 2018 to have a Debian desktop without gtk3 
> installed (unless you want an obscure web browser), it will be 
> possible to have a desktop without gtk2 installed. And if gtk3 is 
> required anyway, why try to use gtk2? 
>
> libreoffice-gtk2 is currently used by default in the Debian Tasks for 
> Xfce, LXQt and LXDE. That may have made sense for Stretch because 
> Stretch shipped LibreOffice 5.2 (the first version where the gtk3 
> version was ready) but I don't think it makes sense for Buster. 
>
> There's a support burden to provide the gtk2 version that may be 
> unjustified if nearly everyone is using the gtk3 version. 
>
> Thanks, 
> Jeremy Bicha 
>

Bug#878214: (no subject)

[Серёга Вставский]

--
Отправлено из Mail.Ru для Android

Bug#501557: build 2 similar binary packages from one source tree

[Simon McVittie]

On Mon, 25 Dec 2017 at 01:43:13 +0900, Osamu Aoki wrote:
> Of course we can build 2 source packages to do this.  But is there any
> easy clean way to do [two builds with different options] without making
> 2 source packages with identical upstream tarball.
>
> Any pointer to a simple example which uses autotools as its build script
> is appreciated.

I wouldn't exactly call them "simple", but src:dbus and src:glib2.0 both
do more than one build of the same Autotools project (one of which is a
cut-down version for the udeb) by doing more than one srcdir != builddir
Autotools build.

In cdbs, doing multiple builds in this way are referred to as "flavors".
I wouldn't recommend cdbs for new packages, but you might find useful
information by using that keyword.

smcv

Bug#884662: reproducible-builds.org: regular files sometimes treated as directories

[Simon McVittie]

On Sun, 24 Dec 2017 at 17:21:07 +, Holger Levsen wrote:
> On Sun, Dec 24, 2017 at 02:52:39PM +, Simon McVittie wrote:
> > install(1) and tar(1) do the wrong thing. What filesystem is used for
> > the build, and which LD_PRELOAD hacks are applied?
> 
> we use pbuilder with eatmydata on tmpfs (on amd64, i386 and arm64, only
> on armel we build on ext3), iirc, but I believe I do ;)

That can't be the only thing that might be intercepting stat(), because
one of the various implementations of fakeroot is also visible in glib2.0
build logs. Do you know which one it is - original fakeroot, fakeroot-ng,
pseudo, proot (probably not that one since it doesn't register itself
as a fakeroot alternative), or something else?

smcv

Bug#883787: ntopng: Error "Missing CSRF parameter" in "Manage users" and "Preferences"

[Ludovico Cavedon]

Hi Daniel,

Thank you for the report.
As you described, the issues is exactly the same as #856048, so I am going
to merge the bugs.
Given that this impacts a core functionality, it may qualify for a stable
release update. I will check with the stable release team.

Thanks,
Ludovico


On Thu, Dec 7, 2017 at 3:45 PM Daniel Aubry 
wrote:

> Package: ntopng
> Version: 2.4+dfsg1-3
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> This is fixed in ntopng/2.4+dfsg1-4 which is not available on debian
> stretch.
>
> Please see bug #856048 for more details.
>
> It is not possible to access the "Manage users" and "Preferences" links on
> the web interface. Both will display an error message:
>
>  Script "/lua/admin/users.lua" returned an error:
>  Missing CSRF parameter
>
>  Script "/lua/admin/prefs.lua" returned an error:
>  Missing CSRF parameter
>
>
> This is the important changelog entry of version 2.4+dfsg1-4
>
>   * Update Check-for-presence-of-crsf-in-admin-scripts.patch to avoid the
> 'Missing CSRF parameter' error (Closes: #856048).
>
>
> Best Reards
> Daniel
>
> -- System Information:
> Debian Release: 9.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ntopng depends on:
> ii  init-system-helpers  1.48
> ii  libc62.24-11+deb9u1
> ii  libcurl3-gnutls  7.52.1-5+deb9u3
> ii  libgcc1  1:6.3.0-18
> ii  libgeoip11.6.9-4
> ii  libhiredis0.13   0.13.3-2
> ii  libjson-c3   0.12.1-1.1
> ii  libluajit-5.1-2  2.0.4+dfsg-1+b1
> ii  libmariadbclient18   10.1.26-0+deb9u1
> ii  libndpi4 1.8-1
> ii  libpcap0.8   1.8.1-3
> ii  librrd8  1.6.0-1+b2
> ii  libsqlite3-0 3.16.2-5
> ii  libstdc++6   6.3.0-18
> ii  libzmq5  4.2.1-4
> ii  lsb-base 9.20161125
> ii  ntopng-data  2.4+dfsg1-3
> ii  redis-server 3:3.2.6-1
> ii  zlib1g   1:1.2.8.dfsg-5
>
> ntopng recommends no packages.
>
> Versions of packages ntopng suggests:
> pn  geoip-database-contrib  
>
> -- no debconf information
>

Bug#884662: [Qa-jenkins-dev] Bug#884662: reproducible-builds.org: regular files sometimes treated as directories

[Mattia Rizzolo]

On Sun, Dec 24, 2017 at 05:32:02PM +, Simon McVittie wrote:
> On Sun, 24 Dec 2017 at 17:21:07 +, Holger Levsen wrote:
> > On Sun, Dec 24, 2017 at 02:52:39PM +, Simon McVittie wrote:
> > > install(1) and tar(1) do the wrong thing. What filesystem is used for
> > > the build, and which LD_PRELOAD hacks are applied?
> > 
> > we use pbuilder with eatmydata on tmpfs (on amd64, i386 and arm64, only
> > on armel we build on ext3), iirc, but I believe I do ;)

Actually, we are using tmpfs on amd64 and arm64, and there we don't use
eatmydata, whereas i386 and armhf are building on regular ext[34] file
systems with eatmydata.

> That can't be the only thing that might be intercepting stat(), because
> one of the various implementations of fakeroot is also visible in glib2.0
> build logs. Do you know which one it is - original fakeroot, fakeroot-ng,
> pseudo, proot (probably not that one since it doesn't register itself
> as a fakeroot alternative), or something else?

regular fakeroot (from the 'fakeroot' package).
The pbuilder version we use is the one in stretch, so it doesn't support
R³ (yet, I do plan on backporting it to stretch-bpo), therefore adding
R³ won't do anything special for now.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#844712: (no subject)

[Серёга Вставский]

--
Отправлено из Mail.Ru для Android

Bug#884662: [Qa-jenkins-dev] Bug#884662: reproducible-builds.org: regular files sometimes treated as directories

[Holger Levsen]

Hi Simon,

On Sun, Dec 24, 2017 at 02:52:39PM +, Simon McVittie wrote:
> install(1) and tar(1) do the wrong thing. What filesystem is used for
> the build, and which LD_PRELOAD hacks are applied?

we use pbuilder with eatmydata on tmpfs (on amd64, i386 and arm64, only
on armel we build on ext3), iirc, but I believe I do ;)

we don't use disorderfs, despite we want to.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#884488: [ktorrent] Freezes at start

[Alex Dănilă]

Hi,

I attached with gdb and I think the process gets stuck trying to empty 
QNetworkReplyHandlerCallQueue::m_enqueuedCalls from inside 
QNetworkReplyHandlerCallQueue 
::flush(), 
spinning in the loop at lines 257-258.


Here's from the gdb session:

(gdb) where
#0  0x721837b2 in __GI___fxstat (vers=vers@entry=1, 
fd=fd@entry=48, buf=buf@entry=0x7fffd160) at 
../sysdeps/unix/sysv/linux/wordsize-64/fxstat.c:35
#1  0x72f2fd1a in fstat64 (__statbuf=0x7fffd160, 
__fd=) at /usr/include/x86_64-linux-gnu/sys/stat.h:514
#2  0x72f2fd1a in QFileSystemEngine::fillMetaData(int, 
QFileSystemMetaData&) (fd=fd@entry=48, data=...) at 
io/qfilesystemengine.cpp:217
#3  0x72f47a2c in 
QFSFileEnginePrivate::doStat(QFlags) 
const (this=this@entry=0x7fffdc0144c0, flags=..., flags@entry=...)

    at io/qfsfileengine_unix.cpp:508
#4  0x72f28385 in QFSFileEnginePrivate::sizeFdFh() const 
(this=0x7fffdc0144c0) at io/qfsfileengine.cpp:484
#5  0x72ed827c in QFileDevice::size() const (this=out>) at io/qfiledevice.cpp:608
#6  0x7fffc92e45ff in WebCore::QNetworkReplyHandler::forwardData() 
() at ../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:712
#7  0x7fffc92e3f5c in 
WebCore::QNetworkReplyHandlerCallQueue::flush() () at 
../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:258
#8  0x7fffc92e5d48 in 
WebCore::QNetworkReplyHandlerCallQueue::flush() () at 
../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:393
#9  0x7fffc92e5d48 in 
WebCore::QNetworkReplyHandlerCallQueue::unlock() () at 
../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:238
#10 0x7fffc92e5d48 in WebCore::QueueLocker::~QueueLocker() () at 
../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:266
#11 0x7fffc92e5d48 in 
WebCore::QNetworkReplyWrapper::emitMetaDataChanged() () at 
../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:388
#12 0x7fffc92e6090 in 
WebCore::QNetworkReplyWrapper::receiveMetaData() () at 
../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:353
#13 0x72febd55 in QMetaObject::activate(QObject*, int, int, 
void**) (sender=0x569b9970, signalOffset=, 
local_signal_index=, argv=)

    at kernel/qobject.cpp:3766
#14 0x72fec8c2 in QObject::event(QEvent*) (this=0x569b9970, 
e=) at kernel/qobject.cpp:1246
#15 0x73cd859c in QApplicationPrivate::notify_helper(QObject*, 
QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x73cdfe64 in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x72fbd258 in QCoreApplication::notifyInternal2(QObject*, 
QEvent*) (receiver=0x569b9970, event=event@entry=0x56f80e50) at 
kernel/qcoreapplication.cpp:1018
#18 0x72fbf9cd in QCoreApplication::sendEvent(QObject*, QEvent*) 
(event=0x56f80e50, receiver=)

    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:233
#19 0x72fbf9cd in 
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) 
(receiver=receiver@entry=0x0, event_type=event_type@entry=0, 
data=0x5588c720)

    at kernel/qcoreapplication.cpp:1678
#20 0x72fbff58 in QCoreApplication::sendPostedEvents(QObject*, 
int) (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at 
kernel/qcoreapplication.cpp:1532
#21 0x73016ac3 in postEventSourceDispatch(GSource*, GSourceFunc, 
gpointer) (s=0x558df6a0) at kernel/qeventdispatcher_glib.cpp:276
#22 0x7fffebf69fa7 in g_main_context_dispatch () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#23 0x7fffebf6a1e0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x7fffebf6a26c in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x730160ef in 
QEventDispatcherGlib::processEvents(QFlags) 
(this=0x558dc090, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#26 0x72fbb2aa in 
QEventLoop::exec(QFlags) 
(this=this@entry=0x7fffd9e0, flags=..., flags@entry=...) at 
kernel/qeventloop.cpp:212
#27 0x72fc4214 in QCoreApplication::exec() () at 
kernel/qcoreapplication.cpp:1291

#28 0x5559702a in  ()
#29 0x720bdf2a in __libc_start_main (main=
    0x55594d60, argc=1, argv=0x7fffdd78, init=, 
fini=, rtld_fini=, 
stack_end=0x7fffdd68) at ../csu/libc-start.c:310

#30 0x55597a0a in _start ()


(gdb) info threads
  Id   Target Id Frame
* 1    Thread 0x77f7b3c0 (LWP 21757) "ktorrent" 0x721837b2 
in __GI___fxstat (vers=vers@entry=1, fd=fd@entry=48, 
buf=buf@entry=0x7fffd160)

    at ../sysdeps/unix/sysv/linux/wordsize-64/fxstat.c:35
  2    Thread 0x7fffe1623700 (LWP 21760) "QXcbEventReader" 
0x721883fb in __GI___poll (fds=0x7fffe1622b70, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux

Bug#883980: security information -- dsa-4073-1 linux

[Gerard M. Vignes]

I installed "security information -- dsa-4073-1 linux" and rebooted into 
the 4.9.0-4-amd64 kernel. The screen-blacking problem still exists, but 
now it is accented by longer periods when the screen goes haywire.


All I have to do to create the problem now is to (1) start Terminator, 
(2) make it full-screen, (3) split it into two horizontal windows and 
(4) use the arrow keys to scroll bash history. The screen goes crazy, as 
if it were being drawn in all the wrong places. The screen rapidly snaps 
between various renderings, most of them incorrect, where parts of the 
screen are in the wrong places. After jumping between dozens of bad 
screen renderings, the screen goes black for a second. When the screen 
lights up again, sometimes it is normal and sometimes the crazy behavior 
repeats. All I have to do is type into the terminal or use the arrow 
keys to trigger the crazy screen behavior, although it still occurs 
somewhat sporadically.


I am back working in the 4.9.0-3-amd64 kernel. No problems.

Bug#866187: add torrc.d configuration directory

[iry]

Hi intrigeri!

intrigeri:
> weasel explained a while ago how he thinks this should be handled:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866187#15
> 
> Next step is probably: whoever wants to see this happen works on it
> and proposes a branch or patch.
Thank you so much for your instructions.

To confirm, the implementation will be what weasel said:

> I'm tempted to stop shipping upstream's torrc as /etc/tor/torrc.  It's
> full of options that most users should never set, and shipping an almost
> empty one is much nicer.
> 
> I suspect that approximately the only thing it ought to have is the
> include line

I can definitely work on that once weasel confirms a /etc/tor/torrc file
with only a single include line is what we expect. Also, could you
please specify which directory will be used as torrc.d directory, weasel?

Thank you very mcuh!

Best Regards,
iry

Bug#501557: build 2 similar binary packages from one source tree

[Osamu Aoki]

Hi,

maildrop source tree can be build with different build option to produce
maildrop program in 2 ways for each arch.

 * set GID mail without restricted caller (maildrop)
 * set UID root with restricted caller for courier-mta
   (maildrop-courier) -- This is now missing in archive but we used to
   have it.

Of course we can build 2 source packages to do this.  But is there any
easy clean way to do this without making 2 source packages with
identical upstream tarball.

Any pointer to a simple example which uses autotools as its build script
is appreciated.  (Program example simpler than glibc or linux kernel is
appreciated.)

Regards,

Osamu

Bug#885140: [pkg-wicd-maint] Bug#885140: wicd: Depends on unmaintained pygtk

[Axel Beckert]

Hi,

Jeremy Bicha wrote:
> The way forward is to port your app to use GObject Introspection
> bindings.

There is an upstream wishlist bug respective blueprint to do this:

https://bugs.launchpad.net/debian/+source/wicd/+bug/878417

But it's from 2011 from the previous upstream maintainer. It's a start
though for anyone who'll try to do that, as there's an incomplete
patch already included.

If nobody steps up to finish the porting, there is (not so nice) plan B: disable
wicd-gtk and leave wicd-curses (more buggy than it should be, but
usable) and wicd-cli.

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

Bug#885141: tor: systemd unit files should confine tor as much as possible

[Nicolas Braud-Santoni]

As discussed on IRC, here is a new patch that drops PermissionsStartOnly.

I also updated the backport script.
commit eaf325d3cf3a42033e32b5535599a3f0427fa519
Author: Nicolas Braud-Santoni 
Date:   Sun Dec 24 17:07:12 2017 +0100

debian/systemd: Drop PermissionsStartOnly

This avoids running --verify-config unconfined

diff --git a/debian/misc/build-tor-sources b/debian/misc/build-tor-sources
index a145a2034..cc83d1b44 100755
--- a/debian/misc/build-tor-sources
+++ b/debian/misc/build-tor-sources
@@ -166,10 +166,15 @@ remove_systemd() {
fi
 }
 
-remove_systemd_instance_namespace() {
+# Remove systemd hardening features that require systemd >= 232
+remove_systemd_hardening() {
 if [ -d debian/systemd ]; then
 sed -i 's,^(ReadWriteDirectories=.*)/%i$,\1,' debian/systemd/*.service
 dch --append 'Remove templated ReadWriteDirectories from 
debian/systemd'
+
+sed -i 's,^(PermissionsStartOnly=).*$,\1=yes,' debian/systemd/*.service
+sed -i 's,^(Exec[^= ]+)=+(.*)$,\1=\2,' debian/systemd/*.service
+dch --append 'Remove privileged ExecXYZ directives from debian/systemd'
 fi
 }
 
@@ -258,7 +263,7 @@ backport_all() {
bp1 $pkg $dir $sid_debian_version jessie
(cd $dir; remove_libzstd)
(cd $dir; old_debug_pkg)
-   (cd $dir; remove_systemd_instance_namespace)
+   (cd $dir; remove_systemd_hardening)
bp2 $pkg $dir $origtar
 
# wheezy
@@ -277,13 +282,13 @@ backport_all() {
(cd $dir; remove_libzstd)
(cd $dir; remove_systemd)
(cd $dir; old_debug_pkg)
-   (cd $dir; remove_systemd_instance_namespace)
+   (cd $dir; remove_systemd_hardening)
bp2 $pkg $dir $origtar
 
# xenial (EOL: Apr 2021)
#
bp1 $pkg $dir $sid_debian_version xenial
-   (cd $dir; remove_systemd_instance_namespace)
+   (cd $dir; remove_systemd_hardening)
bp2 $pkg $dir $origtar
 
# zesty (EOL: Jan 2018)
diff --git a/debian/systemd/tor@.service b/debian/systemd/tor@.service
index acfbf14b9..a0ea3a10f 100644
--- a/debian/systemd/tor@.service
+++ b/debian/systemd/tor@.service
@@ -8,9 +8,9 @@ ReloadPropagatedFrom=tor.service
 Type=notify
 NotifyAccess=all
 PIDFile=/var/run/tor-instances/%i/tor.pid
-PermissionsStartOnly=yes
-ExecStartPre=/usr/bin/install -Z -m 02755 -o _tor-%i -g _tor-%i -d 
/var/run/tor-instances/%i
-ExecStartPre=/bin/sed -e 's/@@NAME@@/%i/g; w 
/var/run/tor-instances/%i.defaults' 
/usr/share/tor/tor-service-defaults-torrc-instances
+PermissionsStartOnly=no
+ExecStartPre=+/usr/bin/install -Z -m 02755 -o _tor-%i -g _tor-%i -d 
/var/run/tor-instances/%i
+ExecStartPre=+/bin/sed -e 's/@@NAME@@/%i/g; w 
/var/run/tor-instances/%i.defaults' 
/usr/share/tor/tor-service-defaults-torrc-instances
 ExecStartPre=/usr/bin/tor --defaults-torrc /var/run/tor-instances/%i.defaults 
-f /etc/tor/instances/%i/torrc --verify-config
 ExecStart=/usr/bin/tor --defaults-torrc /var/run/tor-instances/%i.defaults -f 
/etc/tor/instances/%i/torrc
 ExecReload=/bin/kill -HUP ${MAINPID}
diff --git a/debian/systemd/tor@default.service 
b/debian/systemd/tor@default.service
index 161838f56..864b02df5 100644
--- a/debian/systemd/tor@default.service
+++ b/debian/systemd/tor@default.service
@@ -8,8 +8,8 @@ ReloadPropagatedFrom=tor.service
 Type=notify
 NotifyAccess=all
 PIDFile=/var/run/tor/tor.pid
-PermissionsStartOnly=yes
-ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d 
/var/run/tor
+PermissionsStartOnly=no
+ExecStartPre=+/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d 
/var/run/tor
 ExecStartPre=/usr/bin/tor --defaults-torrc 
/usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 
--verify-config
 ExecStart=/usr/bin/tor --defaults-torrc 
/usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
 ExecReload=/bin/kill -HUP ${MAINPID}


signature.asc
Description: PGP signature

Bug#858398: [Pkg-cmake-team] Proposed (lib)curl switch to openssl 1.1

[Lisandro Damián Nicanor Pérez Meyer]

El 2 dic. 2017 2:34 p.m., "Julien Cristau"  escribió:
[snip]

> 3. This might be an implicit a "transition" (in the Debian release
>management sense) which I would be mishandling, or starting without
>permission, or something.
>
Because of 1 I think we should change the package name (and SONAME) for
libcurl3.  I don't think 2 is appropriate.


Or 2ssl1.1 or alike, in case upstream does a future SONAME bump.

Of course changing SONAME means a transition, but that's the best way to
handle it in my opinion.

My two cents, Lisandro.

Bug#884848: lintian: false positive for source-includes-file-in-files-excluded

[Chris Lamb]

tags 884848 + pending
thanks

Woo, fixed in Git with tests:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b5eaeebead4cc0b4e218e3cdaaf201fa514144fe


Regards,

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

Bug#885146: horizon: [INTL:de] Updated German debconf translation

[Chris Leick]

Package: horizon
Version: 3:12.0.0-5
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#885145: blends-dev: blend-gen-control should use apt-get --allow-releaseinfo-change

[Markus Koschany]

Package: blends-dev
Version: 0.6.100
Severity: normal

Hiho,

while I was working on an update for debian-games, I discovered that
blend-gen-control would not update the apt sources.list and quit with
an error.

E: Repository 'http://ftp.debian.org/debian testing InRelease' changed its 
'Codename' value from 'stretch' to 'buster'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.

When I run make dist and try to release for unstable, the testing
repository will be updated and I will get a list with packages that
are listed in my task files but are not currently present in testing.
I had to change line 145 from

 my $aptget   = "apt-get --assume-yes -o " . join(" -o ", @aptopts);

 to

 my $aptget   = "apt-get --allow-releaseinfo-change --assume-yes -o " . join(" 
-o ", @aptopts);

to work around this issue.

Regards,

Markus

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
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: unable to detect

Versions of packages blends-dev depends on:
ii  build-essential  12.4
ii  debconf  1.5.65
ii  debhelper11
ii  make 4.1-9.1

blends-dev recommends no packages.

Versions of packages blends-dev suggests:
pn  blends-doc  

-- no debconf information

Bug#885144: firefox: Please drop dependency on gtk2

[Jeremy Bicha]

Source: firefox
Version: 58.0~b4-1

I am working on a goal to have Debian GNOME not ship gtk2 by default
for Buster. (There's some other desktops that might be able to achieve
this too.) The only significant blocker to this in my analysis is
Firefox.

Firefox has only one file that naturally depends on gtk2 which I
believe is only used by the Flash plugin now:
/usr/lib/firefox/gtk2/libmozgtk.so

All the Flash plugin packages in Ubuntu and Debian already depend on libgtk2.0-0
- adobe-flashplugin (Ubuntu only)
- flashplugin-installer (from source flashplugin-nonfree )
- pepperflashplugin-nonfree (works in Chromium not Firefox but
mentioned for completeness)

Therefore, I propose we use the same workaround we've used in several
other packages to drop the depends on gtk2. This has been accepted for
Ubuntu's Firefox 58. See

https://anonscm.debian.org/git/pkg-gnome/gnome-themes-standard.git/commit/?id=4c5691e

The only risk I see is that it is possible for someone to manually try
to install Flash without using the system packages but I don't think
we should worry about that use case.

I am aware of https://bugzilla.mozilla.org/1377445 but this issue is
about the binary dependency, not the build depenedency.

By the way, chromium-browser in Debian now depends on gtk3 but not gtk2.

Thanks,
Jeremy Bicha

Bug#884955: tuptime: Files to install

[Ricardo Fraile]

Hi Terry, 

Thank you for the detailed report, it helps me to figure it out where
was the issue plus the help of the service
"https://codesearch.debian.net";. 

As you correctly said, when the "su -" is executed, the scripts located
in the directory /etc/profile.d/ are executed too because it creates a
login shell. 

The process is detailed at the end of the file "/etc/profile" and is the
same for all Bourne-compatible shells, but some of them have a slighly
different behaviour: 

if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi 

A lot of packages use the form "su -s /bin/bash" instead of "su -". I
think too that this is a better approach, the loging shell is not
needed, I was wrong. 

The issue also affects to the init.d script, which was with the same "su
-" format. 

I just update the repo, in dev branch, it will be available in Debian in
a few weeks. 

https://github.com/rfrail3/tuptime.git 

Thanks, 

El 2017-12-24 05:29, Terry Roy escribió:

> I had some comments from the other bug reports I file which led me to do some 
> more testing. Here's what I found.
> 
> I've had three packages with this issue - spamassassin, sa-compile and 
> tuptime.
> 
> The user for spamassassin and sa-compile is debian-spamd whose shell is set 
> to /bin/sh. The user for tuptime is tuptime whose shell is also set to 
> /bin/sh. No other users on my system use /bin/sh.
> 
> Changing the shell to /bin/bash for tuptime for example, eliminates the error 
> with using 'su -'.
> 
> Aliases present no problem. Functions, depending on how they are written, do.
> 
> function somefunction () {} causes a problem.
> 
> function somefunction {} causes a problem.
> 
> somefunction () {} does not. Using the reserved word 'function' causes 
> /bin/sh to throw an error.
> 
> Interestingly, when using the reserved word function, the presence of () 
> changes the error message.
> 
> With the use of ():
> -sh: 5: /etc/profile.d/test.sh: Syntax error: "(" unexpected (expecting "fi")
> 
> Without the use of ():
> -sh: 5: /etc/profile.d/test.sh: function: not found
> 
> Definitely would have been much easier to spot the error had we not used ().
> 
> So while calling a login shell caused a problem, ultimately, it's because 
> /bin/sh does not recognise the reserved word 'function'. I'm not sure there's 
> a good solution for this. It seems to be such a specific issue. Had I not 
> created a user with a /bin/sh shell and tried to recreate the function for 
> that user, I'm not sure I would have twigged that the reserved word function 
> was causing the problem since the error kept coming back as the ( causing the 
> issue.
> 
> Thanks.

Bug#885141: tor: systemd unit files should confine tor as much as possible

[Nicolas Braud-Santoni]

PS: Here is a patch for the backports script.
I was unable to test it, as the script hardcodes your directory layout.

On Sun, Dec 24, 2017 at 03:36:59PM +0100, Nicolas Braud-Santoni wrote:
> Package: tor
> Version: 0.3.2.8-rc-1
> Severity: normal
> Tags: patch stretch buster sid
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi weasel,
> 
> Here is a patch for the systemd unit files that we ship with tor.
> 
> It prevents tor from having read-write access to /var/run, and from having
> access to /var/log (except for tor@default, which writes logs there).
> 
> Moreover, it restrict tor instances to their own directory under
> /var/{lib,run}/tor-instances, now that #781730 is solved.
> 
> I did not (yet) test it on instances other than @default, but I will do so
> momentarily.
> 
> 
> Best,
> 
>   nicoo
> 
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages tor depends on:
> ii  adduser 3.116
> ii  libc6   2.25-3
> ii  libcap2 1:2.25-1.2
> ii  libevent-2.1-6  2.1.8-stable-4
> ii  liblzma55.2.2-1.3
> ii  libseccomp2 2.3.1-2.1
> ii  libssl1.1   1.1.0g-2
> ii  libsystemd0 235-3
> ii  libzstd11.3.2+dfsg2-1
> ii  lsb-base9.20170808
> ii  zlib1g  1:1.2.8.dfsg-5
> 
> Versions of packages tor recommends:
> ii  logrotate3.11.0-0.1
> pn  tor-geoipdb  
> ii  torsocks 2.2.0-2
> 
> Versions of packages tor suggests:
> ii  apparmor-utils   2.11.1-4
> pn  mixmaster
> pn  obfs4proxy   
> ii  socat1.7.3.2-2
> ii  tor-arm  1.4.5.0-1.1
> ii  torbrowser-launcher  0.2.8-5
> 
> - -- Configuration Files:
> /etc/tor/torrc changed:
> SOCKSPort 9050 IPv6Traffic
> 
> 
> - -- no debconf information
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAlo/u4gZHG5pY29sYXNA
> YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z46gtD/0chaqTZjTlNCloeQXgRLPx
> quaEeXfytY61UpvX1ScpQDThLSpGcUW5SAnt/9LE04EHAmnqj30XmOAo0CQi41k4
> K3k+UUWTGaRtIV0+HeaHLdj9AlrXGXSsllk9RzlnXcq2udQhrawTrGbeXau/QeOX
> OL8oTFYT1qC9AEFh3f95nfEicyPv7j3/UYd/73vzzxA49lZ93FELXz5M3EHGiqCH
> 1nXMXPwoeYyEJApqe7jJdCCkrfgAO5fHogYzk5h518+Hd3fUHcwfj1zohRDp//L7
> AZdEzghwNEgkS9VpxQ62MAlueeEwpO7VY12WDC+tulx0Z9pKMhQ+2s25aca/v6e4
> ExE5oA4P9pwoGyyikRbYkq6G7FzTkLpZ1Fqz0VKEbiurrrLJTPG8CTBWDmk0aom0
> PBOgz1nbsqpLJVMPq2sOGS4RGbnxy30vzKmnU7RrBknpvVDrHEqQxNNFjxlLIwJZ
> D1HSOGuZHovVJ1pLqlNS5G2merVe67Rs7LBb09OlTqRLa4s5LOZooQbA7B2qx77z
> FbcJtgB3UeXFy1VtsjDORP+qCI2Ngz5GWGFqNlGYUPNrL+VbwfZs7PwbvuwYD9Fm
> dUIk/cfBxPlFpmEPrgMswNpezLXUX+cgQN0zzmHoAwSFdSmwZlcHDTCiDcPo6UrN
> 9svzH5COBLuPico9AOHHiA==
> =zvBv
> -END PGP SIGNATURE-

> commit 6d5e750ea1566c25d331e227bd1ef3b22cafd039
> Author: Nicolas Braud-Santoni 
> Date:   Sun Dec 24 14:22:44 2017 +0100
> 
> systemd: Prevent tor (except tor@default) from accessing /var/log
> 
> This prevents accidentally exposing sensitive information from logs
> to tor (such as nginx's currently-broken behaviour [0])
> 
> [0]: https://security-tracker.debian.org/tracker/source-package/nginx
> 
> diff --git a/debian/systemd/tor@.service b/debian/systemd/tor@.service
> index 749d517c7..acfbf14b9 100644
> --- a/debian/systemd/tor@.service
> +++ b/debian/systemd/tor@.service
> @@ -27,6 +27,7 @@ PrivateDevices=yes
>  ProtectHome=yes
>  ProtectSystem=full
>  ReadOnlyDirectories=/
> +InaccessibleDirectories=/var/log
>  ReadWriteDirectories=-/var/lib/tor-instances/%i
>  ReadWriteDirectories=-/var/run/tor-instances/%i
>  CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
> CAP_DAC_READ_SEARCH
> 
> commit 34814decca292b43adce9356c3ec247c1e41fa62
> Author: Nicolas Braud-Santoni 
> Date:   Sun Dec 24 14:17:40 2017 +0100
> 
> systemd: Restrict access to more specific paths under /var/run
> 
> This is possible thanks to #781730 being solved.
> 
> diff --git a/debian/systemd/tor@.service b/debian/systemd/tor@.service
> index d71cc31dc..749d517c7 100644
> --- a/debian/systemd/tor@.service
> +++ b/debian/systemd/tor@.service
> @@ -27,10 +27,8 @@ PrivateDevices=yes
>  ProtectHome=yes
>  ProtectSystem=full
>  ReadOnlyDirectories=/
> -# We would really like to restrict the next item to [..]/%i but we can't,
> -# as systemd does not support that yet.  See also #781730.
> -ReadWriteDirectories=-/var/lib/tor-instances
> -ReadWriteDirectories=-/var/run
> +ReadWriteDirectories=-/var/lib/tor-instances/%i
> +ReadWriteDirectories=-/var/run/tor-instances/%i
>  CapabilityBoundingSet=CAP_SETUID CAP_SETGID CA

Bug#885143: libreoffice-gtk2: Drop gtk2 support

[Jeremy Bicha]

Package: libreoffice-gtk2
Version: 1:6.0.0~rc1-1
Tags: buster sid

Please consider dropping gtk2 support even if upstream continues to
provide a gtk2 compile option.

While it's impractical in 2018 to have a Debian desktop without gtk3
installed (unless you want an obscure web browser), it will be
possible to have a desktop without gtk2 installed. And if gtk3 is
required anyway, why try to use gtk2?

libreoffice-gtk2 is currently used by default in the Debian Tasks for
Xfce, LXQt and LXDE. That may have made sense for Stretch because
Stretch shipped LibreOffice 5.2 (the first version where the gtk3
version was ready) but I don't think it makes sense for Buster.

There's a support burden to provide the gtk2 version that may be
unjustified if nearly everyone is using the gtk3 version.

Thanks,
Jeremy Bicha

Bug#642552: stop calling mtp-probe if it is not installed

[Marco d'Itri]

Control: tag -1 patch
Control: retitle -1 stop calling mtp-probe if it is not installed

This trivial patch instructs udev to not call mtp-probe if it is not 
available.
Please apply: this silly bug has been around since 2011.

--- 69-libmtp.rules.orig2017-12-24 16:14:29.102926048 +0100
+++ 69-libmtp.rules 2017-12-24 16:12:11.188007015 +0100
@@ -2279,6 +2279,8 @@
 # Isabella Her Prototype
 ATTR{idVendor}=="0b20", ATTR{idProduct}=="ddee", SYMLINK+="libmtp-%k", 
MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
 
+TEST!="/lib/udev/mtp-probe", GOTO="libmtp_rules_end"
+
 # Autoprobe vendor-specific, communication and PTP devices
 ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", 
ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", 
ATTR{bDeviceClass}=="00|02|06|ef|ff", PROGRAM="mtp-probe /sys$env{DEVPATH} 
$attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="libmtp-%k", MODE="660", 
GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1" 


-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#884964: using "su - " in postinst causing some installs to fail

[LinuxChix SysAdmin]

Thank you again, Simon, for your concise explanations.

We do have a policy on shell usage and the snippets were tested against 
those shells, but not against /bin/sh. My fault, I'm afraid, since I 
hadn't considered system users. We'll be adding that to our policy.


I've sent the info to the two packages I filed bug reports for. 
Hopefully, the next time someone runs into the issue, they'll be able to 
come across these discussions and resolve it quickly.


--
Terry

Bug#884662: reproducible-builds.org: regular files sometimes treated as directories

[Simon McVittie]

Control: reassign 884662 jenkins.debian.org
Control: retitle 884662 reproducible-builds.org: regular files sometimes 
treated as directories
Control: severity 884662 normal
Control: user jenkins.debian@packages.debian.org
Control: usertags 884662 = reproducible

On Mon, 18 Dec 2017 at 23:30:05 +, Simon McVittie wrote:
> dpkg-deb: building package 'libglib2.0-data' in 
> '../libglib2.0-data_2.54.2-2_all.deb'.
> tar: ./usr/share/locale/en_CA/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a 
> directory

This seems to be a symptom of some more general problem on the
reproducible-builds builders - I would guess it's either the
(FUSE?) filesystem, or a LD_PRELOAD hack that intercepts stat(), like
fakeroot does. Build logs indicate that regular files are sometimes
treated as directories by install(1), resulting in the build being
incomplete and unreproducible even in cases where it doesn't FTBFS:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/glib2.0.html

--- b1/build.log2017-12-21 23:47:26.25921 +
+++ b2/build.log2017-12-22 00:01:34.693734003 +
@@ -14556,6 +14571,7 @@
  /usr/bin/install -c -m 644 ./html/api-index-full.html
  /usr/bin/install -c -m 644 ./html/ch01s02.html
  /usr/bin/install -c -m 644 ./html/chapter-gobject.html
+/usr/bin/install: omitting directory './html/chapter-gobject.html'
  /usr/bin/install -c -m 644 ./html/chapter-gtype.html
  /usr/bin/install -c -m 644 ./html/chapter-intro.html
  /usr/bin/install -c -m 644 ./html/chapter-signal.html
@@ -14599,7 +14615,6 @@
  /usr/bin/install -c -m 644 ./html/left.png
  /usr/bin/install -c -m 644 ./html/pr01.html
  /usr/bin/install -c -m 644 ./html/pt01.html
-/usr/bin/install: omitting directory './html/pt01.html'
  /usr/bin/install -c -m 644 ./html/pt02.html
  /usr/bin/install -c -m 644 ./html/pt03.html
  /usr/bin/install -c -m 644 ./html/right-insensitive.png

(In a correct build, all of those files are regular files produced by
gtk-doc, and none are directories or symlinks.)

I am not aware of any reason why gtk-doc would produce
./html/chapter-gobject.html or ./html/pt01.html that are sometimes a
regular file and sometimes a directory, and I've never seen this happen
on the production buildds, so I suspect this might be some issue with
the filesystem or LD_PRELOADs used on the reproducible builders
non-deterministically producing incorrect stat() results that make
install(1) and tar(1) do the wrong thing. What filesystem is used for
the build, and which LD_PRELOAD hacks are applied?

The next upload of glib2.0 is going to have Rules-Requires-Root: no,
which will mitigate this if it's a problem with the implementation of
fakeroot used on these builders (but I'm not going to upload that until
after Christmas unless glib2.0 develops a new RC bug, because we need
to let the current version migrate so it won't block the rest of GNOME).

Regards,
smcv

Bug#884654: glib2.0: FTBFS on amd64 buildd: gdbus-peer test: assertion 'source->ref_count > 0' failed

[Simon McVittie]

Control: severity -1 important

On Tue, 19 Dec 2017 at 00:15:52 +, Simon McVittie wrote:
> On Mon, 18 Dec 2017 at 18:18:41 +, Simon McVittie wrote:
> > I can reproduce this by running the gdbus-peer test in a loop (this is
> > with GLib git master, not Debian's GLib, but that's close enough).
> 
> I can also reproduce it by building 2.54.1-1 or 2.54.2-2 and re-running
> that test in a loop, but not easily (running 100 times in a loop often
> succeeds). Having looked at the history of the code involved, I think
> this is a long-standing race condition

I've mitigated this bug by not running the gdbus-peer test on buildds
for now (it's still run during autopkgtest). It's still a bug, and I'm in
the process of getting it fixed upstream, but I don't think it deserves
to be RC.

smcv

Bug#885142: tasksel: Use non-transitional package for orca

[Jeremy Bicha]

Source: tasksel
Version: 3.42
Severity: minor
Tags: patch

gnome-orca is now a transitional package depending on orca.

I'll attach a patch in my follow-up email.

Thanks,
Jeremy Bicha

Bug#881696:

[Mirko Langisch]

from courier's changelog:

* courier/filters/courierfilter: Move courierfilter from sbindir to
libexecdir. Replace courierfilter is a shell script wrapper that
resets the environment before running the real courierfilter.

Bug#885141: tor: systemd unit files should confine tor as much as possible

[Nicolas Braud-Santoni]

Package: tor
Version: 0.3.2.8-rc-1
Severity: normal
Tags: patch stretch buster sid

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi weasel,

Here is a patch for the systemd unit files that we ship with tor.

It prevents tor from having read-write access to /var/run, and from having
access to /var/log (except for tor@default, which writes logs there).

Moreover, it restrict tor instances to their own directory under
/var/{lib,run}/tor-instances, now that #781730 is solved.

I did not (yet) test it on instances other than @default, but I will do so
momentarily.


Best,

  nicoo

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

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

Versions of packages tor depends on:
ii  adduser 3.116
ii  libc6   2.25-3
ii  libcap2 1:2.25-1.2
ii  libevent-2.1-6  2.1.8-stable-4
ii  liblzma55.2.2-1.3
ii  libseccomp2 2.3.1-2.1
ii  libssl1.1   1.1.0g-2
ii  libsystemd0 235-3
ii  libzstd11.3.2+dfsg2-1
ii  lsb-base9.20170808
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages tor recommends:
ii  logrotate3.11.0-0.1
pn  tor-geoipdb  
ii  torsocks 2.2.0-2

Versions of packages tor suggests:
ii  apparmor-utils   2.11.1-4
pn  mixmaster
pn  obfs4proxy   
ii  socat1.7.3.2-2
ii  tor-arm  1.4.5.0-1.1
ii  torbrowser-launcher  0.2.8-5

- -- Configuration Files:
/etc/tor/torrc changed:
SOCKSPort 9050 IPv6Traffic


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAlo/u4gZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z46gtD/0chaqTZjTlNCloeQXgRLPx
quaEeXfytY61UpvX1ScpQDThLSpGcUW5SAnt/9LE04EHAmnqj30XmOAo0CQi41k4
K3k+UUWTGaRtIV0+HeaHLdj9AlrXGXSsllk9RzlnXcq2udQhrawTrGbeXau/QeOX
OL8oTFYT1qC9AEFh3f95nfEicyPv7j3/UYd/73vzzxA49lZ93FELXz5M3EHGiqCH
1nXMXPwoeYyEJApqe7jJdCCkrfgAO5fHogYzk5h518+Hd3fUHcwfj1zohRDp//L7
AZdEzghwNEgkS9VpxQ62MAlueeEwpO7VY12WDC+tulx0Z9pKMhQ+2s25aca/v6e4
ExE5oA4P9pwoGyyikRbYkq6G7FzTkLpZ1Fqz0VKEbiurrrLJTPG8CTBWDmk0aom0
PBOgz1nbsqpLJVMPq2sOGS4RGbnxy30vzKmnU7RrBknpvVDrHEqQxNNFjxlLIwJZ
D1HSOGuZHovVJ1pLqlNS5G2merVe67Rs7LBb09OlTqRLa4s5LOZooQbA7B2qx77z
FbcJtgB3UeXFy1VtsjDORP+qCI2Ngz5GWGFqNlGYUPNrL+VbwfZs7PwbvuwYD9Fm
dUIk/cfBxPlFpmEPrgMswNpezLXUX+cgQN0zzmHoAwSFdSmwZlcHDTCiDcPo6UrN
9svzH5COBLuPico9AOHHiA==
=zvBv
-END PGP SIGNATURE-
commit 6d5e750ea1566c25d331e227bd1ef3b22cafd039
Author: Nicolas Braud-Santoni 
Date:   Sun Dec 24 14:22:44 2017 +0100

systemd: Prevent tor (except tor@default) from accessing /var/log

This prevents accidentally exposing sensitive information from logs
to tor (such as nginx's currently-broken behaviour [0])

[0]: https://security-tracker.debian.org/tracker/source-package/nginx

diff --git a/debian/systemd/tor@.service b/debian/systemd/tor@.service
index 749d517c7..acfbf14b9 100644
--- a/debian/systemd/tor@.service
+++ b/debian/systemd/tor@.service
@@ -27,6 +27,7 @@ PrivateDevices=yes
 ProtectHome=yes
 ProtectSystem=full
 ReadOnlyDirectories=/
+InaccessibleDirectories=/var/log
 ReadWriteDirectories=-/var/lib/tor-instances/%i
 ReadWriteDirectories=-/var/run/tor-instances/%i
 CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
CAP_DAC_READ_SEARCH

commit 34814decca292b43adce9356c3ec247c1e41fa62
Author: Nicolas Braud-Santoni 
Date:   Sun Dec 24 14:17:40 2017 +0100

systemd: Restrict access to more specific paths under /var/run

This is possible thanks to #781730 being solved.

diff --git a/debian/systemd/tor@.service b/debian/systemd/tor@.service
index d71cc31dc..749d517c7 100644
--- a/debian/systemd/tor@.service
+++ b/debian/systemd/tor@.service
@@ -27,10 +27,8 @@ PrivateDevices=yes
 ProtectHome=yes
 ProtectSystem=full
 ReadOnlyDirectories=/
-# We would really like to restrict the next item to [..]/%i but we can't,
-# as systemd does not support that yet.  See also #781730.
-ReadWriteDirectories=-/var/lib/tor-instances
-ReadWriteDirectories=-/var/run
+ReadWriteDirectories=-/var/lib/tor-instances/%i
+ReadWriteDirectories=-/var/run/tor-instances/%i
 CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
CAP_DAC_READ_SEARCH
 
 [Install]
diff --git a/debian/systemd/tor@default.service 
b/debian/systemd/tor@default.service
index 39d6ba848..161838f56 100644
--- a/debian/systemd/tor@default.service
+++ b/debian/systemd/tor@default.service
@@ -30,5 +30,5 @@ ReadOnlyDirectories=/
 ReadWriteDirectories=-/proc
 ReadWriteDirectories=-/var/lib/tor
 ReadWriteDirectories=-/var/log/tor
-ReadWriteDirectories=-/var/run
+ReadWriteDirectories=-/var/run/tor
 Capabi

Bug#881696:

[Mirko Langisch]

any news on this?

tbh, it looks like the courier package isn't really maintained anymore, i
even waited 3 months before upgrading to 0.78 and yet it broke my mail
server once again: "432 Mail filters temporarily unavailable." \o/

Bug#885140: wicd: Depends on unmaintained pygtk

[Jeremy Bicha]

Source: wicd
Version: 1.7.4+tb2-5
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#743512: Also seen in grub-pc 1.99-27+deb7u3

[Robert L Mathews]

I can confirm this report. I occasionally do what the original reporter
does: replace an entire set of disks on a live server using mdadm --fail
/ mdadm --remove / [physical hot swap] / mdadm --add / grub-install, and
the identical problem happened to me.

In my case the disks are a three-disk RAID 1 array rather than RAID 10,
and I partitioned them with "parted" rather than using "dd".

I replaced the first two and grub-install worked with no trouble:

# grub-install /dev/sdc

# grub-install /dev/sdb

But the third gave me:

# grub-install /dev/sda
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/md0 failed.

# grub-install --recheck /dev/sda
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/md0 failed.

... with the other symptoms identical.

To my astonishment, running this:

# mdadm --examine /dev/sda2

... fixed it; "grub-install /dev/sda" then works without errors.

Clearly "mdadm --examine" has a mysterious helpful side-effect, the
nature of which is puzzling.

However, I can't reproduce the original problem on demand; this has
happened to me only once when doing this on about half a dozen
physically identical (in terms of hardware) servers.

-- 
Robert L Mathews

Bug#885138: bauble: Depends on unmaintained pygtk

[Jeremy Bicha]

Source: bauble
Version: 0.9.7-2.1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885139: blueproximity: Depends on unmaintained pygtk

[Jeremy Bicha]

Source: blueproximity
Version: 1.2.5-6
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885137: ITP: node-serialize-javascript -- Serialize JavaScript to a superset of JSON

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-serialize-javascript
  Version : 1.4.0
  Upstream Author : Eric Ferraiuolo 
* URL : https://github.com/yahoo/serialize-javascript
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Serialize JavaScript to a superset of JSON

 This superset of JSON includes regular expressions, dates and
functions. The
 code in this package began its life as an internal module to express-state.
 .
 Advantages over JSON.stringify(): sometimes we need to serialize JavaScript
 functions, regexps or dates. A great example is a web app that uses
 client-side URL routing where the route definitions are regexps that
need to
 be shared from the server to the client.
 .
 The string returned from this package's single export function is literal
 JavaScript which can be saved to a .js file, or be embedded into an HTML
 document by making the content of a 

Bug#885136: 4digits: Depends on unmaintained pygtk

[Jeremy Bicha]

Package: 4digits
Version: 1.1.4-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885135: pygtk: Unmaintained, use GObject Introspection instead

[Jeremy Bicha]

Source: pytgtk
Version: 2.24.0-5.1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#880615: linux-latest: systemd complains about CONFIG_BPF_SYSCALL not being set

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi

On Thu, Nov 02, 2017 at 12:45:33PM -0700, Francois Marier wrote:
> Source: linux-latest
> Version: 86
> Severity: normal
> 
> systemd complains in syslog about Debian kernels not supporting BPF/cgroup
> firewalling:
> 
>   systemd[1]: File /lib/systemd/system/systemd-udevd.service:32 configures an 
> IP firewall (IPAddressDeny=any), but the local system does not support 
> BPF/cgroup based firewalling.
>   systemd[1]: File /lib/systemd/system/systemd-logind.service:35 configures 
> an IP firewall (IPAddressDeny=any), but the local system does not support 
> BPF/cgroup based firewalling.
>   systemd[1]: File /lib/systemd/system/systemd-journald.service:33 configures 
> an IP firewall (IPAddressDeny=any), but the local system does not support 
> BPF/cgroup based firewalling.
> 
> According to this upstream bug:
> 
>   https://github.com/systemd/systemd/issues/7188
> 
> it's just a matter of adding the following to the kernel config:
> 
>   CONFIG_BPF_SYSCALL=y

CONFIG_BPF_SYSCALL=y is already set since 4.2.5-1. Should that be
CONFIG_CGROUP_BPF in addition (cf. #872560).

Regards,
Salvatore

Bug#879526: dgit broken by recent dpkg (Can't locate object method "new" via package "Dpkg::Compression::Process" …)

[Cyril Brulebois]

Ian Jackson  (2017-10-22):
> On stretch:
>   perl -we 'use Dpkg::Source::Package; my $x = new Dpkg::Compression::Process'
> 
> On sid (libdpkg-perl 1.19.0.3):
>   (build)ian@zealot:~$ perl -we 'use Dpkg::Source::Package; my $x = new 
> Dpkg::Compression::Process'
>   Can't locate object method "new" via package "Dpkg::Compression::Process" 
> (perhaps you forgot to load "Dpkg::Compression::Process"?) at -e line 1.
> 
> Sadly I am not aware of a good way of detecting missing `use'
> direcctives other than waiting for things to break when an implicitly
> loaded module is no longer loaded.

I'm not sure what the problem with use-ing Dpkg::Compression::Process
unconditionally would be?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#885134: gnome-icon-theme-extras: Don't include in Debian

[Jeremy Bicha]

Source: gnome-icon-theme-extras
Version: 3.12.0-1
Severity: serious

This theme has been unmaintained upstream since March 2014. While
arguably, an icon theme may not need much maintainance…

- It provides some additional icons for the GNOME icon theme but the
GNOME icon theme is unmaintained and deprecated. The replacement is
the Adwaita icon theme, but upstream intentionally does not have
Adwaita inherit from the GNOME theme (so these icons won't be usable
by default).

- Many of the icons are in the Adwaita theme now.

- Several icons are not. But some of these are for ancient phones like
the Nexus One.

- In general, I think that if there are important missing icons, they
should be requested to be moved to the Adwaita icon theme directly.
Alternatively, someone could make an adwaita-icon-theme-extras package
but be careful about 2 packages shipping the same file if upstream
does eventually adopt some of the icon names.

- No reverse depends. However, 'gnome-core' used to Depend on it
before Stretch, which explains its lingering high popcon.

I am filing this bug to allow a bit of comment and notice with the
auto-removal before requesting that gnome-icon-theme-extras be
complete removed from Debian.

Thanks,
Jeremy Bicha

Bug#885106: lintian: Please update dh_commands for scour 0.36

[Chris Lamb]

tags 885106 + pending
thanks

Fixed in Git; many thanks!

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=60a3ab35a0487b02b9a38d9065cdefdd17468485


Regards,

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

Bug#885133: gnome-search-tool: Don't include in Buster

[Jeremy Bicha]

Source: gnome-search-tool
Version: 3.6.0-2
Severity: serious

gnome-search-tool has had to releases since September 2012, over 5 years ago.

It provides basic search functionality that is built in to every
modern file browser.

It has no reverse dependencies and doesn't seem to be a very popular app at all.

Unless someone has a strong objection, I propose that we not include
gnome-search-tool in Buster and remove it from Debian.

Thanks,
Jeremy Bicha

Bug#885084: [src:vlc] Shishensho squawks on VLC installation when game is won

[David Baron]

On יום ראשון, 24 בדצמבר 2017 11:32:14 IST Sebastian Ramacher wrote:
> Control: tags -1 + moreinfo
> Control: found -1 3.0.0~rc2-2
> Control: notfound -1 Sid
> 
> On 2017-12-23 19:06:29, David Baron wrote:
> > Package: src:vlc
> > Version: Sid
> > Severity: normal
> > 
> > --- Please enter the report below this line. ---
> > When a game of kshishen is played and won, the program will then put up
> > high scores for that game variation. At this point an error box come up:
> > Phonon's VLC backend failed to start.
> > ... indicates problem with VLC installation.
> > 
> > I have no idea what it needs with VLC for this function, but that is the
> > package called out.
> 
> We really need to know more, i.e. all the information reportbug usually
> sends with bug reports. Please let us know all the versions of all vlc
> related packages and especially those of phonon-backend-vlc and
> phonon4qt5-backend-vlc.
> 
> Cheers

Should have been included but I guess flagging as src defeats all that.
My installation is an up-to-date Sid. So whatever is on unstable. Note that 
these packages updated today so I will retry, see if the problem persists.

Bug#885132: ejabberd 17.08 is incompatible with erlang-p1-xmpp 1.16

[pitchum]

Package: ejabberd
Version: 17.08-3
Severity: important

Since the last upgrade in Buster my ejabberd server has problems
with s2s outgoing connections. See the bugreport I posted upgream:
"Hook s2s_out_closed crashed"
https://github.com/processone/ejabberd/issues/2185

Downgrading erlang-p1-xmpp to 1.14 solves the problem as
suggested by the upstream developer.


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (800, 'stable'), (200, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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)

Versions of packages ejabberd depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  erlang-asn11:20.2.1+dfsg-1
ii  erlang-base [erlang-abi-17.0]  1:20.2.1+dfsg-1
ii  erlang-crypto  1:20.2.1+dfsg-1
ii  erlang-inets   1:20.2.1+dfsg-1
ii  erlang-jiffy   0.14.8+dfsg-1
ii  erlang-lager   3.5.2-1
ii  erlang-mnesia  1:20.2.1+dfsg-1
ii  erlang-odbc1:20.2.1+dfsg-1
ii  erlang-p1-cache-tab1.0.12-1
ii  erlang-p1-iconv1.0.6-1
ii  erlang-p1-stringprep   1.0.10-1
ii  erlang-p1-tls  1.0.17-1
ii  erlang-p1-utils1.0.10-1
ii  erlang-p1-xml  1.1.25-1
ii  erlang-p1-xmpp 1.1.14-1
ii  erlang-p1-yaml 1.0.12-1
ii  erlang-p1-zlib 1.0.3-1
ii  erlang-public-key  1:20.2.1+dfsg-1
ii  erlang-ssl 1:20.2.1+dfsg-1
ii  erlang-syntax-tools1:20.2.1+dfsg-1
ii  erlang-xmerl   1:20.2.1+dfsg-1
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  openssl1.1.0f-3+deb9u1
ii  ucf3.0036

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
pn  apparmor 
pn  apparmor-utils   
pn  ejabberd-contrib 
pn  erlang-luerl 
pn  erlang-p1-mysql  
pn  erlang-p1-oauth2 
pn  erlang-p1-pam
pn  erlang-p1-pgsql  
pn  erlang-p1-sip
pn  erlang-p1-sqlite3
pn  erlang-p1-stun   
pn  erlang-redis-client  
pn  imagemagick  
pn  libunix-syslog-perl  
pn  yamllint 

-- Configuration Files:
/etc/default/ejabberd changed [not included]
/etc/logrotate.d/ejabberd changed [not included]

-- debconf information excluded

Bug#884419: [Pkg-privacy-maintainers] Bug#884419: torbrowser-launcher: debian/rules clean does not run dh_clean

[Roger Shimizu]

control: severity -1 important
control: tags -1 +patch +pending

On Fri, Dec 15, 2017 at 9:56 AM, Andreas Beckmann  wrote:
> Without calling dh_clean, all the temporary stuff in debian/ is retained,
> but luckily dpkg-source chokes on unwanted binaries, refusing to create
> a source package full of binary cruft.
>
> The override_dh_clean target needs to call dh_clean in addition to any
> further cleanup it does.

Thanks for the report!

Though it's policy related, I don't think it deserves testing removal level.
Anyway, I pushed a commit [0] to fix this.

I also confirmed in my box that adding dh_clean is not enough.
It need purging build/ folder manually.

[0] 
https://anonscm.debian.org/cgit/pkg-privacy/packages/torbrowser-launcher.git/commit/?id=f5a953e

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#828451: Patches

[Chris West]

Control: tags -1 + patch

I've sent upstream some patches:
 * https://github.com/netty/netty-tcnative/pull/325
 * https://github.com/netty/netty/pull/7544

There hasn't been any objections, beyond an unwillingness to remove the
feature. I am pretty sure we can live with having removed the feature,
so could apply the patches regardless of upstream's decision.

The patches turned out to be very small, and will usefully conflict with
any upstream changes, e.g. if they decide to properly fix renegotiation.

Chris.

Bug#884974: sdpa: hardcoded mumps runtime dependency

[Makoto Yamashita]

Dear Mr. Gianfranco Costamagna,

Thank you very much for your mail.

Your mail makes me understand your points, and I agree them.

However, unfortunately for us, I could not resolve the issues.
(I tried them before, but I could not.)

When I prepared the debian package, I needed  libmumps-seq-4.10.0.
Without  libmumps-seq-4.10.0, the SDPA package installed by apt-get
could not work, since apt-get could not know that SDPA requires the mumps
library.

And, as for OpenBLAS, as you already know that we switched from ATLAS to
OpenBLAS.
A main reason is that OpenBLAS is much faster than ATLAS.
It would be great that OpenBLAS would work on more plathomes.

Thank you very much again.
Makoto Yamashita




2017-12-24 21:38 GMT+09:00 Gianfranco Costamagna :

> Hello,
>
> >I already applied the patch you sent before.
> >Could you give me more details on what you are indicating?
> >It is now too ambiguous to do a next step correctly.
> >Now, I cannot find any trouble.
>
>
> trouble is:
> 1) you hardcode a runtime dependency on mumps, this makes impossible to do
> a new mumps
> transition without having to full source upload sdpa each times.
> 2) You are including it statically, without no good reason
>
> see the patch here to know how to properly do it
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=
> 868505;filename=debdiff2;msg=27
>
> other issues:
> a) it depends on openblas where it is not available. This is making the
> package not built where it has been
> in previous releases.
> You should drop that dependency, or ask ftpmasters to remove such
> architectures
> https://buildd.debian.org/status/package.php?p=sdpa&suite=unstable
>
> hope this clarifies a bit
>
> G.
>

Bug#884974: sdpa: hardcoded mumps runtime dependency

[Gianfranco Costamagna]

Hello,

>I already applied the patch you sent before.
>Could you give me more details on what you are indicating?
>It is now too ambiguous to do a next step correctly.
>Now, I cannot find any trouble.


trouble is:
1) you hardcode a runtime dependency on mumps, this makes impossible to do a 
new mumps
transition without having to full source upload sdpa each times.
2) You are including it statically, without no good reason

see the patch here to know how to properly do it
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=868505;filename=debdiff2;msg=27

other issues:
a) it depends on openblas where it is not available. This is making the package 
not built where it has been
in previous releases.
You should drop that dependency, or ask ftpmasters to remove such architectures
https://buildd.debian.org/status/package.php?p=sdpa&suite=unstable

hope this clarifies a bit

G.

Bug#885019: reconsider placement of glib-compile-resources

[Simon McVittie]

On Sat, 23 Dec 2017 at 14:11:38 +0100, Helmut Grohne wrote:
> On Fri, Dec 22, 2017 at 11:08:58PM +, Simon McVittie wrote:
> > As far as I can tell from skim-reading its source code, this tool has
> > non-architecture-dependent output, so it should live in libglib2.0-bin or
> > libglib2.0-dev-bin (optionally with symlinks in all the arch-dependent
> > places shipped in for libglib2.0-{0,dev} for backwards compat, if there
> > might be packages that hard-code this Debianism rather than using either
> > PATH or pkg-config). I suspect the arch-dependent symlinks wouldn't be
> > needed, assuming we stop patching the .pc file to refer to them.
> 
> Matches my evaluation. Let me try to turn that into actions:
>  * move glib-compile-resources to libglib2.0-dev-bin (in /usr/bin)
>  * Turn the triplet-location into a symlink.

As I said, I suspect we don't actually need the triplet-location after
the .pc file has been updated, although I'd have to check in codesearch
to be sure.

>  * Update the .pc files to refer to the /usr/bin instance.

That would consist of altering
debian/patches/61_glib-compile-binaries-path.patch so it only affects
glib-compile-schemas, not glib-compile-resources.

>  * Ensure tight enough dependencies and work out breaks/replaces.
> 
> Do you agree with this plan? I'd try to come up with a patch for that.

I can't speak for other maintainers, but I suspect that confirming that
your patch was the right thing to do would take about as long as making
a patch myself, so don't bother unless you're in a particular hurry to
get this done. I'll try to get some time for this over Christmas.

> > The maintainer who packaged it that way might have mixed it up with
> > the older glib-compile-schemas, which genuinely does need to be run on
> > non-developer systems (it's used in maintainer scripts).
> 
> I admit that I am bewildered by the frequent "Exec format error" from
> glib-compile-schemas that I see when configuring glib-ish packages for
> foreign architectures. I am yet unsure whether I should be more
> concerned about the "Exec format error" or the fact the postinst
> succeeds anyway. Something is very wrong here as well, but thus far I
> couldn't connect it to any cross build failures so maybe it really is
> harmless.

It's harmless.

gio-querymodules (which is executed alongside glib-compile-schemas)
genuinely does need to be separate for each architecture: it dlopens the
plugins for which it's building a cache. For each instance of GLib you
have installed, either you can execute binaries of that architecture,
or you can't. If you can (let's say it's libglib2.0-0:i386 on your
amd64 system), gio-querymodules runs and everything is fine. If you can't
(let's say it's libglib2.0-0:mips on your amd64 system, and you don't have
qemu-mips set up) then no mips binary is going to run on this machine
*anyway*, so it doesn't matter that the cache that would be loaded by
a mips libgio isn't valid, because nothing is going to load it.

The only harm done by the current approach, apart from the "Exec format
error", is that the "|| true" applied to the invocation of these tools
masks any genuine errors they might encounter. If dpkg had an interface
for "tell me whether I should expect to be able to execute mips binaries",
then we could use that; but it currently doesn't, so the current approach
is the best we can do for gio-querymodules.

Cross-compiling is all about installing foreign architectures' libraries
that you can't actually execute, but library packages' dependencies are
normally about what is necessary to *use* (execute) those libraries, so
it isn't entirely unexpected that there is some weirdness going on there.

glib-compile-schemas works with architecture-independent files (GSettings
schemata) and builds them into a cache. You have some set of GLib
architectures installed, and you have some set of architectures you
can run. If there is a non-empty overlap, then at least one instance
of glib-compile-schemas succeeds, and you have a valid schema cache.
If there is no architecture where you have GLib *and* can run it, then
it doesn't matter that your schema cache is invalid, because nothing is
going to load that cache on your machine.

If gio-querymodules didn't exist, then I'd be more sympathetic towards
the idea that glib-compile-schemas can't be allowed to fail, although I
can't say I'd be entirely comfortable with adding a circular dependency;
but gio-querymodules does exist, so we already have to deal with the
fact that we might be trying to build caches using helper binaries that
we can't actually run, and we might as well take the same approach for
glib-compile-schemas.

> Well, I suggested relaxing the policy wording to a "should", but a
> non-representative survey on #debian-devel seemed in favour of keeping
> it a "must". I'm unsure where to draw the line. Soname bumps of things
> like glib or glibc are extremely unlikely, yet the policy wording
> requires taking care of this possib

Bug#884964: using "su - " in postinst causing some installs to fail

[Simon McVittie]

On Sat, 23 Dec 2017 at 22:04:44 -0600, LinuxChix SysAdmin wrote:
> Changing the shell to /bin/bash for tuptime for example, eliminates the
> error with using 'su -'.

When writing profile.d snippets, you can't assume that every user has
bash as their login shell. profile.d snippets need to be written to be
at least minimally compatible with the POSIX shell language, if only
via a guard like

if [ -n "$BASH_VERSION" ] || [ -n "$ZSH_VERSION" ]; then
... your bashisms here ...
fi

Debian's default /bin/sh (dash) implements the POSIX shell language and
hardly any more than that.

POSIX shell:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

The superset of POSIX shell that a Debian /bin/sh can be assumed to have:
https://www.debian.org/doc/debian-policy/#scripts

(I think dash implements *slightly* more than what Policy §10.4 requires
it to.)

> Aliases present no problem. Functions, depending on how they are written,
> do.

Yes. Aliases are part of the POSIX shell language, and so are functions defined
with the somefunction () {...} syntax, but the function reserved word in
bash is not a reserved word in the POSIX shell language.

It's unfortunate that the POSIX shell language has so many traps and
pitfalls, but we're several decades too late to influence how it works.

> Doing the same thing but with the () included did not work. That has me
> scratching my head. It should have bypassed those lines entirely.

() is a special token in POSIX /bin/sh, so it can affect tokenization
even inside a check for bash. If you're doing something tricky, you can
use a pattern like


if [ -n "$BASH_VERSION" ]; then
. /usr/local/share/my-bashisms
fi

to dodge that, and put the parts that have weird tokenization in
/usr/local/share/my-bashisms.

> I'm not sure there's a good solution for this. It seems to be
> such a specific issue.

Welcome to shell scripting. :-(

smcv

Bug#884958: illegal instruction crash

[Gianfranco Costamagna]

control: reassign -1 src:libb2
control: affects -1 borgbackup
control: found -1 0.97-4
control: forwarded -1 https://github.com/BLAKE2/libb2/issues/13
>   >│0x739b900a vpxor  %xmm0,%xmm0,%xmm0  
>  │
>│0x739b900e sub$0x48,%rsp 
>  │
>│0x739b9012 mov$0x101,%eax
>  │
>│0x739b9017 vmovaps %xmm0,(%rsp)  
>  │
> 
> So, it's using a AVX XOR instruction not supported by the CPU.
> This is on a Xen VPS host, I've included /proc/cpuinfo below.
> 

this seems to be a libb2 issue.

G.



signature.asc
Description: OpenPGP digital signature

Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )

[Albert van der Horst]

Geert Stappers schreef op 2017-12-22 10:18:

Control: owner -1 !


Also, is this the real source (AKA, "preferred form for 
modification")?
Assembler is a valid language, generated assembler (nor generated 
shell,
generated C, ...) is not.  Some parts say about a configuration 
process

that, as it seems to me, expands variables for a particular platform.




; If this is a configured assembly file, it should be accompanied with
configured
; documentation (texinfo, ps, html.)
; WITHOUT THE DOCUMENTATION: GIVE UP! GET THE REAL THING!
; You have a configured system, if there are NO curly brackets on the 
next line.

;
;
; Configuration of this particular version:
; 32-bits protected mode
; running under Linux  ;  with native forth I/O



So yes, I have the feeling that I'm dealing with generated assembly.

The  .orig.tar.gz does have  ci86.lina.fas
I wonder what generated it and from what.

@Albert: Would you please elaborate?


I appreciate and understand what "prefered form of modification is".
I also understand that Debian must thread carefully here, and not accept
packages that bend the rules. This package certainly doesn't not go 
against

the spirit of the rules and may only superficially seem not to
obey the letter of the law.
This has been discussed already to some extent.

There is a choice of assemblers . I've a kind of generic assembler code,
(that is not assembler code that could be assembled by any assembler)
and then an m4 script that transforms it to either fasm, .s nasm or even 
tasm or

masm format.

This is *not* generated assembler. The assembler is a genuine source. 
There is only

a limited processing between equivalent forms, to present a readable and
modifiable source to some one inclined to modify lina.
There is a one to one correspondance between a line with an assembler 
instruction
in lina.fas lina.s lina.asm lina.nasm and the preconfiguration system, 
and they

all correspond to the same binary code.

The base system also contains code for MS-windows and MSDOS
or even stand alone. This is removed by m4 to present a proper Linux
source. Nothing is gained by drawing all this linux foreign code into
a Debian package, merely to remove it. The more so as this system is
available  and GPL-ed in its own right to be used by anybody
 interested in e.g. an UEFI system booting directly into Forth.

Likewise there is also base documentation with an m4 provision to remove 
all the MS
related documentation for a Linux texinfo file. I wanted to avoid the 
situation with the gnu assembler where almost all options are irrelevant 
for the processor one is

currently working with.

So in short it is a matter of configuration and selection, not 
generation.






Groeten
Geert Stappers


Groetjes Albert

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Bug#885131: nullmailer: Please log to /var/log/mail.log

[Elimar Riesebieter]

Package: nullmailer
Version: 1:2.1-4
Severity: wishlist

Dear maintainer,

I am aware that nullmailer now logs via systemd. To get a more
sorted overview it would be better to separate nullmailer's log
messages to i.e. /var/log/mail.log or even
/var/mail/nullmailer/whatever.

Thanks in advance
Elimar

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

Kernel: Linux 4.15.0-rc4-galadriel-lxtec-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nullmailer depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  libc6  2.25-5
ii  libgnutls303.5.16-1
ii  libstdc++6 7.2.0-18
ii  lsb-base   9.20170808
ii  systemd-sysv   236-1

Versions of packages nullmailer recommends:
ii  rsyslog [system-log-daemon]  8.31.0-2

nullmailer suggests no packages.

-- debconf information excluded

Bug#885130: orca: File conflict with gnome-orca 3.26.0-3 via /etc/xdg/autostart/orca-autostart.desktop

[Boyuan Yang]

Package: orca
Version: 3.26.0-4
Severity: normal

I was doing "apt upgrade" on my Debian Unstable today when I encountered this:

正在选中未选择的软件包 orca。
正准备解包 .../04-orca_3.26.0-4_all.deb  ...
正在解包 orca (3.26.0-4) ...
dpkg: 处理归档 /tmp/apt-dpkg-install-kGRxsa/04-orca_3.26.0-4_all.deb (--unpack)时出错：
 正试图覆盖 /etc/xdg/autostart/orca-autostart.desktop，它同时被包含于软件包 gnome-orca 3.26.0-3
dpkg-deb: 错误: 粘贴 subprocess was killed by signal (断开的管道)
正准备解包 .../05-gnome-orca_3.26.0-4_all.deb  ...
正在将 gnome-orca (3.26.0-4) 解包到 (3.26.0-3) 上 ...

(sorry for non-English locale, but the problem is clear above)

Perhaps we should add versioned Replaces+Breaks to the new package.

Regards,
Boyuan Yang



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

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

Versions of packages orca depends on:
ii  gir1.2-glib-2.01.54.1-4
ii  gir1.2-gtk-3.0 3.22.26-2
ii  gir1.2-pango-1.0   1.40.14-1
ii  gir1.2-wnck-3.03.24.1-1
ii  gsettings-desktop-schemas  3.24.1-2
ii  python33.6.4~rc1-2
ii  python3-brlapi 5.5-4
ii  python3-cairo  1.15.4-2
ii  python3-gi 3.26.1-2
ii  python3-louis  3.3.0-1
ii  python3-pyatspi2.26.0+dfsg-1
ii  python3-speechd0.8.8-1
ii  speech-dispatcher  0.8.8-1

Versions of packages orca recommends:
ii  xbrlapi  5.5-4

orca suggests no packages.

Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )

[Albert van der Horst]

Adam Borowski schreef op 2017-12-21 20:26:

On Wed, Dec 06, 2017 at 05:51:50PM +0100, Albert van der Horst wrote:

 * Package name: lina
Version : 5.3.0-1


Hi!  I for one don't know the slightest bit about Forth, but as no one 
has
taken this RFS, I can review packaging only -- which, while not ideal, 
is

not a show stopper for uploading.


Thanks for the review. It was hard to do everything right from the
Debian documents alone. With the remarks from you and Geert Stappers,
I hope to upload a version 5.3.0-1 that address most of the issues,
hopefully all.




I'm afraid the package fails to build, you need to add fasm to
Build-Depends.




Also, "defects detected by lintian" means nothing.  What matters is 
_what_

needed to be fixed, not what tool was used to spot the defect.



And I always chastize others for non meaningful change messages ...



Before we even start, it would be nice if you could address the rest of
issues detected by lintian -- an automated system saves a lot of human 
time.


Sure thing. Don't waste any more time until I've addressed those.




Also, is this the real source (AKA, "preferred form for modification")?


This is important and I've addressed it in an answer to Geert.

Your choice of a language to code a compiler is... interesting.  But 
then,

at least it's not node.js, php or python :)


As I said in a reply to Geert, this is a compiler, not a scripting
language on top of C. ;-)
A true compiler is written in its own language after an assembly
bootstrap. lina is in this vein, the bulk of the code is in the
library, e.g.
   lina -c hello.frt
runs code from the third (c-th) "block" of the library in order to
compile hello.frt into an elf executable.




May your family not interfere with hacking the next few days.  Meow!


The holidays are perfect for hacking.

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

On Sun, Dec 24, 2017 at 12:52:47PM +0100, Gudjon I. Gudjonsson wrote:

Hi Gudjon,

> You are right. I did compile the file in a normal environment with elyxer 
> installed, sorry.
> But I cannot compile the package (version 27) after I uninstall elyxer. Lyx 
> fails without any 
> proper error message.
> The problem seems to be in the new documentation. If I copy the documentation 
> from ngspice-26 to
> ngspice-27, build-indep works.
> ngspice-26, manual.lyx is made with lyx 2.0 and lyx format 413
> ngspice-27, manual.lyx is made with lyx 2.1 and lyx format 474
> 
> Do you have any idea on how to remove this elyxer dependency from manual.lyx?

I doubt there is a dependency on elyxer. elyxer is just a lyx2html converter 
written
indepedently and stalled now for a few years.
I guess that you've to reconfigure LyX so it knows that elyxer is no longer 
available.
That's something you can only do in the GUI so far.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397464
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816173
is also partially related.

So if you do not use LyX for interactive document writing just rm -r ~/.lyx in 
your
build environment and it should reconfigure on the next invocation.

Another possibility would be that lyx fails to import and convert the manual to 
the
current LyX 2.2.x document format.
Which repo are you building from right now? I'd like to try it out just to see 
what
happens.

Cheers,
Sven

Bug#885129: java-atk-wrapper FTCBFS: javac: Exec format error

[Helmut Grohne]

Source: java-atk-wrapper
Version: 0.33.3-13
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

java-atk-wrapper fails to cross build from source, because it fails
running javac with an "Exec format error". In theory, an arch-only build
should not need to run javac as the resulting class files are only put
into an arch:all package. That seemed difficult to me, so the next best
option is to annotate default-jdk with :native. Once doing so,
java-atk-wrapper cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru java-atk-wrapper-0.33.3/debian/changelog 
java-atk-wrapper-0.33.3/debian/changelog
--- java-atk-wrapper-0.33.3/debian/changelog2016-12-11 13:08:23.0 
+0100
+++ java-atk-wrapper-0.33.3/debian/changelog2017-12-24 12:51:57.0 
+0100
@@ -1,3 +1,10 @@
+java-atk-wrapper (0.33.3-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate default-jdk dependency with :native. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 24 Dec 2017 12:51:57 +0100
+
 java-atk-wrapper (0.33.3-13) unstable; urgency=medium
 
   * patches/thread-daemon: Make JAW thread a daemon so that JVM termination 
does
diff --minimal -Nru java-atk-wrapper-0.33.3/debian/control 
java-atk-wrapper-0.33.3/debian/control
--- java-atk-wrapper-0.33.3/debian/control  2016-05-22 20:43:23.0 
+0200
+++ java-atk-wrapper-0.33.3/debian/control  2017-12-24 12:51:57.0 
+0100
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Debian Accessibility Team 
 Uploaders: Samuel Thibault 
-Build-Depends: debhelper (>= 9.20150628), pkg-config, dh-autoreconf, 
gnome-common, libatk1.0-dev (>= 2.14.0~), libatk-bridge2.0-dev (>= 2.18.1-2~), 
libatspi2.0-dev (>= 2.14.0~), libdbus-1-dev, libglib2.0-dev (>= 2.32.0~), 
libgtk2.0-dev, libgtk-3-dev, default-jdk (>= 2:1.7), java-common (>= 0.54), 
x11-utils
+Build-Depends: debhelper (>= 9.20150628), pkg-config, dh-autoreconf, 
gnome-common, libatk1.0-dev (>= 2.14.0~), libatk-bridge2.0-dev (>= 2.18.1-2~), 
libatspi2.0-dev (>= 2.14.0~), libdbus-1-dev, libglib2.0-dev (>= 2.32.0~), 
libgtk2.0-dev, libgtk-3-dev, default-jdk:native (>= 2:1.7), java-common (>= 
0.54), x11-utils
 Standards-Version: 3.9.8
 Section: java
 Homepage: http://ftp.gnome.org/pub/GNOME/sources/java-atk-wrapper/

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Gudjon I. Gudjonsson]

Hi Sven

You are right. I did compile the file in a normal environment with elyxer 
installed, sorry.
But I cannot compile the package (version 27) after I uninstall elyxer. Lyx 
fails without any 
proper error message.
The problem seems to be in the new documentation. If I copy the documentation 
from ngspice-26 to
ngspice-27, build-indep works.
ngspice-26, manual.lyx is made with lyx 2.0 and lyx format 413
ngspice-27, manual.lyx is made with lyx 2.1 and lyx format 474

Do you have any idea on how to remove this elyxer dependency from manual.lyx?

Regards
Gudjon

Bug#885061: systemd-timesyncd.service fails to start if static user is removed, but group is retained

[Martin Dickopp]

On Sat, Dec 23, 2017 at 11:35:44AM +0100, Michael Biebl wrote:
> Am 23.12.2017 um 09:26 schrieb Martin Dickopp:
> > Following the instructions in /usr/share/doc/systemd/NEWS.Debian.gz
> > 
> >   DynamicUser=yes has been enabled for systemd-journal-upload.service,
> >   systemd-journal-gatewayd.service and systemd-timesyncd.service.
> >   This means we no longer need to statically allocate a 
> > systemd-journal-upload,
> >   systemd-journal-gateway and systemd-timesync user and you can now safely
> >   remove those system users.
> > 
> > I removed the static systemd-timesync user and rebooted the system, after
> > which systemd-timesyncd.service failed to start.
> > 
> > When I removed the static systemd-timesync group as well, and rebooted
> > again, systemd-timesyncd.service worked fine.
> 
> Out of interest: which tool did you use to remove the system user?
> deluser by default will remove the group along with the user automatically.

I removed the entry manually from /etc/passwd and /etc/shadow (with vipw).

> That said, I'd be happy to provide a text which clarifies the above.
> Would ".. and you can now safely remove those system users along with
> their associated groups." be sufficient in your opinion?

Yes, this clarification would have helped me. Thanks!

Best regards,
Martin

Bug#885128: g++-8: Missing file: avx512bitalgintrin

[Sylvestre Ledru]

Package: g++-8
Version: 8-20171223-1
Severity: important

Hello,

One more time a missing file.
Maybe it is time to automate that?

 2:18.25 In file included from 
/root/firefox-gcc-last/gfx/skia/skia/src/core/../opts/SkNx_sse.h:11,
 2:18.25  from 
/root/firefox-gcc-last/gfx/skia/skia/src/core/SkNx.h:361,
 2:18.25  from 
/root/firefox-gcc-last/gfx/skia/skia/src/core/SkBitmapFilter.h:15,
 2:18.25  from 
/root/firefox-gcc-last/gfx/2d/ConvolutionFilter.cpp:9:
 2:18.25 /usr/lib/gcc/x86_64-linux-gnu/8/include/immintrin.h:87:10: fatal 
error: avx512bitalgintrin.h: No such file or directory
 2:18.25  #include 
 2:18.26   ^~
 2:18.26 compilation terminated.

Thanks,
Sylvestre

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

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

Versions of packages g++-8 depends on:
ii  gcc-88-20171223-1
ii  gcc-8-base   8-20171223-1
ii  libc62.24-17
ii  libgmp10 2:6.1.2+dfsg-1
ii  libisl15 0.18-1
ii  libmpc3  1.0.3-1+b2
ii  libmpfr4 3.1.6~rc1-1
ii  libstdc++-8-dev  8-20171223-1
ii  zlib1g   1:1.2.8.dfsg-5

g++-8 recommends no packages.

Versions of packages g++-8 suggests:
pn  g++-8-multilib
pn  gcc-8-doc 
pn  libstdc++6-8-dbg  

-- no debconf information