Bug#903880: RFS: pw/1.2-1 [ITP] -- simple command-line password manager

[Tobias Frost]

Control: -1 wontfix

Hi Dashamir,

please make sure to adress the remarks in #903815.
Just ignoring them and still going forward with an RFS is not going to
work out. I'm sorry but unless that is sorted out, I think pw is not
suitable for Debian at this point of time.
(And frankly, they way you've answered on the ITP contributes to this
impression.)

--
tobi

Bug#903882: python3-aiozmq: Incorrect URL and package name in copyright file

[Petter Reinholdtsen]

Package: python3-aiozmq
Severity: important

Just noticed, the package refered to by the python3-aiozmq copyright
file is aiopg, not aiozmq.  Cut-n-paste error?

I suspect a simple s/aiopg/aiozmq/ will solve the problem.  It will for
the source URL, as https://aiozmq.readthedocs.org/ > is
operational.
-- 
Happy hacking
Petter Reinholdtsen

Bug#903881: bind mounting a device node produces the wrong error message

[Katy Tolsen]

Package: mount
Version: 2.29.2-1+deb9

I foolishly had typed:

mount -o bind /dev/sdc1 /mnt/boot

when I was trying to do a chroot/cross-install of Debian from Debian
onto another drive, and the error only further confused the situation
because it was not the correct error. It said this:

mount: mount(2) failed: /mnt/boot: Not a directory

which it WAS a directory just created, as evident from the output of ls -l /mnt:

drwxr-xr-x 2 root root  4096 Jul 16 00:54 boot

what it seems to have MEANT was, that /dev/sdc1 is not a directory, as
I was trying to bind when a bind wasn't required for this. I am
reporting this so another user less experienced and perhaps more
confused doesn't have to bang their head off their keyboard. ;)

suggested fix is to have it output the correct error message and/or
maybe check to see if something is not a directory before saying that
it isn't so as not to further confuse a situation.

This is a standard Stretch system, stock kernel and all, amd64, I am
sure the bug is likely easily reproducible on any Debian system.

I'll leave classification of this bug up to the maintainer. Its
obviously not real serious, because as far as I know bind is only
suppose to bind one dir to another and this was incorrect usage, the
only problem is that the error was not only not helpful, but was also
incorrect and misled me to try figure out why it said a directory
wasn't a directory until it dawned on me that I was binding when no
bind was necessary. The whole point of plain language errors is to aid
in resolving the problem which this error only compounds if you don't
have the experience and knowledge to realize what is wrong when you
step back and look at what you did.

Bug#903880: RFS: pw/1.2-1 [ITP] -- simple command-line password manager

[Sergio Durigan Junior]

Control: tags -1 + moreinfo

On Sunday, July 15 2018, Dashamir Hoxha wrote:

> Dear mentors,
>
> I am looking for a sponsor for my package "pw"
>
>  * Package name: pw
>Version : 1.2-1
>Upstream Author : Dashamir Hoxha 
>  * URL : https://github.com/dashohoxha/pw
>  * License : GPL-2+
>Section : misc
>
> It builds those binary packages:
>
> pw- Simple command-line password manager.
>
> To access further information about this package, please visit the following 
> URL:
>
> https://mentors.debian.net/package/pw
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x https://mentors.debian.net/debian/pool/main/p/pw/pw_1.2-1.dsc
>
> More information about "pw" can be obtained from the man page:
>
> http://dashohoxha.github.io/pw/man/

Hello,

Thank you for your interest in Debian.

From the website (which unfortunately uses github):

  pw was written by Dashamir Hoxha (dashoho...@gmail.com). The code is
  on GitHub at https://github.com/dashohoxha/pw. pw started as a fork of
  pass (http://www.passwordstore.org/), written by Jason A. Donenfeld
  (ja...@zx2c4.com).

pass is already packaged, works perfectly (I use it myself), has an
active upstream, and doesn't use github (which IMO is a feature
nowadays).  What is the advantage of having "pw" in the archive?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#785764: non-standard XML ISO entity

[Osamu Aoki]

control: tags -1 - patch
control: severity -1 wishlist

As Ubuntu bug report said:

 I think the currently wrong value (224D) was right in 2003, but it has
changed since that date. I can follow the changes with the docbook
releases that show that it has been modified in the 4.4 release in 2005.
By the way other changes have occured in these entity declarations.
 is just an example of the inconsistencies.


This means there is a new data for 4.4 release which needs to be packaged.

I don't think ad-hoc change to old definition is more harmful.  (I may
be wrong here)

I think 2 things needs to happen:

 * package  a new data for 4.4 release
 * update dependency of affected package. (Is this SYSTEM ID issue
   mentioned in https://bugs.debian.org/383507

I am no expert on this issue.  We need people who knows this to
maintain.

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Sun, Jul 15, 2018 at 1:02 PM  wrote:

>
> Nonetheless, I don't have any opinion about pw. I use pass, and I think
> that forks are welcomed.
>

I just uploaded it: https://mentors.debian.net/package/pw
Please review and sponsor it.

Adrien
>

Bug#900216: ITA: kasumi

[Osamu Aoki]

control: retitle -1 ITA: kasumi -- Simple dictionary utility for Anthy

Hi,

I have fixed RC bug #885918, here and upload fixed package soon.
(currently, there is no testing package.  So it is urgent)

I will put this kasumi (user dictionary GUI for input method: anthy)
into Debian Input Method Team which also maintains anthy with the
upcoming upload.

Osamu

Bug#903880: RFS: pw/1.2-1 [ITP] -- simple command-line password manager

[Dashamir Hoxha]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pw
   Version : 1.2-1
   Upstream Author : Dashamir Hoxha 
 * URL : https://github.com/dashohoxha/pw
 * License : GPL-2+
   Section : misc

It builds those binary packages:

pw- Simple command-line password manager.

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/p/pw/pw_1.2-1.dsc

More information about "pw" can be obtained from the man page:

http://dashohoxha.github.io/pw/man/

Regards,
Dashamir Hoxha



signature.asc
Description: PGP signature

Bug#903879: Add openblas 0.3.1 dgesvd regression test to julia

[Lumin]

Package: julia
Version: 0.6.4-2+b1
Severity: important
Owner: !

https://github.com/JuliaLang/julia/pull/28129
This patch is for julia 0.7.X .

Maybe I should backport this test to 0.6.X .

Bug#903878: rhash: unsatisfiable recommends: libssl1.0.0 (>= 1.0.0)

[Cyril Brulebois]

Package: rhash
Version: 1.3.3-1+b2
Severity: important

Hi,

Your package seems able to dlopen various versions of libcrypto, and it
has a Recommends accordingly.

In stretch, librhash/plug_openssl.c has:
| void* handle = dlopen("libcrypto.so", RTLD_NOW);
| if (!handle) handle = dlopen("libcrypto.so.1.0.0", RTLD_NOW); /* 
hotfix */^M
| if (!handle) handle = dlopen("libcrypto.so.0.9.8", RTLD_NOW);

with:
| Recommends: libssl1.0.0 (>= 1.0.0)


In git:
| void* handle = dlopen("libcrypto.so", RTLD_NOW);
| if (!handle) handle = dlopen("libcrypto.so.1.1", RTLD_NOW);
| if (!handle) handle = dlopen("libcrypto.so.1.0.2", RTLD_NOW);
| if (!handle) handle = dlopen("libcrypto.so.1.0.0", RTLD_NOW);
| if (!handle) handle = dlopen("libcrypto.so.0.9.8", RTLD_NOW);

with:
| Recommends: libssl1.1 | libssl1.0.2 | libssl1.0.0


The git version seems fine as the first two are available, even if the
last one isn't. The stretch version doesn't seem reasonable though,
since it only knows about libssl1.0.0, which isn't available in stretch
(it was last seen in jessie).

This makes tools like aptitude report issues due to unmet recommends.
Not entirely sure it's worth fixing though (is adding another dlopen
call with a different filename and adding an alternative recommends
sufficient?). You might want to check with the release team.


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

Bug#901436: Some values in /etc/default/zfs ignored

[Elliott Mitchell]

I'm running into this as well.  Does appear that *some* of the values in
/etc/default/zfs are honored under *some* conditions.

Of note it looks like ZFS_MOUNT, ZFS_POOL_EXCEPTIONS, and
ZPOOL_IMPORT_ALL_VISIBLE WILL be honored if you're avoiding SystemD
(using startpar or other which still uses the initscripts, +1 for Devuan
here).

ZFS_POOL_IMPORT though appears to be ignored under ALL circumstances.
Instead the data in /etc/zfs/zpool.cache is being used.  I'm unsure of
the proper way to modify /etc/zfs/zpool.cache, but was able to get things
to work by removing /etc/zfs/zpool.cache and then doing a
`zpool import `.  This is a bit more interesting if / is normally
read-only.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#903877: Credentials located in gnome-keyring can be extracted easily.

[Seong-Joong Kim]

Package: gnome-keyring
Version: 3.20.0-3
Severity: normal

Dear Maintainer,

I figure out that login credentials, located in gnome-keyring, can be easily
extracted.

Linux based on Gnome basically uses ‘gnome-keyring’ as their backend to store
login credentials in a secure manner. Specifically, google-chrome browser,
network-manager and gnome-online-accounts use this as a backend solution to
store login credentials.

To use this, authentication is performed together with gnome-keyring as part of
‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut
down or logged out. In this state, a simple program that uses ‘Secret Service
API’ call and their ‘D-Bus’ interface can easily retrieve login credentials
from those gnome-keyring without any privilege escalation, listening into the X
events going to another window, or installation an application on target
computer.
(please check PoC source https://github.com/sungjungk/keyring_crack and video
https://youtu.be/Do4E9ZQaPck)

The issue is different from the content shown on the Ubuntu Security FAQ and
GnomeKeyring Wiki [1][2]. It was even said that “PAM session is closed via the
screensaver, all keyrings are locked, and the ‘login’ keyring is unlocked upon
successful authentication to the screensaver”. After trying to crack the
keyring, it was far from what they really thought. It is no different than
plain text file for login credentials somewhere on disk.

To deal with, the root cause of the problem is that ‘Secret Service API’ on
anyone can be easily accessed on DBus API. If access control is enabled, only
well-known? or authorized processes, such as google-chrome, network-manager,
and gnome-online-accounts, will be able to access the login credentials.

DBus originally provides capability that is essential to access control of DBus
API by defining security policy as a form of *.conf file. Currently, various
services based on DBus interface are employing above security policy feature to
perform access control. For example, login/system related functions is
controlled from ‘login1’ and its security policy is described in
“org.freedesktop.login1.conf”. (see
https://github.com/systemd/systemd/blob/master/src/core/org.freedesktop.systemd1.conf)

Likewise, why don’t we try adopting the access control of secret service API
into gnome-keyring environment?

Due to the fact that a process with root privilege can access “.conf” file, an
approved program may only update the target file during installation process

Here is really simple ‘org.freedesktop.secrets.conf’ example.


 
http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>





















Many Thanks!!

[1] https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact

[2] https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy



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

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

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.10.18-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2+b1
ii  gcr   3.20.0-5.1
ii  libc6 2.24-11+deb9u1
ii  libcap-ng00.7.7-3+b1
ii  libcap2-bin   1:2.25-1
ii  libgck-1-03.20.0-5.1
ii  libgcr-base-3-1   3.20.0-5.1
ii  libgcrypt20   1.7.6-2+deb9u3
ii  libglib2.0-0  2.50.3-2
ii  p11-kit   0.23.3-2
ii  pinentry-gnome3   1.0.0-2

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.20.0-3

gnome-keyring suggests no packages.

-- no debconf information

Bug#903703: emacs-goodies-el: should we keep rfcview.el in Debian?

[Nicholas D Steeves]

Hi Dave,

On Mon, Jul 16, 2018 at 09:03:07AM +0900, David Bremner wrote:
> 
> user debian-emac...@lists.debian.org
> retitle 903703 replace rfcview.el with elpa-rfcview
> usertag 903703 elpafy
> quit
> 
> Dave Love  writes:
> 
> > Do you mean "rfcview" (as it looks from apt show), rather than
> > "rfc-view" (which is probably something else)?  If so, I use it
> > occasionally, and it works to that extent.
> 
> Correct, sorry for the typo. And glad to hear it is still in active
> use. It sounds like we should repackage rfcview as an independent
> package.  By the way, there was a request in Debian for sb-rfcview.el
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648703
> 
> Is that something you'd be interested in maintaining? Perhaps it might
> make sense to bundle those together in the same release / VCS repo.
> 
> >
> > Where are the bug reports -- in debbugs?
> 
> Yes, you can find them here
> 
>  
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3Arfcview;package=emacs-goodies-el
> 
> There is nothing very urgent there. I only mentioned the bugs because
> the lack of response made me wonder about the state of the package.

I took the liberty to remove rfcview.el from goodies, marked it as
elpafied, and added a dep elpa-rfcview that can be uncommented
whenever this package is elpafied.  If it wasn't merged upstream it's
likely you'll want to retain (and rename) 50_rfcview.diff, so for your
convenience here is a link to the most recent surviving copy of it:
  
https://salsa.debian.org/emacsen-team/emacs-goodies-el/raw/21d3accaca567404a130c58a51f963fe7283692b/debian/patches/50_rfcview.diff


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#903876: File extension 'xlsx' does not match the detected MIME type of the file (application/zip)

[Chad Seys]

Package: mediawiki
Version: 1:1.27.4-1~deb9u1
Severity: normal

Hi!
  The line
$wgMimeTypeFile = '/etc/mime.types';
  in LocalSettings.php causes mediawiki to refuse to upload 'xlsx' files with 
the error
"File extension 'xlsx' does not match the detected MIME type of the file 
(application/zip)".

  'xlsx' and 'zip' appear in the permitted file types list.

  Commenting out this line allows successful upload of xlsx.

Thanks for packaging mediawiki for Debian!
Chad.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 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 mediawiki depends on:
ii  apache2 [httpd] 2.4.25-3+deb9u4
ii  mediawiki-classes   1:1.27.4-1~deb9u1
ii  mime-support3.60
ii  php 1:7.0+49
ii  php-common  1:49
ii  php-mbstring1:7.0+49
ii  php-mysql   1:7.0+49
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.30-0+deb9u1
ii  php7.0-mbstring [php-mbstring]  7.0.30-0+deb9u1
ii  php7.0-mysql [php-mysqlnd]  7.0.30-0+deb9u1
ii  php7.0-xml [php-xml]7.0.30-0+deb9u1

Versions of packages mediawiki recommends:
ii  default-mysql-server1.0.2
ii  mariadb-server-10.1 [virtual-mysql-server]  10.1.26-0+deb9u1
ii  php-cli 1:7.0+49
ii  php-curl1:7.0+49
ii  php-intl1:7.0+49
ii  php-wikidiff2   1.4.1-1
ii  php7.0-cli [php-cli]7.0.30-0+deb9u1
ii  php7.0-curl [php-curl]  7.0.30-0+deb9u1
ii  php7.0-intl [php-intl]  7.0.30-0+deb9u1
ii  python  2.7.13-2

Versions of packages mediawiki suggests:
pn  clamav   
pn  hhvm 
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u4
pn  memcached
pn  php-apcu 

-- debconf information:
  mediawiki/webserver: apache2

Bug#903869: steam: Some games not open because of locales

[Michael Gilbert]

control: tag -1 - moreinfo
control: tag -1 + upstream
control: severity -1 minor
control: retitle -1 games fail to start when they don't support the
locale in use

On Sun, Jul 15, 2018 at 9:53 PM, Vinícius Couto wrote:
> The problem was that some games is mandatory the en_US.UTF-8 locale needs to
> be enabled too (if this locale is not the default of the system).

Debian cannot do anything about this.  Only Valve and their game
developers can, so please submit a bug directly to them.

> If you have a better way to send Linux bug reports to the mantainers, i will
> be glad to know.

Valve uses github for bug reports [0].  Once you've submitted a report
there, please link back to it here.

Best wishes,
Mike

[0] https://github.com/ValveSoftware/steam-for-linux/issues

Bug#783986: ifupdown ignoring more than up lines for static ipv6

[Elliott Mitchell]

I'm seeing a behavior which I suspect is another manifestation of bug
#783986.  ifupdown also ignores mtu lines for inet6 stanzas:

iface eth0 inet6 manual
mtu 9000

Results in eth0 having a MTU of 1500, not the specified 9000.  I'm
suspecting ifupdown was written to ignore certain portions of inet6
stanzas on the basis they should duplicate inet stanzas.  This is okay
until there is no inet stanza.

Really looking at the present situation I wonder whether there is still
any real need for "inet6" stanzas.  For address and gateway you can
distinguish based on whether periods or colons are used, as long as
netmask is specified via /.  Most of the remainder is simply
duplicated between "inet" and "inet6".


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#903862: FTBFS: override_dh_auto_test exits with exit 2

[Vincent Lefevre]

Control: retitle -1 FTBFS: override_dh_auto_test fails due to test-real-data 
when $SHELL is set to /bin/zsh
Control: severity -1 minor
Control: tags -1 - moreinfo unreproducible

I could check that unsetting SHELL before building avoids the failure.

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

Bug#752993: automake: configure does not parse variables to make foo.Po files

[Paul Hardy]

As a follow-up to my earlier "fixed-upstream" tag based on the
upstream maintainer's belief, I tested my package with automake 1.16.1
(the latest upstream version).  It did fix this bug that automake 1.15
manifested in my case.

I was able to get around the bug in automake 1.15, so it does not
affect me at this moment.  I had to re-do how I implemented "make
check" targets to circumvent it (long story that would involve poring
over generated Makefiles).  But I it would be nice if automake 1.16.x
made it into buster--the bug was quite a stumbling block for me when I
ran into it.

Thanks,


Paul Hardy

Bug#579385: #579385 Completed?

[Elliott Mitchell]

#579385 looks suspiciously complete.  I'm actually making use of this
elsewhere so I'm pretty sure this does in fact work now.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#903873: unattended-upgrades: possible regression: all packages are being kept back

[Paul Wise]

Package: unattended-upgrades
Version: 1.4
Severity: important
Control: clone -1 -2 -3
Control: retitle -2 unattended-upgrades: explain reasons why packages with 
upgradable origin are kept back
Control: severity -2 wishlist
Control: retitle -3 unattended-upgrades: include packages kept back in the log 
file
Control: severity -3 wishlist

My recent unattended-upgrades reports have looked like the following.
There is no reason for any packages to be kept back on my system and
the ones that unattended-upgrades is keeping back are not held and
aren't going to install any new packages so I cannot see why they are
being held back by unattended-upgrades. I think one of the recent
updates to unattended-upgrades may have broken it.

It would also be useful for unattended-upgrades to include the reason
why packages were held back in the report and log file.

It would also be useful for unattended-upgrades to write the list of
held back packages to the log file.

   Unattended upgrade result: All upgrades installed 

   Packages that were upgraded:

   Packages with upgradable origin but kept back:
binutils-mingw-w64 binutils-mingw-w64-i686 binutils-mingw-w64-x86-64 
comerr-dev e2fsprogs gir1.2-gucharmap-2.90 gir1.2-mutter-2 
gnome-shell gnome-shell-common gnome-shell-dbgsym gucharmap 
html2text libcom-err2 libcom-err2-dbgsym libext2fs2 
libgucharmap-2-90-7 libgucharmap-2-90-7-dbgsym libmozjs-52-0 
libmozjs-52-0-dbgsym libmutter-2-0 libmutter-2-0-dbgsym libpng-dev 
libpng-tools libpng16-16 libpng16-16-dbgsym libraw16 libss2 
libutf8proc2 lynx lynx-common minetest-mod-player-3d-armor mutter 
mutter-common mutter-dbgsym python3-proselint 



   Unattended-upgrades log:
   Initial blacklisted packages: 
   Initial whitelisted packages: 
   Starting unattended upgrades script
   Allowed origins are: origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security, origin=Debian
   Packages that will be upgraded: 

$ sudo grep 06:06 /var/log/unattended-upgrades/unattended-upgrades.log
2018-07-16 06:06:38,011 INFO Initial blacklisted packages: 
2018-07-16 06:06:38,027 INFO Initial whitelisted packages: 
2018-07-16 06:06:38,027 INFO Starting unattended upgrades script
2018-07-16 06:06:38,027 INFO Allowed origins are: 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security, origin=Debian
2018-07-16 06:06:51,758 INFO Packages that will be upgraded: 

$ sudo apt upgrade 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  binutils-mingw-w64 binutils-mingw-w64-i686 binutils-mingw-w64-x86-64
  comerr-dev e2fsprogs gir1.2-gucharmap-2.90 gir1.2-mutter-2 gnome-shell
  gnome-shell-common gnome-shell-dbgsym gucharmap html2text libcom-err2
  libcom-err2-dbgsym libext2fs2 libgucharmap-2-90-7 libgucharmap-2-90-7-dbgsym
  libmozjs-52-0 libmozjs-52-0-dbgsym libmutter-2-0 libmutter-2-0-dbgsym
  libpng-dev libpng-tools libpng16-16 libpng16-16-dbgsym libraw16 libss2
  libutf8proc2 lynx lynx-common minetest-mod-player-3d-armor mutter
  mutter-common mutter-dbgsym python3-proselint
35 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/91.3 MB of archives.
After this operation, 154 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

$ sudo apt dist-upgrade 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  binutils-mingw-w64 binutils-mingw-w64-i686 binutils-mingw-w64-x86-64
  comerr-dev e2fsprogs gir1.2-gucharmap-2.90 gir1.2-mutter-2 gnome-shell
  gnome-shell-common gnome-shell-dbgsym gucharmap html2text libcom-err2
  libcom-err2-dbgsym libext2fs2 libgucharmap-2-90-7 libgucharmap-2-90-7-dbgsym
  libmozjs-52-0 libmozjs-52-0-dbgsym libmutter-2-0 libmutter-2-0-dbgsym
  libpng-dev libpng-tools libpng16-16 libpng16-16-dbgsym libraw16 libss2
  libutf8proc2 lynx lynx-common minetest-mod-player-3d-armor mutter
  mutter-common mutter-dbgsym python3-proselint
35 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/91.3 MB of archives.
After this operation, 154 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

$ apt policy mutter
mutter:
  Installed: 3.28.2-2
  Candidate: 3.28.2-3
  Version table:
 3.28.2-3 900
900 https://deb.debian.org/debian testing/main amd64 Packages
800 https://deb.debian.org/debian unstable/main amd64 Packages
 *** 3.28.2-2 100
100 /var/lib/dpkg/status

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

Kernel: Linux 

Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

[Hector Oron]

Hello,

2018-07-16 2:13 GMT+02:00 Hector Oron :
> Hello Svante,
>
>   I have pushed GDB 8.1, but apparently it does not yet have support for Hurd:
>   
> https://buildd.debian.org/status/fetch.php?pkg=gdb=hurd-i386=8.1-1=1531671238=0

I tried applied patchset on exodar (hurd porterbox) but it was also
failing to build.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.



-- Would you like to make a donation towards the upcoming Debian conference?
   Brochure: 
https://media.debconf.org/dc18/fundraising/debconf18_sponsorship_brochure_en.pdf

   ** https://debconf18.debconf.org/sponsors/become-a-sponsor/ **

Bug#860052: logcheck MIME encoding

[brian m. carlson]

Could we get the patch in this bug report applied?  At least once a week
I run into problems with bounced messages due to this bug.

There are at least two independent pull requests on the salsa.debian.org
that implement variants of this patch, and I'm happy to revise mine at
any time to improve it if necessary.

If there's anything else I can do to help get this bug fixed, please let
me know.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#903872: sponsorship-requests: cavestory-nx/1.0.0-1 [ITP] -- Nostalgic side action adventure game

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "cavestory-nx"

 * Package name: cavestory-nx
   Version : 1.0.0-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/cavestory-nx
 * License : BSD-2-Clause
   Section : non-free/games

  It builds those binary packages:

  cavestory-nx - Nostalgic side action adventure game
  cavestory-nx-data - Nostalgic side action adventure game (data files)

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

  https://mentors.debian.net/package/cavestory-nx

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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/c/cavestory-nx/cavestory-nx_1.0.0-1.dsc

  More information about Cave Story NX can be obtained from 
https://gitlab.com/coringao/cavestory-nx.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

[Hector Oron]

Hello Svante,

  I have pushed GDB 8.1, but apparently it does not yet have support for Hurd:
  
https://buildd.debian.org/status/fetch.php?pkg=gdb=hurd-i386=8.1-1=1531671238=0

Regards

On Mon, Jan 08, 2018 at 12:10:58AM +0100, Svante Signell wrote:
> Ping
> 
> On Wed, 2017-12-27 at 23:36 +0100, Svante Signell wrote:
> > On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote:
> > > Hello Svante,
> > > 
> > > On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell
> > >  wrote:
> > > > Hello,
> > > > 
> > > > These patches was submitted to Debian November 13 2017. Nothing has
> > > > happened so far, so maybe upstream would be interested to consider
> > > > the
> > > > patches for next release.
> > > 
> > > I would like to have them applied in Debian package for next release,
> > > however it is taking more time than I thought, then I am going on
> > > vacations. If you are able to upload to Debian, feel free to NMU the
> > > package, otherwise, I'll try to have a look in a couple weeks.
> > 
> > Hi again,
> > 
> > Unfortunately I'm not authorized to NMU that package. However, the
> > reason for submitting the patches upstream is that they should be
> > applied there. In the meanwhile we could create a Debian package of
> > 8.0.1 (or later). If you don't have time maybe Samuel could help out
> > here?
> > 
> > Thanks for your reply anyway!

-- 


signature.asc
Description: PGP signature

Bug#903869: steam: Some games not open because of locales

[Michael Gilbert]

control: tag -1 moreinfo

Vinicius Couto wrote:
> I tried to open some games, but automatcaly closes. No warning or errors 
> appeared.
> After some different ways trying to open, i found that the Debian only load 
> the language locale that the installation ask (only pt_BR.UTF-8, in my case).
> I needed to include the en_US.UTF-8 locale to run properly the games.

The script shipped with the package (/usr/games/steam) will
automatically set the locale to C if a locale is not set.  However, it
won't override one that is already set.  Do we want the package to
override the user like that?

Does Valve have a list of supported languages that we could use to
decide whether or not to do so?

Best wishes,
Mike

Bug#903862: FTBFS: override_dh_auto_test exits with exit 2

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.gnucash.org/show_bug.cgi?id=796763

I've reported the bug upstream, since I can reproduce it from git.

On 2018-07-16 09:53:13 +1000, Dmitry Smirnov wrote:
> On Monday, 16 July 2018 9:03:59 AM AEST Vincent Lefevre wrote:
> > Start  22: test-real-data
> >  22/118 Test  #22: test-real-data ...***Failed 
> >   0.01 sec
> 
> There is not enough information in this bug report to have a slightest clue 
> about the problem. Could you please at least quote a relevant part of log?
> 
> Test failure is followed by cat of "LastTest.log" that should have some 
> information about the failure.

This is not the case, and I didn't know this file.

Testing/Temporary/LastTest.log contains:

22/116 Testing: test-real-data
22/116 Test: test-real-data
Command: "/usr/bin/cmake" "-E" "env" "/bin/zsh" 
"/home/vinc17/software/gnucash/libgnucash/backend/xml/test/test-real-data.sh"
Directory: /home/vinc17/tmp/gnucash-build/libgnucash/backend/xml/test
"test-real-data" start time: Jul 16 01:44 CEST
Output:
--
/home/vinc17/software/gnucash/libgnucash/backend/xml/test/test-real-data.sh:6: 
= not found

Test time =   0.02 sec
--
Test Failed.
"test-real-data" end time: Jul 16 01:44 CEST
"test-real-data" time elapsed: 00:00:00
--

The error corresponds to:

if [ "x$TEST_PATH" == "x" ] ; then

I'm wondering whether the test is run with zsh (my shell), which
yields such an error (since [ is not a zsh builtin), instead of
bash.

Well, this is confirmed by:

Command: "/usr/bin/cmake" "-E" "env" "/bin/zsh" 
"/home/vinc17/software/gnucash/libgnucash/backend/xml/test/test-real-data.sh"

> I can not reproduce the problem in clean build environment.

The build may be affected either by the user shell or by the SHELL
environment variable (both set to /bin/zsh in my case).

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

Bug#902700: Bug#902731: RFS: pulseeffects/4.1.7-3 [ITP]

[Михаил Новоселов]

Updated to PulseEffects 4.1.7. It's source code now has a gstreamer 
plugin, I separated it into package


gstreamer1.0-convolver-pulseeffects

to allow other applications to use it without requiring pulseeffects.

dget -x 
https://mentors.debian.net/debian/pool/main/p/pulseeffects/pulseeffects_4.1.7-3.dsc 


git init
git clone ./pulseeffects_4.1.7-3.git master
cd master
sudo mk-build-deps --install debian/control
dpkg-buildpackag
debian/rules clean

Bug#903703: emacs-goodies-el: should we keep rfcview.el in Debian?

[David Bremner]

user debian-emac...@lists.debian.org
retitle 903703 replace rfcview.el with elpa-rfcview
usertag 903703 elpafy
quit

Dave Love  writes:

> Do you mean "rfcview" (as it looks from apt show), rather than
> "rfc-view" (which is probably something else)?  If so, I use it
> occasionally, and it works to that extent.

Correct, sorry for the typo. And glad to hear it is still in active
use. It sounds like we should repackage rfcview as an independent
package.  By the way, there was a request in Debian for sb-rfcview.el

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

Is that something you'd be interested in maintaining? Perhaps it might
make sense to bundle those together in the same release / VCS repo.

>
> Where are the bug reports -- in debbugs?

Yes, you can find them here

 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3Arfcview;package=emacs-goodies-el

There is nothing very urgent there. I only mentioned the bugs because
the lack of response made me wonder about the state of the package.

Bug#903871: libsane: sane-genesys backend segfaults

[Alison Chaiken]

Package: libsane
Version: 1.0.25-4.1
Severity: important

Dear Maintainer,

scanimage and xsane cannot operate the Xerox Travel Scanner 100.
Sometimes scanimage segfaults, and sometimes there is a USB descriptor
read error, and sometimes the motor runs and an output file is
produced, but the illuminator is off and the image file is all black.

This is what CLI show with "device descriptor read/64, error -110"

$ sudo scanimage > /tmp/image.png
scanimage: sane_start: Invalid argument

Here is what I got with the segfault.   I just installed
systemd-coredump, so I don't have a corefile.
$ sudo scanimage > /tmp/image.png
Segmentation fault

Output of 'dmesg -w':
[ 2525.483714] usb 1-1: new high-speed USB device number 27 using xhci_hcd
[ 2525.629443] usb 1-1: New USB device found, idVendor=04a7, idProduct=04ac
[ 2525.629448] usb 1-1: New USB device strings: Mfr=10, Product=11, 
SerialNumber=12
[ 2525.629450] usb 1-1: Product: Travel Scanner 100
[ 2525.629452] usb 1-1: Manufacturer: Xerox
[ 2525.629453] usb 1-1: SerialNumber: 9480003000494
[ 2551.750497] usb 1-1: reset high-speed USB device number 27 using xhci_hcd
[ 2618.345107] usb 1-1: USB disconnect, device number 27
[ 2618.644696] usb 1-1: new high-speed USB device number 28 using xhci_hcd
[ 2623.805185] usb 1-1: device descriptor read/64, error -110
[ 2639.422719] usb 1-1: device descriptor read/64, error -110
[ 2791.229314] usb 1-1: new high-speed USB device number 30 using xhci_hcd
[ 2791.375142] usb 1-1: New USB device found, idVendor=04a7, idProduct=04ac
[ 2791.375149] usb 1-1: New USB device strings: Mfr=10, Product=11, 
SerialNumber=12
[ 2791.375152] usb 1-1: Product: Travel Scanner 100
[ 2791.375154] usb 1-1: Manufacturer: Xerox
[ 2791.375157] usb 1-1: SerialNumber: 9480003000494
[ 2824.077927] scanimage[4591]: segfault at 0 ip 7f76d3619ffb sp 
7ffd7795df40 error 4 in libsane-genesys.so.1.0.25[7f76d3607000+72000]
[ 3236.935758] usb 1-1: USB disconnect, device number 30
[ 3237.236292] usb 1-1: new high-speed USB device number 31 using xhci_hcd
[ 3237.382036] usb 1-1: New USB device found, idVendor=04a7, idProduct=04ac
[ 3237.382042] usb 1-1: New USB device strings: Mfr=10, Product=11, 
SerialNumber=12
[ 3237.382044] usb 1-1: Product: Travel Scanner 100
[ 3237.382046] usb 1-1: Manufacturer: Xerox
[ 3237.382047] usb 1-1: SerialNumber: 9480003000494
[ 3244.504853] usb 1-1: USB disconnect, device number 31
[ 3246.765217] usb 1-1: new high-speed USB device number 32 using xhci_hcd
[ 3246.911142] usb 1-1: New USB device found, idVendor=04a7, idProduct=04ac
[ 3246.911150] usb 1-1: New USB device strings: Mfr=10, Product=11, 
SerialNumber=12
[ 3246.911154] usb 1-1: Product: Travel Scanner 100
[ 3246.911157] usb 1-1: Manufacturer: Xerox
[ 3246.911160] usb 1-1: SerialNumber: 9480003000494
[ 3282.203292] usb 1-1: USB disconnect, device number 32
[ 3282.500703] usb 1-1: new high-speed USB device number 33 using xhci_hcd
[ 3287.677196] usb 1-1: device descriptor read/64, error -110
[ 3303.294696] usb 1-1: device descriptor read/64, error -110


$ scanimage -L 
device `genesys:libusb:001:017' is a Xerox Travelscanner 100 flatbed scanner

$ lsusb
[ . . . ]
Bus 001 Device 017: ID 04a7:04ac Visioneer Xerox Travel Scanner 100

$ groups alison
alison : alison dialout cdrom floppy audio dip video plugdev systemd-journal 
netdev bluetooth lpadmin scanner

$ sudo getfacl /dev/bus/usb/001/017
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/001/017
# owner: root
# group: root
user::rw-
user:alison:rw-
group::rw-
group:scanner:rw-
mask::rw-
other::r--

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

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

Versions of packages libsane depends on:
ii  acl2.2.52-3+b1
ii  adduser3.117
ii  libavahi-client3   0.7-4
ii  libavahi-common3   0.7-4
ii  libc6  2.27-3
ii  libgphoto2-6   2.5.18-2
ii  libgphoto2-port12  2.5.18-2
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libsane-common 1.0.25-4.1
ii  libtiff5   4.0.9-6
ii  libusb-1.0-0   2:1.0.22-2
ii  udev   239-5

Versions of packages libsane recommends:
ii  libsane-extras  1.0.22.6
ii  sane-utils  1.0.25-4.1

Versions of packages libsane suggests:
ii  avahi-daemon  0.7-4
ii  hplip 3.17.10+repack0-5

-- no debconf information

Bug#903862: FTBFS: override_dh_auto_test exits with exit 2

[Dmitry Smirnov]

On Monday, 16 July 2018 9:03:59 AM AEST Vincent Lefevre wrote:
> Start  22: test-real-data
>  22/118 Test  #22: test-real-data ...***Failed 
>   0.01 sec

There is not enough information in this bug report to have a slightest clue 
about the problem. Could you please at least quote a relevant part of log?

Test failure is followed by cat of "LastTest.log" that should have some 
information about the failure.

I can not reproduce the problem in clean build environment.

-- 
Best wishes,
 Dmitry Smirnov.

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#903836: pcmanfm-qt: depends on libfm4 which pulls in GTK+ libraries

[Alf Gaida]

Maybe the long version is slightly more understandable:
libfm-qt was in the beginning a wrapper around libfm. With the current
release only a minor part of the libfm functionality is used, over time
the dependencies to libfm was reduced and replaced by native c++
implementations. Second dependency from "old" LXDE is menucached.

With the 0.14 release series libfm-qt will be a pure c++ implementation
that uses glib2 and Qt. The old dependencies to libfm are removed.
Unfortunately this doesn't help much right now regarding libfm -
pcmanfm-qt will still depend on menu-cached, menu-cached depend on libfm
- so, bingo. But that isn't so bad as it sounds at a first view - libfm
is small, menu-cached is small, our devs like glib (i can understand
that) - so pcmanfm-qt combines the best things of both worlds. And
menu-cached will only be loaded as long a user use the pcmanfm-qt
application menu. This is the last part we use from LXDE directly.

If one want to get rid of pcmanfm-qt - why not, just use some other Qt
based filemanager, dolphin comes to mind. Hmm, wait, i guess that would
not be a really lightweight replacement.

To sum it up - libfm-qt and pcman-qt will not migrate away from glib2,
dependencies to menu-cached and lifm will hopefully disappear within the
next year.

Bug#903870: steam: sse2 is now required

[Michael Gilbert]

package: steam
severity: wishlist
forwarded: https://support.steampowered.com/kb_article.php?ref=4090-RTKZ-4347

It would be useful to detect and tell the user that their hardware is
not supported because of this.

Best wishes,
Mike

Bug#903869: steam: Some games not open because of locales

[Vinicius Couto]

Package: steam
Version: 1.0.0.54-5
Severity: normal

Dear Maintainer,

I tried to open some games, but automatcaly closes. No warning or errors 
appeared.
After some different ways trying to open, i found that the Debian only load the 
language locale that the installation ask (only pt_BR.UTF-8, in my case).
I needed to include the en_US.UTF-8 locale to run properly the games.
I suggest that the steam package or client warn the needed locale.


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

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

Versions of packages steam depends on:
ii  debconf [debconf-2.0]  1.5.67
ii  libc6  2.27-4
ii  libgl1-mesa-dri18.1.4-1
ii  libgl1-mesa-glx18.1.4-1
ii  libgpg-error0  1.32-1
ii  libstdc++6 8.1.0-10
ii  libudev1   239-5
ii  libx11-6   2:1.6.5-1
ii  libxinerama1   2:1.1.3-1+b3
ii  xz-utils   5.2.2-1.3

Versions of packages steam recommends:
ii  fonts-liberation  1:1.07.4-7
ii  gnome-terminal [x-terminal-emulator]  3.28.2-1
ii  libxss1   1:1.2.2-1+b2
ii  nvidia-driver-libs-i386   390.67-2
ii  xterm [x-terminal-emulator]   333-1
ii  zenity3.28.1-1

Versions of packages steam suggests:
pn  steam-devices  

-- debconf information:
* steam/license:
  steam/purge:
* steam/question: I AGREE

Bug#903837: [Pkg-utopia-maintainers] Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

[Michael Biebl]

Am 16.07.2018 um 00:31 schrieb Alex Dănilă:
> Hi,
> 
> I attached journalctl output for starting Amarok, it generaly repeats
> the following:
> 
> Jul 16 01:07:45 debian systemd[1]: Starting Daemon for power management...
> Jul 16 01:07:45 debian upowerd[15176]: /usr/lib/upower/upowerd: error
> while loading shared libraries: libffi.so.6: cannot enable executable
> stack as shared object requires: Operation not permitted
> Jul 16 01:07:45 debian systemd[1]: upower.service: Main process exited,
> code=exited, status=127/n/a
> Jul 16 01:07:45 debian systemd[1]: upower.service: Failed with result
> 'exit-code'.
> Jul 16 01:07:45 debian systemd[1]: Failed to start Daemon for power
> management.
> 
> Related: the power management applet currently says „no battery
> available” although this is a laptop.

This seems like an unrelated issue.
You have an outdated version of libffi6 installed from experimental.
Downgrade that to the version from sid and upower should work again.

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


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



signature.asc
Description: OpenPGP digital signature

Bug#900657: steam: Screen animations freezes the screen

[Michael Gilbert]

control: tag -1 moreinfo, unreproducible
control: severity -1 normal

I am not able to reproduce this, could you provide more info? For
example, which video driver do you use, is it the amd or nvidia
proprietary driver?

Also, I see that you have apparmor enabled.  That could be the cause,
can you try to see what happens when if it is disabled?

Best wishes,
Mike

Bug#902633: ITA: php-elisp -- php mode for emacs

[Nicholas D Steeves]

Hi Ola,

On Fri, Jul 06, 2018 at 09:44:19AM +0200, Ola Lundqvist wrote:
>Thank you! Let me know when/if you need any help.
> 
>Sent from a phone
>Den fre 6 juli 2018 02:57Nicholas D Steeves  skrev:
> 

Are you able to respond to this issue?  I ran into it while updating
the long description's definition of this package's capabilities.

"Clarify a point in README.md wrt PSR-5 status and PSR-7 status"
https://github.com/ejmr/php-mode/issues/473

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#903862: FTBFS: override_dh_auto_test exits with exit 2

[Vincent Lefevre]

It is the following test that fails:

Start  22: test-real-data
 22/118 Test  #22: test-real-data ...***Failed
0.01 sec

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

Bug#903868: heat: FTBFS in buster/sid (dh_installman: Cannot find "doc/build/man/heat-api.1")

[Santiago Vila]

Package: src:heat
Version: 1:10.0.0-3
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python3,sphinxdoc,systemd
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

writing output... [ 92%] template_guide/hot_guide
writing output... [ 93%] template_guide/hot_spec
writing output... [ 94%] template_guide/index
writing output... [ 95%] template_guide/openstack
writing output... [ 96%] template_guide/software_deployment
writing output... [ 97%] template_guide/unsupported
writing output... [ 98%] templates/cfn/WordPress_Single_Instance
writing output... [ 99%] templates/hot/hello_world
writing output... [100%] templates/index

/<>/doc/source/admin/auth-model.rst:74: WARNING: unknown document: 
identity-management
WARNING: Cannot get gitsha from git repository.
/<>/doc/source/admin/stack-domain-users.rst:120: WARNING: unknown 
document: identity-management
/<>/doc/source/template_guide/environment.rst:55: WARNING: unknown 
option: -e
/<>/doc/source/template_guide/environment.rst:58: WARNING: unknown 
option: --parameter
/<>/doc/source/template_guide/environment.rst:62: WARNING: unknown 
option: --parameter
generating indices... genindex
writing additional pages... search
copying static files... done
copying extra files... done
dumping search index in English (code: en) ... done
dumping object inventory... done
build succeeded, 59 warnings.

The HTML pages are in debian/heat-doc/usr/share/doc/heat-doc/html.
dh_sphinxdoc
dh_sphinxdoc: ignoring unknown JavaScript code: 
debian/heat-doc/usr/share/doc/heat-doc/html/_static/js/bootstrap.min.js
dh_sphinxdoc: ignoring unknown JavaScript code: 
debian/heat-doc/usr/share/doc/heat-doc/html/_static/js/docs.js
dh_sphinxdoc: ignoring unknown JavaScript code: 
debian/heat-doc/usr/share/doc/heat-doc/html/_static/js/navigation.js
dh_sphinxdoc: ignoring unknown JavaScript code: 
debian/heat-doc/usr/share/doc/heat-doc/html/_static/js/webui-popover.js
make[1]: Leaving directory '/<>'
   debian/rules override_dh_installchangelogs
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
if [ -e /<>/debian/CHANGELOG ] ; then \
dh_installchangelogs /<>/debian/CHANGELOG ; \
else \
dh_installchangelogs ; \
fi
make[1]: Leaving directory '/<>'
   dh_installman -i -O--buildsystem=python_distutils
dh_installman: Cannot find (any matches for) "doc/build/man/heat-api.1" (tried 
in .)

dh_installman: Aborting due to earlier error
debian/rules:6: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made with "dpkg-buildpackage -A" in my autobuilder.
Most probably, it also fails here in reproducible builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/heat.html

[ Note: There has been a recent change in debhelper behaviour, the current
  behaviour is the intended one. See Bug #903133 for details ].

Thanks.

Bug#903867: cod-tools: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:cod-tools
Version: 2.2+dfsg-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3 --no-parallel
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>/cod-tools-2.2+dfsg'
Makefile:138: .diff.depend: No such file or directory
tools/mkperldepend scripts/cif-to-utf8 > scripts/.cif-to-utf8.d
tools/mkperldepend scripts/cif2cod > scripts/.cif2cod.d
tools/mkperldepend scripts/cif2csv > scripts/.cif2csv.d
tools/mkperldepend scripts/cif2json > scripts/.cif2json.d
tools/mkperldepend scripts/cif2rdf > scripts/.cif2rdf.d

[... snipped ...]

pycodcif.c:322:43: warning: passing argument 3 of 'PyDict_SetItemString' makes 
pointer from integer without a cast [-Wint-conversion]
 PyDict_SetItemString( ret, "nerrors", PyInt_FromLong( nerrors ) );
   ^~
In file included from /usr/include/python3.6m/Python.h:90:0,
 from pycodcif.c:1:
/usr/include/python3.6m/dictobject.h:160:17: note: expected 'PyObject * {aka 
struct _object *}' but argument is of type 'int'
 PyAPI_FUNC(int) PyDict_SetItemString(PyObject *dp, const char *key, PyObject 
*item);
 ^~~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-z,relro -Wl,-z,now -g -O2 
-fdebug-prefix-map=/<>/cod-tools-2.2+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/externals/cexceptions/cxprintf.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/externals/cexceptions/stringx.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/externals/cexceptions/allocx.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/externals/cexceptions/stdiox.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/externals/cexceptions/cexceptions.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif_options.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/common.o
 build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/compo
 nents/codcif/ciftable.o 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif2_lexer.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cifvalue.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cifmessage.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif_grammar_flex.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif_lexer.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/datablock.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif_compiler.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/ciflist.o
 
build/temp.linux-x86_64-3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif_grammar.tab.o
 build/temp.linux-x86_64-
 3.6/<>/cod-tools-2.2+dfsg/src/components/codcif/cif2_grammar.tab.o 
build/temp.linux-x86_64-3.6/pycodcif_wrap.o 
build/temp.linux-x86_64-3.6/pycodcif.o -o 
build/lib.linux-x86_64-3.6/pycodcif/_pycodcif.cpython-36m-x86_64-linux-gnu.so
running install_lib
creating /<>/cod-tools-2.2+dfsg/debian/python3-pycodcif
creating /<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr
creating /<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local
creating /<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib
creating 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6
creating 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages
creating 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages/pycodcif
copying 
build/lib.linux-x86_64-3.6/pycodcif/_pycodcif.cpython-36m-x86_64-linux-gnu.so 
-> 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages/pycodcif
copying build/lib.linux-x86_64-3.6/pycodcif/__init__.py -> 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages/pycodcif
copying build/lib.linux-x86_64-3.6/pycodcif/pycodcif.py -> 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages/pycodcif
byte-compiling 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages/pycodcif/__init__.py
 to __init__.cpython-36.pyc
byte-compiling 
/<>/cod-tools-2.2+dfsg/debian/python3-pycodcif/usr/local/lib/python3.6/dist-packages/pycodcif/pycodcif.py
 to pycodcif.cpython-36.pyc
running install_egg_info
running egg_info

Bug#903866: python-{clang,lldb}-4.0: missing Breaks+Replaces against python-clang-3.[45], python-lldb-3.5

[Andreas Beckmann]

Package: python-clang-4.0,python-lldb-4.0
Version: 1:4.0.1-10~deb9u2
Severity: serious
Tags: stretch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../python-clang-4.0_1%3a4.0.1-10~deb9u2_amd64.deb ...
  Unpacking python-clang-4.0 (1:4.0.1-10~deb9u2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-clang-4.0_1%3a4.0.1-10~deb9u2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/clang/__init__.py', 
which is also in package python-clang-3.4 1:3.4.2-13
  Errors were encountered while processing:
   /var/cache/apt/archives/python-clang-4.0_1%3a4.0.1-10~deb9u2_amd64.deb

  Preparing to unpack .../python-clang-4.0_1%3a4.0.1-10~deb9u2_amd64.deb ...
  Unpacking python-clang-4.0 (1:4.0.1-10~deb9u2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-clang-4.0_1%3a4.0.1-10~deb9u2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/clang/__init__.py', 
which is also in package python-clang-3.5 1:3.5-10
  Errors were encountered while processing:
   /var/cache/apt/archives/python-clang-4.0_1%3a4.0.1-10~deb9u2_amd64.deb

  Selecting previously unselected package python-lldb-4.0.
  Preparing to unpack .../python-lldb-4.0_1%3a4.0.1-10~deb9u2_amd64.deb ...
  Unpacking python-lldb-4.0 (1:4.0.1-10~deb9u2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-lldb-4.0_1%3a4.0.1-10~deb9u2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/lldb', which is also 
in package python-lldb-3.5 1:3.5-10

The inclusion of llvm-4.0 in stretch brought it into proximity of the
old packages from jessie (that predate the virtual python-{clang,lldb}-x.y
packages), which might remain after an upgrade from jessie to stretch.



cheers,

Andreas


python-clang-3.4=1%3.4.2-13_python-clang-4.0=1%4.0.1-10~deb9u2.log.gz
Description: application/gzip

Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

[Alex Dănilă]

Update: I downgraded: libffi6:amd64 from 3.3~20160224-1 to 3.2.1-8 and 
tested Amarok, kscreenlocker and Dolphin -> all are fixed.


Still, I don't find the libffi6 upgrade in the recent apt logs.

Alex

Bug#903865: reportbug: should automatically add the ftbfs tag for the does-not-build severity

[Vincent Lefevre]

Package: reportbug
Version: 7.5.0
Severity: wishlist

A new tag "ftbfs" has recently been added:

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

When one selects the "does-not-build" virtual severity

5 does-not-build  a bug that stops the package from being built from source.
  (This is a 'virtual severity'.)

reportbug should automatically add this ftbfs tag to the bug,
since this is exactly what this virtual severity is about.

-- Package-specific info:
** Environment settings:
EDITOR="/home/vinc17/bin/eclient"
PAGER="less -Lis"
VISUAL="/home/vinc17/bin/eclient"
EMAIL="vinc...@vinc17.net"
INTERFACE="text"

** /home/vinc17/.reportbugrc:
reportbug_version "2.10"
mode advanced
ui text
realname "Vincent Lefevre"
email "vinc...@vinc17.net"
mua mutt
cc

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

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

Versions of packages reportbug depends on:
ii  apt1.6.3
ii  python33.6.6-1
ii  python3-reportbug  7.5.0
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
ii  debsums 2.2.3
ii  dlocate 1.07+nmu1
ii  emacs25-bin-common  25.2+1-6+b3
ii  file1:5.33-3
ii  gnupg   2.2.8-3
ii  postfix [mail-transport-agent]  3.3.0-1+b1
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.6.3
ii  file   1:5.33-3
ii  python33.6.6-1
ii  python3-apt1.6.2
ii  python3-debian 0.1.32
ii  python3-debianbts  2.7.2
ii  python3-requests   2.18.4-2

python3-reportbug suggests no packages.

-- no debconf information

Bug#903864: [INTL:es] Spanish translation of the debconf template iproute

[jathan]

Package: iproute
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of iproute.

Regards
Jathan

-- 
Por favor evita enviarme adjuntos en formato de word o powerpoint, si
quieres saber porque lee esto:
http://www.gnu.org/philosophy/no-word-attachments.es.html
¡Cámbiate a GNU/Linux! http://getgnulinux.org/es
# iproute2 po-debconf translation to Spanish.
# Copyright (C) 2018 Software in the Public Interest
# This file is distributed under the same license as the iproute2 package.
#
# - Initial translation
# Jonathan Bustillos , 2018.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: iproute2\n"
"Report-Msgid-Bugs-To: iprou...@packages.debian.org\n"
"POT-Creation-Date: 2018-04-12 12:01+0100\n"
"PO-Revision-Date: 2018-07-16 00:36+0200\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: boolean
#. Description
#: ../iproute2.templates:1001
msgid "Allow ordinary users to run ip vrf exec using capabilities?"
msgstr ""
"¿Permitir que los usuarios comunes ejecuten ip vrf exec usando capacidades?"

#. Type: boolean
#. Description
#: ../iproute2.templates:1001
msgid ""
"iproute2 can be used to configure and use Virtual Routing and Forwarding "
"(VRF) functionality in the  kernel. This normally requires root permissions, "
"but sometimes it's useful to allow ordinary users to execute commands from "
"inside a virtual routing and forwarding domain. E.g. ip vrf exec examplevrf "
"ping 10.0.0.1"
msgstr ""
"iproute2 se puede usar para configurar y usar la funcionalidad Virtual "
"Routing and Forwarding (VRF) en el kernel. Esto normalmente requiere "
"privilegios de root, pero a veces es útil para permitir que los usuarios "
"comunes ejecuten órdenes dentro de un dominio de enrutamiento y reenvío "
"virtual. Por ejemplo. ip vrf exec examplevrf ping 10.0.0.1"

#. Type: boolean
#. Description
#: ../iproute2.templates:1001
msgid ""
"The ip command supports dropping capabilities, making an exception for ip "
"vrf exec. The drawback of setting the permissions is that if in the unlikely "
"case of a security critical bug being found before the ip command has "
"dropped capabilities then it could be used by an attacker to gain root "
"permissions. It's up to you to decide about the trade-offs and select the "
"best setting for your system. This will give cap_dac_override, cap_net_admin "
"and cap_sys_admin to /bin/ip."
msgstr ""
"La orden ip admite caídas de capacidades, haciendo una excepción para ip vrf "
"exec. El inconveniente de establecer los privilegios es que, en el caso "
"improbable de que se encuentre un error crítico de seguridad antes de que la "
"orden ip haya descartado las capacidades, un atacante podría usarlo para "
"obtener privilegios de root. Depende de usted decidir sobre las "
"compensaciones y seleccionar la mejor configuración para su sistema. Esto "
"otorgará cap_dac_override, cap_net_admin y cap_sys_admin a /bin/ip."

#. Type: boolean
#. Description
#: ../iproute2.templates:1001
msgid ""
"More information about VRF can be found at: https://www.kernel.org/doc/;
"Documentation/networking/vrf.txt"
msgstr ""
"Se puede encontrar más información sobre VRF en: https://www.kernel.org/doc/;
"Documentation/networking/vrf.txt"


signature.asc
Description: OpenPGP digital signature

Bug#903863: [INTL:es] Spanish translation of the debconf template privoxy

[jathan]

Package: privoxy
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of privoxy.

Regards
Jathan

-- 
Por favor evita enviarme adjuntos en formato de word o powerpoint, si
quieres saber porque lee esto:
http://www.gnu.org/philosophy/no-word-attachments.es.html
¡Cámbiate a GNU/Linux! http://getgnulinux.org/es
# privoxy po-debconf translation to Spanish.
# Copyright (C) 2018 Software in the Public Interest
# This file is distributed under the same license as the privoxy package.
#
# - Initial translation
# Jonathan Bustillos , 2018.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: privoxy\n"
"Report-Msgid-Bugs-To: priv...@packages.debian.org\n"
"POT-Creation-Date: 2016-04-08 17:17+0200\n"
"PO-Revision-Date: 2018-07-16 00:23+0200\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: string
#. Description
#: ../templates:1001
msgid "Adresses on with Privoxy listens:"
msgstr "Direcciones que Privoxy escucha:"

#. Type: string
#. Description
#: ../templates:1001
msgid ""
"Please enter a space separated list of address:port combinations on which "
"Privoxy will listen for client requests."
msgstr ""
"Introduzca una lista de combinaciones dirección:puerto separadas por "
"espacios en las que Privoxy escuchará las solicitudes de los clientes."


signature.asc
Description: OpenPGP digital signature

Bug#903861: [INTL:es] Spanish translation of the debconf template sash

[jathan]

Package: sash
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of sash.

Regards
Jathan


-- 
Por favor evita enviarme adjuntos en formato de word o powerpoint, si
quieres saber porque lee esto:
http://www.gnu.org/philosophy/no-word-attachments.es.html
¡Cámbiate a GNU/Linux! http://getgnulinux.org/es
# sash po-debconf translation to Spanish.
# Copyright (C) 2018 Software in the Public Interest
# This file is distributed under the same license as the sash package.
#
# - Initial translation
# Jonathan Bustillos , 2018.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: sash\n"
"Report-Msgid-Bugs-To: s...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-16 19:14+0200\n"
"PO-Revision-Date: 2018-05-28 23:10+0200\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: error
#. Description
#: ../templates:1001
msgid "sashroot user detected"
msgstr "Usuario sashroot detectado"

#. Type: error
#. Description
#: ../templates:1001
msgid ""
"Previous versions of sash offered to create a root user with shell set to /"
"bin/sash.  This system has such a user."
msgstr ""
"Versiones anteriores de sash ofrecían crear un usuario root con un shell "
"definido en /bin/sash. Este sistema tiene tal usuario."

#. Type: error
#. Description
#: ../templates:1001
msgid ""
"This can unfortunately not be automatically removed together with the "
"package, so you need to manually delete the sashroot user."
msgstr ""
"Desafortunadamente esto no se puede eliminar automáticamente junto con el "
"paquete, por lo que debe eliminar manualmente el usuario sashroot."


signature.asc
Description: OpenPGP digital signature

Bug#903862: FTBFS: override_dh_auto_test exits with exit 2

[Vincent Lefevre]

Source: gnucash
Version: 3.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

The build with "apt-get source -b gnucash" ends with:

[...]
118/118 Testing: python-bindings
118/118 Test: python-bindings
Command: "/usr/bin/python3" 
"/home/vinc17/tmp/gnucash-3.2/bindings/python/tests/runTests.py.in"
Directory: /home/vinc17/tmp/gnucash-3.2/.build/bindings/python/tests
"python-bindings" start time: Jul 15 23:33 CEST
Output:
--
* 23:33:21  WARN  no backend loaded, or the backend doesn't 
define register_cb, returning 0
* 23:33:21  WARN  no backend loaded, or the backend doesn't 
define register_cb, returning 0
* 23:33:21  WARN  no backend loaded, or the backend doesn't 
define register_cb, returning 0
* 23:33:21  WARN  no backend loaded, or the backend doesn't 
define register_cb, returning 0
* 23:33:21  WARN  no backend loaded, or the backend doesn't 
define register_cb, returning 0
.
--
Ran 41 tests in 0.150s

OK

Test time =   0.35 sec
--
Test Passed.
"python-bindings" end time: Jul 15 23:33 CEST
"python-bindings" time elapsed: 00:00:00
--

End testing: Jul 15 23:33 CEST
+ exit 2
make[1]: *** [debian/rules:83: override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/vinc17/tmp/gnucash-3.2'
make: *** [debian/rules:26: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
E: Build command 'cd gnucash-3.2 && dpkg-buildpackage -b -uc' failed.

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

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

-- no debconf information

Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

[Alex Dănilă]

Hi,

I attached journalctl output for starting Amarok, it generaly repeats 
the following:


Jul 16 01:07:45 debian systemd[1]: Starting Daemon for power management...
Jul 16 01:07:45 debian upowerd[15176]: /usr/lib/upower/upowerd: error 
while loading shared libraries: libffi.so.6: cannot enable executable 
stack as shared object requires: Operation not permitted
Jul 16 01:07:45 debian systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 16 01:07:45 debian systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 16 01:07:45 debian systemd[1]: Failed to start Daemon for power 
management.


Related: the power management applet currently says „no battery 
available” although this is a laptop.


Looking at upgrades, indeed, around the date the problem started I had 
upgraded: upower:amd64 (0.99.8-1, 0.99.8-2), libupower-glib3:amd64 
(0.99.8-1, 0.99.8-2). I can filter more data if needed.


Thank you,
Alex


Jul 16 01:07:45 debian dbus-daemon[1022]: [system] Failed to activate service 
'org.freedesktop.UPower': timed out (service_start_timeout=25000ms)
Jul 16 01:07:45 debian dbus-daemon[1022]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.249' (uid=1000 pid=15147 comm="amarok ")
Jul 16 01:07:45 debian systemd[1]: Starting Daemon for power management...
Jul 16 01:07:45 debian upowerd[15176]: /usr/lib/upower/upowerd: error while 
loading shared libraries: libffi.so.6: cannot enable executable stack as shared 
object requires: Operation not permitted
Jul 16 01:07:45 debian systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 16 01:07:45 debian systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 16 01:07:45 debian systemd[1]: Failed to start Daemon for power management.
Jul 16 01:07:45 debian systemd[1]: upower.service: Service RestartSec=100ms 
expired, scheduling restart.
Jul 16 01:07:45 debian systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 1.
Jul 16 01:07:45 debian systemd[1]: Stopped Daemon for power management.
Jul 16 01:07:45 debian systemd[1]: Starting Daemon for power management...
Jul 16 01:07:45 debian upowerd[15179]: /usr/lib/upower/upowerd: error while 
loading shared libraries: libffi.so.6: cannot enable executable stack as shared 
object requires: Operation not permitted
Jul 16 01:07:45 debian systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 16 01:07:45 debian systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 16 01:07:45 debian systemd[1]: Failed to start Daemon for power management.
Jul 16 01:07:45 debian systemd[1]: upower.service: Service RestartSec=100ms 
expired, scheduling restart.
Jul 16 01:07:45 debian systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 2.
Jul 16 01:07:45 debian systemd[1]: Stopped Daemon for power management.
Jul 16 01:07:45 debian systemd[1]: Starting Daemon for power management...
Jul 16 01:07:45 debian upowerd[15182]: /usr/lib/upower/upowerd: error while 
loading shared libraries: libffi.so.6: cannot enable executable stack as shared 
object requires: Operation not permitted
Jul 16 01:07:45 debian systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 16 01:07:45 debian systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 16 01:07:45 debian systemd[1]: Failed to start Daemon for power management.
Jul 16 01:07:45 debian systemd[1]: upower.service: Service RestartSec=100ms 
expired, scheduling restart.
Jul 16 01:07:45 debian systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 3.
Jul 16 01:07:45 debian systemd[1]: Stopped Daemon for power management.
Jul 16 01:07:45 debian systemd[1]: Starting Daemon for power management...
Jul 16 01:07:46 debian upowerd[15185]: /usr/lib/upower/upowerd: error while 
loading shared libraries: libffi.so.6: cannot enable executable stack as shared 
object requires: Operation not permitted
Jul 16 01:07:46 debian systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 16 01:07:46 debian systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 16 01:07:46 debian systemd[1]: Failed to start Daemon for power management.
Jul 16 01:07:46 debian systemd[1]: upower.service: Service RestartSec=100ms 
expired, scheduling restart.
Jul 16 01:07:46 debian systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 4.
Jul 16 01:07:46 debian systemd[1]: Stopped Daemon for power management.
Jul 16 01:07:46 debian systemd[1]: Starting Daemon for power management...
Jul 16 01:07:46 debian upowerd[15188]: /usr/lib/upower/upowerd: error while 
loading shared libraries: libffi.so.6: cannot enable executable stack as shared 
object requires: Operation not permitted
Jul 16 01:07:46 debian systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 16 01:07:46 debian systemd[1]: upower.service: 

Bug#903851: dbus does not automatically start after dist-upgrade system stretch with updates from buster

[Thomas Hardman]

Sir,

I will probably take your advice and revert back to stretch with
stretch-backports. Perhaps, as I do know a workaround that suffices -- this
is not a production system -- I may try to limp along in the hopes that
this might be fixed in in another update or three. For bug-report purposes
you might consider this resolved as far as this user is concerned. The fix
for me is to start in Recovery mode and then start dbus manually from the
root commandline, and then `systemctl default` will bring the system up the
rest of the way.

/var/log/syslog is not particularly helpful. `cat syslog |grep "Jul 15 15:"
|grep dbus` mostly shows success after starting the dbus service by hand
with `service dbus start`. Perhaps there's some failure to report an error
when systemd does not successfully start dbus?

The list of packages upgrades is quite long. Here it is, appended.

Regards,

linux-headers-4.9.0-7-common:amd64 (4.9.110-1, automatic),
linux-headers-4.9.0-7-amd64:amd64 (4.9.110-1, automatic),
libnvidia-egl-wayland1:amd64 (384.130-1, automatic),
libnvidia-ptxjitcompiler1:amd64 (384.130-1, automatic),
nvidia-egl-wayland-icd:amd64 (384.130-1, automatic),
nvidia-egl-wayland-common:amd64 (384.130-1, automatic), libglvnd0:amd64
(1.0.0+git20180308-3, automatic)
Upgrade: libmagick++-6.q16-7:amd64 (8:6.9.7.4+dfsg-11+deb9u4,
8:6.9.7.4+dfsg-11+deb9u5), libimage-magick-perl:amd64
(8:6.9.7.4+dfsg-11+deb9u4, 8:6.9.7.4+dfsg-11+deb9u5), libldap2-dev:amd64
(2.4.44+dfsg-5+deb9u1, 2.4.44+dfsg-5+deb9u2), libcups2:amd64
(2.2.1-8+deb9u1, 2.2.1-8+deb9u2), libglx0-glvnd-nvidia:amd64
(375.82-1~deb9u1, 384.130-1), intel-microcode:amd64 (3.20170707.1~deb9u1,
3.20180425.1~deb9u1), libgles-nvidia1:amd64 (375.82-1~deb9u1, 384.130-1),
libgles-nvidia2:amd64 (375.82-1~deb9u1, 384.130-1), libdiscover2:amd64
(2.1.2-7.1, 2.1.2-7.1+deb9u1), linux-libc-dev:amd64 (4.9.88-1+deb9u1,
4.9.110-1), libldap-2.4-2:amd64 (2.4.44+dfsg-5+deb9u1,
2.4.44+dfsg-5+deb9u2), libnvidia-ml1:amd64 (375.82-1~deb9u1, 384.130-1),
libxapian30:amd64 (1.4.3-2, 1.4.3-2+deb9u1), nvidia-egl-icd:amd64
(375.82-1~deb9u1, 384.130-1), libimage-magick-q16-perl:amd64
(8:6.9.7.4+dfsg-11+deb9u4, 8:6.9.7.4+dfsg-11+deb9u5), imagemagick:amd64
(8:6.9.7.4+dfsg-11+deb9u4, 8:6.9.7.4+dfsg-11+deb9u5), libsystemd0:amd64
(232-25+deb9u2, 232-25+deb9u4), update-glx:amd64 (0.7.4, 0.8.3~deb9u1),
libsystemd-dev:amd64 (232-25+deb9u2, 232-25+deb9u4), libgs9:amd64
(9.20~dfsg-3.2+deb9u1, 9.20~dfsg-3.2+deb9u2), nvidia-driver:amd64
(375.82-1~deb9u1, 384.130-1), libcups2-dev:amd64 (2.2.1-8+deb9u1,
2.2.1-8+deb9u2), libcupsimage2-dev:amd64 (2.2.1-8+deb9u1, 2.2.1-8+deb9u2),
libmagickwand-6.q16-3:amd64 (8:6.9.7.4+dfsg-11+deb9u4,
8:6.9.7.4+dfsg-11+deb9u5), liblouis12:amd64 (3.0.0-3+deb9u1,
3.0.0-3+deb9u4), python3-louis:amd64 (3.0.0-3+deb9u1, 3.0.0-3+deb9u4),
nvidia-vdpau-driver:amd64 (375.82-1~deb9u1, 384.130-1), udev:amd64
(232-25+deb9u2, 232-25+deb9u4), libgl1-nvidia-glvnd-glx:amd64
(375.82-1~deb9u1, 384.130-1), libmagic-dev:amd64 (1:5.30-1+deb9u1,
1:5.30-1+deb9u2), cups-server-common:amd64 (2.2.1-8+deb9u1,
2.2.1-8+deb9u2), libglx-nvidia0:amd64 (375.82-1~deb9u1, 384.130-1),
glx-alternative-nvidia:amd64 (0.7.4, 0.8.3~deb9u1), nvidia-smi:amd64
(375.82-1~deb9u1, 384.130-1), linux-compiler-gcc-6-x86:amd64
(4.9.88-1+deb9u1, 4.9.110-1), cups-common:amd64 (2.2.1-8+deb9u1,
2.2.1-8+deb9u2), libmagic1:amd64 (1:5.30-1+deb9u1, 1:5.30-1+deb9u2),
libpq5:amd64 (9.6.7-0+deb9u1, 9.6.9-0+deb9u1), dselect:amd64 (1.18.24,
1.18.25), apache2-data:amd64 (2.4.25-3+deb9u4, 2.4.25-3+deb9u5),
libsvn1:amd64 (1.9.5-1+deb9u1, 1.9.5-1+deb9u2), libudev1:amd64
(232-25+deb9u2, 232-25+deb9u4), nvidia-kernel-dkms:amd64 (375.82-1~deb9u1,
384.130-1), libpq-dev:amd64 (9.6.7-0+deb9u1, 9.6.9-0+deb9u1),
libegl-nvidia0:amd64 (375.82-1~deb9u1, 384.130-1), nvidia-egl-common:amd64
(375.82-1~deb9u1, 384.130-1), libgles1-glvnd-nvidia:amd64 (375.82-1~deb9u1,
384.130-1), libxerces-c3.1:amd64 (3.1.4+debian-2, 3.1.4+debian-2+deb9u1),
dpkg:amd64 (1.18.24, 1.18.25), imagemagick-6.q16:amd64
(8:6.9.7.4+dfsg-11+deb9u4, 8:6.9.7.4+dfsg-11+deb9u5), libnvidia-cfg1:amd64
(375.82-1~deb9u1, 384.130-1), nvidia-legacy-check:amd64 (375.82-1~deb9u1,
384.130-1), libmagic-mgc:amd64 (1:5.30-1+deb9u1, 1:5.30-1+deb9u2),
libsvn-perl:amd64 (1.9.5-1+deb9u1, 1.9.5-1+deb9u2), libudev-dev:amd64
(232-25+deb9u2, 232-25+deb9u4), cups-ppdc:amd64 (2.2.1-8+deb9u1,
2.2.1-8+deb9u2), libcupsmime1:amd64 (2.2.1-8+deb9u1, 2.2.1-8+deb9u2),
subversion:amd64 (1.9.5-1+deb9u1, 1.9.5-1+deb9u2), reportbug:amd64
(7.1.7+deb9u1, 7.1.7+deb9u2), libnvidia-fatbinaryloader:amd64
(375.82-1~deb9u1, 384.130-1), libnss-myhostname:amd64 (232-25+deb9u2,
232-25+deb9u4), discover:amd64 (2.1.2-7.1, 2.1.2-7.1+deb9u1),
systemd-sysv:amd64 (232-25+deb9u2, 232-25+deb9u4), libldap-common:amd64
(2.4.44+dfsg-5+deb9u1, 2.4.44+dfsg-5+deb9u2), nvidia-kernel-support:amd64
(375.82-1~deb9u1, 384.130-1), glx-diversions:amd64 (0.7.4, 0.8.3~deb9u1),
libpam-systemd:amd64 (232-25+deb9u2, 232-25+deb9u4), clamav:amd64
(0.99.4+dfsg-1+deb9u1, 

Bug#903860: python3-stem: File "/usr/lib/python3/dist-packages/stem/util/test/test_tools.py", line 151 / self.method.async = self /

[Jacobi]

Package: python3-stem
Version: 1.6.0-1
Severity: serious
Tags: a11y
Justification: fails to build from source

Dear Maintainer,



   * What led up to the situation?
Package was pulled in as a dependency for nyx which is a dependency for tor-arm 
and onionshare
   * What exactly did you do (or not do) that was effective (or
 ineffective)?  Have tried purging and building from source.  Have dpkg 
--purge to reinstall the package but was also not effective. 
   * What was the outcome of this action?
Package still will not install
   * What outcome did you expect instead?
Hoping a rebuild would have helped



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

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 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 python3-stem depends on:
ii  python3  3.6.6-1

python3-stem recommends no packages.

python3-stem suggests no packages.

-- no debconf information

Bug#903815: ITP: pw -- A simple command-line password manager

[Simon McVittie]

On Sun, 15 Jul 2018 at 12:07:30 +0200, Dashamir Hoxha wrote:
> Either you did not look close enough to the code, or you are not
> an expert on bash scripting (bash is a bit cryptic and difficult
> to understand even for experts).

You are right to say that shell scripting (for bash or for Bourne shells
in general) is cryptic and difficult to understand. I've found that many
of the people who understand shell well enough to write correct shell
scripts prefer to avoid writing non-trivial shell scripts, because they
know they will be more productive in a language with fewer sharp edges.

In my experience, writing a robust shell script requires a lot of
defensive programming (this is not just my personal opinion, Debian
Policy also touches on this [1]).

> Instead of basing your judgment on general opinions, why don't you
> try to find any particular situation that will break the script in some
> interesting way ;) This is called proof by counter-example.
> If you cannot do this, and if nobody else can do this, then you cannot
> claim that it is not safe to use this script.

You can use proof by counter-example to demonstrate that a particular
shell script is not correct: if your assertion is "this shell script
behaves as documented", finding an input that will make the script
behave not-as-documented disproves that assertion. The converse is
not true. If nobody finds an input that breaks the shell script, that
does not mean that no such input exists: it could equally well mean
that nobody has looked for long enough yet, for instance because they
consider auditing a shell script that doesn't start with set -e [1]
to be an inefficient use of their time.

smcv

[1] https://www.debian.org/doc/debian-policy/#scripts

Bug#903859: CVE-2018-14054

[Moritz Muehlenhoff]

Source: mp4v2
Severity: important
Tags: security

Please see http://www.openwall.com/lists/oss-security/2018/07/13/1

Cheers,
Moritz

Bug#903858: CVE-2018-14072 / CVE-2018-14073

[Moritz Muehlenhoff]

Source: libsixel
Severity: normal
Tags: security

Please see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14072
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14073

These don't warrant a DSA security update, if you want you could
address them via a stretch point release (or we rather ignore
it for stable entirely, as the impact seems negligable)

Cheers,
Moritz

Bug#888793: glibc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Vagrant Cascadian]

On 2018-02-03, Aurelien Jarno wrote:
> On 2018-01-30 00:46, Manuel A. Fernandez Montecelo wrote:
>> The upcoming release 2.27 will ship with support for "riscv64", RISC-V 64 
>> bits
>> little-endian, and we'd like to have it enabled as soon as possible/feasible.
>
> glibc 2.27 is now available in experimental.
>
>> dpkg 1.19.0.5, released a few days ago, contains support for this arch, and 
>> the
>> current plans is to ship this in the next stable update.
>
> Indeed, we can't support riscv64 in glibc before the support for this
> architecture is available in dpkg/stable. Otherwise the package will
> just be rejected on ftpmaster with an unknown architecture issue.

This is no longer an issue; dpkg in stable supports riscv64 and
ftpmaster is accepting riscv64 packages.

Please consider including riscv64 in the next uploads.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#903857: binutils-riscv64-linux-gnu: enable riscv64

[Vagrant Cascadian]

Package: binutils-riscv64-linux-gnu
Severity: wishlist
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Since dpkg was updated in stable to include riscv64 support, and dak now
accepts riscv64 binary packages, it should be possible to build
binutils-riscv64-linux-gnu for riscv64 as well as removing some of the
hacks in debian/rules related to riscv64.

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#903856: RFS: argyll/2.0.1+repack-1

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: argyll
   Version : 2.0.1+repack-1
   Upstream Author : Graeme W. Gill 
   URL : https://www.argyllcms.com/
   License : AGPL-3, Expat, BSD-3, BSD-2, MIT, MIT and GPL-3+,
 GPL-2 or LGPL-2, GPL-2+, GPL-3+, GFDL-1.3+,
 LGPL-2+, public-domain
   Section : graphics

  It builds those binary packages:

argyll - Color Management System, calibrator and profiler
argyll-doc - Color Management System, calibrator and profiler (documentation)
argyll-ref - Color Management System, calibrator and profiler (data files)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/a/argyll/argyll_2.0.1+repack-1.dsc

  Changes since the last upload:

  * New upstream release:
- Refresh patches.
  * Remove obsolete /etc/hotplug/usb/Argyll.usermap (Closes: #885549).
  * Add more typos to patches/0100_spelling.patch.
  * Declare compliance with Debian Policy 4.1.5 (No changes needed).
  * Migrate to debhelper 11:
- Change debian/compat to 11.
- Bump minimum debhelper version in debian/control to >= 11.
  * debian/rules:
- Correct doc directory handling.
- Remove override_dh_strip, used for debug symbol migration.
  * debian/control:
- Switch Vcs-* to new location.
  * debian/copyright:
- Add copyright for numlib/quadprog.*.
- Use secure copyright format URI.
- Correct typo.
- Refresh copyright years.
  * Remove *.postinst, *.postrm and *.preinst. They was used for release
 1.6.3-2 and at oldstable are 1.6.3-4.
  * Remove useless debian/repack.sh.


  Regards,
   Jörg Frings-Fürst


- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltLuXIACgkQCfifPIyh
0l0rkhAAqGkVzijoL7EYjwRDcTklRTLjeGVWcVklmBWZ4MwrNHSosPHO/nqUmnmu
Dgr5m6UcXQFMRUpfVoX1dBKwr4DFb2bliaSiJouDayY+R7mpbZmMSli8owSesZ0A
9jfYhhwR3V/MGwG/fFdpLQXJmHMnw9PSNnXQ/6k8qL4gNETUQrJOlkovHs9BXn1r
6uyd58yHcGxqsrUGSXclp9tq5jLuiMSwJ5ovrIaXsj6zm2or6gUwWz+wsi5ai1H1
PC53UluOrr7F1WHXlur+DhYjTZzi+FYRe7a06R5F+zLoe/ixIuopphMBi9wMSzTE
577We+xqGqAgallpX5ObUyofsCfj3/+JsImxYDbBS4eplqfYwx2lLf93xP6gnnwq
bEaJQExbvdJvfxeUjtpsZiKyhAwByaH7isI+l1YeaPiE1Lf/ixJFEESfDTxsmWeF
sPvJDlwHU/pYFcXcnWo4mdK1/TizMSIN9CZU1a9GLNoKUX+vY3fH5RQs1KQczsCj
bWv43fWeFVh8zMLLxCpADfDjPk6gwNdCTgqk+3pgwr6gx11j/xe5td75R5qU38YL
+fH7imN7kYyy2ROmQc8qvkEVNIQuzWhyMqBTL8Anh8MGc2+1EB1FSC9GA+KXKixv
EdTAb/T/wfe4K+Tx7CKstAyTCaVqKb85EIXwOBKkI8KTr5ABALI=
=nd2O
-END PGP SIGNATURE-

Bug#903851: dbus does not automatically start after dist-upgrade system stretch with updates from buster

[Simon McVittie]

On Sun, 15 Jul 2018 at 16:22:38 -0400, thardman-TJH4 wrote:
> stretch with updates from buster

Partial upgrades like this are difficult to support, and it is not
entirely surprising if they are not fully working. Which packages have
you upgraded to versions from buster?

I would recommend running one of these options:

* Debian 9 'stretch'
* Debian 9 'stretch' with selected packages upgraded from stretch-backports
* Debian testing/unstable (fully upgraded)

Regards,
smcv

Bug#868496: debmake-doc: Please Reference Debian Fonts

[Paul Hardy]

Osamu,

Here is a sample, simple font package that might help you document
font packaging in debmake-doc.  I needed to work through creating a
debian/copyright file in the new format, etc.  I didn't want to send
something that might not be useful as an example.

You can pick and choose what you want from this.  I used GPL 2+ as the
license; if you want a different license for debmake-doc, let me know.

In creating this, I placed a COPYING file and an INSTALL file in the
original (fake upstream) tarball.  They do not get installed of
course, because Debian handles them in different ways.  But those are
standard files in a GNU-style package distribution.

I also created a tiny NEWS file and README file.  Those are copied,
and are listed in debian/docs.

I also used an override for autopkgtest (see
debian/src/lintian-overrides).  With the package only consisting of
one TrueType font (that only contains one letter!) and some text
files, I don't know that autopkgtest can test anything.

Please go ahead and modify this any way you want if it will help make
debmake-doc clearer.

Let me know if you have any questions.

Thanks,


Paul Hardy
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEldLpq4dA2ARjh/0VGgkiex9DWjMFAltLsVUACgkQGgkiex9D
WjNnog//ZbddaD+P2ZwVUIRxuZ7nwtl5HbxipmFFmFft7QBs80HSoHH8X8h8T5MO
b3+Bb9FmJ4S8zCA7Ne0timdQnEglckmHNc5HgF2GMapmV5jHglvTBGJITnk+eYcR
yz68HaYoH7Hs7Z5ynRzL0bLzb8320dI/aIMZm0nyA3Ayjt3zutiA2iXsQtP4k7o7
ldZrtq/x3ur2//4boQcWEDWoXg0LMN8V86FESCssM0eSO1HsJQHyrjcAU1JhlYa3
wKVOl9LuieDXzEXWgEPIh/YO9IMsvhAyxG7R3dAZ3M/+6DEkJQ4gSxnGolN03fI/
Zp5/zx0wVG7WzSEuBhGOYJenVowfMEN8vORuTFUHJitv9FgDf244kMxzGiMtJpj8
qydAoGB1h7ZHfj+cfyxfmV4D7YJUyaoLdYySelTUhlcCpRjTAoGTCRbtHxcwaEao
iine0xcTWd6GYc1O2z7xrkpwi1iN6KdVK6wKU9Iev/U7j5hm8hh0bIWCkhJxsvpK
JrbWyvzEMlGslPGCGj59j8IAtGS1rFL0nb1FiuVF5MNGAkjE6qw784+B5EB23rf+
yHaQQp47R8WpAEw/2TvWUJOesZXNIzO88a1LJ1fDuGIo/J9ZNVBME9/3LTb3d3y/
UMrhGWDoYnuNE133fDigx06PVJpa4Dc0ZtwAgpTOfYu0IR5FKDI=
=2hvL
-END PGP SIGNATURE-


fonts-justa_1.0-1.debian.tar.gz.sig
Description: PGP signature


fonts-justa_1.0-1.debian.tar.gz
Description: application/gzip


fonts-justa_1.0.orig.tar.gz
Description: application/gzip

Bug#818905: Steam Controller is not correctly detected

[Michael Gilbert]

On Wed, May 2, 2018 at 12:22 PM, Simon McVittie wrote:
> Are you saying this because you don't want these udev rules to diverge
> from upstream's, or because your interpretation of the steam package's
> license is that you aren't allowed to patch them?

Both were a concern at the time, but it looks like the license of the
udev rules file has been changed recently to MIT.

> If the former, the udev package in SteamOS brewmaster has a patch that
> (among other things) does the equivalent of what I suggested, so they are
> effectively already doing that in SteamOS (although not in the steam.deb
> that is the "upstream" for Debian's steam package).

I would have expected Valve to update their upstream package by now.
Since they haven't in a very long time, I am fine with adding a patch
to the Debian package.

Best wishes,
Mike

Bug#903851: dbus does not automatically start after dist-upgrade system stretch with updates from buster

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 15 Jul 2018 at 16:22:38 -0400, thardman-TJH4 wrote:
> After `apt-get update ; apt-get dist-upgrade` system will not boot properly.
> service dbus is never started, fails to boot to anything but recovery mode.

What was upgraded in that transaction? (Please look in /var/log/apt
for details)

Please look at the system log (the systemd Journal or /var/log/syslog*)
for any log messages that seem possibly relevant, and in particular
anything that seems to have failed or that involves dbus, systemd or
systemd-tmpfiles.

Also please look in /var/log/apt/term.log* for any error or warning
messages that appeared during your upgrade.

Please send any relevant log messages to this bug. You can censor any
private information, but please make it obvious (replace with  or
similar).

> Discovered problem, no /var/run/dbus
> directory and thus no socket in that directory. Manually started with `service
> dbus start`, checked for existence of /var/run/dbus and it is there now.

systemd is meant to create that directory as a side-effect of creating
the system bus socket, as requested by /lib/systemd/system/dbus.socket.
The fact that `service dbus start` was successful indicates that this
is at least partially working. Hopefully the system log will have
more details of why it did not work during normal system boot.

Thanks,
smcv

Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 15 Jul 2018 at 18:33:39 +0300, Alex Dănilă wrote:
> The following take very long to start, 30 seconds to 2 minutes:
> - SDDM with theme Breeze (doesn't happen with default Maui)
> - kscreenlocker_greet - the first to show the behaviour, since about 1 week
> - Amarok
> - Dolphin
> - Krunner - it appears, but when the first letter is typed it will freeze for 
> a while; after the freeze ends it will run correctly for the rest of the 
> session.

Please look in the system log (systemd Journal or /var/log/syslog) for
any messages that look relevant, in particular around the times that
you are launching these programs. You can censor information from these
logs as long as you make it obvious what's been censored (replace with
 or similar).

Did this problem start with a recent upgrade of some package? The files
in /var/log/apt might be useful to remind you what has been upgraded
recently.

The default timeout for a D-Bus method call is 25 seconds, so if some
program blocks for 25 seconds and then proceeds, it is usually a sign
that it is waiting for a D-Bus method call to finish. This could be a
bug in the program that is blocking, the program that it is contacting,
or the dbus-daemon through which they communicate.

> Amarok:
> (gdb) where
...
> #5  0x7fffe34777fe in dbus_connection_send_with_reply_and_block () at 
> /lib/x86_64-linux-gnu/libdbus-1.so.3
> #6  0x70f7ed93 in q_dbus_connection_send_with_reply_and_block 
> (error=0x7fffd240, timeout_milliseconds=-1, message=0x5594a630, 
> connection=) at qdbus_symbols_p.h:135
> #7  0x70f7ed93 in QDBusConnectionPrivate::sendWithReply(QDBusMessage 
> const&, int, int) (this=this@entry=
> 0x55ce4890, message=..., sendMode=sendMode@entry=1, 
> timeout=timeout@entry=-1) at qdbusintegrator.cpp:1912
> #8  0x70f80f53 in QDBusConnectionPrivate::findMetaObject(QString 
> const&, QString const&, QString const&, QDBusError&) (this=0x55ce4890, 
> service=..., path=..., interface=..., error=...) at qdbusintegrator.cpp:2386
> #9  0x70f8dd0b in 
> QDBusInterfacePrivate::QDBusInterfacePrivate(QString const&, QString const&, 
> QString const&, QDBusConnection const&) (this=0x55d19200, serv=..., 
> p=..., iface=..., con=...) at qdbusinterface.cpp:158
> #10 0x70f8de65 in QDBusInterface::QDBusInterface(QString const&, 
> QString const&, QString const&, QDBusConnection const&, QObject*) 
> (this=0x55d18c98, service=..., path=..., interface=..., connection=..., 
> parent=0x0) at qdbusinterface.cpp:220
> #11 0x718177c9 in 
> Solid::Backends::UPower::UPowerManager::UPowerManager(QObject*) 
> (this=0x55d18c80, parent=)
> at ./solid/solid/backends/upower/upowermanager.cpp:41
> #12 0x717bc12b in Solid::ManagerBasePrivate::loadBackends() 
> (this=this@entry=0x55b887c0) at ./solid/solid/managerbase.cpp:99

It looks like the "Solid" hardware management library used by Amarok is
contacting UPower and waiting for a reply. It should probably be using
an asynchronous call that does not block the main loop, instead of a
blocking call. There might also be some problem with the Solid library
or with UPower.

> For Dolphin
> (gdb) where
...
> #14 0x75baaebb in Solid::DeviceNotifier::instance() () from 
> /usr/lib/x86_64-linux-gnu/libKF5Solid.so.5

This could well be something similar.

smcv

Bug#903855: CVE-2016-10522

[Moritz Muehlenhoff]

Package: ruby-rails-admin
Severity: grave
Tags: security

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10522

Bug#886440: linux: Support to build linux-libc-dev for the upcoming riscv64 architecture

[Vagrant Cascadian]

Control: tags 886440 pending

On 2018-01-06, Manuel A. Fernandez Montecelo wrote:
> 2018-01-06 18:15 GMT+01:00 Ben Hutchings :
>> On Sat, 2018-01-06 at 01:09 +0100, Manuel A. Fernandez Montecelo wrote:
>>> The 4.15 kernel comes with initial support for RISC-V.
>>>
>>> Enabling support to build linux-libc-dev is one of the first steps to 
>>> bootstrap
>>> the architecture, so please consider enabling it.
>>>
>>> If there's anything wrong or missing, please let me know.
>>
>> You've missed out several steps:
>>
>> 1. Add the architecture definition to dpkg/unstable.
>> 2. Backport that addition to dpkg/stable.
>> 3. Get the stable update installed on ftp-master.
>>
>> dak will reject uploads that mention an architecture that the local
>> dpkg doesn't recognise.
>
> It's requested, but not done:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822914
>
> Didn't know about dak, thanks for the notice.

The dpkg patches have been included in stable, and we have reports of at
least one package with riscv64 enabled being successfully uploaded
without getting rejected by dak, so I've enabled this and should be
included in the next upload to sid:

  
https://salsa.debian.org/kernel-team/linux/commit/ba1733832fd94334fc88847ee013c3d62be29009


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#903819: Am I missing something with symlink_to_dir? Re: Bug#903819: r-cran-rmarkdown: Broken link /usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5/shim

[Andreas Tille]

Control: tags -1 help

Hi Ralf,

On Sun, Jul 15, 2018 at 12:06:49PM +0200, Ralf Stubner wrote:
> lrwxrwxrwx 1 root root   43 Jun 29 16:16 shim -> 
> ../../../../shiny/www/shared/bootstrap/shim
> 
> Please let me know if you need further info.

No further info is needed.  I actually realised the issue before and
fixed it in r-cran-rmarkdown_1.10+dfsg-2.  So if you remove
r-cran-rmarkdown_1.10+dfsg-1 and install r-cran-rmarkdown_1.10+dfsg-2
you will succeed with your test.

Unfortunately the issue persists since dpkg can not replace a symlink
with a directory or vice versa and thus if you have installed
r-cran-rmarkdown_1.10+dfsg-1 before the symlink issue remains.

This can be solved by using symlink_to_dir (see
dpkg-maintscript-helper(1)) and I tried this.  Unfortunately my
debian/maintscript[2] does not work (despite the resulting
preinst script looks like


#!/bin/sh
set -e
# Automatically added by dh_installdeb/11.3.5
dpkg-maintscript-helper symlink_to_dir 
/usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5 
../../../../../../share/javascript/bootstrap 1.10\+dfsg-2 -- "$@"
# End automatically added section


My question to debian-mentors list is now: Am I missing something?  How
can I turn the link
/usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5 successfully into
a dir?

Thanks for any help

   Andreas.


[1] 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Will_dpkg_replace_a_symlink_with_a_directory_or_vice_versa.3F
[2] 
https://salsa.debian.org/r-pkg-team/r-cran-rmarkdown/blob/master/debian/maintscript

-- 
http://fam-tille.de

Bug#903852: [Debian-ha-maintainers] Bug#903852: resource-agents: Please run autopkgtest against default-mysql-server instead of a specific implementation

[Valentin Vidic]

On Sun, Jul 15, 2018 at 10:32:27PM +0200, Paul Gevers wrote:
> Your package has an autopkgtest, great. However, I noticed that the
> package fails its reference test runs in testing¹. This is due to the
> test dependency on mysql-server, which isn't available in buster as
> Debian currently ships MariaDB.
> 
> Could consider testing with default-mysql-server instead? Otherwise any
> package is "allowed" to break your autopkgtest without it being noticed.

The mysql test seems to be working fine with default-mysql-server, I will
update the package in the next version.

-- 
Valentin

Bug#903279: closed by Jussi Pakkanen (Bug#903279: fixed in meson 0.47.1-1)

[Jussi Pakkanen]

On Sun, Jul 15, 2018 at 8:28 AM, Helmut Grohne  wrote:

>>* Install depfixer again, it got lost accidentally. Closes: #903279.
>
> The bug being closed here is about debcrossgen. You closed the wrong
> bug. debcrossgen is still missing.

That was a typo, it should have said debcrossgen instead of depfixer.
Sorry about that.

I have uploaded a new version to mentors [0] which does have
debcrossgen (I checked after install that it gets to
/usr/share/meson/debcrossgen).

However I could NOT run the proper test suite on this packaging
because the FPGA toolchain packages in Sid are currently broken. Thus
that package should be considered untested. I don't know what the
correct way to get that fixed is, but I don't like to keep disabling
more and more of the tests that we have (in autopkgtests even) because
our dependency packages break every now and then.

[0] https://mentors.debian.net/package/meson

Bug#903854: xandikos: autopkgtest sometimes times out: not robust against failure

[Paul Gevers]

Source: xandikos
Version: 0.0.9-1
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainers,

The last run of xandikos on ci.debian.net timed out. This happened once
before. I have copied the output below.

Could you please make your autopkgtest robust against this failure, so
that it doesn't waste time waiting?

It also seems that the failure isn't actually catching a regression, but
rather is sensitive to something else. If this happens more often, I
might mark the test as flaky and it will be skipped from
unstable-to-testing migration checking.

Don't hesitate to ask for help for the Debian CI team² if you need help
solving this issue.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xandikos/604719/log.gz

autopkgtest [15:28:02]: test litmus: [---
++ dirname ./compat/xandikos-litmus.sh
+ . ./compat/common.sh
++ XANDIKOS_PID=
+++ mktemp
++ DAEMON_LOG=/tmp/tmp.27fC2UKlVq
+++ mktemp -d
++ SERVEDIR=/tmp/tmp.6FgzxRB9lx
++ '[' -z xandikos ']'
++ set -e
+ TESTS=basic
+ set -e
+ run_xandikos --autocreate
+ XANDIKOS_PID=4295
+ trap xandikos_cleanup 0 EXIT
+ i=0
+ xandikos -p5233 -llocalhost -d /tmp/tmp.6FgzxRB9lx --autocreate
+ '[' 0 -lt 10 ']'
+ curl http://localhost:5233/
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
0curl: (7) Failed to connect to localhost port 5233: Connection refused
+ sleep 1
INFO:root:Creating /tmp/tmp.6FgzxRB9lx/user/
INFO:root:Listening on localhost:5233
+ let i+=1
+ '[' 1 -lt 10 ']'
+ curl http://localhost:5233/
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
0
100   361  100   3610 0  60166  0 --:--:-- --:--:-- --:--:--
60166
+ break
+ which litmus
+ LITMUS=litmus
+ TESTS=basic
+ litmus http://localhost:5233/
-> running `basic':

 0. init..
 0. init.. pass

 1. begin.
 1. begin. pass

 2. options...
 2. options... pass

 3. put_get...
 3. put_get... pass

 4. put_get_utf8_segment..
 4. put_get_utf8_segment.. pass

 5. put_no_parent.
 5. put_no_parent. pass

 6. mkcol_over_plain..
 6. mkcol_over_plain.. pass

 7. delete
 7. delete pass

 8. delete_null...
 8. delete_null... pass

 9. delete_fragment...
 9. delete_fragment... pass

10. mkcol.
10. mkcol. pass

11. mkcol_again...
11. mkcol_again... pass

12. delete_coll...
12. delete_coll... pass

13. mkcol_no_parent...
13. mkcol_no_parent... pass

14. mkcol_with_body...
14. mkcol_with_body... pass

15. finish
15. finish pass
<- summary for `basic': of 16 tests run: 16 passed, 0 failed. 100.0%
+ exit 0
+ xandikos_cleanup
+ '[' -z 4295 ']'
+ kill -TERM 4295
+ rm --preserve-root -rf /tmp/tmp.6FgzxRB9lx
127.0.0.1 - - [14/Jul/2018 15:28:04] "GET / HTTP/1.1" 200 361
127.0.0.1 - - [14/Jul/2018 15:28:04] "DELETE /litmus/ HTTP/1.1" 404 45
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/ HTTP/1.1" 201 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "OPTIONS /litmus/ HTTP/1.1" 200 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "PUT /litmus/res HTTP/1.1" 201 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "GET /litmus/res HTTP/1.1" 200 41
127.0.0.1 - - [14/Jul/2018 15:28:04] "PUT /litmus/res-%e2%82%ac
HTTP/1.1" 201 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "GET /litmus/res-%e2%82%ac
HTTP/1.1" 200 41
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/409me/noparent.txt/
HTTP/1.1" 409 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/res-%e2%82%ac/
HTTP/1.1" 405 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "DELETE /litmus/res-%e2%82%ac
HTTP/1.1" 204 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "DELETE /litmus/404me HTTP/1.1" 404 50
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/frag/ HTTP/1.1" 201 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "DELETE /litmus/frag/#ment
HTTP/1.1" 404 57
127.0.0.1 - - [14/Jul/2018 15:28:04] "DELETE /litmus/frag/ HTTP/1.1" 204 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/coll/ HTTP/1.1" 201 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/coll/ HTTP/1.1" 405 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "DELETE /litmus/coll/ HTTP/1.1" 204 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/409me/noparent/
HTTP/1.1" 409 0
127.0.0.1 - - [14/Jul/2018 15:28:04] "MKCOL /litmus/mkcolbody HTTP/1.1"
415 40
Traceback (most recent call last):
  File "/usr/lib/python3.6/wsgiref/handlers.py", line 138, in run
self.finish_response()
  File "/usr/lib/python3.6/wsgiref/handlers.py", line 180, in
finish_response
self.write(data)
  

Bug#901356: r-cran-caret: new version pulls in loads of development packages

[Dirk Eddelbuettel]

On 13 July 2018 at 09:10, Andreas Tille wrote:
| Dirk, please make sure you will rebuild
| 
| r-cran-rgl
| r-cran-sn
| 
| before Buster freeze.  Sorry for the inconvenience.

Done -- now that I am back from useR! in Australia.

I appreciate the heads-up, and thanks of course also for the dh-r work.

Dirk

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

Bug#903852: resource-agents: Please run autopkgtest against default-mysql-server instead of a specific implementation

[Paul Gevers]

Source: resource-agents
Version: 1:4.1.1-2
User: debian...@lists.debian.org
Usertags: issue

Dear maintainers,

Your package has an autopkgtest, great. However, I noticed that the
package fails its reference test runs in testing¹. This is due to the
test dependency on mysql-server, which isn't available in buster as
Debian currently ships MariaDB.

Could consider testing with default-mysql-server instead? Otherwise any
package is "allowed" to break your autopkgtest without it being noticed.

Paul

¹ https://ci.debian.net/packages/r/resource-agents/testing/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#903853: transition: removal of nepomuk support from src:kde4libs

[Pino Toscano]

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

Hi,

I'd like to remove the support for Nepomuk in src:kde4libs.

Since Nepomuk has been deprecated, and already unused in Debian for
quite some time, this allows us to drop src:soprano &
src:shared-desktop-ontologies. The result is the drop of 3 library
packages from src:kde4libs: libnepomuk4, libnepomukquery4a, and
libnepomukutils4.

The reason of this transition is that libnepomuk was so far listed as
public library dependency for the kde4 versions of kio (libkio5), and
kparts (libkparts4), resulting in overlinking. Fortunately, almost all
the packages either already link in as-needed more, or switched to KDE
Frameworks 5. The only exception is src:kpartsplugin.

Hence, the plan is the following:
1) upload src:kde4libs without Nepomuk support
2) binNMU src:kpartsplugin

I verified that src:kpartsplugin builds fine even without Nepomuk
libraries, effectively not linking against them anymore. I also did
a rebuild of all the other sources still using kdelibs 4.x, and there
were no changes in their build.

PS: since I uploaded kde4libs 4:4.14.38-1 yesterday, I'd wait for it to
migrate to testing, first.

Ben file:

title = "kde4libs without nepomuk";
is_affected = .depends ~ /\blibnepomuk/;
is_good = '';
is_bad = .depends ~ /\blibnepomuk/;

Thanks,
-- 
Pino

Bug#898741: hdparm 9.51+ds-1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: hdparm
Version: 9.51+ds-1+deb9u1

Explanation: only enable APM on disks that advertise it

Bug#903851: dbus does not automatically start after dist-upgrade system stretch with updates from buster

[thardman-TJH4]

Package: dbus
Version: 1.10.26-0+deb9u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

After `apt-get update ; apt-get dist-upgrade` system will not boot properly.
service dbus is never started, fails to boot to anything but recovery mode.

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

Booted to recovery mode via grub. Discovered problem, no /var/run/dbus
directory and thus no socket in that directory. Manually started with `service
dbus start`, checked for existence of /var/run/dbus and it is there now.
Continued boot from this point with 'systemctl default' and system completed
boot including oging ot SDDM display manager login screen.

   * What was the outcome of this action?

System is now usable if booted from Recovery mode and then continued to
"default" runlevels.

   * What outcome did you expect instead?

I expected the system to boot normally without having to start dbus manually
from Recovery mode.





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

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 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/bash
Init: systemd (via /run/systemd/system)

Versions of packages dbus depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libapparmor1 2.11.0-3+deb9u2
ii  libaudit11:2.6.7-2
ii  libc62.24-11+deb9u3
ii  libcap-ng0   0.7.7-3+b1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libexpat12.2.0-2+deb9u1
ii  libselinux1  2.6-3+b3
ii  libsystemd0  232-25+deb9u4
ii  lsb-base 9.20161125

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-user-session [default-dbus-session-bus]  1.10.26-0+deb9u1
ii  dbus-x11 [dbus-session-bus]   1.10.26-0+deb9u1

Versions of packages dbus is related to:
ii  dbus-x11  1.10.26-0+deb9u1
ii  systemd   232-25+deb9u4
ii  systemd-sysv  232-25+deb9u4

-- no debconf information

Bug#903389: glibc/2.27-4 appears to break unrar-free/1:0.0.1+cvs20140707-4 autopktest: different Valgrind status codes

[Paul Gevers]

Hi

On 10-07-18 14:30, Aurelien Jarno wrote:
> We already have many binaries built with -z separate-code in buster, so
> the best would be to add support for them in valgrind. I am therefore
> reaffecting the bug there. If it can't be done soon, the best would be to
> build binutils with --disable-separate-code.

There is a patch upstream now (the bug isn't closed yet, so probably not
committed).

> I think the issue should just be ignored from the CI point of view, it
> just happens that glibc is one of the many affected packages, the other
> haven't been caught before.

Sure. I have marked glibc as force-skiptest as this was the only
remaining itme. It should be considered for migration on the next
migration run.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#903821: [Pkg-xen-devel] Bug#903821: xen-hypervisor-4.8-amd64: Kernel Panic after upgrading to stretch 9.5 (linux-image-4.9.0-7-amd64)

[Hans van Kranenburg]

Hi,

On 07/15/2018 12:16 PM, Benoît Tonnerre wrote:
> [...]
> 
> After updating 3 Xen servers from stretch (9.4) to stretch (9.5), I
> notice a kernel panic on these 3 servers.

Thanks for the report.

This is probably all related:

This went into 4.9.102:
https://www.spinics.net/lists/kernel/msg2808364.html

This into 4.9.107:
https://www.spinics.net/lists/stable/msg242657.html

And this went into 4.9.112:
https://www.spinics.net/lists/stable/msg246729.html

Apparently kernels from 4.9.107 to 4.9.111 don't boot correctly.

Hans

Bug#903850: ITP: python-certbot-dns-ovh -- OVH plugin for Certbot

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: python-certbot-dns-ovh
  Version : 0.26.0
  Upstream Author : Electronic Frontier Foundation
* URL : https://certbot.eff.org
* License : Apache-2.0
  Programming Lang: Python 3
  Description : OVH plugin for Certbot

This package is a certbot plugin and will be maintained by the Debian Let's 
Encrypt Team.

Bug#903849: klibc rebuilt with toolchain from unstable crashes at startup on amd64

[Ben Hutchings]

Package: src:klibc
Version: 2.0.4-11
Severity: grave

Rebuilding the current version of klibc for amd64 adds a large amount
of padding to the .text and .rodata sections of klibc.so:

/lib/klibc-MiRPTuou9LIwcm_gDpcF7E1m-p8.so: file format elf64-x86-64

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text d1ff  00200200  00200200  0200  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata   31af  0030  0030  0010  2**5
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data.rel.ro  0990  00403660  00403660  00103660  2**5
  CONTENTS, ALLOC, LOAD, DATA
  3 .data 0140  00404000  00404000  00104000  2**5
  CONTENTS, ALLOC, LOAD, DATA
  4 .bss  42f8  00404140  00404140  00104140  2**5
  ALLOC

This results in an address conflict with all klibc binaries and an
immediate crash when klibc jumps to the start of the binary.

Other architectures might also be affected.

Ben.

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#903744: Issues blocking ledgersmb being upgraded to 1.6.x upstream version

[Robert J. Clay]

Control: block 903744 by 901739
Control: tag confirm

An issue delaying the upgrade of the ledgersmb package to the 1.6.x
series upstream version has been required Perl modules that are not
yet in Debian.
One that is still left is HTML::Escape [1] but that one (as it is
currently in upstream) in turn requires
Module::Build::Pluggable::PPPort [2] which is also not yet in Debian.
And that one in turn requires Module::Build::Pluggable [3] which is
also not in Debian.

-- 
Robert James Clay
rjc...@gmail.com, j...@rocasa.us
GPG ID: 2448 3AE0 874D 8696 6DCD ECF4 198C AB6F 43B7 EA9A
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901739
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901898
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901882

Bug#903821: 4.16 kernel

[Maxmédia Kft Szerviz]

Hi,

Thanks your report! I can start my system with 4.16 backport kernel.

Bug#903821: linux-image-4.9.0-7-amd64: Can not boot 4.9.0_7_amd64 with Xen

[Sebastien KOECHLIN]

Package: src:linux
Followup-For: Bug #903821

When booting with the new kernel, I got the following Dom0 crash:

Loading Xen 4.8-amd64 ...
Loading Linux 4.9.0-7-amd64 ...
Loading initial ramdisk ...
(XEN) Xen version 4.8.4-pre (Debian 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9) 
(ijack...@chiark.greenend.org.uk) (gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) 
debug=n  Fri Jun 22 15:50:19 UTC 2018
(XEN) Bootloader: GRUB 2.02~beta3-5
(XEN) Command line: placeholder dom0_mem=4096M,max:4096M com2=57600,8n1 
console=com2,vga
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 4 MBR signatures
(XEN)  Found 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 000a (usable)
(XEN)  0010 - 7faa (usable)
(XEN)  7faa - 7fab6000 (reserved)
(XEN)  7fab6000 - 7fad5c00 (ACPI data)
(XEN)  7fad5c00 - 8000 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - 0001 (reserved)
(XEN)  0001 - 00068000 (usable)
(XEN) ACPI: RSDP 000F23D0, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F245C, 00AC (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: FACP 7FAD34F8, 00F4 (r3 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: DSDT 7FAB6000, 3E0D (r1 DELL   PE_SC3  1 INTL 20050624)
(XEN) ACPI: FACS 7FAD5C00, 0040
(XEN) ACPI: APIC 7FAD3078, 008A (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SPCR 7FAD3104, 0050 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: HPET 7FAD3158, 0038 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: MCFG 7FAD3194, 003C (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: WD__ 7FAD31D4, 0134 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SLIC 7FAD330C, 0024 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: ERST 7FABBB88, 0210 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: HEST 7FABBD98, 027C (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: BERT 7FABBA08, 0030 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: EINJ 7FABBA38, 0150 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: TCPA 7FAD3490, 0064 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SSDT 7FAB9E0D, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
(XEN) ACPI: SSDT 7FABA4B3, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
(XEN) ACPI: SSDT 7FABAB59, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
(XEN) ACPI: SSDT 7FABB1FF, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
(XEN) ACPI: SSDT 7FABB8A5, 0162 (r1 DELL   PE_SC3 10 INTL 20050624)
(XEN) System RAM: 24570MB (25159936kB)
(XEN) Domain heap initialised
(XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23
(XEN) IOAPIC[1]: apic_id 5, version 32, address 0xfec1, GSI 256-279
(XEN) IOAPIC[2]: apic_id 6, version 32, address 0xfec1, GSI 64-87
(XEN) Enabling APIC mode:  Flat.  Using 3 I/O APICs
(XEN) Failed to get Error Log Address Range.
(XEN) xstate: size: 0x240 and states: 0x3
(XEN) Unrecognised CPU model 0x17 - assuming vulnerable to LazyFPU
(XEN) Speculative mitigation facilities:
(XEN)   Hardware features:
(XEN)   Compiled-in support: INDIRECT_THUNK
(XEN)   Xen settings: BTI-Thunk RETP(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) not detected
(XEN) Brought up 4 CPUs
(XEN) Dom0 has maximum 856 PIRQs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x1f66000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   00066a00->00066c00 (1035540 pages to be 
allocated)
(XEN)  Init. ramdisk: 00067ed14000->00067e7e
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 8100->81f66000
(XEN)  Init. ramdisk: ->
(XEN)  Phys-Mach map: 0080->00800080
(XEN)  Start info:81f66000->81f664b4
(XEN)  Page tables:   81f67000->81f7a000
(XEN)  Boot stack:81f7a000->81f7b000
(XEN)  TOTAL: 8000->8200
(XEN)  ENTRY ADDRESS: 81d3d180
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 

Bug#898741: stretch-pu: package hdparm/9.51+ds-1+deb9u1

[Adam D. Barratt]

Hi,

On Sun, 2018-07-15 at 18:35 +0200, Cyril Brulebois wrote:
> Adam D. Barratt  (2018-07-14):
> > I missed that hdparm builds a udeb, so CCing the d-i RM for
> > confirmation.
> > 
> > KiBi - hdparm is in the "could be handled by britney" list in
> > hints/freeze, which I think we'd previously agreed meant it didn't
> > need d-i sign-off, but I'm not 100% sure of that right now.
> 
> I think I really should have looked at organizing the lists better,
> but can't really do that now… So looking for a confirmation is
> appreciated.

No worries. It'd be good if we could work out how to not have to bother
you about packages that don't affect d-i at some point.

> Regarding hdparm specifically, I can't seem able to immediately find
> where its udeb is used, so I guess letting the change go through
> should be safe. ;)
> 

Thanks.

Regards,

Adam

Bug#902938: kerneloops-applet takes 100% of a core

[François Revol]

So,
I tried with other desktops, and it doesn't seem to happen.

Further more, it only seems to happen on the first login, not subsequent
ones.

I attached gdb to it, and it seems to keep trying to load the gtk2 settings.

It keeps running gtk_rc_reparse_all_for_settings.

Checking the fds, it seems to open and close the different theme files
sequentially, and redo all over.
revol@me:~$ gdb --pid=2893
GNU gdb (Debian 7.12-6+b2) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 2893
Reading symbols from /usr/bin/kerneloops-applet...(no debugging symbols 
found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libnotify.so.4...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2...(no 
debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libdbus-1.so.3...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0...(no debugging 
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug/.build-id/8f/d0a29758bf6615673836bb20ffdf11dcb531e6.debug...done.
done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libX11.so.6...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libXcomposite.so.1...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libXdamage.so.1...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libXfixes.so.3...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libcairo.so.2...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libfribidi.so.0...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libfontconfig.so.1...(no 
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libfreetype.so.6...(no debugging 
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...Reading symbols from 
/usr/lib/debug/.build-id/e3/24884789b56b585de13a1c80b7f155022ec267.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols 
from 
/usr/lib/debug/.build-id/26/b4971faeffb48a4dad6393856afbba73743fe2.debug...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/x86_64-linux-gnu/libsystemd.so.0...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libffi.so.6...(no debugging 
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libpcre.so.3...(no debugging symbols 
found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/90/56864907e4d74f113132f5a85b5952bc152de1.debug...done.
done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libpng16.so.16...(no debugging 
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...(no debugging symbols 
found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libselinux.so.1...(no debugging 
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libresolv.so.2...Reading 

Bug#903847: taglib: CVE-2018-11439: heap-based buffer over-read via a crafted audio file

[Salvatore Bonaccorso]

Source: taglib
Version: 1.11.1+dfsg.1-0.1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/taglib/taglib/issues/868

Hi,

The following vulnerability was published for taglib.

CVE-2018-11439[0]:
| The TagLib::Ogg::FLAC::File::scan function in oggflacfile.cpp in
| TagLib 1.11.1 allows remote attackers to cause information disclosure
| (heap-based buffer over-read) via a crafted audio file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-11439
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11439
[1] https://github.com/taglib/taglib/issues/868
[2] https://github.com/taglib/taglib/pull/869
[3] 
https://github.com/sgayou/taglib/commit/272648ccfcccae30e002ccf34a22e075dd477278

Regards,
Salvatore

Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype

[James Clarke]

On 15 Jul 2018, at 19:50, Ben Hutchings  wrote:
> 
> Control: tag -1 moreinfo
> 
> On Mon, 1 Jan 2018 22:59:59 + James Clarke  wrote:
> [...]
>> Please consider applying the patch forwarded upstream (linked in an
>> earlier control message) soon; this bug means that if the current
>> initramfs is updated, it will no longer boot, as run-init will segfault
>> in klibc. Given sparc64 is not a release architecture I can't make this
>> bug RC, otherwise I'd probably go for critical.
>> 
>> (To be clear, the issue is in 2.0.4-10 simply because that is the first
>> upload to happen since sparc64 has had PIE enabled by default in GCC)
> 
> How exactly did you test this patch?  It looks like it will cause
> pipe() to crash on success.  You put the first instruction of the PIC
> prologue into a branch delay slot, which overwrites the register
> holding the pointer used to store the system call return values.

I guess nothing I ran used pipe... but you're right, I was trying to be clever
with the branch delay slots (taking into account that some them already
clobbered %g4 for a position-dependent errno address calculation) and hadn't
noticed that pipe was using %g4 as a "caller"-saved register (it's clobbered by
userspace calls...). I shall put the nops back in and somehow give it a proper
test.

James

Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 1 Jan 2018 22:59:59 + James Clarke  wrote:
[...]
> Please consider applying the patch forwarded upstream (linked in an
> earlier control message) soon; this bug means that if the current
> initramfs is updated, it will no longer boot, as run-init will segfault
> in klibc. Given sparc64 is not a release architecture I can't make this
> bug RC, otherwise I'd probably go for critical.
> 
> (To be clear, the issue is in 2.0.4-10 simply because that is the first
> upload to happen since sparc64 has had PIE enabled by default in GCC)

How exactly did you test this patch?  It looks like it will cause
pipe() to crash on success.  You put the first instruction of the PIC
prologue into a branch delay slot, which overwrites the register
holding the pointer used to store the system call return values.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.



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

Bug#903800: Confirming same problem as Dom0 or DomU

[Jered Floyd]

I'm seeing the same behavior; this kernel cannot be used as a Dom0 or DomU 
kernel on xen-hypervisor-4.8-amd64. 

So glad for remote IPMI KVM... that was almost a disaster. 

--Jered 

Bug#866308: qtkeychain 0.8 fails to use kwallet5

[Dino Hüllmann]

Since libqtkeychain1 is built without libsecret, applications depending 
on libqt5keychain1 fail to load passwords on Gnome-based systems now. 
For example, the ownCloud client asks for the password on startup (see 
https://github.com/frankosterfeld/qtkeychain/issues/99). Installing 
libgnome-keyring is not an option since it is replaced by libsecret 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892359).

Bug#903846: adasockets: please rebuild with gcc-8

[Nicolas Boulenguez]

Source: adasockets
Version: 1.10.1-1
Severity: minor
Tags: patch

Hello.
Please consider the attached patch, motivated by
https://lists.debian.org/debian-ada/2018/05/msg4.html.
It also packages latest upstream release,
and most probably closes: #903324.
Thanks.
diff --git a/debian/changelog b/debian/changelog
index cf0d828..56b1f0e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+adasockets (1.11.1-0.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version, built with gcc-8.
+Rename shared library and -dev package per Debian Ada policy.
+  * Drop trailing white spaces in this changelog.
+  * Debhelper 11. Staging directory is now implicit.
+Really install debian/README.Debian.
+  * Standards-Version: 4.1.5. Drop obsolete dependencies.
+  * Let autopkgtest produce more debugging information.
+
+ -- Nicolas Boulenguez   Sun, 15 Jul 2018 20:23:02 +0200
+
 adasockets (1.10.1-1) unstable; urgency=medium
 
   * Acknowledge NMUs 1.9-1.1 and 1.10.1-0.1.  Thank you, Nicolas.
@@ -115,7 +128,7 @@ adasockets (1.8.6-3) unstable; urgency=low
 * New shared library file name libadasockets.so.2.0.0.
 * Modified soname in configure/configure.ac.
 (Closes: #562872).
-  * Change architecture to any (to match gnat-4.4). 
+  * Change architecture to any (to match gnat-4.4).
 (Closes: #568433, #542409).
   * Bump standards version to 3.8.4.
   * Add ${misc:Depends} to Depends.
@@ -131,7 +144,7 @@ adasockets (1.8.6-2) unstable; urgency=low
 
   * Bump gnat version to 4.3.
   * Add mips and mipsel architectures.
-  * Depend on texlive instead of tetex-bin.	
+  * Depend on texlive instead of tetex-bin.
   * Bump standards version to 3.8.0.
 
  -- Phil Brooke   Fri, 18 Jul 2008 07:31:54 +0100
@@ -178,7 +191,7 @@ adasockets (1.8.4.7-4) unstable; urgency=medium
   * Assorted suggestions from Ludovic Brenta (thanks!):
   * libadasockets-dev: .ads and .adb files are now in
 /usr/share/ada/adainclude/adasockets.
-  * libadasockets-dev: .ali files are now in 
+  * libadasockets-dev: .ali files are now in
 /usr/lib/ada/adalib/adasockets.
   * adasockets-config.in also modified.  Will not remove this file
 as requested by bug 383434 because it might be useful to users still.
@@ -229,7 +242,7 @@ adasockets (1.8.4.4-1) unstable; urgency=low
 
   * New upstream release.
   * Refreshed the debian/orig directory.
-  * Added texinfo package to build depends so that `makeinfo' is available 
+  * Added texinfo package to build depends so that `makeinfo' is available
 (closes: #253703).
 
  -- Phil Brooke   Sat, 26 Jun 2004 16:31:30 +0100
@@ -278,7 +291,7 @@ adasockets (1.7-1) unstable; urgency=low
 
   * New upstream release.
   * libadasockets0-dev package now in section libdevel.
-  * Working around dpkg-source's objections to doc/adasockets.pdf being 
+  * Working around dpkg-source's objections to doc/adasockets.pdf being
 regenerated.
 
  -- Phil Brooke   Wed,  6 Aug 2003 23:26:07 +0100
diff --git a/debian/compat b/debian/compat
index f599e28..b4de394 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-10
+11
diff --git a/debian/control b/debian/control
index 5cd6771..eb52ee4 100644
--- a/debian/control
+++ b/debian/control
@@ -2,21 +2,20 @@ Source: adasockets
 Maintainer: Phil Brooke 
 Section: devel
 Priority: optional
-Standards-Version: 4.1.0
+Standards-Version: 4.1.5
+Rules-Requires-Root: no
 Build-Depends:
- gnat, gnat-7,
+ gnat, gnat-8,
 # Note: debian/rules reads this lines to find gnat_version.
- debhelper (>= 10),
+ debhelper (>= 11),
  texinfo, texlive,
- dpkg-dev (>= 1.16.1),
-# providing /usr/share/dpkg/default.mk
  autogen
 # see doc/Makefile.am
 Homepage: https://www.rfc1149.net/devel/adasockets.html
 
-Package: libadasockets7-dev
+Package: libadasockets8-dev
 Architecture: any
-Depends: gnat, gnat-7, libadasockets7 (=${binary:Version}), ${misc:Depends}, dpkg (>= 1.15.4) | install-info
+Depends: gnat, gnat-8, libadasockets8 (=${binary:Version}), ${misc:Depends}
 Section: libdevel
 Description: bindings for socket services in Ada: development files
  This package provides a binding for socket services to be used with GNAT
@@ -26,7 +25,7 @@ Description: bindings for socket services in Ada: development files
  This package provides the Ada programmer with headers and libraries used
  to build Ada programs that use sockets services.
 
-Package: libadasockets7
+Package: libadasockets8
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
diff --git a/debian/copyright b/debian/copyright
index a9cb480..ae90e62 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -3,12 +3,12 @@ Upstream-Name: AdaSockets
 Source: https://github.com/samueltardieu/adasockets
 
 Files: *
-Copyright: 1998-2016 Samuel Tardieu 
+Copyright: 1998-2017 Samuel Tardieu 
1999-2003 ENST http://www.enst.fr/
 License: GPL-2+-with-generic-exception
 
 Files: doc/*
-Copyright: 2002-2013 Samuel Tardieu 

Bug#903842: anbox: Please also package anbox-modules-dkms

[Shengjing Zhu]

Control: tags -1 wontfix

On Mon, Jul 16, 2018 at 2:03 AM Marcel Partap  wrote:
>
> Package: anbox
> Version: 0.0~git20180709-1
> Severity: normal
>
> The recent uptake in anbox dev actitivy is very exciting, THANKS for packaging
> the program!
> Now, running on a Liquorix-kernel, I do not have the android kernel modules
> required and would appreciate availability of a anbox-modules dkms package : )
>

No, we won't package this. Please read /usr/share/doc/anbox/README.Debian first.
In short, we have built these modules in-tree since kernel 4.17.3.
Please wait sometime for this kernel version entering testing and
becoming the default one. You're still able to manually install it
from unstable.

-- 
Best regards,
Shengjing Zhu

Bug#903845: RFS: lv2bm/1.0-1 [ITP] -- LV2 audio plugin tester with uses in autopktest

[Víctor Cuadrado Juan]

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

  I am looking for a sponsor for my package "lv2bm":

 * Package name: lv2bm
   Version : 1.0-1
   Upstream Author : 2014-2018 Ricardo Crudo 
 2015 Filipe Coelho 
 * URL : https://github.com/moddevices/lv2bm
 * License : GPL-2+, GPL-3+
   Section : devel

  It builds those binary packages:

lv2bm - friendly greeter

Description: Benchmark CLI tool for LV2 plugins
 Features:
  - Allows one to select which LV2 URIs to test
  - Uses minimum, maximum and default control values to run the plugins
  - Has a full test mode which check all combinations for discrete controls
  - Can be used along with valgrind to detect plugin memory issues

In addition to shipping /usr/bin/lv2bm, the package also ships
/usr/bin/lv2-plugin_autopkgtest, a script that uses lv2bm to smoke-test
installed LV2 plugins.

  I intend to maintain this package under the Debian Multimedia Team umbrella,
  and use it for automating lv2 plugin's autopkgtests.

  I have uploaded the source code under the Multimedia Team in salsa:
  https://salsa.debian.org/multimedia-team/lv2bm


Kind regards,
Víctor Cuadrado Juan


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

Kernel: Linux 4.16.0-2-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)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAltLj/QACgkQIj8Vylqv
DnhGpAgAj+7XCPqf1zsHohneeh18g/48mDGXI2vnzbWaRB+ZtXIA/4+1qJ/1VVlH
9ahEg7E5ci39ONg2HISJKb8ebqFqY+zCDPdLF425Vg0jK1WAzvlGm9U4k0s+kG+b
RI0vHQQzTHfp7JWzdX7Tx0mmDhoaT5mIu8xJsSb7v/Ss+DGrkJ+HcaVnN0K4iVdp
xgVXYKnobMw56ZLe9NjPPcRIxnydQesUGtq475SeMSPsZhA2aQ3RNZxTeqVzA6Pu
c6j9unPypf9XcA1hm2YybrihmHR9SALPlEpyZeJE2pKFFAdOnLflQYKwgL8i+lQi
Jc4NOcErNgK7KDVxRHPLKbgIll66dQ==
=lF0W
-END PGP SIGNATURE-

Bug#903844: RFS: smpq/1.6-2

[Pali Rohár]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: smpq
   Version : 1.6-2
   Upstream Author : Pali Rohár 
 * URL : https://launchpad.net/smpq
 * License : GPL-3+
   Section : utils

It builds those binary packages:

  smpq  - StormLib MPQ archiving utility

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/s/smpq/smpq_1.6-2.dsc

More information about smpq can be obtained from https://launchpad.net/smpq.

Changes since the last upload:

 * Update Standards-Version to 4.1.5
 * Update to debhelper 11
 * Update watch and signing-key.asc
 * Enable LFS support
 * Use https links in copyright
 * Drop KDE4 package kio-smpq (Closes: #875182)


Regards,
 Pali Rohár


signature.asc
Description: PGP signature

Bug#903843: adacgi: please rebuild with gcc-8

[Nicolas Boulenguez]

Source: adacgi
Version: 1.6-20
Severity: minor
Tags: patch

Hello.
Please consider the attached changes, motivated by
https://lists.debian.org/debian-ada/2018/05/msg4.html.
Thanks.


adacgi.tar.gz
Description: application/gzip

Bug#903842: anbox: Please also package anbox-modules-dkms

[Marcel Partap]

Package: anbox
Version: 0.0~git20180709-1
Severity: normal

The recent uptake in anbox dev actitivy is very exciting, THANKS for packaging
the program!
Now, running on a Liquorix-kernel, I do not have the android kernel modules
required and would appreciate availability of a anbox-modules dkms package : )



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

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

Versions of packages anbox depends on:
ii  iptables1.6.2-1
ii  libboost-atomic1.62.0   1.62.0+dfsg-5+b2
ii  libboost-chrono1.62.0   1.62.0+dfsg-5+b2
ii  libboost-date-time1.62.01.62.0+dfsg-5+b2
ii  libboost-filesystem1.62.0   1.62.0+dfsg-5+b2
ii  libboost-iostreams1.62.01.62.0+dfsg-5+b2
ii  libboost-log1.62.0  1.62.0+dfsg-7
ii  libboost-program-options1.62.0  1.62.0+dfsg-5+b2
ii  libboost-regex1.62.01.62.0+dfsg-7
ii  libboost-serialization1.62.01.62.0+dfsg-7
ii  libboost-system1.62.0   1.62.0+dfsg-5+b2
ii  libboost-thread1.62.0   1.62.0+dfsg-5+b2
ii  libc6   2.27-3
ii  libegl1 1.0.0+git20180308-2
ii  libgcc1 1:8.1.0-3
ii  libgles21.0.0+git20180308-2
ii  liblxc1 1:2.0.9-6
ii  libprotobuf-lite10  3.0.0-9.1
ii  libsdl2-2.0-0   2.0.8+dfsg1-1
ii  libsdl2-image-2.0-0 2.0.3+dfsg1-1
ii  libstdc++6  8.1.0-3
ii  libsystemd0 238-4
ii  lxc 1:2.0.9-6

Versions of packages anbox recommends:
ii  dbus-user-session  1.12.8-2

anbox suggests no packages.

-- no debconf information

Bug#903841: adabrowse: please rebuild with gnat-8

[Nicolas Boulenguez]

Package: adabrowse
Version: 4.0.3-8
Severity: minor
Tags: patch

Hello.
Adabrowse requires an update to complete the gnat transition.
Please review, test and apply the attached suggestions.
Thanks.


adabrowse.tar.gz
Description: application/gzip

Bug#903839: use tar feature to always turn on root-owner-group option

[thomas]

After sending this bug I realized that it might not be possible to restrict 
dpkg-deb to only the users and groups defined by base-passwd since there might 
be derivatives (or organizations) with additional reserved users and groups.

Thus I'm closing this again. Sorry for the noise.

Bug#903840: nslcd unattentded upgrade fails/hangs at unter URI path

[Matt Weatherford]

Package: nslcd
Version: 0.9.7-2+deb9u1
Severity: normal

Dear Maintainer,

First and foremost, thank you for your contributions to Debian and for 
supporting the nslcd
package which we use every single day - very much appreciated.

I went to upgrade my debian 9 system today and got a prompt at the nslcd 
upgrade to enter the
uri path.  I entered this and the upgrade hung.  I am running upgrades over ssh 
sessions in non-interactive
mode and wonder if there is something about this upgrade that is breaking the 
script nslcd is running.

I suspect this is a minor detail.

It seems the new script is parsing the nslcd.conf file and making changes and / 
or normalizing things.
Is there a changelog that I can review to better understand what is happening 
here?

What additional info would be helpful to you that I can gather?

thanks,  Matt



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

Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/16 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 nslcd depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u2
ii  lsb-base   9.20161125

Versions of packages nslcd recommends:
ii  bind9-host [host]   1:9.10.3.dfsg.P4-12.3+deb9u4
ii  ca-certificates 20161130+nmu1+deb9u1
ii  ldap-utils  2.4.44+dfsg-5+deb9u2
ii  libnss-ldapd [libnss-ldap]  0.9.7-2+deb9u1
ii  libpam-krb5 4.7-4
ii  libpam-ldapd [libpam-ldap]  0.9.7-2+deb9u1
ii  nscd2.24-11+deb9u3
ii  nslcd-utils 0.9.7-2+deb9u1

Versions of packages nslcd suggests:
pn  kstart  

-- debconf information:
  nslcd/ldap-cacertfile: /etc/ssl/ldi/InCommonCA.crt
  nslcd/restart-services:
  nslcd/xdm-needs-restart:
  nslcd/ldap-auth-type: SASL
  nslcd/ldap-sasl-secprops:
  nslcd/restart-failed:
* nslcd/ldap-reqcert: never
  nslcd/ldap-binddn:
  nslcd/ldap-starttls: true
  libraries/restart-without-asking: false
  nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
  nslcd/ldap-sasl-mech: EXTERNAL
* nslcd/ldap-uris: ldap://ldi.s.uw.edu
  nslcd/ldap-sasl-authcid:
* nslcd/ldap-base:
  nslcd/disable-screensaver:
  nslcd/ldap-sasl-authzid:
  nslcd/ldap-sasl-realm:

Bug#903811: ocrmypdf: autopkgtest regression: missing versioned depends?

[Sean Whitton]

Hello,

On Sun 15 Jul 2018 at 08:10AM +0200, Paul Gevers wrote:

> With the upload of version 6.2.2-1 your package started to fail its
> autopgktest in testing, however it passes in unstable. I copied the
> output below.
>
> Could you please investigate? I noticed in the changelog/BTS that you
> need python3-ruffus 2.7 but I don't see that in the (build-)
> dependencies, did you loosen it too much? Currently this regression is
> delaying the migration to testing by 13 days.

Indeed, we need 2.7, because this version removed the workaround for
python3-ruffus <=2.7.

Uploading a version with tighter bounds now.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#903807: deb-systemd-helper purge breaks services duplicated between conflicting packages

[Michael Biebl]

Am 15.07.2018 um 18:14 schrieb Richard Laager:
> On 07/15/2018 04:22 AM, Michael Biebl wrote:
>> Fwiw, I think it would be better if ntpsec and ntp would not use the
>> same service file name and if ntpsec would use ntpsec.service instead.
> 
> Are you willing to explain your reasoning? Specifically, is it because
> of these issues, or would you take the same position even if everything
> worked perfectly already?

This is mostly unrelated to this issue.
I just find it confusing to have the service named the same although
it's a different piece of software (in this case a fork).

Imagine if rsyslog (which was originally a fork of sysklogd) kept the
name of the init script as /etc/init.d/sysklogd. Wouldn't you find that
confusing as well?

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#903839: use tar feature to always turn on root-owner-group option

[Thomas Koch]

Package: dpkg
Version: 1.19.0.5
Severity: minor
Tags: newcomer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The dpkg-deb command learned the option --root-owner-group in [1][2]. I
believe this option can be safely removed and turned on by default.

[1] https://bugs.debian.org/291320 dpkg-deb: New --build --owner=root option to 
avoid fakeroot
[2] 
https://salsa.debian.org/dpkg-team/dpkg/commit/2436807c87b033a1ea25164d3b951cd559084a5a

The tar command has the options --owner-map and --group-map which can be used
to except owners and groups from being converted to root:root by the --owner
and --group options.

I produced a list of owners and groups used by packages found by lintian:

$ w3m -dump 
https://lintian.debian.org/tags/should-specify-rules-requires-root.html \
  | egrep "\([^:]+:[^:]+\)" \
  | cut -d \( -f 2 \
  | sort -u

All owners and groups are reserved by base-passwd. It should therefor be save
to call tar for data.tar unconditionally with

- --owner root --group root
- --owner-map reserved-owners
- --group-map reserved-groups

assuming that reserved-* contains mapping of all reserved owners and groups to
themselves.

Please let me know if you think this is a good idea and worth crafting a
patch.

related: #884999 debhelper: Please default Rules-Require-Root to no

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAltLe8cACgkQB/xIkQQr
plq4HRAA4Yt1CdNyVYzMBABgMAvWzuW5aUltUZNInh7v26GDriT6BI2A24Cj6oqe
7uc0taf9iqilkT4oxg08kwM1hGt/T5CcOf72WZ7BeKArC9CjBjyxTLe4UWVn+oB1
LRORyKBP6i9Lx3hagjkQd8vfSEH4I2j21+ddRiIhnRIRo2629mpz2MU9qir+0bwj
xat8Vm2jArPc3DBFY8TVBZTne/OStaiYA26I5JLQUNFjgAOer3wBrJkPXPZKB8jI
Isnha0QlmUbGGkI/LuOnm9duDiZqKMqnwbukxMf+BOLJEmrljPkt1NFPf5iU/ddq
yD+xtsOeIr7aRyC5QFoMNbJJVUj5g7n6Q25rteaCmpzTWPVGpnsAMblop9qWNa9Q
mWtoFKA/DWnHp2u1qy/kcmXfYcjp+3y8sA/OZMA6sI6XLucY9TvRopjAFfEa1H2p
wS0Qpt+qR2D6oivRYVHIr1KFi8roDkCIk8NOkrTfAbONVeZnaIcsWKEsdz117bIs
TnEms6yJu828/TkQP1uE+nOXInaGNFxp4LZJpQgF5mSR4Pe2ZLiejnvQNRvNBZnr
/KY6IR684DmolRG4SjiTxz25nftb4cxTRV2YBuZZ1etX50Hz3n9PapAl5OIvq1Ga
AnnPeY+Qte2+XtdMIDXBhdMwWlsGl1veae+2ikJYK0JoB3Us59w=
=eHdt
-END PGP SIGNATURE-

Bug#898741: stretch-pu: package hdparm/9.51+ds-1+deb9u1

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2018-07-14):
> I missed that hdparm builds a udeb, so CCing the d-i RM for
> confirmation.
> 
> KiBi - hdparm is in the "could be handled by britney" list in
> hints/freeze, which I think we'd previously agreed meant it didn't
> need d-i sign-off, but I'm not 100% sure of that right now.

I think I really should have looked at organizing the lists better, but
can't really do that now… So looking for a confirmation is appreciated.

Regarding hdparm specifically, I can't seem able to immediately find
where its udeb is used, so I guess letting the change go through should
be safe. ;)


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


signature.asc
Description: PGP signature

Bug#903800: linux-image-4.9.0-7-amd64: general protection fault / kernel panic at boot

[Gianluigi Tiesi]

Source: linux
Version: 4.9.110-1
Followup-For: Bug #903800

I have same problems but on dum0, server reboots forever, by adding
no reboot the screen goes black just after the hypervisor loads (instead of
reboot)

This happens on i7-2600 and i7-4770

4.9.0-6 worked fine

I've also upgraded bios but same results



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

Kernel: Linux 4.9.0-7-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

Bug#903807: deb-systemd-helper purge breaks services duplicated between conflicting packages

[Richard Laager]

On 07/15/2018 04:22 AM, Michael Biebl wrote:
> Fwiw, I think it would be better if ntpsec and ntp would not use the
> same service file name and if ntpsec would use ntpsec.service instead.

Are you willing to explain your reasoning? Specifically, is it because
of these issues, or would you take the same position even if everything
worked perfectly already?

My reasoning is as follows: ntpsec's upstreams is a fork of ntp's
upstream. The ntpsec package is a drop-in replacement for the ntp
package. I think it's best for the users to keep things as similar as
possible. That's why I used "ntp" for the service names.

This bug is essentially the same as 680293, except that update-rc.d is
already documented to do what I want (just not actually doing it). Do
you feel both bugs should be closed (this one as wontfix and 680293
fixed by changing the documentation to match the behavior) or do you
have a reason that update-rc.d and deb-systemd-helper should behave
differently in this regard?

-- 
Richard