Bug#885165: ITP: node-cidr-regex -- Regular expression for matching IP addresses in CIDR notation

[Pirate Praveen]

On തിങ്കള്‍ 25 ഡിസംബര്‍ 2017 06:06 വൈകു, Hemant Yadav wrote:
> * Package name    : node-cidr-regex

Since this package is very small, I'm embedding it inside node-is-cidr
(which we actully need for npm 5.x).



signature.asc
Description: OpenPGP digital signature

Bug#887346: python3-pytest-capturelog: Long description broken

[Andreas Beckmann]

Control: tag -1 moreinfo

On Mon, 15 Jan 2018 11:39:31 +0100 Matthias Urlichs
 wrote:
> Package: python3-pytest-capturelog
> Version: 0.7-2

There is no such package in Debian.
Did you get it from another source?
Did you mean a different package?

The closes match I could find is python3-pytest-catchlog, but that has a
different version ...


Andreas

Bug#888236: torbrowser-launcher: broken by Tor Browser 7.5: No such file or directory: '.../Docs/sources/versions'

[intrigeri]

Antoine Beaupre:
> This bug makes torbrowser-launcher completely unusable on Debian
> stretch, as soon as the browser is updated (as it should).

> What's expected from stable users here? Is there going to be a stable
> update for this?

torbrowser-launcher is not included in Debian Stretch.

Cheers,
-- 
intrigeri

Bug#888813: ITP: micro -- a modern and intuitive terminal-based text editor

[Raju Devidas]

Package: wnpp
Severity: wishlist
Owner: Raju Devidas 
X-Debbugs-CC: debian-de...@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org,
pkg-lua-de...@lists.alioth.debian.org

* Package name    : micro
  Version : 1.4.0
  Upstream Author : Zachary Yedidia 
* URL : https://github.com/zyedidia/micro
* License : Expat
  Programming Lang: Go, Lua and others  
  Description : A modern and intuitive terminal-based text editor

 Micro is a terminal-based text editor that aims to be easy to use and
 intuitive, while also taking advantage of the full capabilities of
 modern terminals. As the name indicates, micro aims to be somewhat of
 a successor to the nano editor by being easy to install and use.

Bug#712394: lintian: Warn if override_dh_auto_test target doesn't check for DEB_BUILD_OPTIONS=nocheck

[Chris Lamb]

Hi Mattia,

> This is going to trigger tons of false positives for packages doing
> something like:
> 
> override_dh_auto_test:
> FOO=bar dh_auto_test
> -rm -f file-containing-test-output

Thanks. I've incorporated your idea in:

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

… and lowered the severity here:

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

We might just end up reverting the whole thing, naturally, but let's see
how we go for now...


Regards,

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

Bug#773562: lintian: Detect non-free and contrib packages without a Disclaimer in debian/copyright

[Chris Lamb]

tags 773562 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#664520: lintian: Unusual documentation package name, foo-docs

[Chris Lamb]

tags 664520 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#539326: lintian: Detect upstream examples not shipped by the package

[Chris Lamb]

tags 539326 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#888812: KeepassX is an adandoned project and should be removed from debian

[wei hong]

Package: keepassx
Version: 2.0.3-1
Severity: grave
Tags: security, stable, stretch, testing, buster, unstable, sid

https://github.com/keepassx/keepassx/pull/204

Users can move to keepassxc.

Bug#888811: dnscrypt-proxy: upstream gone, new package

[Brian Clinkenbeard]

Source: dnscrypt-proxy
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Old upstream is abandoned, new package can be found here by original upstream: 
https://github.com/jedisct1/dnscrypt-proxy/

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

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

Bug#888810: transmission-daemon: New rpc-host-whitelist does not persist

[Vincent Bernat]

Package: transmission-daemon
Version: 2.92-2+deb9u1
Severity: normal

Hey!

The new rpc-host-whitelist setting does not persist accross restart.
Transmission likes to rewrite its configuration file. When it happens
(on stop notably), the rpc-host-whitelist is written with an empty value
instead of the configured value.

To reproduce:

 - put a value for rpc-host-whitelist
 - stop transmission-daemon
 - check the value has disappeared

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

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

Versions of packages transmission-daemon depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libcurl3-gnutls  7.52.1-5+deb9u4
ii  libevent-2.0-5   2.0.21-stable-3
ii  libminiupnpc10   1.9.20140610-4
ii  libnatpmp1   20110808-4+b1
ii  libssl1.11.1.0f-3+deb9u1
ii  libsystemd0  232-25+deb9u1
ii  lsb-base 9.20161125
ii  transmission-common  2.92-2+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages transmission-daemon recommends:
ii  transmission-cli  2.92-2+deb9u1

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/transmission-daemon/settings.json [Errno 13] Permission denied: 
'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#888809: lintian: VCS URLs and salsa.d.o

[Paul Wise]

Package: lintian
Version: 2.5.72
Severity: wishlist

Recent git versions give a warning when redirecting URLs. Salsa redirects git 
to URLs ending in ".git/" and redirects browsers to the
URL not ending in ".git/" or ".git".

Accordingly, the Vcs-Git field should end in ".git" or ".git/" and the
Vcs-Browser field should not end in ".git" or ".git/".

In addition the salsa web interface prints URLs ending in ".git" rather
than URLs ending in ".git/" so the former should be preferred in any
lintian output.

I have no idea how salsa deals with repository names that end in
".git", but I guess git URLs will be something like ".../foo.git.git".

$ git clone https://salsa.debian.org/debian/wiki.debian.org ; rm -rf 
wiki.debian.org
Cloning into 'wiki.debian.org'...
warning: redirecting to https://salsa.debian.org/debian/wiki.debian.org.git/
remote: Counting objects: 1351, done.
remote: Compressing objects: 100% (553/553), done.
remote: Total 1351 (delta 721), reused 1340 (delta 717)
Receiving objects: 100% (1351/1351), 195.20 KiB | 112.00 KiB/s, done.
Resolving deltas: 100% (721/721), done.

$ git clone https://salsa.debian.org/debian/wiki.debian.org.git ; rm -rf 
wiki.debian.org
Cloning into 'wiki.debian.org'...
remote: Counting objects: 1351, done.
remote: Compressing objects: 100% (553/553), done.
remote: Total 1351 (delta 721), reused 1340 (delta 717)
Receiving objects: 100% (1351/1351), 195.20 KiB | 164.00 KiB/s, done.
Resolving deltas: 100% (721/721), done.

$ wget https://salsa.debian.org/debian/wiki.debian.org.git ; rm -f 
wiki.debian.org*
--2018-01-30 14:27:34--  https://salsa.debian.org/debian/wiki.debian.org.git
Resolving salsa.debian.org (salsa.debian.org)... 209.87.16.44, 
2607:f8f0:614:1::1274:44
Connecting to salsa.debian.org (salsa.debian.org)|209.87.16.44|:443... 
connected.
HTTP request sent, awaiting response... 302 Found
Location: https://salsa.debian.org/debian/wiki.debian.org [following]
--2018-01-30 14:27:36--  https://salsa.debian.org/debian/wiki.debian.org
Reusing existing connection to salsa.debian.org:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘wiki.debian.org.git’

wiki.debian.org.git[  <=>   
  ]  28.97K 
  103KB/sin 0.3s

2018-01-30 14:27:36 (103 KB/s) - ‘wiki.debian.org.git’ saved [29668]

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Carsten Schoenert]

Hello Guido,

On Mon, Jan 29, 2018 at 01:02:30PM +0100, Guido Günther wrote:
> > If possible gbp could become a at least a option for setting up the
> > number of threads the xz commend will use as long pristine-tar isn't
> > working properly with all kinds xz archives?
> 
> We should not do more options. Multi threaded should be on when:
> 
>   - not using pristine-tar
>   - iff pristine-tar can handle it
> 
> The first one is simple but what about the second?

I agree on not adding more options and put the build/create metrics into
gbp's internal logic.

I was also thinking about a useful co-exitence between gbp and
pristine-tar as it's pointless to add functionality of multi-threaded xz
archive creation into gbp but pristine-tar can't care such tarballs
correctly.
I'm not fully sure how to proceed here, as it's currently more a problem
of pristine-tar I think (given the timespan #869191 is opened). #869191
should be tagged to affect this report firstly?

Regards
Carsten

Bug#888808: gnome-calculator: black rectangle

[Yasushi SHOJI]

Package: gnome-calculator
Version: 3.26.0-3+b1
Severity: normal

Dear Maintainer,

GNOME Calculator 3.26.0-3+b1 gets a black rectangle at very left in the
input box after the last update.

Adding a small screenshot.


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages gnome-calculator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  libatk1.0-0  2.26.1-3
ii  libc62.26-6
ii  libcairo-gobject21.15.8-3
ii  libcairo21.15.8-3
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-2
ii  libgmp10 2:6.1.2+dfsg-2
ii  libgtk-3-0   3.22.26-2
ii  libgtksourceview-3.0-1   3.24.6-1
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.0-5
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libsoup2.4-1 2.60.3-1
ii  libxml2  2.9.4+dfsg1-6.1

Versions of packages gnome-calculator recommends:
ii  gvfs  1.34.1-2
ii  yelp  3.26.0-2

gnome-calculator suggests no packages.

-- no debconf information

Bug#888745: fixed

[Christian Ehrhardt]

ok, 1.3.7.8-2 really fixes it - I was issing that due to the long test queues.
Closing this bug now.

Bug#888807: RFS: qstardict/1.3-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: rodin.alexan...@gmail.com

Dear mentors,

I am looking for a sponsor for the package "qstardict".

I am neither this package's maintainer nor uploader (yet), but I will
be in the uploaders list (co-maintainer)
with the original maintainer's (who's also acting as qstardict's
upstream) approval in a private mail.

 * Package name: qstardict
   Version : 1.3-1
   Upstream Author : Alexander Rodin 
 * URL : https://github.com/a-rodin/qstardict
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

qstardict  - International dictionary written using Qt

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/q/qstardict/qstardict_1.3-1.dsc

  Git packaging repository on Salsa:

  https://salsa.debian.org/debian/qstardict

  Changes since the last upload:

qstardict (1.3-1) unstable; urgency=medium

  * Sponsored upload with original maintainer's approval.
  * Add myself into uploaders list.
  * New upstream release. (2018-01-24) Closes: #528257
+ Ported to Qt5. Closes: #875145
  * Switch to 3.0 (quilt) packaging format.
  * Bump debhelper compat level 5 -> 11.
+ Use dh sequencer.
  * Bump Standards-Version 3.8.0 -> 4.1.3.
  * Drop d/menu and d/qstardict.xpm files in favor of .desktop file.
  * Point d/watch file to GitHub releases.
  * Refresh d/qstardict.1 manpage and install it properly.
  * Rewrite d/copyright with machine-readable format.

 -- Boyuan Yang <073p...@gmail.com>  Tue, 30 Jan 2018 12:53:37 +0800

Also CC-ing the original maintainer here.


Regards,
Boyuan Yang

Bug#888806: pidgin: Please add xmpp-receipts plugin

[Tianming Xie]

Package: pidgin
Version: 2.12.0-1+b1
Severity: wishlist

Dear Maintainer,


Several other xmpp clients natively support XEP-0184, and there has been a
thread discussing it officially: https://developer.pidgin.im/ticket/6940

Currently, several other distributions have already included this plugin,
(e.g. https://www.archlinux.org/packages/community/x86_64/pidgin-xmpp-receipts/
,
https://packages.gentoo.org/packages/x11-plugins/pidgin-xmpp-receipts ,
https://software.opensuse.org/package/pidgin-xmpp-receipts ) while debian and
its descendants not.

XEP-0184 is very useful to detect loss of synchronization when combined with
OTR, for a receipt is not generated if the corresponding message is not
successfully decrypted.

There already is a wish #760451 to add this plugin to pidgin-plugin-pack, but
since it implements a low level feature of XMPP, may it be appropriate to be
bundled with pidgin executable, just as xmppconsole and xmppdisco?



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

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

Versions of packages pidgin depends on:
ii  libatk1.0-0 2.26.1-3
ii  libc6   2.26-4
ii  libcairo2   1.15.8-3
ii  libdbus-1-3 1.12.2-1
ii  libdbus-glib-1-20.108-3
ii  libfontconfig1  2.12.6-0.1
ii  libfreetype62.8.1-1
ii  libgadu31:1.12.2-3
ii  libgdk-pixbuf2.0-0  2.36.11-1
ii  libglib2.0-02.54.3-2
ii  libgstreamer1.0-0   1.12.4-1
ii  libgtk2.0-0 2.24.32-1
ii  libgtkspell02.0.16-1.1
ii  libice6 2:1.0.9-2
ii  libpango-1.0-0  1.40.14-1
ii  libpangocairo-1.0-0 1.40.14-1
ii  libpangoft2-1.0-0   1.40.14-1
ii  libpurple0  2.12.0-1+b1
ii  libsm6  2:1.2.2-1+b3
ii  libx11-62:1.6.4-3
ii  libxss1 1:1.2.2-1+b2
ii  perl-base [perlapi-5.26.0]  5.26.1-4
ii  pidgin-data 2.12.0-1

Versions of packages pidgin recommends:
ii  gstreamer1.0-libav 1.12.4-1
ii  gstreamer1.0-plugins-base  1.12.4-1
ii  gstreamer1.0-plugins-good  1.12.4-1
ii  gstreamer1.0-pulseaudio1.12.4-1

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.22.0-1

-- no debconf information

Bug#888236: torbrowser-launcher: broken by Tor Browser 7.5: No such file or directory: '.../Docs/sources/versions'

[Antoine Beaupré]

On 2018-01-30 12:28:57, Paul Wise wrote:
> On Mon, 2018-01-29 at 22:44 -0500, Antoine Beaupre wrote:
>
>> This bug makes torbrowser-launcher completely unusable on Debian
>> stretch, as soon as the browser is updated (as it should).
>
> That isn't quite true, you can use the workaround until it is fixed:
>
> ~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/start-tor-browser

*I* can, but I do not expect an average user to pop open a terminal
every time they want to start torbrowser. :)

This is major breakage, especially because there's no visual feedback in
GUI environments of what is going on... I think this should be fixed in
stable.

A.

-- 
Incarnez les changements que vous voulez voir se produire dans le monde.
- Gandhi

Bug#888236: torbrowser-launcher: broken by Tor Browser 7.5: No such file or directory: '.../Docs/sources/versions'

[Paul Wise]

On Mon, 2018-01-29 at 22:44 -0500, Antoine Beaupre wrote:

> This bug makes torbrowser-launcher completely unusable on Debian
> stretch, as soon as the browser is updated (as it should).

That isn't quite true, you can use the workaround until it is fixed:

~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/start-tor-browser

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#864565: fixed in chromium-browser 60.0.3112.72-1

[Dmitry Alexandrov]

Control: found -1 chromium-shell/63.0.3239.84-1~deb9u1
Control: tag -1 stretch

> Source: chromium-browser
> Source-Version: 60.0.3112.72-1
>
> We believe that the bug you reported is fixed in the latest version of
> chromium-browser

Sorry, but it seems to me, that this bug is not fixed in stable
(Stretch) and its chromium-shell version 63.0.3239.84-1~deb9u1:

$ chromium-shell
[25398:25398:0128/041122.890412:311365848311:FATAL:v8_initializer.cc(248)] 
Couldn't mmap v8 natives data file, status code is 1
#0 0x55a1fe5d0eb6 
#1 0x55a1fe5e81da 
#2 0x55a1ff27181d 
#3 0x55a1fe0c5e79 
#4 0x55a1fefaf635 
#5 0x55a1fd950e71 
#6 0x55a1fd611c58 
#7 0x7f2c139822b1 __libc_start_main
#8 0x55a1fd6158ea _start

Aborted

$ type chromium-shell
chromium-shell is hashed (/usr/bin/chromium-shell)

$ strace chromium-shell
<...>
open("/usr/bin/snapshot_blob.bin", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/usr/bin/natives_blob.bin", O_RDONLY) = -1 ENOENT (No such file or 
directory)
<...>
open("/usr/bin/content_shell.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EACCES 
(Permission denied)
<...>

Did I miss something?

Bug#887323: dewalls FTBFS on i386: test failures

[Wookey]

I've reported this to upstream in the hope of a clue as to why it
fails on i386 but works on all the other release arches.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#888236: torbrowser-launcher: broken by Tor Browser 7.5: No such file or directory: '.../Docs/sources/versions'

[Antoine Beaupre]

This bug makes torbrowser-launcher completely unusable on Debian
stretch, as soon as the browser is updated (as it should).

What's expected from stable users here? Is there going to be a stable
update for this?

Thanks!

A.

-- 
C'est la nuit qu'il est beau de croire à la lumière
- Edmond Rostand


signature.asc
Description: PGP signature

Bug#888805: Also provide a non-Xwindows plain CLI version

[積丹尼 Dan Jacobson]

Package: unar
Version: 1.10.1-2+b1

On some machines one just cannot install unar, without making the
machine rather unusable.

One would think "I just want to install an program like gunzip. Why must
I give up my nvidia-legacy-304xx-driver ?"

OK it seems unar also has a graphical interface.

I never knew that. I only have used its command line interface.

So, why no also provide a non-X version?

That way one could still use it without dragging in all this extra
stuff!

Thanks.


# aptitude install unar
The following NEW packages will be installed:
  gnustep-base-common{a} (D: gnustep-base-runtime, D: libgnustep-base1.25) 
(unar D: gnustep-base-runtime D: gnustep-base-common)  gnustep-base-runtime{a} 
(D: unar, R: libgnustep-base1.25) (unar D: gnustep-base-runtime)  
gnustep-common{a} (D: gnustep-base-common) (unar D: gnustep-base-runtime D: 
gnustep-base-common D: gnustep-common)  libgnustep-base1.25{a} (D: 
gnustep-base-runtime, D: unar) (unar D: libgnustep-base1.25)  libobjc4{a} (D: 
gnustep-base-runtime, D: libgnustep-base1.25, D: unar) (unar D: libobjc4)  unar
The following packages will be upgraded:
  gcc-8-base (unar D: libobjc4 D: gcc-8-base)
The following packages are SUGGESTED but will NOT be installed:
  gnustep-base-doc (S: gnustep-base-common)
The following packages will NOT be UPGRADED:
  libatomic1{b} (D: gcc-8-base)  libcc1-0{b} (D: gcc-8-base)  libgcc1{b} (D: 
gcc-8-base)  libgomp1{ab} (D: gcc-8-base)  libitm1{b} (D: gcc-8-base)  
liblsan0{b} (D: gcc-8-base)  libmpx2{b} (D: gcc-8-base)  libquadmath0{b} (D: 
gcc-8-base)  libstdc++6{b} (D: gcc-8-base)  libtsan0{b} (D: gcc-8-base)
1 packages upgraded, 6 newly installed, 0 to remove and 10 not upgraded.
Need to get 0 B/3,836 kB of archives. After unpacking 14.9 MB will be used.
The following packages have unmet dependencies:
 libmpx2 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libitm1 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libcilkrts5 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libasan4 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libquadmath0 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libgcc1 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libtsan0 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libubsan0 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 liblsan0 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libgomp1 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libatomic1 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libcc1-0 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
 libstdc++6 : Depends: gcc-8-base (= 8-20171016-1) but 8-20180123-1 is to be 
installed
The following actions will resolve these dependencies:

  Remove the following packages:
1)  dkms [2.3-3 (now, unstable)]
2)  gcc [4:7.2.0-1d1 (now, unstable)]
3)  gcc-6 [6.4.0-12 (now, unstable)]
4)  gcc-7 [7.3.0-1 (now, unstable)]
5)  libasan4 [8-20171016-1 (now)]
6)  libcilkrts5 [8-20171016-1 (now)]
7)  libgcc-6-dev [6.4.0-12 (now, unstable)]
8)  libgcc-7-dev [7.3.0-1 (now, unstable)]
9)  libubsan0 [8-20171016-1 (now)]
10) linux-compiler-gcc-7-x86 [4.15~rc8-1~exp1 (experimental, now)]
11) linux-headers-4.14.0-2-amd64 [4.14.7-1 (now)]
12) linux-headers-4.14.0-3-amd64 [4.14.13-1 (now, unstable)]
13) linux-headers-amd64 [4.14+89 (now, unstable)]
14) nvidia-legacy-304xx-driver [304.137-4 (now, unstable)]
15) nvidia-legacy-304xx-kernel-dkms [304.137-4 (now, unstable)]

  Install the following packages:
16) tcc [0.9.27~git20161217.cd9514ab-3 (unstable)]

  Upgrade the following packages:
17) libatomic1 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
18) libcc1-0 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
19) libgcc1 [1:8-20171016-1 (now) -> 1:8-20180123-1 (experimental)]
20) libgomp1 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
21) libitm1 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
22) liblsan0 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
23) libmpx2 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
24) libquadmath0 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
25) libstdc++6 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]
26) libtsan0 [8-20171016-1 (now) -> 8-20180123-1 (experimental)]

Bug#888804: iproute2: some upstream URLs broken

[Matt Taggart]

Package: iproute2
Version: 4.14.1-2
Severity: wishlist

The Homepage header in debian/control lists

  https://wiki.linuxfoundation.org/networking/iproute2

but that page is 404. It's probably not supposed to be, there is a link 
to the same thing on


  https://wiki.linuxfoundation.org/networking/start

In the source package README it also lists

  http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2

but that seems to redirect to the same 404 URL as well.
The source README also lists this url for git:

  git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git

which I was able to clone and has updates as of today so must be up to 
date... but I don't see it listed at https://git.kernel.org/. There is


  https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/

which seems to be just as up to date, but I'm not sure which is 
considered canonical.


The Download URL listed in the source README is
  http://www.kernel.org/pub/linux/utils/net/iproute2/

and that works and appears to be up to date.

FYI- The wikipedia page also has the same broken links
  https://en.wikipedia.org/wiki/Iproute2

Probably upstream needs to fix things?

--
Matt Taggart
tagg...@debian.org

Bug#888707: Make sure exim4-* are updated before, after, but not during, locales.

[積丹尼 Dan Jacobson]

reopen 888707
retitle Make sure exim4-* are updated before, after, but not during, locales.
thanks

There turns out to be a race condition.

Please adjust the Dependencies to be sure exim4-* is updated before, after,
but not during, locales.


$ grep locale term.log
Preparing to unpack 
.../25-locales_2.26.9000+20180127.7e23a7dd-0experimental0_all.deb ...
Unpacking locales (2.26.9000+20180127.7e23a7dd-0experimental0) over 
(2.26.9000+20180108.401311cf-0experimental0) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up locales (2.26.9000+20180127.7e23a7dd-0experimental0) ...
Generating locales (this might take a while)...
$ egrep exim\|locale term.log
Preparing to unpack 
.../25-locales_2.26.9000+20180127.7e23a7dd-0experimental0_all.deb ...
Unpacking locales (2.26.9000+20180127.7e23a7dd-0experimental0) over 
(2.26.9000+20180108.401311cf-0experimental0) ...
Preparing to unpack .../45-exim4-config_4.90-5_all.deb ...
Unpacking exim4-config (4.90-5) over (4.90-4) ...
Preparing to unpack .../46-exim4_4.90-5_all.deb ...
Unpacking exim4 (4.90-5) over (4.90-4) ...
Preparing to unpack .../47-exim4-base_4.90-5_amd64.deb ...
Unpacking exim4-base (4.90-5) over (4.90-4) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Preparing to unpack .../48-exim4-daemon-light_4.90-5_amd64.deb ...
Unpacking exim4-daemon-light (4.90-5) over (4.90-4) ...
Setting up exim4-config (4.90-5) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up exim4-base (4.90-5) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up exim4-daemon-light (4.90-5) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up locales (2.26.9000+20180127.7e23a7dd-0experimental0) ...
Generating locales (this might take a while)...
Setting up exim4 (4.90-5) ...

Log started: 2018-01-30  10:26:20
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 197661 files and directories currently installed.)
Preparing to unpack .../dash_0.5.8-2.10_amd64.deb ...
Unpacking dash (0.5.8-2.10) over (0.5.8-2.9) ...
Setting up dash (0.5.8-2.10) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 197661 files and directories currently installed.)
Preparing to unpack 
.../libc6-dev_2.26.9000+20180127.7e23a7dd-0experimental0_amd64.deb ...
Unpacking libc6-dev:amd64 (2.26.9000+20180127.7e23a7dd-0experimental0) over 
(2.26.9000+20180108.401311cf-0experimental0) ...
Preparing to unpack 
.../libc-dev-bin_2.26.9000+20180127.7e23a7dd-0experimental0_amd64.deb ...
Unpacking libc-dev-bin (2.26.9000+20180127.7e23a7dd-0experimental0) over 
(2.26.9000+20180108.401311cf-0experimental0) ...
Preparing to unpack 
.../libc6_2.26.9000+20180127.7e23a7dd-0experimental0_amd64.deb ...
Unpacking libc6:amd64 (2.26.9000+20180127.7e23a7dd-0experimental0) over 
(2.26.9000+20180108.401311cf-0experimental0) ...
Setting up libc6:amd64 (2.26.9000+20180127.7e23a7dd-0experimental0) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 197660 files and directories currently installed.)
Preparing to unpack 
.../libc-bin_2.26.9000+20180127.7e23a7dd-0experimental0_amd64.deb ...
Unpacking libc-bin (2.26.9000+20180127.7e23a7dd-0experimental0) over 

Bug#888802: stretch-pu: package webkit2gtk/2.18.6-1~deb9u1

[Jeremy Bicha]

Package: release.debian.org
X-Debbugs-Cc:webkit2...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal

Background
-
New minor releases of webkit2gtk are made approximately monthly to fix
high-impact bugs and security vulnerabilities. New major releases are
made every six months (next one is mid-March). Similar to Firefox
and Chromium, it's not really feasible to separate the security fixes
from other changes. Basically, only one major release series is
supported at a time (sometimes, there will be a final security fix for
the old series shortly after the first release of the new series, but
that's it.)

For Debian 9, webkit2gtk is still excluded from normal security
support and therefore the Debian Security Team is unwilling to accept
webkit2gtk updates via stretch-security to avoid confusing our users.

The latest major release webkit2gtk 2.18 was released in September. I
am unaware of any remaining regressions in the new series. There was
one Ubuntu-specific package that needed to be updated for 2.18. See
https://launchpad.net/bugs/1712047 for more details.

Generally, all the major distros have updated to 2.18 and there has
been plenty of time for regressions to be noticed.

News

https://webkitgtk.org/2017/09/11/webkitgtk2.18.0-released.html
https://webkitgtk.org/2017/10/18/webkitgtk2.18.1-released.html
https://webkitgtk.org/2017/10/27/webkitgtk2.18.2-released.html
https://webkitgtk.org/2017/11/10/webkitgtk2.18.3-released.html
https://webkitgtk.org/2017/12/19/webkitgtk2.18.4-released.html
https://webkitgtk.org/2018/01/10/webkitgtk2.18.5-released.html
https://webkitgtk.org/2018/01/24/webkitgtk2.18.6-released.html

Security Trackers
--
This update will fix all current stretch vulnerabilities listed at
https://security-tracker.debian.org/tracker/source-package/webkit2gtk

https://webkitgtk.org/security/WSA-2017-0008.html
https://webkitgtk.org/security/WSA-2017-0009.html
https://webkitgtk.org/security/WSA-2017-0010.html
https://webkitgtk.org/security/WSA-2018-0001.html
https://webkitgtk.org/security/WSA-2018-0002.html

https://usn.ubuntu.com/usn/usn-3460-1/
https://usn.ubuntu.com/usn/usn-3481-1/
https://usn.ubuntu.com/usn/usn-3514-1/
https://usn.ubuntu.com/usn/usn-3530-1/

Detailed Commit Log and Diff
--
It's not really useful to provide a detailed diff or log for the
upstream changes. For instance, Ubuntu's diff for the the 2.16.6 to
2.18.0 upgrade is 10 MB.

https://launchpad.net/ubuntu/+source/webkit2gtk/2.18.0-0ubuntu0.16.04.2

debdiff gave me a 71MB file.

Builds

webkit2gtk 2.18.6 is available in Debian unstable, testing and
stretch-backports. It has built successfully on all release
architectures. (mips64el is still building on stretch-backports)

Proposed Stretch Update

I am proposing a straight backport from Buster to Stretch. I am
attaching a diff of the debian/ directory.


Thanks,
Jeremy Bicha


webkit2gtk_2.18.6-1~deb9u1.debdiff
Description: Binary data

Bug#638024: user story --- bad Default-Release breaks unattended-upgrades

[Trent W. Buck]

David Kalnischkies wrote:
> On Wed, Jan 24, 2018 at 02:10:43PM +1100, Trent W. Buck wrote:
> > As part of my Best Current Practice I set Default-Release "stretch",
> > to prevent accidental dist-upgrades when sources.list is in an unusual 
> > state.
> > (For THIS server, that's unlikely, but it's BCP so I do it everywhere.)
>
> As your entire story depends on this, could you tell us please what you
> mean here? "accidental dist-upgrade" and "unusual state" don't make
> a lot of sense to me.

Sorry that wasn't clear.

The unusual state I'm thinking of is along the lines of this:

  * my normal system runs stable

  * the frobozz maintainer claims #123456 is fixed in unstable, and asks me to 
check it

  * rather than setting up a whole new unstable test VM,
just enable unstable in sources.list temporarily,
cherry-pick frobozz, test it, then downgrade again.

(Obviously this wouldn't work for something hairy like mysql, but
for GUI apps it's usually fine.)

  * whoops, "apt install frobozz" has upgraded libc and friends because I 
wasn't paying attention and just hit yes.
Now important parts of my system are running unstable, not just that app.

When Default-Release is set, in that last step, I have to explicitly ask for 
any dependencies that can't be met from stable.


These days I personally am more likely to roll an in-house backport
package, but at least three times my coworkers (who aren't debian
experts) have bricked their laptops by trying something along these
lines, usually because "stackoverflow/reddit said this would work".


This is also a helpful safety net if I forget to remove unstable from 
sources.list afterwards.

In the old days, before I knew about rmadison, I would just leave my
system with stable, testing, unstable and experimental all enabled,
but only actually install stuff from stable, so I could use apt-cache
policy to find out what versions of frobozz debian had.

Now that you've made me spell it out, I realize that a lot of the
stuff I've described isn't officially supported, and I haven't
actually used much since about 2013.

I guess at this point I'm setting Default-Release out of habit, because
it's saved me from my own stupid mistakes in the past.

> Nuking /var/lib/apt/lists isn't the best practice either as some
> security features use the "old" data to put up constraints for the "new"
> data – including that a repository can't change its Codename from
> "buster" to "bullseye" without a user explicitly confirming this (even
> if "stable" is written in the sources.list – implemented in 1.5 which is
> why I talk about stable+1 and stable+2 at the time of writing).

When I have persistent storage, I keep /var/lib/apt/lists.
The case where this bit me was a Debian Live environment,
where to keep the image small (<128MB) I habitually strip out a lot of stuff,
including apt lists.

I didn't know about the safety net stuff you describe;
that might be valuable enough to compile apt lists into the Debian Live image —
I'll try it and see how it affects image size and boot time.

Let's see, normal build gives me

4.7Mlive/boot/vmlinuz
17M live/boot/initrd.img
85M live/boot/filesystem.squashfs
106Mtotal

Including /var/lib/apt/lists gives me

4.7Mlive/boot/vmlinuz
17M live/boot/initrd.img
98M live/boot/filesystem.squashfs
119Mtotal

So, a 10.9% increase in image size.
Bleh — although it's still <128MiB, so I'll think about it.

Bug#870301: systemd: Touchpad fix Dell Inspiron Mini 1012

[Michael Biebl]

On Tue, 10 Oct 2017 16:04:46 +0200 Michael Biebl  wrote:
> On Mon, 31 Jul 2017 20:44:17 -0400 (EDT) bw  wrote:
> > On Tue, 1 Aug 2017, Michael Biebl wrote:
> > > It would be great if you can file this issue upstream at
> > > https://github.com/systemd/systemd/issues
> > >
> > > Such a change really belongs into upstream and should not be added as a
> > > downstream patch.
> > >
> > > Regards,
> > > Michael
> > >
> > 
> > I know but they don't want it, I put info in the attachment.
> 
> Well, if the issue is still valid with v234 or v235, upstream is happy
> to review a patch.
> 
> You can either test on a sid/buster system or use the v234 stretch backport.
> 


Ping? Are you still interested in getting this upstream?

-- 
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#888801: RFP: python-tldextract -- A Python library for accurately seperating the TLD from the registered domain or subdomains of a URL, using the Public Suffix List.

[noah]

Package: wnpp
Severity: wishlist

* Package name: python-tldextract
  Version : 2.2.0
  Upstream Author : John Kurkowski
* URL : https://github.com/john-kurkowski/tldextract
* License : BSD
  Programming Lang: Python
  Description : A Python library for accurately seperating the TLD from the 
registered domain or subdomains of a URL, using the Public Suffix List.

This library is a dependency for the python dns-lexicon library, which
is a requirement for a number of Certbot DNS plugins.
The relevant bug for the RFP for python-dns-lexicon is #00.
This will allow dns-lexicon to be packaged, which will in turn allow a
number of Certbot DNS plugins to be packaged, which in turn will allow
users of a number of DNS providers to get wildcard certificates from
Let's Encrypt, when they activate ACME v2.
This package doesn't have a sponsor, but should be able to be maintained
by the normal python packaging team.

Bug#821936: [i18n] minicom does not live well with multicol characters

[Mingye Wang (Artoria2e5)]

Hi Adam,

Apologies for taking so long to respond to your message. Our current 
proposed translation is available at [1], although I must warn you that 
it contains some tabs that needs to be filtered through things like "sed 
-e 's/\\t/\t/g' | expand" to remove. Time really flies...


 [1]: 
https://github.com/AOSC-Dev/translations/blob/master/TranslationProject/minicom-2.6.1.90.zh_CN.po


Thanks,
Mingye

Bug#888800: RFP: python-dns-lexicon -- A python library for manipulating DNS records in a standardized way

[noah]

Package: wnpp
Severity: wishlist

* Package name: python-dns-lexicon
  Version : 2.1.18
  Upstream Author : Jason Kulatunga
* URL : https://github.com/AnalogJ/lexicon
* License : MIT
  Programming Lang: Python
  Description : A python library for manipulating DNS records in a 
standardized way


This is a python wrapper for a general purpose DNS API which is needed as a
dependency for a number of Certbot DNS plugins.
Packaging this will allow the Certbot cloudxns, dns-simple, dnsmadeeasy,
nsone, and luadns plugins to be packaged.
This is notable because DNS authentication is the only method in the
ACME v2 spec that allows for the issuance of wildcard certificates - a
much sought after feature.
You can learn more about the relevant Certbot plugins here:
https://github.com/certbot/certbot
This package requires a sponsor, but should be able to be maintained by
the normal python packaging team.
This package will also need the tldextract python package to be packaged
as well. I will submit an RFP for that package seperately.

Bug#888799: RFP: python-cloudflare -- A python wrapper for the Cloudflare v4 API

[noah]

Package: wnpp
Severity: wishlist

* Package name: python-cloudflare
  Version : 1.8.1
  Upstream Author : Martin J. Levy
* URL : https://github.com/cloudflare/python-cloudflare
* License : MIT
  Programming Lang: Python
  Description : A python wrapper for the Cloudflare v4 API

This is a python wrapper for the cloudflare API which is needed as a dependency 
for the Certbot cloudflare DNS plugin.
Packaging this will allow the Certbot Cloudflare plugin to be packaged. 
This is notable because DNS authentication is the only method in the ACME v2 
spec that allows for the issuance of wildcard certificates - a much sought 
after feature.
You can learn more about the relevant Certbot plugin here: 
https://github.com/certbot/certbot/tree/master/certbot-dns-cloudflare
This package requires a sponsor, but should be able to be maintained by the 
normal python packaging team.

Bug#888798: quick boot changes to 30_os-prober prevents menu from hiding

[Mingye Wang (Artoria2e5)]

Package: grub-common
Version: 2.02-2
Version: 2.02~beta3-5
Version: 2.02~beta2-18

Since 2.02~beta2-18 Debian introduced a "quick_boot.patch" from Ubuntu, 
which allows for the bypass of boot menu. Quoting from its commit message:


> If other operating systems are installed, then automatically unhide 
the menu.


This default is unhelpful as it overrides the manual definitions for 
GRUB_MENU_STYLE set in /etc/default/grub and provides no means of 
disabling besides manually editing the file in question, i.e. 
"/etc/grub.d/30_os-prober" or "util/grub.d/30_os-prober.in" in the 
source code. To add to the confusion, this default remains largely 
undocumented besides the commit message.


Please consider making it configurable or phasing out this default 
behavior. Such overriding decisions should be explicitly called for in 
config files like /etc/default/grub instead of riding on the top of the 
user's head.


Regards,
Artoria2e5

Bug#888571: python3-apt depends on python3 (<< 3.6)

[Axel Beckert]

Dear Jean-Christophe,

jean-christophe manciot wrote:
> > That's wrong. The corresponding sources _are_ shown on
> > https://packages.debian.org/source/sid/python-apt. It's the files
> > called python-apt_1.4.0~beta3.dsc and python-apt_1.4.0~beta3.tar.xz
>
> No, you're confused.

I'm not.

> The whole point of this bug report is that *building*
> python-apt from the sources downloaded from https://packages.debian.
> org/source/sid/python-apt is that the binary python3-apt is incompatible
> with python3 >= 3.6.

This depends a lot on which Debian release you build the package and
what version /usr/bin/python3 has on that system as those versioned
dependencies are calculated at build time.

So if you build that package on Debian Stretch where python3 is 3.5.3,
the above is true, expected and wanted: the package has a dependency
on python3 << 3.6.

And if you build it on Debian Unstable now (where python3 is currently
3.6.4), it's expected and wanted that the package has a dependency on
python3 << 3.7.

Short said: It's built to work with the currently installed version of
python3 and _no_ other (earlier or later) version. That's why Debian
rebuilds such packages when a new python3 minor version enters Debian
Unstable by doing binNMUs.

So there is no bug at all and everything works as expected and wanted.

> If you try to built the packages from those sources, you'll discover

I don't need to discover that. I can tell it by mind and it's
expected.

> that the version is *1.4.0~beta3*, as indicated in debian/changelog.

Of course! Because it's no binNMU if you just build it from source
without the appropriate commandline options for a binNMU.

Please first read

* https://wiki.debian.org/binNMU
* 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#binary-only-nmu,
* the dpkg-buildpackage(1) and dpkg-genchanges(1) man pages on the
  options -B, -C, -e (both) -V and -D (dpkg-genchanges only)
* the deb-substvars(5) man page section on the topic "binary:Version"
* and the dh_python3(1) man page

before writing any further replies to this thread. Thanks.

> > No. Nowhere in Debian you will find a binary package without an
> > according source package. Period.
> 
> It depends on what you call "sources".

I talked about "source packages" (not "sources") which is a very
precise term in Debian context: A Debian source package means a .dsc
file including all files referenced in there (usually a .orig.tar.gz
and a .debian.tar.xz file).

> If you put the *debian* folder aside from your definition, then we
> agree.

The we disagree, because a debian folder of course is part of every
Debian source package.

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

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dl 29 de 01 de 2018 a les 16:24 +, Michael Matz va escriure:
> Is does, but draft means many things, and for the psABI doesn't include 
> "making backward incompatible changes is okay".

I am asking people to be nice, not requiring them to modify their
systems. Let me try a new proposal:

5.2.1
Systems conforming to the AMD64 ABI may want to support
the /lib/ld-linux-x86-64.so.2 path name, which is preferred in
multiarch.

Appendix A.1
Systems conforming to the AMD64 ABI may want to support
lib/x86_64-linux-gnu subdirectories for the libraries, which are
preferred in multiarch.

This way, people that want to help will not be frowned upon.
Could you do another assessment?


smime.p7s
Description: S/MIME cryptographic signature

Bug#387793: aumix: segfaults on console when resolution changes

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 gpm
Control: retitle -2 libgpm crashes on calling syslog

Hello,

Ricardo Fabian Peliquero, on dim. 28 janv. 2018 19:35:22 -0300, wrote:
> Aumix is showing segmentation fault if invoked within an X terminal
> emulator (e.g. stterm). This only happens when using the ncurses
> user interface; then 'aumix -v 100' will work as expected.
> 
> Besides, it works OK from ordinary tty (e.g. tty1-6).

Well, this is not related with bug 387793 then :)

Looking more into the backtrace

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strchrnul_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:76
76  ../sysdeps/x86_64/multiarch/strchr-avx2.S: Aucun fichier ou dossier de 
ce type.
(gdb) bt
#0  __strchrnul_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:76
#1  0x7f88711cbb52 in __find_specmb (
format=0x2573 ) at 
printf-parse.h:108
#2  _IO_vfprintf_internal (s=s@entry=0x557eed6c76d0, 
format=format@entry=0x2573 , 
ap=0x72a3bbf0) at vfprintf.c:1320
#3  0x7f8871283428 in ___vfprintf_chk (fp=fp@entry=0x557eed6c76d0, 
flag=flag@entry=1, 
format=format@entry=0x2573 , 
ap=ap@entry=0x72a3bbf0) at vfprintf_chk.c:33
#4  0x7f887126e777 in __GI___vsyslog_chk (pri=, flag=1, 
fmt=0x2573 , 
ap=ap@entry=0x72a3bbf0)
at ../misc/syslog.c:222
#5  0x7f887126ecbf in __syslog_chk (pri=pri@entry=6, flag=flag@entry=1, 
fmt=fmt@entry=0x2573 )
at ../misc/syslog.c:129
#6  0x7f8871992cdf in syslog (
__fmt=0x2573 , __pri=6)
at /usr/include/x86_64-linux-gnu/bits/syslog.h:31
#7  gpm_report (line=line@entry=478, file=file@entry=0x7f88719934b1 
"lib/liblow.c", 
stat=stat@entry=3, text=text@entry=0x7f8871993539 "Warning: closing 
connection")
at lib/report-lib.c:50
#8  0x7f8871991b67 in Gpm_GetEvent (event=event@entry=0x7f8871b95420 )
at lib/liblow.c:478
#9  0x7f8871992fe8 in Gpm_Wgetch (win=0x557eed6b1cb0) at lib/libcurses.c:87
#10 0x557eeb879247 in Inter () at ../../../src/curses.c:366
#11 0x557eeb876db7 in main (argc=1, argv=0x72a3c028) at 
../../../src/common.c:283

I saw this gpm patch
debian/patches/092_fix-format-not-a-string-literal-and-no-format-arguments.patch

-   syslog(log_level, string);
+   syslog(log_level, '%s', string);


That should obviously rather be

+   syslog(log_level, "%s", string);

:)

Samuel

Bug#888796: w3m: segfaults on keypresses with recent versions of gpm/libgpm2

[Grant Naish]

Package: w3m
Version: 0.5.3-35
Severity: important

Dear Maintainer,

Following a recent dist-upgrade, w3m has become unusable. w3m immediately 
segfaults in response to many hotkeys, including "/" "?" "Esc" "q" "S" etc. 
During the dist-upgrade, libgpm2 was upgraded from version 1.20.4-6.2+b1 to 
1.20.7-4, and this seems to have caused this bug. Downgrading libgpm2 back to 
version 1.20.4-6.2+b1 makes w3m usable again.

The error message on exit is always simply: "Segmentation fault"

Downgrading the libgpm2 mitigates this bug.

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

Kernel: Linux 4.8.0-1-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: sysvinit (via /sbin/init)

Versions of packages w3m depends on:
ii  libc6  2.26-4
ii  libgc1c2   1:7.4.2-8
pn  libgpm2
ii  libssl1.1  1.1.0g-2
ii  libtinfo5  6.0+20171125-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages w3m recommends:
ii  ca-certificates  20170717

Versions of packages w3m suggests:
pn  cmigemo   
ii  curl  7.57.0-1
ii  dict  1.12.1+dfsg-4
pn  dict-wn   
pn  dictd 
pn  libsixel-bin  
ii  man-db2.7.6.1-4
ii  mime-support  3.60
ii  mpv   0.27.0-2+b3
pn  w3m-el
ii  w3m-img   0.5.3-35
ii  wget  1.19.3-2
ii  xdg-utils 1.1.2-1
ii  xsel  1.2.0-4

-- no debconf information

Bug#888795: vite: FTBFS with glm 0.9.9~a2-1

[Andreas Beckmann]

Package: vite
Version: 1.2+svn+git2.ea4d767-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

vite/experimental FTBFS with the new glm in unstable (vite/sid
does not use glm and builds fine):

cd /build/vite-1.2+svn+git2.ea4d767/obj-x86_64-linux-gnu/src && /usr/bin/c++  
-DBOOST_GZIP -DMT_PARSING -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG 
-DQT_OPENGL_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -DWIT
H_OTF -DWITH_VBO 
-I/build/vite-1.2+svn+git2.ea4d767/obj-x86_64-linux-gnu/src/vite_autogen/include
 -I/usr/include/open-trace-format 
-I/build/vite-1.2+svn+git2.ea4d767/obj-x86_64-linux-gnu/src/common 
-I/build/vite-1
.2+svn+git2.ea4d767/obj-x86_64-linux-gnu/src 
-I/build/vite-1.2+svn+git2.ea4d767/src 
-I/build/vite-1.2+svn+git2.ea4d767/externals/qtcolorpicker/src -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x
86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui 
-isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/x86_6
4-linux-gnu/qt5/QtXml -isystem /usr/include/x86_64-linux-gnu/qt5/QtOpenGL 
-isystem /usr/include/x86_64-linux-gnu/qt5/QtUiTools  -g -O2 
-fdebug-prefix-map=/build/vite-1.2+svn+git2.ea4d767=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -fPIC 
-std=gnu++11 -o CMakeFiles/vite.dir/render/vbo.cpp.o -c 
/build/vite-1.2+svn+git2.ea4d767/src/render/vbo.cpp
In file included from /build/vite-1.2+svn+git2.ea4d767/src/render/vbo.cpp:51:0:
/usr/include/glm/gtx/transform.hpp:23:3: error: #error "GLM: GLM_GTX_transform 
is an experimental extension and may change in the future. Use #define 
GLM_ENABLE_EXPERIMENTAL before including it, if you really want to use it."
 # error "GLM: GLM_GTX_transform is an experimental extension and may change in 
the future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you 
really want to use it."
   ^
src/CMakeFiles/vite.dir/build.make:1683: recipe for target 
'src/CMakeFiles/vite.dir/render/vbo.cpp.o' failed


Andreas


vite_1.2+svn+git2.ea4d767-1.log.gz
Description: application/gzip

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

[Manuel A. Fernandez Montecelo]

Source: glibc
Severity: wishlist
Control: user debian-ri...@lists.debian.org
Control: usertag -1 + riscv64

Hello,

This bug is to track the progress on the support for riscv64 in the Debian
package.

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.

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.


Cheers.

Bug#888792: libgpm2: Segfault due to malformed syslog format statement

[William Blough]

Package: libgpm2
Version: 1.20.7-4
Severity: normal
Tags: patch


When a condition occurs that causes gpm_report to be called, a segfault
occurs when writing to syslog.  This is due to the syslog format string
being wrapped in single quotes instead of double quotes, thus being
interpreted as a character instead of a string.  Since syslog expects a
char string, the "single character" is taken as a 16-byte memory address
and results in an invalid memory access attempt.


Sample backtrace:

#0  0x03fffda24408 in ?? () from /lib/s390x-linux-gnu/libc.so.6
#1  0x03fffd9da57e in vfprintf () from /lib/s390x-linux-gnu/libc.so.6
#2  0x03fffda99ae2 in __vfprintf_chk () from /lib/s390x-linux-gnu/libc.so.6
#3  0x03fffda81ab6 in __vsyslog_chk () from /lib/s390x-linux-gnu/libc.so.6
#4  0x03fffda81fb8 in __syslog_chk () from /lib/s390x-linux-gnu/libc.so.6
#5  0x03fffdc04700 in syslog (__fmt=0x2573 , __pri=3)
at /usr/include/s390x-linux-gnu/bits/syslog.h:31
#6  gpm_report (line=line@entry=239, file=file@entry=0x3fffdc05042 
"lib/liblow.c", stat=stat@entry=4, 
text=text@entry=0x3fffdc05008 "unable to open gpm console, check your /dev 
filesystem!\n") at lib/report-lib.c:50
#7  0x03fffdc0298e in Gpm_Open (conn=conn@entry=0x1002e72fc , 
flag=)
at lib/liblow.c:239
#8  0x03fffdc02c16 in Gpm_Open (conn=conn@entry=0x1002e72fc , 
flag=flag@entry=0) at lib/liblow.c:416
#9  0x000100168e06 in gpm_open () at os_unix.c:6946
#10 mch_setmouse (on=) at os_unix.c:3660
#11 0x0001001f8304 in settmode (tmode=) at term.c:3357
#12 0x000100243306 in vim_main2 () at main.c:676
#13 0x000100039178 in main (argc=, argv=) at 
main.c:429


A patch attached for your convenience.
diff -Nuar 
gpm-1.20.7.orig/debian/patches/092_fix-format-not-a-string-literal-and-no-format-arguments.patch
 
gpm-1.20.7/debian/patches/092_fix-format-not-a-string-literal-and-no-format-arguments.patch
--- 
gpm-1.20.7.orig/debian/patches/092_fix-format-not-a-string-literal-and-no-format-arguments.patch
2017-08-19 05:40:43.0 -0400
+++ 
gpm-1.20.7/debian/patches/092_fix-format-not-a-string-literal-and-no-format-arguments.patch
 2018-01-29 18:27:43.615443462 -0500
@@ -3,12 +3,12 @@
 
 --- a/src/lib/report-lib.c
 +++ b/src/lib/report-lib.c
-@@ -47,7 +47,7 @@
+@@ -47,7 +47,7 @@ void gpm_report(int line, char *file, in
 log_level = LOG_CRIT; break;
 }
  #ifdef HAVE_VSYSLOG
 -   syslog(log_level, string);
-+   syslog(log_level, '%s', string);
++   syslog(log_level, "%s", string);
 vsyslog(log_level, text, ap);
  #else
 fprintf(stderr,"%s[%s(%d)]:\n",string,file,line);

Bug#836770: (no subject)

[Rian Hunter]

This bug has been fixed in upstream for ~4 years: 
Message-ID: <151726856505.17087.10846960052117422510.reportbug@tomi>
X-Mailer: reportbug 6.6.6
Date: Mon, 29 Jan 2018 15:29:25 -0800

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/commit/?id=9af07a90a3e2246be5a7d01e3a037cfa731eb5dc

This package is in dire need of an upstream update.

Bug#888156: Please fix lintian errors in ignition-cmake (0.4.0-1)

[Jose Luis Rivero]

Thanks Andreas for the help. I think that I've fixed all the warnings
related to the privacy breaches:
https://salsa.debian.org/science-team/ignition-cmake/commit/44ab97f51f8f8e61ad3ea5fc962314fd89b73cc8

My maintainers right are probably fixed with the latest keyring sync so I
should be able the make the upload. Give me an ok on the changes and I will
try to finish the upload myself.


On Tue, Jan 23, 2018 at 7:26 PM, Andreas Tille  wrote:

> Hi Jose,
>
> thanks for your work on ignition-cmake.  I've built the package to
> sponsor it to the Debian mirror.  However, there are some lintian errors
> + warninge that I would like to see fixed.
>
> E: libignition-cmake-dev: privacy-breach-logo 
> usr/share/ignition/ignition-cmake0/doxygen/header.html
> (https://ignitionrobotics.org/assets/doxygen/ignition_logo.svg)
> W: libignition-cmake-dev: privacy-breach-generic
> usr/share/ignition/ignition-cmake0/doxygen/header.html (
> https://fonts.googleapis.com/icon?family=material+icons)
> W: libignition-cmake-dev: privacy-breach-generic
> usr/share/ignition/ignition-cmake0/doxygen/header.html (
> https://code.getmdl.io/1.3.0/material.deep_orange-blue.min.css)
> W: libignition-cmake-dev: privacy-breach-generic
> usr/share/ignition/ignition-cmake0/doxygen/header.html (
> https://ignitionrobotics.org/assets/doxygen/doxygen.css)
> W: libignition-cmake-dev: privacy-breach-generic ... use
> --no-tag-display-limit to see all (or pipe to a file/program)
> E: libignition-cmake-dev: privacy-breach-uses-embedded-file
> usr/share/ignition/ignition-cmake0/doxygen/header.html You may use the
> libjs-mathjax package. (https://cdnjs.cloudflare.com/
> ajax/libs/mathjax/2.7.2/mathjax.js?config=tex-mml-am_chtml)
> E: libignition-cmake-dev: privacy-breach-logo usr/share/ignition/ignition-
> cmake0/doxygen/tutorials-header.html (https://ignitionrobotics.org/
> assets/doxygen/ignition_logo_white.svg)
>
>
> You will get more verbose hints how to do this when trying
>
>   lintian -i ignition-cmake_0.4.0-1_amd64.changes
>
> Here are some hints:
>
>   1. Just download ignition_logo.svg put it somewhere under
>  debian/ and install it next to the documentation.  Than
>  you can use a relative local link inside header.html.
>   2. May be a similar approach is usefill for the googleapis icon.
>   3. For css files this might work as well but regarding doxygen.css
>  there might be a Debian packaged copy you could use via the
>  apropriate Depends and a file:///... URL to this file
>   4. How to replace mathjax is explained by lintian.
>
> Hope these hints are helpful.
>
> BTW, regarding the SoB condition 3 (Your package is listed on the Blends
> tasks pages) I've pushed the following change to the Git repository of
> the debian-science package:
>
>
> science(master) $ git diff HEAD^
> diff --git a/tasks/robotics-dev b/tasks/robotics-dev
> index b0cf433..b5c0fa5 100644
> --- a/tasks/robotics-dev
> +++ b/tasks/robotics-dev
> @@ -41,6 +41,8 @@ Depends: libgazebo7-dev
>
>  Depends: libsimbody-dev
>
> +Depends: libignition-cmake-dev
> +
>  Depends: libignition-transport-dev
>
>  Depends: libignition-math2-dev
>
>
> This now would create the according paragraph on the Blends page.  Next
> time please check whether the link you are adding to the SoB table and
> ping me accordingly to add the change (or ask for commit permission to
> the debian-science package Git).
>
> Hope this helps
>
> Andreas.
>
> --
> http://fam-tille.de
>

Bug#887940: [Pkg-postgresql-public] Bug#887940: libpq-dev:

[Thomas Andrejak]

On Tue, 23 Jan 2018 09:50:32 +0100 Christoph Berg  wrote:
> Control: reassign -1 src:libpreludedb
>
> Re: Adrian Bunk 2018-01-23 <20180123043023.GA11847@localhost>
> > > > ./configure: line 19300: test: too many arguments
> > > > ...
> > >
> > > Looks like the ax_lib_postgresql.m4 macro should be fixed with some
> > > additional shell quoting.
> >
> > This is not about quoting, the pg_config output changed:
> >
> > 10.1-3:
> > $ pg_config --version
> > PostgreSQL 10.1 (Debian 10.1-3)
>
> The macro is buggy anyway, it decomposes the string into
> major/minor/micro, but the middle component doesn't exist anymore with
> PostgreSQL 10. That was fine with 10.0, but with 10.1, it will think
> there was a new major release "10.1".
>
> Both issues need to be fixed on the libpreludedb side.
>

OK but m4 came from autoconf-archive, they have to provide a new m4
not buggy so we can update it inside libpreludedb.

Regards

Thomas

Bug#785314: libjs-*: Multi-Arch with patch

[Elrond]

package libjs-prototype libjs-scriptaculous
tags 785313 +patch
tags 785314 +patch
thanks


Hi,

Norman Ramsey has provided details on how to fix this in
his initial reports. So tagging with patch.

Cheers

Elrond

Bug#825383: /usr/share/hplip/doctor.py: hp-doctor will not accept sudo password and there is no root account

[Reinhard John]

Am 29.01.2018 um 20:46 schrieb Brian Potkin:



That worked but you cannot expect a user to go through all of this.
Devising a solution still lies in the hands of the hplip team. Whether
they will implement one is another matter.

I tested the complete workaround and it really works! Thank you for your 
analysis, Brian! I learned a lot about the background processes of hplip.


To sum up my own experiences: It is not crucial to change the debian 
version to 8.6. hp-doctor will automatically fall back to version 8.6:

Checking for Deprecated items
error: This distro (i.e debian  9.3) is either deprecated or not yet 
supported.
The diagnosis is limited on unsupported platforms. Do you want to 
continue?(y=yes*, n=no):y

Checking for Dependencies
warning: 2-9.3 version is not supported. Using 2-8.6 versions 
dependencies to verify and install...

It is necessary to replace 'su' in line 35 with 'sudo' in password.py.
And to replace "su -c" and "su_sudo" with "sudo" in the lines 4118 to 
4122 in the file distros.dat.


Then the doctor is able to heal the missing dependencies. (Irrespective 
of the question how crucial these dependencies really are! I also wonder 
at the listing.)


But as Brian pointed out, this is just a workaround, not a solution. 
hp-doctor should be able to accept both types of verification. This is 
intended in the file /usr/share/hplip/doctor.py (line 102 to 122) and it 
doesn´t work, at least not with debian. And this is undoubtedly a bug. 
We will see whether the hplip developers will react to my bug report there.


Regards
Reinhard

Bug#888243: Should dpkg remove /etc/opt/ on package removal?

[Simon McVittie]

On Mon, 29 Jan 2018 at 22:52:32 +0100, Guillem Jover wrote:
> On Sat, 2018-01-27 at 09:46:32 -0500, Jeremy Bicha wrote:
> > One of the supported browsers upstream is Google Chrome, which Google
> > installs to /opt/chrome/ . According to the FHS, that means its
> > configuration should be stored in /etc/opt/chrome/ . To support Google
> > Chrome, chrome-gnome-shell must install files to /etc/opt/chrome/ .
> 
> I don't find the FHS very clear on the /etc/opt topic, TBH. Can for
> example third-party applications read also /etc/ if it's
> present? That could perhaps be another solution, don't know.

If Chrome doesn't actually do this, then wondering whether it would be
allowed to do so doesn't necessarily help us: chrome-gnome-shell supports
(among others) Google Chrome, not a hypothetical better browser similar
to Google Chrome. One of the notable properties that Chrome has is
that as a proprietary binary, we have very limited control over how it
behaves. It's Google's choice where it will install and which integration
points it offers, not ours.

(Arguably there is a non-hypothetical better browser similar to Google
Chrome, and it's called Chromium - but Chrome has some functionality that
Chromium doesn't, so there are reasons to prefer each one over the other.)

smcv

Bug#888791: libsvn-perl: likely some reference counting bug around SVN::Client/SVN::Ra

[Eric Wong]

Package: libsvn-perl
Version: 1.9.5-1+deb9u1
Severity: normal
Tags: upstream

git developers have encountered a weird crash with git-svn
which uses libsvn-perl.

My patch (in the thread below) to undef the SVN::Client instance
before creating SVN::Ra instances seems to solve the problem;
so I suspect there's some sort of reference counting bug in the
Perl bindings.

https://public-inbox.org/git/20180129120627.al2xvx4yhhvwn6ih@untitled/t/#u

Thanks.

Bug#888790: RM: avahi-sharp -- ROM; RC buggy, dead upstream

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Hi,

please remove avahi-sharp and its only reverse dependency, gshare, from
the archive.
The packages haven't been in testing for a while due to being RC buggy
and since upstream is dead since a long time, I think it's best to
remove both packages from the archive.

sjoerd, slomo, if you disagree, please shout.


Thanks,
Michael

Bug#888652: baobab: Baobab opens the wrong handler for inode/directory MIME type

[Simon McVittie]

On Mon, 29 Jan 2018 at 10:29:40 +0100, Rafael Varela Pet wrote:
> 2018-01-28 14:17 GMT+01:00 Simon McVittie :
> > On Sun, 28 Jan 2018 at 13:29:32 +0100, Rafael Varela Pet wrote:
> > > [baobab] seems to ignore the default setting under Xfce4
...
> > What is in ~/.config/mimeapps.list, if that file exists?
> 
> You can find attached a copy of it. For the inode/* MIME type it only
> has a reference to Thunar:
> 
> $ grep -i inode ~/.config/mimeapps.list
> inode/symlink=Thunar-folder-handler.desktop

If you have explicitly configured Thunar to be the default in XFCE,
I would have expected that it would have another entry

inode/directory=Thunar-folder-handler.desktop

I wonder what XFCE does when you change that default setting, if not
writing to ~/.config/mimeapps.list? Perhaps changing the preferred
handler to something else and back to Thunar would work around this?

>From the configuration that you sent, it seems as though all the possible
inode/directory handlers (even Kaffeine) might have an equal claim to be
the "best" handler, so I wouldn't be surprised if it's non-deterministic
which one is chosen. I'm surprised that gio(1) and baobab consistently
make different choices, though - I would have expected that they're
using the same code to do it...

Perhaps XFCE should install an xfce-mimeapps.list similar to GNOME's
gnome-mimeapps.list (but with different choices), to arrange for XFCE
apps to be preferred when running XFCE if all other factors are equal
and there is no relevant personal configuration.

smcv

Bug#760571: libftgl2: problems with bitmap fonts, incorrect blending function, etc.

[Frank Heckenbach]

Manuel A. Fernandez Montecelo wrote:

> So basically the package has been unmaintained all these years, and
> still is.  Sorry that your patches were ignored, but it seems that the
> maintainers are simply not available, and the rest of the Debian folks
> don't always take a look to packages unless they are interested in it
> for some reason.

Sorry for my late reply, I was busy with other stuff ...

> I just uploaded another NMU fixing other problems (related with
> cross-compilation, because it affects other packages), and considered
> including some of your patches, but they are a bit complex (it not just
> a fix initialising a variable, or avoiding a leak, etc),

Actually the first part of my patch is -- but the rest isn't. :)

> and nobody else
> "seconded" the change (I'm CCing other addressed of the authors) or
> asked for the patches to be applied, or pointed that the patch is
> already battle-tested because it's shipped in new upstream releases...
> 
> Essentially, I have very little knowledge about the matter at hand and I
> am not interested in maintaining the package long term, so without
> investing a significant amount of time and effort I don't know what's
> currently wrong with the behaviour, how to test it with the available
> packages using the library (or if I have to create a sample program to
> test the new features of the fonts to rotate them, for example),

I included some test programs with the changes (see below).

> I don't
> know either if they will break applications relying on the current
> behaviour (even if possibly buggy),

That's certainly possible. If bug-compatibility is important, we
basically can't change anything, and I'll have to keep my fixes to
myself.

> I cannot evaluate if you're
> introducing errors in the package as part of a mistake or a nefarious
> plan...

Of course I am. ;>

> and even then, the fixes will be only applied in Debian (and
> possibly derivatives), with behaviour possibly diverging from other
> platforms.

Of course, I'd like the bugs fixed upstream. My understanding (many
years ago when I reported the bugs) was that I should not send a
copy to the upstream software maintainers myself, as it is possible
that the bug exists only in Debian. If necessary, the maintainer of
the package will forward the bug upstream.

Incidentally, that's still what it says today on
https://www.debian.org/Bugs/Reporting (my text is almost a verbatim
quote!). I've had those irritations with many other bug reports I've
made on Debian, and I still don't know what's going on. Is the page
about bug reporting buggy itself? Should we report upstream now?

Then again, the last upstream release is from 2013, so this might be
futile, too.

> (This also happened in the past with SDL packages in Debian for example,
> which contained patches not applied upstream for years changing
> important things about the behaviour).

So why weren't they forwarded upstream? Because nobody cared?

> Now, what I can offer is that if you are interested in the package, want
> to take responsability for the changes, and want to fix the problems in
> the long term (including maybe switching to the fork in github, which
> seems more lively), I will ask you to prepare a new upload fixing these
> and maybe other problems, and will then try to help and sponsor your
> changes.
> 
> Does it sound interesting?

I wasn't aware of the github fork, thanks for mentioning it.

So as I see it, the original version is dead. (Original authors who
are included int he discussion may feel free to contradict me.) This
also concerns me WRT long-term viability. At the moment, I'm using X
and OpenGL, but at some point I'll probably (have to) switch to
Wayland and Vulkan or whatever, and a maintained library has a
better chance to make the switch, I hope.

I've tried it now. I see one of my bugs (3.) is already fixed there
(independently), another one (incorrect blending function) has been
obsoleted by moving it to the caller (I'm fine with that).

So for the other 4 bugs (and 1 new one I found while testing), I
guess my best chances are to offer my patches as pull requests on
github. I'm doing that now.

If/when they are accepted, you might consider uploading that version
to Debian. Until then, a Debian upload of the old version with my
fixes seems like a waste of time. (I've been using a patched
packages for many years now anyway, nobody else seems interested,
and as you said, it would only fix the issues in Debian.)

Regards,
Frank

Bug#888788: stretch-pu: package lxc/1:2.0.7-2+deb9u2

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

iproute has been a transitional package for a while, but the lxc-debian
template was refering to it. Now that iproute has been finally removed,
creating buster or sid containers fails.

This update replaces iproute with iproute2. I am running it on
ci.debian.net

Diff attached.

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

Kernel: Linux 4.14.0-3-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
diff --git a/debian/changelog b/debian/changelog
index 04e3af6..cd60ca9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lxc (1:2.0.7-2+deb9u2) stretch; urgency=medium
+
+  * 0005-debian-Use-iproute2-instead-of-iproute.patch: pull iproute2 instead
+of iproute, fixing the creation of testing and unstable containers after
+the iproute binary package was dropped.
+
+ -- Antonio Terceiro   Mon, 29 Jan 2018 20:23:36 -0200
+
 lxc (1:2.0.7-2+deb9u1) stretch; urgency=medium
 
   * 0003-lxc-debian-don-t-hardcode-valid-releases.patch: don't
diff --git a/debian/patches/0005-debian-Use-iproute2-instead-of-iproute.patch b/debian/patches/0005-debian-Use-iproute2-instead-of-iproute.patch
new file mode 100644
index 000..6bc61e4
--- /dev/null
+++ b/debian/patches/0005-debian-Use-iproute2-instead-of-iproute.patch
@@ -0,0 +1,29 @@
+From: =?utf-8?q?St=C3=A9phane_Graber?= 
+Date: Mon, 29 Jan 2018 18:18:34 -0200
+Subject: debian: Use iproute2 instead of iproute
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: base64
+
+VGhlIHBhY2thZ2UgaGFzIHByZXR0eSBtdWNoIGFsd2F5cyBiZWVuIGlwcm91dGUyIHdpdGggaXBy
+b3V0ZSBiZWluZyBhbgphbGlhcyBmb3IgaXQsIHRoZSBhbGlhcyBpcyBub3cgZ29uZSBzbyB3ZSBu
+ZWVkIHRvIHVzZSBpcHJvdXRlMi4KClNpZ25lZC1vZmYtYnk6IFN0w6lwaGFuZSBHcmFiZXIgPHN0
+Z3JhYmVyQHVidW50dS5jb20+CkJhY2twb3J0LWJ5OiBBbnRvbmlvIFRlcmNlaXJvIDx0ZXJjZWly
+b0BkZWJpYW4ub3JnPgo=
+---
+ templates/lxc-debian.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/templates/lxc-debian.in b/templates/lxc-debian.in
+index 2245770..c927bf6 100644
+--- a/templates/lxc-debian.in
 b/templates/lxc-debian.in
+@@ -271,7 +271,7 @@ dialog,\
+ isc-dhcp-client,\
+ netbase,\
+ net-tools,\
+-iproute,\
++iproute2,\
+ openssh-server
+ 
+ cache=$1
diff --git a/debian/patches/series b/debian/patches/series
index 5e0bb25..587502e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 lxc-2.0-CVE-2017-5985-Ensure-target-netns-is-caller-owned.patch
 0003-lxc-debian-don-t-hardcode-valid-releases.patch
 0004-lxc-debian-don-t-write-C.-locales-to-etc-locale.gen.patch
+0005-debian-Use-iproute2-instead-of-iproute.patch


signature.asc
Description: PGP signature

Bug#888055: ikiwiki: Fenced code block rendering has been broken

[Simon McVittie]

Control: tags -1 + fixed-upstream pending

On Mon, 29 Jan 2018 at 17:56:00 +, Gabriel Filion wrote:
> Simon McVittie:
> > You're right that fenced code blocks are documented as being activated
> > by the MKD_FENCEDCODE flag, but we've never passed that flag to Discount
> > anyway, and they apparently worked in the past. That makes me wonder
> > whether this was an incompatible change in the Discount library or in
> > libtext-markdown-discount-perl, rather than in ikiwiki.

Yes, it looks like this was an incompatible change in the Discount library.

> It's annoying that there's no way to re-enable the fenced code blocks
> through ikiwiki though

I've applied a patch for this upstream, although it's fairly horrible:
the correct API for doing this isn't bound in Text::Markdown::Discount.
I'll include that in the next upload to Debian.

I assume we want them enabled unconditionally, rather than having an
option for it like we do for alphabetically-labelled ordered lists.

http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=f46e429d96ead32943cb2670d7686df8c77de361;hp=400f37967ccca314a052cb3eef7e2863a91ca477

Regards,
smcv

Bug#888787: dpkg-source: mention when picking up an upstream signature

[Mattia Rizzolo]

Package: dpkg-dev
Version: 1.19.0.5
Severity: minor

I see this when building a package with an upstream signature available:

mattia@warren ~/devel/debian/limnoria/limnoria (git)-[master] % dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: applying version
dpkg-source: info: building limnoria using existing 
./limnoria_2018.01.25.orig.tar.gz
dpkg-source: info: building limnoria in limnoria_2018.01.25-1.debian.tar.xz
dpkg-source: info: building limnoria in limnoria_2018.01.25-1.dsc
mattia@warren ~/devel/debian/limnoria/limnoria (git)-[master] % grep orig 
../limnoria_2018.01.25-1.dsc|head -n 2
 fa91c2117b70aaf0f441d69bb13e9a3599fc0d28 876754 limnoria_2018.01.25.orig.tar.gz
 81512d674d42b93681b48aad07a5886d00019981 833 
limnoria_2018.01.25.orig.tar.gz.asc
mattia@warren ~/devel/debian/limnoria/limnoria (git)-[master] %


I'd like for dpkg-source to mention that it detected an .asc (probably
another "using existing" line?)


On a related note, what does that "info: applying version" line mean? :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#888786: pound: CVE-2016-10711

[Salvatore Bonaccorso]

Source: pound
Version: 2.6-6
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for pound.

CVE-2016-10711[0]:
| Apsis Pound before 2.8a allows request smuggling via crafted headers, a
| different vulnerability than CVE-2005-3751.

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-2016-10711
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10711
[1] http://www.apsis.ch/pound/pound_list/archive/2016/2016-10/1477235279000

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888243: Should dpkg remove /etc/opt/ on package removal?

[Guillem Jover]

Hi!

On Sat, 2018-01-27 at 09:46:32 -0500, Jeremy Bicha wrote:
> Background
> =

> One of the supported browsers upstream is Google Chrome, which Google
> installs to /opt/chrome/ . According to the FHS, that means its
> configuration should be stored in /etc/opt/chrome/ . To support Google
> Chrome, chrome-gnome-shell must install files to /etc/opt/chrome/ .

I don't find the FHS very clear on the /etc/opt topic, TBH. Can for
example third-party applications read also /etc/ if it's
present? That could perhaps be another solution, don't know.

> I recently uploaded chrome-gnome-shell 9-2 with Google Chrome support.
> It triggers a pipuparts regression (for itself and all its reverse
> depends like debian-edu) because when chrome-gnome-shell is removed,
> dpkg removes /etc/opt/ since no other package in Debian owns
> /etc/opt/.

Correct.

> base-files creates that directory (in its postinst) because the
> Maintainer believes that that directory should be present in new
> installs for better FHS compliance but that sysadmins should be
> allowed to remove that directory if they like.

Yes, to me this rationale make sense, I guess because I think I've even
found myself cleaning up these kind of dirs on some of my systems! :)

> Suggested Fixes
> 
> 
> 1. "Google Chrome should not install to /opt/ " IMO, I don't think
> this is necessary.

Third-party apps should be able to install into /opt, IMO.

> 2. "chrome-gnome-shell should not install anything to /etc/opt/
> regardless of whether that means not supporting Google Chrome". IMO
> this causes unnecessary harm to Google Chrome users on Debian. Anyway,
> if people support this position, then the lintian auto-reject should
> be re-established.

I think there are two parts to this. One is whether the package should
install files there at all. The other is whether it should ship such
paths as being owned in the dpkg sense.

> 3. "base-files should own /etc/opt/" Rejected by the base-files maintainer.

This could be an easy option, but might annoy users that want to get
rid of those dirs.

> 4. "base-files should introduce a separate, recommended package to own
> directories like /etc/opt/". Also rejected by the base-files
> maintainer.

One additional problem with this approach is that to be able to remove
specific dirs, one would need to add then one package per such
optional dir? :)

> 5. "piuparts could ignore the removal of /etc/opt/" Rejected by the
> piuparts maintainer

I agree that piuparts should not special case this.

> 6. "chrome-gnome-shell could re-create /etc/opt/ in its postrm". Feels
> a bit ugly to me, but maybe acceptable if we can't find a better
> solution.

This might require to preserve sysadmin changes, so if the sysadmin
has removed the directory before package installation, it should get
removed after package removal too.

> 7. How about if dpkg special-case the /etc/opt/ directory and not
> remove it when removing a package that ships files there?

That's not an option. I'd very much like to keep dpkg be as path
neutral as possible by not starting to special case anything which
is distribution-specific.



I think the ideal solution could imply making it possible to mark
pathnames as optional, so that base-files would then mark /opt and
friends as such, and the sysadmin could remove them, and those would
not get restored on upgrade. Of course the interaction with something
like chrome-gnome-shell then becomes a bit tricky, because dpkg then
might need to track the state of the dir when the other package
appeared, so I'm not sure how that'd play out.

For a currently implementable solution, I think you could just ship
those files elsewhere, say just /etc. Then install a noawait trigger
on /opt/ or similar, and when that gets activated
create a symlink in /etc/opt/ from the maintscript
to the place with the actual content.

This has the property that it does not pollute the /etc/opt namespace,
does not trip on any optional path removal, nor piuparts nor lintian
errors, as it will only appear in case the chrome package gets installed.
I think leaving the /etc/opt/ directory (but not its symlinked subdir)
behind after removing is also probably acceptable here.

Would this solve all your problems? Did I miss anything?

Thanks,
Guillem

Bug#888642: Starting blueman fails because /usr/bin/dbus-launch terminated abnormally without any error message

[Michelle Konzack]

OK, it seems, that the error is, that blueman place its modules in

/usr/lib/python3.5/site-packages

and NOT in

/usr/lib/python3.5/dist-packages

Is this an upstream bug since "site-packages" appear only in the
orig.tar.gz

13899: configure
13943: configure
11092: aclocal.m4
11121: aclocal.m4
11163: aclocal.m4

autom4te.cache
2836: traces.0
2865: traces.0
2907: traces.0
13899: output.1
13943: output.1
13903: output.0
13947: output.0


Thanks in avance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

Bug#888649: apt-listbugs: Fails on ipv6

[Francesco Poli]

Control: reassign -1 ruby-httpclient 2.8.3-1
Control: affects -1 + apt-listbugs
Control: tags -1 - moreinfo



On Mon, 29 Jan 2018 21:08:04 +0100 eingousef wrote:

> On Sun, Jan 28, 2018 at 03:19:04PM +0100, Francesco Poli wrote:
> > [...]
> > > Versions of packages apt-listbugs recommends:
> > > pn  ruby-httpclient  
> > [...]
> >
> > I see that you do not have the recommended ruby-httpclient package
> > installed: could you please try to install it with
> >
> >   # aptitude install ruby-httpclient
> >
> > and see whether you still have issues with your IPv6 connection?
> >
> > Please let me know.
> > Thanks for your time and for using apt-listbugs!
> >
> >
>
> After installing that package it still fails but it's more verbose:
>
> Performing actions...
> Récupération des rapports de bogue… 0% Echec
> Échec de récupération des rapports de bogue depuis le serveur avec le message 
> d'erreur suivant :
> Err : HTTPClient::KeepAliveDisconnected:
> Cela peut venir d'une connexion réseau inactive, de problèmes de serveurs 
> mandataires ou de l'arrêt du serveur du
> BTS lui-même. Veuillez vérifier la configuration réseau et recommencer
> Réessayer de télécharger les informations du bogue ? [Y/n]
> Un paquet à la fois ? [Y/n]
> Un rapport de bogue à la fois ? [Y/n]
> Récupération des rapports de bogue… Fait



Dear Debian Ruby Extras Maintainers
I am reassigning a [bug](https://bugs.debian.org/888649) to package
ruby-httpclient, since a user of apt-listbugs is having issues with an
IPv6 connection.
It seems that a similar issue shows up without ruby-httpclient (when
apt-listbugs uses the HTTP library from Ruby standard library), but
ruby-httpclient produces a more verbose error message.

I have too little experience in debugging HTTP connection issues, and
zero experience with IPv6: I am not sure whether the problem lies in
some IPv6 link misconfiguration or in an actual bug of the Ruby HTTP
client libraries.

Could you please help the user in the investigation?

Thanks for your time and dedication!
Bye.

--
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1iZf0c3Gcu.pgp
Description: PGP signature

Bug#888778: nageru: build-depends on libluajit-5.1-dev, not available on s390x

[Steinar H. Gunderson]

On Mon, Jan 29, 2018 at 09:19:21PM +0100, Emilio Pozuelo Monfort wrote:
> Package: nageru
> Version: 1.6.4-1
> Severity: serious
> 
> Hi,
> 
> Your package now depends on libluajit-5.1-dev, which is not available on s390x
> (and other non-release architectures).

There's no way Nageru would run on s390x (it requires OpenGL and USB, for one).
Is s390x a release architecture these days? If so, I can simply exclude it
from the architecture list.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#888784: numpy.ctypeslib.load_library looks for incorrect lib suffix on python2

[Yaroslav Halchenko]

Package: python-numpy
Version: 1:1.13.3-2
Severity: normal

I guess it is a rare usecase since I haven't spotted another bugreport, and we
have managed to miss it for a while I guess.

dh_python2 installs built .so extensions with a arch specific suffix, e.g.:

neurodebian@smaug ~/deb/builds/pymvpa2/2.6.3-1 % grep dh_python2.*so 
pymvpa2_2.6.3-1_amd64.build
I: dh_python2 fs:322: renaming _svmc.so to _svmc.x86_64-linux-gnu.so
I: dh_python2 fs:322: renaming smlrc.so to smlrc.x86_64-linux-gnu.so

and in pymvpa2 we have been using numpy.ctypeslib.load_library to load
them afterwards, but apparently [1,2] it failed to load them for a while,
and that is due to following code in load_library:

  so_ext3 = '.%s-%s.so' % (sysconfig.get_config_var('SOABI'),
   sysconfig.get_config_var('MULTIARCH'))

which is correct for python3, but wouldn't work in python2 since SOABI is not
defined, so we end up looking for .None-x86_64-linux-gnu.so :

$> strace -f python -c 'from numpy.ctypeslib import load_library; 
print(load_library("libXXX", "/"))' 2>&1 | grep libXXX 
[pid  7542] stat("/libXXX.None-x86_64-linux-gnu.so", 0x7fffe43276b0) = 
-1 ENOENT (No such file or directory)
[pid  7542] stat("/libXXX.so", 0x7fffe43276b0) = -1 ENOENT (No such 
file or directory)

I am not sure about "correct" way to address it, but a quick workaround would be

in python2, do not prepend SOABI.  Or alternatively, do not prepend if
sysconfig.get_config_var('SOABI') is not defined altogether

[1] https://github.com/PyMVPA/PyMVPA/issues/564
[2] https://github.com/PyMVPA/PyMVPA/issues/568

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages python-numpy depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-5
ii  libblas3 [libblas.so.3]3.7.1-4
ii  libc6  2.26-2
ii  liblapack3 [liblapack.so.3]3.7.1-4
ii  libopenblas-base [liblapack.so.3]  0.2.20+ds-4
ii  python 2.7.14-4
ii  python2.7  2.7.14-4

python-numpy recommends no packages.

Versions of packages python-numpy suggests:
ii  gcc   4:7.2.0-1d1
ii  gfortran  4:7.2.0-1d1
ii  python-dev2.7.14-4
ii  python-nose   1.3.7-3
ii  python-numpy-dbg  1:1.13.3-2
pn  python-numpy-doc  

-- no debconf information

Bug#888785: [diaspora-installer] [INTL:de] German translation of the debconf template

[Pfannenstein Erik]

Package: diaspora-installer
Version: 0.7.2.0+debian4
Severity: wishlist
Tags: l10n

--- Please enter the report below this line. ---
Dear maintainer,

here is the German version of Diaspora's debconf template. Translated, 
reviewed and ready to be applied.

Best Regards,
Erik


--- System information. ---
Architecture: 
Kernel:   Linux 4.14.14-towo.1-siduction-amd64

Debian Release: buster/sid
  500 unstablewww.deb-multimedia.org 
  500 unstablepackages.siduction.org 
  500 unstableftp.de.debian.org 
  500 stable  repo.skype.com 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.# GERMAN TRANSLATION OF THE DIASPORA-INSTALLER DEBCONF TEMPLATE
# Copyright (C) 2015 THE DIASPORA-INSTALLER AUTHORS
# This file is distributed under the same license as the DIASPORA-INSTALLER package.
# Erik Pfannenstein , 2015, 2018.
msgid ""
msgstr ""
"Project-Id-Version: diaspora-installer\n"
"Report-Msgid-Bugs-To: diaspora-instal...@packages.debian.org\n"
"POT-Creation-Date: 2017-04-27 12:48+0530\n"
"PO-Revision-Date: 2018-01-24 20:34+0200\n"
"Last-Translator: Erik Pfannenstein \n"
"Language-Team: debian-l10n-ger...@lists.debian.org\n"
"Language: de\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: Virtaal 0.7.1\n"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid "Host name for this instance of Diaspora:"
msgstr "Rechnernname für diese Diaspora-Instanz:"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"Please choose the host name which should be used to access this instance of "
"Diaspora."
msgstr ""
"Bitte wählen Sie den Rechnernamen, unter dem diese Diaspora-Instanz erreichbar "
"sein soll."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This should be the fully qualified name as seen from the Internet, with the "
"domain name that will be used to access the pod."
msgstr ""
"Es sollte der vollqualifizierte Rechnername sein, wie er vom Internet aus "
"zu sehen ist, einschließlich des Domain-Namens, unter dem auf den Pod "
"zugegriffen wird."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"If a reverse proxy is used, give the hostname that the proxy server responds "
"to."
msgstr ""
"Geben Sie den Rechnernamen ein, auf den der Proxy-Server antwortet, falls "
"einer im Einsatz ist."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This host name should not be modified after the initial setup because it is "
"hard-coded in the database."
msgstr ""
"Dieser Rechnername sollte nach der Ersteinrichtung nicht mehr verändert "
"werden, weil er in der Datenbank fest kodiert eingetragen wird."

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid "PostgreSQL application password"
msgstr "PostgreSQL-Passwort"

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid ""
"You can leave the PostgreSQL application password blank, as the \"ident\" "
"authentication method is used, allowing the diaspora user on the system to "
"connect to the Diaspora database without a password."
msgstr ""
"Sie können das PostgreSQL-Passwort leer lassen, weil die »ident«-"
"Anmeldungsmethode genutzt wird. Sie ermöglicht es dem diaspora-Benutzer auf "
"dem System, ohne Passwort auf die Diaspora-Datenbank zuzugreifen."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid "Enable https?"
msgstr "HTTPS aktivieren?"

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Enabling https means that an SSL/TLS certificate is required to access this "
"Diaspora instance (as Nginx will be configured to respond only to https "
"requests). A self-signed certificate is enough for local testing (and can be "
"generated using, for instance, the package easy-rsa), but will not be "
"accepted for federation with other Diaspora pods."
msgstr ""
"HTTPS zu aktivieren, bedeutet, dass für den Zugriff auf diese Diaspora-"
"Instanz ein SSL/TLS-Zertifikat erforderlich ist (weil Nginx so konfiguriert "
"wird, dass er nur auf HTTPS-Anfragen antwortet). Für lokale Tests reicht ein "
"selbstsigniertes Zertifikat (welches bspw. mit dem Paket easy-rsa erzeugt "
"werden kann), eine Föderation mit anderen Diaspora-Pods kann man damit aber "
"nicht eingehen."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Some certificate authorities like Let's Encrypt (letsencrypt.org), StartSSL "
"(startssl.com) offer free SSL/TLS certificates that work with Diaspora; "
"however, certificates provided by CAcert will not work with Diaspora."
msgstr ""
"Einige Zertifizierungsstellen (CAs) wie Let's Encrypt (letsencrypt.org) und "
"StartSSL (startssl.com) bieten kostenlose 

Bug#888297: p7zip: Multiple Memory Corruptions via RAR and ZIP

[Salvatore Bonaccorso]

Attaching the used patch for reference.

Regards,
Salvatore
From: =?utf-8?q?Antoine_Beaupr=C3=A9?= 
Date: Sun, 28 Jan 2018 21:19:50 +0100
Subject: backport of the CVE-2017-17969 fix from 7zip 18.00-beta

---
 CPP/7zip/Compress/ShrinkDecoder.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/CPP/7zip/Compress/ShrinkDecoder.cpp b/CPP/7zip/Compress/ShrinkDecoder.cpp
index 80b7e67..4acdce5 100644
--- a/CPP/7zip/Compress/ShrinkDecoder.cpp
+++ b/CPP/7zip/Compress/ShrinkDecoder.cpp
@@ -121,7 +121,12 @@ HRESULT CDecoder::CodeReal(ISequentialInStream *inStream, ISequentialOutStream *
 {
   _stack[i++] = _suffixes[cur];
   cur = _parents[cur];
-}
+  if (i >= kNumItems)
+break;
+ }
+
+if (i >= kNumItems)
+  break;
 
 _stack[i++] = (Byte)cur;
 lastChar2 = (Byte)cur;

Bug#888783: stretch-pu: package postfix/3.1.8-0+deb9u1

[Scott Kitterman]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

This update is intended to accomplish several improvements:

1.  The regression introduced by the libdb security fix is corrected by
upstream.  This was tested by me and is in Unstable in 3.2.5-1.  This
should be allowed to migrate to testing before this upload for stable.
This issue was specifically requested to be fixed by a SRM.

2.  A packaging fix to resolve one cause of postfix faling to start if
inet_interfaces is set to something other than all.  This fix has been in
Unstable/Testing since last year with no negative feedback.

3.  Fixes a regression from oldstable where dynamic maps were not available to
the sendmail command.

4.  Fixes a significant issue in DANE support (new feature for stretch).

5.  Other low risk (including documentation) fixes.

There are also a couple of things that are here that won't affect the user
either way:

1.  A slight bit of patch cruft due to needing to refresh a patch that
slightly colllided with the fix for the security regression.  Ideally it
wouldn't be in the diff, but it didn't seem to clutter things too badly
and it seemed lower risk not to hand edit the patch.

2.  Added a postfix 3.1 specific debian watch file for the maintainer's
convenience.  This is useful for my work flow and has no user impact or
risk.

As usual, the postfix upstream is very careful and thorough in micro-release
updates and all the upstream changes are good things for our users.  I have
the proposed package in production and have not noted any issues.

Thanks for reviewing,

Scott K
diff -Nru postfix-3.1.6/debian/changelog postfix-3.1.8/debian/changelog
--- postfix-3.1.6/debian/changelog	2017-09-27 00:59:24.0 -0400
+++ postfix-3.1.8/debian/changelog	2018-01-29 12:31:22.0 -0500
@@ -1,3 +1,43 @@
+postfix (3.1.8-0+deb9u1) stretch; urgency=medium
+
+[Scott Kitterman]
+
+  * Rewrite debian/postfix-instance-generator to avoid use of postmulti to fix
+failures when inet_interfaces != all.  Closes: #882141
+  * Refresh patches
+  * Add postfix 3.1 specific watch file
+
+  [Wietse Venema]
+
+  * 3.1.7
+- Bugfix (introduced: Postfix 3.1): DANE support. Postfix
+  builds with OpenSSL 1.0.0 or 1.0.1 failed to send email to
+  some sites with "TLSA 2 X X" records associated with an
+  intermediate CA certificate. Problem report and initial
+  fix by Erwan Legrand. File: src/tls/tls_dane.c.
+- Bugfix (introduced: Postfix 3.0) missing dynamicmaps support
+  in the Postfix sendmail command broke authorized_submit_users
+  with a dynamically-loaded map type. File: sendmail/sendmail.c. 
+  * 3.1.8
+- Bugfix (introduced: Postfix 2.1): don't log warnings
+  that some restriction returns OK, when the access map
+  DISCARD feature is in effect. File: smtpd/smtpd_check.c.
+- Bugfix (introduced: 20170611): the DB_CONFIG bugfix broke
+  Berkeley DB configurations with a relative pathname.  File:
+  util/dict_db.c. Closes: #879200
+- Workaround: reportedly, some res_query(3) implementation
+  can return -1 with h_errno==0. Instead of terminating with
+  a panic, the Postfix DNS client now logs a warning and sets
+  h_errno to TRY_AGAIN. File: dns/dns_lookup.c.
+- Documentation patches by Sven Neuhaus. Files:
+  proto/FORWARD_SECRECY_README.html, proto/SMTPD_ACCESS_README.html.
+- Cleanup: missing mailbox seek-to-end error check in the
+  local(8) delivery agent. File: local/mailbox.c.
+- Cleanup: incorrect mailbox seek-to-end error message in the
+  virtual(8) delivery agent. File: virtual/mailbox.c.
+
+ -- Scott Kitterman   Mon, 29 Jan 2018 12:31:19 -0500
+
 postfix (3.1.6-0+deb9u1) stretch; urgency=medium
 
 [Wietse Venema]
diff -Nru postfix-3.1.6/debian/patches/11_postmap_update.diff postfix-3.1.8/debian/patches/11_postmap_update.diff
--- postfix-3.1.6/debian/patches/11_postmap_update.diff	2017-09-27 00:26:51.0 -0400
+++ postfix-3.1.8/debian/patches/11_postmap_update.diff	2018-01-29 12:21:20.0 -0500
@@ -1,7 +1,7 @@
 Index: postfix/html/postmap.1.html
 ===
 postfix.orig/html/postmap.1.html	2017-09-27 00:26:44.474769942 -0400
-+++ postfix/html/postmap.1.html	2017-09-27 00:26:44.466769942 -0400
+--- postfix.orig/html/postmap.1.html	2018-01-29 12:21:01.200764381 -0500
 postfix/html/postmap.1.html	2018-01-29 12:21:01.196764381 -0500
 @@ -10,7 +10,7 @@
 postmap - Postfix lookup table management
  
@@ -24,8 +24,8 @@
instead of the default configuration directory.
 Index: postfix/man/man1/postmap.1
 ===
 postfix.orig/man/man1/postmap.1	2017-09-27 00:26:44.474769942 -0400
-+++ postfix/man/man1/postmap.1	2017-09-27 00:26:44.466769942 

Bug#878088: [Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

On 29-01-2018 00:11, Markus Koschany wrote:
> 
> I noticed that you had to import apt but reportbug does not depend on
> python3-apt. After I had installed this package it worked. I also
> believe you don't need to check for the upstream changelog.gz file, the
> Debian changelog should be sufficient.

There is already a patch in some other bug report that adds a Depends:
on python3-apt.  You are right that this is also required if the new
function gets accepted.

We need to look for both changelog files, since native packages (like
reportbug) do not have a separate Debian one.


Your patch looks good to me now. Only minor nits:

> reportbug.debdiff
> 
> 
> diff -Nru reportbug-7.1.8/bin/reportbug reportbug-7.1.8+nmu1/bin/reportbug
> --- reportbug-7.1.8/bin/reportbug 2017-12-29 05:25:43.0 +0100
> +++ reportbug-7.1.8+nmu1/bin/reportbug2018-01-23 20:43:14.0 
> +0100
> @@ -32,6 +32,8 @@
>  import optparse
>  import re
>  import locale
> +import requests
> +import json
>  import subprocess
>  import shlex
>  import email
> @@ -1926,6 +1928,37 @@
>  listcc += ui.get_multiline(
>  'Enter any additional addresses this report should be sent 
> to; press ENTER after each address.')
>  
> +# If the bug is reported against a package with a version that
> +# indicates a security update add the security or lts team to CC
> +# after user confirmation
> +if pkgversion and package and not self.options.offline and not 
> self.options.mode == 'novice':

Instead of "not self.options.mode == 'novice', please use
"mode > MODE_NOVICE"

> +if utils.is_security_update(package, pkgversion):
> +if ui.yes_no('Do you want to report a regression because of 
> a security update? ',
> + 'Yes, please inform the LTS and security 
> teams.',
> + 'No or I am not sure.', True):
> +regex = re.compile('(\+|~)deb(\d+)u(\d+)')
> +secversion = regex.search(pkgversion)
> +distnumber = secversion.group(2)

shorter: distnumber = re.search('[+~]deb(\d+)u\d+', pkgversion).group(1)

> +support = 'none'
> +email_address = []

email_address = 'none'

> +try:
> +r = 
> requests.get('https://security-tracker.debian.org/tracker/distributions.json',
> +timeout=self.options.timeout)
> +data = r.json()
> +for key, value in data.items():
> +if distnumber == value['major-version']:
> +if value['support']:
> +support = value['support']
> +if value['contact']:
> +email_address = value['contact']

If we can trust that no fields are null, then the last two ifs are not
needed and we can drop them to simplify the code. If we don't trust the
input, should we protect against other errors as well? We'd get
TypeError if some `value` is not a dict, and KeyError if any key is not
there.

> +
> +if support != 'none':

if support != 'none' and utils.check_email_addr(email_address)


> +listcc += [email_address]

else:
ewrite('No support team contact address could be identified.\n')

> +
> +except requests.exceptions.RequestException:

If we want to also catch TypeError and KeyError, do it here or in a
separate except clause?

> +ewrite('Unable to connect to 
> security-tracker.debian.org.\n'
> +   'Please try again later or contact the LTS or 
> security team via email directly.\n')
> +
>  if severity and rtype:
>  severity = debbugs.convert_severity(severity, rtype)
>  

Bug#888777: [pkg-go] Bug#888777: golang-github-miekg-dns: CVE-2017-15133

[Michael Stapelberg]

After fixing this bug, we’ll need to rebuild the following binaries:

golang-github-hashicorp-consul-dev
golang-github-hashicorp-mdns-dev
golang-github-xenolf-lego-dev
docker.io
prometheus-blackbox-exporter
coyim
rawdns
goiardi
prometheus
dnss
kubernetes-client
golang-dns-dev
golang-github-hashicorp-memberlist-dev
golang-github-skynetservices-skydns-dev

On Mon, Jan 29, 2018 at 8:57 PM, Salvatore Bonaccorso 
wrote:

> Source: golang-github-miekg-dns
> Version: 0.0~git20161018.0.58f52c5-1
> Severity: important
> Tags: patch security upstream
>
> Hi,
>
> the following vulnerability was published for golang-github-miekg-dns.
>
> CVE-2017-15133[0]:
> | A denial of service flaw was found in miekg-dns before 1.0.4. A remote
> | attacker could use carefully timed TCP packets to block the DNS server
> | from accepting new connections.
>
> 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-2017-15133
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15133
> [1] https://github.com/miekg/dns/issues/627
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#712394: lintian: Warn if override_dh_auto_test target doesn't check for DEB_BUILD_OPTIONS=nocheck

[Mattia Rizzolo]

On Mon, Jan 29, 2018 at 08:24:47PM +0530, Chris Lamb wrote:
> Fixed in Git, pending upload:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=deaf67c91e17072d7963b457c9a7f16c2ee309e4

That commit does the following:
+if (my $line = $overridden{'dh_auto_test'}) {
+tag 'override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES',
+  "(line $line)"
+  if $rules_per_target{'override_dh_auto_test'}
+  and none { m/(DEB_BUILD_OPTIONS|nocheck)/ } @conditionals;
+}

This is going to trigger tons of false positives for packages doing
something like:

override_dh_auto_test:
FOO=bar dh_auto_test
-rm -f file-containing-test-output

which is otherwise file and respects DEB_BUILD_OPTIONS=nocheck.

I think it's very hard to properly detect such cases, but a way to avoid
all those fpos would be to exclude the tags from overrides containing a
call to dh_auto_test: this will lead to some false negatives (for
packages that in their override_dh_auto_test do something that effectly
is not idenpotent and probably causes ftbfs for nocheck, or stuff like
that), but it's probably a lot better than the many fpos I can think of.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#888782: fp-compiler-3.0.4: fpselect segfaults on arm64

[Adam Borowski]

Package: fp-compiler-3.0.4
Version: 3.0.4+dfsg-14
Severity: normal

Hi!
The following program segfaults on arm64:

.
uses baseunix;
begin
  fpselect(input, nil)
end.
`
(Segfault in fpc doesn't give a message, just silently aborts the program
with return code 216.)

On amd64 and armhf, all is ok -- the above program waits for something to be
available on stdin, then completes successfully.


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.15.0-00183-ga494935d9d25 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages fp-compiler-3.0.4 depends on:
ii  binutils   2.29.90.20180122-1
ii  debconf [debconf-2.0]  1.5.65
ii  fp-units-rtl-3.0.4 3.0.4+dfsg-14
ii  libc6  2.26-6

Versions of packages fp-compiler-3.0.4 recommends:
ii  fp-utils-3.0.4  3.0.4+dfsg-14

Versions of packages fp-compiler-3.0.4 suggests:
ii  fp-docs-3.0.4  3.0.4+dfsg-14

-- debconf information:
  fp-compiler/windres:
  fp-compiler/rename_cfg: true
  fp-compiler/windres-select: Select manually

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

[Mattia Rizzolo]

On Mon, Jan 29, 2018 at 02:05:07PM +, Ian Jackson wrote:
> Ah.  But AIUI source-only upload *must not* be accompanied by an
> _amd64.buildinfo (with the same name, anyway) because that *clashes*
> with the buildd's .buildinfo.

dak handles them correctly whenever there is not a queue in front of the
suite.  So for example doing that for sid and exp uploads is totally
fine, whereas doing that for stable uploads ends up in headaches for
everybody.

> Right.  I was aware of this.  Of course `env' output is not reliably
> parseable if the values might contain newlines but I think we can hope
> that it doesn't and read it accordingly in dgit.

haha, don't keep your hopes too high :P
If you watch my own output you'll see that it does contain newlines
within the variables :)
And also it's not only `env` output, but it's `(set -o posix; set)`
followed by `env` with random messages from pbuilder itself.
Let's just say that `pbuilder dumpconfig` is not really usable for
parsing, it's mostly a debugging tool IMHO.

> (Ideally I think pbuilder dumpconfig would fail if the output is
> misleading.)

Of course it doesn't, and I don't believe it's its job to do it.

Then, there are other gotchas, that make the whole "ask pbuilder what
its configuration is" kind of pointless: pbuilderrc is a shell script
and therefore interpreted at runtime.  If a user wants to (I do for some
things) it can compute values according to what I've been asked to do,
so for example somebody may have options with different values according
to what subcommand is being run.
But I believe this is very similar for sbuild as well, isn't it?


Anyway, that's all speculation, I believe we should check what the
problems are, and what we'd need to do before worrying about how the
world is not nice to us.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#888780: vibe.d: FTBFS: meson: Subproject_dir must not contain a path segment

[Matthias Klumpp]

2018-01-29 21:19 GMT+01:00 Emilio Pozuelo Monfort :
> Source: vibe.d
> Version: 0.8.1-2
> Severity: serious
>
> On a rebuild against new libphobos, your package failed to build from source,
> see:
>
> https://buildd.debian.org/status/package.php?p=vibe.d

This is a known regression in Meson, merging with the existing bug.

Cheers,
Matthias

Bug#888779: appstream-generator: FTBFS: meson: Subproject_dir must not contain a path segment

[Matthias Klumpp]

2018-01-29 21:19 GMT+01:00 Emilio Pozuelo Monfort :
> Source: appstream-generator
> Version: 0.6.8-2
> Severity: serious
>
> Hi,
>
> On a rebuild against new libphobos, your package failed to build from source,
> see:
>
> https://buildd.debian.org/status/package.php?p=appstream-generator

This is a known regression in Meson, merging with the existing bug.

Cheers,
Matthias

Bug#887403: Info received (Bug#887403: Acknowledgement (RFS: budgie-extras/0.4.0-1))

[foss.freedom]

ok,

  I have done a fresh upload with the following revised changelog:

  * New upstream release
  * Packaging Changes:
- debian/control and debian/compat: update to v11
- debian/control: Bump Standards-Version - no changes required
- debian/control: new binary packages budgie-rotation-lock-applet,
  budgie-clockworks-applet,
  budgie-dropby-applet
- debian/copyright: 2018 year updates
- debian/rules remove ninja make rules since debhelper can deal
  with meson builds
- remove not needed debian/files
- signing key; move and rename to debian/upstream

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.4.1-1.dsc



On 27 January 2018 at 16:09, Debian Bug Tracking System
 wrote:
> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Mentors 
>
> If you wish to submit further information on this problem, please
> send it to 887...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 887403: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887403
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#888712: netgen: Please update to newest package version 6.2.x

[kkremitzki]

On Mon, 2018-01-29 at 17:45 +0100, Anton Gladky wrote:
> Hi Kurt,
> 
> thanks for the info. It would be much better if upstream
> makes a release of netgen, so we can upload it into
> the Debian archive. Pulling the rolling release is not
> quite convenient.
> 
> Anton
> 

They are making (monthly) releases, it's just that they're not tagging
them properly in the github.com/ngsolve/netgen repository--the tags are
instead in github.com/ngsolve/ngsolve using ngsolve/netgen as a git
submodule, so for example one can do:

git clone --recursive https://github.com/ngsolve/ngsolve -b v6.2.1801
cd external_dependencies/netgen

to get at the proper commit(s), as well. Is that acceptable? The main
reason I wrote 6.2.x is because I expect 6.2.1802 will be out by the
time I'm ready to upload a package to mentors.debian.net.

P.S. I forgot to mention in the initial bug report that we (FreeCAD
commnity) have a discussion going on this topic with one of the
upstream developers, Mathias Hochsteger, in this thread: https://forum.
freecadweb.org/viewtopic.php?f=10=26278=100

Bug#888736: [Pkg-zfsonlinux-devel] Bug#888736: zfs-dkms: assign a seperate group zfsadm to /dev/zfs

[Richard Laager]

On 01/29/2018 05:10 AM, Hans Freitag wrote:
> I would like to have /dev/zfs assigned to a seperate group zfsadm. The device
> is currently assigned to the group disk.

As of 0.7.0, ZFS on Linux supports delegated administration. That is,
permission checks are handled by the ZFS module, not by the permissions
of /dev/zfs.

After 0.7.0, the permissions on /dev/zfs should be set to 0666.
Obviously the group no longer matters, and so it can be root.

See:
https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.0

-- 
Richard

Bug#867731: RFS: smart-mode-line/2.11.0-1 [ITP]

[Nicholas D Steeves]

Control: retitle -1 RFS: smart-mode-line/2.11.0-1 [ITP]

Bart, thank you for noticing and retitling.

Unstable is now once again the target distribution, with a new
upstream release.


signature.asc
Description: PGP signature

Bug#888780: vibe.d: FTBFS: meson: Subproject_dir must not contain a path segment

[Emilio Pozuelo Monfort]

Source: vibe.d
Version: 0.8.1-2
Severity: serious

On a rebuild against new libphobos, your package failed to build from source,
see:

https://buildd.debian.org/status/package.php?p=vibe.d

Cheers,
Emilio

Bug#888779: appstream-generator: FTBFS: meson: Subproject_dir must not contain a path segment

[Emilio Pozuelo Monfort]

Source: appstream-generator
Version: 0.6.8-2
Severity: serious

Hi,

On a rebuild against new libphobos, your package failed to build from source,
see:

https://buildd.debian.org/status/package.php?p=appstream-generator

Cheers,
Emilio

Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then

[Sebastian Pipping]

Interesting!


For the record, I was not using Magit or even emacs but KWrite, Kate,
and Komodo IDE at the time.  I guess one of these may have a similar issue.

Best



Sebastian

Bug#888778: nageru: build-depends on libluajit-5.1-dev, not available on s390x

[Emilio Pozuelo Monfort]

Package: nageru
Version: 1.6.4-1
Severity: serious

Hi,

Your package now depends on libluajit-5.1-dev, which is not available on s390x
(and other non-release architectures). Maybe in those architectures the package
can go back to lua? See https://buildd.debian.org/status/package.php?p=nageru

Emilio

Bug#823190: lintian: Please error out on orig tarball sigs for source 1.0

[Mattia Rizzolo]

On Mon, Jan 29, 2018 at 09:01:48PM +0100, Mattia Rizzolo wrote:
> Since 1.18.something dpkg can handle unpacking of 1.18.15, and since
> dpkg 1.19.0 it also creates them.  yes it was a issue back then but now
> it's correctly handled, and dak accepts them since last week.

More info in this ftp.debian.org's bug: https://bugs.debian.org/888448

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#888649: apt-listbugs: Fails on ipv6

[eingousef]

On Sun, Jan 28, 2018 at 03:19:04PM +0100, Francesco Poli wrote:
> [...]
> > Versions of packages apt-listbugs recommends:
> > pn  ruby-httpclient  
> [...]
> 
> I see that you do not have the recommended ruby-httpclient package
> installed: could you please try to install it with
> 
>   # aptitude install ruby-httpclient
> 
> and see whether you still have issues with your IPv6 connection?
> 
> Please let me know.
> Thanks for your time and for using apt-listbugs!
> 
> 

After installing that package it still fails but it's more verbose:

Performing actions...   
 
Récupération des rapports de bogue… 0% Échec
 
Échec de récupération des rapports de bogue depuis le serveur avec le message 
d'erreur suivant : 
Err : HTTPClient::KeepAliveDisconnected:
 
Cela peut venir d'une connexion réseau inactive, de problèmes de serveurs 
mandataires ou de l'arrêt du serveur du
BTS lui-même. Veuillez vérifier la configuration réseau et recommencer  
 
Réessayer de télécharger les informations du bogue ? [Y/n]  
 
Un paquet à la fois ? [Y/n] 
 
Un rapport de bogue à la fois ? [Y/n]   
 
Récupération des rapports de bogue… Fait
 

Regards,

-- 

Bug#888571: python3-apt depends on python3 (<< 3.6)

[jean-christophe manciot]

@Axel Beckert

It appears that some debian files have been modified in the meantime in the
sources available at https://packages.debian.org/source/sid/python-apt and
now we can build python-apt to generate the correct dependencies for
python3-apt binary: python3 (<< 3.7), python3 (>= 3.6~),


On Mon, Jan 29, 2018 at 8:45 PM, jean-christophe manciot <
actionmysti...@gmail.com> wrote:

> @Axel Beckert
>
>
>> That's wrong. The corresponding sources _are_ shown on
>> https://packages.debian.org/source/sid/python-apt. It's the files
>> called python-apt_1.4.0~beta3.dsc and python-apt_1.4.0~beta3.tar.xz
>>
>>
> No, you're confused. The whole point of this bug report is that *building*
> python-apt from the sources downloaded from https://packages.debian.o
> rg/source/sid/python-apt is that the binary python3-apt is incompatible
> with python3 >= 3.6.
> If you try to built the packages from those sources, you'll discover that
> the version is *1.4.0~beta3*, as indicated in debian/changelog.
>
> No. Nowhere in Debian you will find a binary package without an
>> according source package. Period.
>>
>
> It depends on what you call "sources". If you put the *debian* folder
> aside from your definition, then we agree.
>
> That might be an issue of your downloader.
>
>
> You're right here. I downloaded the python-apt binaries with Google
> chrome 64.0.3282.119 (Official Build) (64-bit) on Linux.
> I have just reported that issue to Google.
>
> --
> Jean-Christophe Manciot
>



-- 
Jean-Christophe

Bug#823190: lintian: Please error out on orig tarball sigs for source 1.0

[Mattia Rizzolo]

On Tue, Jan 30, 2018 at 12:45:56AM +0530, Chris Lamb wrote:
> tags 823190 + pending
> thanks
> 
> Fixed in Git, pending upload:

Errr, no.

Since 1.18.something dpkg can handle unpacking of 1.18.15, and since
dpkg 1.19.0 it also creates them.  yes it was a issue back then but now
it's correctly handled, and dak accepts them since last week.

>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=2f1efb44994b066c22a985c09a853fc9583aacf8

Please revert this commit and close this bug as no action needed
anymore.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#888777: golang-github-miekg-dns: CVE-2017-15133

[Salvatore Bonaccorso]

Source: golang-github-miekg-dns
Version: 0.0~git20161018.0.58f52c5-1
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for golang-github-miekg-dns.

CVE-2017-15133[0]:
| A denial of service flaw was found in miekg-dns before 1.0.4. A remote
| attacker could use carefully timed TCP packets to block the DNS server
| from accepting new connections.

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-2017-15133
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15133
[1] https://github.com/miekg/dns/issues/627

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#825383: /usr/share/hplip/doctor.py: hp-doctor will not accept sudo password and there is no root account

[Brian Potkin]

severity 825383 minor
thanks



On Mon 29 Jan 2018 at 14:41:50 +, Brian Potkin wrote:

> On Sun 28 Jan 2018 at 17:40:46 +, Brian Potkin wrote:
> 
> > On Sun 28 Jan 2018 at 17:11:49 +0100, Reinhard John wrote:
> > 
> > > I removed two dependencies to test the proposed workaround. Besides: The
> > > correct path of the file is /usr/share/hplip/base/password.py.
> > > Now the hp-doctor asked for the sudoer´s password. But: the installation 
> > > of
> > > the missing dependencies failed.
> > > 
> > > > ENTER SUDO PASSWORD
> > > > ---
> > > > Please enter the sudoer (reinhard)'s password:
> > > > Do you want to update repository and Install missing/incompatible
> > > > packages. (a=install all*, c=custom_install, s=skip):a
> > > > Updating repository
> > > > ---
> > > > Installing Missing/Incompatible packages
> > > > 
> > > > cmd =libssl-dev
> > > > error: Failed to install 'libssl-dev' package, please install manually.
> > > > cmd =libsane-dev
> > > > error: Failed to install 'libsane-dev' package, please install manually.
> > > 
> > > Do you think this error results of a follow-up configuration problem in
> > > another file?
> > > 
> > > I will send a bug report to the hplip developers. If there are any 
> > > solutions
> > > I will post them here.
> > 
> > Success, then; you do not need a root password. Thanks for the testing
> > and the path correction.
> > 
> > I can see no reason why you would need those two files to print or scan.
> > Forget about them.
> 
> My response was less than adequate; apologies. I had actually tested
> hp-plugin after changing su to sudo in password.py. It worked but you
> caused me to wonder why. hp-plugin downloads and installs a plugin.
> Downloading requires no root privileges but installing does, and the
> privileges have already been gained via sudo.

Without any change to password.py the plugin will install with

 sudo hp-plugin -i

So what was chrysn referring to?
 
> hp-doctor uses/usr/share/hplip/installer/distros.dat. The [debian]
> section updates and downloads packages with su -c. I changed all these
> and su_sudo to sudo. I'm using a 9.3 stretch version and also changed
> /etc/issue and /etc/debian_version to 9.1, which is the last entry on
> the versions line.

The last entry is 8.6 on the versions line and only /etc/debian_version
has to be altered to 8.6.
 
> That worked but you cannot expect a user to go through all of this.
> Devising a solution still lies in the hands of the hplip team. Whether
> they will implement one is another matter.

If you are beginning to think I am not very used to the sudo command you
would be quite right. :)

As far as I can make out, a print queue and a plugin can be set up with
sudo. hp-doctor appears to be the only utility affected by the lack of a
root password on the system. I wouldn't rate its importance on the same
level as hp-setup and hp-plugin.

hp-check appears to duplicate hp-doctor's diagnostic ability and the
Missing Required Dependencies lists *-dev programs, which are not needed
to print and scan. Others programs listed as missing are known to be on
a Debian system; libc6, for example. And why cups-bsd is required is
beyond me.

Reducing the severity accordingly.

Cheers,

Brian.

Bug#888571: python3-apt depends on python3 (<< 3.6)

[jean-christophe manciot]

@Axel Beckert


> That's wrong. The corresponding sources _are_ shown on
> https://packages.debian.org/source/sid/python-apt. It's the files
> called python-apt_1.4.0~beta3.dsc and python-apt_1.4.0~beta3.tar.xz
>
>
No, you're confused. The whole point of this bug report is that *building*
python-apt from the sources downloaded from https://packages.debian.
org/source/sid/python-apt is that the binary python3-apt is incompatible
with python3 >= 3.6.
If you try to built the packages from those sources, you'll discover that
the version is *1.4.0~beta3*, as indicated in debian/changelog.

No. Nowhere in Debian you will find a binary package without an
> according source package. Period.
>

It depends on what you call "sources". If you put the *debian* folder aside
from your definition, then we agree.

That might be an issue of your downloader.


You're right here. I downloaded the python-apt binaries with Google
chrome 64.0.3282.119 (Official Build) (64-bit) on Linux.
I have just reported that issue to Google.

-- 
Jean-Christophe Manciot

Bug#820901: Subject: Re: cantata: "Mark episodes as listened" in Podcasts doesn't work anymore [SOLVED]

[Volker Linke]

Package: cantata
Followup-For: Bug #820901

Dear Maintainer,

this bug is solved from the new upstream version in Sid.
Thanks.


-- 

Bug#888707: locale: Cannot set LC_ALL to default locale: No such file or directory

[Andreas Metzler]

On 2018-01-29 積丹尼 Dan Jacobson  wrote:
> Package: exim4-config
> Version: 4.90-5

> New errors never seen before:

> Setting up exim4-config (4.90-5) ...
> locale: Cannot set LC_ALL to default locale: No such file or directory
[...]

Hello,
Afaict the only place where the binary package changes locale settings
is in exim4-config.config:
alias coloncolon2oe="env -u LC_ALL LC_CTYPE=C sed -e "

And that part has not changed for a long time. :-(

Does
env -u LC_ALL LC_CTYPE=C /bin/echo blah
also throw the error on your system?

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

Bug#886294: transition: nodejs

[Philipp Kern]

On 2018-01-25 11:36, Aurelien Jarno wrote:
Bumping the baseline to z196 looks like the easiest way and as you 
said,
it would also fix go, rustc and maybe more software. However we 
discussed
raising the ISA to z10 about one year and a half ago, and the 
conclusion

was that we still have users with older machines. I'll try to restart
the discussion again.


What's the venue to have this discussion in? :)

Kind regards and thanks
Philipp Kern

Bug#658542: lintian: Does not report inconsistencies between "files" and "checksum" sections in changes file

[Chris Lamb]

tags 658542 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#823190: lintian: Please error out on orig tarball sigs for source 1.0

[Chris Lamb]

tags 823190 + pending
thanks

Fixed in Git, pending upload:

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


Regards,

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

Bug#888776: skycat: starting skycat fails with librtd3.2.1.so: cannot open shared object file

[Achim Bohnet]

Package: skycat
Version: 3.1.2+starlink1~b+dfsg-3
Severity: important

Dear Maintainer,

I've installed the package in ubuntu/artful. ask it's an unmodified package and
the lib seem to be missing in debian too, I thought I report it here:

$ sudo apt install skycat
...
$ skycat
Error in startup script: couldn't load file 
"/usr/lib/skycat/libskycat3.1.2.so": librtd3.2.1.so: cannot open shared object 
file: No such file or directory
while executing
"load /usr/lib/skycat/libskycat3.1.2.so Skycat"
("package ifneeded Skycat 3.1.2" script)
invoked from within
"package require Skycat"
(file "/usr/share/skycat/skycat3.1.2/main.tcl" line 7)

According to upstream librtd3 is part of skycat:
See http://starlink.rl.ac.uk/star/lib/

$ dpkg -L skycat | grep -i librtd | wc -l
0

-- System Information:
Debian Release: stretch/sid
  APT prefers artful-updates
  APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 
'artful'), (100, 'artful-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages skycat depends on:
ii  blt   2.5.3+dfsg-3
ii  itcl3 3.4.3-1
ii  itk3  3.4.2-1
ii  libc6 2.26-0ubuntu2.1
ii  libcfitsio5   3.410-1
ii  libgcc1   1:7.2.0-8ubuntu3
ii  libstdc++67.2.0-8ubuntu3
ii  libtk-img 1:1.4.6+dfsg-1
ii  libwcstools1  3.9.5-1
ii  libx11-6  2:1.6.4-3
ii  tcl-expect5.45-8
ii  tcl8.68.6.7+dfsg-1
ii  tk8.6 8.6.7-1ubuntu1
ii  tk8.6-blt2.5  2.5.3+dfsg-3

skycat recommends no packages.

skycat suggests no packages.

-- no debconf information

Bug#888252: py-radix: Incomplete debian/copyright?

[Ευάγγελος Αυγερινός]

Hello there,

Thanks for reporting, I missed that one.
I will fix the debian/copyright and make it DEP-5 asap.

Regards,

~ A

On Wed, Jan 24, 2018 at 12:10 PM, Chris Lamb  wrote:

> Source: py-radix
> Version: 0.10.0-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Aggelos Avgerinos 
>
> Hi,
>
> I just ACCEPTed py-radix from NEW but noticed it was missing
> attribution in debian/copyright for at least Michael J. Schultz
>
> (This is not exhaustive so please check over the entire package
> carefully and address these on your next upload.)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#888642: Starting blueman fails because /usr/bin/dbus-launch terminated abnormally without any error message

[Michelle Konzack]

OK, I have set a

   print(sys.path)

ito the blueman-applet to figure out, whats going on...

[ c '/usr/bin/blueman-applet' ]-
['/usr/bin', '/usr/lib/python35.zip', '/usr/lib/python3.5',
'/usr/lib/python3.5/plat-x86_64-linux-gnu',
'/usr/lib/python3.5/lib-dynload',
'/usr/local/lib/python3.5/dist-packages',
'/usr/lib/python3/dist-packages']
Traceback (most recent call last):
  File "./blueman-applet", line 17, in 
from blueman.Functions import create_logger, create_parser,
set_proc_title
ImportError: No module named 'blueman'


... and it seems, that debian is inserting

/usr/lib/python3/dist-packages

instead of

/usr/lib/python3/site-packages

But what is right or wrong?

Thanks in avance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

Bug#888749: libgnutls28-dev:i386 cannot be installed properly on x86-64 systems (multiarch incompatibility)

[Andreas Metzler]

Control: severity -1 wishlist

Bug#625845: limiting size of archives directory is still broken

[David Kalnischkies]

Hi,

On Mon, Jan 29, 2018 at 01:45:18PM +0100, Björn Lässig wrote:
> I just hit this bug(s) in apt.systemd.daily. What could I do, to fix this?

As Julian in #d-d on IRC already mentioned nobody is actively looking at
the cronjob(s); especially on the still more obscure additional features
it has.

Ideal would probably be if we could get these scripts to be covered by
a few tests (see tests/integration) as one of the reasons nobody touches
it is probably that if you don't use them yourself it is hard to check
if its working.

Any kind of test will greatly increase my willingness (and probably of
others, too) to merge a proposed patch.

If there are questions feel free to drop us a line her or elsewhere; we
are e.g. also around on IRC in #debian-apt.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#888774: mutt: Segfault when saving to a mailbox without write permission

[Christoph Biedl]

Package: mutt
Version: 1.7.2-1
Severity: important
Tags: patch

Dear Maintainer,

in short:

$ touch /tmp/mbox
$ chmod 444 /tmp/mbox
$ mutt -R -f 

Then save a message, select /tmp/mbox, hit enter ...

/tmp/mbox: Permission denied (errno = 13)
 Program received signal SIGSEGV, 
Segmentation fault.
  __GI___fileno (fp=0x0) at fileno.c:35
35  fileno.c: No such file or directory.
(gdb) bt
#0  __GI___fileno (fp=0x0) at fileno.c:35
#1  0x555ad8b6 in mbox_close_mailbox (ctx=0x7fffca80) at 
../../mbox.c:471
#2  0x555b721b in mx_fastclose_mailbox (ctx=0x7fffca80) at 
../../mx.c:721
#3  0x555b7642 in mx_open_mailbox (path=path@entry=0x7fffcbd0 
"/tmp/mbox", 
flags=flags@entry=2, pctx=pctx@entry=0x7fffca80) at ../../mx.c:639
#4  0x5557dc89 in mutt_save_message (h=0x55945540, delete=1, 
decode=0, 
decrypt=0, redraw=) at ../../commands.c:856
#5  0x5558c73c in mutt_index_menu () at ../../curs_main.c:2267
#6  0x5556cf16 in 

This looks a lot like #882468 but I could not reproduce this one,
hence a different bugreport.

This got fixed in testing, a source diff led to the patch below, works
for me. Please fix this in a point release - losing all the flags of an
opened mailbox is a major annoyance.

Regards,

Christoph

--- a/mbox.c
+++ b/mbox.c
@@ -466,7 +466,7 @@
 
 static int mbox_close_mailbox (CONTEXT *ctx)
 {
-  if (ctx->append)
+  if (ctx->append && ctx->fp)
   {
 mx_unlock_file (ctx->path, fileno (ctx->fp), 1);
 mutt_unblock_signals ();


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

System: Linux 4.14.13 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

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

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

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

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

Bug#888775: ekeyd FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: ekeyd
Version: 1.1.5-6.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ekeyd fails to cross build from source, because it uses the build
architecture compiler. Letting dh_auto_build pass a suitable compiler
via CC to make is the easiest way to fix that and indeed after doing so,
it cross builds successfully. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru ekeyd-1.1.5/debian/changelog ekeyd-1.1.5/debian/changelog
--- ekeyd-1.1.5/debian/changelog2017-02-04 16:42:08.0 +0100
+++ ekeyd-1.1.5/debian/changelog2018-01-29 19:52:35.0 +0100
@@ -1,3 +1,10 @@
+ekeyd (1.1.5-6.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Jan 2018 19:52:35 +0100
+
 ekeyd (1.1.5-6.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru ekeyd-1.1.5/debian/rules ekeyd-1.1.5/debian/rules
--- ekeyd-1.1.5/debian/rules2017-02-04 16:42:08.0 +0100
+++ ekeyd-1.1.5/debian/rules2018-01-29 19:52:12.0 +0100
@@ -8,7 +8,7 @@
$(MAKE) -C host clean
 
 override_dh_auto_build:
-   $(MAKE) -C host BUILD_ULUSBD=no
+   dh_auto_build --sourcedirectory=host -- BUILD_ULUSBD=no
 
 override_dh_auto_install:
install -m 644 munin/plugin-conf.d_ekeyd 
debian/ekeyd/etc/munin/plugin-conf.d/ekeyd

Bug#888773: silly FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: silly
Version: 0.1.0-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

silly fails to cross build from source, because it doesn't pass the
relevant --host flag to ./configure. The easiest way of doing so is
deferring that to dh_auto_configure and indeed after using it, silly
cross builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru silly-0.1.0/debian/changelog silly-0.1.0/debian/changelog
--- silly-0.1.0/debian/changelog2016-08-07 19:27:20.0 +0200
+++ silly-0.1.0/debian/changelog2018-01-29 19:36:41.0 +0100
@@ -1,3 +1,10 @@
+silly (0.1.0-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Jan 2018 19:36:41 +0100
+
 silly (0.1.0-8) unstable; urgency=medium
 
   * Bump Standards-Version to 3.9.8.
diff --minimal -Nru silly-0.1.0/debian/rules silly-0.1.0/debian/rules
--- silly-0.1.0/debian/rules2016-05-09 16:13:04.0 +0200
+++ silly-0.1.0/debian/rules2018-01-29 19:36:38.0 +0100
@@ -27,7 +27,7 @@
dh_autoreconf
dh_testdir
# Add here commands to configure the package.
-   ./configure --prefix=/usr --libdir=/usr/lib --includedir=/usr/include
+   dh_auto_configure -- --libdir=/usr/lib
 
 build: build-arch build-indep
 build-arch: build-stamp

Bug#886285: vim-runtime: tex syntax highlighting fails to enter math mode within align environment

[Francesco Poli]

Control: reopen -1
Control: severity -1 wishlist


On Sun, 28 Jan 2018 13:22:28 -0500 James McCoy wrote:

> On Sun, Jan 28, 2018 at 06:31:38PM +0100, Francesco Poli wrote:
> > On Wed, 03 Jan 2018 21:34:19 +0100 Francesco Poli (wintermute) wrote:
> > 
> > [...]
> > > Hello again!
> > > 
> > > I noticed another regression, this time in tex syntax highlighting.
> > [...]
> > 
> > Hello again,
> > is there any progress on this regression?
> 
> Support for align was dropped upstream.  See “:help ft-tex-syntax” and
> “:help tex-morecommands” for extending the tex syntax highlighting.

Mmmmh, ":help tex-morecommands" states, in part:

[...]
| please consider using the techniques in mysyntaxfile-add to extend
| or modify the highlighting provided by syntax/tex.vim.
| Please consider uploading any extensions that you write,
| which typically would go in $HOME/after/syntax/tex/[pkgname].vim, to
| http://vim.sf.net/


So I am puzzled: upstream dropped support for extended syntax provided
by LaTeX packages (such as, for instance, amsmath), but, at the same
time, suggest users to write extensions and contribute them upstream!

Do you find this confusing?
I do.

If they decided to only support basic LaTeX syntax, why do they
solicit contributions to support extended syntax?
If they want to support extended LaTeX syntax, why did they drop
support for one of the extensions (amsmath)?


Anyway, please consider mine as a wishlist bug, asking upstream
to re-enable support for amsmath syntax.

One possible source of extended LaTeX syntax support is the [vimtex]
(https://github.com/lervag/vimtex/) plugin (which, unfortunately, does
not seem to be included in Debian). Its syntax highlighting 
[addition](https://github.com/lervag/vimtex/blob/master/after/syntax/tex.vim)
seems to support a number of syntax extensions, including amsmath.


Please forward this bug report upstream.

Thanks for your time!
Bye.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpiCsb54jByc.pgp
Description: PGP signature

Bug#880111: closed by Alexander Zangerl <a...@debian.org> (Bug#880111: fixed in duplicity 0.7.16-1)

[Francesco Poli]

On Mon, 29 Jan 2018 08:24:56 +1000 Alexander Zangerl wrote:

> On Sun, 28 Jan 2018 12:13:34 +0100, Francesco Poli writes:
> >I upgraded to duplicity/0.7.16-1, but I still get the error on
> >incremental backups:
> 
> upstream considers having this 'error message that is just a notice message'
> to be _the_ fix. ie. benign and ignorable.

Thanks for the explanation.

However, this sounds really weird to me: if an error or warning message
is totally harmless and should be ignored by the user, the most sensible
thing to do is to suppress the message, so that it is not shown to the
user at all.

I suspect that upstream will get a good number of bug reports
about this in the months and years to come, until the spurious
message is finally suppressed...

Maybe the message should be suppressed once and for all?
The sooner, the better.

Do you agree?
Could you please forward these considerations upstream?

Thanks for your time.
Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpEhwg3BxLNn.pgp
Description: PGP signature

Bug#888772: xrdp FTCBFS: passes the empty string to -rpath

[Helmut Grohne]

Source: xrdp
Version: 0.9.5-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xrdp fails to cross build from source, because it passes an empty string
to -rpath and libtool doesn't like that. It turns out that $moduledir
ends up being empty, because it uses the wrong pkg-config to query for
it and doesn't trap failure from pkg-config. After fixing the relevant
configure.ac, the build moves along until the install-data-hook fails
running host tools. It turns out the effects of the install-data-hook
are nullified by the packaging, so we can just skip the whole hook.
After doing so, xrdp cross builds successfully. You can find the
cumulative changes in the attached patch.

Helmut
diff --minimal -Nru xrdp-0.9.5/debian/changelog xrdp-0.9.5/debian/changelog
--- xrdp-0.9.5/debian/changelog 2018-01-07 22:24:28.0 +0100
+++ xrdp-0.9.5/debian/changelog 2018-01-29 17:34:36.0 +0100
@@ -1,3 +1,12 @@
+xrdp (0.9.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Fix pkg-config usage.
++ Avoid useless install-data-hook running host programs.
+
+ -- Helmut Grohne   Mon, 29 Jan 2018 17:34:36 +0100
+
 xrdp (0.9.5-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru xrdp-0.9.5/debian/patches/cross.patch 
xrdp-0.9.5/debian/patches/cross.patch
--- xrdp-0.9.5/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ xrdp-0.9.5/debian/patches/cross.patch   2018-01-29 17:34:16.0 
+0100
@@ -0,0 +1,13 @@
+Index: xrdp-0.9.5/xorgxrdp/configure.ac
+===
+--- xrdp-0.9.5.orig/xorgxrdp/configure.ac
 xrdp-0.9.5/xorgxrdp/configure.ac
+@@ -29,7 +29,7 @@
+ if test "x$enable_strict_locations" = "xyes"; then
+   moduledir='${libdir}/xorg/modules'
+ else
+-  moduledir=`pkg-config xorg-server --variable=moduledir`
++  moduledir=`$PKG_CONFIG xorg-server --variable=moduledir`
+   sysconfdir="/etc"
+ fi
+ 
diff --minimal -Nru xrdp-0.9.5/debian/patches/series 
xrdp-0.9.5/debian/patches/series
--- xrdp-0.9.5/debian/patches/series2018-01-07 15:55:20.0 +0100
+++ xrdp-0.9.5/debian/patches/series2018-01-29 17:33:58.0 +0100
@@ -6,3 +6,4 @@
 systemd.diff
 lfs.diff
 pulse-debian.patch
+cross.patch
diff --minimal -Nru xrdp-0.9.5/debian/rules xrdp-0.9.5/debian/rules
--- xrdp-0.9.5/debian/rules 2018-01-07 17:07:53.0 +0100
+++ xrdp-0.9.5/debian/rules 2018-01-29 17:34:36.0 +0100
@@ -74,6 +74,10 @@
xargs -0 perl -pi -e 's!XRDP_PID_PATH.*?/run!$$&/xrdp!g' --
 
 override_dh_auto_install:
+   # prevent install-data-hook from generating these
+   mkdir -p debian/xrdp/etc/xrdp
+   touch debian/xrdp/etc/xrdp/rsakeys.ini
+   touch debian/xrdp/etc/xrdp/cert.pem
dh_auto_install -v --destdir=debian/xrdp
# remove unused/confusing files
rm -f debian/xrdp/etc/xrdp/xrdp.sh